25.1.19

Анализ реестра сертифицированных ФСТЭК в 2018-м году средств защиты информации

Вчера на портале anti-malware.ru вышла первая часть обзора российского рынка ИБ, которая вызывает лично у меня вопросы (у 63% компаний в России бюджет на ИБ меньше 500 тысяч рублей????), но которая при этом ставит перед собой цель проанализировать общее (и оно, судя по отчету, удручащее) состояние ИБ в нашей стране. Я же параллельно провел уже ставшее традиционным исследование реестра сертифицированных ФСТЭК в 2018-м году средств защиты информации.

Если сравнивать результаты с 2017-м годом, то может сложится впечатление, что ситуация хуже не стала, а местами даже лучше. Общее число выданных за год сертификатов выросло на 18%, а число сертификатов на иностранные решения выросло на 2%. Но на самом деле ситуация немного иная. Например, 77% всех сертификатов у "иностранцев" выдано на решения Cisco. Да, мне, как работнику Cisco, приятно видеть доминирование своей компании, но в целом картина получается той, которую я предсказывал в прошлом году - "иностранцы" уходят с рынка сертифицированных решений, не имея возможности соответствовать все более жестким требованиям регулятора. В списке сертификатов за 2018-й год я не увидел ни одного сертификата от Check Point или Fortinet, а они были достаточно агрессивны в части выполнения требований своих продуктов требованиям ФСТЭК в прошлые годы. Да, на продукты этих компаний действующие сертификаты еще есть, но не на текущие версии ПО (некоторое ПО уже не продается и не поддерживается).


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


С момента введения санкций против России и начала курса на импортозамещение прошло уже почти 5 лет. Достаточно большой срок, чтобы российские производители выпустили аналоги иностранным решениям по ИБ. Интерес со стороны заказчиков есть. Поддержа государства (не деньгами, так нормативкой) тоже есть. Конкуренция снижается. А рынок так ничем и не может заполнить возникший вакуум :-( Лидером по числу выданных сертификатов является направление межсетевых экранов, коих получено 22% от общего числа бумажек с голограммой. В то время как весь мир уже давно бороздит мировой океан движется в сторону прикладной ИБ, занимается решениями по ИБ на блокчейне и искусственном интеллекте, борется с целевыми угрозами, мы по-прежнему основную ставку в защите делаем на межсетевые экраны :-( Правда, стоит снова отметить, что 78% сертификатов на МСЭ выдано на продукцию Cisco. А вот сегмент, который рванул с прошлого года - это системы обнаружения вторжений - их стало больше в три раза. Причем 78% всех сертификатов - это российская продукция. Это, на мой взгляд, тоже объяснимо. Бери иностранные Snort, Surricata или Bro и строй на них "свою" IDS. Затрат минимум - один профит. Можно даже сигнатуры свои не писать, а брать чужие.


Еще ряд интересных наблюдений - из сертифицированных ОС (а их 4), три были иностранного происхождения. Некоторые решения по старинце сертифицировались как СВТ, хотя являлись по сути либо средствами защиты базами данных, либо операционными системами. Кстати, средств защиты СУБД, сертифицированных по ТУ или НДВ, было больше одного (4, если быть точнее). Новый WAF в реестре появился только один, средств защиты виртуализации - три, средство анализа кода - одно, недоSIEM (от СерчИнформа и Ankey) - два, средств анализа защищенности - тоже два.

Кстати, мне можно возразить, что отсутствие новых сертификатов в 2018-м году может означать, что решение было сертифицировано в 2017-м и поэтому, при сроке действия сертификата в течение 3-х лет, оно не требует обновления бумаги от регулятора. Отчасти это так, но... А как же новые версии ПО? Или их за год так и не появилось?

Новых выводов не будет - сделанные год назад подтверждаются. Иностранные решения из сегмента сертифицированных выживают, российских решений больше не становится; закрыть все потребности заказчиков и все пункты из 17/21/31/239 приказов они не могут. Что делать заказчикам, не совсем понятно. Остается вспомнить только птицу Говоруна из мультфильма "Тайна третьей планеты": "Держаться нету больше сил..." :-)

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

22.1.19

Почему хостовые средства защиты не так хороши, как их описывает Сергей Солдатов :-)

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

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

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


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

Третий пример. Вы внедрили у себя средство мониторинга DNS-трафика, которое позволяет вам не только обнаруживать существующие, но и предсказывать будущие DGA-домены, с которых могут быть осуществлены атаки против вашей инфраструктуры. Данное средство не только идентифицирует опасные домены и командные сервера, но и связанные с ними вредоносные семплы. Вам нужно проверить, не встречались ли в вашей инфраструктуре данные семплы? И сделать это можно только путем интеграции сетевой и хостовой безопасности (защитный агент должен в этом случае обладать функцией threat hunting). Одно хостовое решение будет долго ждать, когда до них будет доведена эта информация в ручном режиме.

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


ЗЫ. Отчет Forrester с приведенной выше статистикой о важности автоматизации и интеграции средств защиты можно скачать тут.

17.1.19

