17.11.2017

Optiv Security покупает Decision Lab

16 ноября компания Optiv Security объявила о покупке компании Decision Lab, занимающейся большими данными, а также оркестрацией и автоматизацией. Сумма сделки не сообщается.

Управление логами - фундамент любой SIEM, в котором часто зияют прорехи

Уже совсем скоро пройдет конференция ЦБИ "Мониторинг ИБ: проблемы построения и эксплуатации", на которой я буду вести секцию про полноту и "доступность" источников информации, которые подключаются к SIEM, а потом на их основе работает SOC и принимаются решения о наличии или отсутствии угроз. По сути именно от того, насколько выстроена работа с источниками зависит эффективность всей системы кибербезопасности.

Давайте вспомним вот эту иллюстрацию двухнедельной давности:


В ней атомарным элементом считаются логи. Все логи сразу. Многие компании, да и производители SIEM, могут сказать, что уже они то выстроили достаточно зрелый, может быть даже на пятом уровне, процесс управления логами. И в принципе, не сильно задумываясь, мы можем с ними согласиться, так как о том, как работать с логами, как одним из источников информации ИБ, говорят уже много лет и даже десятилетий. Первые хостовые IDS, появившиеся в начале 80-х годов, как раз опирались в своей работе на данные из журналов регистрации. Можно предположить, что уж с логами-то за почти 40 лет у нас научились работать. Но история умеет преподносить сюрпризы. Вот так выглядит слайд из вчерашней презентации Антона Чувакина из Gartner, который рассказывал про технологию пользовательской поведенческой аналитики (UEBA):


Обратите внимания на первый пункт в списке основных проблем при внедрении и использовании UEBA - сбор данных, их доступность и качество. И это спустя 40 лет после появления первых хостовых IDS и 20 лет после появления первых SIEM. А ведь SIEM, которые в принципе должны уметь работать с источниками данных, потом отдают информацию в UEBA, а также иные системы аналитики ИБ.


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

Какие проблемы можно выделить при работе с источниками информации? Их немало:
  • Множество источников. Это примерно как с DLP, которые вроде и борются с утечками, но когда начинаешь копать, то оказывается, что 2/3 коммуникационных каналов в вашей компании они вообще не отслеживают.
  • Противоречивость данных. Например, в одном источнике у вас указан IP-адрес, но нет, допустим, имени пользователя, а в другом наоборот - имя пользователя есть, а IP-адреса нет. И как связать такие данные между собой? А вот еще простой пример. В одном логе у вас время события записано в формате DD-MMM-YYYY, а в другом - MMDDYYYY. Хорошо, если система управления логами, приводит все к единому формату, а если нет?
  • Противоречивость временных меток. Ну тут все понятно и дело даже не в разных часовых поясах, в которых могли происходить события, а в отсутствии системы синхронизации, что может привести, например, к ситуации, когда в SIEM числится, что события А произошло после события Б через 66 секунд, а на самом деле оно произошло до - на 15 секунд.
  • Множество разных форматов. XML, JSON, syslog, CSV (с разделениями табуляцией или запятыми), SNMP, REST, базы данных и др.
  • Незащищенность логов. Кто мешает злоумышленнику удалить какие-то записи из источника информации или, что еще хуже, подменить их, создавая и поддерживая ложное чувство защищенности? А что с доступностью источников информации?
  • Способы доступа к источникам информации. Часто в описании SIEM/LM написано, что они поддерживают потоковые данные из syslog (а Netflow как, кстати?) и удаленный доступ к логам через API и удаленный доступ. А что с агентами? Некоторые данные без агентов не вытащить и не проанализировать.
  • Неструктурированные данные. Правда, это не совсем задача SIEM или LM, но без них сегодня сложно проводить серьезную аналитику и принимать решения и поэтому стоит задуматься об этой теме заранее.
  • Отсутствие стандартов или отказ от поддержки вендорами уже существующих стандартов. RDEP, CEE, SDEE, IODEF, RID, SecDEF... Их поддерживают средства защиты или системы анализа?

Разумеется, все эти проблемы могут быть решены, но об этом все-таки лучше поинтересоваться у производителя SIEM/UEBA/NTA/IDS и других ИБ-решений. Ну а если вы пишете систему защиты/аналитики сами, то просто подумайте, как вы будете решать эти проблемы? Вот именно этим вопросам и будет посвящена секция на конференции ЦБИ, которую я модерирую. Выступать в ней будут представители:

  • ЦБИ, которые недавно выпустили свою SIEM Neurodat,
  • НТЦ Вулкан, которые активно развивают направление SIEM в своих проектах,
  • Infowatch
  • Код безопасности
  • РТ-Информ
  • R-Vision
и их ждут непростые вопросы от меня :-)

15.11.2017

Что такое Fusion Center и чем он отличается от SOC? #socforum

На прошлой неделе, в Питере, на конференции Secure It World, мне довелось модерировать секцию по безопасности ИТ-инфраструктуры, где выступал представитель Ростелекома с рассказом о том, как у них выстроен SOC. Очень интересный был доклад, но меня в нем, помимо прочего, заинтересовала вот эта иллюстрация:


Меня заинтересовала нижная часть слайда, в которой упоминается Fusion Center. Это второй раз, когда я вижу упоминание этого термина в контексте информационной безопасности. Первым был Сбербанк, который последний год упоминает (и еще тут) этот термин в контексте стратегии развития своего центра мониторинга ИБ.

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

Дело в том, что в США, а именно туда пошла концепция Fusion Center в 2003-м году, это центры обмена информацией, а не круглосуточного мониторинга ИБ. Более того, первоначально, да и сейчас, эти центры не имели ничего общего с кибербезопасностью. Они создавались под эгидой Министерства национальной безопасности (DHS) или Минюста (а позже и на уровне отдельных госорганов или муниципалитетов) и позволяли обмениваться стратегической информацией между ЦРУ, ФБР, МинОбороны, МЧС, а также локальными администрациями и т.д. В первые годы Fusion Center, а их насчитывалось только в США несколько десятков, были достаточно бестолковы - они обменивалсь плохо структурированной информацией, которую сложно было анализировать, искать в ней взаимозависимости и строить на ее основе какие-то выводы и принимать решения. Например, в 2011-м году Fusion Center в Иллинойсе сообщил о взломе насосной станции системы водоснабжения в Иллинойсе. Позже агенты ФБР опровергли данное заявление, доказав, что речь шла о легальном удаленном доступе администратора насосной станции.

