21 тезис с телемоста с руководством ФСТЭК или ответы регулятора на вопросы отрасли. Часть 1-я

17 февраля, в рамках конференции "Кибербезопасность. Наши дни. Промышленные технологии" прошел телемост "Москва-Урал" с участием Виталия Сергеевича Лютикова, заместителя директора ФСТЭК, который отвечал на вопросы, полученные от отрасли. Я вел этот телемост на стороне Урала и позволил себе составить краткое резюме по прозвучавшим ответам. Сразу отмечу, что из почти 70 пришедших вопросов, было отобрано 26, который на мой взгляд были достаточно стратегическими, чтобы задавать их именно Виталию Сергеевичу. На часть тактических и практических вопросов по КИИ позже ответила Елена Борисовна Торбенко, заместитель начальника 8-го Управления ФСТЭК, о чем я еще напишу отдельно. Диалог получился конструктивным, хотя и не на все вопросы были получены четкие ответы, что объяснимо и ниже я попробую про это написать.

1. ФСТЭК планирует продолжить практику участия в онлайн мероприятиях для донесения своей позиции (в последнее время активно участвовали от ФСТЭК не только Лютиков В.С., но и Кубарев А.В.). Проведение своих собственных мероприятий тоже возможно, но когда, непонятно, - ресурсов не хватает. Хотя мне кажется, что это позволило бы снять остроту многих проблем и наладить диалог регулятора не с узким кругом лицензиатов и экспертов, а с отраслью. Тем более, что это не так уж и сложно. Либо купить недорогой тариф у того же Webinar.ru, либо делать трансляции в Youtube, либо попросить помощи у той же группы Авангард-Медиа, которая и проводила телемост и имеет опыт онлайн-мероприятий (один SOC Live чего стоит).
2. ФСТЭК думает о возможности выкладывания на своем сайте обучающих курсов по различным вопросам защиты информации для повышения квалификации кадров, которая у нас не очень высокая по словам той же ФСТЭК на многих мероприятиях. Первую попытку попробуют сделать в марте - в рамках курса по динамическому и фаззинг-тестированию ПО, который проводит ФСТЭК. Этот курс планируют записать и выложить либо на сайт самой ФСТЭК, либо на сайт Банка данных угроз (БДУ).
3. Привлечение экспертов для экспертизы документов никто не отменял и ФСТЭК планирует и дальше привлекать специалистов для такой работы. Однако "массового" привлечения, как это было раньше, или "встреч с блогерами", видимо, не будет. Небольшие группы по несколько человек ФСТЭК считает более эффективным способом, чем собирать по 20-30 экспертов. Основным каналом коммуникаций ФСТЭК видит одностороннее взаимодействие через regulations или через обратную связь на выкладываемые на сайте документы, не требующие оценки регулятивного воздействия. Ну хоть так, хотя именно этот формат, похоже, многих и не устраивает.
4. Проверки субъектов КИИ начинают со второго полугодия 2021-го года. В плане 5 объектов КИИ. Что за объекты неизвестно и в публичной плоскости эти данные не появятся.
5. У ФСТЭК уже есть внутренние методики проведения проверок субъектов КИИ. Будут выкладывать их или нет - неизвестно. Но проверяют публичные требования 235/239-го приказов. Сами методики направлены на то, чтобы унифицировать подход и убрать отсебятину на местах, когда сотрудники терорганов ФСТЭК по своему трактуют то или иное требование нормативных актов.
6. В случае выявления нарушений в рамках проверок передавать данные в правоохранительные и следственные органы ФСТЭК не планирует. Но если от них будут запросы, то никто скрывать результаты проверок не будет. В случае выявления в рамках проверок предпосылок к нанесению ущерба, то данные будут передаваться в НКЦКИ.
7. Контролем использования отечественного ПО и отечественных средств защиты на объектах КИИ, как и вообще импортозамещением, ФСТЭК заниматься не будет. Они не уполномочены на это. Вообще, сложилось впечатление, что ФСТЭК сама не рада, что их используют для этой задачи. С этим же связано, как мне кажется, и то количество отказов от изменений в 239-й приказ, а также в проекты Указа Президента и Постановления Правительства по импортозамещению. ФСТЭК просто вынуждена делать то, что прилетело сверху.
8. По истории с РЖД ответ был витиеватый :-) Мол проверка факта проведена - сделаны выводы. Но вообще тема реагирования на такого рода публичные истории она остается открытой. ФСТЭК говорит, что все отслеживается и реагируется, но непублично.
9. Несмотря на ранее высказанные позиции о том, что объектом КИИ является не любая ИС, АСУ ТП или ИТКС, а только те, которые завязаны на критичные процессы (именно эту позицию ФСТЭК фиксировала в ПП-127), сейчас подход регулятора вернулся к тому, что написано в ФЗ-187, а именно - любая ИС, АСУ или ИТКС является объектом КИИ и подлежит категорированию. Даже если она по итогам категорирования и не будет признана значимым объектом, то все равно процедуры, предусмотренные ПП-127, должны быть проведены в отношении каждой ИС, АСУ или ИТКС. С моей точки зрения, именно этот, один из двух тезисов телемоста, пожалуй, имеет самые серьезные последствия для субъектов КИИ, которым придется пересмотреть результаты уже проведенного категорирования.
10. Второй имеющий серьезные последствия для отрасли тезис прозвучал при ответе на вопрос о том, где проходит водораздел между средствами защиты информации по 239-му приказу ФСТЭК и средствами ГосСОПКИ по 196-му и 282-му приказам ФСБ. Это еще одна тема, в которой ФСТЭК, похоже, пытаются склонить к позиции, которая им не близка. По крайней мере, сейчас прозвучало, что SIEM, СОВ/СОА, МСЭ, антивирусы, IRP и т.п. вполне могут считаться средствами ГосСОПКИ, а не только средствами защиты, и к ним будут предъявляться не только требования ФСТЭК, но и ФСБ. А требования последние - это полный пушной зверек (это уже моя оценка, не ФСТЭК). Согласно требованиям ФСБ вам придется согласовывать с ФСБ места установки средств ГосСОПКИ, использовать сертифицированные в ФСБ средства защиты, а также вам фактически будет запрещено применять иностранные средства защиты информации.
11. Изменений ФЗ-187 и ПП-127 в этом году не планируется. Надо дождаться правоприменительной практики и тогда уже оценивать все статьи закона вместе - что работает, а что нет. Как минимум, ФСТЭК видит необходимость поправить терминологию в части того, кого считать субъектом КИИ и что такое объект КИИ (хотят сузить).
12. Также в этом году нет планов по внесению изменений в 235/239-й приказы, если сверху не прилетит новых указаний, как это было в части импортозамещения.
13. Оценка соответствия прикладного ПО и средств защиты в форме испытаний или ввода в эксплуатацию может быть проведена самостоятельно субъектов КИИ или привлеченной им компанией, если кто-то из них имеет соответствующую экспертизу. А вот ФСТЭК, в соответствие с своими приказами, проверит протоколы испытаний и были ли установлены соответствующие требования при выборе прикладного ПО или средств защиты и их внедрении. Для меня это осталось достаточно спорным вопросом - как регулятор будет проверять выполнение этого требования и насколько его устроит это выполнение. Думаю и сам регулятор пока не знает этого с практической точки зрения.
14. Разъяснений от ФСТЭК по тому как проводить оценку соответствия в формах испытаний и ввода в эксплуатацию не будет.
15. Для проверки уровня доверия прикладного ПО у субъекта КИИ должны быть соответствующие документы, которые имеют отметку "для служебного пользования". ФСТЭК готова ими делиться при условии обоснованного запроса со стороны субъекта КИИ. Я безусловно верю словам замдиректора ФСТЭК, но если мы посмотрим на порядок доступа к документам ограниченного распространения, вывешенный на сайте ФСТЭК, то там четко написано, что для такого доступа нужна лицензия ФСБ на гостайну. Более того, для организаций, не имеющих ведомственной принадлежности (то есть обычные разработчики ПО попадают именно сюда), доступ к таким документам (помимо лицензии ФСБ на гостайну) осуществляется на платной основе и необходимо заключить договор с ГНИИ ПТЗИ ФСТЭК. Ровно такой же процесс (наличие лицензии) был упомянут начальником 2-го Управления ФСТЭК Д.Н.Шевцовым в рамках ТБ-Форума. Так что не все так просто, как говорится в телемосте. 
16. Вообще ФСТЭК не откажется от подхода к "засекречиванию" своих документов, объясняя это тем, что "у всех так".
17. Для прикладного ПО может быть выбрана оценка соответствия в форме обязательной сертификации по желанию самого субъекта КИИ и тогда он должен будет найти испытательную лабораторию, которая согласится провести такие работы. И вот тут еще один нюанс возник. Согласно всем последним приказам ФСТЭК (и уходящему 131-му и новому 76-му) проверка уровней доверия возможна только для средств технической защиты информации или средств по обеспечению безопасности информационных технологий. Поэтому формально обычное прикладное ПО оценивать по уровням доверия испытательные лаборатории не могут. Но если перефразировать слова ФСТЭК "если очень хочется, то можно". В общем, надо посмотреть, как все будут выкручиваться из этой ситуации.
18. Пересматривать уже разработанные модели угроз при условии принятия новой методики моделирования не требуется. Если только речь не идет о модернизации или развитии объекта КИИ.
19. Банк данных угроз будет переделан в течение ближайших месяцев для соответствия новой методики моделирования угроз. Может быть (сроки неясны) ФСТЭК выпустит и средство автоматизации этого процесса и сделает его бесплатным по аналогии с решением ScanOVAL, которое распространяется с сайта БДУ.
20. В ближайшее время будет выпущена новая редакция ГОСТа 56939 по безопасной разработке. Кардинальных изменений не будет и проводить повторную оценку его выполнения разработчикам не потребуется. 
21. И хотя Виталий Сергеевич на ТБ-Форуме "обещал не обещать" в рамках телемоста он осознанно нарушил свое обещание не обещать и озвучил планы по разработке нормативных и методических документов на ближайшее время:
• проект методички по расчету показателей критерия социальной значимости (в дополнение к выложенной на прошлой неделе методичке по расчету показателей критерия экономической значимости)
• порядок организации и проведения работ по аттестации объектов информатизации на соответстие требованиям о защите информации, не составляющей гостайну
• требования по безопасности информации к средствам обеспечения безопасной дистанционной работы в информационных (автоматизированных) системах
• изменения вв 31-й приказ ФСТЭК
• методика анализа и поиска уязвимостей и НДВ в аппаратных средствах
• новая методика анализа и поиска уязвимостей в ПО
• типовая модель угроз для аппаратных средств
• методичка по видам и методам испытаний при проведении аттестации
• метожичка по управлению обновлениями (патч-менеджменту).