Что общего между ИБ и кухней?

Есть три вещи, которые меня раздражают в российских новогодних праздниках - безделье (но я научился с ним бороться), фейрверки в новогоднюю ночь до 4-х утра и бесконечная еда (кого-то еще раздражает постоянные возлияния горячительными напитками, но не меня). Вот про еду мы сегодня и поговорим :-) Когда-то я написал несколько заметок, которые проводили параллели между ИБ и ремонтом, поясом верности, женщиной, медициной, футболом, автомобилем и, наконец, фауной. Это было несколько лет назад и я решил вернуться к теме аналогий, проведя параллели между ИБ и кухней.
  1. Вы готовите блюда. Будучи шеф-поваром, ваша задача приготовить блюдо, которое устроит ваших клиентов, имеющих совсем разные вкусы и разные потребности. Так и в ИБ - ваша служба должна удовлетворить их все. У кого-то изысканный вкус, у кого-то его и вовсе нет; кому-то нужны специфичные блюда по ИБ, а кого-то устроит и обычный фастфуд. При этом именно шеф службы ИБ отвечает за все.
  2. У вас должно быть меню. Когда вы приходите в ресторан, вы врядли самостоятельно набираете ингредиенты и указываете поварам, как их готовить (хотя такие фишки у ресторанов бывают). Вот и в ИБ вам нужно меню, в котором будут ваши фирменные блюда, то есть сервисы ИБ, которые должны удовлетворять потребности клиентов. При этом, в зависимости от "высоты" вашей кухни у вас будут либо только типовые "блюда" - борьба с DDoS, контроль утечек, защита периметра, антивирус и т.п., либо вы сможете приготовить и рецепты высокой кухни - безопасность промышленных систем, защита ERP, BYOD, DevSecOps и т.п.
  3. Вам нужны правильные ингредиенты. Качество ваших блюд зависит от ингредиентов - их качества, свежести, количества. А что является ингредиентом в ИБ? Данные, которые позволяют принимать нужные решения - события ИБ, инциденты, атаки, потоки, транзакции и т.п. От того, насколько они полны и вовремя поданы и будет зависеть ваше блюдо. Вот нет у вас событий с облачной инфраструктуры и вкус вашей безопасности уже не тот. А если у вас Netflow, то в вашем меню будут отсутствовать "блюда", связанные с внутренней ИБ. Важную роль играет и комбинация этих ингредиентов. Например, данные от оконечных устройств, скоррелированные с данными Netflow, взятые с существующей сетевой инфраструктуры, позволяют детектировать сложные атаки, а решения UEBA так и вовсе не могут функционировать без набора разных данных - от ПК, сети, СУБД, приложений и т.п.
  4. Вам нужны квалифицированные повара разных специализаций. Вы смотрели сериал "Кухня"? Там повара имеют свою специализацию - кто-то кондитер, кто-то по мясу, кто-то по рыбе специализируется. В других ресторанах есть также сомелье, бариста и даже вителье (специалист по сигарам). В ИБ все тоже самое - для приготовления правильных блюд нужны специалисты разного профиля - аналитики, криптографы, писатели политик, реверсеры малвари, специалисты по расследованию и реагированию на инциденты и т.п. И все они должны быть квалифицированными и, более того, регулярно повышать свою квалификацию и компетенции.
  5. Шеф-повар. Какие бы ингредиенты и повара у вас не были, кухню "играет" шеф-повар. Именно от него зависит, получит ваша кухня звезду Мишлена, не будет иметь наград, но будет славиться среди клиентов, или при наличии огромных ресурсов ваша кухня будет достойна только привокзальной столовки где-нибудь на перегоне на Кольском полуострове. Так и с CISO, от которого зависит правильный замес всех элементов - данных, безопасников, средств защиты и т.п. 
  6. Вам нужна правильная посуда! Правильная, а не дорогая или широко разрекламированная. Понятно, что иногда это синонимым, но все-таки эти понятия неравнозначны. Так и в ИБ - вам нужные разные инструменты для аудита, инвентаризации, построения векторов атак, моделирования угроз, блокирования и обнаружения разных типов атак, реагирования на инциденты, мониторинга и т.п. Недорогой инвентарь (open source) может быть компенсирован классным поваром, а слайсеры или наборы поварских ножей (SOAR, SIEM, UEBA, NTA, CASB и др.) могут нивелировать некоторые слабости поваров.
  7. Помещение. Кухня - это еще и помещение, от правильной расстановки мебели в которой, а также от вентиляции, освещения, давления, наличия окон и т.п. зависит очень многое. Помните, я писал про особенности дизайна и проектирования помещений для Security Operations Center (SOC)? Эта заметка неплохо показывает важность этих вопросов в обеспечении ИБ. Комнатушка, в которой толкутся и сидят на коленях друг у друга безопасники, явно не делает их работу легче (хотя и сближает).
  8. Рецептура. Моя жена говорит, что я достиг идеала в приготовлении шашлыка (мне и самому нравится :-) и это не случайно. Я не являюсь кулинаром от бога, просто строго соблюдаю рецептуру. Точное количество ингредиентов, точное время приготовления, точная последовательность действия, точная подготовка мяса и маринада. Вот и в ИБ самодеятельность и хаотичность вредят результату. Нужна книга рецептов ИБ, то есть то, что иностранцы любят называть словом Playbook и Runbook. Неслучайно в названии многих книжек по ИБ или презентаций часто используют слово cookbook (кулинарная книга) или recipe book (книга рецептов). Кстати, время приготовления блюда очень важно и в ИБ - долгое расследование или несвоевременное реагирование влекут за собой ущерб, нарушение сроков внедрения системы защиты также влечет за собой ущерб, нарушение сроков согласования договора может привести к прекращению срока действия лицензии на систему защиты и ее останову, то есть опять к ущербу.
  9. Анализ трендов. Вы замечали, что как и в модной индустрии, в ресторанном бизнесе есть свои течения, свои новинки, свои "горячие" блюда, которые вдруг появляются сразу во многих местах? Да, в кулинарии тоже важно отслеживать тенденции на рынке и своевременно им следовать их. В ИБ все тоже самое - анализ трендов по ту сторону баррикад (Threat Intelligence), тенденций в области технологий ИБ, в области законодательства и т.п.
  10. Вы гоняетесь за "звездами Мишлена". Люди (и организации) падки на похвалу и награды. Это касается шеф-поваров, ресторанов, директоров по ИБ и ИБ-проектов. У нас в отрасли нет своего "красного гида Мишлена", но зато есть различные отраслевые награды - SC Award, Best Security Blogger, Top100 CISO, "Маяк безопасности", ЗУБР, "Информационная безопасность банков" и т.п. 
  11. Проверки. Рестораны, как места общественного питания и обслуживания населения, постоянно проверяют - санэпидемстанция, налоговая, пожарники, и куча других надзорных органов. Да-да, вы поняли, куда я клоню. В ИБ тоже полно своих надзорных органов - ФСТЭК, ФСБ, РКН, ЦБ и др.
  12. Правильная подача. От того, как вы подадите свое блюдо (блюда) зависит отношение к вам клиентов. Их лояльность, их желание поделиться с вами деньгами и желание посещать вашу кухню снова и снова. Так и в ИБ - от того, как вы "продаете" свои блюда целевой аудитории (преимущественно руководству вашей компании) зависит судьба службы ИБ, ее статус и ее ресурсы. Помните другую мою заметку про мониторинг бизнес-показателей со стороны SOC? Она как раз об этом. 

