08.11.2019

Как не ошибиться в выборе SOC-as-a-Service (презентация)

Вчера выступал на нижегородском Коде ИБ, где рассказывал про особенности выбора аутсорсингого партнера по ИБ на примере SOC-as-a-Service. Выкладываю презентацию (на Slideshare).



06.11.2019

Как защищать систему без моделирования угроз?

Сегодня совпало три события, которые и повлекли за собой написание этой заметки. Во-первых, я читал сегодня вебинар по концепции Zero Trust (если вдруг интересно, то вот ссылки на  материалы и видео). Во-вторых, а сейчас изучаю проект новой методики ФСТЭК по моделированию угроз, которая должна быть утверждена до конца года. Наконец, среди интересного проскочила новость, что исследователи нашли способ взламывать Siri, Alexa, Google Assistant с помощью лазера, который внедряет команды, заставляющие голосовых помощников открывать двери, заходить на сайты, запускать и разблокировать автомобили и т.п.

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

По сути мы являемся заложниками подхода, который заключается в том, что сначала мы моделируем угрозы, а потом разрабатываем меры их нейтрализации и никак иначе. Это даже в нормативной базе прописано. Но что делать, когда у вас не хватает квалификации для этого или система меняется достаточно оперативно, чтобы постоянно вносить правки в модель угроз? Именно в таких условиях и родилась концепция "нулевого доверия" или Zero Trust, появившаяся в 2010-м году у компании Forrester.

Первоначально она развивала идеи термина "депериметризация", родившегося ранее на Jericho Forum, и касавшаяся только сетевой составляющей. В оригинальную модель Zero Trust входило три компонента, которые позволяли повысить уровень защищенности, не доверяя статическим правилам на МСЭ, коммутаторах и точках доступа. 

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


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

 Это краткое изложении концепции Zero Trust, которая сейчас реализуется многими компаниями, - Cisco, Illumio, Okta, Google, Intel, Akamai, MobileIron и т.п. Но этот, достаточно инновационный подход для многих российских компаний врядли так быстро займет свое место на нашем рынке. Требования регуляторов по моделированию угроз и от него никуда не деться. Поэтому придется совмещать первое со вторым.

05.11.2019

Киберучения на SOC Forum 2018 (видео)

BIS TV выложило на своем канале в YouTube запись прошлогодних киберучений, который я вел на прошлом SOC Forum 2018. Меня многие спрашивали то презентацию с них, то примеры сценариев, и вот теперь есть возможность увидеть не только это, но и саму процедуру их проведения. В обычной жизни они проходят не так пафосно и пишутся под конкретную организацию, но и данное видео очень неплохо показывают всю концепцию и ее реализацию.


ЗЫ. Остается всего две недели до нынешнего форума

27.10.2019

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

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


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

По сути речь идет о попытке обосновать нужду в ИБ опираясь на три составных части, которые "заинтересованы" в атаках и защите от них - пациенты, регуляторы и хакеры. Но как мы уже поняли, первым двум категориям в целом ИБ не так уж и важна. А третья... А что третья? Как она может монетизировать атаки на медицинские учреждения? Социнжиниринг? Может быть, но маловероятно, так как что можно заставить сделать пациента, которому представились представителем его медучреждения? Повторно сдать анализы?


Но... давайте посмотрим чуть шире и попробуем встать на место конкретного пациента, который ходил не только в поликлиники по врачам, но и может лечь в стационар на 2-3 недели. Что можем ему помешать "насладиться" лежанием в больничной палате? Отсутствие Wi-Fi, выведенного из строя хакерской атакой? Может быть, если речь идет не о Москве с его безлимитным LTE. Подмена лекарств или рецептуры в электронной карте больного? Тоже может быть. Но пока не в России, где электронные карты - еще редкость. Шантаж родных, близких и знакомых разглашением факта "плохой" болезни? Да, вполне. В свое время представители РКН и Госдумы именно под этим соусом продвигали ФЗ-152 в его жесткой редакции. Еще утечка может быть актуальной в тех случаях, когда среди пациентов есть всяческие селебрити - звезды шоу-бизнеса, чиновники, телеведущие и т.п. Из информации об их болезнях можно сварганить репортаж, который привлечет массу людей, рекламодателей и т.п. Вспомните, непрекращающуюся последние пару месяцев эпопею с "болезнью" Заворотнюк...

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


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

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

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

23.10.2019

Запор Ярилы, стезя педагогона или старославянский словарь импортозаместителей от ИБ

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

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

Какие еще у нас могут быть применимы слова старославянского языка в кибербезопасности? Вот список, например, для английских слов, столь популярных в лексиконе отечественных безопасников:
  • backdoor - афедрон
  • blackholing - хлябь
  • Cisco - лепота
  • CISO - воевода, стража, стратиг, стратилат
  • compliance - путы 
  • CTF - палестра, ристалище 
  • dlp - брещи
  • Huawei - стезя педагогона
  • Infosecurity Russia - позорище 
  • SIEM - многоочитый 
  • SOC - чертог.

