Как я моделировал угрозы по проекту новой методики ФСТЭК. Часть 6 (финал)

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

Но п.7.2 сразу вводит меня в ступор, так как согласно нему уровень опасности угрозы определяется уровнем сложности ее реализации, что на мой взгляд совсем не так. Опасность - это то, что касается потребителя. Сложность - это то, что касается нарушителя. Лично мне пофигу, насколько тяжело реализовать ту или иную атаку. Опасной для меня атака будет считаться опасной, если ущерб от ее реализации будет значимым. Возможно, сложность атаки определяется вероятностью ее реализации, которая в свою очередь, если следовать алгоритму определения потенциала нападения из ГОСТ 18045, зависит от мотивации нарушителя, его компетентности и ресурсов. Но это мы уже определили раньше, когда говорили о возможностях нарушителя. Зачем нам еще городить огород со сложностью реализации угрозы, и так усложняя непростую методику? Кстати, в одной из прежних редакций проекта методики ГОСТ 18045 использовался, но от него потом отказались. Хотя на мой взгляд предложенный там алгоритм был проще того, что используется сейчас.

Дальше, в п.7.3, ступор усиливается. Я думал, что оценка опасностей делается для приоритезации защитных мер и ни для чего больше, но авторы методики разделяют цели оценки в зависимости от ситуации. Это на этапе эксплуатации опасность определяет приоритет мер защиты, а на этапе проектирования - определяет наиболее уязвимые компоненты ИС. Ох уж эти уязвимости. Такое впечатление, что документ писали люди, которые зарабатывают на поиске и анализе уязвимостей - все притягивают к нему.

Уровень опасности зависит от от типа доступа (наконец-то становится понятно, зачем мы мучались с определением локального, физического и удаленного доступа), сложности реализации угрозы и уровня значимости атакуемых информационных ресурсов. А ущерб? В п.7.2 же говорится, что негативные последствия тоже должны учитываться...

Дальше, в пп.7.5-7.6 у нас повторяется то, что было в разделах 3-5, - три типа доступа и 4 уровня сложности. Как и предполагалось уровень сложности реализации угрозы - это тоже самое, что и уровень возможностей нарушителя; один в один. Зачем тогда вводить еще одну сущность? П.7.7 вводит еще одну сущность - уровень значимости информационных ресурсов или компонентов, который... никак не связан с определенным в 3-м разделе ущербе (виде негативных последствий). Но зато вводится сложная конструкция с подсчетом числа пострадавших пользователей или критических процессов со странной градацией - один, больше одного, все, а также с введением непонятно как считаемого понятия "недостаточная эффективность критического процесса".
Апофеозом моделирования угроз является п.7.8 и таблица 8, которые показывают, что... сценарии реализации угроз нам нафиг не сдались, так как они никак не учитываются при оценке опасности каждой угрозы. Если бы мы хоть как-то могли оценивать сложность их реализации, то, возможно, и да. Хотя это была бы нетривиальная задача и 99% компаний и такой же процент специалистов по ИБ ее бы не смогли сделать (я бы вот не смог, признаю честно). Но у нас сложность реализации угрозы напрямую увязана с возможностями нарушителя и все. Поэтому весь 6-й раздел можно спокойно пропустить - в выполнении задачи он не нужен. Хотя провести работу по составлению максимально возможного перечня сценариев атак все равно придется. Хотя бы для галочки.

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

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

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

ЗЫ. Все, что было написано в серии заметок отражает мое сугубо субъективное мнение, с которым можно соглашаться или не соглашаться :-) 

Подробнее…

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

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

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

Явно это не говорится, но идея использования терминов "тактики" и "техники" взята из американской MITRE ATT&CK, которая содержит уже за 200 техник и больше десятка тактик. Почему нет упоминания американской матрицы понятно, но это еще сыграет злую шутку с нами. Местами в таблице 4 используются совершенно непонятные без разъяснения термины, которые являются достаточно грубой калькой с англоязычной матрицы. Например, техника 5.4 "Запасные и многоступенчатые каналы" в оригинале определены как две техники - T1104 "Multu-Stage Channel" и T1008 "Fallback Channels". И если, вдруг, какой-то госорган спросит регулятора, что означает техника 5.4 придется как-то выкручиваться. А самое неприятное, что и сопоставление TTP ФСТЭК и MITRE очень сложно реализовать, так как у нас постеснялись признать применение общепринятой методики и решили "пойти своим путем". Поэтому у нас свой набор техник, свой набор тактик, своя нумерация и невозможность сопоставить их один к одному. И хотя у методике написано, что помимо таблицы 4 можно использовать и иные базы, в реальности все будет известно как. Проверяющие, незнакомые с английским языком и ATT&CK, а также боящиеся самодеятельности, будут ориентироваться на то, что есть в таблице 4, тем самым доводя изначально хорошую идею до абсурда. Если уж регулятор не хочет признаваться в копировании чужого опыта (и понятно почему), может тогда поступить как Банк России, который в своих нормативных актах написал, что список инцидентов размещается на сайте ЦБ. Его и править тогда проще. Так и ФСТЭК могла бы поступить.

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

В проекте методики ФСТЭК, к сожалению, первая часть совершенно упущена из ввиду. Разобравшись с типами антропогенных источников, мы сразу стали разбираться в сотнях миллиардов возможных сценариев реализации угроз (хотя правильно было говорить о сценариях атак, но это вряд ли возможно, так как термин "атака" уже закреплен за другим регулятором в области ИБ). При этом даже в части с TTP у текущего, "фстэковского" варианта, есть свои нюансы. Например, если посмотреть на онтологию взаимосвязей техник, тактик и процедур, то мы увидим, что они очень тесно завязаны с инструментарием, используемым тем или иным нарушителем (причем та же MITRE ATT&CK оперирует конкретными группировками, а не абстрактными антропогенными факторами), используемыми им командами и характеризующими его индикаторами (IOC). У ФСТЭК эти три компонента отсутствуют и у меня есть стойкое подозрение, что их и не появится, так как конкретными хакерскими группировками и их атрибуцией у нас в России если и занимаются, то только частные компании типа Лаборатории Касперского, Groip IB или Positive Technologies, а индикаторы у нас рассылают ГосСОПКА (ФСБ) и ФинЦЕРТ (Банк России). А будут ли все эти участники следовать общей стратегии я не знаю.

