16.07.2019

Тенденции рынка пентестов - от полной автоматизации до краудсорсинга

Наткнулся тут на новый канал в Телеграме - СекьюриСТ, в котором автор недавно коснулся темы пентестов и описал вкратце, что это такое. Я вообще не очень люблю эте тему, но тут так совпало, что при формировании программы сочинского "Код ИБ. Профи", по просьбам участников в нее был включен практический доклад Жени Волошина из BI.ZONE, как раз посвященный пентестам. Поэтому я решил тоже тиснуть небольшую заметку, но скорее о некоторых тенденциях, которые за пределами России существуют в этой области. Понятно, что не все из них дойдут до нас, но учитывая, что регуляторы в лице ФСТЭК и ЦБ начинают активно требовать проведения тестов на проникновение, понимание рыночных трендов будет полезно.


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


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

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

Чтобы уйти от этих проблем сегодня активно рассматривается в качестве альтернативы платформы для краудсорсингового пентеста, в рамках которых, десятки и сотни исследователей начинают "ломать" вас, ища уязвимости в вашей инфраструктуре и в ваших приложениях (преимущественно именно в них). В отличие от обычного пентестера, краудсоринговый исследователь получает деньги только за обнаруженную уязвимость (за это такой анализ еще называют bug bounty program), а сам процесс поиска может быть непрерывным, что позволяет встраивать такой краудсорсинговый пентест в практику DevOps. Примерами таких платформ можно назвать Synack или HackerOne Challenge.

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

Однако не стоит думать, что краудсорсинговые пентесты поглотят классику. Все-таки у крадсорсинговой модели анализа защищенности есть и свои ограничения. В частности, с ее помощью гораздо сложнее проводить тестирование внутренней сети или устройств Интернета вещей. В этом сценарии классический пентест пока подходит лучше. Однако и тут есть свои тренды. Например, активное внедрение автоматизации в процесс проведения тестов на проникновение. И речь идет не только о решениях класса Breach and Attack Simulation (BAS), яркими представителями которых являются компании AttackIQ, Cymulate, SafeBreach, Threatcare, Verodin и другие. Сейчас стал нарождаться новый сегмент рынка ИБ, в котором уже есть такие компании как CyCognito, Pcysys. Randori, SCYTHE, которые предлагают инструментарий для автоматизации пентестов.

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

ЗЫ. У вас еще есть шанс успеть зарегистрироваться на сочинский "Код ИБ. Профи" и послушать доклад Евгения Волошина, посвященный пентестам.

15.07.2019

Какой должна быть структура службы ИБ?

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

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


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


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

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

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


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


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


Вот как-то так получается с оргструктурой службы ИБ. Универсального ответа нет, но есть на что ориентироваться.

12.07.2019

ИБ для бизнеса на примере HR-подразделения: пять уровней зрелости

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


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

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

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

Четвертый уровень зрелости вроде как и не относится к защите информации, потому что мы начинаем думать совершенно иными категориями. Мы не защищаемся от атак на информационные активы. Мы используем информационные активы для защиты бизнеса от широкого спектра угроз. Например, в случае с HR мы начинаем использовать классический ИБшный инструментарий для того, что является одной из ключевых задач HR - удержание кадров. Это странно звучит, но на самом деле, HR должен заниматься именно удержанием персонала, а не его наймом (этим занимается рекрутинг) или увольнением. И чтобы удерживать персонал, среди прочего, надо иметь оперативную информацию о том, когда сотрудники начинает смотреть на сторону и искать работу, размещая резюме, просматривая вакансии или получая job offer по электронной почте. И отслеживать это можно с помощью DLP, прокси, NGFW, SIG (Secure Internet Gateway), E-mail Security и т.п. решений.

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

А что у нас на 5-м уровне? А все тоже самое, только на более высоком уровне. Мы можем вовсе не использовать классический ИБ-инструментарий для того, чтобы обеспечивать интересы бизнеса, но мы обязательно должны задействовать информационную сферу, в которой мы будем искать следы нарушений или аномалии, которые могут нанести ущерб интересам бизнеса. Вот, например, интересный кейс был реализован в "Почте России". С помощью новой автоматизированной системы "1С" удалось выявить "мертвые души" в почтовых отделениях (их число достигало в отдельных отделениях 50%), выявив фальшивые трудовые книжки и выплаты несуществующим людям. Это угроза и угроза в большой и распределенной компании достаточно серьезная. И может быть даже более опасная, чем какая-нибудь DDoS-атака. Чья это епархия? HR? Безусловно. Но они и сами могут быть вовлечены в преступный сговор с целью незаконного обогащения за корпоративный счет. И вот тут вновь нам помогает ИБ, так как она может контролировать информационные потоки, отслеживать события, связанные с тем или иным процессом, анализировать отклонения от эталонного состояния и их допустимость и т.п. Да, это не МСЭ и не антивирус, не контроль Netflow и не разграничение сетевого доступа. Но это все равно информационная безопасность и именно такая ИБ максимально приближена к бизнесу.

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