А теперь список англицизмов и соответствующих им посконно русских синонимов:
  • админ, оставивший сервер ElasticSearch в открытом виде - кукомоя
  • атаковать - уязвлять 
  • блокчейн - пленица 
  • безопасник - поборник 
  • бумажный безопасник - законник
  • вирусная эпидемия  - проказа, лепра 
  • деятельность без лицензии - забобоны
  • идентификатор - ипостась
  • инсайдер - афарим, сходник
  • инцидент - тля 
  • киберпреступник - окаянный, пакостник, тать 
  • конфа по ИБ - глумилище
  • кража - татьба 
  • тайновидец - криптограф 
  • лицензия - вериги
  • место для лицензий регуляторов - красный угол 
  • метрика - литра, мерило 
  • межсетевой экран - мандра (это еще и названием собственным может стать), вратарь, вратник
  • облако - мгла, морок 
  • оплата аутсорсинговых услуг - оброк
  • отказ системы - долгонедужие
  • патч - плат 
  • последователи реальной безопасности, отрицающие ФСТЭК и ее требования - штундисты 
  • реестр российского ПО Минкомсвязи - буява
  • рынок сертифицированных средств защиты информации - вертеп
  • система обнаружения вторжений - мрежа, бредень
  • сотрудники службы ИБ - челядь
  • социальный инжиниринг - искушение
  • требования по ИБ - умовредие
  • уязвимость - язва
  • фейковый аккаунт - личина, харя, лярва
  • ФинЦЕРТ - нощный вран
  • фишинговые учения - козни
  • фишинг - прелесть 
  • ФСТЭК - доилица, кормило 
  • хакер - супостат, боритель
  • чиновник - косноязычный 
  • штраф за нарушение требований по защите информации - епитимия
  • 8-й центр - капище
Обладая таким словарем можно уже спокойно найти патриотические аналоги столь привычных нам названий наших компаний и продуктов по ИБ:
  • Infowatch - Инфоглядун, Инфосоглядатай или Инфооко
  • Secret Net - Тайный Невод
  • ViPNet - Знатный Невод
  • DIONIS - Корс (это уже не греческий, а славянский бог пьянства)
  • Secret Studio - Тайная светлица
  • Комрад - Товарисч
  • UserGate - Холопские врата
  • Мастерчейн - Гривнозлатарь
  • Перспективный мониторинг - Узреющая ворожения.
Согласитесь, так все звучит гораздо лучше и в русле взятого в России на хоругвь импортозамещения в области кибербезопасности. Получив основы старославянского языка, дальше вы можете и сами переложить отечественные ИБ-названия на язык, который скоро может вернуться в обиход.


21.10.2019

Эскалация инцидентов ИБ

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


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

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

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

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

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

При эскалации одной из важнейших задач является обоснование для нее. Я, как, думаю, и многие люди, не всегда объясняю причины своих поступков, считая, что "все же и так очевидно". Вот в эскалации такая фигня не работает - чтобы эскалация прошла успешно, должна быть веская причина. "Я так хочу", "Это же очевидно", "Я же босс" к таковым не относятся. Интересно, но когда пытаешься внятно сформулировать, зачем тебе нужна эскалация, часто получается, что она и не нужна :-) Если же верно все-таки обратное, то обоснование для эскалации должно быть бизнес-ориентированным. "Данный инцидент может стать достоянием СМИ и надо подготовиться", "Несмотря на стандартные двое суток на решение данного типа инцидента, нам надо его решить к завтрашнему совету директоров", "По результатам расследования стало известно, что утекло не 1000 записей о клиентах, а 1 миллион записей", "Шифровальщик заразил компьютеры бухгалтерии и они не успевают сдать отчетность в налоговую, что может привести к штрафам" и т.п.

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

15.10.2019

Приоритезация инцидентов ИБ: все не так просто

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


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

Но дело даже не в этом, а в том, что все инциденты ИБ считаются равнозначными. Я неоднократно в рамках киберучений задавал вопрос о том, надо ли на основе полученной информации изменить приоритет инцидента или нет. И судя по многочисленным ответам и не только на этих киберучениях, это оказалось достаточно распространенной проблемой. Но если вдуматься, мы же понимаем, что не все инциденты одинаковы. Например, заражение шифровальщиком ПК секретарши или сервера АСУ ТП, утечка 5000 записей о клиентах или 60 миллионов, простой на 1 час или на неделю... Как минимум, по уровню ущерба инциденты сильно отличаются друг от друга. Я в мае уже писал про варианты оценки ущерба от инцидентов ИБ. Это один, и самый популярный, пожалуй, из вариантов классификации инцидентов ИБ. Градации вы можете определить самостоятельно - обычно их пять, но это число может быть и три, и шесть, и семь, и девять. В зависимости от направления бизнеса и варианты ущерба могут быть разные.


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


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


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


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


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

ЗЫ. Пытливый читатель мог бы задаться вопросом - а что, если в процессе расследования окажется, что инцидент масштабнее, чем предполагалось изначально? А что если мы не уложимся в отведенное время? А что если понадобится принять решение, выходящее за рамки полномочий лица, на чьем уровне принятия решения сейчас находится инцидент? Для всех этих случаев потребуется эскалация, о которой разговор пойдет в другой раз.

14.10.2019

Вас шантажируют утечкой данных. Что делать?

Весной 2019-го года, на CISO Forum, я проводил киберучения, где среди прочего был и такой кейс - вы получаете сообщение через соцсети (чат в Facebook Messenger, Telegram, Whatsapp, Viber и т.п.) от человека, который называет себя известным в отрасли ИБ именем и который заявляет, что нашел в Darknet доказательства утечки у вас базы данных. Он, разумеется, готов вам помочь провести расследование данного инцидента. Следующий кейс - этот же человек публикует в открытом доступе информацию об утечке в вашей компании и вы сталкиваетесь с запросами со стороны СМИ.


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