Дюжина совпадений. На самом деле их гораздо больше. У ИБ вообще очень много схожего с различными сферами нашей жизни и деятельности. А тему кулинарии я выбрал неслучайно - дело в том, что именно она выбрана заглавной на весеннем CISO Forum, который так и называется "XII Международный Форум CISO FORUM: Кулинарная книга CISO". Мастер-классы от шеф-поваров, разговоры об ингредиентах, гастрономические клубы, кухни разных регионов мира, разнообразное меню, выставка инструментов... А в качестве вишенки на торте - настоящая кулинарная книга рецептов от руководителей служб ИБ российских предприятий. Кстати, если вы любите и умеете готовить, у вас есть любимые рецепты и вы готовы поделиться своей тайной с коллегами, то вы тоже можете поучаствовать в создании кулинарной книги рецептов CISO - присылайте свои рецепты организаторам мероприятия!

До встречи на CISO Forum!

ЗЫ. Я на CISO Forum планирую проводить киберучения и, возможно, будет еще что-то - пока есть время до мероприятия и формирования моих планов.

15.1.19

Впечатления от курса CompTIA Cybersecurity Analyst CySA+

Новогодние праздники достаточно длинны и их можно тратить на что-то более полезное, чем обжирание и пьянство :-) Вот и я, после чтения купленных на праздники книг по математике и регулярных коньков, перемежающихся расчисткой дорожек от снега на даче, решил пройти обучение. Давеча завершил я прохождение онлайн курса про программе CompTIA Cybersecurity Analyst CySA+ и хотел бы поделиться впечатлениями.


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


Этот курс, как написано в описании, дает глубокое понимание основ и принципов кибербезопасности. И в этом я целиком согласен с аннотацией. 21 час, 4 модуля, 17 уроков посвящены рассмотрению почти всех тем по ИБ - от kill chain до пентестов, от выбора защитных мер до обзора нормативки, от анализа различных защитных технологий до рассмотрения процесса реагирования на инциденты, от SDLC до SABSA.


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


Согласно аннотации курс относится к уровню Intermediate и я склонен с этим согласиться. Хотя по ряду тем курс ближе к pre-intermediate, а по ряду к post-intermediate.



Практики нет, но ряд заданий можно выполнять самостоятельно, повторяя за инструкторами, запускающими nmap, wireshark, SET и другие утилиты Kali Linux, демонстрирующими основные положения первой части курса. Во второй, процессной части, практики почти нет, что обусловлено материалом.

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


ЗЫ. Проходил курс на www.safaribooksonline.com в рамках корпоративной подписки. Экзамен не сдавал - необходимости нет. 

