Почему на российских мероприятиях по ИБ мало выступлений от заказчиков?

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

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

1. Технологическая отсталость. Не секрет, что Россия, до недавнего времени активно строящая свои системы защиты опираясь на compliance, а не на требования реальной безопасности, была достаточно отсталой в технологическом плане. Завися от требований ФСТЭК, заказчики использовали антивирусы, межсетевые экраны, шифраторы, средства защиты от НСД и системы идентификации и аутентификации пользователей. Вот и весь джентльменский набор. С выходом 17/21-го приказов ФСТЭК ситуация сдвинулась с мертвой точки и в арсенале отдельных заказчиков стали появляться WAFы, SAST/DAST-сканеры, SIEMы и другие нишевые продукты. Но произошло это не так давно и называть это мейнстримом пока нельзя. Не знаю, насколько я прав, но думаю, что 80% компаний до сих пор используют вышеупомянутый джентльменский набор, а то и еще меньший состав решений по ИБ. В такой ситуации докладчик боится выглядеть глупо и архаично на фоне таких монстров как Qiwi, Вымпелком или Газпромбанк, которые не стесняются рассказывать о своем богатом опыте применения различных, в том числе и новомодных технологий. 
2. Неумение говорить. Об этой причине я уже высказывался не раз, но повторюсь. Очень мало кто из потенциальных спикеров когда-либо проходил курсы по так называемым presentation skills. Даже у вендоров докладчики не всегда умеют говорить красиво и доходчиво. А уж со стороны потребителей умение выступать - это еще большая редкость. На Западе же ситуация иная - искусству презентовать учат в университетах и почти каждый выпускник умеет это делать, продолжая оттачивать свое мастерство на работе (без этого сложно двигаться по карьерной лестнице). Вот сегодня я слушал представителей разных внутренних подразделений Cisco (разработчики, ИТ, ИБ, тестировщики, CSIRT и т.п.), которые не ориентированы на общение с заказчиками. Они выступали для своих, таких же как они. Но при этом они все умеют выступать. Не сбиваются, не мямлят, не бурчат себе под нос, соблюдают временные рамки, делают сбалансированные презентации. Их слушать не только интересно, но и приятно. У нас такое редкость и потенциально интересные спикеры боятся выходить на публику, даже если им есть, что сказать.
3. Нежелание говорить. Основной же проблемой российского рынка ИБ-мероприятий является низкая зрелость докладчиков со стороны заказчиков, которые не считают необходимым делиться своим опытом и знаниями с коллегами. Дело тут не в принципе security through obscurity, которым можно было бы обосновать нежелание выносить на публику аспекты построения систем защиты на своих предприятиях (хотя и это тоже присутствует), а именно в непонимании того факта, что отдавая что-то (знания, опыт), можно получить еще больше. Почему-то у нас часто грамотные ИБшники, которым есть, чем делиться, и которые знают, как это все донести до аудитории, не хотят выступать, отвечая на предложение программных комитетов классическим "А зачем мне это надо?" или "Я занят; мне некогда". На Западе такое тоже присутствует (а где этого нет?), но уровень зрелости европейских и американских спикеров "от сохи" все-таки гораздо выше российского. У нас спикер после доклада часто сваливает "на работу", а на той же RSA Conference или SANS или иных западных мероприятиях, докладчики остаются и с охотой отвечают на вопросы слушателей. И это еще хорошо, если "наш" просто торопится на работу; бывают и просто вопиющие случаи. Например, "и швец, и жнец, и на дуде игрец" в своем выступлении говорить полную банальщину, а на просьбу все-таки рассказать чуть подробнее отказывается, ссылаясь на коммерческую тайну, ноу-хау и нежелание делиться тем, что самостоятельно изучал в течение нескольких лет. Так какого хрена ты тогда вообще выступал? Поторговать лицом? Или другой случай. Выступает, допустим чудак на букву "М" с по своему интересным докладом, после которого к нему подходят люди и спрашивают конкретные вопросы по существу. А докладчик от всех отмахивается, заявляя, чтобы ответы на эти вопросы стоят денег и за просто так он свое время тратить не готов. И снова вопрос, какую цель преследует докладчик, отшивая слушателей и вызывая у них стойкий негатив к себе, который транслируется и на компанию, в которой работает спикер?

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

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

Подробнее…

Новые каталоги угроз

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

Первый - это open source проект по созданию открытой, поддерживаемой индустрией таксономии потенциальных угроз информационным системам. Проект еще находится в стадии развития и текущая версия, v1.1, документа содержит не так уж и много угроз:

• 14 физических угрозы, влияющих на ИБ
• 13 угроз ресурсам, которые влияют на информационные системы (водоснабжение, электричество и т.п.)
• 7 угроз со стороны персонала
• 41 техническая угроза.

Второй документ гораздо более серьезный. Он представляет собой результат 4-хлетней работы европейского агентства по информационной и сетевой безопасности ENISA (обновлен в сентябре 2016). Разработанная таксономия вобрала в себя свыше 30 других существующих проектов и документов в области создания таксономии угроз (ФСТЭК в списке нет).

Всего в текущей версии таксономии ENISA 177 угроз (почти столько же, сколько и у ФСТЭК) и они разделены на 8 высокоуровневых категорий:

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

Разделение весьма странное и местами спорное (особенно в части гнусной активности), но Европа теперь живет именно по нему и отталкивается в своих проектах, коих у ENISA большое множество.

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

Другой документ подготовлен МинОбороны США и посвящен модели угроз беспилотным летательным аппаратам.

Финальной находкой стала модель угроз для Интернета вещей, подготовленная Beecham Research. Она носит скорее маркетинговый характер, чем полезный в работе документ (по сравнению с предыдущими упомянутыми моделями и таксономиями), но общее представление о проблеме дает.

ЗЫ. С доступом к первому описанному документу могут быть сложности. Похоже из России доступ к сайту ограничен - мне пришлось поднимать VPN, чтобы зайти на страницу проекта.

Подробнее…

Как приоритезировать события в SOC?

На последнем PHDays, где я вел секцию по SIEM, все участники сошлись во мнении, что правила корреляции из коробки не работают и про них надо забыть сразу после покупки решения по управлению событиями безопасности. С SOC ситуация ровно таже самая и перед нами встает вопрос не только о том, как создать правила корреляции событий, но и как приоритезировать эти события, попадающие в поле зрения SOC. Как отсечь ложные срабатывания от реальных инцидентов?

Можно предложить следующий алгоритм, завязанный в том числе и на Kill Chaim, которой посвящено несколько моих последних заметок. При приоритезации мы должны учесть несколько важных параметров:

• фазу Kill Chain
• зрелость метода обнаружения
• кампанию.

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

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

Третий параметр, влияющий на приоритет рассмотрения угроз в SOC, - это зрелость способа детектирования угрозы. Мы прекрасно понимаем, что у нас может быть сигнатура IDS или результат работы Threat Intelligence Platform, которые на 100% дают нам положительной ответ о наличии угрозы в сетевом трафике или каком-либо файле. Это так называемый стабильный уровень зрелости обнаружения, который будет давать тот же самый результат при любом количестве повторов. Уровень ложных срабатываний при нем будет равен или очень близок нулю. Никакой доработки данный метод не потребует и он живет своей жизнью в рамках SOC. Другое дело, когда мы имеем дело с совершенно новым и еще не аппробированным методом детектирования, который не имеет доказанной эффективности и может давать достаточно высокий процент ложных срабатываний. В этом случае можно говорить о низком, экспериментальном уровне зрелости.

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

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

Подробнее…

Threat Hunting в деятельности SOC

Threat Hunting - это процесс проактивного поиска и обнаружения угроз, которые не обнаруживаются традиционными защитными мерами, такими как МСЭ, IDS, SIEM. В противовес традиционным автоматизированным решениям Threat Hunting - это преимущественно ручной процесс с элементами автоматизации, в рамках которого аналитик, опираясь на свои знания и квалификацию просеивают большие объемы информации в поисках признаков компрометации, соответствующих первоначально определенной гипотезе. Это еще одно отличие Threat Hunting от обычных средств кибербезопасности, которые работают в соответствии с предопределенными шаблонами (решающими правилами) и автоматизируют поиск того, что уже известно. Threat Hunting ищет в тех же самых источниках данных то, что еще неизвестно, но вероятно произошло согласно гипотезе аналитика, который либо находит ей подтверждение, либо отметает, как несостоявшуюся, переходя к следующей гипотезе. Если вернуться к уже упомянутым мной "окну Джохари" и теории "Черного лебедя", то Threat Hunting помогает искать угрозы именно в неизвестной зоне, самой сложной в окне Джохари.

Threat Hunting - это не новая концепция, не продукт и не серебряная пуля. Стандартов для Threat Hunting также никаких не существует, как и лучших практик. По сути речь идет о расширении традиционных механизмов поиска следов злоумышленника (можно сказать и целенаправленных угроз), которые не ищутся имеющимися средствами автоматизации задач кибербезопасности (IDS, AV, SIEM и т.п.). Особенно активно данная тема стала развиваться в контексте центров мониторинга безопасности (SOC), в которых Threat Hunting является одним из множества реализуемых процессов. Он же показывает разницу между SIEM и SOC.