Вот представьте, что пока вы читаете эту заметку, к вам пришло сообщение о том, что ваша база клиентов утекла и ее продают в Darknet? Что вы будете делать? Если собрать все, что звучало в рамках киберучений (не только двух упомянутых) и добавить кое-что от себя, то вырисовывается следующий набор действий, который надо делать в таких ситуациях.

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

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

07.10.2019

Применение роботов (платформ RPA) для кибербезопасности

В сентябре на Хабре я написал большой материал про мониторинг ИБ облаков (первая и вторая части). Среди прочего я описывал достаточно частую ситуацию, встречающуюся у облачных провайдеров. Журналы регистрации событий доступны, но выгрузить их можно только в ручном режиме - сформировать лог за интересующий временной интервал и скачать к себе на компьютер  в виде таблички Excel или CSV-файла. При этом делать это на регулярной основе непросто и можно в какой-то момент времени забыть сделать выгрузку, потеряв часть данных для анализа. Можно ли автоматизировать выгрузку таких данных при полном отсутствии API?


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

Что умеют  роботы RPA? Они работают с Web-формами, приложениями, почтой, документами, базами данных, файлами на диске или в Интернет, которые могут быть преобразованы по заданному сценарию или алгоритму. Такой робот:
  • позволяет снизить число ошибок
  • работает круглосуточно, без выходных и не требует сверхурочных
  • объединяет данные из разных систем, сокращая время на работу с ними
  • легко  подстраивается под изменчивый процесс
  • не требует интеграции в существующую инфраструктуру.
Внедрение робота занимает немного времени - от 2-х дней уходит на изучение процесса, определение необходимых приложений и ИС, с которыми нужно работать, и снятие скриншотов действий пользователя. От 5-ти дней уходит на настройку робота - сценариев его работы и взаимодействия с нужными системами. От 3-х дней уходит на тестирование и доработку робота. Для простых случаев автоматизации внедрение робота займет около 10 дней - в более сложных может понадобиться 1-2 месяца.


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

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

  • Заход в личный кабинет ФинЦЕРТ или ГосСОПКА для получения бюллетеней или уведомлений
  • Обогащение событий безопасности из источников TI
  • Заведение тикетов в IRP / SOAR
  • Анализ заявок на предоставление доступа к корпоративным ресурсам
  • Организация фишинговых симуляций
  • Сбор облачных логов в Excel/CSV и загрузка их в SIEM
  • Анализ входящих сообщений от пользователей
  • Работа с унаследованными или legacy системами ИБ
  • Тестирование защищенности Web-приложений
  • Сбор инвентаризационных данных из десятка источников и приведение к единому формату с загрузкой в CMDB
  • Мониторинг Интернет-ресурсов, а также анализ новостей по ИБ и отправка ключевых во внутреннюю рассылку
  • Построение dashboard
  • Получение согласий на обработку ПДн от клиентов
  • Уведомление о нарушении прав субъекта ПДн.
Это неполный перечень, но он достаточно показательный. С помощью RPA можно автоматизировать многие рутинные задачи, возникающие в деятельности ИБ. Кто выпускает RPA-платформы? Вот список некоторых вендоров, которых можно встретить в России, - UiPath, Automation Anywhere, Blueprism, WorkFusion, Pegasystems, NICE, Kryon, Kofax, Contextor, Softomotive, Redwood Software, EdgeVerve, Another Monday, Antworks, Toughtonomy, SAP iRPA, Datamatics Trubot, Jacada, NTT-AT, Helpsystems, Servicetrace, Robin, PIX, HyperUp, electroNeek.

23.09.2019

Измерение эффективности ИБ промышленных систем

На прошлой неделе мне довелось выступать на конференции Kaspersky ICS Cybersecurity Conference с докладом, посвященным оценке эффективности ИБ промышленных систем. Оказалось, что я удачно дополнил доклад выступившего передо мной Патрика Миллера из Archer про коммуникации с бизнесом. У меня же доклад был более приземленный с примерами метрик, которые могут быть использованы при оценке своей эффективности и последующей коммуникации с бизнесом.


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

Выкладываю свою презентацию:



09.09.2019

Разъяснения Банка России с осенной сессии Уральского форума

На прошлой неделе прошла конференция, организатором которой стал Банк России, и которая стала выездной сессией Уральского форума, проведенной в Москве. На ней регулятор попробовал ответить на животрепещущие вопросы, касающиеся как ЕБС, так и недавно выпущенных, но уже вызвавших немало вопросов нормативных актов (683-П, 684-П и т.п.). Параллельно с этим, как член ПК1 ТК122 я собрал с отрасли около 50 вопросов, которые были направлены в Департамент ИБ Банка России с целью получения ответов на них. И вот часть таких ответов прозвучала на конференции. Позволю себе тезисно озвучить то, что было озвучено.

