Показаны сообщения с ярлыком ФСТЭК. Показать все сообщения
Показаны сообщения с ярлыком ФСТЭК. Показать все сообщения

27.10.21

Куда падает качество нормативки наших регуляторов и что с этим делать?

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

Давайте к примерам? Возьмем методику оценки угроз ФСТЭК, утвержденную 5-го февраля этого года. ЭТОГО! Но уже известно, что регулятор готовит в нее поправки. Документу от силы было полгода, когда регулятор решил вносить в него изменения, которые, согласно публичным высказываниям регулятора, планируют утвердить в первом квартале уже следующего года. У Банка России такая же проблема. 716-П по рискам вступило в силу 1-го октября прошлого года, но уже готов проект с поправками в него на 30+ (!) страниц. Не это ли свидетельство того, что документ получился сложным для восприятия? Ну а как может быть иначе, когда у вас нормативный акт занимает 130 страниц и к нему еще готовится ГОСТ на 180 страниц. 300 страниц (!), которые можно было бы изложить на одной странице формата А4! И это только один пример - у ЦБ таких косяков просто масса (отдельный пост им посвящу). РКН со своим 1046-м Постановление Правительства по надзору в области персональных данных тоже накосячил - и в расширительном толковании отдельных терминов, и синтаксических ошибках. И это только три примера, которые достаточно свежие и от разных регуляторов, но их ведь гораздо больше.   

Как с этим бороться? На мой взгляд вариантов решения проблемы всего несколько. Первый - сформировать пул лояльных специалистов, которые не будут зависеть от регулятора, и через которых можно было бы пропускать проекты нормативки с обещанием принять всю критику и постараться ее исправить. Причем делать это адресно в обе стороны, а не так обезличенно, как это сейчас работает на regulations.gov.ru. Хотя где найти таких специалистов в достаточном количестве? Все же реально ссут сказать что-то супротив регулятора, от которого зависит сертификация выпускаемых твоей компанией продуктов или обновление/расширение лицензии или еще какие-то ништяки. Надо сказать, что это не совсем проблема регулятора, что у нас исторически все боятся сказать что-то против политики партии, но и его тоже - он же поощряет ее.

Второй вариант - при выходе каждого нормативного акта давать переходный период в 6-12 месяцев на его апробацию и без введения его в контур обязательных требований. Тогда первые желающие смогут попробовать что-то сделать, наступить на все грабли и сообщить о них регулятору, который внесет поправки в свои документы и выпустит уже гораздо более проработанный с точки зрения практики документ. Но и тут есть подводные камни. Не все захотят по доброй воле апробировать необязательные пока еще нормативные требования. А потом нужно время на повторную регистрацию документов в МинЮсте, что занимает много времени (сейчас доходит до шести месяцев). Ну и проблема "бесстрашных" рецензентов из предыдущего пункта тоже никуда не девается.  

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

Хорошей практикой является обучение. Есть высказывание, что когда начинаешь готовить материал для обучения и преподавать, то начинаешь лучше разбираться в вопросе (а почему я так активно преподаю, а?). А когда начинаешь рассказывать, что же ты имел ввиду в документе по 10 раз перед разными людьми, тогда лучше начинаешь понимать и область регулирования и свои корявые формулировки. Можно, конечно, сделать вариант-минимум - читать перед подчиненными, но они же правду в глаза не скажут все равно. Поэтому только публичная активность, но на это рассчитывать не приходится - не приучен у нас регулятор к публичной критике, а еще и отомстить может.  

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

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

26.10.21

Моделирование угроз в процессе разработки ПО

Решил я тут раскрыть чуть больше краткую заметку в своем Telegram, посвященную моделированию угроз в процессе разработки ПО. Я написал следующее: "Методика оценки угроз ФСТЭК не применяется при моделировании угроз в рамках безопасной разработки. Учитывая, что ФСТЭК уделяет последней очень много внимания, стоит ли ждать отдельного документа/стандарта по этому вопросу? Пока у меня нет ответа на этот вопрос, хотя появление ГОСТа по этой теме было бы логичным.

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

- STRIDE от Microsoft (и Threat Modeling Tool от них же)

- OWASP - (и Threat Dragon Tool от них же)

- Матрица угроз ATT&CK для CI/CD

- Инструмент Materialize Threats Tools

- threatspec

- The Raindance Project

- PyTM

- Meta Attack Language

- Agile Threat Modeling Toolkit"

Коллеги обратили мое внимание, что у ФСТЭК есть разделы в ГОСТах по безопасной разработке, посвященные моделированию угроз. И вот этот момент я бы и хотел прокомментировать. Если мы возьмем ГОСТ Р 56939 "Разработка безопасного ПО. Общие требования", то в разделе 5.2.1 говорится, что разработчик должен провести моделирование угроз, а в разделе 5.2.3.1 этот вопрос раскрывается чуть подробнее, но и в нем не приводится никакой методологии моделирования, а всего лишь уточняется, что она должна быть и что документация разработчика должна содержать описание выбранной методологии, список выявленных угроз и список мер, эти угрозы нейтрализующих.

Эта процедура моделирования из методики Microsoft

Список угроз можно найти в другом стандарте - ГОСТе Р 58412 "Разработка безопасного ПО. Угрозы безопасности информации при разработке ПО", в котором перечислено 19 угроз. Но в нем также нет методологии выбора из перечисленного перечня угроз актуальных. Да и сами угрозы достаточно высокоуровневы и хотелось бы иметь их большую детализацию. Например, огромный пласт угроз для процесса CI/CD или угрозы, реализуемые через репозитории кода, объединяются в одну - угрозу внедрения уязвимостей программы из-за неверного использования инструментальных средств при разработке ПО. Лично мне не хватает в ГОСТ 58412 деталей, - тех же техник и тактик, которые есть в методике ФСТЭК, процедуры выбора угроз, примеров, то есть ровно того, что сделает документ практически полезным в работе.

А, например, угрозы при использовании API куда попадают в рамках упомянутого ГОСТа? А отсутствие шифрования или хотя бы хэширования паролей в разрабатываемых приложениях? А отсутствие контроля вводимых параметров? Или это не угроза, а уязвимость переполнения буфера (хотя SQL Injection это именно угроза)? А угрозы генерации неслучайных чисел в "датчиках случайных чисел"? А работа с памятью, позволяющая выполнять вредоносный код от имени привилегированных пользователей/процессов? А, в конце концов, нарушение правил контроля доступа, которое отвечает за 10 из 30 основных проблем безопасности ПО? Или такой уровень детализации не является предметом регулирования ГОСТ 58412? Вообще, хотелось бы видеть либо что-то аналогичное проекту CAPEC от MITRE (раз уж мы так активно используем концепции этой корпорации у нас), либо ссылку на возможность его использования в том же ГОСТе 58412 (рах уж мы ссылаемся на CAPEC в методике оценки угроз от 5-го февраля).

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