Еще один момент, связанный с развитием всего этого подхода. Матрица MITRE ATT&CK поддерживается и активно развивается международным сообществом ИБ и любой желающий может поучаствовать в расширении списка техник и атак. Кто будет поддерживать модель угроз и БДУ ФСТЭК? Один Воронежский ГНИИ ПТЗИ? Или им еще Positive Technologies будет помогать, чьи картинки используются в проекте методики ФСТЭК? Ну одна она будет не в состоянии это тянуть. В п.6.3 написано, что при выявлении новых TTP информацию о них надо направлять во ФСТЭК, но кто это будет делать и зачем? В итоге одни вопросы...

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

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

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

П.6.6 вновь напоминает, что моделировать угрозы надо на 5-ти уровнях - аппаратном, системном, прикладном, сетевом и сервисном. Правда, в 3-м разделе последний уровень касался только пользователей, а сейчас в него добавили еще Web-интерфейсы, информацию и иные компоненты (синхронизировать бы).

П.6.8 возникает в методике как гаишник из кустов на безлюдной трассе. Внезапно. Согласно нему угрозой считается совокупность ранее определенных:

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

То есть оформление этого множества превратит специалистов по моделированию угроз в апологетов супрематизма. На рисунке 11 показан пример того, как может быть определен сценарий реализации угрозы. И такие картинки надо рисовать на каждый сценарий или группу сценариев. "Позитиву" впору выпускать библиотеку готовых сценариев или библиотеку иконок и шаблонов для их оформления. Большинство компаний будет не в состоянии оформить даже одну угрозу, не говоря уже обо всех. При этом п.6.8 зачем-то посылает нас на три буквы, то есть к БДУ, который должен стать основой для формирования исходного перечня угроз. Но формат БДУ сейчас вообще не соответствует тому, что написано в методике. И еще не меньше года не будет соответствовать, так как описать даже текущих 77 техник и соотнести их с текущими 200 угрозами - задача нетривиальная. Еще же надо не забыть решить вопрос с теми, кто уже провел моделирование по БДУ. Надо ли им будет все переделывать или нет? И, кстати, вопрос. Будет ли введена эта методика сразу или только после обновления БДУ?

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

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

На этом заканчивается 6-й раздел и мы почти подошли к финалу рассмотрения методики моделирования. В следующей заметке мы перейдем к 7-му, последнему разделу проекта методики, который... да-да, это еще не конец, позволит ранжировать все триллионы и миллиарды угроз по трем уровням опасности.

Подробнее…

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

Раздел 5 погружает нас в мир нарушителей, которые могут атаковать нас или реализовывать непреднамеренные угрозы (то есть теща). Источниками угроз у нас могут быть как антропогенные, так и техногенные. Как мы помним из введения в методику, она не предназначена для моделирования последних. Тем непонятнее требование из п.5.1 моделировать и их, а также п.5.2, который описывает причины возникновения техногенных угроз и их источники. Так надо их моделировать или нет? И если да, то как? Куда хотя бы смотреть? Может в ГОСТ Р 51901 по анализу рисков технологических систем?

Возьмем, к примеру, проведение дистанционной телеконференции с помощью Zoom. Вполне распространенная практика, от которой, правда, многие отказываются из-за проблем с безопасностью на этой платформе. Согласно первым разделам методики, Zoom - это облачный поставщик услуг, от которого мы должны потребовать его модель угроз. Но вот в п.5.2 говорится, что низкое качество ПО, в том числе и уязвимости в Zoom, отсутствие безопасников в Zoom, недоступность Zoom из-за DDoS-атаки или бана со стороны Роскомнадзора и т.п., - это все приводит к угрозам техногенных источников. И как их моделировать? Они же вполне реальные. Почти все, что касается внешних поставщиков, согласно п.5.2 будет отнесено к техногенным источникам, работать с которыми непонятно как, так как проект методики рассчитан только на антропогенные угрозы. Но ФСТЭК путает окончательно в п.5.3 и примере 4, рассматривая в качестве источника угрозы программную или аппаратную закладку и предлагая учитывать ее при моделировании, хотя сама же в 1-м разделе утвердила распространение методики только на антропогенные источники.

Но самое неприятное, что ФСТЭК вводит новую классификацию источников угроз при наличии уже существующих и утвержденных. Например, для операторов связи есть утвержденный ТК362 (то есть ФСТЭК) ГОСТ Р 52448-2005. Там источников угроз три - субъект (то, что ФСТЭК назвала антропогенным источником), материальный объект и физическое явление (последние два ФСТЭК объединила под техногенным источником). В ГОСТ Р 51901.1-2002 по управлению рисками технологических систем источников уже 4 - природные, технические, социальные и связанные с укладом жизни. А есть еще ГОСТ Р 51275-2006 или ГОСТ Р ИСО/МЭК ТО 13335-3-2007, который определяет три источника угроз - естественный, преднамеренный и случайный.
Но идем дальше. Источником антропогенных угроз является лицо (группа лиц), которое реализовало угрозу путем несанкционированного доступа или воздействия на информационные системы. Я попробовал представить себе ситуацию, когда я, находясь на удаленном доступе, выложил на разрешенный Box или Dropbox конфиденциальные файлы (это допустимо), но дальше по причине корявости рук нашего админа или админа Box/Dropbox файлы оказались доступны неограниченному кругу лиц. Кто тут является нарушителем? Я ничего несанкционированного не делал. Админы тоже никак несанкционированно не воздействовали на систему. Скорее их бездействие привело к тому, что угроза утечки информации реализовалась. Методика этот момент не учитывает. Дима Кузнецов, комментируя моя заметки в Фейсбуке, написал, что бездействие админа - это не угроза, а уязвимость! Возможно, ему, как участнику последнего состава рабочей группы по разработке проекта методики, это понятно. Но вот мне, участнику предпоследнего состава :-), это совсем неочевидно. Вообще текст методики с последних чисел декабря изменился кардинально - как новый документ читаешь.

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