Вот такой краткий пересказ полуторачасового эфира, запись которого вы можете увидеть ниже:

ЗЫ. На оставшие вопросы от отрасли ответила Елена Борисовна Торбенко в своем выступлении (про это завтра), а все, что осталось без ответа на форуме "Кибербезопасности. Наши дни. Промышленные технологии", будет отвечено представителями ФСТЭК в рамках последующих мероприятий с их участием.

Подробнее…

Как ФСТЭК выполняет свои обещания. Анализ за 6 лет

На прошедшем на прошлой неделе эфире AM Live, посвященном средствам защиты от несанкционированного доступа, был поднят вопрос о том, зачем нужны средства защиты, которые покупаются преимущественно госорганами для выполнения "бумажных" требований, которые, при этом, не менялись с 1992-го года (да, РД на СВТ не менялся уже почти 30 лет). На это поступило возражение, что для современных систем защиты, которые уже ближе к решениям класса EPP по версии Gartner (Endpoint Protection), при сертификации применяются либо набор из РД (по СВТ, по МСЭ, по антивирусам, по контролю съемных носителей), либо продукт сертифицируется по заданию по безопасности (оно же техническое задание), которое разрабатывается специально под решение и которое описывает весь включаемый в область действия сертификации функционал. И вот тут я подумал, что если ФСТЭК не может обновить свой документ 1992-го года, то как вообще обстоит дело с требованиями к различным средствам защиты, которые должны использоваться при сертификации и которые упоминаются во всех требованиях ФСТЭК по защите ИСПДн, ГИС, АСУ ТП, КИИ и других объектов защиты (дспшные требования)?

Я поступил просто - взял презентации выступлений руководителей ФСТЭК за последние 6 лет, прозввучавшие на февральской конференции регулятора, проводимой в рамках ТБ Форума. То есть никакой отсебятины - одни факты. Вначале, в 2015-м и 2016-м годах ФСТЭК очень активно давала обещания по разрабатываемым документам, проекты которых уже разработаны и "вот-вот" должны быть утверждены. И такие обещания укладывались в общую картину, которая заключалась в том, что регулятор еще в 2013-м году пообещал, что за каждым требованием 17-го и 21-го, которое может быть реализовано с помощью средства защиты, будет свой руководящий документ, который и устанавливает требования к этим средствам. Логично... Но вот реальность оказалась совсем иной.

Желтое означает обещание. Зеленое - его выполнение

После того, как блогеры (читай - я) и в 2016-м, и в 2017-м годах в заметках "спросил" регулятора про его обещания, ФСТЭК стала более осмотрительной, и в 2017-м году забыла про все ранее данные обещания (хотя врядли про сами документы, которые в недрах регуляторы должны были и дальше разрабатываться и появиться как чертик из табакерки; по аналогии с РД на операционные системы, о котором в 2015-м году не упоминали, а в 2016-м уже разработали и утвердили). В 2017-м регулятор пообещал только три новых документа - по управлению потоками информации (на фоне постоянных вопросов о том, можно ли VLANами или встроенными возможностями сетевого оборудования защищать внутренние сети), по системам управления базами данных и по средствам защиты среды ввиртуализации. Но не получилось...

В 2018-м году по стране победно шел ФЗ-187 и вся конференция ФСТЭК была посвящена именно этой теме - про сертификацию не сказали ни слова. Вновь к этой теме вернулись в 2019-м году, и регулятор не только вспомнил про обещание разработать тройку РД по управлению потоками информации, СУБД и виртуализации, но и пообещал обновить 6 ранее разработанных документов - по межсетевым экранам, операционным системам, антивирусам, системам обнаружения вторжения, средствам контроля съемных носителей и средствам доверенной загрузки. Но увы, тоже не получились...

В этом году, на конференции ФСТЭК не вспоминала об обещании обновить шесть РД, ограничившись обещанием обновить только требования к антивирусам. Требования по защите виртуализации тоже не упомянули, оставив планы только на два новых документа - по управлению потоками информации и по СУБД.

И вот, мы подходим к концу 2020-го года, который ознаменовался тем, что многие сидели  по домам, не ездили в командировки, не участвовали в надзорной деятельности и, вроде бы, времени должно было быть чуть больше чем в прежние года. Но увы. Опять (буду рад ошибиться, если за оставшиеся пару недель регулятор выпустит эти документы) ничего. Опять обещания не выполнены. 

Итоги обещаний по новым РД свел в таблицу (выше). Из 19 обещанных за 6 лет документов разработано только 2 (!) и то, в 2016-м году. Обновлений ранее разработанных документов так и не случилось. Но вроде бы уже и не ждешь. Привыкли :-(

ЗЫ. У ФСТЭК был еще нигде не озвучивавшийся план по требованиям к средствам отражения DDoS-атак, но вот уже прошло больше двух лет, а документ так и не выпущен.

ЗЗЫ. А может все требования выпустили, но засекретили? И даже приказы об утверждении тоже секретные?.. 

Подробнее…

Актуальные требования регуляторов к средствам защиты (видео)

В январе выступал на конференции Oracle Security Day с рассказом об актуальных на тот момент требованиях регуляторов к средствам защиты информации. Оказывается видео этого выступления было официально выложено на Youtube:

ЗЫ. Понятно, что с января много воды утекло, но многие аспекты остаются пока еще актуальными.

Подробнее…

Как ДИБ и ФинЦЕРТ могли бы улучшить кибербезопасность финансовых организаций?

Одним из часто звучащих вопросов от руководства, которое мало что смыслит в ИБ, но хочет держать руку на пульсе, среди прочих, является: "Как мы соотносимся с конкурентами?" За этим, казалось бы простым и сложным одновременно, вопросом скрывается вполне понятные управленческие решения. Мы хуже других - значит надо "наказать" виновных и инвестировать в улучшения. Мы лучше других - надо наградить "непричастных" и хвалиться этим.

Но если отбросить в сторону болтовню, то знание своего уровня безопасности по сравнению с другими, позволяет безопаснику фокусироваться на тех процессах и проектах, которые позволят улучшить свою ИБ как в целом, так и в отдельных направлениях.

Чтобы узнать свой уровень можно обратиться к "большой четверке" и они в рамках Security Benchmarking смогут оценить вас, как по отношению к "коллегам" в вашей отрасли, так и по отношению с компаниями из других сфер деятельности. Схожую задачу могут решить и просто крупные международные аудиторы, которые за время своей работы накопили статистику и могут оценивать зрелость своих клиентов и сравнивать ее со "средней температурой по больнице" (мы, например, такое делаем при аудите SOCов, сравнивая их между собой).

А теперь вернемся к заголовку заметки. Как эту задачу мог бы помочь решить Банк России для своих поднадзорных организаций? А все просто. В ЦБ стекается на протяжении уже нескольких лет 202-я форма отчетности (а до этого отчетность по СТО БР, а сейчас еще и отчетность по ГОСТ 57580.2), которая содержит всю нужную информацию. Раньше ГУБЗИ уже публиковало сводную статистику по числу кредитных организаций, достигших того или иного уровня соответствия по 202-й форме. Но в последнее время уже ДИБ перестал это делать, уделяя внимание только данным по мошенническим операциям (свежий отчет) и атакам.

А ведь, что может быть проще, раз в год, публиковать сводную радарную диаграмму по средним уровням соответствия требованиям того же ГОСТа. Можно пойти еще дальше и делать выборку по разным типам финансовых организаций - банки с базовой лицензией, крупняк, операторы платежных систем, разные типы НФО и т.п.     

Никакой тайны в этом случае не раскрывается, репутация финансовых организаций не страдает, а у последних появляется ценнейший источник информации, на который можно ориентироваться в своей деятельности. И на вопрос руководства: "А как мы соотносимся с конкурентами?" всегда можно быстро подготовить один слайдик с радарной диаграммой и правильно его преподнести.

И ЦБ - единственный из всех регулятор, кто способен это сделать. У ФСТЭК нет этих данных, хотя если аккумулировать результаты аттестаций, то может получиться тоже неплохая аналитика. ФСБ/НКЦКИ все по привычки засекречивает и делится только данными о десятках миллионов атак, отраженных на сайт Президента России. И только ЦБ в лице ДИБ не только имеет все необходимые данные, но и может их публиковать, так как уже делал это раньше и делает сейчас по смежным направлениям своей деятельности. Думаю, вот за это ДИБу бы реально сказали "спасибо". А то попытка вынести тему ИБ на уровень Правления, предпринятая в проекте положения по системе управления операционными рисками в принципе неплоха, но очень уж сложна для восприятия и реализации. Я уже дважды прочитал именно эту редакцию проекта, но пока в голове не уложил всю схему того, что хочет сделать ЦБ и как это соотнести с уже имеющимися мероприятиями по ИБ, требуемыми по другим нормативным актам регулятора.

Подробнее…

Дифференциация требований по ИБ на примере новой системы сертификации МинОбороны

Наблюдая за тем, что делает ФСТЭК (ФСБ тоже), а точнее как, замечаешь одну вещь. Регулятор воспринимает только два цвета - белое или черное. Вспоминается дискуссия во время принятия последней редакции Постановления Правительства о лицензировании отдельных видов деятельности и перечня требования к лицензиатам на мониторинг ИБ. Кто помнит, там есть такие пункты, которые обязывают владельца коммерческого SOC иметь ряд сертифицированных средств защиты, например, SIEM, а также аттестовать SOC по требованиям ГИС1. Первое требование обходится всеми российскими SOCами, которые для лицензии покупают один SIEM, а в работе использует другой :-) И проверять это регулятор не хочет, хотя нередко упоминает, что они используют стратегию "тайного покупателя". Второе же требование по сути не только запрещает виртуальные и мобильные SOCи, но и закрывает доступ на российский рынок вход SOCам иностранным.