14.1.19

Крупные мероприятия по информационной безопасности на 2019 год

На прошлой неделе несколько человек спросило меня, буду ли я делать в очередной раз календарь мероприятий по ИБ на 2019-й год. Если честно, то я не планировал это делать, так как работа немного теряет смысл. Новые мероприятия появляются достаточно редко, уже проводимые не раз повторяются примерно в те же даты и на том же уровне, корпоративные мероприятия (а их становится все больше) ограничены для входа. Повторить мои прошлогодние перечни может любой желающий - для этого нужно всего лишь проапдейтить даты, взяв их с сайтов мероприятий. Ну да ладно причитать. Я запустил опрос на Facebook и результат оказался не в мою пользу :-)


В итоге пришлось повторить перечень мероприятий по ИБ, обновив в нем только даты. Новых в нем почти нет (разве, что Сберовские ICC и Offzone, а также промышленный и итоговый Коды ИБ). Скачать файл можно по ссылке на Dropbox (если вы не хотите обходить блокировки Роскомнадзора).



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

ЗЗЫ. Проект http://risc.events все-таки, похоже, умер - никакой активности ни на сайте, ни в его Твиттере я не видел давно. А жаль :-(

ЗЗЫ. Если будут новые, то буду обновлять только файл на Dropbox (на Slideshare поменяли правила игры и теперь там нельзя обновить файл - надо заливать новый).

11.1.19

Сертификат о прочтении моего блога и засчитывании его в качестве программы повышения квалификации по ИБ

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

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


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

10.1.19

2 новых примера повышения осведомленности

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


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

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

9.1.19

Блиц-обзор новостей по ИБ за прошедшие праздники

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

  • Число утечек продолжает активно расти и новогодние праздники не стали исключением - почти на всех материках (кроме Антарктиды) зафиксированы инциденты с персональными данными - в Австралии утекли данные работников правительства штата Виктория (еще в Австралии было 4 утечки, но не столь массовых), утечка у игровой компании BlankMediaGames, в Германии утекли персональные данные немецких политикой, включая и Ангелу Меркель, у американской металлургической компании украдены данные покупателей. Не обошли утечки и компании, занимающиеся безопасностью - произошла утечка данных 24 миллионов пользователей парольного менеджера Blur. Вообще, утечка данных десятков миллионов пользователей уже не представляет из себя ничего уникального - таких примеров уже десятки, а общее число утекших данных превысило 4 миллиарда записей и скоро достигнет общей численности земного шара. В 2019-м году эта тенденция только продолжится, о чем я уже писал в нашем корпоративном блоге на Хабре.
  • Эксперты отмечают рост внимания злоумышленников к провайдерам услуг и вот первый пример этого года - атака шифровальщиком Ryuk облачного провайдера Data Resolution.
  • Уязвимости
    • Очередная, но неплохая обзорная публикация о том, что Телеграм небезопасен
    • Злоумышленники стали использовать новую тактику для обхода антифишинговых средств - скрытие исходного кода фальшивых страниц с помощью пользовательских цeb-шрифтов
    • Zerodium поднял цены на скупку уязвимостей. Цена на дыры в iOS возросла до 2 миллионов долларов (рост на 25%), в WhatsApp - до миллиона (рост на 50%). Цена на RCE в Chrome цена выросла в 2,5 раза до полумиллиона долларов, а цена на RCE в Windows в 2 раза - до 1 миллиона долларов.
  • Новые тулы
    • Анонсирована новая децентрализованная платформа обмена Threat Intelligence на блокчейне - Polyswarm. Предполагается, что она будет отличаться от VirusTotal двумя моментами - привлечением независимых аналитиков вместо антивирусных движков и вознаграждением работы аналитиков.
    • Стало известно, что на грядущей RSA Conference АНБ откроет сообществу свой open source реверс-инжиниринговый тул GHIDRA, который упоминается в утечке Vault 7 на Wikileaks 
  • Новогодние праздники ознаменовались двумя отключениями Интернет в африканских странах, Конго и Габоне, в которых проходили демократические выборы.
  • Геополитика
    • В России задержали американца за получение секретных сведений на флешке от неизвестного лица (На флешке? В эпоху Интернета?). Считается, что этого "шпиона" будут менять на задержанную в США Бутину или на Сайпане Макаренко. После этого МИД выпустил предупреждение россиянам, о том, что стоит соблюдать остороность при поездках заграницу. Некоторые американские специалисты по ИБ уже написали в соцсетях, что они воздержатся от посещения России (даже те, кто и не планировал никогда сюда ехать) из-за опасности задержания с целью последующего обмена. Помимо нас и американцев в эпопею с задержаниями активно включился Китай, который, после задержания топ-менеджера Huawei в Канаде, задержал у себя на территории 13 канадцев. К ИБ это имеет мало отношения - тут чистая геополитика, но держать в голове этот факт при планировании поездок стоит. 
    • Вдруг на праздниках американцы стали активно обсуждают офицера ГРУ Нетыкшо и его в/ч, якобы замешанных в кибератаках на американскую демократию. В чем причина такого интереса разных специалистов к Нетыкшо я пока не понял - вроде никаких причин для этого нет - обвинения к нему американский Минюст предъявил еще летом 2018-го года.
    • Американские эксперты начинают прямо говорить, что кибервойна с Китаем гораздо опаснее "русских хакеров". Если с нами все предельно понятно и просто, то китайцы действуют медленно и незаметно, что гораздо опаснее. Кроме того, китайцы ставят перед собой цель мирового экономического господства, что делает их попытки кражи интеллектуальной собственности в США достаточно серьезными.
    • Американское сообщество разведывательных органов начинает кампанию помощи частным американским компаниям против угроз (преимущественно из киберпространства), исходящих от иностранных государств, в первую очередь Китая, России, Северной Кореи, Ирана. 
  • Япония ввела новый налог с выезжающих из страны по морю или воздуху, который пойдет на компенсацию затрат на сбор биометрии.
