19.06.2018

F-Secure покупает MWR InfoSecurity

18 июня финская F-Secure подписала соглашение о покупке MWR InfoSecurity, занимающуюся threat hunting, пентестами и антифишингом. Размер сделки составляет 91 миллион евро.

Новая отечественная TI-платформа и здоровая конкуренция между двумя главными банками страны

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

Интерфейс TI-платформы (фото BIS Journal)
Платформа обмена данными позволит участникам АБР в режиме реального времени получать самую актуальную информацию о киберугрозах, злоумышленниках и их методах работы (речь идет о TTP), и автоматически применять ее в своих защитных решениях через API. Что интересно, участники АБР могут направить (и уже направили) в BI.ZONE данные о своих средствах защиты, которые можно будет автоматически интегрировать с Платформой.

Компания BI.ZONE ("дочка" Сбербанка) - технический провайдер сервиса. В течение бесплатного пилотного периода, который продлится 3 месяца, информация (читай, индикаторы компрометации) в Платформу будут поступать только из потока данных BI.ZONE. После этого возможность загружать данные получат все организации-участники сервиса. База индикаторов компрометации и обширная контекстуальная информация помогут повысить защищенность инфраструктуры, снизить количество инцидентов и, в конечном счете, ущерб от атак киберпреступников. На данный момент к Платформе подключились «Сбербанк России», «Кубань Кредит» и Саровбизнесбанк. В ближайшее время также ожидается подписание соглашений с 17 другими банками, также выразившими желание присоединиться к Платформе.

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


То ЦБ был первым, то Сбербанк, то наоборот. Но в целом они идут ноздря в ноздрю, занимаясь в целом важным для финансовой отрасли делом - повышением ее кибербезопасности. Один банк имеет функции регулятора и может проводить многие решения в виде нормативных актов (своих или на уровне законодательства), другой имеет большую свободу в финансировании своих проектов и поэтому динамичнее в тех вопросах, где надо заплатить, привлечь лучшие умы страны и, возможно, всего мира (вы видели программу международного форума по кибербезопасности, который организует Сбербанк 5-6 июля?). ЦБ в этом плане менее поворотлив и поэтому Сбер часто опережает финансового регулятора там, где последний начинал первым. Например, про обучение банковских безопасников на Уральском форуме заговорили пару лет назад, а программы переподготовки должны быть еще только подготовлены, а Сбер запустил свою Академию Кибербезопасности еще в прошлом году. ФинЦЕРТ запущен уже несколько лет, но до сих пор так и не запустил автоматизацию процесса обмена данными об угрозах и индикаторами компрометации. Отчасти из-за бюджета, отчасти из-за необходимости согласования такого обмена с форматами и протоколами ГосСОПКИ (для этого как раз разработан стандарт СТО 1.5). Сберу ни с кем ничего согласовывать не надо и через свою дочку BI.ZONE этот процесс можно сделать гораздо быстрее, что и было продемонстрировано выше. В конце марта этого года на заседании АБР упомянули о важности такой платформы, в апреле был представлен проект и архитектура системы, а вчера запущен пилот. Зато у Сбера нет таких возможностей по продвижению своих инициатив на уровне Правительства (даже несмотря на вхожесть Грефа в высокие кабинеты).

Получается этакая здоровая конкуренция, которая движет рынок вперед. Тем интереснее будет увидеть планы, которые были озвучены Станиславом Кузнецовым (зампред Сбербанка по безопасности) в январе этого года:

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

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

15.06.2018

Инфовотч продала немецкую "дочку" EgoSecure

События такого плана нечастые, поэтому и тега в блоге у меня для них нет. Хотя я даже и не знаю как я бы назвал этот тег. "Расконсолидация"? "Распродажа"? Короче. Infowatch вчера объявила о продаже своей немецкой "дочки" EgoSecure, которая и так скрывала на всех мероприятиях (что InfoSecurity в Лондоне, что RSAC в Сан-Франциско) свои "русские" деньги. Наталья Касперская связывает продажу с информационными атаками на нее в немецкой прессе и обвинения в связях с Кремлем и ФСБ, что привело к потере нескольких клиентов. Как бы то ни было, контрольный пакет EgoSecure продан немецкому поставщику офисного ПО - Matrix42.

13.06.2018

Capgemini покупает Leidos Cyber

Французская консалтинговая ИТ-фирма Capgeini 7 июня анонсировала приобретение киберподразделения Leidos Cyber у американской Leidos, которая раньше называлась SAIC. Размер сделки не сообщается.

Переход НПС на российскую криптографию и квантовые атаки

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

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

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

Как показывают многочисленные исследования криптоалгоритмы, базирующиеся на сложности факторизации целых чисел (например, RSA) или дискретного логарифмирования (например, Эль-Гамаль или эллиптические кривые), находятся под ударом - они не являются квантовобезопасными, так как не могут адаптироваться к квантовым атакам просто увеличивая длину ключа (Диффи-Хеллман тоже уязвим). Симметричные алгоритмы AES или ГОСТ Р 34.12-2015 считаются квантовобезопасными, так как всего лишь достаточно увеличить длину ключа (считается, что квантовые компьютеры снижают эффективную длину криптографических ключей в два раза - ГОСТ с длиной ключа 256 бит для квантового компьютера - это тоже самое, что и ГОСТ с длиной ключа 128 бит для обычного компьютера).