Если вы введете в Google поиск по картинкам с ключевой фразой "fusion center", то вы увидите кучу фотографий больших залов, напичканных кучей мониторов, за которыми сидят люди и пялятся в экраны. Это не fusion center, хотя его именно так многие и представляют. Отсюда и попытка применить этот термин в ИБ, в которой есть свои SOCи c кучей плазм и больших мониторов. Fusion center - это и не центр реагирования на инциденты, хотя иногда такая функция в нем и встречается, но она не основная. Fusion center не выполняет никаких оперативных функций - это центр поддержки, базирующийся на анализе разрозненных данных. Наиболее близки к концепции Fusion Center CDC (Cyber Defence Center) или ISAC (Information Sharing and Analysis Center), но и они все-таки работают преимущественно со структурированной информацией, в то время как Fusion Center работает с обоими типами данных - структурированными и не очень (особенно с последней). Это позволяет, за счет различных алгоритм и матмоделей, предсказывать многие инциденты и купировать их в зародыше.

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


ЗЫ. Кстати, на модерируемой мной секции Future SOC на SOC Forum будет выступление Алексея Качалина из Сбербанка, который будет рассказывать о своем видении будущего SOC через 8 лет. Не видя еще презентации, могу предположить, что во-многом она будет базироваться на том, каким видит свой Fusion Center Сбербанк в 2025-м году. А Эльман Бейбутов на той же секции будет рассказывать как раз про продвинутую аналитику в деле ИБ. Приходите, будет интересно.

ЗЗЫ. На сайте DHS много полезных руководств по созданию и эксплуатации Fusion Center. Есть там и руководства по интеграции в Fusion Center тематики кибербезопасности.

14.11.2017

Какие стандарты будет применять ГосСОПКА для получения карточек инцидентов и раздачи индикаторов компрометации? #socforum

В предверии SOC Forum хочу вернуться к теме, которую я уже не раз поднимал и важность которой становится все острее и острее. Речь идет о стандартизации обмена информацией об угрозах, инцидентах и индикаторах компрометации между ГосСОПКОЙ и сегментами/центрами ГосСОПКИ.


Сейчас уже существует временная форма карточки инцидента, разработанная 8-м Центром ФСБ и представленная в формате XML. Это очень важный шаг в стандартизации обмена информацией об инцидентах, которые будут передаваться в ГосСОПКУ. Эту же карточку с высокой вероятностью будет использовать и ФинЦЕРТ при своем взаимодействии с финансовыми организациями, которые обязаны сообщать об инцидентах в своей инфраструктуре. Пока рано говорить о том, насколько предложенный формат карточки инцидента совпадает с признанным во всем мире стандартом STIX, о котором я уже писал 4 года назад. Меня гораздо больше интересует другой вопрос. Разработан ли протокол обмена такими карточками инцидентов и каков формат данных об индикаторах компрометации, которые НКЦКИ должен будет рассылать по своим подопечным. В методических рекомендациях по созданию корпоративных и ведомственных центров ГосСОПКИ тема взаимодействия описана очень скупо. Более того, слово "индивидуально" меня смущает - оно так напоминает классическое "в частном порядке", которое очень любят представители 8-го Центра, которым задают вопросы по криптографии.


Как может выглядеть взаимодействие с ГосСОПКОЙ? Я бы выделил несколько вариантов передачи данных по инцидентам:

  • Старая добрая электронная почта, по которой будут отправляться карточки инцидентов на заранее определенный ящик (так делается сейчас в рамках взаимодействия с ФинЦЕРТ). Если не рассматривать вариант, что этот канал слабо защищен и может потребоваться внедрение средств обеспечения целостности и конфиденциальности (разумеется, на ГОСТе и сертифицированных), то возникает сложность с автоматизацией процесса разбора таких сообщений e-mail на стороне ГосСОПКИ. Конечно, это не наша проблема, но мы же сейчас рассуждаем о всей схеме.
  • Система личных кабинетов, которую планируют к концу следующего года внедрить в ФинЦЕРТе и вроде такие же слухи ходят и про ГосСОПКУ. Иными словами участник информационного обмена должен будет самостоятельно заливать карточки об инцидентах в личный кабинет, а оттуда она уже попадет в системы аналитики. Тут тоже возникает вопрос с автоматизацией данного действа - будет ли какой-то API для залива (с токенизацией, конечно, для защиты от подмены) или все надо будет делать вручную?
  • API для взаимодействия по специальному протоколу (например, TAXI), который позволит унифицировать процедуру и автоматизировать ее. На мой взгляд, это был бы идеальный вариант, учитывая известность TAXI и его поддержку многими производителями средств защиты и мониторинга (те же SIEM).


Я надеюсь, что к 1-му января 2018-го года уже наступит ясность (а может ее внесут уже на SOC Forum, где по ГосСОПКЕ будет отдельная секция с 3-мя докладами представителей ФСБ) по вопросу взаимодействия с ГосСОПКОЙ, так как в противном случае возможны самые нехорошие последствия. Например, дополнительные затраты (в том числе бюджетные) на приобретение решений, которые только и поддерживают протокол, разработанный в ФСБ. Сейчас уже ходяит по рынку компания, которая заверяет заказчиков, что она единственная, кто уполномочена ФСБ разрабатывать шлюз взаимодействия с ГосСОПКОЙ и что надо в обязательном порядке приобрести ее шлюз, который будет транслировать данные из имеющихся у заказчиков решений в понимаемый ГосСОПКОЙ формат. А это уже потенциально обвинения в монополии и другией репутационные риски.

А что делать с уже имеющими у многих заказчиков SIEM, которые работают годами и их никто не планирует выбрасывать на свалку и заменять на что-то отечественное (при всем выбранном на импортозамещение курсе)? В идеале им бы выдать описание формата карточки инцидента (это будет сделано) и описание протокола, под который можно написать соответствующий коннектор и подцепить к SIEM или IRP (будь-то QRadar, ArcSight, LogRhytm, Splunk, R-Vision, IBM Resilient и т.п.). Тогда затраты, включая и бюджетные, будут гораздо ниже, чем в случае использования отдельного "православного" шлюза.