Еще в мое поле зрения только на праздниках попал канадский список защитных мероприятий, которые должны решить большинство проблем с ИБ. Этот список, выпущенный в октябре, идеологически схож с австралийским списком 4/8/35 мер DSD и американским CIS Controls (бывший SANS Top 20). Ничего нового, но все равно интересно :-)

28.12.18

Персональный чеклист безопасника на 2019 год

4 года назад я уже как-то обращался к идее составления новогоднего обывательского чеклиста по безопасности. Решил обновить тот список и ориентировать его больше на специалистов по кибербезопасности, которые могут не только обезопасить себя, но и сделать окружающий мир чуточку лучше, следуя теории малых шагов. Затрачивая немного усилий в течение года, можно сделать себя, близких и друзей безопаснее, а коллегам показать пример. Выкладываю скриншот для тех, кто не сможет зайти на Slideshare и скачать файл в формате PDF (хотя обычный плагин в Хроме, даже не VPN, решает эту задачу элементарно).








17.12.18

Утечка из Marriott/Starwood или 10 ошибок при уведомлении об инциденте

30 ноября Marriott International анонсировала, что неизвестные хакеры (позже появилась информация, что следу ведут в Китай, в государственные шпионские структуры) смогли взломать систему резервирования сети отелей Starwood, принадлежащей Marriott, и в течение 4 лет (еще до поглощения сети Starwood сетью Marriott) смогли украсть данные около полумиллиарда постояльцев, что может обойтись компании в десятки миллиардов долларов потерь. Цифра эта взята не с потолка. Marriott пообещала компенсировать смену паспорта тем, чьи паспортные данные могли утечь, а это без малого 327 миллионов постояльцев. При стоимости замены паспорта в 100$ компенсация может составить около 30 миллиардов долларов. Стоимость акций Marriott за последние две недели упала с 122 до 104 долларов, что тоже не самым лучшим образом сказывается на финансовом положении Marriott, которая вынуждена расплачиваться за проблемы Starwood, которую взломали еще до слияния с Marriott (тут, кстати, встает вопрос качестве Due Dilligence и делался ли при покупке аудит безопасности).

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


