0-Day не так важны или почему знать TTP важнее

Цель безопасника не предотвратить все, что может плохого произойти в его владениях, но помешать хакеру быть успешным. 8 с половиной лет назад я подхватил на свой компьютер троянца и это несмотря на наличие у меня постоянно обновляемого антивируса. Только установленный у меня Cisco Security Agent смог зафиксировать и заблокировать непонятное сетевое соединение с компа с внешним узлом в Украине. Я так и не понял, как и где я подцепил заразу и проведенное расследование не смогло ответить на этот вопрос. Но!.. И ущерба мне нанесено никакого не было, так как вредоносная программа не смогла соединиться с внешним миром для передачи данных. Если обратиться к убийственной цепочке Kill Chain, то последний этап реализации атаки не сработал и можно считать ее всю неуспешной для злоумышленника.

К чему этот исторический экскурс? 0-Day существовали, существуют и будут существовать всегда. Все равно ни рядовой, ни корпоративный пользователь ничего не может с этим поделать - это прерогатива производителя, который в меру своих знаний и ресурсов оперативно устранит обнаруженную проблему; или не устранит. Устранив один 0-Day, появится второй, потом третий... Это гонка бесконечна. Постоянно появляется что-то новое, что может помочь злоумышленнику заразить ваши компьютеры. То есть 4-й этап Kill Chain может случиться все равно. Но вот техники, используемые злоумышленниками после заражения и компрометации, практически не меняются. Вспомним матрицу ATT&CK - она очень хорошо это иллюстрирует. И поэтому с точки зрения обеспечения кибербезопасности разумнее было бы сфокусироваться на том, что мы можем обнаружить и блокировать.

А для этого необходимо то, что на Западе емко называют TTP (tactics, techniques, and procedures), то есть тактика, техники и процедуры злоумышленников. Но важно не просто понимать, что могут сделать плохие парни; важно знать, что этому противопоставить каждой технике. Просто знать о том, что можно сломать сетевое оборудование через буткит мало - гораздо важнее с точки зрения кибербезопасности знать, что этому можно противопоставить. Без этой информации рассказы о том, как сломать, - это не более чем помощь настоящим злоумышленникам. Пользы в этом и уж тем более развития ИБ нет. Скорее наоборот. Такая информация способствует росту киберпреступности. Поэтому описанная ранее матрица ATT&CK связана с шаблонами атак CAPEC и для каждой техники предложен набор защитных мер. Это позволяет быстро понять, как выстроить систему защиту, а не только подивиться хитрому мозговыверту злоумышленников, которые нашли очередной способ обойти защитные механизмы вендора, даже несмотря на внедренный SDLC.

Анатомия внешней атаки from Aleksey Lukatskiy

Как связать этапы Kill Chain и защитные меры?

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

Это ровно то, что в свое время постоянно спрашивали применительно к методике моделирования угроз ФСТЭК, которую обещают выпустить в 1-м квартале 2017-го года. Можно ли увязать угрозы с защитными мерами из 17/21/31-го приказов ФСТЭК. Я придерживался мысли, что задача это малореальная, так как оба множества (и защитных мер, и угроз) у нас бесконечные и отрисовывать между ними связи - задача непростая.

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

Собственно MITRE эту задача планомерно и реализует. В упомянутой вчера матрице ATT&CK для многих методов атак прописаны соответствующие им методы нейтрализации. И тоже самое сделано в базе шаблонов атак CAPEC (например, вот так).

Можно пойти и дальше и уже применительно к деятельности SOC для каждого из этапов Kill Chain и атакующих методик прописать типы индикаторов компрометации (IoC), которые помогут обнаруживать те или иные нарушения или аномалии. Например, на этапе доставки это могут быть IP/DNS-адреса, URL-адреса или адреса e-mail. На этапе управления это также будут IP/DNS-адреса. На этапе инсталляции это могут быть значения реестра или хэши файлов. Зная какие типы IoC помогают нам обнаруживать активность злоумышленников, мы сможем искать источники для этих IoC для своего SOC.

Матрица ATT&CK для описания всех возможных методок атак

Продолжая начатую вчера тему убийственной цепочки, хотел бы привести пример еще одной интересной классификации, которая имеет более практическое применение и может быть использована при моделировании угроз, при котором так важна систематизация имеющейся информации о методах, используемых злоумышленниками. Речь идет о матрице ATT&CK (Adversarial Tactics, Techniques & Common Knowledge), разработанной американской корпорацией MITRE, известной своими стандартами CVE, CAPEC, TAXII и другими. Данная матрица не заменяет Kill Chain, а всего лишь уточняет, что скрывается за последними тремя этапами убийственной цепочки.

В последней версии, вышедшей в июля 2016-го года, три последних стадии атаки делятся на 10 тактик, используемых злоумышленниками:

• живучесть
• повышение привилегий
• обход защитных мер
• доступ к учетным записям
• обнаружение
• lateral movement (не знаю как перевести нормально на русский)
• исполнение
• сбор
• утечка
• управление и контроль.

Указанные 10 тактик тетализируются в 121 технике, которые и перечислены в матрице, фрагмент которой показан ниже. Для многих техник даны ссылки на базу шаблонов атак CAPEC, которую разработала таже MITRE. Каждая техника описана подробно в формате wiki - с примерами, перекрестными ссылками, дополнительной информацией.

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

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

Kill chain для внутреннего нарушителя

Вчерашняя заметка, как справедливо отметили коллеги в комментариях, ориентирована на внешнего нарушителя и не очень хорошо подходит для описания нарушителя внутреннего. Это и так и не так одновременно. Все зависит от того, о каком нарушителе мы ведем речь. Если это обычный сотрудник, который решил поживиться ценной информацией перед своим увольнением, приведенная Lockheed Martin схема будет избыточной. А вот если мы говорим о специально внедренном на какой-либо критически важный объект "казачке", задача которого проникнуть в святая святых и используя внешние связи получить доступ к важной системе или информации с использованием специально подготовленного "кибероружия", то убийственная цепочка продолжает оставаться актуальной. Но таких ситуаций все-таки не так много и поэтому давайте попробуем составить Kill Chain для инсайдера.

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

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

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

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

ЗЫ. Хочется отметить, что эти две разных убийственных цепочки очень хорошо показывают различия в действиях внешних и внутренних нарушителей и в необходимости разработки разных так называемых use cases при построении и эксплуатации SOC, о чем мы тоже будем говорить на ноябрьском SOC Forum.

Убийственная цепочка или что такое Kill Chain

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

Впервые широко этот термин стал использоваться после публикации компании Lockheed Martin и его задача описать последовательность шагов злоумышленника, осуществляющего проникновение в информационную систему.

На уровне подсознания мы прекрасно понимаем, что любая атака происходит не на пустом месте, она требует подготовки и ряда иных действий для того, чтобы быть успешной. Вот Kill Chain и описывает эти шаги, начинающиеся не с проникновения через периметр корпоративной или ведомственной сети, а с сбора разведывательной информации. По сути Lockheed Martin аккумулировала имеющиеся ранее исследования и модели МинОбороны США, ВВС США и ряда других организаций и предложила 7 стадий, которые проходит злоумышленник для успешной реализации своей деятельности:

1. Разведка. Исследование, идентификация и выбор свой жертвы, часто используя публичные источники данных - соцсети, сайты конференций, списки рассылки и т.п.
2. Вооружение. Оснащение вредоносным содержанием файла (например, PDF или MS Office) или иного контента, который должен быть прочтен/открыт жертвой. 
3. Доставка. Донесение вредоносного контента до жертвы, чаще всего используя для этого e-mail, web-сайты или USB-флешки.
4. Заражение. Запуск вредоносного кода, используя имеющиеся на целевом компьютере уязвимости, с последующим его заражением.
5. Инсталляция. Открытие удаленного доступа для незаметного управления и обновления вредоносного кода. В последнее время для этого чаще всего используется протокол DNS.
6. Получение управления. Получение обновлений с новым функционалом извне, а также управляющих команд для достижения поставленных целей.
7. Выполнение действий. Сбор и кража данных, шифрование файлов, перехват управления, подмена данных и другие задачи, которые могут стоять перед нарушителем.

Понятно, что злоумышленник не обязательно должен соблюдать указанные 7 шагов, но в этом случае эффективность его деятельности снижается. Более того, 7 шагов часто модифицируются в 6 или 8. Например, в картинке ниже (скачана из Интернет) этап утечки данных выделен отдельно. А на последней картинке восьмой этап описывает уничтожение следов после выполнения своей задачи злоумышленником. Но как бы то ни было, первые шаги, описанные несколько лет назад Lockheed Martin, остаются неизменными.

Если подытожить, то Kill Chain представляет собой систематический процесс достижения нарушителем цели для получения желаемого эффекта. С этой же целью (систематизация) это понятие и стоит включить в арсенал служб ИБ (если этого еще не сделано). Использовать это понятие можно при моделировании угроз, а с практической точки зрения нередко когда Kill Chain используется при оценке эффективности Security Operation Center (SOC). Распределение обнаруженных и нейтрализованных атак по их стадии - это одна из метрик SOC. Логично предположить, что чем раьнше мы обнаруживаем направленные против нас действия злоумышленников, тем эффективнее работает наша система защиты.

ЗЫ. О применении Kill Chain в работе Security Operations Center мы будем говорить 16 ноября на втором ежегодном SOC Forum.