Тем не менее у квантовобезопасных симметричных алгоритмов остается проблема распределения ключей, которая может быть решена с помощью соответствующих квантовых вычислений. Не случайно 20 июля 2017 года ФСБ утвердила «Временные требования к квантовым криптографическим системам выработки и распределения ключей для средств криптографической защиты информации, не содержащей сведений, составляющих государственную тайну». А что с самими криптографическими алгоритмами? И вот тут мы плавно подходим к тому, ради чего эта заметка писалась.

На заседании ПК1 ТК122 в Банке России 30-го мая прозвучало, что в новую редакцию 382-П, которая уже прошла все согласования и находится на регистрации в Минюсте, внесли требование по использованию в НСПК с 2024 года HSM российского производства, а с 2031 года - переход всей крипты в национально значимых платежных системах на российские алгоритмы. Обратите внимание, речь идет только о национально значимых; то же ПП-127 по категорированию объектов КИИ касается только системно или социально значимых. По данным на 8-е июня к национально значимым платежным системам относились (понятно, что этот список будет меняться):
  • Юнистрим
  • НКК
  • Юнион Кард
  • HandyBank
  • BLIZKO
  • НРД
  • Таможенная карта
  • Лидер
  • УЭК
  • Мультисервисная платежная система
  • Платежная система ВТБ
  • Платежная система Сбербанк
  • REXPAY
  • БЭСТ
  • CONTACT
  • Sendy.

Понятно, что переход на отечественную криптографию в масштабах упомянутых платежных систем будет происходит неодномоментно и потребует немало ресурсов (временных и финансовых) на протяжении оставшихся 13 лет (а для НСПК 6 лет). И начнут многие финансовые организации уже скоро. И вот тут основной вопрос. А на какую отечественную криптографию переходить? Учитывают ли принятые и введенные в действие ГОСТы по шифрованию, ЭП, хэшу квантовые атаки? Являются ли наши ГОСТы по электронной подписи и хэшу квантовобезопасными? А "симметричные" ГОСТы? Если да, то останутся ли они таковыми к 2031-му году, учитывая существующие прогнозы? Если нет, то каковы сроки внесения изменения в ГОСТы и реализации этих изменений в отечественной криптопродукции? И какова стоимость обновления текущих решений на будущие, квантовобезопасные?


Думаю, что оба регулятора, и Банк России, и 8-й Центр ФСБ, прекрасно все понимают и имеют ответы на поставленные вопросы и они готовы к ответу на них, если таковые будут от финансовых организаций. А они будут, как только 382-П будет зарегистрирован и увидит свет.

08.06.2018

SIGMA - новый язык описания индикаторов компрометации для SIEM

Пока все ждут от ФСБ документов по ГосСОПКЕ и, в частности, по правилам и форматам передачи данных об инцидентах, я бы хотел поговорить об одном из недавно появившихся стандартов описания индикаторов компрометации. Но сначала вопрос. Какие языки для описания индикаторов компрометации / сигнатур / шаблонов для файловых атак вы знаете? Первое, что приходит на ум, - это YARA. А для сетевых атак? Правильно, Snort. А что для системных событий? И вот тут мы пасуем. Наши SIEM просто берут данные в форматах syslog или Event Log и анализируют по сути сырые данные. Существует ли язык, который мог бы помогать SIEM анализировать события?


Оказывается да. Это SIGMA, язык появившийся год назад, который позволяет легко описывать события для анализа в SIEM и делиться ими между различными организациями в рамках информационного обмена. По мере получения популярности SIGMA для логов должен стать тем же, что YARA для файлов и Snort для сетевого трафика.

Вот так, например, будет выглядеть очистка одного из логов Windows:

title: Очистка EventLog
description: один из логов Windows очищается
author: Florian Roth
logsource:
  product: windows
detection:
  selection:
    EventLog: System
    EventID: 104
  condition: selection
falsepositives:
    - Unknown
level: medium

А вот так выглядит описание сценария, когда офисный документ запускает интерпретатор командной строки cmd.exe:

title: Макрос в офисном документе запускает cmd.exe
status: экспериментальный
description: правило для Windows
references: - https://www.hybrid-analysis.com
author: Florian Roth
logsource:
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 1
    ParentImage:
      - '*\WINDOWRD.EXE'
      - '*\EXCEL.EXE'
    Image: '*\cmd.exe'
  condition: selection
fields:
    - CommandLine
    - ParentCommandLine

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


Наконец, вот так описывается один из тригеров DragonFly:

action: global
title: CrackMapExecWin
description: Обнаружение активности CrackMapExecWin как описывает NCSC
status: экспериментальный
references: - https://www.ncsc.gov.uk/alerts/hostile-state-actors-compromising-uk-organisations-focus-engineering-and-industrial-control
author: Markus Neis
detection:
  condition: 1 of them
falsepositives: - None
level: critical
--- # Сначала анализируем Windows Audit Log 
logsource:
  product: windows
  service: security
  description: 'Requirements: Audit Policy : Detailed Tracking > Audit Process creation, Group Policy : Administrative Templates\System\Audit Process Creation'