С получением данных Threat Intelligence от ГосСОПКИ ситуация и проще и сложнее одновременно. Про то, какой формат будет использовать для передачи индикаторов компрометации пока не говорится. Это может быть OpenIOC, это может быть CybOX, это может быть STIX и т.п. Наверное, это был бы самый правильный вариант, чтобы не плодить промежуточные конверторы из принятых в мире стандартов в нечто, что понимается только ГосСОПКОЙ. И с одной стороны ГосСОПКА не чурается применения международных (читай, американских) стандартов, например, TLP:


и сигнатуры атак описывает на языке стандарта дефакто в области обнаружения атак - Snort:

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

С протоколом передачи IoC от ГосСОПКИ пока тоже ясности нет. PDFки или Word'овые документы тут не подойдут - опять же нужна стандартизация для последующей автоматизации процесса. TAXI? CSV (тоже вариант, кстати)? API, с помощью которого можно будет периодически заходить на сайт НКЦКИ и сгружать оттуда новые индикаторы? Или снова личный кабинет и e-mail? Нет ответа.

И это мы еще не наложили на данную схему требование применения сертифицированных СКЗИ при взаимодействии с ГосСОПКОЙ. Встроенных в SIEM сертифицированных СКЗИ я что-то не припомню (может просто не знаю). Значит наложенная VPN-сеть? А какие VPN-шлюзы будут применяться в ГосСОПКЕ? Один выбранный производитель (а что делать, если у заказчика закуплены решения другого?) или будет кластер из шлюзов всех вендоров?

Подводя итог, хочется отметить, что воможно я дую на воду и все описанные в заметке вопросы уже решены и ФСБ готовит пакет документов и разъяснений по тому, как интегрироваться с ГосСОПКОЙ. Возможно на SOC Forum будут даны ответы на все вопросы, которые возникают не только у меня, но и у многих коллег по цеху, которые не всегда имеют возможность задать их представителям 8-го Центра.

ЗЗЫ. Интересно, а если для карточки инцидента будет применяться JSON, то решены ли с ним вопросы безопасности? На последнем BlackHat, в июле, был интересный доклад по атакам на JSON. Вообще это благодарная тема - атаки на JSON рассматриваются уже не первый год (например, тут или тут). Обработка JSON в ГосСОПКЕ лишена этих проблем?

13.11.2017

Гримасы импортозамещения в контексте мировых тенденций ИБ (парадоксы и презентации)

На прошлой неделе довелось участвовать в питерской конференции по ИБ Secure It World. Прекрасное мероприятие, прекрасная компания, прекрасные доклады.


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



Также я модерировал секцию по защите ИТ-инфраструктуры, где из 6 докладов целых 3 выступления было посвящено теме SOCов (от Solar, Ростелекома и Техносерва), но про них я еще напишу отдельно. Доклад Group-IB был посвящен трендам киберпреступности. Но отдельно я бы хотел отметить доклад Конфидента, который задался закономерным вопросом - насколько совместимы требования по ИБ от регуляторов и курс на импортозамещение. И дальше с цифрами в руках они показали текущую несовместимость этих двух миров :-)

Крутится все вокруг российских операционных систем. Парадоксальный факт. При наличии 30 отечественных ОС в реестре Минкомсвязи и 40 ОС в реестре ФСТЭК, пересечение между ними происходит всего в 4 случаях. То есть всего 4 ОС (две версии ALT Linux, Астра и Синергия) считаются российскими и имеют сертификаты ФСТЭК. И только одна сертифицирована по новым РД ФСТЭК к ОС. То есть получается, что заказчик, который всерьез задумывается о реальном импортозамещении не имеет большого выбора в части отечественных ОС.


Второй интересный момент касается сертифицированных средств защиты. Большинство якобы российских программных продуктов по-прежнему рассчитано на работу только с Windows. Для российских ОС средств защиты почти нет. А если взять за основу 17-й приказ ФСТЭК и посмотреть, какие меры защиты входят в базовый набор и должны использоваться для защиты ГИС, то получается, что... реализовать 17-й приказ на базе отечественных ОС нельзя в принципе. Как минимум, нет тех же средств контроля машинных носителей, с СОВами тоже проблема. Да и сертифицированные МСЭ далеко не всегда работают на отечественных защищенных ОС.


Конфидент делает с одной стороны парадоксальный, а с другой вполне реальный вывод, что аттестовать ГИС, в которой решили использовать отечественные ОС, нельзя.


Ну и еще одно наблюдение Конфидента, который решил проанализировать, насколько эффективно в российских сертифицированных ОС выстроен процесс устранения уязвимостей. Предсказуемо, но процесс не самый лучший и не самый оперативный, существенно уступающий и родным Linux, с которых клонированы "отечественные" ОС, и уступающий Windows.


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

10.11.2017

Кто такие "русские хакеры" и есть ли у России кибервойска?

В последние несколько недель, с момента начала конфликта с Лабораторией Касперского, мне постоянно звонят журналисты иностранных изданий, аккредитованных в России, с просьбой прокомментировать ряд вопросов, которые, как им кажется, являются уникальными и очень интересными. Первый раз это выглядело забавно. Второй я уже отвечал по накатанной. На третий раз я начал злиться. Когда одни и те же вопросы я услышал раз в десятый, я решил написать эту заметку, а окончательно оформилась она вчера, во время перелета на конференцию Secure It World в Питере.

Вопросов обычно звучит три:
  • Как запрет США на поставки Лаборатории Касперского скажется на бизнесе компании?
  • Действительно ли ИБ-компании сотрудничают со спецслужбами?
  • Откуда русские государственные хакеры осуществляют свои атаки на весь мир?

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

Итак, начнем с конца, поговорим про русских хакеров, которые ломают все что движется и всех. Стоит преклонить голову перед пропагандистской машиной США, которые убедили весь мир, что во всем виноваты русские хакеры. Проигрыш демократов Трампу? Русские хакеры. Раздолбайство Yahoo? Русские хакеры. Из ЦРУ и АНБ утекли секретные архивы кибероружия? Русские хакеры. Домогательство Кевина Спейси к Вайнстайну (или Вайнштейну)? Не удивлюсь, если тоже скоро найдут следы русских хакеров. Скоро и Stuxnet на наших повесят. Конечно, внутри, меня переполняет гордость за нашу страну, которая поставила всех на колени своими невидимимыми кибервойсками. Но вот за пределами страны от этого только хуже. Запущенный США маховик раскручивается и даже лояльные и независимые специалисты, компании, организации начинают задумываться, что нет дыма без огня.

Следуя традиции скоро станет известно о хакерской группировке "Red Bear"

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

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