ЦБ требует от страховщиков заняться защитой от DDoS-атак

ЦБ подготовил требования к работе сайтов страховщиков и Российского союза автостраховщиков (РСА), направленные на обеспечение бесперебойности работы при продажах электронных полисов ОСАГО, и которые вступают в силу с 1 января 2017 года (именно тогда можно будет приобретать ОСАГО в электронном виде). Данный проект НПА продолжает серию документов Банка России по регулированию вопросов обеспечения бесперебойности функционирования различных систем. У ЦБ, например, уже был документ по обеспечению беспоробойного функционирования платежных систем. И вот новые требования уже для страховщиков.

Хотя в заголовке данной заметки говорится о DDoS, на самом деле ЦБ говорит о любых причинах, которые могут повлечь за собой нарушение функционирования сайта страховщика. Это могут быть и обычные атаки, и DoS (а не DDoS), и проблемы с обработкой форм на сайте и т.п. Но поскольку речь идет именно о сайтах, то первой угрозой для них будет именно DDoS. Согласно требованиям ЦБ, сайт страховой компании не должен простаивать более 4-х часов в месяц. Простой сайта более 2-х минут уже считается нарушением! 2 минуты!!!! Если нарушение, приведшее к недоступности сайта, не устранено в течение 2-х часов, то это нарушение считается критическим.

Помимо применения технических мер недопущения перебоев в функционирования сайтов от страховщиков также требуется (среди прочего):

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

Страховщикам стоит задуматься о внедрении различных технологий защиты сайтов от нарушения их бесперебойного функционирования - сканеры безопасности, Web Application Firewall (WAF или МСЭ типа "Г" по версии ФСТЭК), средства или сервисы по защите от DDoS-атак.

ЗЫ. Кстати, на февральском форуме по ИБ в финансовой сфере в Магнитогорске теме ИБ страховщиков будет уделено особое внимание.

Немножко последних изменений по ИБ в госорганах

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

• Министерство связи и массовых коммуникаций РФ опубликовало проект постановления правительства «О внесении изменений в Требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Сами требования были разработаны еще в 2015-м году в соответствие с ФЗ-149 и в целях повышения качества государственных информационных систем за счет установления методологического единства требований к стадиям их жизненного цикла. Из крупных изменений можно отметить запрет на ввод в эксплуатацию ГИС, если в реестре территориального размещения ИС нет сведений о размещении технических средств информационной системы на территории РФ (в соответствие с поправками в ФЗ-149, ступившими в силу с 1-го июля 2015 года). В документе добавился новый этап создания ГИС - формирование требований к системе и требований к защите информации, содержащейся в информационной системе. Также во все разделы документа включены требования по обеспечению защиты информации на всех стадиях жизненного цикла ГИС, включая формирование требований по защите информации, разработку и согласование технического задания на систему с ФСБ России и ФСТЭК России в части, касающейся требований по защите информации и модели угроз безопасности информации, аттестации государственной информационной системы по требованиям защиты информации, разработки и утверждения организационно-распорядительных документов, определяющих мероприятия по защите информации в ходе эксплуатации системы.
• В мае прошлого года я писал про 260-й Указ Президента и вот ФСО, спустя год, выпускает проект своего приказа, который будет регулировать работу российского государственного сегмента информационно-телекоммуникационной сети «Интернет». Приказ очень рамочный и по сути ничего конкретного не определяет (в отличие от предыдущих приказов ФСО на ту же тему) - все определяется соглашением о подключении к RSNet (там же прописаны и требования по ИБ).
• Постановление Правительства от 13 августа 2016 года №789 установило порядок использования простой электронной подписи при обращении за получением государственных и муниципальных услуг в электронной форме с помощью мобильного телефона, смартфона, планшета и порядок передачи результатов оказания государственных и муниципальных услуг в электронном виде третьим лицам.
• Минкомсвязь выложило проект Указа Президента "О создании и функционировании специального сегмента системы межведомственного электронного взаимодействия в целях обеспечения обмена между органами власти, государственными внебюджетными фондами и организациями информацией, доступ к которой ограничен", суть которого понятна из названия. Вместо того, чтобы все-таки принять закон "О служебной тайне" принимаются совершенно непонятные по сути нормативные акты, как упомянутый Указ Президента. Вот на обработку какой информации он рассчитан? Персональные данные - это тоже информация ограниченного доступа. И что, их тоже надо будет засунуть в отдельный сегмент СМЭВ? А что тогда останется в СМЭВ? И как это связано с проектом создания отдельной защищенной сети связи для госорганов, физически отделенной от общей сети, которую хотел замутить СовБез на базе Ростелекома?
• Наконец, 21-го июля Президент дал поручение Правительству для повышения безопасности и устойчивости работы информационных систем органов государственной власти обеспечить разработку и внесение в Госдуму федерального закона о преимущественном использовании государственными органами единой инфраструктуры электронного правительства. По сути речь идет о пресловутом Гособлаке, которое пытались завести уже неоднократно. Тут и Указ Президента от мая 2015-го года, и последовавшее за ним в октябре распоряжение Правительства. Но что-то не заводится - приходится Президенту давать очередное поручение Правительству ускориться. Видно не хотят у нас переходить на единую и унифицированную инфраструктуру.