Единая биометрическая система
  1. Банк России опросил 38 банков, 7 из которых планируют делать свои собственные решения для подключения к ЕБС. Остальные хотят использовать типовое решение, самых распространенных сейчас четыре - от Ростелекома, Инфотекса, ЦФТ и IDSystems.
  2. Стоимость облачного решения Ростелекома - около 3 миллионов рублей в год. Стоимость типового решения - 5 миллионов (включая инфраструктуру построения, HSM, антивирусы и т.п.).
  3. Типовое решение уже включает тематические исследования и финансовым организациям проводить их не требуется.
  4. Покупка типового решения не отменяет выполнения методички Банка России МР-4.
  5. По словам ЦБ, ряд разработчиков типовых решений делают только сбор биометрии, без предоставления функции верификации, что неправильно по мнению регулятора.
  6. Стоимость собственной разработки (в качестве примера был приглашен Тинькофф) обходится примерно в те же 5 миллионов. Но это все без резервирования тех HSM. С резервированием - стоимость увеличивается еще примерно на 3-4 миллиона. Длительность создания собственного решения у Тинькофф составила 4-5 месяцев без тематических исследований.
  7. Обсуждалась тема мобильного сбора биометрии, для которой максимальный возможный класс сертификации СКЗИ озвучивался как КС2. Готовых решений пока нет, но Ростелеком работает над ним. При этом вопрос качества собранной биометрии с помощью планшета или смартфона не обсуждался совсем.
  8. Для удаленного сбора должны применяться только СКЗИ КС3 или КС2 но с соблюдением. требований к СВТ 4-го класса. Пока обойти эти требования или снизить нельзя. 

683-П / 684-П / 672-П
  1. Планируется кардинальное изменение 382-П, из которого уберут упоминание кредитных организаций (операторов по переводу денежных средств). 382-П будет распространяться на участников НПС - некредитные организации, а также на новые сущности, введенные последними правками в 161-ФЗ - платежные агрегаторы, разработчики платежных приложений, операторы информационного обмена (SWIFT, привет!). Защита информации при осуществлении переводов денежных средств уйдут целиком под 683-П, который покрывает все банковские операции. 
  2. ЦБ считает, что анализ уязвимостей можно проводить своими силами, если есть для этого возможности, навыки и квалификация. Но пока непонятно, как отсекать некачественно проведенную оценку. ЦБ думает над этим.  
  3. На вопрос о том, что является доказательством проведения анализа уязвимостей, если это делает производитель платежного ПО или привлекаемый лицензиат, ЦБ подготовит разъяснение. Надо внимательно посмотреть ГОСТ 15408 в части представления результатов оценки.
  4. В августе ЦБ разослал письмо по кредитным организациям, в котором говорится, что с учетом принятия ГОСТ 57580.1/57580.2 и 683-П, направлять оценку по СТО БР ИББС 1.2-2014 больше не требуется. Ее проведение остается на усмотрение кредитной организации. Когда кредитные организации выведут и из под 382-П, то у них останется единственная оценка соответствия - по ГОСТу. Надзор ЦБ больше не будет руководствоваться СТО БР при проведении своих мероприятий.
  5. 202-я форма будет пересмотрена.
  6. Документ по операционным рискам (с резервирование капитала и прочим блэкджеком) будет очень плотно завязан на новый ГОСТ по управлению киберрисками, который сейчас активно пишется и в октябре будет представлен членам ПК1 ТК122. Так что можно ожидать, что до конца года положение по операционным рискам будет все-таки принято.  
  7. На вопрос о том, почему 683-П и 684-П местами так отличаются друг от друга, прозвучало, что хоть они и писались ДИБом, но затем сильно перерабатывались соответствующими - департаментами банковским и НФО.
  8. Несмотря на то, что в 684-П прямо не упомянуты (при установлении уровней защиты) микрофинансовые организации, ломбарды и ряд иных, на них распространяются общие требования, прописанные в 684-П (защита от вредоносного кода, уведомление клиентов о рисках и т.п.).
  9. Если кредитная организация ведет депозитарную и репозитарную деятельность, то применять необходимо и 684-П, даже несмотря на то, что у него сфера деятельности - некредитные финансовые организации. Но, учитывая, что кредитные организации обязаны также выполнять и 683-П, то при пересечении требований выполняться должны те, которые жестче, то есть, по сути, 683-П. 
  10. По поводу SMS и Push ЦБ считает, что не обязательно применять УКЭП. Можно использовать и другие меры подтверждения целостности без УКЭП. Сейчас завершается подготовка информационного письма для этого.
  11. Было озвучено, что есть правовые проблемы с использованием облачным провайдером ЭП банка (ключи нельзя передавать третьим лицам). ЦБ вроде как нашел с ФСБ некое решение, но у них есть сомнение в его правомерности. Если в новую редакцию 63-ФЗ внесут "третью доверенную сторону", то проблема разрешится. Пока этот вопрос в серой зоне и каждая кредитная организация решает его для себя самостоятельно.
  12. ГОСТ допускает применение несертифицированных средств защиты при отсутствии их на рынке (техническая невозможность) или высокой цены (экономическая нецелесообразность). Это и так было понятно, но тут это прозвучало еще раз на прямо заданный вопрос.
  13. Вновь прозвучала мысль, которая звучит последние лет 10, что ЦБ не интересует КАК будут реализовываться защитные меры и какие конкретные технические решения будут применяться. Финансовые организации сами выбирают способ реализации. Для ЦБ важна оценка уровня риска, для чего ЦБ сейчас внедряет новый риск-ориентированный подход, который будет оценивать каждую организацию по набору показателей.

Перспективы и планы

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

04.09.2019