Когда обсуждался пункт про аттестацию на ГИС1 доводы ФСТЭК звучали следующим образом: вдруг к SOCу придет госорган, который захочет купить услугу мониторинга ИБ для своих ГИС 1-го класса? SOC должен иметь тот же уровень аттестации. А на закономерный вопрос, что SOCов, к которым могут прийти госорганы, у нас в стране можно пересчитать по пальцам одной руки, и поэтому устанавливать в качестве обязательного требования аттестацию ГИС1 не совсем разумно - это отсечет многие региональные SOCи, которые будут ориентироваться на малый бизнес, который крупным федеральным SOCам пока мало интересен. Но увы, деля все на черное и белое, на все или ничего, регулятор не захотел пересматривать свои взгляды. И так во всем - сертифицированное или несертифицированное, отечественное или зарубежное, под контролем или не под контролем, аттестованная или неаттестованная, лицензиат или нелицензиат...

А возможна ли ситуация с 50 оттенками серого между черным и белым? Да, вполне. Например, так поступило МинОбороны США, которое выпустило на днях систему сертификации компаний с точки зрения кибербезопасности (Cybersecurity Maturity Model Certification), которую должны соблюдать все компании, которые работают с американским военным ведомством, а их число насчитывает около 300 тысяч.

Я не буду подробно рассказывать о самой системе (желающие могут почитать про это сами), а коснусь только ключевых тезисов, показывающих ключевую идею новой системы:

• Система разработана не для всех организаций, а только для тех, кто работает с МинОбороны США. Как не хватает нам в России такой же дифференциации. Вот есть требования, они жесткие, но они только для тех, кто имеет доступ к ВПК/ОПК. А вот есть требования для тех, кто работает с госорганами. Они различаются по уровню защищаемой информации. А для тех, кто работает с гражданским сектором требования устанавливаются на основе лучших практик или гражданского законодательства. Но нет... у нас всех под одну гребенку :-(
• Система охватывает не только прямых поставщиков, но и всю цепочку поставщиков. Причем речь идет не о требованиях к продуктам или компонентам, а о требованиях именно к самим компаниям, производящим или поставляющим что-то в интересах военного ведомства. Это связано с тем, что по мнению разработчиков системы, злоумышленники часто действуют не напрямую на военные организации или их прямых подрядчиков, а через поставщиков вплоть до 6-8 уровней.
• Новая система базируется на уже известных требованиях NIST SP800-53, ISO 27001, ISO 27032, NIST SP800-171.
• Малый бизнес, работающий в интересах МинОбороны, очень важен для него, но не всегда в состоянии выполнить те же самые требования, что и крупные игроки типа Lockheed Martin или Raytheon. Поэтому требования системы CMMC являются дифференцированными.
• На сертификацию выделяется 3 года. Невыполнение требований приведет не к штрафу, а к отказу от заключения контрактов. Такое "наказание" выглядит вполне действенным, так как серьезно бьет по карману собственников, не давая им зарабатывать; в отличие от штрафов, которые обычно фиксированные и их легко платить.
• Сертификацию проводят независимые аккредитованные организации, правила выбора и аккредитации которых еще предстоит разработать.
• Все требования по безопасности разбиваются на 5 уровней - от базовой кибергигены до продвинутого. Правила соотнесения определенного военного контракта и нужного уровня соответствия пока неясны - они находятся в разработке.
• Взлом компании не означает потерю контракта или потерю сертификата, но может потребовать повторной сертификации

Система CMMC, которую сейчас внедряет американское МинОбороны, находится только в самом начале своего пути и пока еще не отвечает на все вопросы (например, должны ли ей соответствовать поставщики обычного коммерческого софта, продаваемого на открытом рынке; а поставщики в рамках микрозакупок типа канцелярки или поставщики бухгалтерских услуг?). Но сама идея оценки состояния ИБ поставщиков, а также дифференциация требований по ИБ в зависимости от типа контракта и уровня защищаемой информации, является достаточно здравой и позволяющей учесть различные типы компаний, которые работают с министерством, а не грести всех под одну гребенку.

Подробнее…

Что еще могла бы сделать ФСТЭК по аналогии с CIS

Ну раз уж я последние три дня публиковал некоторые рекомендации по возможному улучшению результатов работы ФСТЭК, то закончу эту неделю еще одним набором рекомендаций. Их тоже будет три и я их "подсмотрел" у уже не раз упомянутого на неделе Center of Internet Security (CIS).

С CIS Controls и Community Attack Model вроде мы разобрались. Что еще есть у CIS? CIS Benchmarks - набор рекомендаций по настройке широкого спектра ПО (серверное, операционные системы, облачное ПО, десктопное ПО), мобильных устройств, сетевого оборудования и многофункциональных устройств. Почти 50 вендоров, около 100 версий ПО, включая самое современное и востребованное (Docker, Kubernetes, MongoDB, MS Sharepoint и т.п.). Это отличный инструмент (есть бесплатный набор руководств и расширенный, по подписке), который сразу подсказывает, как правильно настроить то или иное ПО, чтобы уменьшить площадь возможной атаки и защитить информационные активы. ФСТЭК в своем БДУ уже фокусируется на уязвимостях в ПО и "железе", которое чаще всего используется в российских госорганах. Вот если бы они еще делали рекомендации по его безопасной настройке...

Есть у CIS еще одна фишка, которая связана с рекомендациями по защищенной настройке, - защищенные образы ПО, которые уже настроены в соответствие с рекомендациями CIS, и которые можно скачать с их сайта. Но боюсь, что именно эта возможность для ФСТЭК недоступна - ждать, что регулятор будет распространять защищенный "Мой офис", 1С, Астру и т.п. не приходится (не его это функция).

Если вы не можете скачать с сайта CIS уже настроенное защищенным образом ПО, вы можете проверить правильность настройки установленного у вас софта. Для этого у CIS есть соответствующий сервис CIS CAT (и CIS CAT Pro), который представляет собой сканер конфигураций. С его помощью (а его клиентская часть ставится на Windows и Ubuntu) вы можете просканировать все свои узлы и получить отчет с оценкой соответствия от 0 до 100 (и контролем динамики изменения уровня соответствия).

CIS CAT доступен в двух версиях, позволяющих сканировать локальные и удаленные узлы (а также имеющих только CLI или GUI), и в двух редакциях - бесплатной (скачать) и коммерческой (отличия в количестве проверяемых руководств CIS Benchmarks). У ФСТЭК есть бесплатный сканер уязвимостей для Windows - ScanOVAL, но если бы у регулятора был продукт, схожий с CIS CAT, то было бы вообще прекрасно. В условиях нехватки кадров, о который так часто говорят представители ФСТЭК, автоматизация поиска уязвимых конфигураций и поддержка сканера в актуальном состоянии, такой сервис был бы очень полезен.

Еще одним инструментом, и бесплатным, который выпустил CIS, является RAM (Risk Assessment Method), который позволяет провести анализ рисков и связать актуальные риски с защитными мерами CIS Controls. Скачав CIS RAM вы получаете инструкции, примеры, шаблоны для того, чтобы провести оценку рисков на своем предприятии (хотя она ближе к моделированию угроз, на мой взгляд). Самое полезное, что есть в RAM (а методик анализа риска известно с несколько десятков), это ее взаимосвязь с ранее упомянутой моделью угроз Community Attack Model и набором защитных мер CIS Controls.

Если CIS CAT позволяет оценивать, насколько вы правильно сконфигурировали свои узлы в соответствие с CIS Benchmarks, то бесплатное web-приложение CSAT позволяет вам оценить и приоритизировать защитные меры CIS Controls.

Кто знаком с CIS Controls, тот знает, что существует Excel'вская табличка-опросник AuditScripts Critical Security Control Manual Assessment Tool (с российских IP-адресов могут не пускать), которая позволяет провести анализ своего соответствия требованиям CIS и проверить, какие из защитных мер вы реализовали, а какие вам еще только предстоит внедрить. Это примерно то, что могла бы сделать ФСТЭК, как я писал вчера. CIS CSAT базируется как раз на вопросах из этого опросника и визуализирует работу с ним, добавляя к нему различные фишки, позволяющие документировать, отслеживать, автоматизировать и внедрять защитные меры из каталога CIS Controls, в том числе и маппировать их в PCI DSS или NIST SP800-53.

Три с лишним года назад я писал про соревновательный дух при выполнении требований регуляторов. CIS CSAT позволяет визуализировать этот "дух" и сравнивать выполнение защитных мер по различным подразделениям. Данный бесплатный инструмент можно использовать прямо сейчас, но учитывая, что это облачный сервис, который размещается не в России, не уверен, что отечественные госорганы его захотят использовать. А вот такой инструмент на базе ФСТЭК был бы очень полезен и помог бы многим поднадзорным ФСТЭК организациям регулярно проводить свою оценку соответствия, не тратя бюджетных средств на привлечение внешних организаций.

Описанные выше сервисы являются бесплатными (хотя часть из них и имеет платные варианты) и доступны любой организации, в том числе и в России. Но есть у CIS и ряд сервисов, доступных только для государственных структур США (часть только за деньги). К их числу относится:

• сервис мониторинга сетевых угроз "Альберт"
• CIS CyberMarket - сервис коллективной закупки средств ИБ, позволяющей существенно экономить бюджетные средства
• MS-ISAC - круглосуточный SOC, включающий мониторинг ИБ и реагирование на инциденты. 

Вот такая интересная организация CIS, которая подсказывает несколько интересных вариантов для развития и наших регуляторов (и не только ФСТЭК). При этом первые три рекомендации, данные во вторник-четверг, могут быть реализованы минимумом усилий. Приоритизация и "экселизация" так уж точно. Расширение БДУ и увязывание его с защитными мерами потребует больше аналитической работы. А вот сегодняшние рекомендации - это уже высший пилотаж и потребуют определенных финансовых вложений на реализацию схожего функционала.

Подробнее…

Долгожданное письмо ФСТЭК про Windows 7

Во вторник ФСТЭК выпустила информационное сообщение о ситуации с Windows 7 и Windows Server 2008 R2, чья поддержка закончилась 14 января 2020 года. Если тезисно, то письмо ФСТЭК содержит следующее:

• Microsoft прекратила поддержку и выпуск обновлений для Windows 7 и Windows Server 2008 R2.
• В ФОИВ, ОГВ, ОМС и других используется много сертифицированных копий данных ОС.
• ФСТЭК выдала 7 сертификатов соответствия на данные ОС.
• Обязательное условие действие сертификатов - установка сертифицированных обновлений.
• Отсутствие обновления может привести к росту угроз использования новых уязвимостей.
• ФСТЭК прекращает действие двух сертификатов (видимо с 20-го января 2020 года) и исключает все семь сертификатов из реестра сертифицированных средств защиты с 1-го июня.
• ФСТЭК рекомендует перейти до 1-го июня 2020 года на сертифицированные и обновляемые ОС.
• До перехода надо выполнять рекомендации ФСТЭК из информационного письма.

Замена на новую ОС имеет смысл только на ОС, у которой срок окончания сертификата заканчивается не в 2020-м и даже не в 2021-м году. Сколько ОС у нас сертифицировано по новым требованиям ФСТЭК к ОС, удовлетворяющих таким требованиям? Мобильную ОС Sailfisf, дистрибутив ФССП и EMIAS мы отбрасываем и получаем в итоге следующий список:

• РЕД ОС
• РОСА КОБАЛЬТ
• SUSE Linux Enterprise Server 12 SP3
• Альт 8 СП.

И вот тут у меня закономерный вопрос; даже два. В условиях цикла бюджетирования в госорганах перейти на новую ОС до 1-го июня невозможно. Но это мелочи. Как пишет ФСТЭК - под Windows 7 и Windows Server 2008 R2 написано много разного прикладного софта. Как его до 1-го июня портировать под упомянутые выше форки Linux? Понятно, что это не проблема ФСТЭК и организациям надо было думать раньше, но все-таки проблема существует и как ее решать, непонятно.

 

Среди рекомендаций ФСТЭК указано, что надо применять дополнительные сертифицированные средства защиты. Но можно ли использовать их как защиту от угроз, которые могут использовать непатченные уязвимости? Ведь обновление нужно не просто так, а потому, что уязвимости могут быть использованы злоумышленниками. Если мы выстроим вокруг непатченной ОС эшелонированную систему предотвращения угроз и на саму ОС поставим средство защиты, то не снимет ли это проблему? Особенно если следовать требованиям тех же приказов ФСТЭК (например, 17-го). Тогда можно и срок перехода продлить до момента портирования приложений на новую ОС.

Но самое интересное кроется в аннулировании сертификатов. Основание для этого вроде бы следует из нормативных документов ФСТЭК - нет обновления, сертификат прекращает свое действие. Но парадокс в том, что Microsoft не прекращала выпуск обновлений, устраняющих уязвимости в Windows 7 и Windows Server 2008 R2. Да, домашним пользователям стоит подумать о смене ОС. Но вот корпоративным пользователям Microsoft предлагает EUS - Extended Security Updates, то есть расширенную поддержку, которая действует до января 2023-го года, в течение которой пользователи будут получать обновления, устраняющие уязвимости.

И вот тут возникает проблема. Если ФОИВ купил EUS, то он все равно использовать Windows 7  уже не сможет, так как ФСТЭК аннулировала своим приказом сертификаты соответствия. И вроде ОС работает, уязвимости устраняются, бюджетные средства потрачены, а пользоваться ОС нельзя, так как для нее больше нет сертификатов. И ладно бы было только информационное сообщение ФСТЭК - обязательным оно не является. Но вот приказ об аннулировании сертификатов так просто не отменишь. По крайней мере я не помню случаев, когда сертификат аннулировался, а потом возвращался "в строй". И как тут быть, непонятно. Не ждать же от ФСТЭК от выпущенных же ими разъяснений и приказов... Хотя это был бы поступок. Сродни признанию Ираном факта уничтожения украинского Боинга.

Подробнее…

Метод "пяти почему" в ИБ

Основатель компании Toyota, господин Тойода, постоянно пользовался правилом "пяти почему" или "пять зачем", которое помогало ему добраться до сути многих сложных процессов и разбираться во многих непонятных ситуациях.

Давайте попробуем применить его к кибербезопасности. Например, стоите вы перед выбором, купить вам межсетевой экран с сертификатом ФСТЭК или купить что-то более функциональное. И продавцы сертифицированных МСЭ так и вьются вокруг вас, а вы находитесь в раздумьях. И вот вы начинаете применять к этой ситуации метод "пяти почему".

Спрашиваете себя - почему я хочу сертифицированный МСЭ? Это первое «почему». Отвечаете: потому что так написано в законодательстве. ОК, переходим ко второму «почему». Почему вы думаете, что так написано в законодательстве? Ответ: Потому что все про это говорят и продавцы МСЭ тоже. Третье «почему»: Почему все, включая продавцов, говорят о необходимости сертификации МСЭ? Ответ: Потому что они хотят заработать денег на мне. Четвертое «почему». Почему они хотят заработать денег? Ответ: Потому что по другому их продукция не продается. Пятое «почему». Почему она не продается? Ответ: Потому что их продукция говно менее функциональная и может похвастаться только сертификатом с высоким уровнем соответствия требованиям регулятора. Ну вроде очевидный ответ, но он ни слова не говорит вам, почему именно вам нужен именно сертифицированный МСЭ? Может вас устроит и несертифицированное решение?

Давайте попробуем пройти эту процедуру еще раз. Начнем сразу со второго "почему". Почему вы думаете, что так написано в законодательстве? Ответ: Потому что я верю тем, кто говорит средства защиты должны иметь сертификат. Третье «почему». Почему я им верю на слово? Ответ: Потому что они лучше меня разбираются в законодательстве. Четвертое «почему»: Почему они лучше разбираются? Ответ: Потому что им надо продать мне свою продукцию. Пятое «почему»: Почему она не продается? Ответ: Потому что их продукция говно... Ой, опять тоже самое :-)

Давайте снова запустим метод "пяти почему". Начнем с третьего "почему". Почему я им верю на слово? Ответ: Потому что я сам не разбирался в хитросплетениях нашего сложного законодательства. Четвертое «почему»: Почему я не разбирался в законодательстве? Ответ: Потому что мне не хочется разбираться в скучном законодательстве. Пятое «почему»: Почему мне не хочется разбираться в скучном законодательстве? Ответ: Потому что... вот тут может несколько причин. Мне не хочется спорить с регуляторами. У меня нет юридического образования. У меня нет юристов, которые бы помогли мне. Мне, у меня, я... Последнее "почему" можно сформулировать проще, не прячась за отговорками. Я НЕ ХОЧУ НАПРЯГАТЬСЯ и МНЕ ТАК ПРОЩЕ.