Ее, кстати, нет и в текущей методике оценки угроз, что ставить нас перед непростой задачей - какую из актуальных угроз нейтрализовывать первой, какую второй, какую третьей и т.д. Ровно то, о чем я писал в июне, рассказывая о методике TARA той же MITRE. А применительно к моделированию угроз в рамках безопасной разработке за основу такого метода ранжирования можно взять DREAD от Microsoft, а можно и что-то другое.

А пока я остаюсь при своем мнении относительно того, что пока у нас нет методики оценки угроз в рамках процесса безопасной разработки. Но именно что пока...

27.9.21

Круглый стол "Формальная безопасность vs практическая безопасность: как достичь синергии"

Вторым круглым столом на конференции "Кибербезопасность нового времени", проведенной Innostage в рамках казанской DigitalWeek, был "Формальная безопасность vs практическая безопасность: как достичь синергии", который получился не таким, как я его задумывал изначально, готовя вопросы. Поэтому в этой заметке я буду говорить не столько о самом круглом столе, сколько о том, во что вылилась дискуссия и что я про все это думаю.

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

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

Или вот еще история. В самом начале круглого стола, который проходил сразу после выступления Романа Чаплыгина из Positive Technologies об открытых стандартах по ИБ (лучших практиках, создаваемых сообществом), я задал вопрос в зал, сколько из них знает о профессиональном стандарте 12.004 "Специалист по обнаружению, предупреждению и ликвидации последствий компьютерных атак", который был утвержден в 2015 (!) году? Шесть лет назад! Было всего 3 поднятых руки! Всего три на зал из 150 человек. А все потому, что этот стандарт имеет пометку "для служебного пользования". Ну вот о каких открытых стандартах можно говорить, если регуляторы у нас так любят политику засекречения всего, даже списка навыков, которым должен обладать специалист по реагированию на инциденты ИБ? Но интересно не это, а то, что получить этот документ нереально. Если вы запросите его в Минтруде (захотите найти - спрашивайте в Минтруде приказ 1179н/дсп от 29.12.2015), вам откажут и пошлют в ФСБ. Запрос в ФСБ тоже закончится ничем - вас отправят в Минтруд. Вот такой замкнутый круг. А я напомню, что согласно ПП-584 от 27.06.2016 профстандарты являются обязательными к применению всем государственным и муниципальным учреждениям, фондам, а также предприятиям, компаниям и корпорациям, что принадлежат государственным либо муниципальным органам власти (на праве владения более чем 50% от уставного капитала).

Еще одна обсуждаемая на круглом столе тема - трактовки требований регуляторов. Это вообще боль; даже для самих регуляторов, в которых написание требований и их проверка - это часто разные подразделения. А тут еще приближенные к регуляторам компании, которые часто участвуют в разработке требований в составе рабочих групп. Представители этих компаний потом выступают на мероприятиях, в чатах, в соцсетях и выдают собственное мнение за позицию регулятора. Ну есть еще и просто эксперты, которые также по своему трактуют требования нормативных актов. И вот у нас уже 4 разных точки зрения на один документ. И как тут быть? Участники круглого стола, например, Виктор Вячеславов из Innostage, Шальнов Олег из Росэнергоатома или Александр Дубасов из ФГБУ ЦНИИОИЗ Минздрава, посоветовали общаться с регулятором, задавать ему вопросы. Но тут всплывает классическая история - лучше не светиться :-( Наши регуляторы любят при общении с народом задавать вопрос: "Представьтесь, пожалуста" или "Какую организацию вы представляете?" Ну и кто захочет отвечать на такой вопрос? Смельчаков мало. Вот и любят у нас все ждать, когда кто-то храбрый сам спросит регулятора, а потом выложит ответ в каком-нибудь чатике. А сам регулятор, не видя вопросов, считает, что все нормально. Или он видит вопросы с мест, но не хочет публично показывать, что он поторопился с каким-то требованием. Поэтому и информационные письма с разъяснениями он не часто выпускает, ограничиваясь короткими комментариями в узком кругу специалистов или на закрытых встречах. И те, кого на этих мероприятиях "за закрытыми дверями", нет, потом вынуждены слушать пересказы и играть в испорченный телефон.

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

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

Вот такой был круглый стол в Казани, который не ограничился только залом, а вышел за его пределы и дал возможность поговорить с участниками "не под камеру". А это всегда ценно.

ЗЫ. Мне кажется, что регуляторам надо выпускать свои документы тройками - сами требования,  разъяснения к ним для тех, на кого требования распространяются, и методика их проверки (в идеале тоже публичная). Все три документа должны быть взаимоувязаны между собой. Тогда и проблем ни с их толкованием, ни выполнением, ни проверкой не будет (ну кроме редких ошибок и клинических идиотов). Прислушался бы кто-нибудь, а?!

13.9.21

Перевод MITRE ATT&CK и ее маппинг на техники ФСТЭК

В пятницу, на конференции Kaspersky ICS Cybersecurity Conference, я выступал с темой "Основные сценарии реализации угроз на АСУ ТП и их преломление на методику оценки угроз ФСТЭК" (презентацию выложил в своем Telegram-канале). К этому выступлению я планировал завершить перевод последней версии матрицы MITRE ATT&CK v9 на русский язык и маппинг техник ФСТЭК в техники MITRE ATT&CK, что и было сделано (ссылки будут ниже).

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

Первым делом я перевел текущую, девятую версию матрицы MITRE ATT&CK на русский язык. Да, я прекрасно понимаю, что специалист по ИБ должен знать английский и должен самостоятельно читать матрицу MITRE в оригинале, но, увы, это пожелание далеко от реализации и многие не так хорошо говорят/понимают по-английски, как того хотелось бы. Да чего там, я сам не могу похвастаться хорошим знанием языка :-) Но это не помешало мне перевести названия техник ATT&CK на русский язык.


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


Второй и, наверное, более серьезной задачей было найти соответствие между 145 техниками ФСТЭК и 400+ техник MITRE ATT&CK. Сразу скажу, что это была более сложная работа, так было не всегда просто понять, что имел ввиду наш регулятор под той или иной техникой? Иногда техники повторялись по смыслу, но чуть-чуть отличались по тексту. Иногда смысл техники вообще ускользал от меня. Иногда техника ФСТЭК могла быть описана сразу несколько техниками ATT&CK. В ряде случаев у техник ФСТЭК отсутствовал аналог в ATT&CK (такое тоже было, но нечасто). Наконец, необходимо отметить, что если ATT&CK использует не только техники, но и подтехники, описывающие детали реализации для конкретной платформы (Windows, Linux, облака и т.п.), то у ФСТЭК все ограничивается только уровнем техник, что также не всегда позволяет сделать четкое сопоставление.


