Пришла как-то к нам заявка на услуги облака. Мы прикинули в общих чертах, что от нас потребуется, и отправили в ответ список вопросов для уточнения деталей. Затем проанализировали ответы и поняли: заказчик хочет размещать в облаке персональные данные второго уровня защищенности. Отвечаем ему: «У вас второй уровень персданных, извините, можем только частное облако сделать». А он: «Знаете, а вот в компании X мне могут все и в публичном разместить».
Фото Steve Crisp, Reuters
Странные дела! Мы пошли на сайт компании X, изучили их аттестационные документы, покачали головами и поняли: открытых вопросов в размещении персданных очень много и их стоит хорошенько провентилировать. Чем мы и займемся в этом посте.
Для начала разберемся, по каким признакам персональные данные вообще относят к тому или иному уровню защищенности. Это зависит от категории данных, от количества субъектов этих данных, которые хранит и обрабатывает оператор, а также от типа актуальных угроз.
Определение типов актуальных угроз приведено в постановлении Правительства РФ №1119 от 1 ноября 2012 г. «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»:
Основное в этих определениях — наличие недокументированных (недекларированных) возможностей. Для подтверждения отсутствия недокументированных возможностей ПО (в случае с облаком это гипервизор) проводится сертификация ФСТЭК России. Если оператор ПДн принимает, что таких возможностей в ПО нет, то и соответствующие угрозы неактуальны. Угрозы 1-го и 2-го типов операторы ПДн крайне редко принимают актуальными.
Помимо определения уровня защищенности ПДн оператор должен также определить конкретные актуальные угрозы для публичного облака и, исходя из выявленного уровня защищенности ПДн и актуальных угроз, определить необходимые меры и средства защиты от них.
У ФСТЭК все основные угрозы четко перечислены в БДУ (банке данных угроз). Провайдеры и аттестаторы облачных инфраструктур в работе используют эту базу. Вот примеры угроз:
Защититься от этих угроз можно только с помощью гипервизора, поскольку именно он управляет виртуальными ресурсами. Таким образом, гипервизор необходимо рассматривать как средство защиты.
И в соответствии с приказом ФСТЭК №21 от 18 февраля 2013 г., гипервизор должен пройти сертификацию на отсутствие НДВ по 4 уровню, иначе использование персональных данных 1 и 2 уровня с ним будет незаконно («п.12. … Для обеспечения 1 и 2 уровней защищенности персональных данных, а также для обеспечения 3 уровня защищенности персональных данных в информационных системах, для которых к актуальным отнесены угрозы 2-го типа, применяются средства защиты информации, программное обеспечение которых прошло проверку не ниже чем по 4 уровню контроля отсутствия недекларированных возможностей»).
Нужным уровнем сертификации, НДВ-4, обладает только один гипервизор, российской разработки — Горизонт ВС. Мягко говоря, не самое популярное решение. Коммерческие облака, как правило, строятся на базе VMware vSphere, KVM, Microsoft Hyper-V. Ни один из этих продуктов не имеет сертификации на НДВ-4. Почему? Вероятно, получение такой сертификации для производителей пока экономически не оправдано.
И остается нам для персданных 1 и 2 уровня в публичном облаке лишь Горизонт ВС. Sad but true.
На первый взгляд, все достаточно строго: указанные угрозы должны устраняться правильной настройкой штатных механизмов защиты гипервизора, сертифицированного по НДВ-4. Но есть одна лазейка. В соответствии с Приказом ФСТЭК №21 («п.2 Безопасность персональных данных при их обработке в информационной системе персональных данных (далее — информационная система) обеспечивает оператор или лицо, осуществляющее обработку персональных данных по поручению оператора в соответствии с законодательством Российской Федерации»), провайдеры самостоятельно оценивают актуальность возможных угроз и в соответствии с этим выбирают меры защиты. Поэтому, если не принять актуальными угрозы УБИ.44 и УБИ.101, то не возникнет и потребности использовать сертифицированный по НДВ-4 гипервизор, который как раз и должен обеспечивать защиту от них. И этого будет достаточно для получения аттестата соответствия публичного облака 1 и 2 уровням защищенности ПДн, которым будет вполне удовлетворен Роскомнадзор.
Конечно, помимо Роскомнадзора с проверкой может прийти ФСТЭК — и эта организация куда более дотошна в технических вопросах. Ее наверняка заинтересует, почему именно угрозы УБИ.44 и УБИ.101 были признаны неактуальными? Но обычно ФСТЭК предпринимает проверку только когда получает информацию о каком-то ярком инциденте. В этом случае федеральная служба сначала приходит к оператору персданных — то есть заказчику облачных услуг. В худшем случае, оператор получает небольшой штраф — например, для Twitter в начале года штраф в похожем случае составил 5000 рублей. Затем ФСТЭК идет дальше, к провайдеру облачных услуг. Которого вполне может лишить лицензии из-за невыполнения нормативных требований — а это уже совсем другие риски, как для облачного провайдера, так и для его клиентов. Но, повторяюсь, для проверки ФСТЭК обычно нужен четкий повод. Так что облачные провайдеры готовы идти на риск. До первого серьезного инцидента.
Есть еще группа «более ответственных» провайдеров, которые считают, что можно закрыть все угрозы, дополнив гипервизор надстройкой типа vGate. Но в распределенной между заказчиками виртуальной среде для некоторых угроз (например, приведенной выше УБИ.101) действенный механизм защиты можно реализовать только на уровне сертифицированного по НДВ-4 гипервизора, поскольку любые системы-надстройки на штатные функции работы гипервизора по управлению ресурсами (в частности, оперативной памятью) не влияют.
У нас есть облачный сегмент, реализованный на гипервизоре, сертифицированном ФСТЭК (но без сертификации на НДВ-4). Этот сегмент аттестован, так что в облаке на его основе можно размещать персональные данные 3 и 4 уровней защищенности — требования по защите от недекларированных возможностей здесь соблюдать не нужно. Вот, кстати, архитектура нашего защищенного сегмента облака:
Системы для персональных данных 1 и 2 уровней защищенности мы реализуем только на выделенном оборудовании. Лишь в этом случае, например, угроза УБИ.101 действительно не актуальна, поскольку серверные стойки, не объединенные одной виртуальной средой, не могут влиять друг на друга даже при размещении в одном ЦОД. Для таких случаев мы предлагаем услугу аренды выделенного оборудования (ее еще называют Hardware as a service, оборудование как сервис).
Если же вы не уверены, какой уровень защищенности требуется для вашей системы персональных данных, мы также помогаем в их классификации.
Наше небольшое исследование рынка показало: некоторые облачные операторы для получения заказа вполне готовы рискнуть и безопасностью данных клиентов, и собственным будущим. Но мы в этих вопросах придерживаемся иной политики, которую вкратце описали чуть выше. Будем рады ответить в комментариях на ваши вопросы.
Фото Steve Crisp, Reuters
Странные дела! Мы пошли на сайт компании X, изучили их аттестационные документы, покачали головами и поняли: открытых вопросов в размещении персданных очень много и их стоит хорошенько провентилировать. Чем мы и займемся в этом посте.
Как все должно работать
Для начала разберемся, по каким признакам персональные данные вообще относят к тому или иному уровню защищенности. Это зависит от категории данных, от количества субъектов этих данных, которые хранит и обрабатывает оператор, а также от типа актуальных угроз.
Определение типов актуальных угроз приведено в постановлении Правительства РФ №1119 от 1 ноября 2012 г. «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»:
«Угрозы 1-го типа актуальны для информационной системы, если для нее в том числе актуальны угрозы, связанные с наличием недокументированных (недекларированных) возможностей в системном программном обеспечении, используемом в информационной системе.
Угрозы 2-го типа актуальны для информационной системы, если для нее в том числе актуальны угрозы, связанные с наличием недокументированных (недекларированных) возможностей в прикладном программном обеспечении, используемом в информационной системе.
Угрозы 3-го типа актуальны для информационной системы, если для нее актуальны угрозы, не связанные с наличием недокументированных (недекларированных) возможностей в системном и прикладном программном обеспечении, используемом в информационной системе.»
Основное в этих определениях — наличие недокументированных (недекларированных) возможностей. Для подтверждения отсутствия недокументированных возможностей ПО (в случае с облаком это гипервизор) проводится сертификация ФСТЭК России. Если оператор ПДн принимает, что таких возможностей в ПО нет, то и соответствующие угрозы неактуальны. Угрозы 1-го и 2-го типов операторы ПДн крайне редко принимают актуальными.
Помимо определения уровня защищенности ПДн оператор должен также определить конкретные актуальные угрозы для публичного облака и, исходя из выявленного уровня защищенности ПДн и актуальных угроз, определить необходимые меры и средства защиты от них.
У ФСТЭК все основные угрозы четко перечислены в БДУ (банке данных угроз). Провайдеры и аттестаторы облачных инфраструктур в работе используют эту базу. Вот примеры угроз:
УБИ.44: «Угроза заключается в возможности нарушения безопасности пользовательских данных программ, функционирующих внутри виртуальной машины, вредоносным программным обеспечением, функционирующим вне виртуальной машины». Данная угроза обусловлена наличием уязвимостей программного обеспечения гипервизора, обеспечивающего изолированность адресного пространства, используемого для хранения пользовательских данных программ, функционирующих внутри виртуальной машины, от несанкционированного доступа со стороны вредоносного программного обеспечения, функционирующего вне виртуальной машины.
Реализация данной угрозы возможна при условии успешного преодоления вредоносным программным кодом границ виртуальной машины не только за счёт эксплуатации уязвимостей гипервизора, но и путем осуществления такого воздействия с более низких (по отношению к гипервизору) уровней функционирования системы».
УБИ.101: «Угроза заключается в возможности осуществления несанкционированного доступа к защищаемой информации одного потребителя облачных услуг со стороны другого. Данная угроза обусловлена тем, что из-за особенностей облачных технологий потребителям облачных услуг приходится совместно использовать одну и ту же облачную инфраструктуру. Реализация данной угрозы возможна в случае допущения ошибок при разделении элементов облачной инфраструктуры между потребителями облачных услуг, а также при изоляции их ресурсов и обособлении данных друг от друга».
Защититься от этих угроз можно только с помощью гипервизора, поскольку именно он управляет виртуальными ресурсами. Таким образом, гипервизор необходимо рассматривать как средство защиты.
И в соответствии с приказом ФСТЭК №21 от 18 февраля 2013 г., гипервизор должен пройти сертификацию на отсутствие НДВ по 4 уровню, иначе использование персональных данных 1 и 2 уровня с ним будет незаконно («п.12. … Для обеспечения 1 и 2 уровней защищенности персональных данных, а также для обеспечения 3 уровня защищенности персональных данных в информационных системах, для которых к актуальным отнесены угрозы 2-го типа, применяются средства защиты информации, программное обеспечение которых прошло проверку не ниже чем по 4 уровню контроля отсутствия недекларированных возможностей»).
Нужным уровнем сертификации, НДВ-4, обладает только один гипервизор, российской разработки — Горизонт ВС. Мягко говоря, не самое популярное решение. Коммерческие облака, как правило, строятся на базе VMware vSphere, KVM, Microsoft Hyper-V. Ни один из этих продуктов не имеет сертификации на НДВ-4. Почему? Вероятно, получение такой сертификации для производителей пока экономически не оправдано.
И остается нам для персданных 1 и 2 уровня в публичном облаке лишь Горизонт ВС. Sad but true.
Как все (на наш взгляд) работает на самом деле
На первый взгляд, все достаточно строго: указанные угрозы должны устраняться правильной настройкой штатных механизмов защиты гипервизора, сертифицированного по НДВ-4. Но есть одна лазейка. В соответствии с Приказом ФСТЭК №21 («п.2 Безопасность персональных данных при их обработке в информационной системе персональных данных (далее — информационная система) обеспечивает оператор или лицо, осуществляющее обработку персональных данных по поручению оператора в соответствии с законодательством Российской Федерации»), провайдеры самостоятельно оценивают актуальность возможных угроз и в соответствии с этим выбирают меры защиты. Поэтому, если не принять актуальными угрозы УБИ.44 и УБИ.101, то не возникнет и потребности использовать сертифицированный по НДВ-4 гипервизор, который как раз и должен обеспечивать защиту от них. И этого будет достаточно для получения аттестата соответствия публичного облака 1 и 2 уровням защищенности ПДн, которым будет вполне удовлетворен Роскомнадзор.
Конечно, помимо Роскомнадзора с проверкой может прийти ФСТЭК — и эта организация куда более дотошна в технических вопросах. Ее наверняка заинтересует, почему именно угрозы УБИ.44 и УБИ.101 были признаны неактуальными? Но обычно ФСТЭК предпринимает проверку только когда получает информацию о каком-то ярком инциденте. В этом случае федеральная служба сначала приходит к оператору персданных — то есть заказчику облачных услуг. В худшем случае, оператор получает небольшой штраф — например, для Twitter в начале года штраф в похожем случае составил 5000 рублей. Затем ФСТЭК идет дальше, к провайдеру облачных услуг. Которого вполне может лишить лицензии из-за невыполнения нормативных требований — а это уже совсем другие риски, как для облачного провайдера, так и для его клиентов. Но, повторяюсь, для проверки ФСТЭК обычно нужен четкий повод. Так что облачные провайдеры готовы идти на риск. До первого серьезного инцидента.
Есть еще группа «более ответственных» провайдеров, которые считают, что можно закрыть все угрозы, дополнив гипервизор надстройкой типа vGate. Но в распределенной между заказчиками виртуальной среде для некоторых угроз (например, приведенной выше УБИ.101) действенный механизм защиты можно реализовать только на уровне сертифицированного по НДВ-4 гипервизора, поскольку любые системы-надстройки на штатные функции работы гипервизора по управлению ресурсами (в частности, оперативной памятью) не влияют.
Как работаем мы
У нас есть облачный сегмент, реализованный на гипервизоре, сертифицированном ФСТЭК (но без сертификации на НДВ-4). Этот сегмент аттестован, так что в облаке на его основе можно размещать персональные данные 3 и 4 уровней защищенности — требования по защите от недекларированных возможностей здесь соблюдать не нужно. Вот, кстати, архитектура нашего защищенного сегмента облака:
Системы для персональных данных 1 и 2 уровней защищенности мы реализуем только на выделенном оборудовании. Лишь в этом случае, например, угроза УБИ.101 действительно не актуальна, поскольку серверные стойки, не объединенные одной виртуальной средой, не могут влиять друг на друга даже при размещении в одном ЦОД. Для таких случаев мы предлагаем услугу аренды выделенного оборудования (ее еще называют Hardware as a service, оборудование как сервис).
Если же вы не уверены, какой уровень защищенности требуется для вашей системы персональных данных, мы также помогаем в их классификации.
Вывод
Наше небольшое исследование рынка показало: некоторые облачные операторы для получения заказа вполне готовы рискнуть и безопасностью данных клиентов, и собственным будущим. Но мы в этих вопросах придерживаемся иной политики, которую вкратце описали чуть выше. Будем рады ответить в комментариях на ваши вопросы.
amarao
Скажите, а сертификация ФСТЭК гарантирует отсутствие недокументированных возможностей в сертифицированном ПО?
Например, ФСТЭК сказала, что недокументированной возможности выполнять код без авторизации нет, а завтра CVE в которой написано, что возможность есть.
Что происходит?
а) ФСТЭК признаёт, что лохи и не могут решить задачу остановки.
б) Роскомнадзор блокирует доступ к страничке CVE на митре.
в) Написавшего об этом сажают как экстремиста (на территории страны) или кормят следующими двумя буквами из таблицы Менделеева (за пределами).
г) Все делают вид, что так и должно быть.
Я не понимаю, какой из вариантов реализуется. Объясните мне, неразумному. Спасибо.
ADanielyan Автор
Сертификация ФСТЭК не предполагает выдачу гарантий. Естественно, в сертифицированном ПО могут остаться незамеченными как недекларированные возможности, так и уязвимости. Но сама система сертификации направлена на то, чтобы минимизировать такие риски. ФСТЭК обязывает производителей сертифицированного ПО незамедлительно устранять выявленные уязвимости и недекларированные возможности. Вот выдержка из приказа 55 ФСТЭК от 3 апреля 2018 г. по сертификации:
«11. Заявители должны обеспечивать соответствие сертифицированных средств защиты информации требованиям по безопасности информации, а также осуществлять устранение недостатков и дефектов средств защиты информации, в том числе устранение уязвимостей и недекларированных возможностей программного обеспечения средств защиты информации, информирование потребителей об обновлении программного обеспечения средств защиты информации, доведение до потребителей обновлений программного обеспечения средств защиты информации, а также изменений в эксплуатационную документацию».
Иначе действие сертификата будет приостановлено (из того же Приказа):
«83. Действие сертификата соответствия приостанавливается в случаях:
…
установления факта несоответствия сертифицированного средства защиты информации требованиям по безопасности информации на основании поступившей в ФСТЭК России информации, в том числе о наличии в сертифицированном средстве защиты информации уязвимостей или недекларированных возможностей;
…»
Поэтому, реализуется вариант «д», который у Вас не приведен:
д) Заявитель/производитель оперативно устраняет выявленную проблему в сертифицированном ПО.
amarao
Отлично! Софт с апдейтами.
Дано: apt get install qemu-system-x86. С апдейтами! Производитель оперативно устраняет выявленную проблему в несертифицированном ПО.
Дано: сертификат ФСТЭК. Всё то же самое, только с сертификатом.
И зачем нам тогда сертификат? И вся процедура сертификации, когда кто-то (всего лишь человечишка) так же тупит в сырцы как в них тупит и программист — к чему она?
Ведь сертифицирующие товарищи — они же даже баги не репортят. Т.е. пользы от ФСТЭК куда меньше, чем от первого попавшегося линтера или фаззи-тестера.
Зато сколько слов "должны".
Вот если я стану Президентом РФ, то я издам указ о том, что все ДОЛЖНЫ писать софт, который ДОЛЖЕН работать без багов. И все будут ДОЛЖНЫ писать софт без багов. ДОЛЖНЫ ДОЛЖНЫ ДОЛЖНЫ. И даже обязаны.
ADanielyan Автор
Dura lex sed lex — закон суров, но это закон.
amarao
Голосовать ногами, а закон выполнять в минимально необходимой степени, чтобы отстали.
Обычно, в обществе, есть идея, что законы придумываются для того, чтобы людям жить лучше было, а бесполезные законы отменяют или даже не принимают в первую очередь.
… или я что-то за последние годы упустил в политике РФ?
d_olex
For fucks sake, она направленна только на то, что бы поддерживать безбедное существование руководства очередной бесполезной госконторы федерального уровня.
Угу, при том что примерно все мировые производители промышленно используемого ПО успешно делают это без внешних регулирующих органов.
mayorovp
Но ведь процесс получения сертификата ФСТЭК замедляет выход обновлений, из-за чего сертифицированное ПО всегда немного устаревшее и дырявое.
Или я чего-то пропустил, и всё давно поменялось?
teecat
все верно, только сильно устаревшее
d_olex
Однажды я дропнул в фулл дисклож эксплойт для high severity 0day уязвимости в отечественном СЗИ сертифицированном для защиты гостайны, ФСТЭК не имел ко мне каких-либо претензий и даже поставил ссылку на мой блог в своем реестре уязвимостей. Короче говоря, там сидят куда менее дубовые чуваки чем кажется на первый взгляд.
amarao
Они во время сертификации код глазами смотрят? Что делают, если баги видят?
d_olex
Не смотрят потому что это нереально от слова совсем. Если они каким-то чудом захантят всех-всех-всех vulnerability researcher-ов которым к настоящему моменту времени не повезло жить на территории РФ и посадят их 24/7 аудировать код всего того говна на которое ФСТЭК выдает сертификаты — даже этой армии не хватит.
amarao
Т.е. пользы от них никакой.
d_olex
Вода мокрая, трава зеленая, новости в 9.
Protos
Этим занимаются лаборатории и совсем не всегда сам ФСТЭК
d_olex
д) ФСТЭК ведет свой реестр уязвимостей и пинает вендоров на предмет фиксов, в особо запущенных случаях (в теории) отзывает сертификацию их продуктов.
SatumQuata
Простите, а почему вы путаете две разные вещи?
Согласно определению ФСТЭК они ищут:
2.1. Недекларированные возможности — функциональные возможности ПО, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации (ссылка на РД).
А вы говорите про уязвимости программного обеспечения, на которые ФСТЭК не смотрит от слова совсем.
Если бы ФСТЭК вместо производителя проверял на наличие уявимостей и работоспособность ПО, то кол-во сертифицированных средств защиты было бы близко к нулю.
amarao
О! А расскажите мне, в чём разница между RCE-CVE и бэкдором? А между бэкдором и хардкоженным паролем Pa$$w0rd в устройстве? А между хардкоженным паролем и немного странной константой для криптоалгоритма?
Кроме того, я не понимаю, как можно искать недокументированные возможности не читая исходный код. А если они читают исходный код, то это code review и он должен баги ловить.
servermen
По большому счёту вся эта сертификация просто сбор денег! Хотя, может быть, в случае чего производитель ПО сможет прикрыться этой бумажкой и не возмещать убытки…
teecat
Производитель в лицензионном пишет, что без гарантий. А вот в суде случай вроде как был, что использование сертифицированного ПО не освобождает от ответственности за заражение
SatumQuata
Мне жаль, что вы не попытались понять написанное мною. Тема очень тонкая, но я постараюсь ответить на ваши вопросы.
Вы неправильно трактуете термин «недокументированные». В понимании ФСТЭК это функции, которые отсутствуют в переданной им документации к коду или функции, которые этой документации не соответствуют и могут нарушить конфиденциальность, доступность или целостность.
Цель, которую преследует сертификация – это подтверждение того факта, что производитель не получит доступ и/или не передаст такой доступ заинтересованным лицам.
Сертификация — это попытка решения проблемы доверия к ПО или программно аппаратному комплексу, который вы будете использовать при работе с защищаемыми данными.
Проверка всего остального это задачи бизнеса, проходящего сертификацию. Потому что от этого зависит в том числе и брэнд, и репутация компании и к ФСТЭК не имеет никакого отношения. Но по факту очень мало кто занимается полным циклом разработки безопасного программного обеспечения. И основное требования бизнеса как правило звучит как:«вот мы продали, поставка завтра, как вы это организуете нас не волнует».
Исходя из определения «Backdoor» — это целенаправленное встраивание разработчиком функций, позволяющих получить доступ к управлению «продуктом» или получению доступа к данным.
RCE-CVE — исполнение произвольного кода, и тут далеко не всякий RCE позволяет получить доступ к управлению или доступ к данным. Например, «js injection» это тоже RCE.
Backdoor и захордкоженный Pa$$w0rd – одно и то же по определению (см. выше), туда же ваш пример про пароль и константу криптоалгоритма, но последним занимается ФСБ.
Надеюсь, что смог немного прояснить для вас ситуацию.
amarao
Я не понимаю разницы. Если у нас есть zero-day RCE (и не js-что-то, а прям натуральный RCE — прислали без авторизации хитрый utf8 — получили рута), то чем он отличается от забытого тестового аккаунта? В обоих случаях человек, знающий магическую последовательность из какашек и символов цвета кожи может выполнить свой код на чужом оборудовании.
Дальше мы можем начать классифицировать их как "умышленные" и "неумышленные". Но тестовые аккаунты (привет, Циска) забывают тоже по небрежности, совершенно такой же, как и проверку на размер буффера в Си.
Т.е. я не понимаю от чего защищает сертификация и чем сертифицированное ПО от несертифицированного отличается.
SatumQuata
Хорошо, попробуем зайти, с другой стороны.
Дано:
1. Вы государство с растущей информатизацией и информацией уровня секретно и выше;
2. НИИ/ФГУП и тд. силовых ведомств не могут производить оборудование и ПО для организации необходимой инфраструктуры, как следствие вы не доверяете всему спектру ПО/ПАК на рынке;
3. Организация всех взаимодействий на закрытых каналах связи (прямые охраняемые линии) без доступа к общественным сетям невозможна, так как необходимо взаимодействие как минимум с юр. лицами.
Задача:
Построить инфраструктуру так, чтобы защитить информацию и исключить возможность несанкционированного доступа.
Предложите ваше решение.
За качество и защищенность ПО/ПАК отвечает разработчик этого ПО/ПАК. И как отметил представитель КРОК выше, сертифицируясь разработчик принимает на себя ответственность и обязательства в исправлении найденных уязвимостей, в противном случае он лишается лицензии и всех заказов со стороны государства и коммерции, которую обязали обмениваться данными с государством посредством сертифицированных версий (а это очень большие суммы).
В несертифицируемом ПО/ПАК вы полностью доверяете разработчику и принимаете все риски, связанные с его безопасностью и как покупатель не можете повлиять на наличие выхода обновлений безопасности. В случае обнаружения RCE вы будете принимать решение о дальнейшем использовании ПО/ПАК или переходе на новое, что вызовет дополнительные траты.
Я хотел бы обозначить свою позицию, я не призываю пользоваться везде сертифицированными версиями и не пытаюсь вас склонить к этому (хотя идея идеального «реестра безопасного ПО/ПАК» мне немного импонирует, но как обычно реализация всегда вызывает вопросы). Сертификация нужна, по моему мнению, только в гос. структурах и для взаимодействия с ним, что порождает низкое качество сертифицированных ПО/ПАК в ввиду почти полного отсутствия конкуренции.
amarao
Задача: Построить инфраструктуру так, чтобы защитить информацию и исключить возможность несанкционированного доступа.
Решение тривиально: решаем задачу останова, с помощью решённой задачи автоматически валидируем на правильность весь код в системе.
Если решить задачу останова руки коротки, то цель "Построить инфраструктуру так, чтобы защитить информацию и исключить возможность несанкционированного доступа." недостижима.
Дальше можно сколько угодно делать магические пассы руками, но в стандарте языка Си сказано, что шаг влево, шаг в право — undefined behaviour, в том числе и всё самое страшное, что вы можете себе представить. Вот с этим и живём.
Рядом есть cox, но с его помощью полного стека (ОС, компилятор и т.д.) никто ещё не написал.
SatumQuata
Я никак не могу понять, почему вы задачи бизнеса упорно пытаетесь переложить на государство.
Это, как если бы у производителей продуктов представители Роспотребнадзора проверяли каждую партию и следили за качеством продукции и точности состава. Очень удобно для бизнеса, зачем тратиться на свой отдел контроля качества, когда все это делает за вас государство.
Так, же к своему невежеству прошу вас объяснить, что вы понимаете под «задачу останова» (поскольку вы говорите о ней, а подразумеваете SDLC)? В моем понимании «задача останова» формулируется как определение завершится ли задача когда-либо при определенных исходных данных. SDLC – оно несколько по другое, оно про написание кода исключающего возможность эксплуатации уязвимостей. Специалисты в этой области получают довольно высокий оклад и далеко не все компании могут позволить себе таких специалистов. Вы же предлагаете это полностью переложить на государство.
Если я правильно понимаю, то вы хотите следующую схему:
1. программисты «вашей» компании пишут любой код с любыми RCE;
2. вы направляете этот код в ФСТЭК;
3. ФСТЭК делает подробный анализ вашего кода, составляет полный отчет и направляет обратно;
4. Цикл повторяется любое кол-во раз пока вы не пройдет «сертификацию».
У меня вопросы:
1. за чей счет сей банкет?
2. почему вы перекладываете ответственность за ваш «продукт» на государство?
sneka
С одной стороны вы правы с другой есть один момент ради чего вся эта сертификация и задумана. (особенно актуально в свете уголовки оператору критически важной инфраструктуры)
У вас есть задача: " Построить инфраструктуру так, чтобы защитить информацию и исключить возможность несанкционированного доступа.". Вы ее выполнили в силу своего разумения (пусть и хорошего и грамотного) на открытом ПО. Выходит 0day уязвимость и вашу систему успевают вальнуть.
Начинается разбор полетов. Приходят компетентные органы и спрашивают «А что вы предприняли, чтоб защитится?»
-Ну я поставил, то се и вот это вот.
— А с чего вы взяли, что это все от чего то защищает и вообще безопасно?
— Ну я так решил на основании отзывов в сети, анализа кода и т.д.
-Ага! То есть ты решил — вот тебе и отвечать! Посиди ка троечку колонии поселения.
А при сертифицированном ПО диалог пойдет по другому.
-Ну я поставил, то се и вот это вот.
— А с чего вы взяли, что это все от чего то защищает и вообще безопасно?
— Ну на все это есть сертификаты ФСТЭК и оно закрывает уязвимости из перечня ФСТЭК. Вот бумажки.
— Ну чтож меры защиты были приняты, вины админа нет.
Вот только ради этого вся эта сертификация и существует.
teecat
Дополню. Я тоже не люблю сертификацию. Но! Да вендоры выпускают апдейты, но вот пользователи их не ставят (ванна край). И ФСТЭК заставляет ставить апдейты. Способ правда вызывает справедливые нарекания
mayorovp
Как пользователь может поставить апдейт, если на него ещё сертификата ФСТЭК не готово?
teecat
Нам присылают уведомления об уязвимостях, мы сразу делаем исправления в несертифицированных версиях. В сертифицированных версиях пользователям становятся доступны обновления после ИК
Но то, что для пользователей доступны обновления в обычных версиях не значит, что их обновят. Серверное ПО обновляется администратором например и у нас огромное количество пользователей на древних версиях. Не ставят и остаются уязвимыми
teecat
Проверяет и выкатывает список уязвимостей к устранению. И было бы это хорошо, но последующая ИК ну уж очень долго идет
zim32
Не всегда сертификаты бесполезны. К примеру pcidss четко регламентирует как часто должно происходить обновление по и с каких репозиториев, как реагировать на cve и т.д. Т.е. риск того что на сервере будет стоять трехлетней давности nginx, как часто бывает, сводится к нулю.