11.07.2019

Презентации с Payment Security по 0day и нормативке ЦБ

На прошлой недел в Питере прошла уже в очередной раз конференция Payment Security, на которой я выступал (точнее, пытался; из-за болезни) с двумя презентациями - про борьбе с 0day-атаками и про нормативку ЦБ по ИБ. Выкладываю.






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

Думаю уже все видели новость, что компанию British Airways могут оштрафовать на 183 миллиона фунтов стерлингов за утечку данных платежных карт полумиллиона клиентов во время покупки ими авиабилетов. Я про этот кейс (и Equifax) делал презентацию с их разбором:



На 100 миллионов Великобритания хочет оштрафовать еще и Marriott за утечку ПДн полумиллиона постояльцев сети Starwood, купленной Marriott. В целом, вроде как и заслуженно, но есть нюансы, о которых я и хотел написать.

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

Во-вторых, в случае с BA, авиакомпания пострадала дважды. Сначала увели деньги ее клиентов. И тут еще вопрос, кто будет возмещать ущерб. По крайней мере, коллективный иск к BA подан и посмотрим на его результаты. Потом уполномоченный орган по защите ПДн Великобритании запланировал наказать BA на почти 200 миллионов за утечку. Но интересно, что в случае с BA есть версия, что взломали не ее саму, а подрядчика, которому принадлежал скрипт на сайте BA, отвечающий за сбор данных платежных карт. Вторая версия взлома BA говорит, что компрометация произошла не основного сайта BA, а его CDN, размещенного у одного из операторов связи. В обеих версиях, получается, пострадала аутсорсинговая компания, которой была поручена обработка данных авиапассажиров. Получается, что BA отвечает за проблемы других? Да. За недооценку вопросов ИБ у привлеченных компаний, за которые она несет всю полноту ответственности.

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

Вопрос же заключается в том, что в Европе (а в России такие кейсы пока нереальны) акценты в ИБ начинают очень активно меняться. Ведь даже если вы выполнили все требования по ИБ, но вас взломали (а 100%-й защиты не гарантирует никто), то вас могут оштрафовать на достаточно крупную сумму. А это требует в свою очередь внедрение немного иных практик ИБ, к которым ранее обращались далеко не все и не всегда. В частности, речь должна идти об активном расширении практики оценки соответствия как поглощаемых (в рамках due dilligence), так и привлекаемых к выполнению отдельных работ компаний. Причем во втором случае, это будет не разовый процесс, а проводимый на регулярной основе. В случае собственных активов стоит создать и начать активно эксплуатировать команды red team, которые смогут действовать как хакеры и находить то, что может быть использовано "плохими парнями" для компрометации вашей сети. Лучше, если вы сами себя сломаете и потом исправите, чем если это сделают посторонние. Ну и, наконец, так как все равно 100%-й безопасности вы не можете гарантировать, стоить подумать о страховании киберрисков (правда, пока не в России), которое может помочь покрыть возможные претензии органов контроля/надзора.

Вчера на Эхе Москвы была передача с Андреем Мовчаном, экономистом, который высказал очень правильную мысль. Бизнес бессмысленно заставлять делать, что надо, и не делать, что не надо. Бизнес надо мотивировать, чтобы он сам захотел это делать или не делать. Мотивирует ли бизнес 200 миллионов фунтов штрафа? Да нифига. Пополнить казну, опустевшую после Brexit, это помогает. Но это мотивация для регулятора, а не для бизнеса. И 100 миллионов фунтов штрафа тоже не мотивирует. Гораздо разумнее поступил румынский регулятор, который на днях оштрафовал румынский Юникредитбанк за нарушение статьи 25(1) GDPR. Согласно материалам дела банк спроектировал систему так, что раскрыл часть ПДн плательщиков была раскрыта получателям платежа, что нарушает принцип минимизации раскрываемых данных. Косяк архитектора и штраф в наказание. Но штраф не карающий, как в случае с BA или Marriott, а мотивирующий. Да 130 тысяч евро - это немало, но все-таки на 3 порядка меньше, чем у английских коллег румынского "роскомнадзора".


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

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