В итоге я выполнил достаточно творческое упражнение, в результате которого транслировал техники ФСТЭК в техники MITRE ATT&CK. Допускаю, что у кого-то может быть свой вариант маппинга (я знаю, как минимум, о двух схожих инициативах), но, думаю, что моя оценка точна более чем на 80%.  


В октябре должна быть анонсирована новая, 10-я версия, MITRE ATT&CK и я планирую обновить свои переводы и маппинг. Кроме того, у меня в планах перевести матрицу ATT&CK for ICS, провести маппинг техник ФСТЭК с ней, а также провести обратный маппинг - из ATT&CK в ФСТЭК. Пока все сделано в Excel (мне было так удобнее), но, возможно, я сменю формат или просто экспортирую перевод и маппинг в что-то другое (ODS или CSV).

Переводы и маппинг выложил пока в свой Telegram-канал "Пост Лукацкого", но думаю над Google.Drive и Github (точнее я туда уже тоже выложил, но пока не пойму, где удобнее). Но судя по опросу, проведенному в Телеграме, большинству удобнее, чтобы файлы были выложены именно там.

24.8.21

2 государевых модели угроз, авторы которых забили болт на требования ФСТЭК

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

  • Где модель нарушителя? Предположу, что это в неопубликованной части, но что-то по тексту это не прослеживается. Либо модели нарушителя не было вообще, либо на сайте выборов опубликовали не просто выписку, а отдельно написанный документ для публичного ознакомления. Походя указано, что администраторы могут иметь деструктивные наклонности и негативно повлиять на инфраструктуру ДЭГ и поэтому для борьбы с этим предлагается использовать... СКЗИ (как связаны СКЗИ и возможность противодействия деструктивным действия администраторов, я не знаю).
  • Меня немного удивило заявление, что в ДЭГ не обрабатываются специальная категория персональных данных о политических взглядах. При выборах в Госдуму и при волеизъявлении в пользу той или иной политической партии ДЭГ не обрабатывает данных о политических взглядах? Смелое заявление, отображающее стремление занизить уровень защищенности ИСПДн. Но рассчитано явно на людей, плохо соображающих или тех, с кем есть договоренность. С другой стороны, РКН модель не согласовывает, а ФСТЭКу в целом все равно, какой там уровень защищенности ИСПДн, если класс защищенности ГИС 1-й. 
  • Также, видимо, в целях снижения уровня защищенности ИСПДн в ДЭГ признаны неактуальными недокументированные возможности (читай, закладки) на уровне ОС и приложений. Я склонен был бы согласиться с таким выводом, если бы речь шла о ИСПДн какой-либо noname-компании, но система для государственных выборов?.. Но тогда возникает вопрос, зачем там СКЗИ класса КА, которое как раз от таких угроз среди прочего и защищает? 
  • Кстати, о криптографии. А где угрозы по этой части? В выписке написано, что модель разрабатывалась в соответствие с 676-м Постановлением Правительства, но в нем есть требование согласования модели не только с ФСТЭК, но и (а не или) с ФСБ, которой все равно, что написано в БДУ, но которая требует, чтобы были указаны угрозы именно по части СКЗИ. Но их в опубликованной выписке нет. Видимо, в закрытой части.  
  • А что есть в открытой, так это упоминание необходимости применения СКЗИ при общении с  избирателем и СКЗИ это должно быть класса КС1. Но как это сделать, если у избирателя нет браузера "Спутник" или он работает с мобильного устройства? По тексту допускается применение шифрования RSA (написано, что это даже согласовано), но вот зачем тогда упоминается КС1? Кстати, меня покоробило упоминание RSA в контексте шифрования данных. Обычно с помощью RSA шифруется только сеансовый ключ, а уж сам сеанс защищается симметричной криптографией, включенной в протокол TLS. Ну да оставим это на совести тех, кто писал часть по криптографии - она вообще очень куцая в выписке.
  • В выписке перечислен чуть ли не весь банк данных угроз, признанных актуальными для ДЭГ, но я не нашел в модели, описывающей угрозы для системы на базе блокчейна, угроз для собственно самого блокчейна. Они признаны неактуальными? 
  • В одной из своих презентаций, я рассказывал о том, как была взломана три года назад компания British Airways. Одной из высказанных версий назывался взлом не самого сайта авиакомпании, а кеширующих серверов CDN, которые не контролировались самой BA. Так вот в описании модели угроз ДЭГ также говорится об использовании CDN, но ни слова о том, что эти распределенные сервера входят в контур защиты ДЭГ и что для них рассматривались угрозы. Возможно технология взаимодействия с избирателями никак не завязана на CDN и угрозы ему признаны неактуальными, "а что, мля, если да", как пелось в известной песне Слепакова? 
  • В приложении А в выписке отображена архитектура ДЭГ. Если она верна, то компоненты всей системы работают через VPN, а Интернет используется только на получение данных от избирателей. То есть, если верить опубликованной схеме, у членов избирательных комиссий нет прямого выхода в Интернет для того, чтобы посерфить в свободное от мониторинга голосования время. И это правильно. Но тогда зачем в списке актуальных угроз фишинг и фарминг? А откуда взялась угроза внедрения ВПО через рекламу (члены электронных избирательных комиссий рекламу смотрят)? А угрозы внедрения ВПО при посещении зараженных сайтов? Угроза хищения информации из cookies? Зачем рассматривать угрозы, которых по идее быть вообще не должно на рабочих местах людей, ответственных за голосование? 
Но основной вопрос, который у меня возник после прочтения этой выписки, связан не с упомянутыми выше темами. Вопрос в другом. В феврале этого года ФСТЭК утвердила методику оценки угроз, которая является обязательной для всех ГИС (а система дистанционного электронного голосования относится к ним). В этом нормативном документе описана и структура модели угроз, которая должна быть, и ряд обязательных элементов, среди которых сценарии реализации угроз. Но где они в выписке? Они судя по всему отсутствуют и в закрытой части. ПОЧЕМУ?


Почему владельцы государственной информационной системы забили болт на требования регулятора по ИБ? И если такое сделано публично, то почему остальные госорганы не должны сделать тоже самое? И почему субъекты КИИ, операторы ИСПДн и АСУ ТП не должны следовать той же логике?

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

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

27.7.21