И скажите теперь, при чем тут сертификат на МСЭ? Мы покупаем сертифицированное решение по одной простой причине, если, конечно, мы не госорган, - нам не хочется напрягаться, чтобы разобраться в отечественном законодательстве и понять, кому и в каких ситуациях требуется сертификат ФСТЭК, а в каких можно обойтись иными формами оценки соответствия.

Какой еще пример можно привести? Допустим, в компании утекла база данных и был нанесен слишком большой ущерб. Мы хотим понять, в чем причина этого и почему утекло так много данных. Первое "почему" так и будет звучать: Почему у нас утекло так много данных? Ответ: потому что мы слишком поздно среагировали на инцидент. Второе "почему" мы сформулируем как: Почему мы слишком поздно среагировали на инцидент? Ответ: потому что мы слишком долго расследовали утечку. Третье "почему": Почему мы слишком долго расследовали утечку? Ответ: у нас не хватает компетенций (вариацией ответа может быть "у нас не хватает соответствующего playbook" или "у нас не хватает нужного инструмента" или "у нас не выстроен процесс борьбы с утечками" или "у нас не вся организация покрыта средствами мониторинга" или "). Четвертое "почему": Почему у нас не хватает компетенций? Ответ: нас не учили бороться с утечками (или "мы не проводили практические киберучения" или ""). Финальное "почему": Почему нас не учили бороться с утечками? Ответ: у нас нет денег (у нас нет понимания необходимости обучения).

Обратили внимание, что в зависимости от того, как вы выстроили цепочку из пяти "почему", у вас выявляются разные первопричины? Очень редко когда она одна. Это как корневая система у растения - есть основной, а есть дополнительные и придаточные корни.

Господин Тойода считал, что в ответе на пятое "почему" и кроется первопричина наших (или не наших) поступков и действий, которая на первый взгляд не прослеживается. Именно она отражает то, что мы скрывали сами от себя и что действительно является важным.

Подробнее…

О сертификации NGFW - текущий статус

В январе я написал заметку о том, что согласно новым подходам ФСТЭК, сертифицировать многие зарубежные средства защиты будет скоро невозможно. В апреле я продолжил тему, когда ФСТЭК выпустила письмо, требующее до 1-го января 2020 года (осталось 4 месяца) обновить все действующие сертификаты и подтвердить соответствие требованиям по доверию. И вот сейчас, спустя 4 месяца после последней заметки я хотел бы обновить тему и написать о текущем статусе сертификации NGFW.

Несмотря на кочующий из доклада в доклада, из статьи в статью, тезис о том, что 100% организаций имеют межсетевой экран и антивирус, в реальности все-таки речь обычно идет не об обычном МСЭ, а о межсетевом экране следующего поколения (NGFW), задача которого не только фильтровать трафик на прикладном уровне, но и распознавать приложения и осуществляемые внутри них действия, применяя к ним соответствующие политики, блокировать атаки, нейтрализовывать вредоносный код, предоставлять функцию VPN и контролировать доступ в Интернет, беря на себя функцию прокси. Это типовой функционал NGFW, который в зависимости от вендора расширяется песочницами, CASB, глубокой DNS-инспекцией, отражением DDoS-атак, WAF, сканером уязвимостей и т.п.

Как я уже писал в январе, чтобы получить по новым требованиям ФСТЭК сертификат на такой "комбайн", необходимо проверить весь функционал (хорошо, что ФСТЭК пока не требует, чтобы в NGFW функция VPN строилась на базе сертифицированных СКЗИ). Прошли те времена (хотя иногда раз-раз, да проскользнет мимо ФСТЭК такой сертификат) когда можно было получить для NGFW сертификат только по РД к МСЭ. Сегодня будь добр сертифицировать все - и антивирус (на соответствующий РД), и систему обнаружения вторжений, и WAF. А для того, для чего у ФСТЭК нет РД, будь добр прописывай проверку этих функций и среды функционирования в задание по безопасности. Весь непроверяемый функционал должен быть удален. Правда, в этом случае уже не приходится говорить о продукте класса NG, но это уже частности (кому-то важна именно бумажка, а не чистота процесса).

Все это была прелюдия, о которой я уже писал. Теперь пора посмотреть, что происходит у нас в части сертификации популярных в России NGFW по линии ФСТЭК (по линии ФСБ это и в голову никому не приходит). Не слукавлю, если скажу, что 99% всех NGFW, которые продаются в России, имеют иностранное происхождение. Специально не буду называть вендоров, но думаю, что их все и так знают. Так вот, общаясь с коллегами из всех этих компаний, но не называя имен, у меня сложилась сейчас следующая картина по состоянию сертификаций из NGFW:

• Один вендор вырезал из своего продукта часть основного (например, обнаружение приложений) и управляющего функционала (например, поддержку SSL, что поставило вопрос о работе с HTTPS, управлении по HTTPS и получении обновлений по нему же). В итоге NGFW превратился в обычный МСЭ (без приставки NG).
• Другой вендор, имея на NGFW-платформе, несколько вариантов ПО, сертифицирует только тот, который содержит только функционал МСЭ. Даже СОВ уже сертифицировать нельзя (это касается всех производителей), так как они все обновляются из-за рубежа, что по версии регулятора является угрозой ИБ.
• Третий вендор пытается запустить для России разработку особой ветки своего продукта, в котором от NGFW останется только FW, превратив его, да, в гораздо более удобный, чем российские МСЭ, продукт, но все-таки это уже не решение класса NG.
• Кто-то пытается скрыть свой NGFW в корпусе другого продукта, в котором еще установлен российский VPN, что якобы должно сделать продукт российским и обойти преграды при сертификации. Но судя по отсутствию сертификата, этот фокус тоже не прошел.
• Последний из иностранных вендоров и вовсе отказался от сертификации, понимая всю бесперспективность этого процесса для своего продукта.

Что в итоге? Полное отсутствие популярных сертифицированных NGFW на российском рынке, каковая тенденция сохранится и в будущем. И дальше у иностранного вендора два пути. Первый - продолжать сертифицировать свои решения только как МСЭ (если вендор в состояния представить продукт в варианте "нестареющей классики" без всяких модных технологий, упомянутых выше), но не выше 6-го класса по РД на МСЭ. Нужен ли будет кому-то такой сертификат - большой вопрос. Вариант второй - забить на сертификацию. И что-то по общению с коллегами я вижу, что многие стали склоняться к этому варианту развития событий. Слишком большие усилия необходимо предпринять с обеих сторон (и в штаб-квартире, и в России), чтобы получить минимально возможный класс. Овчинка не стоит выделки.

А заказчикам стоит задуматься, им нужны шашечки или ехать? 

ЗЫ. Кстати, с сертификацией даже на 6-й класс сейчас тоже немало интересного происходит. Прописанный в требованиях ФСТЭК к доверию фаззинг - это то еще приключение, "карта" которого не понятна до конца даже регулятору, не говоря уже об испытательных лабораториях и заявителях. 

Подробнее…

Тенденции рынка пентестов - от полной автоматизации до краудсорсинга

Наткнулся тут на новый канал в Телеграме - СекьюриСТ, в котором автор недавно коснулся темы пентестов и описал вкратце, что это такое. Я вообще не очень люблю эте тему, но тут так совпало, что при формировании программы сочинского "Код ИБ. Профи", по просьбам участников в нее был включен практический доклад Жени Волошина из BI.ZONE, как раз посвященный пентестам. Поэтому я решил тоже тиснуть небольшую заметку, но скорее о некоторых тенденциях, которые за пределами России существуют в этой области. Понятно, что не все из них дойдут до нас, но учитывая, что регуляторы в лице ФСТЭК и ЦБ начинают активно требовать проведения тестов на проникновение, понимание рыночных трендов будет полезно.

Напомню, что пентесты бывают трех основных типов, отличающихся по своему объему работу, выбранным целям, уровню автоматизации и длительности. Это условное деление, но оно в целом отражает действительность. В отличие от сканирования уязвимостей (хотя его иногда выдают за пентесты), тестирование на проникновение заключается в реализации многовекторных и многошаговых сценариев с последующей попыткой проникновения в сеть компании, используя найденные уязвимости.

Red Teaming - это более продвинутая версия пентестов, отличающаяся большей длительностью, более сложными атаками, попытками скрыть свое присутствие в системе, привязкой к актуальным TTP злоумышленников и, в итоге, более высокой ценой.

У классического пентеста есть, однако, свои слабые места. Обычно, это небольшая группа исследователей (один-два человека), которые не всегда могут найти все слабые места, которые есть в выбранными вами для пентеста целях. Понятно, что это не всегда и нужно, но все-таки, если в вашу модель угроз включены продвинутые злоумышленники, то уровень квалификации пентестеров должен быть им под стать. Во-вторых, в традиционной модели оказания услуг на проникновение, это осуществляет периодически, например, один раз в квартал или даже один раз в год. В условиях внедрения современных подходов к DevOps у вас инфраструктура может быть месяцами уязвима, а вы не будете об этом знать. В-третьих, классическому пентестеру присущ одноименный синдром, когда в итоговый отчет попадает немало уязвимостей (даже с высокой степенью риска), которые непонятно как эксплуатировать злоумышленнику (а в отчет они попали только потому, что пентестер нашел один непропатченный сервер в ДМЗ). И таких уязвимостей может быть очень много - без контекста разбираться в них становится сложновато и ценность пентеста падает. Наконец, пентестер получает деньги независимо от того, нашел он что-то или нет в рамках своей работы (обычно, конечно, находят).

Чтобы уйти от этих проблем сегодня активно рассматривается в качестве альтернативы платформы для краудсорсингового пентеста, в рамках которых, десятки и сотни исследователей начинают "ломать" вас, ища уязвимости в вашей инфраструктуре и в ваших приложениях (преимущественно именно в них). В отличие от обычного пентестера, краудсоринговый исследователь получает деньги только за обнаруженную уязвимость (за это такой анализ еще называют bug bounty program), а сам процесс поиска может быть непрерывным, что позволяет встраивать такой краудсорсинговый пентест в практику DevOps. Примерами таких платформ можно назвать Synack или HackerOne Challenge.

В российских условиях, правда, краудсорсинговый пентест не имеет больших перспектив. По крайней мере для тех компаний, которые плотно подсели на нормативку ФСТЭК или ЦБ, требующую, чтобы анализ защищенности проводил только соответствующий лицензиат, в зависимость от которого и попадает компания, желающая провести пентест своей инфраструктуры. У тех же, кто не связан ограничениями нормативных требований, появляется большая гибкость в проведении анализа собственной защищенности - в краудсорсинговых платформах и экспертиза исследователей пошире, и проведение тестов начинается гораздо раньше, и оплата осуществляется только за результат (хотя определенные деньги провайдеру платформы платить все-таки надо).

Однако не стоит думать, что краудсорсинговые пентесты поглотят классику. Все-таки у крадсорсинговой модели анализа защищенности есть и свои ограничения. В частности, с ее помощью гораздо сложнее проводить тестирование внутренней сети или устройств Интернета вещей. В этом сценарии классический пентест пока подходит лучше. Однако и тут есть свои тренды. Например, активное внедрение автоматизации в процесс проведения тестов на проникновение. И речь идет не только о решениях класса Breach and Attack Simulation (BAS), яркими представителями которых являются компании AttackIQ, Cymulate, SafeBreach, Threatcare, Verodin и другие. Сейчас стал нарождаться новый сегмент рынка ИБ, в котором уже есть такие компании как CyCognito, Pcysys. Randori, SCYTHE, которые предлагают инструментарий для автоматизации пентестов.

Эти решения практически не представлены на российском рынке и врядли когда-либо будут у нас сертифицированы. Однако, и это положительно, явных требований по применению при проведении тестов на проникновение сертифицированных средств защиты вроде как нигде и не предусмотрено (если не рассматривать фразу про сертифицированные средства контроля защищенности при получении лицензии ФСТЭК на соответствующий вид деятельности). Это означает, что российские игроки рынка пентестов могут автоматизировать свою деятельность, предложив заказчикам более качественную услугу, чем это было раньше. Правда, только при условии наличия желания это сделать.

ЗЫ. У вас еще есть шанс успеть зарегистрироваться на сочинский "Код ИБ. Профи" и послушать доклад Евгения Волошина, посвященный пентестам.

Подробнее…

Новые положения Банка России: новые требования и новые вопросы

После того, как осенью прошлого года ЦБ получил новые полномочия по установлению требований по безопасности не только в рамках НПС, но и вообще для кредитных и некредитных организаций, финансовой регулятор выпустил сразу несколько новых нормативных актов:

• 672-П - положение по защите информации в платежной системе Банка России, которое пришло на смену 552-П. Это первое положение регулятора, которое ссылается на ГОСТ 57580.1 с базовыми защитными мерами. Однако, эта ссылка, наряду с упоминанием и обязательным использованием 382-П, у меня вызвало некоторую фрустрацию. Дело в том, что ГОСТ 57580.1 построено по совершенно иной идеологии - оно разрешает самостоятельный выбор защитных мер. В отличие от 382-П, которое обязывает применять определенный набор из защитных мероприятий. Получается, что в одном документе нас отсылают на ГОСТ с самостоятельным выбором мер ИБ и на 382-П, где меры уже за нас выбраны Банком России. И какой тогда смысл было ссылаться на ГОСТ?
• 683-П - положение по защите информации, суть и необходимость которого от меня немного ускользает, так как я не могу до конца понять его соотношение со схожим 382-П. Да, у них есть и некоторая разница, но все-таки сфера их действия достаточно сильно пересекается. Можно было бы предположить, что 683-П - это прообраз будущего нормативного акта, который заменит 382-П и в котором не будет обязательного списка защитных мер, которые уйдут в ГОСТ. Но пока 382-П продолжает действовать...

Ключевые вехи 683-П

•  684-П - положение по защите информации для некредитных финансовых организаций. Этот документ устанавливает требования для НПФ, клиринга, репозитариев, ПИФов, депозитариев, брокеров, управляющих, регистраторов и других свои требования по защите информации в соответствие с ГОСТ 57580.1. Самое неприятное в этом нормативном акте - сертификация платежного/финансового ПО в ФСТЭК на наличие уязвимостей и НДВ (видимо, все-таки, на их отсутствие) или анализ уязвимостей по ОУД4. Боюсь, что многие финансовые организации просто не в состоянии это будут сделать до 1-го января 2020 года (осталось всего 7 месяцев). И, кстати, к какому уровню защиты относить микрофинансовые организации? В 684-П про это ни слова и возникает вопрос - они вообще должны что-то делать с точки зрения защиты или ГОСТ 57580.1 на них не распространяется? 

Ключевые вехи 684-П

В связи с этими новыми документами у меня, после их прочтения, возникло ряд вопросов:

• ЦБ ссылается на требования ФСТЭК по сертификации на наличие уязвимостей или НДВ. Но у ФСТЭК такие требования отменены были еще до принятия документов ЦБ и заменены на уровни доверия. Какой уровень доверия должен быть у прикладного ПО по требованиям ЦБ? ЦБ обещал выпустить профиль для сертификации такого ПО, но только к концу года. Откуда разработчики платежного софта, особенно если это внутренняя разработка, как у многих, получат ДСПшные документы ФСТЭК? И будут ли испытательные лаборатории ФСТЭК заниматься такой сертификацией, если ФСТЭК регулярно говорит на мероприятиях, что они берутся за сертификацию только средств защиты информации?
• Если пойти по пути не сертификации прикладного ПО, а анализа уязвимостей по ОУД4, то какова процедура и форма подтверждения для этого варианта? Можно ли проводить анализ защищенности самостоятельно, как это написано в 684-П, или в 683-П/672-П надо привлекать лицензиатов ФСТЭК?
• Как (и зачем) проводить оценку соответствия одновременно по 382-П и ГОСТ 57580.2? Особенно в тех случаях, когда сроки этой оценки не совпадают. И я молчу про оценку по СТО БР ИББС, которую до сих ряд банков продолжает делать, так как формально она не отменена (как и сам СТО).

Активность созданного в прошлом году Департамента ИБ можно только приветствовать, но появляется слишком много вопросов даже по относительно "старым" требованиям. Чего уж говорить о свежих требованиях по той же ЕБС или по еще невыпущенным требованиям по финтеху (цифровому профилю, маркетплейсу, мастерчейну), СУОР и другим.

Ну а в заключение сводный слайд по все возрастающей отчетности по ИБ, объем которой только возрастает.

Подробнее…

О методике ФСТЭК по поиску аппаратных уязвимостей и НДВ

На фоне обвинений Китая в закладках на уровне материнских плат, которые звучали в начале года, я прошел обучение по теме тестирования аппаратной части современных ИТ-решений на предмет поиска различных уязвимостей - от контрафакта или клонирования до закладок и временных бомб в кремнии. Это было очень познавательный тренинг, который расширил мои знания в области тестирования не только программной, но и аппаратной части средств обеспечения безопасности. Кстати, рынок такого контрафактного оборудования (включая и содержащего закладки) оценивался в 2011-м году в полторы сотни миллиардов долларов с ежегодным ростом этого значения в 25%.

Чуть позже, ФСТЭК выпустила ДСПшную методику выявления уязвимостей и недекларированных возможностей в программном обеспечении. Интересно то, что в этом документе ФСТЭК декларировала появление методики выявления уязвимостей и НДВ в аппаратном обеспечении. А вчера стало известно об обнаружении уязвимости в процессорах Intel, названной Zombieload. Это продолжении серии уязвимостей Spectre, Meltdown и Foreshadow, найденных в продукции главного производителя процессов за последнее время. Интересно, что исследования, позволившие найти данную уязвимость, длились больше года.

И вот тут у меня появилось ряд вопросов, которые я позволю себе просто озвучить в рамках данной заметки:

1. Планирует ли регулятор разрабатывать свою методику с нуля или будет ориентироваться на уже существующие стандарты (AS6081, AS5553, AS6171 и ARP6178 от SAE G-19A, CTI CCAP-101, IDEA-STD-1010 и др.) в этой и смежных областях, например, в аэрокосмической? Они хоть и не посвящены целиком безопасности, но очень недурно описывают таксономию методов поиска.
2. Будут ли методы поиска уязвимостей и НДВ в новом документе привязаны к уровням/классам защищаемой информации/систем? Допускаю, что да, но тут важно не требовать очень уж серьезных проверок на низких уровнях доверия (например, на 6-м). Учитывая, что таких методов существует немало, то это будет непростая задача.





3. Будет ли методика учитывать различные типы аппаратных компонентов - цифровые (например, ASIC или FPGA, как это сделано в ряде иностранных средств защиты уже сейчас), аналоговые (например, АЦП и ЦАП или DAC и ACD в англоязычной литературе), дискретные (например, резисторы, диоды, транзисторы и т.п.)?
4. Какие требования будут предъявляться к разработчикам средств защиты в части аппаратных компонентов? Особенно учитывая, что сегодня нет российских ИБ-производителей, которые бы изготавливали железо целиком сами. А уж использование чужих компонентов, часто из Китая или Тайваня, происходит сплошь и рядом.



5. Как будет учитываться тот факт, что сегодня НДВ может быть внесена в процессе транспортировки готового изделия от производителя к потребителю? Или вообще быть внесена уже в процессе эксплуатации (если используется перепрограммируемые микросхемы). В этом случае процедура выявления на стороне производителя ничего не даст.
6. Насколько увеличится цена работ по сертификации?
7. Насколько увеличится длительность работ по сертификации? Она и сейчас не очень маленькая и часто срок сертификации превышает срок жизни конкретной версии оцениваемого ПО. А уж при наличии нового документа ситуации и вовсе станет аховой.
8. Наличие оборудования для проведения соответствующих работ; особенно сертифицированного по требованиям регулятора. Во-первых, оно очень дорогое для определенного типа проверок. А, во-вторых, оно не выпускается в России.



9. Будут ли выставлены требования по компетенциям сотрудникам испытательных лабораторий? Если да, то где им проходить обучение? А если нет, то не превратится ли процесс оценки в профанацию?
10. Как ФСТЭК будет проверять качество проводимых работ и есть ли у самого регулятора соответствующие специалисты? 
11. Что делать, если у ИЛ или регулятора появятся вопросы к используемым аппаратным компонентам? Недавно один из российских производителей МСЭ поделился своей болью. Для выполнения одного из пунктов методики проверки МСЭ по новым требованиям ФСТЭК, им потребовалось поменять ряд ранее используемых аппаратных модулей, из-за чего стоимость возросла в разы. И, конечно же, эти затраты будут возложены на плечи заказчиков, большая часть из которых относится к государственных органам, которые обязаны будут применять только сертифицированные средства защиты.
12. Будут ли признаваться результаты СИ/СП, проводимых по линии ФСБ, для тех решений, которые подаются на сертификацию еще и в ФСТЭК?
13. Готова ли ФСТЭК к существенному изменению правил игры, которые даже многие отечественные вендоры не смогут соблюдать?

Вот такая чертова дюжина вопросов к еще неразработанному документу регулятора. Вполне допускаю, что у регулятора уже есть на них ответы. Но, вспоминая песню Слепакова, "а чё, мля, если нет?" 

А напоследок вам задачка, какие из представленных ниже семплов могут представлять угрозу?

ЗЫ. В рамках упомянутого выше тренинга нам рассказывали о применении нейросетей для выявления несущих угрозу аппаратных компонентов, что в очередной раз показало очень интересные варианты применения машинного обучения в кибербезопасности. Но пока не в России.

Подробнее…

Почему ФСТЭК блокирует использование облачных платформ Threat Intelligence?

Продолжу-ка я тему, начатую позавчера, и разверну вопрос, упомянутый вскользь, - облачная аналитика Threat Intelligence. Я упомянул, что новые сертификационные требования ФСТЭК по требованиям безопасности фактически делают невозможным оперативное получение данных об угрозах из облаков. Причина такого решения ФСТЭК мне понятна - они опасаются нанесения ущерба защищаемым объектам из таких облаков. Рисков два - утечка информации из защищаемой сети в облако и получение из него вместо обновлений вредоносного кода.

Что можно сделать в такой ситуации? Как, например, можно обновлять антивирус или систему обнаружения атак, требующие регулярного получения сигнатур? Флешка - самый простой вариант, который нередко используется сертифицированного решениями. Или создается нечто вроде прокси-шлюза, который отвечает за обновление всех средств защиты внутри защищаемого объекта, а сам он обновляется с помощью той же флешки или через однонаправленный канал. Например, именно такой вариант используют те же решения "Лаборатории Касперского", которые применяют не обычную KSN, а ее приватную версию - KPSN (Kaspersky Private Security Network). Кстати, и при сертификации "Касперского" подавалась именно KPSN, а не KSN. Схожая схема используется в тех же решениях Cisco, которые могут обмениваться данными с облачной песочницей Threat Grid, а могут с локальной, работающей даже в режиме "air-gap". EDR-решение Cisco AMP имеет как управление из публичного облака, так и из частного. Но вариант с флешкой или локальным сервером обновления (или той же "песочницей") работает только в случае, когда источник обновления всего один - от самого вендора средства защиты.

Но сегодня нельзя доверять одному вендору. И дело не в том, что он может прекратить свое существование или неоперативно обновлять свои средства защиты. Он не может "видеть" и знать все и обо всем. Например, он может хорошо разбираться в угрозах для финансовых организаций, но не иметь представления о промышленных атаках. Или он может прекрасно разбираться в атаках, присущих для европейского региона, но не "видеть" азиатских или американских операций хакеров. В любом случае потребитель хочет иметь возможность резервировать источники получения информации об угрозах. Поэтому сегодня многие современные защитные решения поддерживают функцию работы с различными TI-сервисами по стандартизованным протоколам - STIX/TAXI, OpenIOC, CyBOX и т.п. В этом случае вы можете существенно повысить эффективность купленных решений.

Но не в том случае, если вы хотите использовать сертифицированное ФСТЭК решение, так как было показано выше облачная аналитика угроз де-факто недопустима регулятором. Вы еще можете заменить флешкой один источник данных TI. Ну два; ну три. Но десятки или даже сотни уже нет. И вы встаете перед выбором - иметь сертификат и отказаться от оперативного обновления средства защиты данными о новых появляющихся атаках (оперативно - это один раз в 3-5 минут, а не один раз в день) или нарушить сертификат, повысив защищенность своей компании и подключив множество внешних TI-источников напрямую. Правда, последний вариант у меня вызывает вопросы, так как и сертифицировать решение с поддержкой таких подключений в ФСТЭК нельзя. Третий вариант я озвучил позавчера - забить на сертификацию и начать дышать полной грудью, выбирая то, что нужно, а не то, что есть в реестре сертифицированных решений (рабочий вариант, если вы не госорган).

ЗЫ. Да, стоит отметить, что описанные проблемы касаются только тех решений (а они преимущественно не отечественные), которые умеют работать не только со своими источниками обновления, но и с независимыми внешними источниками. Если же у решения только один канал получения сигнатур, данных по уязвимостям, индикаторов компрометации, то достаточно, чтобы производитель смог подтвердить доверенность канала обновления (хотя это отдельная тема - доверие к каналу и источнику обновления) или возможность получения обновлений на флешке или через локальный сервер.

ЗЗЫ. Отдельный вопрос - как проверить облачную площадку на соответствие новым требованиям к доверию? Ведь такое облако является частью сертифицируемого решения и его тоже надо "подавать" на оценку соответствия. И что-то я пока не вижу, как можно новую методику ФСТЭК по поиску НДВ и уязвимостей применить к облачной платформе, неотчуждаемой от вендора (и уж тем более расположенной за пределами РФ)?

Подробнее…

Новые требования ФСТЭК по сертификации еще больше сужают рынок средств защиты

Вчера на сайте ФСТЭК было опубликовано информационное сообщение об утверждении требований по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий. Данный документ вступает в силу с 1-го июня 2019 года и приходит на смену РД на  НДВ, который по сути прекращает свое действие. Новые требования по доверию, о которых ФСТЭК говорила уже давно, являются обязательными для всех разработчиков средств защиты и заявителей на сертификацию ФСТЭК. Уже становится традицией, что этот документ, а также идущая с ним в паре методика выявления уязвимостей и недекларированных возможностей, носят пометку "для служебного пользования" и широкому кругу лиц недоступны.

Меня в этом информационном сообщении заинтересовал только один пункт, а именно следующий: "Разработчикам и производителям сертифицированных средств защиты информации рекомендуется с привлечением испытательных лабораторий провести оценку соответствия средств защиты информации Требованиям к уровням доверия и представить результаты в ФСТЭК России для переоформления соответствующих сертификатов соответствия. Действие сертификатов соответствия средств защиты информации, в отношении которых указанная оценка соответствия не будет проведена до 1 января 2020 г. на основании пункта 83 Положения о сертификации средств защиты информации, утвержденного приказом ФСТЭК России от 3 апреля 2018 г. N 55, может быть приостановлено" (выделение мое).

Если читать этот абзац буквально, то все действующие сертификаты должны быть пересмотрены до 1-го января следующего года (вот у испытательных лабораторий работки-то подвалит) и в них должны появиться приписки по поводу соответствия требованиям по доверию. Не хочется быть гонцом с плохими вестями, но подозреваю, что не все разработчики, особенно зарубежные, смогут пройти проверку даже на 6-й уровень доверия, что означает для некоторых разработчиков, что их попросят "выйти вон" с рынка. И все в рамках абсолютно законной процедуры, направленной на повышение национальной безопасности.

Надо заметить, что после фактического запрета на сертификацию решений с облачной Threat Intelligence (а куда сейчас без нее) многие применяемые в России продукты и так были несертифицируемы, но новый посыл регулятора недвусмысленно дает понять взятый курс. Отсюда простой вывод (как мне кажется) - коммерческим компаниям надо прекратить заморачиваться вопросом с сертификацией по требованиям безопасности (на безопасность это не влияет никак, а ограничивает очень сильно), а государственным органам можно только посочувствовать - возможности выбора ими средств защиты станут с одной стороны проще (продуктов останется совсем мало), а с другой стороны сложнее (конкуренция падает, а за ней и качество).

ЗЫ. Но есть и хорошие новости. Но после обеда :-)