А пока я жду хоть какой-то ясности, я решил составит перечень типовых ошибок, которые делают компании, которые сталкиваются с инцидентом ИБ. Кстати, эта тема хорошо ложится на тему штабных киберучений, в рамках которых можно прекрасно отработать навыки коммуникаций во время серьезного инцидента ИБ. Итак, на мой взгляд, перечень типовых ошибок выглядит следующим образом:
  1. Скрытие инцидента. "Про то, что нас взломали, никто не узнает. Поэтому скроем это от всех". Это реально одно из самых типовых заблуждений, которое я нередко слышу во время киберучения или при встречах с заказчиками. Но, как показывает опыт, в последнее время с инцидентами сталкиваются все и поэтому глупо рассчитывать на то, что это удастся оставить в секрете. Вспоминая высказывание гендиректора Cisco Джона Чемберса (хотя это говорили многие): "Есть два типа компаний - те, кого уже взломали, и те, кто еще об этом не знает".
  2. Рассмотрение инцидента как ИТ-проблемы. "Это не проблема ИБ - это сбой в ИТ-системе". "Наш сайт не работает не из-за DDoS-атаки, а из-за блокировки Роскомнадзора". "У нас плановое обновление ПО". "У нас регламентные работы и поэтому система не позволяет переводить денежные средства". После скрытия инцидента, это вторая по популярности ошибка, которую допускают многие.
  3. Атака русских|китайских|иранских|северокорейских хакеров. Я не понимаю, чем это отмазка лучше других, но и она нередко звучит, когда надо переложить ответственность на кого-то, снимая ее с себя. Кто бы вас не атаковал, выстраивание системы защиты - это ваша обязанность и при моделировании угроз и нарушителей надо предусматривать такие вещи. Тем более, что используют и государственные, и обычные хакеры типовые методы. Миф о каких-то секретных знаниях "хакеров в погонах" сильно преувеличены, судя по всем обвинениям, которые сыпатся в последнее время против России, Китая, Северной Кореи или Ирана.
  4. Отсутствие плана. Самое худшее, чтобы понять как реагировать на инцидент, выяснять это во время инцидента. Когда проводятся киберучения - основная их задача - подготовиться к плохому и нештатному. И все это надо внести в план, в котором надо ответить на 4 ключевых вопроса - кто будет сообщать об инциденте, какую информацию, кому и когда. Клиенты? Подрядчики и партнеры? Правоохранительные органы? СМИ? Уполномоченные органы по защите прав субъектов ПДн (в письме Starwood указаны адреса всех европейских DPA, что является требованием GDPR, но, кстати, нет РКН)? Кто должен входить в команду, отвечающую за сообщение об инциденте? Маркетинг, PR, юристы…
  5. Преуменьшение инцидента. Не пытайтесь скрывать инцидент или вводить аудиторию в заблуждение. Мало того, что это не удастся, так это еще может быть и незаконно в разных странах мира (если у вас клиенты не только в России). Сокрытие может повлечь за собой дополнительные иски и ущерб репутации. Тот же Marriott поступил достаточно честно, сразу уточнив, что речь идет о 500 миллионов гостей Starwood. Да, это неприятно, но зато честно. А если бы они сообщили об утечек 50 миллионов и потом всплыли факты про еще 450 миллионов, то это было бы крайне негативно воспринято всеми. Можно попробовать заявить, что масштаб инцидента не понятен, но кто знает, как это обернется в будущем. Хотя тот же Facebook, когда у него утекло вроде как данные 50 миллионов учетных записей, заявил, что они не знают о реальном масштабе бедствия. 
  6. Задержка с уведомлением. Equifax и Marriott сообщили об инциденте спустя два-три месяца с момента его обнаружения. Вообще затягивать с этим не стоит. Скорость и четкость при инциденте имеют важнейшее значение. Часто задержка связана с тем, что жертва просто не понимает, что у нее пострадало; она не знает свой бизнес, свою инфраструктуру; а инвентаризацию проводило очень давно. Иногда это происходит потому, что службы ИБ или ИТ тратит много времени на расследование, не сообщая об инциденте руководству компании и не следуя плану реагирования и уведомления (если план вообще есть). В любом случае любая задержка должна быть обоснована и обусловлена требованиями правоохранительных органов (если вы обращаетесь к ним) или иными юридическими требованиями. Понятно, что и бежать в тот же день раскрывать все карты не стоит - нужно собрать достаточно информации, чтобы не выглядеть попкой, непонимающим, что происходит. Кстати, с уведомлением тоже есть отдельные нюансы. Marriott о своем взломе сообщил 30-го ноября, а я получил от них письмо только 12-го декабря. С чем это может быть связано? Представьте, что вам надо направить 500 миллионов уведомлений! Вы же сразу попадете во всем спам-базы и вас будут блокировать все средства защиты. Поэтому надо либо отправлять небольшими порциями, либо договариваться с владельцами соответствующи сервисов, чтобы вас не блокировали на время массовой рассылки. 
  7. Распространение слишком малого объема информации. Цель публичного уведомления об инциденте - не покаяться, а помочь клиентам защитить себя. Поэтому делитесь тем, что им поможет в этом. Если вас уведомили об инциденте, но не сказали, что делать, вы будете разочарованы. Marriott в своем письме предложил вот такой перечень (помимо контактов с DPA, правоохранителями, бесплатного доступа к WebWatcher /если вы гражданин США, Канады и Великобритании/ и компенсации замены паспорта):

  8. Распространение слишком большого объема информации. Мало информации - плохо. Много информации... Тоже плохо. Нужно найти баланс и раскрыть только то, что принесет пользу вам, вашим клиентам и акционерам. Не надо раскрывать то, что может навредить другим компаниям. Например, Equifax сразу раскрыла, что это кредитное бюро взломали через уязвимость в Apache Struts. Это заставило многих компаний понервничать, так как у них тоже была эта уязвимость и она не была устранена. Это давало хакерам преимущество. Вообще кейс с Equifax на сегодняшний день уже стал хрестоматийным - немалое количество отчетов на десятки страниц посвящено этой утечке. В разрабатываемом плане коммуникаций по результатам инцидентов надо указать, кому и в каком объеме должна быть представена информации. Понятно, что правоохранительным органам надо представить информации больше, чем для прессы. Клиентам нужны рекомендации по снижению ущерба, а агентству по расследованию инцидентов (Marriott, например, пригласил Kroll) эта информация без надобности. 
  9. Невзаимодействие с правоохранительными органами. В России не так уж и принято взаимодействовать с органами внутренних дел в случае того или иного инцидента. Недоверие к полиции и неверие в ее компетентность приводят к тому, что все пытаются с инцидентами бороться самостоятельно (исключая те случаи, в которых может понадобиться решение суда). На Западе ситуация иная - поэтому там как раз рекомендуется активно взаимодействовать с правоохранительными органами. И они во многих случаях сами расскажут, что раскрывать, а что нет, чтобы не навредить следствию. У вас всего один шанс, показать, что вы сделали все, что нужно для защиты себя и своих клиентов. Обращение в правоохранительные органы (как и привлечение какой-либо известной компании для расследования) - хороший тон и демонстрация того, что вы ответственно действуете в соответствие с лучшими практиками.
  10. Отсутствие киберучений :-) Да, это не совсем связано с уведомлением об инциденте ИБ, но именно отсутствие киберучений часто приводит к тому, что описанные выше девять ошибок совершаются. В процессе имитации реальных кейсов проявляются все подводные камни и формируются пункты будущего плана реагирования на инциденты и плана коммуникаций в случае их наступления.