detection:
  selection1:
  # Does not require group policy 'Audit Process Creation' > Include command line in process creation events
     EventID: 4688 
     NewProcessName: - '*\crackmapexec.exe' 
--- 
# Затем анализируем Sysmon 
logsource:
  product: windows 
  service: sysmon 
detection: 
  selection1: 
  # Does not require group policy 'Audit Process Creation' > Include command line in process creation events 
   EventID: 1 
   Image: 
     - '*\crackmapexec.exe'

Достаточно несложно и эффективно. Однако есть один нюанс - нужны средства автоматизации для работы со сценариями SIGMA. Пока это делает только MISP (для обмена индикаторами компрометации) и Splunk через соответствующий App - TA-Sigma-Searches. Также SIGMA поддерживает Elastic и kibana. У автора SIGMA были планы по интеграции своего языка в различные SIEM (например, ArcSight и QRadar), но пока они не реализованы. Может отечественные производители будут первыми?

ЗЫ. Кстати. Вы слышали что-нибудь про JA3, метод описания цифровых отпечатков для SSL/TLS-клиентов, который может использоваться в рамках Threat Intelligence? Вот так выглядит отпечаток JA3 для Dridex - 74927e242d6c3febf8cb9cab10a7f889.

07.06.2018

О чем говорили у Gartner'а

На этой неделе в пригороде Вашингтона прошел очередной Gartner Risk & Security Management Summit. В этот раз я на него не смог поехать, но пристально следил за тем, что там происходит, получая информацию от коллег или из Интернет. Некоторым образом меня зацепило во всем потоке информации три тенденции, на которые я бы хотел обратить внимание.

Первая касается планов по распределению бюжетов на покупку новых технологий в ближайшие 2 года. Да, это результаты опроса среди преимущественно американских компаний. Да, в США немного иной процент проникновения технологий, о которых в России либо еще не слышали, либо внедрения носят эпизодический характер. Но как взгляд на то, что происходит на самом крупном рынке ИБ, эта картинка очень интересна. Посмотрите, в Топ 6 технологий, которые будут привлекать новые бюджеты входят:

  • Cloud Access Security Broker (у нас отечественных решений такого класса нет и вроде как никто и не разрабатывает)
  • Управление привилегированными запиясми (особенно учитывая, что данная защитная мера наряду с обновлениями ОС и приложений, а также замкнутой программной средой позволяет закрыть 85% всего угроз)
  • Контроль поведения пользователей (пресловутая UEBA)
  • Тестирование безопасности приложений
  • Шифрование и токенизация (думаю, к нам эти технологии с Запада не придут ввиду особенностей отечественного законодательства по криптографии)
  • SIEM (ох уж эти SIEMы).


Еще в сентябре я писал про каталог новых профессий АСИ, в котором нашлось место и новым специальностям по кибербезопасности, которые будут востребованы в ближайшем будущем. На мероприятии Gartner эта тема тоже не была обойдена вниманием и было представлено 4 новых профессии:

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


На самом деле, в оригинальном материале, опубликованном в апреле этого года, говорилось не о 4-х, а о 7-ми новых профессиях. К упомянутой выше четверке еще надо добавить:

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

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


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


Ну и последним штрихом стал прогноз, сделанный Gartner'ом, относительно пентестов, которые должны не то, чтобы умереть, сколько существенно потесниться, уступив место либо внутренним Red Team командам, либо специализированному ПО класса BAS (Breach & Attack Simulation). Это новый класс средств защиты, который ввел Gartner в прошлом году, и примеры которого можно было найти на RSA на протяжении последних пары лет. Автоматизация работы пентестеров уже предсказывалась некоторое время назад - пришло время воплощать это в жизнь.


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

05.06.2018

Fortinet покупает Brafdord Networks

4 июня американская компания Fortinet объявила о завершении покупки американской же Bradford Networks, занимающейся технологиями контроля сетевого доступа. Размер сделки составляет от 17 до 19 миллионов долларов.

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

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


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


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

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


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


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


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

01.06.2018

Немного юмора по ИБ

Пятница... Первый день лета. Можно и пошутить немного :-) Решил собрать последние мемы и шутки, которые замутил с начала года. Хотя, как известно, в каждой шутке есть доля... то ли шутки, то ли правды :-)

Надоело быть просто специалистом по ИБ? Хочешь быть президентом собственного объединения или ассоциации? Не знаешь какое название дать своему союзу? Воспользуйся методичкой и у твоего партнерства по ИБ будет свое уникальное имя. Не забудь в начало добавить "независимый" или "некоммерческий" :-)


Как отличить криптографа от нормально человека?


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


И тоже самое для "бумажных" безопасников (это часть возможных стикеров - в списке отсутствует, например, GDPR):


Взгляд на деятельность службы ИБ с точки зрения самой службы и с точки зрения бизнеса:


Мозг ибешника перед сном:


Популярная стратегия кибербезопасности:


Thoma Bravo покупает контрольный пакет LogRhythm

31 мая инвестиционный фонд Thoma Bravo, известный своими поглощениями на ниве ИБ, объявил о подписании соглашения о покупке контрольного пакета акций SIEM-производителя LogRhythm. Остальные детали сделки не разглашаются.

31.05.2018

Firemon покупает Lumeta