Подробнее…

О сертификации блокчейна по требованиям безопасности

Вчера я наскоком был на РусКрипто (в этом году не смог остаться подальше, и интеллектуальную игру не смог провести сегодня), на секции по блокчейну. Пока ждал своего выступления вдруг подумал, что даже если бы в России и были свои решения по кибербезопасности на базе блокчейна (системы управления идентификацией, SIEM, системы уведомления об инцидентах и т.п.),  то их было бы невозможно сертифицировать по текущим требованиям ФСТЭК по безопасности.

Ведь если посмотреть на текущий подход регулятора, то он мог бы быть описана тремя словами - изоляция, статика и централизация. То есть сертифицируемое средство защиты должно быть четко описано, иметь определенные границы и среда функционирования должна быть понятна. В случае с блокчейном это требование не соблюдается. Нет ни границ, ни понятной среды функционирования. Со статикой тоже все непросто. Число участников блокчейна может меняться, а так как его узлы составляют объект оценки при сертификации, то надо либо забыть о статике, либо забыть о сертификации (или менять ее правила). Ну а централизация в принципе противоречит идее блокчейна (если это, конечно, не закрытый частный блокчейн). Вот и получается, что если бы кто-то у нас решил создать систему защиты на блокчейне, то сертифицировать ее в текущих условиях было бы невозможно. Думаю, что и аттестовать тоже.