Почему ВУЗы не преподают теорию игр специалистам по ИБ?

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

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

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

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

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

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


За последний год проект существенно обновился и "вырос" - появились различные варианты подписки - для ВУЗов, для корпоративных пользователей и т.п.


Есть различные сценарии проведения игр с разным числом участников и разными заданиями.


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


Есть в Project Ares и развлекательные компоненты, например, "пасьянс "Косынка" на тему ИБ:


или аналог "Своей игры":


или аналог "Змейки":


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


Но стали появляться и компьютерные игры, доступные каждому желающему. Например, на игровой платформе Steam скоро выпустят игру ThreatGEN: Red vs Blue, которая позволит множеству игроков попробовать себя в роли хакеров или защитников, не ломая реальные сети и системы, но оттачивая свои стратегические и тактические навыки, которые можно будет применять в реальной жизни (конечно, с оговорками). 

У этой игры будет несколько версий:
  • Red vs Blue. Игра для всех желающих на платформе Steam.
  • Red vs Blue Corporate. Настраиваемые сценарии игр для корпоративных тренингов.
  • Red vs Blue CTF. Соревнования команд.
  • Red vs Blue Tabletop. Игра для проведения штабных киберучений.
  • Red vs Blue Instructor Led Training.
Несмотря на громкое название заметки, я не ставил перед собой цель написать учебник или пособие по теории игр для кибербезопасника (все-таки я учил эту дисциплину в качестве факультатива, для себя лично, уже после окончания ВУЗа, и не могу сказать, что я в ней специалист). Скорее мне хотелось показать, что сегодня, в условиях непрерывно меняющихся технологий, атак, нормативки, и постоянно устаревающих знаний, подходы к обучению (в том числе и корпоративному) должны меняться. И геймификация, построенная на теории игр, является одним из инструментов решения этой задачи.

03.09.2019

Deepfake: обход биометрии, непредусмотренный регуляторами

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



Меня эта тема интересует последние пару лет, когда только появилось первое приложение DeepFake и когда Банк России стал семимильными шагами внедрять Единую Биометрическую Систему (ЕБС). Когда ЦБ выпустил свое Указание 4859-У, то я надеялся, что там такого рода угрозы найдут отражение, но все, что хоть как-то можно отнести к ним, это расплывчатая формулировка про актуальность угроз нарушения целостности (подмены) биометрических персональных данных. Настолько абстрактное понятие, что даже непонятно, о чем идет речь - о deepfake или о подмене свертки биометрического фактора?

Была надежда, что в 321-м приказе МинЦифры или в МР-4 Банка России включат раздел про нейтрализацию таких угроз, но увы. И эти документы оказались далеки от прикладных атак, концентрируясь либо на применении криптографии, либо на применении сертифицированной ОС, МСЭ и антивируса, напрочь забыв даже про защитные меры из 21-го приказа ФСТЭК по защите ИСПДн. Последний, перекрывая по своему содержанию и МР-4 и приказ №321, тоже ни слова не говорит о том, как. бороться с deepfake.

Самое неприятное, что на различных мероприятиях или в соцсетях, где присутствуют участники процесса, связанного с ЕБС, упорно обходят молчанием эту тему, даже если им задаешь напрямую вопрос о том, как бороться с этой проблемой. Хоть какой-то ответ я нашел в одной презентации "Центра речевых технологий", чьи технологии используются в ЕБС, например, у того же Банка "Открытие" и ряда других (решение VoiceKey.INSPECTOR). Правда, используются они при сборе биометрии, а проблема с deepfake возникает на этапе ее проверки в режиме повседневной эксплуатации.

Если посмотреть на классический жизненный цикл биометрической, то он в обязательном порядке должен содержать этап проверки "живости", без которого биометрия не имеет никакой ценности, несмотря на использование СКЗИ класса КВ или даже КА.


В своих материалах ЦРТ приводит методы проверки живости для изображения лица, как биометрического признака:

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

Но какие из этих методов реализованы в ЕБС не совсем понятно. В описании того же "Ключа" от Ростелоекома говорится о liveness detection, но без каких-либо деталей и уточнений. А судя по презентациям отдельных банков, которые бодро отрапортовали о том, что они не только интегрировались с ЕБС, но и внедряют уже биометрию в свои банковские процессы, далеко не все понимают угрозу deepfake и борются с ней. Например, один из банков предлагает возможность перевода денег без указания номера карты или телефона, "просто сфотографировав получателя". В данной схеме даже liveness detection никакого нет - работа со статическим биометрическим признаком, который подделать ничего не стоит.

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

Если посмотреть на обратную сторону, на то, что можно противопоставить deepfake, то тут исследований не так уж и много. На последних крупных конференциях по ИБ я вспомнил только одно. А вот с готовыми решениями по этой теме, что-то не густо. Что-то встроено в сами биометрические решения, но не во все. В отличие от идентификации фальшивых изображений (OZ Forensics) или собственно самой биометрической идентификации. И тут остается полагаться на здравый смысл безопасников, которые будут следовать не только нормативных актам регуляторов, но и самостоятельно задавать вопросы производителям внедряемых решений о том, как те борятся с deepfake. Ибо цена ошибки достаточно высока, а ответственности за взлом биометрической системы регуляторы не несут; как и сами вендоры, которые продают свою решения по принципу "AS IS". Как минимум, стоит посмотреть в сторону решений по многофакторной аутентификации, которые могут частично. нивелировать проблемы, связанные с низкой защищенностью биометрии.

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