29 мая компания Firemon, занимающаяся управлением сетевыми политиками безопасности, объявила о намерении приобрести компанию Lumeta, игрока специфической ниши по ситуационной осведомленности. Детали сделки не раскрываются.

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

Четвертым, финальным докладом на IT & Security Forum, стала тема искусственного интеллекта в кибербезопасности. Учитывая сокращенный формат, я с одной стороны подсократил презентацию, которую я читал на RIGF, а с другой добавил туда ряд новой информации из презентации, которую я читал в Школе управления Сколково. В итоге получилось вот такое творение:



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

Проведение киберучений по ИБ для топ-менеджмента (презентация)

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

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



29.05.2018

Антисуслик Шредингера: документы ФСБ, которые есть и которых нет одновременно (презентация)

Продолжаю публиковать презентации с ITSF, которые я читал на этом прекрасном мероприятии. Эта связана с кратким обзором проектов приказов ФСБ по ГосСОПКЕ, которые должны были быть приняты до 1-го января, но до сих пор находятся в статусе проектов. В них есть энное количество неочевидных вопросов, которыми я и задался в рамках своего доклада.



У меня сложилось впечатление, что не все субъекты КИИ читали эти приказы и не до конца осознают последствия от их принятия. Поэтому я и позволил себе свести некоторые из последствий (с рекомендациями по сценариям действий) в единую презентацию.

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


Подводные камни open source при создании отечественных средств защиты

Давайте не будем лукавить и честно признаемся - свежие российские решения по ИБ (исключая СЗИ от НСД, СКЗИ и других “старичков”) активно используют open source компоненты в своем составе. Этого нечего стыдиться - это нормальная практика, задействовать уже написанный кем-то и распространяемый под разными лицензиями (GPL, ) код. Согласно отчету Black Duck Open Source Security and Risk Analysis (OSSRA) за 2017-й год 96% проанализированных авторами отчета приложений используют open source. Прошли те времена, когда сложные приложениям (да и не очень сложные тоже) целиком создавались одной командной с нуля. В условиях нехватки времени и компетенций, многие используют уже кем-то написанный код. И наша отрасль не является исключением. По данным отчета OSSRA сфера кибербезопасности находится на 3-м месте по проценту использования открытого ПО (после здравоохранения и ритейла с электронной коммерцией). А вообще согласно OSSRA 96% приложений задействует open source компоненты, число которых может достигать 147 штук на одно приложение.

Учитывая стратегию на импортозамещение в России, тема контроля применения open source в российских средствах защиты информации становится как никогда актуальной. Особенно в контексте последних нормативных изменений. Например, недавний приказ ФСТЭК №55 по новым правилам сертификации. Есть там такой пассаж, который применяется в тех случаях, когда продукт, подаваемый на сертификацию, содержит компоненты не только одного разработчика, но и других компаний или команд. Да, к open source этот фрагмент тоже имеет отношение.


Соответственно, при использовании open source, заявитель должен прикладывать к продукту текст лицензии (GPL, BSD и других), которые и считаются договорами. Интересно, что согласно OSSRA 85% приложений содержат компоненты open source в нарушение существующих лицензий, а 53% и вовсе не упоминают об использовании open source, нарушая права авторов на создание, модификацию и распространение своего ПО. Например, у Континент СОВ явного упоминания использования open source нет - кроме единственной новости 2013-го года про использования Snort и завуалированной новости про устранение уязвимости в движках Snort и Suricata. А вот у Инфотекса есть отдельный документ про использование open source, который прилагается к VipNet IDS. И тут возникает

Вопрос №1. Должна ли ФСТЭК требовать соблюдения лицензий GPL и др. от заявителей? 

Второй вопрос достаточно очевиден и я про него уже не раз писал. Речь идет об уязвимостях в open source и иных компонентах третьих фирм. Согласно требованиям ФСТЭК именно заявитель отвечает за устранение уязвимостей в своем продукте, независимо от того, в каком компоненте (своем или чужом) эта уязвимость найдена. Согласно OSSRA среднее число уязвимостей в open source компоненте составляет 27, а известные open source уязвимости (OpenSSL, Apache, zlib, libxml2, libpng, ядро Linux и др.) найдены в 67% приложений. Вспоминая историю с некоторыми сертифицированными форками, авторы которых прямо признавались, что они не способны устранить уязвимость, пока ее не устранит сообщество, поддерживающее компонент open source, возникает логичный:

Вопрос 2. Что делать потребителю, если ФСТЭК отзывает/приостанавливает сертификат на средство защиты при отказе/невозможности заявителя устранять уязвимость в open source компоненте?

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


Меня в этой пятерке требований интересует 3-й и 4-й пункт, которые, если транслировать их на open source, вызывают вопросы. Возьмем к примеру Snort или Suricata, в числе активных контрибуторов или разработчиков которого, российских ИБ-вендоров не наблюдается. Кто занимается модернизацией этих движков, на которых построены некоторые "отечественные IDS"? Российский вендор или все-таки сообщество, которое находится преимущественно зарубежом и обычно работает в иностранных организациях? Что-то мне подсказывает, что второе. Но тогда получается, что это приводит к невозможности выполнения третьего пункта в перечне на слайде? А покупка сигнатур атак у той же Emerging Threats - это ведь гарантийная поддержка (4-й пункт слайда)? Кстати, наличие управляющей компании в Лондоне тоже ведь нарушает данные требования ФСБ (правда, это уже не про open source). Отсюда

