Я может и хотел бы как разработчик, но с формальным подходом при сертификации ни разу не сталкивался. Ни в России, ни в США, ни в Германии. У вас практический опыт с каким регулятором и каким классом сертификации?
При сертификации в модели угроз предполагается, что исходники доступны нарушителю. Согласен, что многие продукты создаются без модели угроз и без внимания к безопасности вообще, но различные государства придумали различные механизмы сертификации как защиту от недобросовестного (или скорее безответственного) разработчика. А потребителям стоит обращать внимание на то, проверял ли кто-то предлагаемое решение и какие сертификаты имеются. Понятно, что это повышает требования и к самому покупателю, но за его безопасностью никакой добрый дядя не последит. Всегда можно выбирать — экономить или использовать более дорогие и проверенные решения. Например, можно использовать в своих виртуалках на Amazon просто openssl, а можно использовать сертифицированное FIPS решение в том же Amazon (не сочтите за рекламу, и подобные решения есть почти у всех провайдеров). При этом на социально значимых объектах как правило регуляторы требуют установку сертифицированных решений, у которых формализованы модели угроз. Наверное раньше было хуже, а сейчас становится чуть лучше. И я как разработчик это могу сказать, который описывает и реализует меры защиты на заявленные угрозы и это вовсе не формальный процесс, а настоящие инженерные задачи.
Доступ к конструкторской документации предполагается на всех уровнях. Иначе это Security through obscurity, а серьезные вещи так не проектируются. Вообще говоря, компания разработчик всегда считается нарушителем. Именно с этим нарушителем борется система сертификации и исследования сторонними организациями.
А при разработке продукта это означает, например, то, что нельзя в документации (в том числе в коде, который является ее частью) оставлять константных* ключей шифрования или паролей. Иначе нарушителю они будут известны из исходных кодов и он сможет взломать работающую систему. Вместо этого ключи должны формироваться с криптографического датчика случайных чисел в процессе ввода системы в эксплуатацию и периодически меняться. И тогда знание алгоритма шифрования без знания самого ключа шифрования не дает никаких преимуществ. Это, наверное, самый простой пример, но при этом является самой распространенной ошибкой разработчиков.
*Константный ключ — это не обязательно что-то простое, вроде 0x000000111111, что можно найти в коде автоматически, анализируя энтропию Шеннона в процессе сборки. Константный означает константу, которая не меняется в процессе работы, но при этом сама константа может быть «достаточно случайной». И их использование должно отлавливаться на этапе ревью проекта архитектуры.
Непонятно что мешает поднять цены и забирать сверхприбыль себе. Понятно, когда это разовый всплеск, а договоры поставки уже заключены. Но ситуация с видеокартами держится не первый год, а договоры поставки не бессрочные и пересмотр цен вполне возможен.
Все равно непонятно. Продаем майнерам в 5 раз дороже, чем могут купить обычные пользователи. Майнеры продают потом геймерам и покупают новые, опять в 5 раз дороже. Если карт не хватает, то значит спрос превышает предложение и логично увеличивать отпускную цену. Я так понимаю, что есть нюансы, но не совсем понимаю какие именно. И было бы интересно услышать ответ от производителя железа. Например, я бы понял ответ в виде того, что сопутствующие покупки игровых материнских плат приносят гораздо больше прибыли, чем продажа видеокарт, даже если в 5 раз дороже, но майнеры их не покупают. Ну или что-то в таком духе. А пока не ясно, что мешает установить высокую отпускную цену именно с завода.
А в чем интерес производителю ограничивать цены и препятствовать майнингу на их железе? Если покупатели готовы платить, то это же хорошо — можно повышать отгрузочные цены и заработать больше. Или я что-то не понимаю?
Понять можно довольно много. В п. 2.1 обозначены поставленные цели, а в п. 2.2 ссылки на классы защищенности для различных частей инфраструктуры. Требования ФСТЭК не являются закрытыми и так или иначе коррелируют с Common Criteria.
Методы защиты от нарушителя должны строится исходя из модели угроз и нарушителя. Можно немного порассуждать на эту тему как системный аналитик…
Для начала, непонятно откуда возникает требование проверить свой голос уже после голосования. Ведь с бумажным бюллетенем невозможно проверить свой голос после того как он смешался с другими бумажками. Т.е. изначально такого требования не было и странно его предъявлять в разрабатываемых электронных системах. При построении бумажной системы мы доверяем тому, что в системе не происходит подмены бумажных бюллетеней, но есть проблемы с нежеланием ходить на участки для голосования и есть вопросы к самодеятельности на местах (т.е. локальные нарушители).
Исходя из этого мне видится, что нам нужно гарантировать, что один человек подает только один голос, как это было в исходной системе, повысить доступность голосования и немного повысить безопасность всей процедуры.
Первая часть задачи решается аутентификацией с помощью Госуслуг (считаем это надежным способом). Сам голос инкрементирует счетчик того или иного кандидата, в системе нигде, даже в целях отладки, не должна сохраняться привязка токена аутентификации человека к значению голоса, только сам факт участия. Повторное голосование исключено, удобство достигнуто. Такое голосование можно считать тайным. Наличие тех или иных систем скрытого сбора данных можно выявлять путем независимого аудита исходных кодов системы голосования, т.е. публиковать их. Поскольку мы, как пользователи, доверяем государству (см. нашу модель угроз), то аудит могут (и должны) проводить эксперты из соответствующих ведомств. Аудит должен быть доступен всем желающим по причине того, что нарушителем в нашей модели являются также спецслужбы других государств и следует считать, что им исходные коды доступны. Поэтому security through obscurity не работает.
Сервера аутентификации и подсчета голосов не контролируются на местах, поэтому просто так вбросить бюллетени не выйдет. Проверить количество поданных голосов и сумму подсчитанных должны иметь возможность все желающие. При расхождении можно объявлять результаты недействительными на конкретном участке и проводить расследование на предмет вмешательства в работу системы.
Другими словами, электронное голосование — это просто более удобный формат, который заодно немного повышает требования к нарушителю. Но этот формат не ставит целью защищаться от нарушителя в виде государства, заказчик (государство) такой цели не ставит, т.е. это уже совсем другая задача и решаться должна иначе, в следующей версии продукта.
P.S. Я не имеют отношения к государству и к разработчикам данной системы, не знаю подробностей реализации. Это попытка посмотреть на эту систему, как на продукт с понятной моделью угроз и нарушителя.
Скорее я за то, чтобы было и то и другое, а каждый сам для себя решит что для него лично плохо или хорошо, без подсказок СМИ.
Наличие корреляции не означает наличие причинно-следственной связи. Уход ключевых сотрудников может коррелировать с шумихой в СМИ, но не обязательно является следствием обсуждаемых там вопросов.
Этим СМИ постоянно занимаются, как вы могли раньше не замечать.
Замечал и мне это не нравится)
Закон сам по себе не появится. Надо поднимать бучу в СМИ, чтобы законодатели видели, что для людей это важно. И тогда может что-то сдвинется.
Дело в том, что СМИ также не принадлежат людям и мы не знаем кто является конечным бенефициаром этой шумихи. СМИ позволяют капиталу манипулировать общественным мнением, а не наоборот. Механизм взаимодействия с законодателем мне видится в прямом обращении граждан к своим представителям — депутатам, конгрессменам, сенаторам и т.п.
И в целом я ничего не имею против широкого обсуждения тех или иных вопросов в СМИ, мне не нравится именно привязка к отдельным компаниям.
сказать, что взять негра на роль белоснежки было ошибкой
Если взять это в качестве примера, то я за то, чтобы можно было критиковать это решение и иметь право не покупать билеты на подобные экранизации, но я против закона, который запрещает Диснею снимать негров в роли белоснежки или, наоборот, заставляет это делать.
Книга, действительно, рассматривает реальность с одной стороны, просто с другой. Всегда полезно держать в голове взгляд с нескольких сторон и понимать плюсы и минусы каждой, даже если эмоционально или на основе своего опыта и личного интереса поддерживаешь какую-то одну.
Недоумение скорее не про то, что работники имеют свое мнение — это как раз нормально и правильно. А в том, что люди вообще (в данном случае СМИ), которые не имеют к этой теме прямого отношения, пытаются влиять на общественное мнение, акцентируя внимание не на вопросе в целом, а именно в контексте данной компании (а я уверен, что недовольные есть в любой), что для меня, как потенциального конечного потребителя их продукции, это может вылиться в снижении качества и/или повышении цен на товары.
Я бы поддержал полностью общественную дискуссию на тему дать ли право сотрудникам (любых компаний) выбирать способ работы и выбирать как тратить свое рабочее время. И, если общий закон передаст право принятия этого решения сотрудникам, то это будет частью общественного договора, и, возможно, приведет к поднятию налогов или снижениям зарплат в целом, но не создаст худших условий для одной единственной компании.
Работники компании считают, что текущая ситуация не оказала негативного воздействия на бизнес Apple и компании нужно принять пожелания сотрудников, а не отстраняться от них.
Печально, что люди начинают забывать, что компания принадлежит не работникам, а владельцам, то есть тем, кто рискует капиталом принимая те или иные решения. Книга «Атлант расправил плечи» выглядит тут пророческой…
Что-то подобное про ставки было описано у Matthew Mather в книге Darknet, выглядит устрашающе. Может быть это уже происходит и мы не можем быть точно уверены, что нет.
При регистрации в Минцифре как IT-компании страховые взносы можно было уменьшить с 30% до 14%. А сейчас льгот стало еще больше. Регистрация – это по сути просто письмо написать.
Какой моделью угроз и нарушителей вы руководствовались, когда реализовывали меры защиты и проектировали ролевую модель? Можно где-то почитать формальное описание модели угроз?
есть ненулевая вероятность выпиливания уже принятого в стандарт хэша Стрибог (с тем же SBox), а так же RFC 7801, в котором описан Кузнечик.
RFC 7801 тут зря упомянули. Во-первых, что-то «выпилить» из RFC вообще вряд ли возможно. Надо понимать, что RFC никого ни к чему не обязывает. Во-вторых, RFC 7801 вообще INFORMATIONAL. Это тоже самое, что предложить «выпилить» RFC 3514.
Хотел бы особо отметить, что я не вкладывают никакого особого смысла при выборе RFC 3514, он просто иллюстрирует абсурдность идеи «выпиливания» чего-либо из RFC.
В РФ можете попробовать подать декларацию в электронном виде на nalog.ru. Копии подтверждающих документов также в электронном виде прикрепляются. Я так подаю несколько лет — проблем не было, возвраты налогов стабильно приходят на указанный счет. Если им вдруг нужны оригиналы документов, то высылаете почтой. Оригиналы за все время требовались только на медицинские расходы.
У меня только один вопрос — о чем эта новость? Варианты ответа:
1. Это пиар акция Яндекса, который типа стоит на защите данных пользователей и не отдает их ключи. Как попытка реабилитироваться после отчета RDR.
2. Яндекс хочет привлечь внимание общественности, чтобы не городить механизм хранения сессионных ключей, т.к. это лишние затраты.
3. Все нужные ключи уже давно отдали. А это слив инфы от (не)правильно информированных сотрудников.
4. Яндекс работает по HTTP («работает в полном соответствии с действующим законодательством»), а шифрованием занимается голландский CDN — вот к ним и обращайтесь.
5. Свой вариант.
Допустим, я захотел создать приватный навык, чтобы голосом сообщать Алисе, что «с*** опять отключили горячую воду». В результате должны переключиться маршруты воды путем закрытия/открытия набора вентелей и включиться бойлер (допустим, краны и реле бойлера управляются с Arduino). Arduino пусть будет подключена к Raspberry, где реализуется HTTP API с функциями открыть/закрыть вентиль, и включить/выключить бойлер. Схема реализуется через сценарий, и также можно реализовать сценарий «все, я в отпуск», когда вообще вся вода перекроется и т.п. — это все понятно. Возникли вопросы:
1. Хочу потестировать, но после заполнения полей можно только отправить на модерацию. А тестировать как? В документации говорится про некую вкладку Тестирование, но такого в консоли разработчика нет. Нужно что-то специальное для этого сделать?
2. Возможно ли сконфигурировать систему так, чтобы запросы шли только в локальной изолированной подсети от локальной Станции, а не от серверов Яндекса? Не хочется API управления водой отдавать в интернет — вдруг (наверняка) у меня там уязвимости. Ну и регистрация домена только для своего дома так себе идея.
Я понимаю, что расчет больше на крупных вендеров, но ведь завоевание рынка всегда идет через энтузиастов )
В какой-то момент пытался восстановить свои старые 5.25" диски для Spectrum. Некоторые утилиты написал на Python, некоторые выложил на GitHub. Есть там и парсер Hobeta со встроенной справкой о формате.
Времени катастрофически не хватает развивать этот проект, но он не заброшен. Пул-риквесты приветствуются.
А при разработке продукта это означает, например, то, что нельзя в документации (в том числе в коде, который является ее частью) оставлять константных* ключей шифрования или паролей. Иначе нарушителю они будут известны из исходных кодов и он сможет взломать работающую систему. Вместо этого ключи должны формироваться с криптографического датчика случайных чисел в процессе ввода системы в эксплуатацию и периодически меняться. И тогда знание алгоритма шифрования без знания самого ключа шифрования не дает никаких преимуществ. Это, наверное, самый простой пример, но при этом является самой распространенной ошибкой разработчиков.
*Константный ключ — это не обязательно что-то простое, вроде 0x000000111111, что можно найти в коде автоматически, анализируя энтропию Шеннона в процессе сборки. Константный означает константу, которая не меняется в процессе работы, но при этом сама константа может быть «достаточно случайной». И их использование должно отлавливаться на этапе ревью проекта архитектуры.
Для начала, непонятно откуда возникает требование проверить свой голос уже после голосования. Ведь с бумажным бюллетенем невозможно проверить свой голос после того как он смешался с другими бумажками. Т.е. изначально такого требования не было и странно его предъявлять в разрабатываемых электронных системах. При построении бумажной системы мы доверяем тому, что в системе не происходит подмены бумажных бюллетеней, но есть проблемы с нежеланием ходить на участки для голосования и есть вопросы к самодеятельности на местах (т.е. локальные нарушители).
Исходя из этого мне видится, что нам нужно гарантировать, что один человек подает только один голос, как это было в исходной системе, повысить доступность голосования и немного повысить безопасность всей процедуры.
Первая часть задачи решается аутентификацией с помощью Госуслуг (считаем это надежным способом). Сам голос инкрементирует счетчик того или иного кандидата, в системе нигде, даже в целях отладки, не должна сохраняться привязка токена аутентификации человека к значению голоса, только сам факт участия. Повторное голосование исключено, удобство достигнуто. Такое голосование можно считать тайным. Наличие тех или иных систем скрытого сбора данных можно выявлять путем независимого аудита исходных кодов системы голосования, т.е. публиковать их. Поскольку мы, как пользователи, доверяем государству (см. нашу модель угроз), то аудит могут (и должны) проводить эксперты из соответствующих ведомств. Аудит должен быть доступен всем желающим по причине того, что нарушителем в нашей модели являются также спецслужбы других государств и следует считать, что им исходные коды доступны. Поэтому security through obscurity не работает.
Сервера аутентификации и подсчета голосов не контролируются на местах, поэтому просто так вбросить бюллетени не выйдет. Проверить количество поданных голосов и сумму подсчитанных должны иметь возможность все желающие. При расхождении можно объявлять результаты недействительными на конкретном участке и проводить расследование на предмет вмешательства в работу системы.
Другими словами, электронное голосование — это просто более удобный формат, который заодно немного повышает требования к нарушителю. Но этот формат не ставит целью защищаться от нарушителя в виде государства, заказчик (государство) такой цели не ставит, т.е. это уже совсем другая задача и решаться должна иначе, в следующей версии продукта.
P.S. Я не имеют отношения к государству и к разработчикам данной системы, не знаю подробностей реализации. Это попытка посмотреть на эту систему, как на продукт с понятной моделью угроз и нарушителя.
Наличие корреляции не означает наличие причинно-следственной связи. Уход ключевых сотрудников может коррелировать с шумихой в СМИ, но не обязательно является следствием обсуждаемых там вопросов.
Замечал и мне это не нравится)
Дело в том, что СМИ также не принадлежат людям и мы не знаем кто является конечным бенефициаром этой шумихи. СМИ позволяют капиталу манипулировать общественным мнением, а не наоборот. Механизм взаимодействия с законодателем мне видится в прямом обращении граждан к своим представителям — депутатам, конгрессменам, сенаторам и т.п.
И в целом я ничего не имею против широкого обсуждения тех или иных вопросов в СМИ, мне не нравится именно привязка к отдельным компаниям.
Если взять это в качестве примера, то я за то, чтобы можно было критиковать это решение и иметь право не покупать билеты на подобные экранизации, но я против закона, который запрещает Диснею снимать негров в роли белоснежки или, наоборот, заставляет это делать.
Недоумение скорее не про то, что работники имеют свое мнение — это как раз нормально и правильно. А в том, что люди вообще (в данном случае СМИ), которые не имеют к этой теме прямого отношения, пытаются влиять на общественное мнение, акцентируя внимание не на вопросе в целом, а именно в контексте данной компании (а я уверен, что недовольные есть в любой), что для меня, как потенциального конечного потребителя их продукции, это может вылиться в снижении качества и/или повышении цен на товары.
Я бы поддержал полностью общественную дискуссию на тему дать ли право сотрудникам (любых компаний) выбирать способ работы и выбирать как тратить свое рабочее время. И, если общий закон передаст право принятия этого решения сотрудникам, то это будет частью общественного договора, и, возможно, приведет к поднятию налогов или снижениям зарплат в целом, но не создаст худших условий для одной единственной компании.
Печально, что люди начинают забывать, что компания принадлежит не работникам, а владельцам, то есть тем, кто рискует капиталом принимая те или иные решения. Книга «Атлант расправил плечи» выглядит тут пророческой…
RFC 7801 тут зря упомянули. Во-первых, что-то «выпилить» из RFC вообще вряд ли возможно. Надо понимать, что RFC никого ни к чему не обязывает. Во-вторых, RFC 7801 вообще INFORMATIONAL. Это тоже самое, что предложить «выпилить» RFC 3514.
Хотел бы особо отметить, что я не вкладывают никакого особого смысла при выборе RFC 3514, он просто иллюстрирует абсурдность идеи «выпиливания» чего-либо из RFC.
1. Это пиар акция Яндекса, который типа стоит на защите данных пользователей и не отдает их ключи. Как попытка реабилитироваться после отчета RDR.
2. Яндекс хочет привлечь внимание общественности, чтобы не городить механизм хранения сессионных ключей, т.к. это лишние затраты.
3. Все нужные ключи уже давно отдали. А это слив инфы от (не)правильно информированных сотрудников.
4. Яндекс работает по HTTP («работает в полном соответствии с действующим законодательством»), а шифрованием занимается голландский CDN — вот к ним и обращайтесь.
5. Свой вариант.
1. Хочу потестировать, но после заполнения полей можно только отправить на модерацию. А тестировать как? В документации говорится про некую вкладку Тестирование, но такого в консоли разработчика нет. Нужно что-то специальное для этого сделать?
2. Возможно ли сконфигурировать систему так, чтобы запросы шли только в локальной изолированной подсети от локальной Станции, а не от серверов Яндекса? Не хочется API управления водой отдавать в интернет — вдруг (наверняка) у меня там уязвимости. Ну и регистрация домена только для своего дома так себе идея.
Я понимаю, что расчет больше на крупных вендеров, но ведь завоевание рынка всегда идет через энтузиастов )
Времени катастрофически не хватает развивать этот проект, но он не заброшен. Пул-риквесты приветствуются.