Понятие внешнего нарушителя почему-то тесно завязано на наличие Интернет (прямо или косвенно). А если его нет? Вот представим себе такую ситуацию. Я работаю в изолированной среде, например, на атомной станции. И мне подкидывают флешку с вредоносным кодом (кто сказал Stuxnet?). А вредоносный код был залит на флешку на полигоне АНБ в штате Айдахо (кто сказал, что там есть только полигон МинЭнерго США и лаборатории INL?). И в Интернет этот вредоносный код никогда не попадал, как и в смежные с атакующей системой тоже. Каким нарушителем мне считать АНБ в этом случае? Под определение внешнего оно не подходит. Ну а внутренним тем более. Или более приземленный пример с системой удаленного доступа. Живет у нас в доме, на одном со мной этаже, сотрудник Хуавей. И допустим, написал он на своем домашнем ПК вредоносную программу, которую он, поигравшись с моим домашним Wi-Fi, засадил на мой домашний ПК. Это какой нарушитель - внутренний или внешний? Кстати, можно ли к беспроводным сетям применять термин "линия связи, расположенная за пределами контролируемой зоны"? Хотя, вон, Роскомнадзор и депутаты вполне себе применяют к Интернет термин "государственная граница"...

С внутренними нарушителями все, более или менее, понятно. Вот сотрудник Zoom, сидящий в Китае, для меня является нарушителем внутренним. И сотрудник Apple, который обеспечивает поддержку моего Macbook, тоже. А вот фирма DHL, которая перевозит мой сломанный ноутбук из моего дома в Apple, - это уже нарушитель внешний. По крайней мере, так написано в проекте методики.

П.5.5 является очень важным, так как говорит, что мы должны определить для себя актуальных нарушителей, для чего надо предположить, зачем им нас атаковать. Допустим, я предположу (имею право), что меня может атаковать компания Хуавей и попробовать через меня попасть во внутреннюю сеть Сиско и украсть наши ноу-хау. Это будет п/п.20 из таблицы 2, а значит уровень возможностей нарушителя будет базовый повышенный. Может ли меня атаковать АНБ? Да фиг там. Исключаю. А ФСБ? Да вот тоже. Исключаю. Могу ли я предположить, что компания Apple, операционной системой которой я пользуюсь, решила внедрить в macOS скрытые функции на этапе разработки? Могу. А могу ли я предположить, что АНБ на этапе поставки ко мне моего ноутбука для удаленного доступа внедрила в него скрытые функции? Тоже могу. Но я считаю для себя это неактуальным. Вычеркиваю.

Местами все-таки таблица 2 вызывает вопросы. Например, для киберпреступных группировок, крадущих деньги, уровень возможностей определен как базовый повышенный. Хотя мы все видим, что их возможности иногда мало чем уступают спецслужбам иностранных государств, а иногда и превосходя их (и это если не брать в расчет наличие в свободном доступе инструментария АНБ и ЦРУ, утекшего в результате известных инцидентов Vault7 и Shadow Brokers). Но если та же группировка работает в интересах спецслужб (а мы знаем, что есть группировки, которые работают сразу по нескольким фронтам), то ее уровень возможностей автоматически взлетает до максимального - высокого. А куда относить хакеров, нанятых спецслужбами?

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

Разобравшись с актуальными для себя типами нарушителей и тем, какие цели они преследуют, я по таблице 2 определяю потенциал нарушителя, а по таблице 3 его возможности. В итоге мы получаем 4 модели нарушителя - Н1-Н4. Как их соотнести с моделями нарушителя Н1-Н6 ФСБ даже и не спрашивайте. Пожалуй, единственное, что точно можно сказать, что Н4 по ФСТЭК - это тоже самое, что и Н6 по ФСБ.

Мы подошли к концу пятого раздела, по итогам которого у меня должны сформироваться списки:

• Источников угроз. Хотя я могу сразу сказать, что у меня будут оба источника - антропогенный и техногенный. Это можно было так и записать в методике и не мучаться с описанием на две страницы.
• Возможных целей нарушителей. Тут чистое творчество - методика никак мне не подсказывает, как это сделать. Я бы попробовал совместить список целей из таблицы 2 с предложенным в прошлой заметке списком видов ущерба.
• Категориями и видами нарушителей. Я могу заранее утверждать, что у меня возможны обе категории нарушителей (внешние и внутренние); даже в условиях корявости их определения. Вот с видами чуть сложнее - понадобится экспертная оценка. Но спецслужбы, террористов и экстремистов я бы исключал в 99% случаев; как и единожды встречающихся разработчиков и производителей ПО и железа (а вот почему-то объединенных с ними поставщиков ПО и железа вообще бы исключил или перенос бы к ремонтникам).
• Возможностей нарушителей, который автоматически вытекают из таблицы 2 и 3, и знание источников угроз и категорий нарушителей никак тут не нужно.

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

Подробнее…

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

А я продолжаю свое путешествие по проекту методики моделирования угроз и перехожу к 4-му разделу, который позволяет оценить мне потенциал нарушителя или, как написано в методике, условия реализации угроз безопасности информации. Почему я оцениваю потенциал нарушителя ДО определения самих нарушителей, для меня остается тайной. Возможно потому, что пройдя через 4-й раздел вы поймете, что вам уже все равно, кто вас атакует - мамкин хакер или хакер в погонах. А может потому, что потенциал нарушителя, то есть оценка его возможностей, описывается в 5-м разделе? Зачем надо было разделять условия реализации угроз и возможности нарушителя?

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

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

Пункт 4.7 предлагает мне подумать над тем, откуда нарушитель может реализовать свои угрозы - удаленно, локально или... физически. Для меня деление на локальный и физический доступ выглядит несколько надуманно; даже при разъяснении в примере 4. Вот представьте, что вы согласно 3-му разделу отнесли к компонентам ИС PLC или IP-телефон. Если я втыкаюсь в PLC, находясь внутри компании, или подменяю IP-телефон, то это какой доступ, локальный или физический? А в случае с удаленным доступом, если теща со своей учетки решила разложить пасьянс на домашнем ПК, подключенном к корпоративной сети, и случайно занесла на этот компьютер вредоносный код, то это какой доступ - удаленный, локальный или физический? Или, вспоминая первую заметку, это вообще не угроза, так как никаких неправомерных действий теща не совершала? :-) Теще, кстати, посвящен п.4.8, но и он не отвечает на вопрос выше.