Калькулятор оценки технологической зрелости соответствия 239-му приказу

 Несколько лет назад, а именно пять, я писал о том, как можно было бы облегчить жизнь с реализацией приказов ФСТЭК, внедрив неку/ю модель зрелости, которая бы позволила оценивать текущий уровень реализации требований регулятора и выстраивать некую дорожную карту достижения желаемого уровня соответствия. К сожалению, описанная мной тогда идея так и осталась идеей и, в отличие от NIST, который к своему фреймворку CSF предложил как раз схожую тему, наш регулятор, видимо по причине загруженности в условиях нехватки кадров, оставил этот вопрос в стороне. И вот на днях подумал я, что неплохо бы реализовать такую идею самостоятельно, что я и сделал. Итак, представляю калькулятор оценки технологической зрелости реализации приказа №239 ФСТЭК (для значимых объектов КИИ).


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

В итоге получилась вот такая табличка, где для каждого блока защитных мер были выделены 5 уровней зрелости, характеризующихся применением тех или иных технологий или тем или иным уровнем автоматизации. Например, на первом уровне блока ИАФ (идентификация и аутентификация) компания применяет обычные пароли для своих пользователей. Затем она переходит к многофакторной аутентификации, потом задумывается о Zero Trust или 802.1x начинает аутентифицировать не только пользователей, но и устройства. Потом компания созревает до доступа к своим активам внешних пользователей и начинает аутентифицировать их, а в финале, на пятом уровне зрелости, применяет федеративную систему аутентификации, применяемую в том числе и на внешних ресурсах - облаках и т.п.

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

Но и с обнаружением вторжений ситуация не столь сложна, как с аудитом безопасности, под которым приказ 239 понимает не только классический аудит, но и мониторинг ИБ, а также применение решений по анализу трафика, которому, на мой взгляд, место больше в обнаружении вторжении. Но такова уж карма термина "активный аудит", который в России известен уже давно и в него засовывают и обнаружение вторжений, и анализ защищенности. Но и с этим я тоже справился. В итоге получилась небольшая таблица, в которой достаточно всего лишь 20 раз выбрать нужный уровень вашей технологической зрелости, после чего будет отрисована радарная диаграмма, показывающая уровень зрелости по каждому из блоков защитных мер и насколько нам далеко до желаемого/рекомендуемого уровня. Кстати, о последнем. Я его выбирал опираясь на собственный опыт. При желании там можно поиграться с уровнем, к которому надо стремиться.

Вот такой вот легонький инструмент, который я выложил у себя в Телеграме.

10.6.21

От техник и тактик угроз к мерам обнаружения и защиты. Как сопоставить первое со вторым?

Читая методику оценки угроз ФСТЭК, собственно как и матрицу MITRE ATT&CK, понимаешь, что делается это все не просто так, а для какой-то цели (вот новость-то). И целью этой является выработка защитных мер, которые позволят нам противодейстовать выбранным нами как актуальными техникам и тактикам нарушителей. Еще во время появления первых документов ФСТЭК в 2013-м году многие эксперты задавались вопросом, а как увязать защитные меры с моделью угроз. У ФСТЭК пока нет ответа на этот вопрос, а вот у MITRE есть. Ему я и посвящу данную заметку.

В фреймворк MITRE ATT&CK помимо техник и тактик входит еще один блок - защитных мер (mitigations), которые увязаны с блокируемыми ими техниками и тактиками.


Таким образом, выбрав актуальные для вас техники и тактики, можно перейти к мерам, которые позволяют их нейтрализовать. На текущий момент фреймворк MITRE ATT&CK содержит 42 защитные меры (для мобильных устройств еще 13 защитных мер), среди которых шифрование важных данных, антивирус, контроль сетевого доступа, управление привилегированными учетными записями, обновление ПО, программа Threat Intelligence и т.п. Среди 42-х мер (вот он ответ на главный вопрос жизни, вселенной и всего такого) есть и такая "не надо блокировать", в описании которой сказано, что реализация защитной меры может повлечь рост риска компрометации: а значит нейтрализация не рекомендуется (сейчас техник, для которых эта рекомендация дана, всего две).


Для многих техник и тактик в матрице указаны не только защитные меры, но и источники данных, которые позволяют их детектировать с помощью различных технологий - от XDR и SIEM до антивирусов и средств контроля целостности файлов и ПО.


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


Самое интересное, что 42 защитные меры от MITRE ATT&CK могут быть смаппированы в различные иные защитные фреймворки - ISO 27001/27002, NIST CSF и CIS Controls. Например, вот так этом может выглядеть для последнего фреймворка.  

В защитные меры из приказов ФСТЭК тоже можно смаппировать, но про это в другой раз.

2.6.21

Что не покрывает методика оценки угроз ФСТЭК?

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

Во-первых, угрозы, связанные с шифровальными средствами, регулируются различными публичными и не очень документами ФСБ, в том числе:

  • «Методические рекомендации по разработке нормативных правовых актов, определяющих угрозы безопасности ПДн, актуальные при обработке ПДн в ИСПДн, эксплуатируемых при осуществлении соответствующих видов деятельности» (утверждены руководством 8 Центра ФСБ России 31 марта 2015 года, № 149/7/2/6-432)
  • «Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности» (утверждены приказом ФСБ России от 10 июля 2014 года № 378).
Во-вторых, финансовые организации, которые являются либо операторами ПДн, либо владельцами ЗОКИИ, обязаны соблюдать помимо документов ФСТЭК еще и документы Банка России, а именно два действующих Указания:
  • Указание Банка России от 10 декабря 2015 г. № 3889-У «Об определении угроз безопасности ПДн, актуальных при обработке ПДн в ИСПДн»
  • Указание Банка России и ПАО «Ростелеком» от 9 июля 2018 г. № 4859-У/01/01/782-18 «О перечне угроз безопасности, актуальных при обработке, включая сбор и хранение, биометрических ПДн, их проверке и передаче информации о степени их соответствия предоставленным биометрическим ПДн гражданина РФ в государственных органах, банках и иных организациях, указанных в абзаце первом части 1 статьи 14.1 Федерального закона от 27 июля 2006 года N 149-ФЗ «Об информации, информационных технологиях и о защите информации», в единой биометрической системе»
Также, ввиду внесения крупных изменений в законодательство по Единой биометрической системе, сейчас планируется выход двух новых указаний Банка России по угрозам персональным данным при их передаче финансовыми организациями в ЕБС и внутренних системах биометрических ПДн в финансовых организациях.

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

Разные методики моделирования угроз

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

Но если внимательно посмотреть на описанные зоны действия методики, то мы увидим, что она, например, плохо подходит для оценки угроз при разработке программного обеспечения, что, например, требуется по отечественным ГОСТам по безопасной разработке. В этом случае вам потребуется что-то другое. Например, хорошим стартом может послужить методика от Microsoft, которую для краткости называют STRIDE, хотя она этой аббревиатурой и не ограничивается. Она, безусловно покарывает не все угрозы для ПО, но самые популярные точно. Кроме того, по ней существует немало материалов и курсов, а также бесплатные средства автоматизации данной задачи. Можно еще посмотреть в сторону методики OWASP, но она не сильно отличается от Microsoft'овской.

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

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