Вопрос №3. ФСБ сознательно закрывает доступ open source в ГосСОПКА или с этой стороны о проблемах никто не думал?

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


ЗЫ. Тем, кто утверждает, что на open source не распространяются геополитические риски и санкции, впору вспомнить историю с запретом Asterisk в Иране и кейс с блокированием доступа к Sourceforge пользователям Судана, Сирии, Кубы, Ирана и Северной Кореи.

28.05.2018

Malwarebytes покупает Binisoft

24 мая Malwarebytes анонсировала приобретение частной румынской компании Binisoft, занимающейся защитой ПК под управлением Windows. Размер сделки не раскрывается.

Анатомия атаки на АСУ ТП (презентация)

Выкладываю первую презентацию с IT & Security Forum, который прошел в Казани на прошлой неделе и на которой у меня было 4 выступления. Эта презентация была последней в списке и подготовленной в попыхах, буквально за полтора часа до выступления. Так что получилось не очень - лично мне не нравится. Но вдруг кому-то будет интересно.



Видео, которые использовались в презентации, также выложу. Первое описывает анатомию атаки на корпоративную сеть, которая также применяется и как первый этап атаки на промышленные системы.


Второй ролик описывает атаку на Интернет вещей:


ЗЫ. Надо признаться, что ITSF стал для меня примером идеального мероприятия, в котором найден баланс между деловой и культурной программой, рекламой и контентом, нетворкингом и стендами. 11 лет работы не прошло даром. С мероприятия, которое начиналось в офисе ICL (если я ничего не путаю), оно доросло до общероссийской конференции, которой могут позавидовать и московские ИБ/ИТ-тусовки.

23.05.2018

Ростелеком покупает Solar Security

22 мая Ростелеком анонсировал приобретение за 1,5 миллиарда рублей 100% компании Solar Security, известной как своим продуктовым направлением, так и направлением аутсорсинга SOC. Несмотря на значимость события для российского рынка ввиду редкости у нас M&A-сделок, комментировать его пока рано. Мне показался примечательным факт из пресс-релиза, что Solar Security сохранит свою самостоятельность и в Solar Security будут переведены сервисы и специалисты Ростелекома по ИБ. Но, как говорит современная молодежь, "это не точно" :-) Будем следить за развитием событий.

ЗЫ. Видео-репортаж с пресс-конференции Ростелекома и Solar Security.

Антисуслик Шредингера. Документы ФСБ, которые есть и которых нет одновременно

Завтра и послезавтра я буду выступать в Казани на IT & Security Forum и участвовать в двух круглых столах. И если с круглыми столами и тремя темами для выступлений мы с организаторами определились достаточно быстро, то четвертая тема в потоке по КИИ вызывала вопросы. До тех пор пока я не погрузился в изучение проектов приказов ФСБ в рамках законодательства по безопасности критической информационной инфраструктуры.


Вообще в последнее время я мало пишу про законодательство (последний раз аж 2 месяца назад), занимаясь немного другими проектами. Но иногда, нет да приходится погрузиться в эту тему. На этот раз я попробовал вычленить что-то из тех приказов ФСБ, которые были анонсированы в декабре 2017-го - марте 2018-го годов, но которые до сих пор так и не приняты. Вот именно этим документам я и посвящу свое четвертое выступление на ITSF. И хотя это пока проекты и есть надежда, что финальные версии будут отличаться от текущих, я бы хотел задаться рядом вопросов, ответы на которые, возможно, прозвучат в Казани, а возможно авторы документов по ГосСОПКЕ учтут их в финальной версии.

