Почему не срабатывают страшилки про киберугрозы и хакеров?

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

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

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

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

Что же делать, чтобы изменить поведение людей? Нужны положительные примеры. Например, британское правительство раньше рассылало письма с требованием оплатить налоги, чтобы "жить спокойно" (знакомо, да). Это не работало. Потом они поменяли текст и стали писать о том, насколько важно платить налоги. Тоже не сработало. А потом они добавили всего лишь одну фразу "9 из 10 жителей Британии платят налоги вовремя". Это привело к 15% улучшению показателя собираемости налогов. Люди видят/слышат, что делают другие и это является мощным стимулом делать также. Не надо рассказывать, что пароли меньше 8 символов - это плохо. Расскажите, что многие люди выбирают пароли длиной 10 символов. Суть та же, а окраска совершенно иная - и эффект иной.

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

Аппаратные закладки в фокусе Offzone

На прошлой неделе прошла Offzone имени BI.ZONE, которая в этом году была посвящена аппаратной безопасности. Учитывая, что в списке из 9 тысяч проходок на PHDays я себя не нашел, то Offzone оказалась для меня первой хардкорной конфой в этом году :-)

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

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

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

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

Самое неприятное, что сегодня площадь аппаратных атак слишком велика и не ограничивается только вендором, который выпускает средство защиты на основе какого-то чипа или микросхемы. Допустим ФСТЭК выпустила разрабатываемую сейчас методику поиска аппаратных уязвимостей. Но производитель не в состоянии будет проверить все компоненты по ней, так как многие из них вообще ему неизвестны. У него на материнской плате может быть с 2-3 десятка компонентов от разных производителей, которые в свою очередь зависят от других производителей, а также от надежности логистических процессов между ними. И как в такой ситуации говорить о безопасности?

На Offzone распространялся классный обзор аппаратных атак, методов их реализации и нейтрализации.

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

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

ЗЫ. А пока до массового применения аппаратных закладок дело не дошло, злоумышленники активно пользуются уже наработанными подходами. На выходных были обнаружены ботнеты из устройств Хуавея.

Финал "Нашей игры"

На Youtube выложена запись финала "Нашей игры", которая прошла в канун дня России и которая подвела некий итог первого сезона этого интеллектуального шоу по ИБ. Позади пять игр,  которые были посвящены совершенно разным, но животрепещущим темам, находящимся в повестке дня российского безопасника:

• Security Operations Center
• Регуляторы
• Криптография
• Сетевая безопасность
• "Сделано в России".

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


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

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

SOC - это набор сервисов или процессов?

Очень часто, в презентациях про SOC говорят про классическую триаду, которая позволяет создать хороший центр мониторинга, - "люди - процессы - технологии". Эта триада так въелась в головы многих, что ее уже никто не воспринимает критически. В то время как она является некорректной по сути и уводящей многие SOC не туда. Я, во время рассказа о наших сервисах про проектирование или аудит SOCов постоянно сталкиваюсь с этой проблемой и так как она носит уже хронический характер, то я решил посвятить ей отдельную заметку. Тем более, что и после публикации в блоге презентаций по теме SOC меня стали часто спрашивать, что такое сервисная стратегия SOC, зачем она нужна и чем сервисы SOC отличаются от его процессов. Причиной тому служит слайд, который я постоянно использую во всех своих презентациях по SOC - и в 30-тиминутных, и в 8-мичасовых.

Составные части сервисной стратегии SOC

Идея разделения сервисов и процессов SOC очень проста. Представим, что у нас в организации есть две стороны - потребитель услуг SOC и их исполнитель (то есть служба ИБ или внешняя организация). Так вот существует два совершенно отличных друг от друга подхода к организации деятельности SOC (да и любой другой деятельности тоже). Первый заключается в непосредственном управлении деятельностью центра мониторинга, которая обычно представляется в виде процессов (мониторинга, реагирования, threat intelligence и т.п.). В этом случае за конечный результат отвечает потребитель, который и должен установить правила для процессов, а поставщик должен эти правила соблюдать. Второй подход заключается в том, что мы управляем только значимыми для потребителя результатами деятельности без погружения в детали ее организации. В контексте SOC разумнее именно так и поступать, так как врядли бизнес будет сам устанавливать правила для непонятных ему процессов. Особо внимательные читатели заметили, что второй подход - это классический сервисный подход, описываемый ITIL или CoBIT. В этом варианте за конечный результат отвечает поставщик, а заказчик SOC - только за корректные требования к результату.

Сервисный подход требует более высокого уровня зрелости от службы ИБ и по сути взаимодействие с ней строится по тем же самым принципам, что и с внешней аутсорсинговой компанией (разве что без заключения юридически значимого договора). У нас также прописывается SLA между бизнесом и SOC, в соответствие с которым мы начинаем предоставлять бизнес-ориентированные услуги, которые понятны бизнесу. А с внутренними поставщиками (либо с отделами/группами SOC, либо с внешними поставщиками услуг TI, реверс-инжиниринга вредоносного ПО, фишинговых симуляций и т.п.) прописываются OLA (operational level agreement), которые фиксируют обязательства внутренних поставщиков в части работоспособности софта и железа, выполнения операций (например, реагирования на инциденты) в заданные временные рамки и т.п.

Пример каталога сервисов SOC

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

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

Пример высокоуровневого описания одного из сервисов SOC в сервисной стратегии

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

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

Именно сервисная стратегия определяет все последующее - процессы, технологии, людей в SOC 