ЗЫ. Почти три года назад я уже обращался к теме коммуникаций с внешним миром. Правда, тогда, я проводил аналогии с допинговыми скандалами в российском спорте. И как показали прошедшие годы я был прав. Шарапова вернулась в спорт, а остальные участники, описанные в заметке, - похоже нет. Так что даже в случае с произошедшем инцидентов можно извлеь правильные уроки и повернуть историю себе во благо. Было бы желание.

13.12.18

Занимательная нумерология ИБ или как манипулировать статистикой

В курсе по измерению ИБ есть у меня раздел, который называется "Как врать с помощью цифр ИБ", название которого является аллюзией на известное высказывание Дизраэли, популяризованное Марком Твеном "Есть три вида лжи: ложь, наглая ложь и статистика". В этом разделе я привожу несколько манипуляций, которые позволяют сформировать определенное мнение относительно демонстрируемых цифр, имеющих отношение к ИБ.

Один из примеров касается понятия "среднеестатистическое". Большинство под этим термином понимает "среднее арифметическое", которым многие ИБ-компании и консультанты манипулируют. Например, вы встречаете в каком-нибудь отчете тезис, что средняя сумма инцидента ИБ составляет 11 миллионов рублей (цифра взята с потолка). Авторы отчета умалчивают, что они имели ввиду под средним, но чаще всего они, недолго думают, просто делят сумму по всем инцидентам на число инцидентов. Является ли это действительно средним? Увы. В данной ситуации средним должна быть медиана - именно она наиболее точно показывает среднестатическую компанию. Давайте проиллюстрирую. Представим, что у нас 10 компаний сообщили об инцидентах ИБ. У 9 компаний размер ущерба составил 1 миллион рублей, а у десятой - 100 миллионов рублей. Среднее арифметическое будет равно 10.9 миллионам, а вот медиана - одному миллиону. И именно медиана отражает реальную картину с размером ущерба (только если у всех ущерб одинаковый, то медиана будет равна среднему арифметическому).


Другой пример "манипуляции" (цифры-то все верные), изменение размерности графика. На примере ниже показан именно такой случай. Достаточно всего лишь изменить размер по оси ординат (Y) и у вас сразу меняется отношение к цифрам - вы начинаете думать, что у вас колоссальный рост атак произошел за месяц, хотя на самом деле это не так.

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


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

И последняя манипуляция цифрами. "Ведомости", по отчету Лаборатории Касперского,  напечатали статью, согласно которой хакерским атакам подверглась половина компьютеров российской промышленности. Все в панике и бегут срочно покупать средства защиты информации. Специалисты по ИБ справедливо критикуют эти цифры, которые не отражают действительности. А все дело в грамотном пиаре и нежелании журналистов разбираться в подоплеке цифр. Ведь ЛК прямо пишет, что атакованными она считает только то есть компьютеры, на которых сработали их средства защиты. При этом число таких инсталляций она не сообщает. Что в итоге? Срабатывание 5 миллионов антивирусов на 10 миллионах компьютеров - это половина! Срабатывание 1 антивируса на 2 компьютерах - это тоже половина! Бинго! А в материале "Ведомостей" звучит устрашающе и руководство компаний начинает задумываться о своей безопасности. А после пресс-конференции Мурашова у всех уже не возникает сомнений, что Россия в круге киберврагов и надо усиливать кибербезопасность страны и подключаться к ГосСОПКЕ.

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

11.12.18

Какой крест по ИБ вам нести на своих плечах?..

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

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


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


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

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


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


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


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


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

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

Вот такая аллюзия родилась в пробке... Иногда это полезно; постоять, подумать... :-)

10.12.18

О киберучениях на SOC Forum

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


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


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


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

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


Обратил внимание, что многие участники не рассматривают в качестве одного из источников угрозы третьи лица, например, подрядчиков, поставщиков и т.п. В ситуации №4 я использовал кейс с подменой скрипта JavaScript на сайте подрядчика, с которого скрипт и загружался. Поэтому попытка вычистить скрипт с сайта гипотетической организации ни к чему не приведет - возможны повторные заражения. Такой сценарий активно использовался группировкой Magecart, которая активно действует до сих пор. British Airways, взломанная в сентябре, вообще была атакована, по одной из версий, через CDN, а не через основной сайт авиакомпании, что отследить было достаточно нетривиальной задачей.

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


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


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