02.09.2019

От. 2,5 до 5 часов за смену тратят аналитики SOC на работу с инцидентами

В августе я уже делал обзор двух отчетов, SANS и Exabeam, по центрам мониторинга ИБ (SOCам) и вот в руки попало еще один - от CriticalStart. В нем есть несколько интересных цифр о том, как аналитики SOC занимаются своей ежедневной деятельностью. Например, часто звучащий вопрос о том, сколько в среднем инцидентов ИБ в день, попадает в SOC? Я пару лет назад уже писал об этом, давая ссылки на конкретные организации, которые делились своей статистикой. В отчете CriticalStart, который стал результатом опроса около 50 различных корпоративных и аутсорсинговых SOC и MDR, приводится некая средняя цифра - 70% аналитиков расследует более 10 инцидентов в день на каждого. Достаточно большое число; особенно удивляет, что 7% аналитиков более 50 инцидентов в день отрабатывает, то есть по инциденту за 10 минут (!).


Понятно, что отчет показывает среднюю температуру по больнице, но в целом получается, что 95% инцидентов расследуется максимум за 20 минут. Если немного усреднить первые два параметра, то получается, что аналитики тратят на исследования инцидентов от 2,5 до 5 часов за смену (в прошлом году я писал про другое исследование по распределению времени у аналитиков SOC).


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


А вот дальше интересно. На вопрос, что вы делаете с большим количеством сигналов тревоги, 39% аналитиков... игнорируют некоторые категории алертов! Прекрасное решение :-) 38% отключают регистрацию большого числа событий. Также 38% (данный вопрос подразумевал множественный выбор) просто нанимает большее число аналитиков.


В прошлом году у 70% аналитиков основной целью называлось анализ и снижение числа угроз. В этом году этот показатель хоть и остался на первом месте, но снизился до 41%. А высвободившиеся 30% ушли на "тиранию алертов", то есть снижение времени на борьбу с ними (пятикратный рост по сравнению с прошлым годом) и расследование как можно большего их числа (трехкратный рост).


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


28.08.2019

Уберизация SOCов

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

Итак, представим, что нам нужно добраться из точки А в точку Б на автомобиле. У нас есть три возможности:
  • Собственный автомобиль. Удобный и полностью контролируемый способ передвижения. Но и самый дорогой из всех.
  • Аренда автомобиля, например, через Яндекс.Драйв. Этот вариант дешевле собственного авто, но бензин вы оплачиваете сами и водить вы будете самостоятельно (или надо нанимать водителя). Яндекс.Драйв предоставляет. вам только средство передвижения, не более того. Все остальное - ваша прерогатива.
  • Услуга такси, например, через Яндекс.Такси. Вы просто заказываете такси, которое приезжает и отвозит вас, куда скажете. Вам ничего не надо делать, только сделать заказ и оплатить его.
Если посмотреть на российский рынок центров мониторинга ИБ, то у вас только две альтернативы, - построить SOC самостоятельно или заказать услугу в аутсорсинговом SOCе. В мире же рынок SOCов выглядит немного иначе - помимо указанных двух вариантов предоставляется еще и третий, аналогичный Яндекс.Драйву. Вы обращаетесь к компании, которая сдает вам платформу для управления SOCами в аренду. То есть вам не надо покупать SIEM, IRP/SOAR, TIP и другой инструментарий SOC, но при этом аналитики должны быть ваши, как и выстроенные процессы, playbook, runbook и т.п.

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

Если возвращаться ко всем трем вариантам, то у каждого из них есть свои преимущества и свои недостатки. Но в вариантах "Яндекс.Драйва" и "Яндекс.Такси" важно понимать, что услуга может быть оказана по-разному. Вспомним,  что у Яндекса есть несколько пакетов оказания услуги - Эконом, Комфорт, Комфорт+, Бизнес, Премиум. Многие берут первое из-за экономии. Но тогда без претензий по качеству. “Дорогу покажешь, дарагой” - такого уже почти нет (благодаря Яндекс.Картам), но слушать радио “Восток” всю дорогу и смотреть как водила чатится с кем-то, попутно еще и руля, стремно. Стоит ли экономия таких рисков?

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


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

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

Может тогда стоит посмотреть в сторону Яндекс.Драйва облачной платформы SOC или построения собственного SOC? Я ни в коем случае не призываю отказываться от аутсорсинга SOC и не говорю, что это все профанация (тем более, что Cisco сама оказывает такие услуги, но не в России). Просто стоит все очень серьезно взвесить, задумывась о передаче SOC в чужие руки (не забыв задать и ранее мной описанные вопросы). И только потом принимать взвешенное решение.

27.08.2019

Как НЕ надо выбирать SIEM?

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

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

Не выбирайте SIEM, потому что это модно

Ну это вроде и так понятно. Выбирайте не то, что модно, а то, что нужно. Это простая истина применима не только к SIEM, но и вообще к любому хайпу - от SOCа до блокчейна, от WAF до CASB. Для этого вам, правда, нужно знать, что нужно :-) А поняв это, вы поймете, как этого достичь и, только потом, сможете определиться с инструментарием для этого.

Не выбирайте SIEM под требования регуляторов

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

Не выбирайте SIEM, потому что вы строите SOC