Трата времени на определение типов доступа при моделировании угроз по анализируемой методике является, на мой взгляд, избыточным. В 6-м разделе, в п.6.5, говорится, что тип доступа определяет начальные тактики Т1 и Т2. Фигушки. Ничего он не определяет, так как Т1 - это сбор информации о сетях и системах, а он, и это я бы принял за аксиому, проводится почти во всех серьезных сценариях угроз (а для непреднамеренных угроз "отказ" нарушителя от этой тактики не влияет на конечный результат методики - для остальных типов нарушителей сбор всего равно осуществляется и мы все равно должны на него закладываться). С Т2, получением первоначального доступа к компонентам систем и сетей, тоже все проще. Я вот с трудом себе представляю ситуацию, когда злоумышленник действует только извне или только изнутри. А если мы посмотрим на 5-й раздел (его мы анализируем завтра), то вы поймете, что из-за нечеткости определения внутреннего и внешнего нарушителя и достаточно динамичного перехода одного статуса в другой, совершенно не важно, какие типы доступа у вас есть - вы все равно, перебирая сценарии угроз, включите в список актуальных оба варианта. По-другому сегодня просто не бывает.

Раздел завершается пунктом 4.9, который говорит, что должно быть определено по итогам оценки потенциала нарушителя. Но я так и не понял, что, а самое главное, как это должно быть определено. Как, конкретно, выявить уязвимости на этапе создания системы? Как, конкретно, выявить уязвимости, на этапе эксплуатации системы (или только пентест, условия проведения которого выходит за рамки методики)? Как выявить недекларированные возможности? По ДСПшному документу ФСТЭК (ну так где ссылка на него или выписку из него)? Зачем мне подробное описание типов доступа нарушителей и как я его должен использовать (кроме п.6.5)? А самое главное, как все выявленное я должен описать? В разделе 3 хотя бы пример таблицы был дан, а тут пустота. Возможно, в следующих разделах станет понятно, зачем это все надо было. Но пока 4-й раздел выглядит для меня незаконченным.

Подробнее…

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

Завершив прошлую заметку математическими выкладками, я решил проверить, а насколько сама MITRE ATT&CK пропагандирует такой подход с перебором всех возможных комбинаций. В документе "Getting Started With ATT&CK" приводится 4 основных сценария применения этой матрицы:

• Threat Intelligence
• Обнаружение и аналитика
• Эмуляция нарушителей и red team'инг
• Оценка и инжиниринг.

Интересно, что авторы этой матрицы, понимая, что ею будут пользоваться и крупные компании, и не очень, выделили 3 уровня зрелости команд ИБ, использующих ATT&CK в своей работе. Но в любом случае, среди этих сценариев нет ни слова о полном переборе (это уже не говоря о том, что среди этих сценариев и моделирования угроз-то нет). Учитывая, что для государственных структур эта методика будет обязательной, то боюсь, что они не смогут выполнить это требование. Если предположить, чисто гипотетически, что на составление и проверку одного сочетания уйдет 1 секунда, то на проверку всех комбинаций понадобится 277 миллионов часов, или 11 с половиной миллионов суток (без перерыва) или 31709 лет непрерывной работы! Можно конечно распараллелить эту работу среди множества специалистов по ИБ (если они есть), или автоматизировать (если есть средство автоматизации), или поручить какой-нибудь компании... Ну то есть дело небезнадежное. Особенно если запустить краудсорсинговый проект по аналогии с поиском внеземных цивилизаций SETI@home и привлечь тысячи волонтеров, которые будут отдавать свои свободные вычислительные ресурсы для поиска всех комбинаций.

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

Я попробовал применить это к системе удаленного доступа в Cisco (кому интересно, как это устроено, мы в четверг будем проводить вебекс на эту тему) и понял, что не могу - у нас только активных IP-устройств в сети около полумиллиона, несколько сотен тысяч рабочих станций, десятки тысяч пользователей, тысячи серверов и виртуальных машин, а также тысячи приложений. Как вы думаете какое количество комбинаций взаимодействия будет в такой конфигурации? Да, у нас есть средства автоматизации анализа взаимодействия на уровне ОС, приложений, сети и пользователей, но работают они у нас преимущественно для ЦОДов и облачных сред, то есть только там, где обрабатываются данные и работают критичные для нас приложения.

Дальше, согласно пункту 3.3, мы должны определить для каждого компонента виды неправомерного доступа, которые могут привести к негативным последствиям. ДЛЯ КАЖДОГО. Не для целой системы или процесса, не для группы ресурсов или компонентов, а для каждого. Чем виды неправомерного (хотя, наверное, должно было быть "несанкционированного") доступа для моего ноутбука отличаются от таких же видов НСД для еще несколько тысяч моих коллег по компании, имеющих те же привилегии, что и я, я не знаю. Также как и негативные последствия. Я еще могут понять, когда ущерб считается для всех бухгалтеров, для всех имеющих доступ к ПДн, для всех, имеющих доступ к конфиденциальной информации, для всех коммутаторов в ЦОДе и т.п. Такое группирование логично. Но оценивать это для КАЖДОГО?.. То есть я еще не закончил процесс вычисления всех комбинаций тактик и техник, не завершил процесс вычисления всех комбинаций взаимодействия компонентов ИС на пяти уровнях, а тут мне еще и все виды несанкционированного доступа для всех этих компонентов надо определить.

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

Кстати, в перечислении шести видов неправомерного доступа упоминаются и негативные последствия. Например, в примере 2, утечка - это негативные последствия, а в п.3.3 - это уже неправомерный доступ. Также к неправомерному доступу относится отказ в обслуживании и нарушение функционирования, что, на мой взгляд, скорее относится к последствиям.

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

Подробнее…

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

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