31.5.21

Магия моделирования угроз по ФСТЭК

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

  1. ФСТЭК обязывает использовать БДУ, как основной источник данных об угрозах, но он вообще никак не синхронизирован с текущей методикой оценки. Методика требует оценивать угрозы для 6 свойств информации, а БДУ описывает их только для трех (классической триады - КДЦ). БДУ использует понятие "потенциал", которое хоть и отличается от "уровень возможностей нарушителя" из методики, но все же идентично. Но в БДУ таких уровней 3, а в методике уже 4. Кстати, кто-то может объяснить отличие "базового" уровня от "базового повышенного" и "базового повышенного" от "среднего"? Если уж за год с лишним (а о новом подходе в моделировании угроз объявили еще в феврале 2020-го года и тогда же обещали, что в БДУ уже вносятся изменения) в БДУ так и не смогли внести изменения, то может выпустить письмо о неприменении БДУ на переходный период? А то на курсах один из самых популярных вопросов - как натянуть БДУ на новую методику.
  2. С источниками угроз тоже все непросто. В одном месте ФСТЭК пишет, что они рассматривают только антропогенные источники, то бишь людей. В другом, что техногенные тоже нужно, если к системам и сетям предъявляются требования к устойчивости и надежности. А вы вообще видели где-нибудь системы, к которым не предъявляются такие требования?
  3. Зачем ФСТЭК при классификации уровней возможностей нарушителей использовала букву Н, получив 4 уровня возможностей, - от Н1 до Н4? А то, что ФСБ использовала эту букву в своей классификации моделей нарушителей Н1-Н6, регулятора не волнует? И да, кому какое дело, что госорганы по 676-П обязаны согласовывать свою модель с двумя регуляторами и чтобы это сделать, они вынуждены писать 2 модели и согласовывать их по отдельности. Да-да, я помню, что проблемы индейцев шерифа не волнуют.
  4. Я бы вообще при определении уровней возможностей нарушителей вернулся к первоначально рассматриваемой идее с потенциалом нападения из ГОСТ 18045, который позволяет оценить все возможности по идентификации слабых мест и их использовании и разделить их именно на 4 уровня. Но в отличие от методики ФСТЭК в ГОСТе эти уровни вычисляются по элементарной и понятной формуле, которая не позволяет скатиться в волюнтаристскую экспертную оценку.
  5. Про категории нарушителей я уже писал и вновь повторюсь - смысла деления на внутренних и внешних нарушителей сегодня никакого нет. Эта грань уже давно канула в небытие и тратить время на то, чтобы понять, кем является китаец из Zoom (а он внутренний нарушитель по методике), смысла нет. Избыточное упражнение, которое не дает никакого эффекта с точки зрения защитных мероприятий, но отнимает время.
  6. С перечнем возможных нарушителей тоже не все просто. По сути вроде все верно - определили актуальных по их мотивации, а остальных отсекли. Но на практике все немного иначе. Согласно методике, если поставщик внешних услуг (например, облачный провайдер) отказывается предоставлять мне свою модель угрз (а кто ж ее предоставит-то?), то я должен исходить из предположения, что против меня действует нарушитель с максимальным уровнем возможностей, то есть спецслужба иностранного государства. А можете ли вы себе представить организацию, которую не использует внешних и обслуживающих себя систем? Например, DNS-сервера, которые можно прекрасно атаковать и подменить записи соответствия доменных имен и IP-адресов, перенаправив жертву с сайта, например, ФСТЭК на сайт клон. Получается, что те, кто завязан на сервисы Zoom, Google, Cloudflare, Box, Яндекс, Mail.ru, Ростелекома и т.п., должны всегда рассматривать спецслужбы в своей модели угроз со всеми вытекающими отсюда последствиями? Ну надо было так и прописать, что этот нарушитель для всех обязателен - сэкономили бы кучу времени.
  7. Кстати, о спецслужбах иностранных государств. КГБ Беларуси относится к таковым? А КНБ Казахстана? С АНБ и ЦРУ вроде вопросов нет, но вот что с остальными, менее известными обычному безопаснику спецслужбами или спецслужбами дружественных нам, а местами и союзных государств. У меня в ВУЗе был даже отдельный предмет (секретный), на котором нам рассказывали об оргструктуре разведывательных органов и иных спецслужб разных государств. А откуда этот список взять при моделировании? А террористы и экстремисты? С ними все понятно (хотя ФСТЭК могла бы и сослаться на реестр террористических и экстремистких организаций, которые ведут Минюст и ФСБ) и мы должны опасаться атак со стороны Свидетелей Иеговы и ФБК Навального. 
  8. Кстати, рассматривать ли санкции в отношении меня как угрозу ИБ? Если мне, например, отключат обновления средств защиты или операционной системы и приложений, то это повлечет за собой негативные последствия. Очевидно. И более того, это будет сделано с умыслом. А что за источник угрозы, который будет реализовывать данную угрозу? Антропогенный ли он? Ну, допустим, что иностранное государство, которое и реализует эту угрозу, мы персонифицируем до ее Президента или госсекретаря (хотя это и очень условно). Но кто будет нарушителем в классификации ФСТЭК? Максимально возможный вариант - это спецслужба иностранного государства, но не они вводят санкции. Так кого же писать в этом случае в модель?
  9. Почему, взяв за основу MITRE ATT&CK при описании своих техник и тактик угроз, ФСТЭК решила придумать свои тактики и свои техники? Где-то они совпадают, а где-то нет. И ладно, если бы регулятор пошел бы по пути MITRE и описал бы субтехники для разных платформ, добавил бы еще соответствие техник и хакерских групп (у MITRE их почти 100 описано) или хотя бы хакерского инструментария (у MITRE их почти 400 описано), но нет. Все надо придумывать самим и даже опыт MITRE ATT&CK тут не сильно помогает - я пытался смаппировать одно в другое и у меня не очень-то и получилось. А что мешает регулятора заставить всех своих лицензиатов, которые имеют SOCи и выпускают бюллетени Threat Intelligence, описывать угрозы, используя ТТУ от ФСТЭК, а не от супостатной MITRE? У нас импортозамещение или где? Да, пусть они по-прежнему используют TTP от ATT&CK, раз уж у нас НКЦКИ ориентирован на американские стандарты Threat Intelligence (тот же TLP или ATT&CK). Но пусть маппят и в техники ФСТЭК, не перекладывая эту проблему на потребителей (это второй по популярности вопрос на курсе - как соотнести уже имеющиеся отчеты и описания угроз и инцидентов по MITRE ATT&CK в то, что делает ФСТЭК?).
  10. Последний момент связан с перечислением актуальных сценариев реализации угроз. Вы же в курсе, что сначала вы должны составить перечень всех угроз, потом оставить из них возможные, а потом уже определить актуальные? Вы же понимаете разницу между возможной угрозой и актуальной? Возможная становится актуальной, если есть хотя бы один сценарий реализации угрозы. А вы видели угрозы, для которых нет хотя бы одного сценария? Сценарий же это не последовательность из обязательно всех десяти тактик. Одна техника (например, сканирование) тоже может быть сценарием. Но проблема даже не в очередном ненужном этапе (выделении актуальных угроз из списка возможных), а в том, что какие бы сценарии у вас не были (а число их комбинаций из 145 имеющихся техник и 10 тактик измеряется даже не триллионами), все они все равно состоят из ограниченного числа техник. Их всего 145. Если я смогу определить и нейтрализовать эти 145 техник, то какая мне разница, сколько у меня сценариев их использующих? Ровно на этом построены почти все зарубежные подходы, базирующиеся на MITRE ATT&CK, и ровно эта идея заложена в зарубежные средства защиты, которые борются не со сценариями угроз, а с конкретными техниками. И сравнивают продукты по обнаруживаемым/блокируемым техникам. И пентесты и редтиминг по техникам выстраивают, а не по сценариям. Этап с определением сценариев надо убирать - он лишний. Все равно весь рынок ИБ (что консалтинговый, что продуктовый) заточен именно на техники.