В рамках дискуссии у слушателей возник схожий вопрос о сертификации по линии ФСБ. И хотя тот же "Мастерчейн" Ассоциации Финтех сейчас находится на этапе сертификации в ФСБ (хотелось бы взглянуть на ТЗ), у многих участников сессии возникли закономерные вопросы о том, можно ли вообще сертифицировать блокчейн по требованиям криптографического регулятора. Ведь у него тоже, и местами даже более жестко, стоят требования к среде функционирования, которая в случае с блокчейном заранее не определена и, самое неприятное, может изменяться в процессе эксплуатации непредсказуемым образом. Если же оценивать (именно оценивать, а не сертифицировать) только криптографию в рамках блокчейна, то возникнет вопрос об оценке всего решения в целом - кто ее будет проводить и нести ответственность за законченное решение? Вопрос с оценкой безопасности алгоритма консенсуса тоже стоит достаточно остро, но на этот вопрос ответа вообще сегодня нет.

Отдельно стоит вопрос о применении требований безопасного программирования, а возможно, и сертификации (хотя бы по уровням доверия) смарт-контрактов, но этот вопрос вчера на РусКрипто не поднимался вообще.  И как подступиться к этому вопросу пока вообще непонятно.

Подробнее…

Реестр сертифицированных средств защиты ФСТЭК 2.0