Надо ли переходить на сервисную модель в SOC? Это большой вопрос. С одной стороны это позволит показать свою нужность бизнесу и заручиться его поддержкой, в том числе и финансовой. С другой, это требует определенной зрелости от службы ИБ и готовность брать на себя ответственность за принимаемые решения и получаемые результаты. Не все к этому готовы. Кроме того, переход к сервисной модели и определение SLA и OLA может привести к обострению внутренних конфликтов между группами SOC, которые не привыкли работать в четко оговоренных рамках. Представьте, что вы начинаете требовать от своей группы Threat Intelligence, чтобы она не просто тратила деньги на источники фидов и в реактивном режиме сообщала в группу мониторинга о новых индикаторах компрометации с задержкой в пару дней ("так выходные же были"), но и прогнозировала новые атаки и проактивно сообщала о том, как с ними бороться, а также обновляла каталог use case'ов, playbook'и и др.

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

ЗЫ. И, кстати. Не стоит забывать, что SOC может быть не только набором процессов, но и проектом. Когда его строят или когда проводят аудит и обновление, тогда SOC превращается в проект со сроками начала и конца работ, менеджером проекта, временными участниками, конечной целью.

Почему сертификат ISO 27001 приводит к снижению инвестиционной привлекательности, а программа bug bounty лучше пентестов...

Есть такое классное мероприятие по ИБ (не в России), которое называется The Workshop on the Economics of Information Security (WEIS) и которое из года в год собирает доклады, посвященные различным исследованиям в области экономики ИБ. В этом году WEIS проходил в Бостоне 3-4 июня и в его рамках было представлено ряд интересных докладов, о которых мне хотелось бы немного рассказать.

Равив Марчиано-Горофф представил исследование о влиянии калифорнийского закона 2002 года о раскрытии инцидентов с утечками данных на инвестиции в информационную безопасность. В России после принятия ФЗ-152 ситуация с ИБ не менялась до 2008-го года, когда было принято первое "четверокнижие" ФСТЭК с требованиями по защите ПДн. После этого многие службы ИБ "подняли" денег на выполнении требований регулятора. А вот закон Калифорнии, как оказалось, не сильно повлиял на американский бизнес и его инвестиции по ИБ. Исследование проводилось среди 214 тысяч компаний, которые оценивались по одному параметру - установка обновлений безопасности на web-сайтах, обрабатывающих персданные. Выглядит достаточно нестандартно, но, видимо, это единственно публичная и унифицированная  информация, которую нашел Равив. Так вот оказалось, что только 1,8-2,8% компаний обновили свои сервера после выхода закона американского штата. Это позволило сделать вывод, что принятие аналога ФЗ-152 не сильно повлияло на инвестиции в ИБ. Примерно тоже самое мы видим и в России сейчас (хотя у нас таких исследований и не проводилось). Думаю, что GDPR немного изменит эту статистику, но только по одной причине - сумма потенциального штрафа.

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

• Инвесторы не реагируют однозначно негативно на инциденты с безопасностью.
• Невзломанные компании сталкиваются с отрицательной доходностью после объявления инцидентов в своей отрасли, а также с ростом затрат на аудиты на 6%.
• Доходность акций страховых компаний также падает.

Третье исследование было посвящено экономической эффективности программ bug bounty. Я вспоминаю выступления Кирилла Ермакова из Qiwi на прошлогоднем "Код ИБ. Профи" в Москве, где он сравнивал экономику пентестов и bug bounty. На WEIS 2019 исследование базировалось на большем количестве исходных данных. Не буду перечислять все выводы; обращу внимание лишь на парочку:

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

В заключение упомяну еще одно исследование, представленное на WEIS 2019. Оно было посвящено изучению оценки влияния фондового рынка на инвестиции в проекты по ИБ, которые имели некоторую публичную составляющую. В частности, речь шла о получении сертификатов соответствия английской Cyber Essentials и ISO 27001. 145 сертификатов UK Cyber Essentials за период 2014-2018 годы привели к положительной оценке со стороны фондового рынка и рост доходности компаний, получивших сертификат. А вот с ISO 27001 ситуация оказалась прямо противоположной и даже парадоксальной. 76 сертификаций по ISO 27001 с 2001 по 2018 годы показывают значительную негативную оценку со стороны рынка. По мнению авторов исследования это связано с тем, что рыночные аналитики и инвесторы рассматривают дорогостоящие инвестиции в ISO 27001 как бессмысленную трату денег, которая только ухудшает финансовые показатели компаний и ничего не дает с точки зрения бизнеса. Интересная версия...

17 способов опозорить ваш МСЭ и проникнуть в корпоративную сеть (презентация)

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

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

17 способов опозорить ваш МСЭ и проникнуть в корпоративную сеть from Aleksey Lukatskiy

От SOC v0.1 к SOC v2.0 (презентация)

В четверг на ITSF я выступал с обзором законодательных новинок по ИБ от ЦБ. Днем позже, в пятницу, я открывал поток по SOCам с презентацией: "От SOC v0.1 к SOC v2.0", где делился в очень сжатые сроки некоторыми зарисовками о том, чем отличается "простой" SOC начального уровня от `SOCа более продвинутого. Понятно, что 30 минут - это очень мало, но я постарался обратить внимание на ключевые моменты, которые достаточно важны на мой взгляд (хотя и не все, что хотел, успел рассказать).

От SOC v0.1 к SOC v2.0 from Aleksey Lukatskiy

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