Общее впечталение от учений высказал Дмитрий Кузнецов из Positive Technologies (он был участником одной из команд): "...участники не столько отыгрывали роль руководителя SOC, сколько демонстрировали свой кругозор ;)". Вот тут я согласен. Но отчасти это объясняется тем, что для многих участников киберучения - это забавное времяпрепровождение и возможность показать себя. Мало кто, пропускает кейсы через себя, свой опыт и свою организацию. Поэтому ответы звучат из серии "Мы должны...", а не "Я сделаю...". Ну и сам формат публичных киберучений тоже не подразумевает заточки под конкретную организацию, что размывает внимание аудитории, которая не видит в кейсах себя. В заметке про пять типовых ошибок в организации штабных киберучений я уже писал про это. Когда проводишь киберучения в конкретной организации и затачиваешь сценарий под нее, реакция немного иная.


Следующие штабные киберучения я планирую проводить (если все сложится успешно) на московском "Код ИБ. Профи" (28-31 марта) и CISO Forum (22-23 апреля). Разумеется, сценарии там будут иные, но формат тот же. Единственное, что там, я так думаю, не будет зрителей. Все-таки мероприятия платные и просто сидеть и смотреть на других, когда в соседних залах идут другие, интересные доклады,  будут немногие.

ЗЫ. Кстати, следующий раунд "Нашей игры" пройдет 18-го декабря. Учитывая грядущее 20-е декабря, то есть день сотрудников госбезопасности, мы решили посвятить эту игру регуляторам. Но так как "Наша игра" направлена на расширение кругозора, то мы не будем концентрироваться только на отечественных структурах, регулирующих вопросы ИБ, но посмотрим и на зарубежные, имеющие отношение к кибербезопасности, включая и криптографию. 

5.12.18

DNS и искусственный интеллект на страже кибербезопасности (презентация)

По приглашению ICANN выступал на вчера с keynote на восточно-европейском DNS-форуме (впервые в России ICANN проводит мероприятие) с темой применения искусственного интеллекта для мониторинга и защиты DNS-инфраструктуры. Вроде получилось неплохо. Выкладываю презентацию, а видео можно посмотреть на самом сайте.




29.11.18

Почему аналитики L1 в SOC бесполезны? (презентация)

Вчера выступал на SOC Forum с дискуссионной темой о бесполезности первой линии SOC. Докладу предшествовала дискуссия в Facebook, где мне высказывали позицию, что автоматизация (а я предлагаю именно ее взамен слабому человеку) не может решить все проблемы и человек все равно нужен. Спор бесконечный и у каждого участника есть свои аргументы за его позицию. На моей стороне около сотни построенных нашей компанией SOCов по всему миру и накопленная база знаний, а также большое количество исследований в области создания ситуационных центров или, как их часто называют в англоязычной литературе, Control Room. У оппонентов какие-то свои доказательства. Рассудит, как обычно, жизнь. Пока же наличие SOCов, опирающихся на аналитиков L1, не дает каких-то прорывов в ИБ у их владельцев. Атаки, уязвимости, реализованные инциденты, нанесенный ущерб. А аналитики первой линии работают - мониторят, эскалируют, передают на вторую линию, заводят карточки инцидентов... Каждый выбирает для себя.



26.11.18

Безопасность - это не право, а привилегия

В четверг довелось мне в рамках RIW модерировать секцию "Выбор пользователя: полная анонимность или полное доверие - поиск "золотой середины" в рамках мини-конференции "Большие данные и приватность в интернете", которая изначально планировалась как площадка для дискуссии по теме Big Data. В процессе подготовки к мероприятию я столкнулся с интересной дилеммой - в мире Big Data - это в первую очередь технологии, а в России - законодательство. Отсюда и некоторая рассинхронизация в дискуссии, которая предсказуемо скатилась в обсуждение персональных/пользовательских данных. Одним из рассматриваемых кейсов я взял известную летнюю историю про индексацию Яндексом документов Google. У участников дискуссии я спросил: "Кто несет ответственность за то, что произошло?" и вот тут меня поджидал некоторый сюрприз.

Представители Яндекса и Group-IB высказали мысль, что спасение утопающих - дело рук самих утопающих, то есть виноват сам пользователь. Отчасти я, конечно, согласен с тем, что пользователи должны чуть более внимательно относиться к настройкам приватности того, что они выкладывают в Интернет. И касается это не только документов, но и профилей соцсетей, фотографий, переписок в мессенджерах и т.п. И вот тут в дискуссию вступил Георгий Грицай из АНО "Цифровая экономика", который высказал, показавшуюся мне сначала крамольной, мысль, что безопасность - это не право, а привилегия и ее надо заслужить или оплатить. Иными словами, Интернет-компании не обязаны тратить все свои силы на безопасность пользовательских данных, а пользователь будет сидеть и ничего не делать, ожидая, что провайдер Интернет-услуг все сделает за него. Конечно ничего не делать тоже можно, но тогда надо переложить всю ответственность на кого-то.

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


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

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

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

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

ЗЫ. Презентация-подстрочник, как иллюстративный ряд к дискуссии на секции.