Всего 10 вопросов я вынес в эту заметку, но даже они показывают, что регулятор сам не пропускал через свою методику ни свой сайт, ни свою ИС бухгалтерии или кадров, ни даже ИС своего подведомственного воронежского института. Если бы он это сделал, то сразу бы сам и наткнулся на явные косяки методики, с которыми сейчас сталкиваются, как минимум, все госорганы, которые обязаны согласовывать свои модели угроз по 676-му Постановлению Правительства. И то, что должно было облегчить им жизнь, сделало ее только хуже. Особенно тем, кто должен был ввести в эксплуатацию свои системы весной/летом этого года, но неожиданный выпуск новой методики и отсутствие переходного периода на ее внедрение спутал все карты и увеличил сроки на выполнение обязательных требований, сорвав ввод в эксплуатацию или, что чаще всего, заставив сделать процесс моделирования для галочки.

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

ЗЫ. Решить описанные проблемы можно одним из двух вариантов - поменять методику или выпустить средство автоматизации, которое проведет "за ручку" своих адептов по шагам, не давая им думать, а просто выбирая нужные варианты из выпадающих меню или ставя нужные чекбоксы.

19.4.21

Моделирование нарушителей по методике ФСТЭК: теория и реальность

В последнее время, либо готовясь к выступлению на различных мероприятиях, либо помогая нашим заказчикам в понимании методики оценки угроз ФСТЭК, я в очередной раз убеждаюсь, что регулятор сам так и не попробовал незамутненным взглядом пройтись по своему документу и никак не учитывал, что компании и производители средства защиты уже не первый год занимаются моделированием угроз немного не так, как это написал регулятор. Например, многие давно используют матрицу MITRE ATT&CK, которая стала стандартом де-факто в мире, но наш регулятор, позаимствовав идею с kill chain, не подумал (или не захотел, что еще хуже) синхронизировать свои техники с техниками ATT&CK. Например, когда я попробовал Топ10 техник ATT&CK, использованных шифровальщиками в 2020-м году, наложить на техники ФСТЭК, у меня получилось так, что совпадение между ними всего на 80%. Да, мы можем добавить к 145 техникам ФСТЭК техники ATT&CK (методика это позволяет), но в условиях их несовпадения придется потратить немало времени на сопоставление.

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

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

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

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

У отдельных организаций могут быть также включены конкуренты в список нарушителей. Госорганам в этом плане повезло - у них нет конкурентов (кто захочет с ними конкурировать?). А что с разработчиками ПО? Среди предлагаемых регулятором целей мы видим следующие. "Накосячить" - отбрасываем. Получение конкурентных преимуществ или финансовой выгоды. Тоже отбрасываем - ну не интересны мы компании Microsoft или Google или Apple ни с точки зрения конкуренции, ни с точки зрения денег. Есть еще одна странная цель - "внедрение дополнительных функциональных возможностей в ПО на этапе разработки", но что это, я не совсем понял. Речь о закладках? Или о том, что программисты напишут код и забудут его задокументировать (а иначе какой же он дополнительный?)? Тоже самое и остальных категорий нарушителей - они если и встречаются в реальной жизни, то достаточно редко. В итоге мы имеем на выходе всего 5 помеченных на картинке выше типов актуальных нарушителей.

Расслабились? Подождите. Это еще не все. Посмотрите на свою текущую инфраструктуру. Я подозреваю, что она не полностью изолирована от внешнего мира. Более того, я на 100% уверен, что она задействует внешние сервисы. Да хотя бы тот же DNS. А еще есть файловые хранилища, системы групповой работы, видеоконференции, CRM-системы и т.п. Да много чего еще. И все это принадлежит не вам, а кому-то. Согласно же методике, если поставщики таких систем, не оценили или предоставили вам свои оценки угроз, то вы должны исходить из того, что против вас действует нарушитель с максимальным уровнем возможностей (п.2.11), то есть спецслужба иностранного государства.