У Китая и США есть свои кибервойска, насчитывающие тысячи военнослужащих. У Израиля есть военное подразделение 8200, есть подразделения Matzov и Mamram. Даже у КНДР есть свои подразделения. А у нас нет. То есть нельзя сказать, что ФСБ, СВР, ГРУ игнорируют киберпространство и не используют его для проведения наступательных, оборонительных и разведывательных операций (было бы глупо так думать, когда весь мир устремляется в виртуальное пространство, а НАТО рассматривает его отдельным доменом для ведения боевых действий), но и отдельного огромного штата на тысячи человек у нас нет. Это журналистам можно проводить аналогии и считать, что раз в США и Китае есть, то и у нас тоже есть. Но мы-то, работающие не один год, знаем. Повторюсь. Я допускаю, что в наших спецслужбах есть те, кто может делать то, в чем их обвиняют, но чтобы их были тысячи или даже сотни?.. Вот тут у меня есть сомнения.

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

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

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

09.11.2017

Symantec покупает SurfEasy

6 ноября Symantec объявила о покупке SurfEasy, разработчика VPN-решений, которым ранее владела Opera Software. Стоимость сделки составляет 38,5 миллионов долларов.

Proofpoint покупает Cloudmark

7 ноября Proofpoint подписала соглашение о приобретении Cloudmark, занимающейся защитой контента и threat intelligence для операторов связи. Размер сделки составил 110 миллионов долларов.

Future SOC - модерируемая мной секция на #socforum

По статистике полугодового отчета Cisco по информационной безопасности за 2017-й год 55% компаний, в том числе и в России, пользуются услугами от 6 до 50 поставщиков решений безопасности. А число организаций, которые используют более 6 различных продуктов по ИБ превышает 65%. Эти цифры означают, что как никогда возрастает необходимость внедрения в своих организациях систем мониторинга ИБ, позволяющих объединить данные с множества разрозненных средств защиты информации. С другой стороны мы сталкиваемся с ситуацией, когда несмотря на все попытки предотвращения угроз, мы не можем гарантировать этого. Неслучайно вся отрасль ИБ (по крайней мере мировая) смотрит в сторону обнаружения и реагирования на инциденты, которые позволяют минимизировать ущерб от действия киберпреступников. А значит на сцену выходит тема центров мониторинга ИБ (SOC), которые позволяют не только мониторить события безопасности, но и оперативно реагировать на них. Именно этому посвящены последние два, а также нынешний SOC Forum. Но…

Надо признать, что пока эта тема достаточно нова для российского потребителя, который часто путает SOC и SIEM, а программу управления инцидентами и соответствующие платформы IRP с требованиями по уведомлению регуляторов об обнаружении инцидентов ИБ в своей организации. Поэтому и темы, и вопросы, звучащие на SOC Forum пока носят базовый характер, так сказать «для начинающих» (что тоже важно). Однако это не значит, что помимо "азбуки" SOC, специалистов не интересуют продвинутые темы о применении в мониторинге ИБ Big Data, нейросетей, машинного обучения, блокчейна, когнитивных технологий, виртуальной реальности и других «модных словечек», о которых многие слышали, но не все знают о практике их применения. И не только вообще, но и в ИБ в частности. Именно поэтому в рамках SOC Forum было решено выделить целую секцию Future SOC и посвятить ее перспективным технологиям, которые только начинают применяться в современных центрах мониторинга ИБ. На секции будут и обзорные доклады о применении продвинутых аналитических методов в ИБ, и практические доклады для обмена опытом по использованию Big Data в деятельности одного из российских SOC, и дискуссионные доклады о возможности применения блокчейна при обмене информацией об угрозах. Завершит секцию открытая дискуссия со всеми ее участниками.


Модерировать секцию буду я, а свое участие в ней уже подтвердили:
  • Эльман Бейбутов из IBM, который выступит с докладом "Когда все правила в SIEM уже написаны, наступает время для Advanced Security Analytics". 
  • Сергей Рублев из ГК Инфосекьюрити расскажет про "SOC в эпоху BigData" и реальный опыт применения Больших данных в деятельности SOC финансовой группы компаний. 
  • Алексей Качалиниз Сбербанка поделится своим видением "SOC 20..25: новые вызовы, новые горизонты" о том, какими свойствами будет/должен обладать центр мониторинга через 7-8 лет.
Я планировал также выступить в этой секции с докладом про применение блокчейна для обмена информацией об угрозах, достоинства и недостатки технологии в деятельности SOC.

Приходите, будет интересно!

ЗЫ. Программа SOC Forum уже финализирована и выложена на сайте.

08.11.2017

Synopsys покупает Black Duck

2 ноября компания Synopsys объявила о намерении купить американского производителя средств анализа безопасности исходных кодов Black Duck Software. Стоимость сделки составила 560 миллионов долларов.

Словарь терминов, связанных с центрами мониторинга ИБ #socforum

"Дело было вечером, делать было нечего"... Так писал в своем стихотворении Сергей Михалков. Примерно также обстояли дела и в моем случае. Правда, дело было не вечером, а ночью, и делать мне было чего. Но я вдруг подумал: "А почему бы мне не сваять словарь терминов, связанных с деятельностью SOCов?" Сказано - сделано. Сваял. На все потратил часа три-четыре. И вот первая версия.


Разумеется, это не весь глоссарий. Я постарался включить в него наиболее активно используемые в русскоязычной и англозычной литературе термины, которые я постоянно вижу перед глазами. Понятно, что термины, связанные со стандартами в области обмена информацией об угрозах и инцидентах (например, я про них писал тут и тут), я включил далеко не все; достаточно было включить STIX, TAXII, TLP, OpenIOC и CybOX. Все остальное не так популярно.

Какой-то основы/оригинала у словаря нет. По сути - это надерганные из разных источников термины, которые я свел воедино и которые перевел на русский язык. К российским терминологическим стандартам (ФСТЭКовские ГОСТы и ЦБшные РСки) я обратился всего в 2-3-х случаях. Других терминов там просто нет, что и понятно. Тема SOCов относительно нова и ее еще просто не успели кодифицировать.

Качать свободно можно отсюда... (регистрация не требуется).

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

07.11.2017

SOC, ориентированный на реальный мониторинг и на compliance #socforum

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

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