03.07.2019

Асимметрия информации, информационная экономика и рынок ИБ

Я уже обращался к теме экономики безопасности не один раз (последний - пару недель назад), но тема эта безгранична и поэтому я вновь вернуться к ней. Тем более и повод есть. Росс Андерсон пишет третье издание своего классического труда "Security Engineering" и постепенно выкладывает написанные главы на своем сайте. Последнюю главу, посвященную информационной экономике, он выложил 29-го июня. Я позволю себе поделиться некоторыми выводами (тезисно) из этой главы и некоторыми моими добавлениями к ним:

  • Люди не меняют своего поведения, если у них нет к этому стимула. Человек, выставляющий в Интернет небезопасную машину, не несет никаких последствий, в то время как человек, который пытается делать все правильно, страдает от побочных эффектов. Тоже самое касается и компаний.
  • Асимметричная информация, о которой я впервые написал 10 лет назад (и еще 6 лет назад), управляет рынком ИБ. Если у вас нет полной информации об интересующих вас средствах защиты, их качестве и функционале, то для вас основным критерием покупки будет стоимость. А если транслировать отсутствие информации при покупке в даркнете, то вы будете заложником знакомого вам продавца или площадки и будете торговаться по его ценам и условиям. И так по многим направлениям, в которых тот, кто обладает большей информацией, манипулирует теми, у кого ее нет. В условиях же цифровой симметрии, когда у всех информация одна и та же, наступает конкурентное равновесие. Например, если бы где-то был сайт (или сайты), который, как агрегатор стоимости авиабилетов или отелей, отображал бы стоимость разных МСЭ, соответствующих заданному функционалу, то их цена бы поползла вниз, так как у всех потребителей была бы одинаковая информация и ею нельзя было бы манипулировать. 
  • Люди до сих пор покупают антивирусы, хотя это совершенно бессмысленная трата денег. Вирусописатели ведь проверяют свои творения на всех известных средствах защиты до того, как выпустить свой код "в свет". То есть на момент своего победоносного шествия по миру вредоносная программа не детектируется антивирусами. Но об этом производители не говорят, а потребитель просто не задумывается об этом. Еще бы - последние 25 лет на всех углах говорят о важности антивируса и 100% потребителей их использующих (тут вступает в игру одна из предыдущих заметок про страшилки и необходимость демонстрации прогресса и равнения на лучших) поэтому не знает об этом. Налицо цифровая асимметрия.
  • Интересно, что асимметричность информации объясняет очень многое в мире ИБ. Многие заинтересованные лица не заинтересованы говорить правду. Спецслужбы и ИБ-компании преувеличивают угрозы; компании электронной коммерции и банки - преуменьшают их. Американские спецслужбы обвиняли в кибератаках на США Россию, не предоставив никаких доказательств. И снова проявление асимметрии информации.
  • Ввиду коммерциализации рынка киберпреступности, он также начинает активно жить по экономическим законам. Цена многих услуг падает до нуля и мелкие игроки киберпреступности постепенно уходят с рынка, уступаю место крупняку, который консолидирует усилия и может вышибать нишевых игроков с рынка продавая услуги "в минус", компенсируя потери в других сегментах. Такое происходит на рынке услуг спама, или DDoS. Кстати той же стратегии придерживаются и многие интеграторы, которые торгуют пентестами задешево, выбивая мелкие нишевые конторы с этого рынка. Правда, при этом страдает и качество услуг, но в условиях асимметрии информации потребитель об этом не узнает, а интеграторы не спешат делиться этим откровением.
  • Цена информации равна стоимости ее производства, что во многих случаях означает, что она равна стоимость копирования, то есть нулю. Отсюда вытекает отсутствие нормальных аналитических ресурсов, которые не могут жить только за счет информации (ее легко копируют и распространяют) и вынуждены прибегать к рекламе.
  • Есть всего два способа получить то, что вам хочется, если вы не можете создать это сами или найти где-то. Вы либо делаете что-то полезное другим и торгуете этим (обмениваетесь или на вырученные деньги покупаете нужное), либо берете то, что вам нужно, силой. Выборе между сотрудничеством и конфликтом ведется каждый день на уровне людей и на уровне компаний. Основным инструментом, который изучает сотрудничество и конфликты, является теория игр.
  • Люди, которые занимаются ИБ систем, не являются людьми, которые несут потери от атак на эти системы.
  • Иногда механизмы безопасности используются, чтобы свалить вину на других. И если вы один из этих "других", то вам было бы лучше, если бы система была небезопасной.
  • Безопасность часть используют для продвижения своих интересов, а не для достижения общего блага.
  • Безопасность мешает развитию и рациональным поведением для компании будет пренебрегать ею пока не будет защищена его позиция на рынке. И только после этого можно начать думать о защищенности. Именно поэтому у многих стартапов и начинающих разработчиков ПО проблемы с безопасностью.
  • "Сделка - потом грабеж" - так называется ситуация, когда поставщик средств ИБ продает свои решения задешево, но потом начинает "стричь" заказчика на ежегодном продлении, цена которого может составлять 70 и даже 100 процентов от первоначальной стоимости решения. Это тоже объясняется простой экономикой.
  • Если вы используете какое-то сложное ПО (Microsoft или  Splunk), то вы начинаете использовать его по максимуму, все его хитрости и трюки. Это существенно осложняет процесс миграции на другое ПО.
  • Правоохранительные органы очень мало занимаются киберпреступностью, так как им проще не замечать ее, игнорировать проблему и удерживать жертв от заявлений о преступлениях.
  • Обнаружение мошенничества с кликами в рекламных сетях означает, что рекламная сеть не может брать денег с рекламодателей за эти клики. Значит, если владелец рекламной сети очень хорошо борется с мошенничеством, то он меньше зарабатывает. Тоже самое с борьбой с DDoS в условиях, когда оператор связи получает деньги за объем трафика.
  • Поиск ошибок и уязвимостей в разработанном вами коде приводит к потере конкурентных преимуществ. Чем больше вы ищете, тем больше вы находите, и тем дальше вы отдаляете срок выхода своего ПО. Менее щепитильные компании или команды в результате выигрывают. Поэтому большого стимула внедрять анализ кода нет, если только об этом не просят клиенты или не введена ответственность за отсутствие анализа.