Итак, вопросы следующие:

  1. Согласно правилам платежных систем Visa и Master Card, а также по правилам SWIFT, их клиенты сообщают об инцидентах, произошедших в указанных системах/сервисах. Однако согласно п.8 порядка "Обмена информацией о компьютерных инцидентах..." передача информации об инцидентах за пределы РФ осуществляется только через НКЦКИ. Согласно описанной в пп.9-14 процедуре субъект КИИ направляет в НКЦКИ обращение по каждому инциденту, а НКЦКИ в случае положительного решения переправляет информацию зарубеж в течение 12 часов с момента обращения субъекта посредством почтовой, факсимильной и электронной связи, а также через инфраструктуру НКЦКИ. Если же НКЦКИ считает необходимым отказать, то он это делает в течение 24 часов, о чем сообщает субъекту, направляя ему выписку из принятого решения. У меня возникает три вопроса. Посредством чего НКЦКИ направляет субъектам свой отказ? Является ли этот отказ мотивированным? И действительно ли надо по сотням тысяч инцидентов с картами Visa и Master Card (а именно такое число фигурирует в отчете ФинЦЕРТ за 2017-й год) оформлять обращения на каждое из них?
  2. Согласно методичке по созданию ведомственных и корпоративных центров ГосСОПКИ такие центры должны среди прочей информации о компьютерных атаках уведомлять о рассылках спама (п.8.6). Спам также фигурирует в п.8.7 уже в разряде инцидентов. У меня снова три вопроса по данному требованию. Зачем по спаму сообщать IP-адреса атакующих и пострадавших, а не их почтовые адреса и почтовые сервера? Сообщать надо именно о спаме или также о срабатывании репутационных фильтров? Также мне интересно, надо ли сообщать о каждом спамерском сообщении? Например, в Cisco ежемесячно спам-фильтрами блокируется около 5 миллионов сообщений, а репутационными - 81 миллион сообщений. Надо составлять 86 (в худшем случае) или 5 (в "лучшем") миллионов карточек инцидентов?
  3. Согласно перечня информации, предоставляемой в ГосСОПКУ, об инцидентах надо уведомлять незамедлительно, но не позднее 24-х часов с момента их обнаружения. Все бы ничего, но по каждому инциденту надо среди прочего сообщать о последствиях инцидента. У меня вопрос - как можно оценить последствия (ущерб) от инцидента в течение суток (и это в худшем варианте - если придерживать информацию) в течение такого короткого интервала времени? У ЦБ в 2831-У для этого предусмотрены формы за прошлый отчетный период, когда мы уже имеем собранную информацию, в том числе и по последствиям.
  4. Финальный вопрос, который я не перестаю задавать в последние месяцы, касается формата обмена информацией об атаках / инцидентах / признаках атак. Это STIX/TAXII, OpenIOC, иные стандарты обмена данными? Кроме применения TLP пока ни о какой стандартизации речи не идет, что печально. Будет ли назван такой стандарт или разработан с нуля? Вот ЦБ недавно анонсировал проект СТО 1.5 как раз по описанию формата данных при обмене с ФинЦЕРТ (и вроде даже как заявляется, что проект стандарта согласован с ФСБ). А что регулятор по ГосСОПКЕ?
Ну вот такие предварительные вопросы. На самом деле их больше, но часть из них (с возможными ответами) я буду освещать в рамках своего выступления на ITSF.


ЗЫ. Три оставшиеся темы будут посвящены искусственному интеллекту и ИБ, киберучениям по ИБ для руководства, а также анатомии атаки на АСУ ТП. 

21.05.2018

Новые форматы донесения важности ИБ до неспециалистов

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

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


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


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


В любом случае хочу сказать спасибо Русту за его критику :-)

17.05.2018

Куда податься бедному хакеру?

Давайте себе представим представителя темной стороны киберсилы, то есть хакера, которого гнетет его противоправная деятельность и он жаждет поскорее покинуть свое поприще и начать зарабатывать себе на хлеб законными методами. Куда ему податься? На первый взгляд у него всего один путь (если не рассматривать уход из “профессии” в фермеры или таксисты) - пойти в пентестеры. Это достаточно распространенный вариант трудоустройства - человек продолжает заниматься тем же, только меняет знак с минуса на плюс. Кто-то даже работает сразу в двух мирах - в рабочее время, с 9-ти до 6-ти, человек трудится во благо кибербезопасности, защищая сети своих клиентов. А вот в вечернее и ночное время он возвращается к своей прошлой жизни, работая по своей прежней “специальности”, зачастую ломая тех, кого днем он защищает. Есть у ряда российских пентестерских контор такие люди, которые “и нашим и вашим”. Но речь пойдет не о них и даже не о пентестерах вообще, хотя, повторюсь, это один из самых очевидных путей будущего трудоустройства. Особенно ввиду роста востребованности тестов на проникновение после попадания их в нормативные документы ФСТЭК.

На прошедшей недавно выставке RSAC (да и вообще в последнее время) я заметил, что на Западе создание небольших стартапов по ИБ - очень популярная тема. И создают их часто те ребята, кто еще недавно ходил по грани (а то и за ней). Мне довелось пообщаться с несколькими из них, а также я походил по стендам таких "новичков" и у меня сложился следующий перечень направлений, которыми могут заниматься бывшие хакеры:
  • Фишинговые симуляции. Эти люди хорошо знают, как ломать разные компании. А так как одним из самых популярных способов до сих пор остается фишинг, то логично, что бывшие хакеры уходят именно в это направление security awareness и по заказу создают фишинговые кампании и оценивают их эффективность. 
  • Обучение. При наличии предрасположенности и знаний, нередко "хакеры" начинают разрабатывать курсы и преподавать их. Часто это направление offensive, но бывают и смешанные программы, объединяющие в себе нападение и защиту.
  • Киберучения. Имея немалый опыт участия в реальных пентестах и смоделированных CTF, бывшие кибербойцы начинают заниматься очень интересной темой киберучений, в рамках которых не просто эмулируются искусственные уязвимости, а прокачиваются навыки защиты и нападения, работы в Red и Blue Team. 
  • Консалтинг. Ну тут вроде все понятно. 
  • ПО для симуляции атак. Консалтинг, обучение, фишинговые симуляции - это все не очень масштабируемые вещи. И хотя на хлеб с маслом на них можно заработать, на черную икру уже может и не хватить. Поэтому нередко "хакерские" команды пытаются создавать ПО, которое затем предлагается рынку. Достаточно новым направлением на рынке сегодня можно назвать ПО для симуляции атак. Это не Metasploit, а решения именно корпоративного уровня, ориентированные на защитников, а не атакующих. Про этот класс решений мы поговорим завтра - там немало интересных новинок появилось за последний год.