Близится конференция ФСТЭК, на которой помимо вопросов КИИ будут рассказывать о новой методике обеспечения доверия (взамен НДВ), практике оценке соответствия в соответствии с новым приказом ФСТЭК №55 по сертификации и т.п. И приснилось мне тут во сне, что один из докладов мог бы быть посвящен абсолютно новой версии реестра сертифицированных средств защиты ФСТЭК, который, как мне кажется, является самой популярной и самой востребованной страницей сайта регулятора. И вот выходит представитель воронежского ГНИИ ПТЗИ и начинает свой доклад (не по бумажке и с отличными слайдами).

Уважаемые коллеги! Все вы знаете, что одной из задач ФСТЭК является ведение реестра сертифицированных средств защиты информации, который является подспорьем для всех заказчиков, которые ищут для своей безопасности средства защиты информации, прошедшие оценку соответствия в форме обязательной сертификации. Мы давно и планомерно улучшаем реестр, расширяя его функциональность и повышая оперативность размещения в нем сведений о новых сертификатах. Если раньше данный реестр приходилось скачивать на комьпютер для полноценного поиска в нем, то сегодня это можно сделать сразу на сайте с помощью соответствующей строки поиска/фильтрации. Также, начиная с 2019-го года мы стали обновлять реестр не раз в квартал, как было раньше, а в течение суток после появления нового сертификата.

Однако мы не стоим на месте и хотим вам представить новую версию реестра, работа над которой сейчас завершается и в самое ближайшее время она будет представлена общественности. Сегодня же мне бы хотелось кратко рассказать о тех нововведениях, которые вас ждут и которые были реализованы опираясь на опыт работы с банком данных угроз и уязвимостей ФСТЭК. Те, кто активно пользуется БДУ знают, что в нем реализована эффективная система фильтрации, позволяющая быстро находить среди двух десятков тысяч уязвимостей те, которые вас интересуют. Мы решили перенять этот опыт и реализовали в новой версии реестра фильтрацию по всем полям реестра. Если раньше, например, можно было искать теперь можно легко найти все сертификаты, в которых упоминалось конкретное решение (например, Cisco ASA) наряду с его заявителем и испытательной лабораторией (надо было только в строке поиска указать через пробел три слова), то в новой версии мы сделали возможность более сложных множественных фильтров, учитывающих также диапазон дат действия сертификата и схему сертификации. Кроме того, у нас появилась возможность поиска всех сертификатов, которые начали свое действия позже указанной даты, а также сертификатов, которые завершают свое действие до указанной даты. Это позволит быстрее искать сертификаты, которые, например, скоро прекратят свое действие.

Для стимуляции заявителей более оперативно устранять выявленные в их продуктах уязвимости, мы решили добавить информацию об отозванных сертификатах и причинах этого. Кроме того, теперь доступа возможность поиска в уже недействующих сертификатах, для того, чтобы своевременно выявлять неточности в маркетинговых материалах отдельных компаний, использующих недобросовестную конкуренцию и рекламу.

Помимо расширения функции поиска и фильтрации, мы решили вставлять ссылки на требования, по которым сертифицировался тот или иной продукт. Это позволит сразу увидеть, какие требования проверялись в процессе оценке соответствия. При этом ссылка дается не на весь руководящий документ, а на конкретную таблицу с проверяемыми требованиями. Кроме того, мы добавили ссылки на сайт заявителей, на которых можно получить более подробную информацию о возможности приобретения сертифицированных средств защиты (это позволит поддержать наших разработчиков и стимулирует их развитие), а также о возможностях обновления сертифицированных решений.

Несмотря на то, что ФСТЭК исключила практику указания в сертификатах ссылок на классы защищенности информационных систем, в которых возможно применять сертифицированное средство защиты, в новой версии реестра появилась возможность такой подсказки. Наведя курсором на соответствующее упоминание класса защиты будет появляться подсказка, в каких классах защищенности ГИС, ИСПДн, АСУ ТП или КИИ могут применяться указанные решения. Разумеется, речь идет только о подсказке, которая, однако, очень востребована заказчиками, которые не всегда хорошо разбираются в мерах защиты, разработанных регулятором.

Наконец, мы решили сделать еще один большой шаг вперед и будем выкладывать теперь копии всех сертификатов, чтобы потребителям не пришлось искать их в Интернет или клянчить у заявителей, которые не всегда готовы делиться этими документами. Это вызывает раздражение у потребителя и поэтому мы решили помимо выходных данных сертификатов, в реестре также давать возможность скачивания и скан-копии самого сертификата. Для защиты от подделки таких сертификатов мы планируем ввести соответствующие цифровые "водяные" знаки. Кроме того, учитывая, что основными потребителями, использующими сертифицированные средства защиты, являются госорганы, мы думаем о том, чтобы снабжать копию каждого сертификата электронной подписью, что будет гарантировать ее подлинность. Пока вопрос еще не решен, но возможно, мы также будем выкладывать на сайт еще и ТУ (или выписки из них).

В заключение мне хотелось бы объявить о еще двух новшествах, связанных с реестром. Во-первых, мы добавим по аналогии с БДУ раздел инфографики, где можно будет увидеть статистику по сертификации различных типов средств защиты, наиболее активных заявителях и испытательных лабораториях, а также ряд других интересных графиков и диаграмм, отражающих процесс сертификации средств защиты информации. А во-вторых, мы запустим официальный Твиттер-канал для реестра сертифицированных средств защиты, в котором будут размещаться новости о новых, завершающих свое действие, продленных или отозванных сертификатов. Аналогичный Твиттер-канал действует для банка данных угроз и уязвимостей и он показал свою эффективность. За два года с момента его запуска мы опубликовали 170 обновлений, что говорит о том, что частота публикации в нем составляет около одного твита в четыре дня.

Уважаемые коллеги! На этом позвольте мне завершить свое краткое выступление про новую версию реестра сертифицированных средств защиты информации, которая в ближайшее время будет запущена и доступна для всех потребителей сертифицированной ФСТЭК продукции. Большое спасибо за внимание!

ЗЫ. Дабы у читателей не возникло мысли, что это все взаправду, я еще раз хочу отметить, что это моя фантазия, сон. Хотя такие мечты есть у многих коллег по цеху, судя по результатам опроса, который я проводил неделю назад в своем Твиттере и в Телеграме.

Подробнее…