Вот такой короткий пересказ интересной главы. Вроде многие тезисы не новы и мы с ним сталкиваемся регулярно по работе. Но часто мы думаем, что это нечто выдающееся или наоборот исключительное событие и что у других-то такого нет. Но дело в том, что углубляясь в тему информационной экономики, начинаешь понимать, что все, что происходит в ИБ, подчиняется вполне определенным законам. ИБ не является каким-то черным ящиком, живущим по своим правилам, отличным от того, что происходит вокруг. И поэтому такие законы неплохо бы знать, чтобы можно было быть готовым к каким-то событиям, которые все равно произойдут.

ЗЫ. В книге наткнулся на упоминание интересного кейса. В 2012-м году один из волонтеров внес в открытое ПО (WebKit) уязвимость, чтобы потом через программу bug bounty получить вознаграждение. Деталей в Интернете что-то не смог найти, но на интересные мысли этот кейс наводит. Включены ли ваши разработчики или разработчики ПО, которое пишется для вас, в вашу модель угроз/нарушителя?

ЗЗЫ. Кого интересует тема информационной экономики могу посоветовать материалы ежегодной конференции WEIS (The Workshop on the Economics of Information Security), где эту тему активно обсуждают с 2002-го года. 

02.07.2019

Юбилейный "Код ИБ. Профи". Какие сюрпризы ждут участников?

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

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