Попробовал для себя сформулировать признаки двух типов SOC - ориентированных на выполнение требований законодательства и на реальный мониторинг происходящего на предприятии в контексте кибербезопасности. У SOC в первом случае могут быть следующие признаки:

  • Фокусировка на мониторинге средств предотвращения угроз (МСЭ, AV, IPS, антиспам, контроль доступа и т.п.). Практически полное отсутствие поддержки систем настоящего мониторинга - NTA, CASB, EDR, UEBA и т.п.
  • Инструментарий SOC живет по принципу “заблокировал и забыл” - никакого расследования инцидентов нет и в помине (тем более выстроенных процессов реагирования инцидентов). Также нет и аналитиков третьей линии, занимающихся threat hunting, и инструментария для обеспечения их работы (да того же YARA).
  • Отсутствие playbook и написание правил корреляции по мере возникновения задачи, а не путем анализа use case (сценариев), которые должны лечь в основу ТЗ на построение SOC. 
  • Попытка охватить мониторингом все, что есть в организации, приводящая к перегрузке SIEM, наличии на первых порах сотен и тысяч тикетов в день.
  • Ориентация на решения, подключенные к SOC, и технологии, обеспечивающие его работу. Полная забывчивость в отношении выстраивания процессов и их документирования (да-да, опять playbook/runbook), а также в отношении людей, составляющих ядро нормального SOC.
  • Ориентация и следование стандартам и нормативным требованиям ("а как нам выполнить вот этт пункт приказа №17?").
  • Никак не интегрированное с ИТ управление. Этот критерий поставил на последнее место, так как бывают такие ситуации, когда ИТ и ИБ живут как кошка с собакой и не дружат совсем. Но все-таки жить друг без друга они не могут и для достижения лучших результатов должны дружить, обмениваться данными и интегрировать свои решения по мониторингу (а то и вовсем иметь единую базу событий с разными процессами их анализа, расследования и реагирования).
SOC ориентированный на реальный мониторинг и решение проблем ИБ может быть охарактеризован следующими признаками:

  • Ориентация не на события ИБ, а на инциденты, включая обработку единиц тикетов в день, проведения расследований, выстраивание процессов реагирования, наличие команды threat hunting (или контакты с внешними людьми) и т.п. Наличие нормального решения класса IRP (Incident Response Platform) или SOAR тоже является признаком хорошего SOC.
  • Защита критичных активов, а не всего, что требует предварительного анализа и понимания существующего ландшафта используемых технологий, решений, процессов, узлов, пользователей, информации и т.п. Мы это все знаем?
  • Ориентация на людей в SOC, а не на продукты. Игнорировать последние, конечно, не стоит, но и сильно уж полагаться на них тоже.
  • Знание не только ЧТО [написано в стандартах и требованиях], но и КАК [это надо реализовать наиболее эффективно]. Это проверка/аудит/инспекция/аттестация будет проходить по принципу "есть/нет", а в реальной работе надо понимать, зачем вам та или иная функция и как ее можно решить наиболее оптимальным образом.
  • Тесная интеграция с ИТ.
Чтобы выстроить "правильный" SOC вам может помочь модифицированный метод "пяти почему", который я бы назвал "пять зачем", и который позволяет изучить причинно-следственные связи, лежащие в основе той или иной проблемы или задачи. Суть метода заключается в том, что вы, последовательно задавая пять раз вопрос "зачем" пытаетесь докопаться до первопричины своих решений. Каждый последующий вопрос задается к ответу на предыдущий. Например, это может выглядеть так:

  • Зачем нам SOC?
  • Потому мы уже не справляемся с хаосом средств защиты и нам нужна упорядоченность.
  • Зачем нам упорядоченность?
  • Потому что нам нужно систематизировать все события безопасности, получаемые от средств защиты и приоритезировать их.
  • Зачем нам систематизация и приоритезация?
  • Потому что нам нужно реагировать в первую очередь только на самые важные инциденты.
  • Зачем нам нужно реагировать сначала на важные инциденты?
  • Потому что нам надо предотвратить ущерб для критичных активов предприятия.

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

  • Зачем нам SOC?
  • Потому что нам надо будет отправлять данные об инцидентах в ГосСОПКУ.
  • Зачем нам туда направлять данные об инцидентах?
  • Потому что скоро вступят в силу требования 187-ФЗ.
  • Зачем нам выполнять требования 187-ФЗ?
  • Потому что мы субъекты критической информационной инфраструктуры.
  • Зачем нам выполнять требования, предъявляемые к субъектам КИИ?
  • Потому что за их невыполнение грядет уголовная ответственность.
  • Зачем нам выполнять эти требования?
  • Потому что мы не хотим сесть в тюрьму на 6-10 лет лишения свободы.

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


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

03.11.2017

Термин "периметр" только вредит информационной безопасности

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

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

Но каждое из этих определений очевидно имеет свои плюсы свои минусы и они не равнозначны. Как воспринимать ситуацию даже с таким казалось бы простым вариантом как промышленный сегмент, возможно даже физически изолированным от внешнего мира, если туда пришел представитель подрядный организации с ноутбуком который подключён через 3G четыре же модем к интернету. Появляется ли у нас здесь периметр или не появляется? А если мы посмотрим на ситуацию когда сотрудник с мобильным устройством подключается к облаку внешнему в котором хранятся конфиденциальные данные компании или работает приложение, обрабатывающее данные. Здесь есть периметр или нет? Ведь мы вообще можем использовать личное устройство сотрудника и чужую инфраструктуру облачного провайдера и кроме как информация от компании здесь нет вообще ничего.

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

Утром того дня, когда я начинал писать эту заметку, я работал из дома, читая вебинар для одного из наших заказчиков, днём я приехал в офис и работал внутри нашей беспроводной корпоративной сети. Ближе к вечеру я пошёл на встречу в близлежащий Starbucks и также был подключён к нашей корпоративной сети уже через публичный хот-спот. Вечером я улетел в командировку и в процессе добирания до аэропорта на Аэроэкспрессе я работал через Wi-Fi в вагоне. В аэропорту я также подключился к корпоративной сети через местный WiFi, а в самолёте беспроводная сеть и выход в Интернет были предоставлены мне авиакомпанией. Всё время это были разные сети с разными требованиями и механизмами безопасности, но их объединяло одно - я всегда находился внутри своей корпоративной сети. Существует ли в такой динамической ситуации периметр и можно ли меня загнать в рамки традиционного периметра?

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

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

  • 800-1000 годы нашей эры - фортификация становится стратегической задачей; активно начинают возводиться внешние стены и башни, окружающие объект защиты (дворец князя или иного властителя)
  • 1000-1200 н.э. - утолщение стен, новые материалы (камень против дерева), здания с внутренней защитой 
  • 1400 - … - конец эры замков