PS. На глаза еще попадал НПА, в котором среди прочего упоминался аутсорсинг ИБ в госорганах, но что-то я его не нашел, когда писал эту заметку.

Тройка интересных переводов по безопасности критических инфраструктур

Сначала думал закинуть эти ссылки в Twitter, но подумал, что эти документы достойны заметки в блоге. Все-таки не часто иностранцы переводят на русский язык свои документы, да еще и по информационной безопасности. И если производители еще могут пойти на это и часто делают, то от национальных регуляторов такое видеть очень показательно.

Итак, первый документ - от Schneider Electric. 110 страниц подробных рекомендаций по кибербезопасности промышленных систем. Безусловно, есть ориентация на продукцию Schneider, но много и вендор-независимых рекомендаций.

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

А вот третий документ оказался для меня вообще неожиданным. Это концепция мер по защите критической инфраструктуры Германии. На русском языке! Я могу понять Schneider. Я могу понять ОБСЕ. Я мог бы понять даже ENISA, хотя в Евросоюзе русский не является одним из основных языков. Но Германия? Зачем переводить национальный документ на язык потенциального противника (если судить по СМИ)? Но в любом случае документ хороший. Может в будущем и другие немецкие документы по критической инфраструктуре переводут - у них отличная подборка по этой теме.

Куда делся Havex?

Помните фильм "Комедия строго режима"? Есть там такой смешной фрагмент:

  

Так вот он мне напомнил ситуацию с нашумевшим в свое время вредоносным кодом Havex, участвующим в кампании Dragonfly, направленной против промышленных систем. Данная кампания датируется концом 2010-го - началом 2011-го года, но публично о ней заговорили только в июне 2014-го года, когда финская F-Secure опубликовала у себя в блоге заметку о вредоносном коде Havex, который занимался разведкой и поиском промышленных систем. Позже Symantec опубликовала детальный технический отчет по Dragonfly и потом эта информация попала в СМИ, которые и стали в течение всего лета 2014-го года эксплуатировать тему нового и уникального вредоносного кода, который, по сути, был вторым серьезным экземпляром (после Stuxnet), ориентированном именно на промышленные системы.

Havex, также известный как Backdorr.Oldrea или Energetic Bear RAT (любят иностранцы медведей - то Energetic Bear, то Fancy Bear, то Cozy Bear). Заражая компьютеры жертв через почтовый фишинг, заражение промышленного ПО и веб-сайтов, Havex смог заразить по открытой информации около 2500 жертв. И основной задачей Havex было не выведение из строя промышленных систем (как у Stuxnet), а сбор информации - о зараженной системе, о OPC-сервисах, об используемых промышленных протоколах в сети. И вот тут начинается самое интересное. С конца 2014-го года о Havex перестали писать так, как будто его и не было или у всех наступила амнезия.

История появления разных версий Havex (по данным Belden) 

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

Но почему же с конца 2014-го индустрия хранит полное молчание об этом вредоносном коде? Ведь для кого-то разведывательная информация собиралась? Вариантов такого молчания я вижу два. Или Havex - это наш компьютерные "вирус Эбола", который очень быстро возник в СМИ и также быстро сошел на нет после того, как было выделено немалое количестве денег на борьбу со смертельной угрозой, которая должна была угробить весь мир (так про Эболу писали журналисты). Или кто-то дал команду молчать про Havex, который незапланированно вырвался на страницы СМИ (не могла же финская F-Secure знать, что публиковать про Havex ничего не надо). И какой из двух версий отдать предпочтение я пока не знаю. Первая вполне реальна, но непонятно, кто тогда нажился на этой "пустышке"? Каких-то серьезных денежных вливаний ни от кого в эту тему не было. Вторая версия предполагает наличие мирового закулисья, которое может дать команду прекратить писать об опасных темах и все ведущие СМИ и компании возьмут под козырек. Можно было бы предположить, что за всем этим стоят США, но именно там по данным Лаборатории Касперского и зафиксировано максимальное количество жертв Havex (а в России ни одной).

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