Но все-таки, как куратору деловой программы, мне бы хотелось думать, что участники едут туда не только для того, чтобы за корпоративный счет (а есть те, кто платит и свои кровные, что уже само по себе показатель) отдохнуть в Сочи, но и получить новые знания и навыки. Тем более, что мероприятий с таким уровнем спикеров и с такой длительностью выступлений в России почти нет. В этом году мне удалось вытащить для участия очередной "состав мечты":
  • Наталья Гуляева. Наташа будет рассказывать о цифровых доказательствах и о том, как подготовить их и представить в суде. Дело в том, что сейчас достаточно много разных выступлений про реагирование на инциденты и даже про форензику. Но вот про то, как не просрать все собранные доказательства и сделать так, чтобы суд их принял, почти никто не говорит. Наташа, являясь профессиональным юристом именно в области кибербезопасности, как раз и подскажет, как все сделать так, чтобы никто и придраться не смог к собранным вами доказательствам. А еще Наташу можно будет помучить в свободное время на тему персданных и GDPR :-)
  • Рустем Хайретдинов. Руст продолжит тему, начатую на московском "Коде ИБ. Профи", и покажет, как описывать бизнес-процессы с точки зрения ИБ, как составлять план их безопасности, как выделить триггеры и маркеры, характеризующие нарушения, которые наносят ущерб бизнесу. В идеале, если вы сможете захватить с собой ноутбук, чтобы двухчасовой мастер-класс вы смогли не только слушать или рисовать на бумаге, но и выполнять задания на одном или двух реальных бизнес-процессах.
  • Дмитрий Мананников. Дима продолжит свою победную серию мастер-классов про экономику ИБ-проектов. В этот раз у Димы будет два часа, за которые участники смогут не просто внимать гуру экономики ИБ, но и самостоятельно просчитать экономику своих проектов по ИБ и своими глазами убедиться, что ИБ рублем посчитать не только можно, но это и не так сложно.
  • Илья Борисов. Илья будет делиться опытом, как за 15 минут и 7 слайдов поделиться с топ-менеджментов текущим статусом ИБ в компании, как не допускать типовых ошибок, как правильно расставить акценты при выступлении и какие приемы коммуникаций наиболее эффективны? Как и на московском "Коде ИБ. Профи" у Ильи будет двухчасовой мастер-класс с вовлечением участников, которые смогут попробовать самостоятельно сделать то, что потом поможет им поднять свой статус в организации и увеличить ресурсы на ИБ. Неплохо было бы, если бы вы взяли с собой ноутбук на этот мастер-класс и смогли бы сделать реальную презентацию для руководства.
  • Алексей Пятигорский. Алексей будет рассказывать о реальном кейсе, с которым ему пришлось столкнуться в своей нынешней роли. Как организация чуть не проспала атаку, имея мощную систему ИБ, кучу индикаторов компрометации, фидов и вот этого всего? Как отделить ложные срабатывания от реальных и как выжать максимум из результатов форензики? 
  • Антон Карпов. Думаю многие видели в новостях историю о том, что иностранные спецслужбы атаковали Яндекс. А у нас по счастливой случайности будет выступать Антон Карпов с докладом о том, как бороться с продвинутыми угрозами. Я бы сказал, что это эксклюзивная возможность узнать, как бороться с тем, что в последнее время все чаще попадает на страницы СМИ и что месяцами и годами находится в корпоративных сетях, не будучи обнаруженным (тот же Regin сидел в Belgacom целых два года).  
  • Алексей Качалин. Если ваша компания внедряет систему управления цепочками поставок на блокчейне, то знаете ли вы, какие риски это влечет за собой и как надо защищать блокчейн от хакеров? А вдруг вы подсели на квантовый хайп и решили внедрить систему шифрования на базе квантового распределения криптографических ключей? На что стоит обратить внимание в этом проекте? Алексей попробует поднять участников конференции с земли в небо и расскажет о том, как и с чем есть прорывные технологии (Большие данные, машинное обучение, квантовые вычисления, интернет вещей, блокчейн и т.п.) в контексте ИБ.
  • Лев Палей. Сегодня, даже в условиях импортозамещения, когда число возможных альтернатив снижается, все равно на повестке многих компаний стоит вопрос о том, как выбрать именно то решение по ИБ, которое нужно именно вашей компании, и не попасться на удочку маркетологов и "продаванов от ИБ". Лев поделится реально работающей методикой выбора решений по ИБ. Но это будет не монолог Льва, а мастер-класс с вовлечением - участники будут разбиты на три команды, которым будут предложено несколько решений по ИБ и надо будет выбрать и обосновать свой выбор перед лицом строгой комиссией.
  • Сергей Волдохин. Фишинг остается самым популярным способом начала многих атак - от банальных до целевых, от инициируемых хакерскими группировками до спонсируемых государством. О том, как выстроить программу защиты от фишинга я рассказывал на последнем московском "Коде ИБ. Профи". А вот о том, как обучать и тренировать своих сотрудников, как разработать сценарий и формат фишинговых симуляций, как измерить поведение сотрудников, расскажет Сергей. В паре с ним будет будет работать профессиональный психолог - Ольга Лимонова. Этот мастер-класс заберет у участников тоже два часа. Если вы возьмете ноутбук, то мастер-класс Сергея будет еще более эффективным.
  • Евгений Волошин. На первом "Коде ИБ. Профи", который проходил как раз в Сочи, на заключительной сессии мы спросили участников, чего им не хватало из тем. И прозвучало (и потом в анкетах это повторилось), что людям хотелось бы услышать "про пентесты". Меня это немного удивило, но так как этот запрос повторялся почти на каждом "Коде ИБ. Профи", то на пятый раз мы все-таки решили сделать мастер-класс про пентесты. Но не про абы какие :-) Женя расскажет, почему не стоит пускать YOLO-пентестеров в свою инфраструктуру, а также расскажет о комплексном подходе к тестированию на проникновение: зачем привлекать администраторов в проектную команду, и каким должен быть инфраструктурный пентест здорового человека на примере реальных кейсов. Также Женя объяснит, почему текущий подход к проведению инфраструктурного пентеста не повышает общий уровень защищенности компании.
  • Андрей Прозоров. Как говорят англичане "last but not least" и эта характеристика очень хорошо подходит к Андрею, который перебрался на Запад, но не перестает скучать по Родине и регулярно заезжать к нам и делиться своим опытом. В этот раз Андрей поделится опытом по реализации нестареющей классики - ISO 27001. Подводные камни, особенности оценки, непрерывное совершенствование, избежание проблем при внедрении этого международного стандарта управления ИБ. 