Все умные люди, говоря о SOCах, обычно делают знак равенства между двумя фразами "имею SOC" и "имею SIEM", но это не совсем так. Достаточно просто вспомнить, что вы можете аутсорсить свой SOC у внешнего поставщика услуг, к которому вы предъявляете требования по скорости реакции, гарантиям, охвату вашей инфраструктуры, но точно не по тому инструментарию, который он должен использовать. Это его прерогатива, раз уж вы выбрали его из множества аутсорсинговых SOCов; доверьте ему и выбор SIEM. Вы вообще можете не знать, какой SIEM у вашего SOC-as-a-Service; вы же платите за услугу с понятными входными и выходными данными и вам не так уж и важно, что у нее внутри.

Не выбирайте SIEM, потому что он в правом верхнем углу магического квадранта

Обратите внимание, я не говорю, не выбирайте SIEM из этого угла квадранта. Я говорю, не выбирайте, потому что он там. Чувствуете разницу? Если SIEM попал в этот угол, значит он достаточно хорош (а вы же хотите все самое лучшее, не так ли?). Но вам нужна не медаль на грудь и не "мировой рекорд",  а решение стоящих перед вами задач. Возможно вас устроит что-то более простое и не столь дорогое? Возможно 50% функционала самого крутого SIEM в мире вам просто не нужны? Так зачем за нее платить (а также за специалистов, которые знают как работать с самым крутым SIEM в мире)?

Не выбирайте SIEM, потому что вас зачморили коллеги и говорят вам "Ты что, с Урала?"

Помните советский фильм "Самая обязательная и привлекательная"? Там был эпизод, где главную героиню привели к, как сейчас модно говорить, байеру, который предлагал то одну модную штуку, то другую, то третью. А на изумленный вопрос героини "А зачем это?", ее сравнили с деревенщиной, припечатав, ставшим классикой, "Ты что, с Урала?" Не выбирайте конкретный SIEM и вообще SIEM, потому что это модно и у всех ваших коллег это есть.

Не выбирайте SIEM, потому что вам надо выстроить сбор логов

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

Не выбирайте SIEM по фичам и обещаниям вендора

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

Или другой пример. Продавец SIEM вам говорит, что вы сэкономите, купив его решение, так как у него SIEM и SOAR и IRP - все в одном флаконе. А вы же понимаете, что хотя бы IRP, но вам нужна (а может и SOAR вместо IRP). Вы берете этот SIEM, но потом оказывается, что он не работает в multi-tenant архитектуре, а у вас холдинг и каждому предприятию нужен свой "кусок". Или multi-tenant поддерживается, но нет иерархии SIEM "главный-подчиненный", которая вам нужна для охвата 9 часовых поясов и размещения нескольких центров мониторинга по России и странам СНГ, в которых у вас размещены точки присутствия. Смотрите сначала на архитектуру, а потом на конкретные функции, тем более обещаемые.

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

Не выбирайте SIEM, потому что он поддерживает искусственный интеллект

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

От ответов на них зависит, понимает ли вендор, что такое ИИ и машинное обучение в частности или нет? И стоит ли вестись на всю эту хайповую тему с магической заменой кучи конструкций "IF THEN" в коде или корреляционном правиле на словосочетания "искусственный интеллект", "нейросеть" или "глубокое обучение". Для того, чтобы назвать атакой 3+ попыток неудачного входа в систему с одной учетки за короткий интервал времени, много ума не надо. В отличие от идентификации кражи учетной записи по определению нетипичного места входа в систему, опираясь на результаты кластеризации таких попыток за большой интервал предыдущего времени, опираясь именно на ваши данные. ИИ в SIEM есть и он может решать свои задачи - вопрос в том, знаете ли, как выжать максимум из него, и знает ли это локальный поставщик?

Не выбирайте SIEM, потому что у него отличная корреляция

Это древняя песня, которую я помню еще с конца 90-х годов, когда внедрял свой первый SIEM в одном из национальных банков на постсоветском пространстве. Заказчик тогда тоже купился на рассказ про корреляцию и вот это вот все, но реальность была совсем другой. Несмотря на наличие правил корреляции "из коробки", которыми так кичился вендор, пришлось писать много своей логики, отличавшейся от задумки производителя. И это при том, что число источников, подключаемых к SIEM, было на порядки меньше, чем у современных решений по мониторингу. По рынку ходит цифра, что сколько бы правил корреляции в вашем SIEM не было, только 20% их них можно применять безболезненно. Поэтому надо четко осознавать, что писать правила корреляции под ваши use case придется вам (или внешнему интегратору за дополнительные деньги) и все слова о "уникальной системе корреляции" превратятся в реальности в тыкву.

Не выбирайте SIEM, потому что он имеет универсальный коннектор ко всему

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

Не выбирайте SIEM, у которого нет плана развития