Раздел 2 является обзорным, описывающим, как нам надо выстраивать процесс моделированияЕ не погружаясь в детали. Пункт 2.1 говорит нам, что мы можем закрыть глаза на ошибки пользователей, так как они врядли относятся к неправомерным действиям. С другой стороны у нас неоправданно расширен список возможных угроз, с которыми нам придется бороться, так как в качестве угроз мы рассматриваем не только действия и(или) воздействия, в результате которых возможно нарушение безопасности информации и(или) нарушение или прекращение функционирования систем и сетей, повлекшее наступление негативных событий, но и все остальные неправомерные действия и(или) воздействия, в результате которых возможно нарушение безопасности информации; уже независимо от наступления негативных событий. Возможно, в предпоследней строке п.2.1 вместо слова "повлекшЕе" должно было стоять "повлекшИе", но пока это слово относится только к последней части абзаца, то есть к нарушению или прекращению функционирования систем и сетей. Также, этим пунктом мы исключаем из рассмотрения все угрозы, связанные с бездействием. Например, появилась уязвимость в VPN-клиенте или шлюзе удаленного доступа и логично было бы ее устранить, но мой администратор решил забить на это и ничего не делать. Позже через эту уязвимость в сеть залезли хакеры, но администратор разводит руками, так как в модели угроз его бездействие не было учтено.

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

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

Пункт 2.4 как раз нам и говорит о том, что надо определиться с границами объектам защиты (почему-то названными границами процесса моделирования) и его взаимосвязями, в том числе и с обеспечивающими системами. Например, если злоумышленники выведут из строя подстанцию, которая дает электричество на мой офис, то им не надо будет атаковать ни моих удаленных пользователей, ни кластер удаленного доступа. Они решат свою задачу окольным путем (если им надо было нарушить доступность всей системы). Тоже самое касается и провайдеров VPN-доступа, которые не относятся к моему объекту защиты, но при этом этот объект от них сильно зависит и мы должны включить его в зону нашего внимания. Правда, регулятор, возможно, чтобы не усложнять методику, исключил обслуживающие системы из процесса моделирования, оставив только те, которые принадлежат обладателю информации или оператору ИС или сети, ее обрабатывающей, то есть лицу, с которым у меня заключен соответствующий договор. Рисунок 2, про границы моделирования для ИС, использующих ресурсы внешнего ЦОДа, это подтверждает. Не знаю, насколько это правильно; я бы все-таки старался учитывать еще и системы обеспечения. Пока я не дошел до следующих пунктов, задамся вопросом, а надо ли мне при моделировании учитывать возможные неправомерные действия, осуществляемые при ремонте компонентов моей системы? А при их поставке и разработке?

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

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

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

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

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

А рисунок 3, кстати, запутывает процесс моделирования. Распределение зон ответственности лучше было отражать на рисунке 2. Это же относится и к рисункам 4 и 5. Понятно, что хотел сказать регулятор, но отобразить это стоило бы, как мне кажется, в виде вертикальных блоков/зон, как это часто показывают в презентациях и статьях по защите облаков, рассказывая про разделяемую ответственность. Я вот нашел такую в какой-то из своих презентаций 10-тилетней давности. На ней, кстати, показан и такой непростой вопрос при моделировании угроз, как API, который в методике назван интерфейсами взаимодействия с иным программным обеспечением.

Пункты 2.13 и 2.15 противоречат друг другу в той части, что в первом случае указано, что структура модели угроз должна соответствовать приложению 3, а во втором - это уже не требование, а рекомендация.

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

Таблица 4 6-го раздела содержит 10 тактик и 77 техник. И если мне надо определить максимально возможное число таких совокупностей, то взяв на вооружение комбинаторику и предположив, что для реализации угрозы нарушитель будет использовать все 10 тактик (то есть шагов kill chain), я получу... до хрена вариантов. Очень условно, я бы назвал, что таких комбинаций будет чуть больше 1 триллиона (число сочетаний из 77 техник по 10 штук в каждом). Даже если "выровнять" число техник до 5 для каждой из 10 тактик, число возможных сочетаний у меня будет больше 10 миллиардов. Для матрицы MITRE ATT&CK (я о ней писал неоднократно), которую использовать тоже можно, у меня число возможных сочетаний будет измеряться квадриллионами. Да, я понимаю, что в реальности не все такие сочетания будут возможны, но формулировка "максимально возможное число сценариев" заставляет перебирать их все и отбрасывать неприменимые. А в условиях отсутствия средств автоматизации такой работы, на ней все и умрут...

На этой позитивной ноте я завершил изучение 2-го раздела проекта методики моделирования угроз. Завершу и эту заметку, продолжение которой будет завтра.

Подробнее…

Пока все дома. Чем развлечься безопаснику?

Вопрос, вынесенный в заголовок, вроде и простой. Ну чем заняться? Работу же никто не отменял. Пусть наш гарант и отправил всех на оплачиваемые выходные, но ИТ-системы, которые обслуживают экономику страны, продолжают работать и их продолжают атаковать. А значит и защищать их тоже надо. Поэтому многие специалисты по ИБ продолжают работать несмотря ни на что. Кто-то ездит в офис, кто-то сидит на удаленке. Но надо признать, кто-то и не работает. Кого-то отправили в неоплачиваемый отпуск, кого-то сократили, кому-то сократили рабочий день. Но выходить-то на улицу все равно нельзя. Что делать? Можно заняться самообразованием. А можно... можно развлекаться. Вот о развлечениях и будет эта заметка.

На самом деле, она будет очень субъективной, так как я немного приложил руку к тому, что сделала медиа-группа Авангард. Но от этого сделанное не стало хуже :-) Началось все с продолжения ставшей популярной в прошлом году "Нашей игры", где безопасники могли проверить свою эрудицию и знания в области ИБ. Но так как очно собираться сейчас нельзя, то Авангард запустил домашнюю версию этой игры - "Наша игра. Home Edition". В прошлый четверг состоялась уже первая игра, котора лично мне понравилась. Жаль, что я не могу принимать участие, так как являюсь соавтором вопросов и имею преимущество перед другими игроками.



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

Но это не все, что придумал Авангард. Еще он запустил конкурс рисунка #рисуйib. Ну почти как в советское время, когда пионеры и октябрята слали свои рисунки в "Утреннюю зорьку" или "Пионерскую правду" и их работы публиковались в детских СМИ :-) Этот конкурс тоже для детей и их восприятие шоу "Наша игра. Home Edition". Если у вас есть дети, то их можно занять в свободное время и получить для них приз :-)

Еще медиа-группа "Авангард" начала размещать квизы и тесты по ИБ. Пока там всего один ребус, но их число будет расти. Они будут забавные и познавательные одновременно. А самое главное они позволят скоротать время, которое так долго и нудно течет в четырех стенах.

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