Кроме мастер-классов мы реализуем в этот раз так называемую "песочницу", то есть серию круглых столов со всеми экспертами, сидящими во главе каждого стола и которым можно задавать любые вопросы, которые вас интересуют. Надо признать, что у каждого спикера есть богатый опыт не только по той теме, по которой он будет выступать. И мы хотим сделать так, чтобы эксперты смогли поделиться им, а участники могли спросить то, что их интересует.

Про культурную программу (регата или прогулка на яхте в один день и прогулка в горах во второй) писать не буду - это позволит перезагрузить мозг и получить неплохую физическую подзарядку.

Внимание! В трех мастер-классах (от Рустема, Ильи и Сергея) неплохо бы иметь при себе ноутбук. Если у вас есть такая возможность, то захватите его с собой. Тогда пользы от вашего обучения будет еще больше!

ЗЫ. Ааа, про себя-то я забыл написать. У меня будет двухчасовой практический мастер-класс по моделированию угроз, на котором я сначала дам краткую вводную в моделирование, а затем мы, разбившись на группы, попробуем смоделировать угрозы для 3-5 выбранных объектов защиты. Учитывая, как часто в последнее время компании страдают от рук хакеров, понимаешь, что у многих процесс моделирования угроз либо не выстроен вообще, либо сделан для галочки, для соответствия требованиям регуляторов. Мы попробуем поменять эту порочную практику. Будет у меня еще часовое выступление, которое я хотел посвятить проведению стратегических сессии по ИБ, но последние дни я все больше склоняюсь к тому, что я могу сильно пересечься с темой Ильи Борисова. Возможно я поменяю эту тему на что-то иное. Есть задумка рассказать о рынке киберпреступности с точки зрения бизнес-моделирования. Я эту тему на публике почти не читаю (только на закрытых мероприятиях), но тут можно попробовать чуть облегчить ее и уложить в час.

01.07.2019

Как "дочкам" иностранных компаний обмениваться инцидентами с штаб-квартирами?

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