Я уже писал выше, что надо проверять все заявленные и нужные вам фичи в рамках пилота. Не менее важно, чтобы у SIEMа был четкий план развития (с соответствующими подтверждениями), который учитывает тенденции рынка и вашу стратегию развития. Возможности масштабирования, рост производительности, новые коннекторы для интеграция с различными решениями (не забывайте учитывать все скрытые затраты такой интеграции, которые лягут тяжким бременем на ваши плечи), поддержка каких-либо стандартов (от STIX/TAXII и MITRE ATT&CK до ГосСОПКИ и ФинЦЕРТа), новые функциональные модули, новые корреляционные возможности, обнаружение новых атак и т.п. Вроде бы очевидные вещи, но часто бывает так, что продукт берется ради сиюминутных задач, а потом оказывается, что вендор и не развивает свой продукт, делая только косметические правки, оставаясь на позади конкурентов. Такое было в свое время с netForensics - лидером рынка SIEMов, который сдулся и прекратил свое существование. Кстати, план развития тоже не гарантия, что продукт будет развиваться согласно ему. Но это уже ситуация, которая не предсказуема и с которой приходится просто мириться, на ходу меняя решение на другое.

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

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

Не выбирайте SIEM, потому что у него харизматичный лидер с горящими глазами

Проверьте, что за этим лидером есть команда, которая готова развивать и поддерживать продукт. Извините, никто не вечен и все может произойти в жизни - от рождения детей до попадания в ДТП на "джихад-такси" Яндекс.Такси. Горящие глаза и делающие руки - это классно, но любая разработка - это процесс, который не должен зависеть от одного винтика, вынув который, все ломается. К иностранным вендорам этот совет малоприменим, а вот в России такие случаи бывают. 

Не выбирайте SIEM, потому что он поддерживает ваши средства защиты периметра

Первые SIEM появились в конце 90-х годов, чтобы сократить число ложных срабатываний у систем обнаружения вторжений и межсетевых экранов. С тех пор число источников событий безопасности и объем этих событий возросли многократно. Насколько выбираемый вами SIEM способен работать с такими источниками? DLP? CASB? AWS CloudTrail? Azure Monitor? UEBA? EDR? HRM? СКУД? SCM? ERP? СУБД? Иные бизнес-системы?

Не выбирайте SIEM, у которого нет реагирования

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

Не выбирайте SIEM, если не знаете, где взять людей для работы с ним

Очевидно.

Не выбирайте SIEM, если у вас нет процесса мониторинга ИБ

SIEM - это инструмент, который позволяет вам автоматизировать процесс мониторинга ИБ. С его помощью вы сможете собирать нужные данные с нужных источников, производить над ними нужную обработку и анализ, сохранять и принимать те или иные решения. Но для эффективного использования этого инструмента, у вас должен быть сначала выстроен процесс. Вы должны четко понимать:
  • Что вы хотите собирать?
  • Где это находится?
  • Кто отвечает за эти источники?
  • Как и в каком формате хранятся эти данные?
  • Как отдаются эти данные?
  • Что надо предпринять, чтобы забрать эти данные?
  • Как обеспечивается целостность и непротиворечивость этих данных?
  • Что вы будете делать с этими данными?
  • Сколько надо хранить эти данные?
  • Какие виды анализа вы будете проводить над этими данными? 
  • Как вы управляете временными метками в вашей инфраструктуре?
  • Кто имеет доступ к этим данным?
  • Насколько структурированы эти данные?
Вот только небольшой список вопросов, на которые надо получить ответы до начала выбора SIEM.

Не выбирайте SIEM с непонятным TCO

По результатам общения с вендором вам все понравилось и вы готовы заплатить кругленькую сумму за систему мониторинга событий ИБ. Но... посчитайте TCO для него. На тестах оказалось, что вам нужна иная конфигурация, чем вы изначально рассчитывали? Вам нужна лицензия на большее число EPS, чем думали изначально? Выбранное или рекомендованное вендором железо "не тянет" и требуется более мощное? Ваша архитектура потребовала новых коллекторов? Курсы обучения по SIEM в России не проводятся и надо ехать в Европу (а вас по приезду развернули, потому что вы под санкциями, несмотря на полную предоплату, - реальный случай)? Вы не учли размер хранилища под собираемые события ИБ (кстати, вы в курсе, что будет, если на ваш SIEM подадут больше EPS, чем надо, или база переполнится?)? Вы не заложили стоимость написания коннекторов под ваши специфические источники? Есть вендора, которые предлагают к своим решениям полную калькуляцию всех статей расходов, которые могут понадобиться для развертывания и эксплуатации SIEM с расчетом на 12, 24 или даже 36 месяцев. Ваш вендор вам такое может сделать с учетом вертикального (число EPS) и горизонтального масштабирования (число и типы источников)?

 Не выбирайте SIEM-вендора - выбирайте SIEM-партнера

В отличие от МСЭ, EDR, NGIPS или SIG, решение по мониторингу событий ИБ требует гораздо более тесного взаимодействия с его производителем (тоже можно сказать и про DLP, и про другие прикладные ИБ-игрушки). Это не коробка, которая работает по принципу "поставил и забыл". Работы с новыми источниками, понимание методов анализа, разработка правил корреляции, масштабирование, расчет TCO, обучение модели ML... Да мало ли еще тем, по которым вы будете постоянно общаться с производителем вашего SIEM. Готов ли вендор к этому? Готовы ли вы к этому?

 Не выбирайте SIEM как самодостаточную систему

Как вы будете использовать SIEM? Это важный вопрос. Не для чего, а именно как. Вы планируете ее использовать как самодостаточное решение или интегрировать с IRP/SOAR, TIP, NTA, UEBA, EDR, CASB, CMDB и другими решениями, которые вместе позволят выстроить вам цикл управления инцидентами в вашей инфраструктуре? Если второе, то смотрите на то, с чем и как может интегрироваться выбираемый вами SIEM.

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