ЗЫ. Кстати, если прогнать через VisrusTotal хеши участвующих в кампании Dragonfly файлов, включая и Havex, то картинка получается интересная. Не все ловят :-(

Атрибуция кибератак

Вчера мне довелось выступать на мероприятии, организованном Российским советом по международным делам в партнерстве с Институтом "Восток-Запад". Тема была выбрана непростая - "Сотрудничество России и США по противодействию киберпреступности и защите критической инфраструктуры", что на фоне субботнего выступления Лаврова выглядело достаточно странно. Ну о каком сотрудничестве можно вести речь, когда США постоянно и бездоказательно обвиняют Россию в кибератаках на "все, что движется"?

В рамках встречи обсуждались вопросы взаимодействия России и США в области противодействия киберпреступлениям и террористическим атакам во всемирной сети, нормы поведения в киберпространстве, а также возможность разработки совместных документов на межгосударственном уровне. Уровень участников был достаточно высокий - бывший министр иностранных дел Иванов, представитель президента по вопросам ИБ Крутских, советник министра внутренних дел Овчинский, вице-президент ICANN Якушев и другие эксперты, представлявшие МИД, ПИР-Центр, РАЭК, Интерпол, Центр Карнеги, ОДКБ, МГИМО и т.д. С "того берега" присутствовали президент и вице-президента института "Восток-Запад" и старший юрист Microsoft.

Дискуссия получилась неоднозначной, но в целом неплохо отражающая текущую картину мира. Много разговоров о том, что "надо делать" и о том, "почему не получается". Но все сходились во мнении, что до окончания президентских выборов и инаугурации о чем-то конкретном говорить не приходится. Нет сейчас уверенности в том, что все двусторонние соглашения, что уже заключены между США и Россией, будут подтверждены новым Президентом США. Хотя оптимизм у выступающих присутствовал, а учитывая уровень выступавших, они часто вдавались в воспоминания о том, как это было "тогда" и что даже в условиях холодной войны, бомбардировок американцами Югославии, между странами было взаимодействие - либо напрямую, либо через Интерпол. Поэтому есть надежда, что несмотря на все политические заявления здравый смысл у специалистов двух стран возобладает и практическое сотрудничество в сфере борьбы с киберпреступностью, с кибератаками на критические инфраструктуры и в военной сфере продолжится.

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

Я на мероприятии делал краткое (всем давали по 10 минут) выступление про атрибуцию кибератак. По сути я свою большую статью для ПИР-Центра вложил в 14 слайдов, чтобы показать, что голословные утверждения американцев о "русском следе" - это не более чем геополитика. При наличии технических методов атрибуции кибератак, их мало кто применял в последних нашумевших взломах демократов, WADA, американских СМИ и т.п. А может быть применяли, но боятся показать результаты, которые будут отличаться от уже озвученных и считающихся незыблемыми.

Атрибуция кибератак from Aleksey Lukatskiy

Что я жду от Думы №7?

Дума №6 закончила свою работу и бывшие народные избранники со спокойной совестью разъехались по домам. Новые депутаты, “бьющие копытом” в своем желании помочь простому российскому гражданину жить лучше и безопаснее, скоро приступят к своим прямым обязанностям. Их яркой законотворческой деятельности нам осталось ждать совсем недолго - скоро они получат свои удостоверения и пропуска, обкатают служебные и пока еще неимпортозамещенные автомобили, обживут новую жилплощадь. И вот тогда мы столкнемся с целоя плеядой законопроектов, которые должны превратить нашу планету, ну или хотя бы наше государство, в мечту всех утопистов и фантастов, начиная с Томмазо Кампанеллы. Я же жду от седьмой волны всенародно и честно избранных депутатов принятия горячей пятерки нормативных актов, имеющих прямое отношение к информационной безопасности:

• Поправки в “закон Яровой” в контексте средств шифрования. Хотя поправки - это достаточно оптимистично звучит. Скорее хотелось бы увидеть обещанные подзаконные акты в виде Постановления Правительства и различных приказов ФСБ, четко разясняющих, как выполнять бредятину, принятую прошлой Думой.
• Поправки в трехглавый закон “Об информации…” в части усиления мер защиты в госорганах. Речь идет о том, чтобы распространить требования 17-го приказа (и вообще требования ФСТЭК), не только на госорганы и муниципальные учреждения, сколько на любую организацию, обрабатывающую информацию, обладателем которой является государство. Вторая часть этих поправок должна обязать госорганы сообщать об инцидентах в ФСТЭК и ФСБ, что заставит их пересмотреть свою систему обеспечения ИБ и постепенно уходить от подхода к ИБ "пройти аттестацию, а после хоть трава не расти".
• Поправки в закон “О персональных данных”, связанные с реформой европейского законодательства. Тут пока все очень туманно, но и Дума у нас выбирается на 5 лет. За это время решение какое-нибудь да примут. Все-таки мы пока еще входим в Совет Европы и по словам РКН, планировали гармонизировать свой ФЗ-152 с новыми европейскими документами. А там тоже немало интересного есть. Тут и изменение правил работы с ПДн в электронных коммуникациях и Интернет. И уведомление об инцидентах с ПДн. И обязательные требования по защите ПДн. И увеличение штрафов (РКН уже как-то пытался ввести процентный подход). 
• Поправки Центробанка, связанные с борьбой с киберпреступностью. Это давняя история - ЦБ пытается уже года два внести поправки в УК, УПК и ряд других законопроектов, уточняющие и место совершения киберпреступления, и процедуру его расследования, и порядок обмена информацией о киберпреступниках, и т.п. Возможно этот созыв сможет принять этот пакет поправок. 
• Законопроект о безопасности критической информационной инфраструктуры (КИИ). Ну тут я лишний раз подтвержу свою позицию, что по моим сведениям этот законопроект почил в бозе и к нему уже возврата не будет в том виде, в котором мы его знаем с 2013-го года. По версии коллег к нему должны были вернуться осенью. После екатринбургского "Коба ИБ" вспылал дата "не раньше 2018-го года", то есть после выборов Президента. По сути это означает, что законопроект по безопасности критической инфраструктуры превращается в законопроект по служебной тайне, по штрафам за ПДн, законопроект Гаттарова-Матвиенко. Они как бы и есть и даже в Госдуму внесены, но висят там мертвым грузом. Вот боюсь, что и с этим законопроектом ситуация схожая. Хотелось бы ошибаться (закон на эту тему нужен), но пока я пессимистичен в этом вопросе.

ЗЫ. А пока депутаты приняли в первом чтении законопроект, наделяющий Минкомсвязь правом надзора в области ПДн.

Чеклист проверки этичности любого действия

Закончим неделю очередной, на этот раз краткой, заметкой об этике. В книжке "Этика для каждого" (Ethics 4 Everyone) есть простой чеклист для проверки этичности своих поступков (проверять лучше ДО, а не ПОСЛЕ). Достаточно ответить себе на ряд вопросов:

• Это законно?
• Это согласуется с нашими правилами и процедурами?
• Это согласуется с ценностями нашей компании?
• Это соответствует нашим заявленным обязательствам?
• Будет ли у меня чувство вины, если я сделаю это?
• Будет ли это делать самый этичный человек, которого я знаю?
• Сделал бы я это для своей семьи и друзей?
• Буду ли я чувствовать себя нормально, если кто-то это сделает в отношении меня?

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

Ну и раз уж я упомянул книгу про этику, то не могу не вспомнить и специализированную книгу для безопасников, которую можно скачать в Интернет:

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

Об этике CISO да и вообще любого специалиста по ИБ

В упомянутом вчера материале Reuters говорится, что, согласно неназванным источникам, запрос спецслужб вызвал отторжение у ряда высокопоставленных сотрудников Yahoo, некоторые из которых покинули компанию. Одним из них был Алекс Стамос, руководившей службой ИБ Yahoo. После Yahoo Стамос перешел на аналогичную должность в Facebook. Я не раз слушал Стамоса (и у нас в Cisco на внутренних мероприятиях, и на публичных конференциях) и могу сказать, что он очень грамотный и адекватный мужик, прекрасно понимающий реалии рынка ИБ. И вот ему становится известно о решении Yahoo передавать информацию спецслужбам в рамках действующего американского законодательства (интересно, раньше спецслужбы не обращались  что ли в Yahoo?). Он молча уходит из компании в Facebook, который, теоретически, ничем не отличается от Yahoo по части интереса для спецслужб. И только спустя год после его ухода, когда стало известно о соглашении между Yahoo и спецслужбами, упоминается, что Стамос ушел именно из-за этого. В соцсетях я видел уже немало хвалебных сообщений в сторону Стамоса. Мол, чувак поступил честно, как подсказывала совесть... И вот тут и возникает дилемма, которая и заставила меня написать эту заметку (если исходить из версии, что Yahoo действительно сливает данные в АНБ, а Стамос действительно ушел по этой причине, а не из-за того, что в растущей FB ему предложили больше денег, чем в угасающей Yahoo).

Насколько этично было со стороны Стамоса промолчать, уходя в Facebook, оставив миллионы пользователей своего бывшего работодателя в неведении относительно "нарушения" их прав на тайну переписки? Или надо было поступить как Сноуден и рубануть с плеча, выдав правду-матку в СМИ? Или надо было молча продолжать работать в Yahoo? Где та грань, после которой действия Стамоса могут считаться неэтичными? И могут ли они вообще таковыми считаться?

Сидеть и наблюдать со стороны за этой историей достаточно интересно и можно даже дистанцироваться от нее, пытаясь рассуждать об этике CISO. Должен он был или не должен раскрыть всем "заговор спецслужб против демократии"? Особенно легко рассуждать, когда у твоей компании нет вообще клиентов-физлиц и тебя эта ситуация может коснуться только в теории. Но каково должно было быть Стамосу, когда он узнал о решении Yahoo? Лично я не знаю, как бы поступил на его месте. Остаться, значит быть сопричастным и активно помогать (пусть и своим бездействием) ненавистным многим спецслужбам. Уйти в сторону, уволившись и выйдя на новую работу? Это принцип страуса, зарывающего голову в песок и живущего по принципе "моя хата с краю". Возможно. А возможно и нет. Громко кричать об этом на каждом углу и стать персоной нон-грата в США, как это произошло со Сноуденом или Ассанжем? Или персоной нон-грата у спецслужб, что означает будущие сложности в работе на такой роли, как у Стамоса (что в Yahoo, что в Facebook), где приходится контактировать со спецслужбами. Тихо  и анонимно слить весь компромат в WikiLeaks или СМИ и хоть так попробовать повлиять на ситуацию? Вопросов много, ответов нет. Точнее у каждого он будет свой.

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

Занимательный факт - 3 года назад, на 21-м DEFCONе, Стамос уже говорил об этой дилемме. Его доклад "An Open Letter - The White Hat's Dilemma: Professional Ethics in the Age of Swartz, PRISM and Stuxnet" был посвящен этой этической дилемме, кстати, применимой не только к CISO. Стамос на DEFCON говорил про White и Black Hat, про то, что мир поменялся и только в  фантастических романах он выглядит черно-белым, а в реальной жизни полно оттенков, которые и ставят многих специалистов перед дилеммой.

Выступление Стамоса было эмоциональном (выступал он как независимый эксперт) и изобиловало различными интересными примерами и философскими вопросами. Я взял их, расширил, и получил вот такой список (неполный, конечно):

• Можно ли продавать собранные данные клиентов рекламным компаниям за деньги?
• Можно ли читать личную переписку сотрудников и следить за их поведением в Интернет?
• Можно ли продавать собранные в рамках исследования ПО одного вендора уязвимости его конкурентам?

• Можно ли не сообщать клиенту о дырах в его системе защиты, если это не входит в scope работ?

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

• Можно ли манипулировать вендором, ссылаясь на "лучшие условия" от конкурента?
• Можно ли провоцировать сотрудников на нарушения для улучшения показателей своей работы?
• Можно ли неофициально заказать взлом своей организации, чтобы вынудить руководство задуматься о своей безопасности?
• Можно ли покупать уязвимости у Black Hat, провоцируя их и дальше заниматься своим черным делом?
• Можно ли держать на работе "хакера", который днем считает себя White Hat, а ночью подрабатывает Black Hat?
• Можно ли подсиживать своего руководителя, если ты считаешь себя умнее его?
• Можно ли оставаться программистом в компании, если вы знаете, что она встраивает закладки в свою продукцию по требованию спецслужб?
• Можно ли нарушить права одного человека, скрываясь за благом для большей группы людей?
• Можно ли участвовать в создании наступательного кибероружия?
• Можно ли участвовать экспертом в суде на стороне обвинения, зная, что ваша экспертиза может засадить человека за решетку на 3 года только на том основании, что в его логах есть факты посещения хакерских сайтов?

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

Сам же Алекс Стамос похоже предвидел текущую историю с Yahoo (если она действительно выполняла требования спецслужб в рамках американского СОРМ). На 21-м DEFCON он сформулировал этическую дилемму и для себя. Тогда он очень быстро проскочил этот слайд, но сейчас мы видим, что похоже он выбрал вариант C (возможно до этого был и B).

ЗЫ. Кстати, такой вот опросник - хорошая тема для какого-либо мероприятия по ИБ. Надо будет замутить где-нибудь...

Что скрывается за кейсом Yahoo?

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

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

Мне самому регулярно приходится комментировать различные новости из мира ИБ и я прекрасно вижу весь процесс работы журналиста (исключая получение первичной информации). Тебе присылают выжимку из документа или скриншот и спрашивают: "А вы что думаете?" Или тебе обрисовывают вербально кейс и задают вопрос, вокруг которого и будет строиться статья: "А возможна ли вот такая ситуация?" И ты отвечаешь, опираясь на свои экспертные знания. Они могут не совпасть с мнением и уже выстроенной картиной мира журналиста и он твою цитату даже не вставляет в итоговый материал. Хороший журналист вставляет эту отличную от его позицию как иную точку зрения. Но почти всегда твое имя фигурирует в материале и ты отвечаешь за свои слова. Если, конечно, ты не хочешь остаться анонимом в особо скользких темах (возможно кейс Yahoo именно такой?).

Если бы меня спросил журналист Reuters "А как вы думаете, может ли Yahoo "читать" переписку пользователей по требованию спецслужб?" я бы ответил примерно так: "Ни для кого не секрет, что почти в любой стране мира есть аналог отечественного СОРМ и спецслужбы хотят, разумеется в интересах национальной безопасности, мониторить электронные коммуникации в поисках следов террористов и экстремистов. И прописан этот аналог на уровне законов страны. И каждый резидент такой страны обязан соблюдать законодательство. Поэтому Yahoo и отвечает на запросы журналистов заученной фразой: "Мы законопослушная компания и соблюдаем законы США". А что им еще отвечать? Что они не будут выполнять законы США? Такого они ответить не могут. Прямо признать, что да, читали почту пользователей (пусть и по требованию спецслужб)? Ну так клиентов можно потерять, а их у Yahoo и так все меньше и меньше. Это классическая дилемма "интересы гражданина или интересы государства" и каждый решает ее обычно не в пользу гражданина".

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

А что за секретное требование? Если история имела место быть, а не журналист пересказывает слухи, полученные из третьих рук или призванные еще больше создать негатива вокруг бывшего гендиректора Yahoo и сделки  Yahoo/Verizon, то обычно известно, о чем идет речь. Возможно, это решение секретного суда FISС (Foreign Intelligence Surveillance Court или FISA Court), который выдает такие документы? А может это National Security Letter (NSL), например, от ФБР?

Что в итоге? А ничего :-) Из статьи в Reuters невозможно сделать никаких выводов - ее можно трактовать как угодно, в том числе и в негативном ключе, чем, собственно, все и занимаются.