Что из себя сегодня представляет платформа для Threat Hunting? По сути это набор уже известных решений и технологий - SIEM, Threat Intelligence Platform, OSINT и, возможно, иные источники данных для анализа. Одним из примеров такой платформы можно назвать Cisco OpenSOC, о котором я уже писал на Хабре. Среди других платформ можно назвать ELK, RITA, ONI, Splunk, Hadoop, Sqrrl.

Задача аналитика в рамкахThreat Hunting - собрать все возможные данные с узлов, с сети, с средств защиты, с систем контроля доступа, от HR, из источников OSINT и применить к ним различные техники, позволяющие увидеть невидимое - визуализацию (вот пример такого инструмента), статистический анализ, машинное обучение и т.п. На выходе мы получим (если гипотеза аналитика верна) необходимые доказательства. Учитывая используемые техники, мы должны четко понимать, что является у нас нормой, а что отклонением от эталонного поведения (аномалией), которое и покажет нам угрозу, необнаруженную другими средствами защиты.

Threat Hunting может быть организован как с дополнительной информацией (с Intelligence) и без оной (с Zero-Intelligence). В первом случае вы получаете эту дополнительную информацию (хеши файлов, IP-адреса, названия файлов, ключи реестра и другие IoC) из внешних источников (IOCBucket, Abuse.ch, VirusTotal, ThreatGrid, AlienVault, EmerhingThreats и др.), ищете ее на локальном или удаленном узле с помощью различных инструментов (Yara,  CrowdResponse, rastrea2r и т.п.) и потом применяете меры реагирования. Без дополнительной информации искать что-то достаточно сложно и требуется обладать высокой квалификацией и знаниями по исследуемой системе. Также можно использовать и различный инструментарий, облегчающий вам жизнь. Например, утилита Autorun из набора Sysinternals позволяет вам проанализировать все, что у вас автоматически запускается на компьютере, снять с этих файлов хеши и отправить на VirusTotal для проверки. Понятно, что Threat Hunting с Zero-Intelligence является высшим пилотажем и может определять действительно серьезный SOC от временной конторы, которая решила срубить денег на горячей теме и установив у себя open source SIEM, назвала все это SOCом.

Помнится в конце 90-х я учился в SANS на курсах по анализу сетевого трафика. Сетевых IDS тогда на рынке еще почти не было и то, что мы изучали по сути и являлось Threat Hunting’ом. Нам давали сетевые дампы и мы должны были в них отыскать признаки тех или иных атак. Позже эта задача была целиком автоматизирована с помощью сетевых IDS. Так и с Threat Hunting. Есть уже вышедшие на плато своей продуктивности технологии, а есть еще вещи, которые сложно автоматизировать и которые приходится делать в ручном режиме с активным вовлечением человека. Threat Hunting относится именно к ним.

Подробнее…

Мои недавние статьи

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

• Программы-вымогатели - бич современного предприятия
• Как обосновать необходимость ИБ бизнесу
• Кибератаки на Вашингтон: как отвечать на агрессию в Интернет (скорее не статья, а большая передача на BBC с последующей расшифровкой)
• О готовящихся изменениях в законодательстве по безопасности критических инфраструктур
• О "хороших" и "плохих" парнях из мира ИБ

Подробнее…

Теория "Черного лебедя" в деятельности SOC

Во вчерашней заметке особо пытливые читатели могли заметить, что в неизвестной зоне окна Джохари для ИБ я упомянул термин "Черный лебедь". Так называются события из теории, предложенной Нассимом Николасом Талебом в книге "Черный лебедь. Под знаком непредсказуемости". Это редкие и труднопрогнозируемые, но имеющие значительные последствия, события. По версии Талеба такие события обладают тремя признаками:

• неожиданность для эксперта
• значительность последствий
• рациональное объяснение в ретроспективе (уже после свершения).

Талеб считал почти все научные открытия, значимые политические и исторические события, именно "черными лебедями". Интернет, развал СССР, 11 сентября... С одной стороны его теория кажется вполне реалистичной, но многие ученые подвергают сомнение тот факт, что Талеб свел абсолютно все редкие события со значительным эффектом к "черным лебедям". То, что большинство людей не могло предсказать Stuxnet, взлом RSA или "законопроект Яровой" не означает, что такая слепота была присуща всем и уж тем более, что эти события нельзя было спрогнозировать с применением тех или иных методик (имитационное моделирование, сценарный анализ и т.п.). Кстати, вчера было 28 лет с того дня, как Роберт Моррис запустил своего известного червя (червя Морриса), который в 1988 году вывел из строя около 10% Интернет. И это событие тоже можно считать "Черным лебедем".

