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. На сайте проекта упомянуты все используемые формулы, адаптированные к русскому языку.

16.3.21

Список идей для штабных киберучений

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

Фрагмент сценария с киберучений "Зомби атакуют"

Итак список идей для сценариев выглядит таким образом:

  • Утечка важной для бизнеса информации (например, планов поглощения и слияния или планов выпуска новой продукции)
  • Нарушение контрактных обязательств из-за действия шифровальщика
  • Инициация конкурентами проверки со стороны регулятора
  • Шантаж со стороны мошенников/хакеров
  • Санкционная тематика (отключение средства защиты или его обновления)
  • Внезапная публикация в СМИ информации об инциденте (да, если вы за 4 часа не среагировали, то вы проиграли эту информационную битву)
  • Массовое заражение шифровальщиком, включая цифровую АТС и почтовый сервер
  • Злой айтишник
  • Фишинг от имени руководства компании
  • Сервер компании заражен ПО для майнинга
  • Инцидент на новогодние праздники

Реализация этих идей позволяет реализовать многоходовые сценарии, раскрывающие их более детально, и позволяющие отработать разные стороны реагирования на инциденты - от сбора доказательств до анализа масштаба бедствия, от взаимодействия с ИТ до подготовки сообщения для прессы, от проверки регламентов до ответа на вопрос: "Надо ли платить выкуп вымогателям?".

Возьмем, к примеру, сценарий "Злой айтишник". Он может выглядеть по-крупному из следующих шагов:

  1. Знающий о своем увольнении системный администратор устанавливает закладки на все критичные сервера (или разработчик это делает в отношении ключевых компонентов разрабатываемого ПО).
  2. После увольнения бывший админ (разработчик) входит в ИТ-системы бывшего работодателя и крадет информацию, нарушая целостность всех баз данных и их резервных копий.
  3. Сисадмин находит на черном рынке покупателя на украденную информацию и продает ее.
  4. Покупатель требует выкуп; иначе угрожает опубликовать данные в СМИ. СМИ все равно узнают о данном шантаже и публикуют новость об этом.
Обратите внимание, задание правильных вопросов на каждом из 4-х этапов позволит прокачать как технические моменты (сбор артефактов и доказательств противоправной деятельности нарушителя или необходимость отключения учетных записей увольняемых сотрудников и контроль их наследия), так и организационные (взаимодействие со СМИ или анализ Darknet) и юридические (возбуждение уголовного дела и предоставление юридически значимых доказательств).

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

Фрагмент сценария с киберучения на "Магнитке" в феврале 2021

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

Но как вы понимаете, это только часть задач при организации киберучений. О других я еще напишу в блоге, а кроме того, о них мы поговорим в рамках выделенной сессии на Antifraud Spring Russia'2021 28 апреля, которая будет посвящена киберучениям. Ну а чтобы прокачаться перед ней, можно посмотреть уже упомянутый ранее эфир AM Live.

15.3.21

Список значимых отечественных мероприятий по ИБ в 2021-м году

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

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

Вот такой список. Очевидно, что он будет пополняться, так как в нем отсутствуют финальные мероприятия года - SOC Forum и Antifraud Russia, но их даты, скорее всего, станут известны позднее, по мере определения эпидемиологической ситуации. Кроме того, мне известны планы по запуску еще нескольких конференционных проектов, которые могут стать знаковыми и повторяющимися для России, но говорить о них пока рано. Однако, как только сведения о них станут доступны, я сразу внесу их в список.

12.3.21