Огнестрельное оружие и пушки изменили лицо войн. Замки претерпевают определенные изменения в конструкции, но теряют свое стратегическое значение, уступая принятию новых стратегий для парирования новых технологических угроз. Еще раз обратимся к истории и посмотрим на некоторые известные осады на нашем материке:


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

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

Что делать, спросите вы? Для начала просто понять слабость периметрового подхода. Этого уже немало. Во-вторых, надо защищать не только периметр, но и внутреннюю инфраструктуру, приложения и данные (а также облака и мобильные устройства, если они используются). Я про это писал 4 года назад, повторяться не буду. Но можно пойти еще дальше, внедрив концепцию "доверенного устройства" (мы ее у себя внутри Cisco так и назвали - "Trusted Device"), которая подразумевает, что центральным звеном защиты становится мобильное устройство сотрудника (ноутбук, смартфон, планшет и т.п.). Мы исходим из того, что это устройство может динамично перемещаться по разным местам (смотри выше пример с описанием того, как писалась эта заметка) и может не находиться под защитой периметрового МСЭ/IPS/ESA/WSA и др. Приняв это за основу, мы строим защиту вокруг именно устройства, делая его доверенным звеном, а всю размытую сеть Cisco - набором доверенных элементов. Но про эту концепцию я напишу как-нибудь отдельно.

Ну и в заключение минутка юмора. Классический мультфильм на тему незащищенного периметра. Я его еще лет 20 назад показывал на различных мероприятиях по ИБ:



02.11.2017

Мониторинга много не бывает или зачем вам SOC, если у вас нет SIEM?

Осень выдается достаточно урожайной на мероприятия, посвященные теме мониторинга информационной безопасности. И на многих из них я часто слышу вопрос от коллег, который звучит очень просто: “Что должен уметь делать SOC?”. Как мне кажется, если такой вопрос возникает, то это значит, что компания еще не готова к SOC, так как в отличие от коробочных продуктов, сравниваемых по функциям/возможностям, SOC строится под конкретную компанию, под конкретную задачу. Поэтому бессмысленно спрашивать, что должен уметь делать SOC. Важнее понять, зачем он нужен и что будет делать, если компания решится инвестировать в него деньги. По этой же причине совершенно бестолково сравнивать SOCи между собой. Даже если они и построены на базе общих технологических решений, они могут решать совсем разные задачи, затачиваться под разные сценарии (use cases).

Посмотрите на эту картинку:


Она иллюстрирует упрощенную модель зрелости процесса управления журналами регистрации (log management). На каком уровне вы находитесь? Ответье честно сами себе. Если вы не достигли финального, пятого уровня (то, что находится в самом низу - это нулевой уровень), то о каком SOC может идти речь? Впору задуматься о SIEM, системе мониторинга ИБ. Кстати, неслучайно в нормативных документах той же ФСТЭК говорится о сборе событий безопасности, а не о мониторинге; это высший пилотаж, который могут потянуть далеко не все. Да, отсутствие NTA, EDR, UEBA, IRP (SOAR), CASB и других технологий тоже говорит, что вам пока рано думать о SOC, но управление логами - это основа основ мониторинга ИБ.

Я уже не раз писал, что в России не хватает фокусных мероприятий по тем или иным темам. Да, есть SOC Forum, целиком посвященный центрам мониторинга ИБ. Но в нем, по сути, мы перескочили через базу - через системы мониторинга (SIEM), без которых SOC не построишь. Хотя вон “Перспективный мониторинг” везде говорит, что у них в SOC нет SIEM, а все базируется на системе TIAS собственной разработки. Кстати, собственные разработки в области SIEM - это один из трендов российского рынка. Как раньше все разработчики создавали DLP-решения, так сейчас пришла пора для систем мониторинга, нужда в которых есть, а применять решения зарубежные боязно. Кто-то санкций боится, кому-то и вовсе запрещено применять иностранное, а кому-то нужно решение сертифицированное.

И вот на фоне этих обстоятельств и родилось еще одно мероприятие, которое пройдет 21-го ноября в Москве. Речь идет о научно-практической конференции “Мониторинг информационной безопасности - проблемы построения и эксплуатации”, проводимой ЦБИ. Когда я узнал об этом мероприятии (а меня пригласили модерировать одну из его секций), то у меня возник закономерный вопрос. 22-го же ноября проходит SOC Forum; не будет ли пересечения у этих двух событий, посвященных схожей теме? Но внимательно посмотрев на предварительную программу и пообщавшись с организаторами, я склоняюсь к мысли, что пересечений у конференции ЦБИ и SOC Forum будет немного.

Во-первых, мероприятие ЦБИ фокусируется на системах (SIEM), а не центрах (SOC) мониторинга. На нем будут говорить про масштабирование SIEM, работу с разными источниками данных, их нормализацию, оценку полноты данных и т.п. То есть речь пойдет одновременно и о научных аспектах, и о практических. Во-вторых, конференция “Мониторинг информационной безопасности” организована известным российским вендором со сложившейся клиентской базой. Поэтому предположу, что целевые аудитории у двух мероприятий будут разные. Кстати, это будет не совсем моновендорная конференция - в программе заявлены представители разных игроков рынка - Microsoft, РТ-Информа, Кода безопасности, НТЦ Вулкан, НИИАС, Infowatch, Крока, СолидЛаб, Газинформсервиса, ГНИВЦ ФНС и т.п. (это помимо ряда крупных заказчиков, которые будут делиться своим опытом применения систем мониторинга ИБ). В третьих, у мероприятия ЦБИ заявлено еще два интересных момента - объявление грантов на инновационные разработки в области мониторинга ИБ и сбор и формулирование предложений по совершенствованию нормативной базы в области мониторинга ИБ. Учитывая активную работу ЦБИ с отечественными регуляторами, может получиться донести до ФСТЭК, начавшей лицензирование SOC, и ФСБ, планирующей аккредитацию центров ГосСОПКИ, определенные правильные мысли. А если вспомнить, что на отдельных слайдах ФСТЭК в свое время проявлялась тема разработки требований по сертификации SIEM, то становится еще интереснее...

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


01.11.2017

DNS как улика