Однако применительно к деятельности Security Operations Center такие события существуют и действительно являются одной из серьезных головных болей для аналитиков. Ведь они сложнопредсказуемы, но могут нанести серьезный ущерб защищаемой компании. Особенно опасны такие события для аутсорсингового SOC, который берет на себя ответственность, в том числе и финансовую, за защищенность своих клиентов. Самоуверенность в своих силах может сыграть злую шутку с SOC, который пропустит то, за что потом придется расплачиваться деньгами и репутацией. Талеб в свое книге как раз предупреждает о том, что человек по своей сути излишне самоуверен и на самом деле неспособен прогнозировать; уверенность в своих знаниях опережает сами знания и порождает феномен "сверхуверенности". Взломы Sony, АНБ, Target, JPMorgan, Adobe, RSA лемонстрируют этот феномен. Всех их взломали и все они при этом имели серьезную систему ИБ, включая и систему мониторинга.

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

У нас накапливается много данных в SIEM и это создает уверенность в том, что мы знаем и видим все происходящее с точки зрения кибербезопасности. Но так ли это? Мы даже не всегда индикаторы компрометации применяем для поиска уже известных угроз. И корреляция событий безопасности у нас нередко настроена из рук вон плохо. И сетевые аномалии с помощью Netflow мы не собираем и не анализируем. Чего уж говорить о "черных лебедях"?

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

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

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

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

Подробнее…

Окно Джохари и методы обнаружения угроз для SOC

В 1955-м году два американских психолога Джозеф Лифт и Харингтон Инхам разработали технику, которая позволяет людям лучше понять взаимосвязь между своими личными качествами и тем, как их воспринимают окружающие. В соответствии с методикой, названной "Окном Джохари", у каждого человека имеются четыре зоны: Открытая, Слепая, Спрятанная и Неизвестная:

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

Используемое обычно для саморазвития "окно Джохари" может быть применено и в области обнаружения вредоносной активности, в деятельности Security Operations Center.

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

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

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

Неизвестная зона - это проблема проблем в ИБ. Очень хорошо ее озвучил бывший министр обороны США Дональд Рамсфельд: "Есть известные известные — вещи, о которых мы знаем, что знаем их. Есть также известные неизвестные — вещи, о которых мы знаем, что не знаем. Но еще есть неизвестные неизвестные — это вещи, о которых мы не знаем, что не знаем их". В ИБ таких событий огромное количество. Это и 0-Days, по которым в прошлой заметке я призывал не напрягаться, так как мы все равно не способны повлиять на их присутствие или отсутствие. Это и события, для которых еще нет сигнатур или иных решающих правил.

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

Опираясь на "окно Джохари" и то, что видит аналитик SOC с помощью имеющихся у него возможностей, можно говорить о зрелости или поколениях SOC. Но об этом уже в другой заметке...

Подробнее…

Kill Chain и индикаторы компрометации

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

Самые распространенные они потому, что с ними проще всего работать и проще всего получать. Достаточно подписаться на бесплатные фиды и регулярно получать их подгружая в свои SOCи и системы анализа. Можно воспользоваться и коммерческими, более навороченными ресурсами, которые будут отдавать нам также информацию о различных артефактах - сетевых и хостовых. Однако обычно, три верхних уровня пирамиды - это то, что создается самим потребителем; извне такие данные поступают редко. Я в прошлом году, на SOC Forum рассказывал как раз о таких ресурсах, выборе фидов, платформах Threat Intelligence. Но этого тоже мало. Как хорошо показано в презентации Дэвида Бьянко из Mandiant для поноценного расследования инцидентов и обнаружения целевых атак необходимо понимать TTP - абрревиатуру, о которой я писал вчера.

Если же наложить известные нам индикаторы компрометации на этапы Kill Chain (картинку тоже стащил у Бьянко), то мы увидим, какие IoC нам могут понадобиться. Это знание полезно с двух точек зрения. С одой, если у нас уже есть некие фиды с IoC, то мы можем понять, насколько полно мы покрываем ими все 7 фаз убийственной цепочки и чего нам не хватает. С другой, если мы только строим свой SOC и хотим выбрать нужный источники Threat Intelligence, то эта картинка подскажет, на что обращать внимание при выборе TIP-платформы.

ЗЫ. Уже опубликована программа SOC Forum 2.0 и я думаю нам удастся обсудить эту тему в рамках одной из шести сессий.

Подробнее…

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 и известный специалист по ИБ (я у него в свое время учился на курсах по обнаружению вторжений и мониторингу сетевого трафика).

Подробнее…