Краткий обзор новой методики оценки угроз ФСТЭК

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

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

  1. Методика чего? Оценки? Определения? Моделирования? Постоянно перескакивают с термина на термин, что вводит в заблуждение. На суть не влияет, но уже напрягает.
  2. Методика обязательна для всех поднадзорных ФСТЭК организаций, так как распространяется на все объекты защиты - ИСПДн, ГИС, ЗОКИИ, АСУ ТП, ИС оборонки. Разве что станки с ЧПУ (не из оборонки) не затрагивают, хотя у ФСТЭК есть требования по их защите.
  3. В документе отсутствует переходный период и вопрос, как быть если модель угроз сейчас на согласовании в ФСТЭК, никто ответить не может. Даже сам регулятор. Надо переписывать модель (и тратить бюджетные средства на это) или нет?
  4. Упоминаемый по тексту методики STIX - это язык описания угроз, а не их база/источник, как CAPEC и т.п.
  5. Без автоматизации вся это методика мертворождена - не взлетает из-за количества задач, которые нужно реализовывать. ФСТЭК обещала средство автоматизации, но пока его нет. Ждем... 
  6. Методика оторвана от БДУ. ФСТЭК обещала его поменять, но пока это тоже не сделано. Поэтому и нужен был переходный период. 
  7. ФСТЭК обязывает реализовывать не дискретный процесс моделирования (раз в три года перед аттестацией или вообще никогда после сдачи толстого фолианта), а непрерывный. Поэтому без автоматизации вообще никак. И это средство автоматизации должно будет подгружать новые данные об угрозах и т.п. с сайта регулятора. Поддержание модели угроз в актуальном состоянии в свою очередь ставит вопрос о непрерывной переаттестации, что требует разъяснений от регулятора и бюджетов от аттестуемых (кто ж бесплатно это будет делать).
  8. В документе не говорится, но обновлять надо не реже одного раза в год (так часто либо НПА ФСТЭК меняются). А уж новые уязвимости, влияющие на возможности реализации угроз, а также новые тактики, появляются еще чаще. Так что процесс это не одноразовый. 
  9. Видимо не успели, но в идеале было отлично видеть привязку к разработанным проектам/методичкам оценки показателей значимости при категорировании ОКИИ. По сути подход же не меняется.
  10. Общая проблема документов ФСТЭК - их авторы никогда не пропускают себя через них. Вот что мешало ФСТЭК проект новой методики натянуть на какую-либо систему и сделать частную модель угроз? Был бы отличный пример работы документа и многие вопросы снялись бы автоматически. Причем ФСТЭК же по ее словам это уже делала. Когда на конференции ФСТЭК в рамках ТБ-Форума Д.Н.Шевцов рассказывал о новых требованиях к средствам защиты дистанционной работы, он говорил, что были проанализированы все угрозы для такого режима работы. Почему бы не опубликовать эту модель угроз, соответствующую новой методике? Все же работы уже проведены. Все бы спасибо сказали.
  11. Нарушитель актуален, если его действия МОГУТ привести к негативным последствиям и рискам (видам ущерба). Не получается ли так, что спецслужбы иностранных государств должны включаться всеми в список актуальных? Да и вообще, по этой логике любой тип нарушителя является актуальным. А самое главное, зачем мне их оценивать, если сценарии реализации угроз с ними никак не связаны?
  12. К делению нарушителей на внутренние и внешние те же вопросы. Если спецслужба может привлекать внутреннего нарушителя, то смысл делить всех на внешние и внутренние? Разработчик ПО по методике - это внутренний нарушитель. Звучит не очень логично, но по сути верно. Но почему сотрудник АНБ, который реализует фишинг против работника жертвы, внешний нарушитель? А если он внедрил закладку на этапе разработки или поставки (вспомним SolarWinds)? Почему оператор связи - это внутренний нарушитель, а поставщик обеспечивающих услуг (например, DNS) - внешний? В конце концов, почему разработчик ПО - это нарушитель со средними возможностями, а спецслужба - с высокими? Разработчик ПО имеет больше возможностей и знаний по внедрению вредоноса в свою продукцию, чем спецслужба. А почему APT, которая использует украденный арсенал кибероружия ЦРУ, - это базовые повышенные возможности? А почему спецслужба, привлекающая АРТ к своей деятельности, - это максимальные возможности? А главное, опять, зачем это все, если мы никак это не используем далее?  
  13. Классификация возможностей нарушителя Н1-Н4 приводит к путанице с моделями нарушителей Н1-Н6 ФСБ. Зачем это было сделано?
  14. Классификация источников угроз противоречит ранее выпущенным ГОСТам ФСТЭК и в методике вообще нет отсылок ранее принятых ТК362 ГОСТов. Зачем их тогда принимали? Они же классифицируют и систематизируют многие вопросы, рассматриваемые в методике, - нарушителей, источники угроз, мотивы и т.п.
  15. Из методики странным образом исчез вопорос ПОЧЕМУ. КТО может хакнуть (то есть нарушитель) у нас определяется. КАК хакнут (методы) - тоже. КУДА хакнут (интерфейс) - присутствует. ЧТО хакнут (компоненты) -тоже есть. А ПОЧЕМУ хакнут (мотивация) исключили. То есть нам все равно, могут нас вообще захотеть атаковать или нет? И мы исходим только из теоретической возможности такого взлома? Ведь была же раньше попытка сослаться на ГОСТ 18045 с его потенциалом нападения. И при оценке безопасности ИТ-продуктов эта концепция используется. А вот сейчас про нее забыли :-(
  16. Также из риск-ориентированной методики убрали понятие вероятности реализации негативного события. То есть ущерб (негативные последствия) мы оцениваем, а их вероятность - нет, принимая ее равной единице? С какого перепугу мы уравниваем вероятность подцепить шифровальщика, атаку китайских хакеров и падение метеорита?
  17. Очень мне не хватило примеров. Это ж методичка - ее не надо утверждать в Минюсте. Почему бы не добавить понятности и разбавить документ множеством примеров? Стало бы в разы все понятнее.
  18. Хорошо, что есть деление на угрозы возможные и актуальные. Но дальше все плохо - наличие хотя бы одного сценария делает угрозу актуальной. Тогда разницы между возможными и актуальными нет, так как мне сложно представить угрозу, для которой не было в современной организации хотя бы одного сценария реализации. А значит мы опять все возможные угрозы делаем актуальными, не имея возможности их сократить :-(
  19. Почему на этапе создания оцениваемой системы должен быть определен хотя бы один сценарий (TTP)? А на этапе эксплуатации множество? И сколько это - множество?
  20. Определили сценарии (правда, непонятно как - этот раздел прошлого проекта удалили) и что? Обрыв методики. Как выбрать меры по нейтрализации угроз?
  21. Как влияет определяемый уровень возможностей нарушителя, его категория, виды, риски и т.п. на определение актуальных угроз? НИКАК! Все равно все скатывается к определению возможных сценариев угроз, которые непонятно как связать с нарушителями и их возможностямяи. Мы проделали кучу работы, результаты которой мы не используем и которые ни на что не влияют.
  22. Опять тот же вопрос про утечки. Это пример воздействия на ресурсы и компоненты или пример негативного последствия? Оно используется и там и там. Отказ в обслуживании - это тоже вид воздействия; хотя логичнее было бы его считать негативным последствием.
  23. Проблема с тактиками осталась. Зачем этот неполный список оставлять в приложении к методике? Его же таким и будут использовать и расширить его будет нереально. Разместите на сайте ФСТЭК, как ЦБ сделал со списком инцидентов. И обновляйте, когда хотите. А почему нет ссылок на нумерацию MITRE ATT&CK? Ведь эту матрицу брали за основу. Ну и сделали бы ссылки, чтобы было удобнее. Ну или перевели бы целиком (отрасль бы спасибо сказала). За год уж точно можно было бы НИР для ГНИИ ПТЗИ заказать и все сделать (кстати, выполнение НИР делает ГНИИ ПТЗИ субъектом КИИ или нет?).
  24. На сайт регулятора можно было и все остальные приложения с перечнями (ущерба, нарушителей и т.п.) вынести. А по тексту просто сослаться, что это пример, но последние версии лежат там-то. Ведь они не требуют согласования с Минюстом и можно их пополнять в любое удобное время. А если эти перечни еще сделать в машинно-читаемом формате, то можно было и в средство автоматизации их подгружать. Было бы полезно и удобно.
Вот таких две дюжины вопросов к утвержденной методике. И ведь большая их часть мной задавалась и формулировалась еще год назад (части 1, 2, 3, 4, 5 и 6). Посчитали несущественными или неправильными? Ну может быть - не мне судить и не мне за регулятора решать, как ему делать свою работу. Но вопросов ФСТЭК огребет получит теперь немало - и по почте, и на своих мероприятиях. Не умеет регулятор просчитывать последствия своих действий и моделировать их. А вроде должен, если других учит в своих методических документах. Ну да ладно. Жизнь нас рассудит, а правоприменительная практика покажет, кто был прав и являются ли описанные выше нюансы значимыми или нет. В любом случае рынок услуг по моделированию угроз только вырастет - то есть задачу улучшению экономического положения лицензиатов регулятор точно своим документом решит. А это уже немало.

26.2.21

Дистанционное рабочее место - новое направление регулирования ФСТЭК

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


  1. ФСТЭК признает и я склонен с ней согласиться, что существующие нормы 17-го приказа (а также иных приказов) ФСТЭК вполне себе допускают удаленную работу и позволяют защитить ее в рамках действующей нормативной базы. Но зачем-то, вдруг, появляется требование о том, что удаленный доступ должен быть организован только со специальных технических решений, к которым надо установить требования.
  2. ФСТЭК, трезво оценивая нехватку бюджета у госорганов и понимая, что каждому чиновнику выдать по служебному компьютеру для работы из дома невозможно, предлагает использовать концепцию LiveUSB, то есть специальной защищенной флешки, с которой можно загружаться и подключаться к ГИС или работать со слежубными документами вне рамок аттестованного помещения и контролируемой зоны.
  3. При этом ФСТЭК считает, что это не может быть любая флешка, на которую установлены сертифицированные средства защиты, а только специальная флешка, сделанная под заказ в соответствие с треваниями по ИБ и стоящая как космический корабль.
  4. На этой LiveUSB, которая должна быть сертифицирована, должны быть реализованы/установлены соответствующие средства и механизмы защиты - доверенная загрузка, ОС, двухфакторная аутентификация, СКЗИ, удаленное управление. 
  5. ФСТЭК разрабатывает сейчас (на финишной прямой) руководящий документ к таким средствам, который будет ориентирован только на разработчиков и испытательные лаборатории. Вот тут у меня, конечно, в очередной раз всплывает вопрос. Понятно, что сделать документ, ориентированный на ограниченное количество участников, проще, чем документ для широкого круга лиц. Но если целью всего этого является именно усиление защиты информации и повышение ее уровня (а вроде именно это декларируется и является целью регулятора), то разрабатывать надо не только требования к средствам, но и требования к процессу безопасной удаленной работы. То есть речь может идти о методическе по безопасной удаленке, которой могли бы руководствоваться все госорганы, уровень квалификации которых не очень высок. И никакое, даже обвешанное сертификатами, средство не способно решить проблему безопасной удаленной работы, если не работать с конечными потребителями, чего ФСТЭК упорно не хочет делать, перекладывая эту головную боль на разработчиков средств защиты.
  6. ФСТЭК планирует внести изменения в 17-й приказ (ЗИС.31) и методичку "меры защиты" в связи с появлением этого РД, но когда это будет сделано, пока непонятно. В выступлении Шевцова Д.Н. прозвучало, что "мы по полгода все регистрируем в Минюсте", а значит ждать нам этих изменений не раньше конца года :-( так как цепочка тут простая. Сначала надо принять РД, потом поправки в 17-й приказ, а потом уже и в методичку внести изменения.
  7. Правда, в методичку внесут изменения явно не скоро. Днем ранее, на секции по безопасности АСУ ТП, Кубарев А.В. сказал, что ФСТЭК планирует (отмечу - давно планирует) разработать универсальную методичку по мерам защиты, которая бы объединяла разъяснение защитных мер не только к 17-му приказу ФСТЭК для ГИС, но и к 21-му (ИСПДн), 31-му (АСУ ТП), 31-му (оборонка), 239-му (ЗОКИИ). И будет это сделано, как было сказано, либо в этом, либо, что реальнее, в следующем году, Очевидно, что работа эта невозможна без синхронизации нумерации и наименования всех защитных мер в приказах ФСТЭК, чего пока не наблюдается. А это за собой тянет внесение изменений во все приказы регулятора, что, как мы помним из выступления Лютикова В.С., в 2021-м году делать не планируется.
  8. В отличии от всех ранее выпущенных РД ФСТЭК, никакого деления на классы защиты/защищенности у средств безопасной удаленной работы не будет. Все требования будут едины и применяться, что к ГИС 3-го класса, что к ГИС 1-го, что к ЗОКИИ 3-го уровня, что 1-го. С одной стороны унификация, а с другой - явное завышение защитных требований и отсутствие дифференциации, которое приведет к росту затрат и невозможности реализации требований ФСТЭК у многих субъектов регулирования. Ровно такая же ситуация была с требованиями по лицензированию мониторинга ИБ, когда ФСТЭК сразу установила требования по аттестации SOC по ГИС1 (и как ряд лицензиатов оказывает услуги мониторинга ИБ с облачного сервиса Microsoft Azure Sentinel мне до сих пор непонятно), мотивируя это тем, что к лицензиату может обратиться организация с ГИС1. Почему нельзя было прописать просто требование, что при мониторинге ГИС у лицензиата должен быть аттестат соответствия SOC уровня ни ниже того, который выдан на систему, отдаваемую на аутсорсинговый мониторинг? Так бы ФСТЭК дала развиваться рынку мониторинга ИБ, не снижая при этом уровня защиты госов. Сейчас ФСТЭК наступает на те же грабли, приравнивая какой-либо региональный банк (как СуКИИ) или районную больницу и корпорации типа Газпрома, РЖД или министерства типа Минцифры или Минфина. Всех под одну гребенку и всем выполнять максимально возможные требования - средства защиты не ниже 4 класса защиты (максимально возможный для "негостайны"). И если выполнение требований этого документа будет обязательным только для госов, то и ладно. Но если такие тревания будут обязательны, например, для субъектов КИИ, то реализовать их будет зачастую невозможно, так как не все приложения можно запустить с LiveUSB, особенно если речь идет об АСУ ТП.
  9. Вообще вопрос установки прикладного ПО на LiveUSB, как мне кажется, регулятором проработан не до конца. С web-приложениями вроде все понятно, но как работать с обычными standalone-приложениями? Ставить их на флешку? А места хватит? А сертифицированная ОС это позволит? А скорости работы с USB 2.0 (пока с этой версией) хватит? Одни вопросы.
  10. Кстати, и еще один вопрос. А как быть с требованиями ФСБ к СКЗИ? Насколько допустима такая схема не совсем понятно. Из проекта приказа ФСБ "Об утверждении требований о защите информации, содержащейся в ГИС, с использованием СКЗИ" у меня сложилось впечатление, что там вообще не учтена дистанционная работа. Еще LiveUSB будет хранилищем для ключей и сертификатов электронной подписи - поэтому надо смотреть, насколько эти флешки выполняют еще и требования ФСБ к средствам ЭП. Ну и скорость работы СКЗИ на слабой аппаратной начинке флешки тоже может стать очередным раздражителем.
  11. Требования будут ДСП. Если кто-то захочет получить к ним доступ после их регистрации, то необходимо сделать официальный запрос в ФСТЭК, но для этого надо иметь лицензию, о чем я уже писал, рассказывая про телемост с Лютиковым В.С. Правда, тут опять возникает вопрос. Если требования только для разработчиков, то как потребителю понять, какие он требования должен выставить к данным средствам? И как он может понять, что было сделано разработчиком в соответствие с закрытыми документами регулятора? 
  12. Интересно, что действующие нормативные документы ФСТЭК запрещают осуществлять удаленный доступ администраторов к ГИС, требуя, чтобы администрирование было только локальным. Останется ли данное требование или его поменяют? Пока непонятно. Вроде как Шевцов Д.Н. упомянул, что изменения внесут, но по срокам см.выше.
  13. Также не до конца понятна ситуация с уже аттестованными системами. Как быть с ними? Требуется ли переаттестация или достаточно проведения дополнительных мероприятий по проверке безопасности дистанционного доступа? Вроде как ФСТЭК говорит о последнем, но судя по вопросам на конференции, и пользователям и самим аттестационным лабораториям не хватает официальных и публичных разъяснений регулятора. 
  14. Интересно, что в рамках выступлений и вопросов неоднократно упоминалась информация "ДСП", то есть служебная тайна. Но на прямой вопрос, когда же хоть кто-то сможет назвать сроки принятия закона о ней, так никто и не ответил. На вопрос Шевцову Д.Н. из зала, как защищать "информацию ДСП" и в соответствие с чем, от представителя ФСТЭК последовал очевидный ответ - "в соответствие с 17-м приказом". Хотя с юридической точки зрения это нонсенс. 17-й приказ никакого отношения к информации ограниченного распространения не имеет - он регулирует защиту ГИС и только. Все всё понимают, но делают вид, что все хорошо :-(
  15. С практической точки зрения у данного подхода есть и еще один нюанс (помимо прикладного ПО) - чтобы загрузиться с LiveUSB необходимо в BIOS указать, что загрузка осуществляется с флешки, а не с жесткого диска домашнего компьютера. Как это объяснить низкоквалифицированным пользователям, не совсем понятно. Особенно при том многообразии домашних компьютеров, которые имеют BIOS/UEFI разных версий разных производителей. А ведь некоторые ПК вообще не имеют такой возможности. С техникой Apple вообще засада. И хотя у многих рядовых служащих нет макбуков, но у чиновников высокого ранга это не редкость. И как быть с ними непонятно. Как и с теми, кто вместо ПК использует планшеты, в которые нельзя воткнуть LiveUSB. Вопрос печати на локальных принтерах тоже остается открытым...
  16. Как мы помним, Минцифра с Минпромторгом, пытаются импортозаместить все госорганы, а к средствам защиты так и вовсе предъявляют требования об использовании отечественной микроэлектроники к определенному сроку. Сейчас, имеющиеся на рынке решения LiveUSB такие требования не выполняют, хотя и заявляют о движении в эту сторону. Это означает, что после переходя на отечественные микроконтроллеры и модули флеш-памяти придется заново проводить сертификацию готового изделия, а заказчикам тратиться на повторную закупку.     

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


Из доклада представителя Минцифры я с удивлением узнал о какой-то новой классификации информационных систем. Были упомянуты медицинские информационные системы и информационных банковские системы 1-го класса защищенности. Что это такое? Тоже самое было и в докладе генерального директора Аладдина Р.Д. Груздева С.Л. Кто у его копипастил (а там не только классификация совпадала, но и некоторые слайды)?

Вот такой краткий пересказ того, что говорили регуляторы на тему удаленной работы в безопасном режиме. По мне, так половины нужного сказано не было :-( Я выше уже написал, что защищенная дистанционная работа - это не только сертифицированная LiveUSB. В своем выступлении на GIS Day я приводил краткий чеклист того, что надо делать и в нем я писал не только про защиту оконечных устройств, с которых осуществляется удаленный доступ (а именно про это и говорит ФСТЭК), но и про защиту периметра предприятия или облачной инфраструктуры, а также про мониторинг активности на сетевом уровне, различные требования к защите соединения, изменение культуры работы, управление инцидентами и т.п. Вопросов много и место им в отдельной методичке по безопасной удаленной работе, которая должна учитывать как вопросы ИТ и ИБ при внедрении удаленки (например, вот так это выглядело у нас - в целом, для работы с облаком Azure и с облаком AWS), так и вопросы ее использования. 

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

ЗЫ. Презентацию Шевцова Д.Н. можно посмотреть здесь, а Гурзова К.А. - здесь.

25.2.21

Ответы ФСТЭК на вопросы отрасли. Часть 2-я

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

  1. Статистика категорирования достаточно плачевна - от 1,5% до 50-60% по разным отраслям. И это при условии, что до 1-го сентября 2020 года категорирование должно было быть завершено, в том числе и для предприятий промышленности.
  2. Если изменилась информация о лице, эксплуатирующем ОКИИ, то об этом надо оповестить ФСТЭК в 30-тидневный срок.
  3. Если объект КИИ поменял собственника (продан, сменилась форма собственности, передан на баланс другому предприятию и т.п.), то об этом также надо уведомлять ФСТЭК. Причем уведомлять должны две организации - прежний собственник и новый.
  4. Аналогичная ситуация и в случае выведения из эксплуатации значимых и незначимых объектов - уведомлять ФСТЭК надо как и при любом изменении объекта КИИ.
  5. Если организация принимает решение о переводе незначимого ОКИИ в значимые, то необходимо направить информацию об этом в ФСТЭК, в которой должно быть соответствующее обоснование.
  6. Если у объекта КИИ изменился состав технических средств или применяемых защитных мер, то уведомить об этом ФСТЭК надо в разумные сроки, под которым регулятор понимает 30 дней.
  7. На вопрос о том, надо ли уведомлять ФСТЭК при изменении модели угроз, которая существенно не влияет на категорию значимости ОКИИ, регулятор прямо не ответил, но судя по характеру ответов на схожие вопросы про несущественные изменения в результатах категорирования, уведомлять ФСТЭК все-таки надо.
  8. О любых произошедших изменениях ФСТЭК сама уведомляет НКЦКИ - самостоятельно субъекту ничего писать в ФСБ не нужно.
  9. ФСТЭК обязательно хочет видеть от субъекта КИИ подробные расчеты показателей категорий значимости (для этого и опубликован проект методики по расчету экономического показателя и планируется методика по социальному показателю). Если тот или иной показатель не применим к объекту КИИ, то необходимо обосновать, почему? ФСТЭК прямо заявляет, что безопасники не в состоянии самостоятельно провести такую оценку и требуется участие других подразделений, обладающих знаниями по ценности объектов.
  10. После принятия ПП-452, внесшего изменения в ПП-127, стали возникать инсинууации по поводу сроков категорирования для создаваемых объектов. ФСТЭК считает, что для таких ОКИИ категорию значимости надо закладывать еще в ТЗ/ЧТЗ. То есть к моменту создания объекта его категория уже известна и срок в 12 месяцев из ПП-127 к таким объектам уже не применяется.
  11. ГНИИ ПТЗИ ФСТЭК, как и все подведомственные организации ФСТЭК, выполняют требования ФЗ-187 и подзаконных актов. На конференции "Актуальные вопросы защиты информации" Шевцов Д.Н., отвечая на вопросы из зала, отметил, что ФСТЭК постепенно переходит на отечественное ПО и оборудование, следуя курсу на импортозамещение. Хотя по оговорке было понятно, что денег особо не выделяют.  
  12. Субъекты промышленности задавали вопрос о том, какие показатели значимости к ним применимы, на что последовал ответ, что это зависит от сферы деятельности предприятия. Но, в частности, было отмечено, что социальный показатель применим. Также применим 7-й показатель, если организация участвует в исполнении какого-либо международного договора. 8-й и 9-й экономические показатели применимы также; 9-й так вообще применим к любому объекту КИИ. 11-й показатель применим для экологически опасных производств, а 13-й - для всех организаций ОПК.
  13. Время, в течение которого субъект КИИ должен ждать ответа от ФСТЭК по поводу результатов категорирования, составляет не 30 дней, а 30 дней на рассмотрение + 10 дней на подготовку ответа + неделя-другая на доставку почтой. Фактом внесения данных об ОКИИ в реестром является присвоению ему реестрового номера, о чем вас ФСТЭК должна уведомить. Но если вы считаете, что у вас ЗОКИИ, то не надо дожидаться получения реестрового номера, - можно сразу начинать обеспечение безопасности.
  14. При оценке показателя экономической значимости, при оценке снижения уровня дохода от выполнения деятельности предприятия в результате воздействия на объект КИИ при оценке сценария расчета потерь необходимо рассматривать не среднегодовые потери, а потери в случае успешной реализации конкретного негативного воздействия.
  15. При оценке потерь, наступающих в случае успешной реализации негативного воздействия на объект КИИ, потери часто зависят от возможностей предприятия по локализации и устранению последствий инцидента. ФСТЭК считает, что последствия от воздействия должны учитываться на временном промежутке до момента восстановления плановых показателей (до инцидента). 

Пока все. Часть ответов была раскрыта в самом выступлении Торбенко Е.Б., которое скоро выложат на сайте организаторов. Также ФСТЭК обещала на других своих мероприятия ответить на оставшиеся вопросы. Из интересного также хочу отметить интересную цифру, озвученную Кубаревым А.К. на конференции по защите АСУ ТП в рамках ТБ-Форума. Его спросили, хватит ли у ФСТЭК ресурсов на проверки всех объектов КИИ, число которых по разным выступлениям ФСТЭК разнится от 25 тысяч до полумиллиона? Ответ был нерадостен - ФСТЭК, имея в центральном аппарате всего 200, а в регионах 1000 человек, не сможет ежегодно проверять даже 1% от общего числа объектов КИИ :-( 


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

В заключение хочу отметить, что есть ряд вопросов, на которые регулятор врядли будет отвечать на своих мероприятиях, но ответы на которые хотелось бы все-таки увидеть в том или ином виде:
  1. Когда на сайте ФСТЭК появится вменяемый реестр сертиицированных средств защиты с возможностью фильтрации по классам и типам средств? Да и сам сайт пора бы уже обновить - он как из 90-х годов.
  2. Почему до сих пор не синхронизированы нумерация и названия мер защиты в приказах ФСТЭК?
  3. Почему до сих пор не отменен РД на АС 1992 года, если у ФСТЭК уже совершенно иная классификация ИС? Почему проверяющие ссылаются на ПП-79, в котором есть слова про «автоматизированные системы» и из-за этого вынуждают выполнять требования документа 92-го года.
  4. Как относится ФСТЭК к ситуации, когда средства защиты не покупаются предприятием, а берутся в лизинг или аренду у аутсорсинговой компании?
  5. Выпустит ли ФСТЭК матрицу соответствия "старых" специальностей и новых, утвержденных Минобразованием? Вообще вопрос образования вызвал бурную дискуссию на конференции по защите АСУ ТП в рамках ТБ-Форума. Ведь требования по квалификации специалистов и руководителей по ИБ есть, а как их трактовать до конца никто не знает. Вот у меня специальность по диплому "Прикладная математика" (квалификация "инженер-математик") и хотя у меня было немало предметов, связанных с защитой информации, формально я не могу считаться специалистом по защите информации и мне пришлось бы проходить соответствующие курсы переподготовки. С учетом того, что за последние полтора-два десятка лет у нас не раз менялись ФГОСы по ИБ, названия и номера специальностей, было бы неплохо иметь такую матрицу соответствия (сделать-то ее несложно). Говорят, у ФСБ такая есть.   
ЗЫ. Из интересного: по словам Шевцова Д.Н. именно он в ФСТЭК курирует вопросы импортозамещения. Странно, почему не ИТ-служба? Вообще всегда было интересно узнать, как сам регулятор реализует у себя вопросы информатизации и ИБ и кто за это отвечает у регулятора? Если за импортозамещение отвечает 2-е Управление, то это странновато.

24.2.21

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-й приказ ФСТЭК
    • методика анализа и поиска уязвимостей и НДВ в аппаратных средствах
    • новая методика анализа и поиска уязвимостей в ПО
    • типовая модель угроз для аппаратных средств
    • методичка по видам и методам испытаний при проведении аттестации
    • метожичка по управлению обновлениями (патч-менеджменту).

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


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

4.2.21

Что общего между числом калорий и числом инцидентов? И снова о метриках ИБ (анонс нового Telegram-канала)

Каждый год многие, я так думаю, ставят перед собой какие-нибудь амбициозные цели, например, похудеть. Ой, что это я, мы же про безопасность говорим. Значит ставятся цели по ИБ. Допустим снизить число инцидентов в день с 23 до 18 или на 17%. Вроде бы красивая и нужная цель, но чтобы достичь ее, необходимо произвести ряд шагов. И раз уж я упомянул похудение, то попробуем сравнить эти два процесса между собой.

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

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

Думаю именно поэтому я не так часто вижу хорошо реализованные проекты по измерению и визуализации ИБ (да и плохо тоже). А я за прошлый год поучаствовал в десятке проектов по проектированию или аудиту SOCов (Cisco активно занимается такими проектами). Не любят у нас показывать результаты своей работы, которые в ИБ не всегда такие уж и положительные.

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

С инцидентами все тоже самое. Само по себе снижение числа инцидентов не говорит ни о чем. Причиной этого может быть:

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

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

  1. Измерять все. Потом
  2. Измерять правильные вещи. Потом
  3. Измерять правильные вещи правильным образом

Но начинать с измерения всего (ну или многого).

И вот тут я подступаю к тому, для чего писалась эта длинная заметка. Решил я тут поддаться модному поверью, называемому гитхабизации ИБ (на русском), и запустить новый Telegram-канал по метрикам ИБ (Cyber Security Metrics). Буду ежедневно делиться одной метрикой ИБ с ее кратким описанием, формулей, источниками данных, ограничениями и т.п. На самом деле это, конечно, не гитхабизация, но как это назвать, я не знаю. Сначала я думал заделать сразу каталог метрик и выложить его на Github, но времени на то, чтобы сделать это сразу и все, нет. А вот по частям мне показалось вполне подъемной задачей. В день по метрике - к концу года получится 250 разных метрик из разных доменов ИБ - реагирование на инциденты, управление уязвимостями, Red Team, Privacy, управление финансами, мониторинг ИБ, compliance и т.п. В отличие от своего текущего канала "Пост Лукацкого", у нового я включил возможность комментариев и обсуждения, чтобы можно обсуждать каждую метрику, делиться опытом и т.п.

Так что добро пожаловать в новый Telegram-канал, который будет этаким регулярно наполняемым каталогом метрик по ИБ.