В общем, не скучайте...

Подробнее…

ИБ и рекламируемые на солидных ресурсах мошеннические сайты, "торгующие" медицинскими масками

На Хабре я уже писал о том, как мошенники Рунета отреагировали на коронавирус. Сейчас я бы хотел рассмотреть эту историю, но уже с другими примерами, немного с другой точки зрения. Иногда просматривая новости на различных солидных ресурсах, натыкаешься на рекламу, которую обычно пропускаешь уже на автомате. Но в этот раз глаз уцепился за два рекламных объявления, которые я увидел на мобильной версии сайта РБК (левых две картинки). Если приглядеться, то мы увидим, что они ведут на схожие по названию сайты - marketsshoop[.]ru и marketshoop[.]ru. Третья картинка - это реклама уже в стационарной версии какого-то популярного сайта. Эта ссылка ведет на ozonrf[.]ru (сразу скажу, что никакого отношения к Интернет-магазину "Озон" этот домен не имеет).

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

Если посмотреть на детали этих доменов, в целом ничего такого уж криминального не замечаешь. Ни фишинга, ни распространения вредоносного кода, ни наличия C&C-составляющей.

Но вот дальше интереснее. Все эти домены, принадлежащие разным ООО (а я быстренько проверил владельцев фирм, которые стоят за этими доменами), "висят" на одном IP-адресе - 94[.]130[.]71[.]230. 

Мало того, многие домены еще и начали свою активность примерно в одно и тоже время.

Начинаешь просматривать, кому принадлежат все эти ООО, которые, согласно рекламе, продают медицинские маски, так нужные гражданам в условиях пандемии? И что оказывается? На сайтах обычно нет никаких контактов. Ни телефонов, ни e-mail. И это у электронного магазина? Во-вторых, многие из проанализированных ООО имеют недостоверные адреса, находятся в процессе ликвидации, у кого-то приостановлены операции по счетам. То есть речь идет явно не о каком-то налаженном легальном бизнесе, который решил, несмотря на то, что у многих в качестве основной деятельности указана торговля продуктами питания, галантереей и т.п., помочь людям. А вспоминая свежую историю на Хабре про OSINT одного из мошенников, который тоже "торговал" масками, понимаешь, что и примеры выше тоже, скорее всего, являются мошенническими и выманивают деньги желающих купить медицинские товары для борьбы с COVID-19.

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

Во-первых, иногда, отсутствие явных связей между различными ООО, которые не показывают специализированные сервисы типа Спарка и т.п. А вот анализ инфраструктуры доменов и сайтов, общие AS, IP, e-mail владельцев, даты и время создания и т.п. показывает явную связь между ресурсами. И помочь в этом может именно ИБ, обладающая соответствующим инструментарием.

Во-вторых, мы видим, что ссылки на явно мошеннические ресурсы рекламируются на таком солидном и активно посещаемом сайте, как РБК. И проблема тут не в РБК, который неправильно было бы обвинять в способствовании деятельности мошенников. Проблема в том, как устроенная баннерная реклама. Мошенники выкупают показы на сайтах, участвующих в баннерном обмене. И дальше их реклама может быть показана на РБК, на Mail.ru, на Анекдотах, на hh.ru и т.п. И посколько вы доверяете этим сайтам, подспудно вы, а точнее ваши пользователи, будут доверять и рекламе на них. Один клик и пользователь заражен. Об этом стоит говорить в рассылках по повышению осведомленности, чтобы пользователи понимали нюансы. Кроме того, стоит им напомнить, что присутствие в названии сайта знакомых слов - ozon, sberbank, zoom, facebook и т.п. еще не означает, что владельцы этих торговых марок имеют хоть какое-то отношение к таким сайтам. Пример с ozonrf[.]ru выше только демонстрирует это.