Однако стоит отметить, что описанные выше 5 направлений приложения своих сил, "списаны" с западного рынка - в России и странах СНГ могут быть свои нюансы. Например, в государственной программе Казахстана "Киберщит" прописано, что все "хакеры" должны быть взяты на учет и внесены в специальный реестр. Россия не отстает от своего азиатского "коллеги" - Наталья Касперская с мужем высказывали схожие идеи - от ведения учета всех хакеров, безопасников и айтишников до запрета их выезда за границу и отказа от признания отечественных дипломов зарубежом (чтобы никто не убежал). Но даже если эти одиозные идеи не выйдут за рамки воспаленного сознания отдельных представителей нашей отрасли, то для того, чтобы начать свой бизнес в России, надо приложить немало усилий (гораздо больше, чем на Западе) и не факт, что они увенчаются успехом. Очень уж у нас закрытый рынок ИБ - лицензирование деятельности, сертификация ПО, подтверждение квалификации, сертификация специалистов...

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

07.05.2018

Дашборды по ИБ для руководства: объединяем все вместе (презентация)

Теперь попробуем собрать все заметки по дашбордам (1, 2, 3 и 4) вместе. Получится презентация, которую я выложил на Slideshare (да, он заблокирован на территории России, но кого это останавливает?), и которую я читал в рамках мастер-классов в Москве на CISO Forum и в Санкт-Петербурге на Код ИБ.



04.05.2018

Дашборды по ИБ для руководства: как получить финальный вариант?

Давайте посмотрим на дашборды, которые есть у современных решений по ИБ. В качестве примера я возьму то, что мне ближе, - решения Cisco (Cisco ISE, Cisco Stealthwatch, Cisco Threat Grid и Cisco Cognitive Threat Analytics). Посмотрите на иллюстрацию ниже. Мы видим, что все дашборды построены по описанному вчера принципу - сначала ключевые показатели, потом аналитические диаграммы, раскрывающие эти показатели. Клик по выбранным диаграммам приводит к детальным отчетам. Все вроде бы на месте, но можем ли мы такие дашборды показывать руководству? Увы, нет. Ибо они не отвечают на вопросы, которые нужны топ-менеджменту.


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


Чтобы вынести все эти показатели на дашборд нам нужно их каким-то образом выцепить из разных систем, собрать вместе, произвести дополнительные вычисления (например, рейтинг успешности повышения осведомленности в области использования и защиты e-mail) и визуализировать все это в рамках дашборда. Для этого нам понадобится взять "сырые" данные от средств защиты и данные от бизнес-систем (HRM, SCM, ERP, CRM и т.п.), для чего воспользоваться API, которое сегодня является неотьемлемой частью любого современного решения по ИБ (и не только). Помните, я в прошлом году писал о пяти вещах, которые вы должны требовать от любого ИБ-вендора. Так вот наличие API там стояло там на первом месте. Для захвата данных через API необходимо умение программировать. Сразу надо заметить, что речь идет не о "кодинге" на C++ или Ассемблере, а о навыках извлекать данные из разных систем. Будет это ODBC, JDBC, Visual Basic или Python и R, - не так уж и важно.

Что использовать в качестве инструмента для создания и визуализации дашборда? Этот вопрос звучит чаще других, но именно он-то совсем неважен. В конце концов, какая разница, что позволит вам решить вашу задачу? С чем вы лучше знакомы и что используется у вас в организации - то и применяйте. Это может быть Excel (для простых задач вполне себе решение), MS PowerBI, Tableau, QlikView или grafana. В конце концов вы можете заточить под это ваш SIEM, если у него есть возможность конструирования дашбордов и развитый API для подключения к внешним системам. Я вновь повторю, что не так важно КАК визуализировать, как то, ЧТО вы хотите показать и ЧЕГО достичь своим дашбордом.

03.05.2018

Дашборды по ИБ для руководства: как создать макет?

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

Макет позволяет нам понять, какие блоки информации нам нужно отобразить, чтобы дать целевой аудитории ответы на их вопросы и помочь ей принять нужное решение. Возьмем к примеру тему SOC, столь модную в последнее время. Допустим, руководитель всея ИБ компании только-только создал центр мониторинга и хочет получить ответы на три вопроса:
  • Насколько эффективно задействованы его сотрудники? Ответ на этот вопрос позволит принять обоснованное решение в пользу расширения численности сотрудников SOC или в пользу более оптимального использования текущего человеческого ресурса или в пользу автоматизации некоторых рутинных задач.
  • Все ли инциденты отрабатываются в срок? Этот вопрос помогает нам понять, насколько эффективны в своей работе аналитики SOC, правильно ли у нас выставлены KPI для них, насколько эффективно выстроен процесс разбора инцидентов?
  • Какие инциденты отнимают больше всего ресурсов? Ответ на этот вопрос позволяет понять, не надо ли аналитиков послать на обучение по отдельным видам инцидентов или возможно стоит выделить немного денег на решения по автоматизации и, тем самым, ускорению обработки отдельных видов инцидентов?