Выступал на Russian Internet Week с рассказом про угрозы со стороны DNS и использование DNS как инструмента для проведения расследований инцидентов, защиты бренда, поиска сайтов-клонов и т.п. задач. Выкладываю презентацию:



Скачать ее можно с Dropbox. Кроме того, сегодня вышла и одноименная статья, которая по сути является текстовой версией (пусть и немного урезанной и менее иллюстрированной) этой презентации. Я ее писал для "ИТ Менеджера".

ЗЫ. Самое интересное, что описанные в презентации методы хакеров (тот же Fast Flux или DGA) могут использоваться пользователями для обхода блокировок анонимайзеров и VPN, закон о которых вступил в силу сегодня. Раньше ИТ-подходы находили свое отражение по ту сторону баррикад, а сейчас, похоже, будет обратный процесс.

31.10.2017

Сиюминутность ИБытия или анализ страхования рисков и блокчейна в исторической перспективе

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

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

Другой пример - страхование киберрисков. После статьи в Коммерсанте о готовящейся инициативе по обязательному страхованию киберрисков (по аналогии с ОСАГО), все заговорили о том, как это своевременно и нужно. Однако мало кто вспомнил, что теме страхования информационных рисков в России уже 20 лет (будет в следующем году). Еще в 1998-м году было подписано Соглашение о сотрудничестве в области страхования информационных рисков между Госкомсвязи России и страховыми организациями (№6836 от 10.11.98). Спустя месяц было Госкомсвязью было подписано Указание от 4 декабря 1998 года №121-У "О реализации соглашения о сотрудничестве в области страхования информационных рисков", в котором упоминались среди прочего уже разработанные документы, которые должны были лечь в основу нового законодательства по страхованию информационных рисков (в точ числе и обязательного). Среди этих документов:
  • Проект Концепции страхования информационных рисков
  • Проект Концепции развития системы страхования информационных рисков
  • Отчет "Анализ объема отечественного рынка информационных систем, ресурсов и технологий как объектов страхования".
  • Отчет "Анализ страхового поля по страхованию ответственности разработчиков, изготовителей и поставщиков систем автоматизации банковской деятельности, систем и средств защиты информации, информационных ресурсов и технологий, а также информационно - вычислительных и автоматизированных систем различного назначения".
  • Отчет "Анализ статистических данных по безопасности информационных систем с целью определения вероятности страховых случаев и размеров предполагаемого ущерба".
  • Отчет "Анализ методических и нормативных документов в деятельности зарубежных и отечественных страховых компаний и подготовка проектов соответствующих организационно - методических документов по страхованию информационных рисков". 
  • Проект Правил страхования (информационных рисков) информационных систем, информационных ресурсов, технических и программных средств вычислительной техники и оргтехники предприятий, организаций, учреждений и граждан. 
  • Технико - экономическое и социальное обоснования эффективности операций по страхованию информационных рисков. 
  • Проект Методики управления информационными рисками. 
  • Проект Методики оценки стоимости информационных систем, ресурсов, программных и технических средств вычислительной техники как объектов страхования. 
  • Проект Положения и инструкции о проведении экспертизы информационных систем, технологий, программных ресурсов, технических и программных средств вычислительной техники при заключении договора страхования и при возникновении страхового случая.
Второй виток интереса к теме страхования информационных рисков случился 5-тью годами позже (основным застрельщиком был ВНИИПВТИ), когда возникла тема с законопроектом об обязательной гражданской ответственности государственных информационных систем. В трехглавый закон "Об информации, информатизации и защите информации" планировали внести новую статью 22.1 "Страхование информационных ресурсов, систем, технологий и средств их обеспечения" с всего двумя пунктами  (аналогичная норма должна была войти в закон "Об информационных ресурсах и информатизации в г.Москве"):
  1. Государственные информационные ресурсы, системы, технологии и средства их обеспечения подлежат обязательному страхованию. Порядок и условия страхования определяются законодательством Российской Федерации.
  2. Негосударственные информационные ресурсы, системы, технологии и средства их обеспечения страхуются в порядке, установленном законодательством Российской Федерации.
Позже планировалось разработать отдельный закон "Об обязательном и добровольном страховании информационных рисков", а также внести ряд поправок в нормативно-правовые акты по страхованию, банковской деятельности и т.п.

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

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

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


30.10.2017

Особенности построения национальных центров мониторинга киберугроз

В пятницу довелось мне выступать на алматинском Kaz'Hack'Stan, этаком казахстанском аналоге PHDays. Очень интересное мероприятие оказалось и на удивление огромное количество народу - чуть более 2000 человек. Для Алматы это очень много.


На пресс-конференции прозвучала цифра - 30 тысяч ИТ-выпускников в год и только 1% из имеет отношение к ИБ-специальностям, то есть всего около 300 человек. В ФБ прозвучала иная цифра - выпускается всего 60-70 безопасников в год, а всего ИТшников - 11 тысяч. В любом случае цифра в 2000 участников - это очень много, что не может не вызывать уважения и удивления, как организаторам это удалось.


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

Основная же презентация была посвящена особенностям построения национальных центров мониторинга киберугроз, которые в отличие от корпоративных и ведомственных  SOCов зовутся CDC (Cyber Defense Center). Вот при них я и рассказывал в течении 30-ти минут. На самом деле тема эта гораздо более объемная, но я постарался сфокусировать внимание на некоторых ключевых моментах, с которыми приходилось сталкиваться, участвуя в проектах по построению национальных центров мониторинга киберугроз.



ЗЫ. Презентация выложена на SlideShare, который заблокирован на территории России.

24.10.2017

Три мифа о специалистах SOC #socforum

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


В SOC работают квалифицированные специалисты

Бытует мнение, что в SOC работают обычно высококлассные специалисты, охотники за угрозами, аналитики, влет идентифицирующие APT и иные сложные атаки. Увы... Это миф. Даже в Европе уровень ротации специалистов SOC достигает... 90%. 90 процентов!!! О какой квалификации можно говорить в такой ситуации? Люди просто не успевают ее получить, уходя на другое место работы. Понятно, что эта цифра касается не всех работников, но даже на первой линии SOC такой показатель говорит, что специалист может пропускать атаки ввиду своей невысокой компетенции.

Нанимать в SOC надо специалистов по безопасности