В-третьих, вы скорее всего не вносите домен www.rbc.ru в черный список на своем прокси. А значит, что пользователь увидит все, что подгружается на страницы РБК или иного разрешенного сайта во время захода на них с помощью браузера. Загружаются в том числе и ссылки на вредоносные ресурсы :-( Поэтому, с точки зрения мониторинга Web-трафика, стоит ориентироваться не на технологии, работающие по принципу белых/черных списков, а на что-то более продвинутое. Например, есть решения, которые анализируют на лету посещаемые страницы и вырезают оттуда все вредоносное и опасное, заново пересобирая страницу уже в безопасном формате.

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

А в заключение сделаю некоторый прогноз о том, какие темы станут популярными у кибермошенников в самое ближайшее время:

• Ресурсы/приложения, генерящие код/пропуск для проезда в режиме самоизоляции. Учитывая, что большинство государственных ИТ-архитекторов и программистов не рассчитывали на пиковые нагрузки при посещениях гражданами своих ресурсов, то они, по понятной причине, не справились с нагрузкой и постоянно недоступны. На этом фоне родится предложение по созданию сайтов или мобильных приложений, которые будут генерить цифровые пропуска. Это будет либо за деньги, либо сайты/приложения будут красть информацию пользователей.
• Ресурсы/рассылки для пользователей сервисов видео- и теле-конференций. Вам будут приходить письма, что используемый вами сервис не справляется с нагрузкой и вам надо скачать либо обновленное приложение, либо проверить пропускную способность перед подключением к конференции.
• Ресурсы/рассылки/приложения для онлайн обучения или иного времяпрепровождения. Оно и понятно - люди скучают и хотят тратить время с пользой или без оной. Поэтому использование темы повышения квалификации или развлечений онлайн будет на коне.
• Ссылки на новые VPN/RDP-шлюзы. Тут тоже понятно - при удаленной работе сотрудники подключаются именно через них и вполне логично, что злоумышленники будут рассылать письма с адресами новых, менее загруженных точек подключения.
• Для России неактуально, но на Западе уже идет рост рассылок по теме психологического и физического здоровья. В условиях существенной смены режима у многих людей начинаются расстройства психики, стресс, обжираловка и другие излишества. А помочь бороться с этим могут различные программы оздоровления, которые также проводятся онлайн. Злоумышленники уже начинают маскироваться под такие рассылки.

Подробнее…

Смена приоритетов ИБ как следствие коронавируса

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

Совершенно очевидно, что для абсолютного большинства компаний на первое место вышла тема удаленной работы. Такой же важный приоритет у этой темы и для ИБшников, которым надо было в экстренном режиме либо с нуля выстроить архитектуру безопасного удаленного доступа, не мешающего бизнесу, либо проверить, что уже построенная ранее архитектура справится с многократным ростом числа удаленных подключений (тут и кластеризация VPN-шлюзов, и правильное "прокидывание" удаленных пользователей к нужному сегменту/приложению, и защита от DDoS VPN-кластера и т.п.). Удаленка - это вообще отдельная тема, требующая не одной статьи. Я попробую ее начать раскрывать на следующей неделе.

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

а также обновить график реализации своих проектов в условиях удаленки, изменения приоритетов и, возможного, сокращения бюджетов: 

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

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

• EDR, которые позволяют не только обнаруживать неизвестное вредоносное ПО, но и проводить расследование, в том числе удаленное (антивирусы выкиньте в топку - это бессмысленная трата денег).
• ПО для защиты мобильных устройств (если у вас есть такие пользователи, которые работают с планшетов и, возможно, со смартфонов). Не забудьте про безопасность SmartTV (хотя защитного софта для них вроде и нет), так как бывает, что сотрудники ставят на SmartTV ПО для проведения телеконференций и с них ведут конфиденциальные переговоры.
• Zero Trust. Это целый пласт решений (писал про них тут и тут), который при удаленной работе становится очень важным, так как ваши удаленные пользователи уже не защищены корпоративными и ведомственными средствами защиты и остаются один на один с киберугрозами. Если вдруг вам интересно, как киберпреступники используют тему коронавируса в своей деятельности, то на Хабре я написал две статьи об этом - тут и тут.
• Мониторинг DNS. Учитывая, что сотрудники могут работать с личных устройств и их могут легко затроянить, стоит посмотреть в сторону сервисов по мониторингу DNS, которые позволяют без установки ПО на компьютер, мониторить доступ к фишинговым сайтам, блокировать работу ботнетов и обращение к C&C-серверам. Простенько и  прозрачно для пользователя.
• Многофакторная аутентификация (MFA). Ну тут вроде и так все понятно. Учитывая, что в 81% инцидентов задействованы были украденные или подобранные учетки, то доверять обычным паролям сегодня нельзя. А при удаленной работе тем более.
• Повышение осведомленности и фишинговые симуляции. Если вы прошли по последним двум ссылкам (на два абзаца выше), то увидели примеры фишинговых атак, которые сейчас популярны у киберпреступников. Пользователей, которые не сидят в офисе, и предоставлены сами себе, будут чаще попадать на удочку мошенников, чем раньше. Стоит их обучать тому, как выявлять подозрительные письма, сайты и ссылки, и что делать, если они с ними столкнутся. 
• UEBA. Это из серии "неплохо бы", так как существенно возрастают риски неправомерных действий со стороны сотрудников, как с их ведома, так и без оного. Но можно и просто правильно настроить существующие средства мониторинга (те же NTA, SIEM и др.).

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

Также не стоит забывать, что многие производители сейчас выдают лицензии на свои продукты бесплатно, но не навсегда, а на определенное время. У кого-то 45, у кого-то 60, у кого-то 90 или 180 дней, которые пролетят очень быстро. Особенно если наш гарант в очередной раз, вспомнив про половцев и печенегов, не продлит, наплевав на Конституцию, Трудовой Кодекс, закон о ЧС и эпидемиологическом благополучии населения,  режим самоизоляции. И тогда надо думать, как продлять полученные разные лицензии. Кто-то из производителей может и продлит, а кому-то это не позволят сделать финансовые контроллеры и надо будет оплачивать лицензии.

Стартапам от ИБ будет тяжело (а им так тяжело в России, так как отечественные требования по ИБ не дают возможности малым компаниям развиваться и находить заказчиков), так как CISO в текущих условиях будут предпочитать доверенных и проверенных поставщиков. Стартапы к таковым, увы, не относятся.

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

Подробнее…

Каких навыков не хватает ИБшникам и какие навыки востребованы?

Наткнулся я на днях на вот такую матрицу, которая показывает результаты анонимного опроса 34-х специалистов по ИБ с минимум 5-тилетним стажем по 19 различным навыкам, которыми они обладают или не обладают. Черным показаны пробелы в навыках. Если посмотреть внимательно, то окажется, что только один чувак с опытом более 24 лет обладает всеми навыками. У остальных есть пробелы, местами достаточно значительные. Отсюда можно сделать два простых вывода:

1. Нельзя знать все! Если вы чего-то в ИБ не знаете, не надо посыпать голову пеплом. 97% специалистов такие же как и вы и тоже чего-то не знают. Скорее это повод задуматься о том, каких навыков вам не хватает и пойти их нарабатывать.
2. Но нарабатывать их вам надо, если вам они нужны. И отсюда второй вывод. Специалисты по ИБ широкого профиля редки на рынке. У многих есть своя специализация и он растет в ней.

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

• управлением уязвимостями и поиск багов
• управление доступом и идентификационной информацией
• разработка эксплойтов
• пентесты
• безопасность ПО (тут, думаю, речь идет об AppSec) и DevOps
• социальный инжиниринг.

Такая картина соответствует, как минимум, моему восприятию мира. SecDevOps и AppSec - это достаточно новое направление в ИБ и в нем еще маловато специалистов. Социнжиниринг подразумевает работу с людьми и знание психологии, что никогда не было коньком безопасников. Еще три навыка относятся к offensive-тематике, которая хорошо знакома обычно молодому поколению, а не пиджакам. Немного выбивается тема Identity Management; не знаю почему.

Завершить эту небольшую заметку хотелось бы другой статистикой; на этот раз от IDC. В декабре 2018-го года они провели опрос 1438 респондентов, спросив у них про наиболее важные навыки в их работе специалистов по ИБ. Был предложен список из полусотни навыков, которые затем были ранжированы по важности. В десятку вошли следующие (в порядке убывания):

1. Умение писать скрипты для различных задач, возникающих в деятельности безопасника
2. Знание бизнеса и умение говорить с ним на одном языке
3. Гиперконвергентные инфраструктуры
4. Анализ данных
5. Понимание бизнес-тенденций
6. Машинное обучение
7. Управление приложениями
8. API
9. SQL
10. ERM или ERP.

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

• блокчейн
• виртуальная и дополненная реальность
• управление бизнес-процессами
• CRM
• DevOps
• управление базами данных
• управление сетями
• телекоммуникации
• пользовательский интерфейс
• и другие.

Часть из этого списка "аутсайдеров" скорее связана с тем, что безопасники думают, что они все знают в той или иной области (например, в сетях, open source или той же кибербезопасности, тех областях которые вообще не были названы), а остальные темы скорее просто неинтересны безопасникам и они их считают неперспективными (тот же VR/AR или блокчейн) или ненужными в своей работе (тот же BPM или UD/UX).

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

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

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

И не болейте! 

Подробнее…

Вопросы к ИБ-регуляторам по поводу коронавируса

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

• Для субъектов КИИ ФСТЭК выпустила рекомендации (письмо ФСТЭК от 20 марта №240/84/389) об обеспечении безопасности объектов КИИ при реализации дистанционного режима исполнения должностных обязанностей работниками субъектов КИИ. Кстати, какова юридическая сила этого письма по сравнению с тем же 235/239-м приказами?
• Схожие, но почему-то дспшные, рекомендации (письмо ФСТЭК от 20 марта 2020 г. №240/22/1204дсп) о мерах защиты информации, принимаемых в информационных системах, в целях минимизации рисков возникновения дополнительных угроз безопасности информации при осуществлении удаленного доступа их работников, ФСТЭК направила в ФОИВ и подведомственные организации.
• НКЦКИ также 20 марта опубликовал уведомление об угрозах безопасности информации, связанные с пандемией коронавируса.
• 23 марта и Банк России опубликовал свои собственные рекомендации по организации работы соответствующих сотрудников вне зависимости от того, работают они из офиса или удаленно в условиях распространения коронавируса.

Даже Верховный Главнокомандующий у нас на удаленке

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

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

1. ФСТЭК при оказании услуг мониторинга ИБ требует, чтобы у SOC было свое помещение и своя соответствующая требованиям ИБ информационная система. В условиях перевода на удаленку работников SOC, как выполнить это требование? Не пора ли все-таки перестать привязывать деятельность по ИБ к ее физическому местоположению и допустить существование виртуальных и мобильных SOCов?
2. Аналогичный вопрос и к центрам ГосСОПКИ. Насколько возможно обеспечение их функционирования из дома?
3. Многие работники, находящиеся на удаленке и работающие не только с корпоративных, но и личных устройств, имеют доступ к персональным данным, тем самым расширяя границы своих ИСПДн. Как ФСТЭК и Роскомнадзор рекомендуют вести себя операторам ПДн в таких ситуациях? Надо ли пересматривать требования по ИБ, установленные 21-м приказом ФСТЭК, или заново отправлять обновленное уведомление в РКН?
4. РКН вообще единственный не выдал никаких рекомендаций, кроме работы с тепловизорами при измерении температуры и новостей о том, что возможен фишинг (и тут) и спам, паразитирующий на теме коронавируса (без примеров и тем более индикаторов компрометации). А мне, например, интересно было бы посмотреть на рекомендации, связанные с получением согласий на обработку ПДн при дистанционной работе.
5. ЦБ и ФСБ (а в ряде случаев и ФСТЭК) настойчиво рекомендуют использование сертифицированных СКЗИ. Как выполнить это требование в условиях дистанционной работы? Не с технической точки зрения, а с точки зрения всех регламентов, формуляров, инструкций (той же 152-й) и т.п.? Это не говоря уже о том, что число мест, в которых ведется работа с применением СКЗИ существенно возросло и не потребует ли это внесения изменения в лицензию ФСБ на деятельность, связанную с шифровальными средствами?
6. Произойдут ли какие-то изменения в части ЕБС? Как с точки зрения съема биометрических данных (например, рекомендация приостановить эту деятельность), так и с точки зрения выполнения всего спектра нормативных и нормативно-правовых актов, связанных с работой ЕБС. В условиях пандемии выполнить их все достаточно затруднительно.
7. Есть подозрение, что в условиях пандемии и разработчикам средств защиты, и разработчикам финансового ПО, которое должно пройти оценку соответствия по требованиям ФСТЭК и Банка России, будет сделать это затруднительно. И начало лета, установленное обоими регуляторами (ФСТЭК - в части крайнего срока обновления сертификатов; ЦБ - в части отсрочки проверки), как мне кажется, становится уже нереальной датой для выполнения соответствующих требований. Будут ли смещать этот срок?
8. Как выполнять аудит внешними силами по требованиям ЦБ. Многие сидят дома и боятся высунуть нос на улицу. Можно ли проводить аудит дистанционно? Как удостовериться в его честности? Можно ли отсрочить проведение аудита (именно аудита со стороны финансовых организаций, а не проверок со стороны регулятора)? Если чуть расширить этот вопрос, то как вообще можно дистанционно убедиться в выполнении требований по оценке соответствия в условиях текущей нормативки? Если никак, то надо ли ее менять или  временно отложить ее применение?
9. Можно ли проводить оценку уровня доверия и вообще сертификационные испытания по требованиям ФСТЭК из дома? Как, например, читать дспшные требования к уровням доверия, если ты находишься на удаленной работе? Это вообще возможно (думаю, что нет)?
10. Как утверждать/заверять решения совещаний, проводимых дистанционно с помощью различных сервисов телеконференций? Как организовывать работы всяких комиссий, упоминаемых в нормативных документов регуляторов, например, комиссии по категорированию объектов КИИ? А если смотреть шире, то как вообще дистанционно выстраивать процессы, завязанные на бумажный документооборот (всякие согласования, утверждения, журналы и т.п.)? Причем это вопрос не только к тем, кто выполняет требования регуляторов, но и к тем, кто их проверяет.
11. Рекомендации по применению УКЭП при дистанционной работе.
12. Надо ли обновлять контакты лиц, отвечающих за ИБ или за обработку ПДн, которые собирали регуляторы в рамках выполнения своих обязанностей?

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

ЗЫ. Хорошо хоть категорирование объектов КИИ все уже закончили... ну или должны были закончить еще в прошлом году :-)

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

Подробнее…