То есть, чтобы вы ни делали, уровень возможностей нарушителя, с которым вам придется бороться, будет все равно максимальным и большого смысла в сокращении числа актуальных нарушителей нет :-(

13.4.21

Моделирование угроз по ФСТЭК - лайфхак

Одним из камней преткновения в новой методике оценки угроз является пункт о необходимости составления перечня возможных сценариев реализации угроз, который нереализуем сегодня. Во-первых, нет средств автоматизации, а использование зарубежных разбивается о нестыковки и несовместимость ТТУ и TTP ФСТЭК и MITRE соответственно. Во-вторых, вы должны досконально знать все методы злоумышленников, чтобы составить такой список, а у нас этому нигде особо и не учат. Да, кто-то может быть имеет то, что иностранцы называют "Attacker mindset" ("мышление хакера"), но мне кажется, что 97% специалистов по ИБ знают только одну сторону - оборонительную, защитную. В-третьих, само по себе это занятие не имеет большого смысла, так как у вас в природе не существует средств или мер защиты, которые бы помогали бороться именно со сценариями реализации угроз. А это значит, что смаппить сценарии в защитные меры по 17/21/31/31v2017/239-м приказам ФСТЭК будет нельзя.

Я пытался, но с ходу так и не вспомнил ни одного проекта, где кто-либо пытался составить перечень возможных сценариев. Все ограничиваются именно техниками. Такая-то группа использует такие-то техники. Об этом пишут Cisco. Fireeye, Crowdstrike, Касперский и множество других компаний по ИБ. Возьмем, к примеру, китайскую группировку APT41 (она же Double Dragon, она же Winnti Group, она же Barium, она же Axiom). Согласно исследовательским отчетам она использует не менее 40 различных техник MITRE ATT&CK. Например, Информзащита недавно опубликовала отчет об обнаружении Winnti на ряде промышленных предприятий России (перед этим, правда, долго пыталась доказать, что публикация TTP может нанести ущерб Российской Федерации и должна быть согласована с ФСБ :-)


А вот пример отчета другого лицензиата ФСТЭК, компании Positive Technologies, которая, как считают многие, приложила руку к разработке методики оценки угроз ФСТЭК. Они обнаружили группировку, названную ими Calypso:


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

Ведь какие бы сценарии вы не напридумывали (имеет ли вы такой опыт или нет), они все будут ограничены комбинациями из 145 техник ФСТЭК или 200+ техник ATT&CK. Ну, возможно, вы придумаете еще какие-то свои техники. Но врядли их будут тысячи или даже сотни. Скорее всего вы не выйдете за рамках ТТУ ФСТЭК или TTP ATT&CK. И средства защиты вы будете искать те, которые будут закрывать не сценарии реализации угроз, а техники. 

Привязка конкретных проявлений атаки к ATT&CK в Cisco Secure Malware Analytics

Более того. Чем еще интересен проект MITRE ATT&CK? У них есть не только матрица тактик и техник атак. И не только список APT-групп с присущими ими TTP (у нас эту задачу должна была бы решать ГосСОПКА или ФинЦЕРТ, но будут ли они описывать действия нарушителей по методике ФСТЭК, - большой вопрос). Есть у них еще и список защитных мер, которые связаны с нейтрализуемыми тактиками и техниками. И многие производители средств защиты внутри своих продуктах не только делают отсылки на TTP, но и предоставляют своим заказчикам матрицы соответствия своих решений защитным мерам по ATT&CK. Например, вот так это выглядит у нас в Cisco: 

То есть упомянутый выше лайфхак будет звучать как "фокусируйтесь на определении техник реализации угроз, а не их сценариях". Это без снижения качества результата (все равно нейтрализовывать мы будем техники) позволит существенно сэкономить по времени и усилиям. Определить же нужные вам техники вы можете либо по отчетам различных ИБ-компаний, либо по сайту MITRE ATT&CK (по списку группировок/нарушителей или используемому ими инструментарию), либо с помощью инструмента CARET.

Фрагмент работы CARET для группировки Winnti (красным подсвечены актуальные техники)

Так мы же работаем не по MITRE ATT&CK! Мы же должны по ТТУ от ФСТЭК строить систему защиты! И да, и нет. В методике оценки угроз написано, что вы вполне имеете право использовать и MITRE ATT&CK в том числе. Так используйте. А вот будет ли регулятор обращать внимание, что сделанный вами перевод TTP немного отличается от названий ТТУ, вопрос не такой уж и важный. Суть методики вы же уловили верно и я не думаю, что регулятор будет лезть в бутылку и настаивать на слепом соблюдении буквы документа, который реализовать в текущем виде нельзя.

12.4.21

Методика оценки угроз ФСТЭК: первая попытка применить ее на практике

Для курса по моделированию угроз, который я читаю в Информзащите, и курса по методике оценки угроз именно ФСТЭК, который я читаю в Аста74, в последнее время я стал глубже копать то, что сотворил наш регулятор, чтобы попробовать сделать что-то практичное и практически полезное. Учитывая, что ключевой проблемой всей методики является ее последняя часть, посвященная составлению списка возможных сценариев реализации угроз, я попробовал применить опыт, имеющийся при использовании матрицы MITRE ATT&CK. Начал я с трансляции 11-го приложения документа ФСТЭК в более привычный по ATT&CK и более удобный Excel-формат для работы с таблицами (результат выложил у себя в Telegram-канале).

Дальше у меня была 2 простых идеи; раз уж я не участвовал в работе над последней редакцией методики. Во-первых, я подумал смаппировать ТТУ (тактики и техники угроз) по методике ФСТЭК с TTP (tactics, technics and procedures) по MITRE. А, во-вторых, подумалось мне, что сделать версию ATT&CK Navigator на базе отечественных техник и тактик было бы неплохим подспорьем для автоматизации (а там можно было бы и над переводом Unfetter подумать). Но когда я стал сравнивать ТТУ и TTP меня ждало разочарование.

Оказалось, что они плохо соотносятся друг с другом. 10 тактик ФСТЭК являются результатом объединения ряда тактик MITRE. Но если это еще можно как-то объяснить, то вот техники там уже перемешаны более сильно. Например, техника Т1.7 у ФСТЭК описывает сбор данных, предоставляемых DNS-сервисами. В ATT&CK это уже две техники - T1590.002 (сбор сетевой информации о цели - DNS) и T1596.001 (поиск в открытых базах данных - DNS/Passive DNS).     

А, например, техника Т4.1 описывает несанкционированное создание или кражу учетных записей. У MITRE это вообще отдельная тактика "доступ к учетным записям" (Credential Access), в которой 15 основных и 52 второстепенных техники. И как их соотносить?

Разумеется, если постараться, то соотнести можно, но вот смысл теряется. Если бы ТТУ ФСТЭК были простым переводом TTP, то маппинг бы имел смысл, так как тогда можно было бы легко задействовать все базирующиеся на MITRE ATT&CK инструменты. Например, тот же ATT&CK Navigator. Простой open source инструмент, который облегчает работу с тактиками и техниками, позволяя легко описывать сценарии атак (если не брать в расчет их возможное количество), описывать те сценарии, которые не закрываются текущими мерами защиты, проводить тесты средств защиты и проводить кучу иных мероприятий.

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

Поддержка ATT&CK в подсистеме threat hunting в Cisco Secure Endpoint (бывший AMP4E) 

Возможно, у ФСТЭК есть идея сделать схожую штуку и для отечественных производителей. Правда, что делать российским вендорам, которые активно работают на зарубежных рынках и которые поддерживают в своих решениях именно  MITRE ATT&CK? В том же Kaspersky EDR (версия Expert) это есть. В своей аналитике "Касперский" тоже привязывает обнаруживаемую вредоносную активность к ATT&CK. Теперь им делать двойную работу?

Отчет Kaspersky MDR с привязкой к ATT&CK

PT NAD с поддержкой ATT&CK

Вот пытаюсь я понять, в чем был смысл городить огород с собственной, нестыкуемой с ATT&CK, матрицей ТТУ и не могут понять :-( Возможно регулятор повторит путь MITRE и сообщества, которое участвует в работе над ATT&CK, и не ограничится одной таблицей в Word, а создаст реальный фреймворк с автоматизацией, API, поддержкой в российских продуктах (которые никто не поймет за пределами РФ, так как там все пользуются ATT&CK - привет, декларируемый Президентом страны экспорт российских ИТ). Но верю я в это пока с трудом - у ФСТЭК нет для этого ни денег, ни людей. Да и от краудсорсинга регулятор в последнее время отказался - делая все свои активности закрытыми и ограниченными только отдельными лицензиатами.  

Сводная аналитика по вредоносному коду с привязкой к ATT&CK в Cisco Secure Malware Analytics 

Но даже если все это будет создано, то возникает вопрос, как пользоваться результатами труда сотен зарубежных компаний, которые в своих отчетах используют привязку именно к ATT&CK? Кто будет сопоставлять TTP с ТТУ? Закроемся от всего мира и опустим железный занавес на отрасль ИБ? Ну тоже вариант. Правда, что делать с киберпреступниками, которые границ не признают, и данные по которым, присутствуют, например, в сервисе CARET, построенном на базе ATT&CK? Сейчас я могу ввести в него набор выявленных мной техник и инструмент подскажет мне группировки, которые могут стоять за атаками. И наоборот. Если в процессе моделирования нарушителей, я определился с актуальными для меня, CARET поможет мне определить, какие техники они используют, сильно сократив время на анализ.  

Пример описания техник, используемых одним из нарушителей с помощью ATT&CK

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

ЗЫ. Кстати, за основу средства автоматизации моделирования угроз и определения тактик и техник на базе MITRE ATT&CK, которое могло бы лечь в основу инструментария ФСТЭК, обещанного в этом году, можно взять Unfetter, который я уже описывал три года назад. Оно доступно в формате open source. Правда, его делало Агентство национальный безопасности и это может стать камнем преткновения для наших регуляторов :-(

29.3.21

Математическая оценка читабельности нормативных актов регуляторов

Если мне не изменяет память, то в одном из романов Айзека Азимова из серии про Академию (она же "Фонд", она же "Основание") был фрагмент о том, что речь галактического чиновника прогнали через специальный алгоритм оценки осмысленности речи, чтобы понять, что важного было сказано за всей той канцелярщиной, которой так изобилует речь государевых мужей. И, о, ужас, оказалось, что несмотря на многочасовую речь, уровень ее осмысленности был равен нулю. Я раньше думал, что это такой красивый литературный ход, пока не столкнулся с различными технологиями DLP, синтаксического и семантического анализа, которые позволяли оценивать текст с разных точек зрения. И вот на днях, я наткнулся на интересный проект plainrussian.ru, который позволяет оценивать читабельность текста.

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

Начал я с документа, который всегда вызывал сложность при его изучении. Речь про 382-П от Банка России. А все потому, что почти каждый абзац начинался со одинаковых конструкций "Оператор по переводу денежных средств, оператор услуг информационной инфраструктуры, банковский платежных агент (субагент) должен...". И так почти 40 страниц. К середине уже голова пухла от этих перечислений. Математический анализ тоже показывает, что документ читать очень сложно и для его восприятия требуется наличие второго высшего образования или оконченной аспирантуры :-)

Уровень читабельности 382-П 

У меня нет ни второго высшего, а аспирантуру я так и не закончил. Думаю поэтому мне приходилось читать нормативные акты Банка России по несколько раз. Такой же и один из последних образчиков ЦБшного творчества, 716-П. Он также далек от простоты восприятия (и он даже хуже 382-П по уровню читабельности).

Уровень читабельности 716-П

У ФСТЭК ситуация тоже далека от идеала. Вот так выглядит уровень читабельности приказа №17 с требованиями по защите государственных информационных систем.


Поэтому, когда регулятор утверждает, что его документы понятно написаны и это сами госы виноваты, что ничего не понимают, математика это отрицает. Помню, когда представители ФСБ рассказывали о готовящемся 378-м приказе по защите персональных данных, они упоминали, что этот нормативно-правовый акт прошел не менее 43-й редакций перед тем, как появилась финальная версия. Но такое количество проходов на читабельность повлияло плохо - в сегодняшней подборке это один из худших примеров читабельности текста.


Другие приказы ФСБ недалеко ушли от "лидера". Например, уровень читабельности приказа 196-го по требованиям к средствам ГосСОПКИ выглядит так:


А есть примеры абсолютно читабельного текста? Да, конечно. Например, если прогнать через проект "Простым языком" русскую сказку "Колобок", то уровень ее читабельности будет рассчитан даже на детей 6-8 лет. Понятно, что нормативка врядли будет изучаться учениками 1-3 классов, но как ориентир этот пример неплох. 


Кстати, сказки Владимира Безмалого по ИБ вполне себе в читабельной форме (правда, нормативку в таком виде не опубликуешь): 


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


Чуть более "формальный" обзор телемоста с Лютиковым В.С. оказался рассчитанным на студентов начальных курсов ВУЗов и мне кажется, что это именно тот уровень, к которому нужно стремиться в нормативных документах по ИБ (может быть достигая уровня 5-6 курсов ВУЗа). 


Судя по всему, это обычный для моих статей и заметок уровень. Вот, например, так выглядит уровень читабельности для моей статьи по SOCам для BIS Journal:


Читабельность моего раздела по кибербезопасности для учебника CDTO проект "Простым языком" оценил уже на грани. Думаю, что больше усложнять уже не надо, так как рядовым читателем многое будет восприниматься непросто, что приведет к неясности. 


Но чиновники, увы, видимо, не прогоняют свои творения через такого рода проекты (а у "Простым языком" и API свой есть, который можно было бы подцепить к системам подготовки нормативных актов). Вот так, например, выглядит уровень читабельности ФЗ-152:


или ПП-127 о категорировании объектов КИИ (это безусловный лидер сегодняшнего обзора, который не разобрать без ста грамм второго образования):


Но не надо думать, что регуляторы не способны писать читабельные документы. Например, проект ГОСТа по безопасной разработке ПО вполне себе читаем его целевой аудиторией:


Как и утвержденная методика ФСТЭК по оценке угроз (вопрос ее реализуемости оставим в стороне):

Вот такая картина получается. Не то, чтобы в заметке есть какие-то сюрпризы, но если по ее прочтении, регуляторы начнут прогонять проекты своих текстов через нее, было бы неплохо. Все-таки читабельность текстов и в их интересах - меньше критики, меньше вопросов, меньше отвлечения от работы.

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