Рустем Хайретдинов в ФБ любит упоминать, что он зарекся нанимать на работу сейла безопасников. Их мозги забиты мусором, который сначала надо вычистить, а потом уже прививать что-то нужное. Гораздо проще брать сейла из смежной области, а уж особенностям рынка ИБ научить несложно. Не буду спорить с данным тезисом; тем более что в SOC ровно та же самая ситуация :-) Брать надо не безопасников, а тех, кто обладает хорошими коммуникативными навыками, так нужными при расследовании инцидентов. Если они еще и знаниями ИБ обладают, так вообще супер. Но в первую очередь смотреть надо на то, как общается человек в коллективе, особенно в стрессовой ситуации, которые в SOC происходят регулярно.

Работа аналитика в SOC очень интересна

Вообще я люблю писать и могу делать это достаточно долго (вот в выходные даже 3 статьи накатал). Но даже я устаю от этого. А теперь представьте работу аналитика, который 8 часов в день (а есть SOCи, которые используют 12-тичасовую смену) пялится в экран и пытается найти угрозы в тысячах строк логов, потоков и других источников событий безопасности (даже при высоком уровне автоматизации ручная работа еще очень нескоро уйдет из арсенала безопасников SOC). Одна из классических проблем аналитиков SOC - демотивация. Изо дня в день видеть огромное количество событий и при этом не знать, какие из них хорошие, а какие плохие. Это классическая психологическая проблема боязни совершить ошибку в ответственном мероприятии. Этот страх отвлекает аналитика SOC от смысла выполняемых действий; он фиксируется на мелочах, упуская главное. Страх сделать ошибку заставляет аналитика перепроверять свои выводы и свою работу, что приводит к лишней трате времени и сил и снижает продуктивность специалистов SOC. Возможно и отсюда тоже вытекает высокая ротация в SOCах.

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

23.10.2017

Booz Allen покупает Morphick

Известный подрядчик американского МинОбороны, АНБ и других спецслужб, компания Booz Allen Hamilton (Сноуден на нее работал в процессе кражи данных АНБ), объявил 20-го октября о приобретении малоизвестной компании Morphick, одного из участников обзора Gartner по рынку MDR, а также одной из нескольких компаний, аккредитованных АНБ, на проведение расследований инцидентов в целях национальной безопасности США. Размер сделки неизвестен.

20.10.2017

Сколько инцидентов ИБ должен обрабатывать SOC? #socforum

На почти любых мероприятиях по SOC, и небольших, как круглый стол, который я модерировал на InfoSecurity Russia, и крупных, как SOC Forum, всегда возникают вопросы по тем или иным количественным характеристикам SOC. Сколько людей нужно в SOC? Сколько стоит строительство SOC? Сколько событий безопасности обрабатывает SOC? Сколько инцидентов ИБ попадает в SOC? И т.п. Надо сразу сказать, что эти вопросы НЕВЕРНЫ и правильного ответа на них не существует. Точнее все ответы будут правильными, так они зависят от кучи параметров - масштаба организации, покрываемой SOC области, определения инцидента и т.п. Но так как вопросы все равно возникают и будут возникать (особенно у тех, кто только подступается к теме SOC), я попробовал найти хоть какие-нибудь численные значения, на которые можно ориентироваться.

Итак:
  • Внутренняя служба реагирования на инциденты в Cisco обрабатывает около 2000 инцидентов в квартал. При этом угроз мы видим около 2.5 миллиардов, а число событий безопасности и вовсе измеряется десятками триллионов.
  • Наш внешний SOC (хотя аутсорсинговые центры мониторинга и реагирования на инциденты вообще сложно оценивать - очень уж разное у них количество заказчиков может быть) при около 200 миллиардах поступаемых событий "ужимает" их в 7 миллионов угроз, которые транслируются в 7 тысяч кейсов для наших аналитиков. Есть только цифры по двум из заказчиков, которые отдали нам аутсорсинг свою безопасность.
Количественные показатели по заказчику-банку
Количественные показатели по заказчику из промышленности
  • Австралийский центр кибербезопасности зафиксировал с 1-го января 2015 по 30 июня 2016 года серьезных 1095 инцидентов на государственные системы, то есть примерно (если считать, что распределение равномерное) по 60 инцидентов в месяц. Австралийский же CERT за год отработали 14804 инцидентов.
  • У британского центра кибербезопасности схожие цифры - 1131 инцидент в год (из них 590 серьезных).
  • Голландский центр кибербезопасности в год фиксирует около 600 инцидентов.
  • Центр киберзащиты HPE CDC, мониторящий и сеть HPE и сеть ее заказчиков, детектирует ежедневно около 5 миллионов атак и 2,5 миллиардов событий безопасности. Число инцидентов, которые обрабатываются аналитиками CDC, я не нашел. Предвосхищая вопрос, почему порядок отслеживаемых событий у Cisco и HPE отличается на порядок, отвечу, что HPE CDC мониторит только периметр (это только первая стадия трехэтапной стратегии развития HPE CDC).
  • У Solar Security средний поток событий безопасности в первом полугодим 2017-го года составил чуть больше 6 миллиардов в сутки, а событий с подозрением на инцидент было обнаружено 172 тысячи, то есть около 955 в сутки. 
  • Отечественной компанией "Перспективный мониторинг" за первый квартал 2017-го года было зафиксировано всего 137 миллионов событий безопасности, в которых было обнаружено 98 инцидентов ИБ.
  • На российские организации по словам секретаря Совета Безопасности в прошлом году было осуществлено несколько десятков миллионов атак.
Есть у меня в копилке и еще ряд цифр, но они уже носят непубличный характер и поэтому демонстрировать их я не буду. Но некоторые выводы могу сделать:
  1. Число инцидентов, которые обрабатывает SOC в год, измеряется несколькими сотнями в случае, если мы имеем дело с государственным центром мониторинга, и несколькими тысячами, если мы имеем дело с корпоративным SOC мультинациональной компании, офисы которой разбросаны по всему миру. При этом это число врядли превысит 7-8 тысяч. Поэтому у меня есть вопросы по данным Solar Security, которые за год около 350 тысяч инцидентов фиксирует.
  2. Государственные центры ИБ в первую очередь собирают данные об инцидентах, не занимаясь их мониторингом в реальном времени.
  3. Многие SOCи (что корпоративные, что аутсорсинговые) преимущественно ориентируются на мониторинг периметра, "забывая" или не имея возможности следить за внутренней сетью предприятия.
ЗЫ. Про особенности построения государственных центров мониторинга ИБ буду рассказывать 27 октября в рамках Kaz'Hack'Stan в Алматы.