Кибербезопасность в повседневной жизни (презентация)

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

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

Информационная безопасность в повседневной жизни from Aleksey Lukatskiy

В каких случах необходимо обязательное уведомление об инцидентах ИБ?

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

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

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

Итак, то, что уже находится на регистрации в МинЮсте - это новое положение Банка России "О требованиях к защите информации в платежной системе Банка России", в котором есть такой пункт: "10.1. Участники осуществляют информирование Банка России о выявленных инцидентах, связанных с нарушением требований к обеспечению защиты информации, (далее - Инциденты) на Участке ПС БР, в том числе о несанкционированных переводах денежных средств Участника через ПС БР, подозрениях о возникновении или о возможности возникновения Инцидентов на Участке ПС БР. Информирование осуществляется в произвольной форме на электронный адрес fincert@cbr.ru, либо инициируется запрос на передачу этих сведений с применением мер и средств защиты информации, не позднее трех часов, после выявления Инцидента".

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

Два других новых "старых" документа будут обязывать уведомлять об инцидентах госорганы. О поправках в ФЗ-149 говорилось на недавней InfoSecurity Russia, а сам законопроект давно выложен в Интернет.

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

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

Оставшихся два сценария принесла нам заграница; точнее может принести. Речь идет о новых требованиях по безопасности SWIFT, которые будут доведены до всех участников этого платежного сервиса в октябре, и о новых требованиях Совета Европа в части защиты прав субъектов персональных данных. По SWIFT сказать пока ничего не могу - не видел документов, да и мало они будут привязаны к России - это общее требование, как у той же Visa. А вот с персданными ситуация интереснее. Россия, как сторона Совета Европы, должна будет гармонизировать свое законодательство с новыми европейскими правилами по защите прав субъектов ПДн, в которых говорится об обязанности оператора ПДн сообщать в уполномоченным орган об инциденте с ПДн субъектов. С одной стороны РКН готовился вносить поправки в ФЗ-152, связанные с реформой европейского законодательства, а с другой - РКН все время дистанцировался от того, чтобы получать информацию об инцидентах от субъектов. Во время обсуждения законопроекта на эту тему пару лет назад представители РКН прямо заявляли, что им нафиг не сдалась эта обязанность и они не хотят заниматься регистрацией и обработкой инцидентов с ПДн. Посмотрим, чем это закончится.

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

ЗЫ. Планируется, что на приближающемся SOC Forum этому вопросу посвятят отдельную секцию.

Кибербезопасность промышленного Интернета вещей (презентация)

В прошлую среду открывал поток по Industrial Internet of Things на форуме "Интернет вещей". Обычно с безопасности такие мероприятия не начинаются (зачем пугать раньше времени), но тут все было по-другому :-) Так что не знаю, с каким ощущением останутся участники мероприятия, услышавшие, что с безопасностью в Интернете вещей все не очень хорошо и нас еще ждут различные потрясения, если они, разработчики, не задумаются об этой задаче.

Кибербезопасность промышленного Интернета вещей from Aleksey Lukatskiy

Но, видимо, я озадачил некоторых, так как после меня выступал представитель одного из разработчиков, так как после презентации он начал с ответа мне такой фразой: "Мы живём не в идеальном мире с единорогами"... Что он имел ввиду я так и не понял; так и улетел в командировку в полном недоумении :-)