Учитывая, что в НКЦКИ никто так ни разу и не обратился по поводу разрешения на передачу данных зарубеж, регулятор вполне очевидно негодует и грозит карами (до двухсот тысяч рублей за нарушение). И вот тут возникает несколько моментов, на которые я хотел бы обратить внимание:
  1. Из пунктов 11-12 не вытекает, что получать разрешение НКЦКИ надо на каждый инцидент и вроде бы можно получить его один раз. Но п.15 говорит о том, что НКЦКИ принимает решение по каждому инциденту отдельно.
  2. Про оперативность реагирования можно забыть. НКЦКИ берет 24 часа на принятие решения об отправке данных об инциденте зарубеж и еще 12 часов на то, чтобы переправить вам ответ из-за рубежа. Итого 36 часов. Оперативно, ничего не скажешь :-(
  3. Дальше больше. Взаимодействие с иностранными организациями ведется на... иностранном языке. При это взаимодействие с НКЦКИ ведется на русском языке. И возникает вопрос, кто будет осуществлять перевод информации об инциденте? Например, у нас в Cisco (хотя мы и не являемся субъектами КИИ) информирование об инцидентах ведется только на английском языке и во всех системах тикеты заводятся на английском (интересно, в азиатских компаниях на каком языке?).
  4. Банк России, активно стоящий на страже интересов вкладчиков, подписал соглашение с рядом Нацбанков СНГ о взаимном обмене информацией об инцидентах, например, с Арменией. Так вот получается, что ФинЦЕРТ является тоже нарушителем требований ФСБ, так как он передает данные своим коллегам в Армении (а также в ряде иных государств) напрямую, минуя НКЦКИ.
  5. У международных платежных систем (например, у Visa) существует требование об уведомлении об инцидентах в отношении компрометации данных платежных карт. Насколько я помню, схожее требование есть у SWIFT.
  6. Дальше больше. Информация об инциденте от субъекта КИИ его зарубежному "визави" передается не субъектом, а НКЦКИ в формате, установленным НКЦКИ. Пока эти форматы публично нигде не описаны и соответственно на повестке дня возникает простой вопрос. А как зарубежная организация сможет принять данные на русском языке да еще в формате, который нигде не описан и, вероятно, не совпадает с тем, что используется на предприятии за пределами России? Вы пробовали, будучи дочкой иностранной организации, получить документы ФСБ официальным путем? Ооооо, это я вам доложу та еще эпопея.
  7. Наконец, представьте себе, что вам от АНБ приходит информация об инциденте у вас внутри? Представили? Отложим в сторону эмоции. Вы вообще готовы к принятию такой информации извне (даже если отбросить в сторону репутацию нашей спецслужбы в мире)? К принятию IOCов да, но к карточкам с описанием инцидентов? Тут тоже есть сомнения, что процессы многих организаций вообще учитывают возможность приема данных об инцидентах извне, по внешним каналам. Да и чисто технически не совсем понятно, как это будет происходит.
Какой же ответ можно дать представительствам иностранных компаний, которым не повезло стать субъектами КИИ? Чего я не буду советовать:
  • Скрывать факт передачи инцидентов зарубеж.
  • Пытаться уйти от попадания под КИИ.
  • Путем "правильного" категорирования прийти к ситуации с отсутствием значимых объектов (на взаимодействие с ГосСОПКОЙ это все равно не влияет - уведомлять надо об инцидентах на любых объектах).
Что же тогда делать? Я бы посоветовал несколько вариантов:
  • Через Ассоциацию Европейского бизнеса, американскую торговую палату, российско-германскую внешнеторговую палату, франко-российскую торговую палату делать запросы в НКЦКИ и обсуждать с ним возможные пути решения проблем.
  • Создавать в России службу ИБ, которая могла бы взять на себя функции реагирования на инциденты, а в головную структуру, если и передавать что-то, то в одностороннем порядке (тогда это не будет считаться обменом и, формально, не попадет под ограничения в приказе ФСБ).
ЗЫ. У Валерия в заметке приводится интересный кейс с наказанием организации, которая опубликовала на сайте определенный материал, который не должен был распространяться за пределы РФ. Ну дальше можно фантазировать в меру своей испорченности :-(

26.06.2019

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

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


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

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

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

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

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

25.06.2019

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

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

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


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


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


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

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


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


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


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

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

24.06.2019

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

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

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

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


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

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

17.06.2019

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 превращается в проект со сроками начала и конца работ, менеджером проекта, временными участниками, конечной целью.


14.06.2019

Почему сертификат 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 как бессмысленную трату денег, которая только ухудшает финансовые показатели компаний и ничего не дает с точки зрения бизнеса. Интересная версия...

04.06.2019

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

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

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


03.06.2019

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

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



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

31.05.2019

Новинки нормотворчества по ИБ от Банка России (презентация)

Отчитал вчера на IT & Security Forum в Казани незапланированную программой презентацию с обзором последних новинок нормотворчества по ИБ от Банка России. Вообще эту тему я обычно читаю в течение 4-5 часов, но тут мне пришлось ужаться до 1 часа и "выбросить" тему КИИ, ПДн, СПФС, ФинЦЕРТ, ЕБС и другие.



ЗЫ. Что было особенно приятно, после выступления получил от коллег из ЦБ небольшой сувенир в виде коллекции монет СССР :-)