Чтобы ответить на эти вопросы нам по каждому инциденту нужно собрать следующие данные:
  • аналитик SOC, работающий с инцидентом
  • тип инцидента
  • источник инцидента
  • статус инцидента (разрешен/просрочен)
  • дата и время.
В итоге на дашборде у меня 4 ключевых показателя и 4 диаграммы, отображающие аналитику, поясняющую ключевые показатели, позволяющие ответить на 3 исходных вопроса.



Разумеется это еще не макет дашборда - это скорее набросок той информации, которая должна быть на дашборде. А вот макет будет выглядеть так:


На его отрисовку у меня ушло всего 10-15 минут. Да, не Пикассо. С этим к руководству не пойдешь. Но и задача такая не стоит на этом этапе. Зато мы видим, как будет выглядеть дашборд, какие диаграммы и какие ключевые показатели будут отображаться на нем.

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

  • Время между созданием и закрытием заявки (ticket) в SOC
  • Процент инцидентов обнаруживаемых и нейтрализуемых автоматически, без участия специалистов SOC
  • Соотношение открытых и «закрытых» заявок
  • Соотношение инцидентов и заявок
  • Число повторных инцидентов
  • Соотношение методов коммуникаций с SOC (e-mail / звонков / портал)
  • Число false positives (несуществующих инцидентов)
  • Число изменений средств защиты по результатам расследований инцидентов
  • Соотношение инцидентов по их критичности
  • Цена/длительность разрешения инцидента
  • Число новых заявок.
В идеале же мы должны всегда помнить, что ИБ нужна не ради ИБ, а для достижения целей бизнеса, и поэтому важно уметь привязывать деятельность SOC к финансовым показателям (это еще не весь бизнес, но уже большой шаг в правильном направлении). Если уйти от данных, которые есть только в SOC, и попробовать научиться общаться с бизнесом, то у него можно получить данные, которые можно сопоставить с деятельностью по ИБ. Например, можно оценить потери компании от реализованных инцидентов (в зависимости от бизнеса это может быть просто или не очень). А еще можно попробовать оценить предотвращенные потери - свои и (или) клиентов, а также оценить стоимость расследования каждого инцидента. В итоге макет дашборда может выглядеть таким образом:



Финальную заметку я посвящу вопросу создания прототипа и финального варианта дашборда, для чего нам понадобятся различные средства автоматизации - от Excel или MS PowerBI до Canopy или Splunk.

16.04.2018

Palo Alto покупает Secdo

10 апреля Palo Alto Networks объявила о подписании соглашения о приобретении израильской Secdo, малоизвестного стартапа, занимающегося технологиями защиты оконечных устройств. Детали сделки не раскрываются.

10 типовых ошибок при работе с SOC (презентация)

Выкладываю презентацию с прошдедшего в день космонавтики в Казахстане SOC Forum. Но самая главная ошибка в презентации не упомянута и заключается в том, что на SOC возлагают слишком большие надежды, совершенно забывая про то, что SOC - это вершина пирамиды. Чтобы SOCу было что мониторить или чем управлять, должна быть выстроена полноценная система защиты. Без нее все разговоры про SOC обречены на провал. Ну как можно строить SOC, если даже на периметре организации используется обычный МСЭ (без приставок NG) без помощи со стороны DNS Firewall, NGIPS, систем контетной фильтрации? Я уже не говорю про отсутствие систем внутреннего мониторинга. Ну какой SOC? Даже 20 защитных мер CIS Controls или хотя Топ 4 защитных мер австралийского МинОбороны не все реализуют. Зачем в таких ситуациях SOC?..


Dsrkfls

06.04.2018

RSA покупает Fortscale

5 апреля RSA объявила о приобретении Fortscale, известной своим UEBA-решением, которое теперь станет частью RSA Netwitness. Размер сделки неизвестен.

Qualys покупает 1Mobility

2 апреля Qualys объявила о приобретении 1Mobility, MDM-вендора из Сингапура, который также занимается утечками информации на мобильных устройствах и выполнением требований  compliance.

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

Сделал в рамках keynote на Russian Internet Governance Forum (RIGF) обзор применения искусственного интеллекта в кибербезопасности. Что хорошо приносит ИИ в жизнь безопасников? Как используют ИИ злоумышленники? Какие слабые места есть у ИИ, которыми могут воспользоваться "плохие парни"? Почему вендора пока не способны выпускать воспроизводимые ИИ-продукты "из коробки" (исключая отдельные направления применения ИИ). Вопросы этики применения ИИ в кибербезопасности. И многое другое. Получился короткий обзор более объемной презентации по применению ИИ, обзору различных алгоритмов ИИ и рассмотрению примеров реализации ИИ в кибербезопасности по обе стороны баррикад т.п.



02.04.2018

VMware покупает E8 Security и CloudCoreo

28 марта компания VMware анонсировала приобретение компании E8 Security, занимающуюся в сегменте UEBA. Размер сделки не сообщается. Это уже второе поглощение VMware в сфере безопасности за последний месяц. 14 февраля VMware сообщила о приобретении компании CloudCoreo, занимающейся облачной ИБ.

01.04.2018

Новая награда России - "Криптографическая Фиалка"

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




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

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


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


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

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

ЗЫ. Первое вручение "криптографической фиалки" произошло в обстановке строжайшей секретности в рамках РусКрипто.