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 часа и "выбросить" тему КИИ, ПДн, СПФС, ФинЦЕРТ, ЕБС и другие.



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


29.05.2019

Как шифровальщик накрыл полумиллионный город

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


Какие интересные факты известны вокруг данного инцидента? Вот некоторые из них:
  1. Шифровальщик использовал EternalBlue - часть инструментария, утекшего двумя годами ранее из АНБ в результате атаки Shadow Brokers. Спустя два месяца EternalBlue использовался в рамках нашумевшего WannaCry. Иными словами, несмотря на ту шумиху, которую произвел WannaCry, администрация Балтимора так и не удосужилась устранить уязвимости, патч для которой был разработан до WannaCry за месяц. Интересно, что и многие системы обнаружения атак имеют сигнатуры для обнаружения факта использования EternalBlue, но, видимо, они также не использовались в крупнейшем городе штата Мэриленд.
  2. Вредонос начал свое победоносное распространение через фишинг, направленный на одного из служащих муниципалитета. Но был ли он целенаправленным или случайным пока неизвестно. В любом случае русских хакеров в атаке пока не обвиняли :-)
  3. За последние 7 лет 4 CIO Балтимора были уволены или ушли самостоятельно, а два до сих пор находятся под следствием (за неправомерные расходы и сексуальный харассмент). Как это знакомо, не правда ли? В России тоже многие руководители ИТ госорганов обвинены в растратах и "сидят" в ожидании приговора суда (а кто-то уже и сидит). Получается, что нормально развивать ИТ и ИБ в Балтиморе не удавалось - каждые 1,5 года начальство, определяющее путь развития города, менялось. В 2017-м году Gartner разработал для Балтимора 5-тилетний план развития, но реализовать его пока не удалось.
  4. Бюджет ИТ (включает расходы и на ИБ) составлял всего 2,5% от общего бюджета города, что вдвое ниже средних цифр американских городских бюджетов. Менеджер по ИБ на бюджетном комитете просил денег на мероприятия по ИБ, но ему было отказано. В повышении осведомленности муниципальных служащих тоже. 
  5. RobbinHood до Балтимора накрыл еще один американский город - Гринвиль в Северной Калифорнии. А всего в этом году около 20 муниципалитетов в США столкнулось с шифровальщиками (нашим бы тоже задуматься). Кстати, в 2018-м году в Балтиморе от шифровальщика уже пострадала одна из систем (служба 911). Произошло это из-за отключенных в процессе поддержки внутренних систем правил на МСЭ. Однако никаких уроков, видимо, сделано так и не было. 
  6. В прошлом году, в марте, накрыло Атланту (вредоносом SamSam) - еще один крупный город Америки. Злоумышленники требовали выкуп вдвое меньший (50 тысяч), чем в Балтиморе, а итоговая сумма восстановления всех пострадавших систем составила около 17 миллионов долларов. Кстати, в Атланте было страхование от кибератак, в отличие от Балтимора. 
  7. Про это нигде не говорится, но судя по тому, что многие системы не восстанавливаются уже три недели, а ту же почту и вовсе перенесли в облако (это рекомендовалось Gartner'ом), "забив" на восстановление, можно предположить, что резервных копий в Балтиморе не было (хотя мэр говорит, что они есть).
  8. Плана реагирования на инциденты в муниципалитет не было, что тоже удивительно. План ручного восстановления был разработан спустя две недели после начала эпидемии. Отчасти оправдать это можно тем, что в Балтиморе мэр вступил в должность за несколько дней до эпидемии RobbinHood и многие должности в администрации пустовали, что и привело к хаотическому метанию из стороны в сторону. Прежний мэр ушел в отставку из-за обвинений в растущей коррупции (тоже знакомо, да?).
  9. Интересно, что часть ИТ-инфраструктуры была размещена в облаке Amazon, но город почти и ее потерял, так как раз в начале мая завершился контракт на поддержку, который не могут продлить из-за неработающих систем оплаты счетов.
  10. Время восстановления городской ИТ-инфраструктуры, по словам нового мэра, оценивается в месяцы. Ряд систем необходимо будет перестроить заново.

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

27.05.2019

Новые положения Банка России: новые требования и новые вопросы

После того, как осенью прошлого года ЦБ получил новые полномочия по установлению требований по безопасности не только в рамках НПС, но и вообще для кредитных и некредитных организаций, финансовой регулятор выпустил сразу несколько новых нормативных актов:
  • 672-П - положение по защите информации в платежной системе Банка России, которое пришло на смену 552-П. Это первое положение регулятора, которое ссылается на ГОСТ 57580.1 с базовыми защитными мерами. Однако, эта ссылка, наряду с упоминанием и обязательным использованием 382-П, у меня вызвало некоторую фрустрацию. Дело в том, что ГОСТ 57580.1 построено по совершенно иной идеологии - оно разрешает самостоятельный выбор защитных мер. В отличие от 382-П, которое обязывает применять определенный набор из защитных мероприятий. Получается, что в одном документе нас отсылают на ГОСТ с самостоятельным выбором мер ИБ и на 382-П, где меры уже за нас выбраны Банком России. И какой тогда смысл было ссылаться на ГОСТ?
  • 683-П - положение по защите информации, суть и необходимость которого от меня немного ускользает, так как я не могу до конца понять его соотношение со схожим 382-П. Да, у них есть и некоторая разница, но все-таки сфера их действия достаточно сильно пересекается. Можно было бы предположить, что 683-П - это прообраз будущего нормативного акта, который заменит 382-П и в котором не будет обязательного списка защитных мер, которые уйдут в ГОСТ. Но пока 382-П продолжает действовать...

Ключевые вехи 683-П

  •  684-П - положение по защите информации для некредитных финансовых организаций. Этот документ устанавливает требования для НПФ, клиринга, репозитариев, ПИФов, депозитариев, брокеров, управляющих, регистраторов и других свои требования по защите информации в соответствие с ГОСТ 57580.1. Самое неприятное в этом нормативном акте - сертификация платежного/финансового ПО в ФСТЭК на наличие уязвимостей и НДВ (видимо, все-таки, на их отсутствие) или анализ уязвимостей по ОУД4. Боюсь, что многие финансовые организации просто не в состоянии это будут сделать до 1-го января 2020 года (осталось всего 7 месяцев). И, кстати, к какому уровню защиты относить микрофинансовые организации? В 684-П про это ни слова и возникает вопрос - они вообще должны что-то делать с точки зрения защиты или ГОСТ 57580.1 на них не распространяется? 

Ключевые вехи 684-П
В связи с этими новыми документами у меня, после их прочтения, возникло ряд вопросов:
  • ЦБ ссылается на требования ФСТЭК по сертификации на наличие уязвимостей или НДВ. Но у ФСТЭК такие требования отменены были еще до принятия документов ЦБ и заменены на уровни доверия. Какой уровень доверия должен быть у прикладного ПО по требованиям ЦБ? ЦБ обещал выпустить профиль для сертификации такого ПО, но только к концу года. Откуда разработчики платежного софта, особенно если это внутренняя разработка, как у многих, получат ДСПшные документы ФСТЭК? И будут ли испытательные лаборатории ФСТЭК заниматься такой сертификацией, если ФСТЭК регулярно говорит на мероприятиях, что они берутся за сертификацию только средств защиты информации?
  • Если пойти по пути не сертификации прикладного ПО, а анализа уязвимостей по ОУД4, то какова процедура и форма подтверждения для этого варианта? Можно ли проводить анализ защищенности самостоятельно, как это написано в 684-П, или в 683-П/672-П надо привлекать лицензиатов ФСТЭК?
  • Как (и зачем) проводить оценку соответствия одновременно по 382-П и ГОСТ 57580.2? Особенно в тех случаях, когда сроки этой оценки не совпадают. И я молчу про оценку по СТО БР ИББС, которую до сих ряд банков продолжает делать, так как формально она не отменена (как и сам СТО).
Активность созданного в прошлом году Департамента ИБ можно только приветствовать, но появляется слишком много вопросов даже по относительно "старым" требованиям. Чего уж говорить о свежих требованиях по той же ЕБС или по еще невыпущенным требованиям по финтеху (цифровому профилю, маркетплейсу, мастерчейну), СУОР и другим.

Ну а в заключение сводный слайд по все возрастающей отчетности по ИБ, объем которой только возрастает.


23.05.2019

Атрибуция кибератак (презентация)

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

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



Вторая причина заключается в том, атрибуция - это часть более крупного процесса под названием Threat Intelligence и вся картинка будет выглядеть следующим образом:

  • определение того, ЧТО на вас напало - работа с индикаторами компрометации
  • определение того, КАК это произошло - определение тактик, техник и процедур злоумышленников
  • определение того, СЛУЧАЙНО ли это произошло или является частью целой КАМПАНИИ
  • определение того, КТО стоит за атакой и ПОЧЕМУ кто-то нас атакует.
То есть атрибуция - это всего лишь вершина Threat Intelligence, достижение которой нужно не всем и не всегда. В обычной корпоративной среде обычно хватает ответов на первые два, максимум, три вопроса.

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




22.05.2019

Техническая защита персональных данных. Как соблюсти GDPR и ФЗ-152 (презентация)

Вчера я по приглашению выступал в рамках московского GDPR Day, на котором меня коллеги из Б-152 попросили разбавить рассказы юристов о мерах по защите прав субъектов ПДн экскурсом в технические меры по защите ПДн и насколько можно совместить требования 32-й статьи GDPR и 21-го приказа ФСТЭК, разработанного во исполнение ФЗ-152. Получилась вот такая презентация:



В рамках презентации я ссылаюсь на исследование, которое проводила Cisco в ряде стран мира, включая и Россию, которое было посвящено готовности компаний к GDPR и что дает выполнение этих нормативов операторам ПДн. Это исследование мы переводили и на русский язык и выложили на сайте.

17.05.2019

Выбрана тема финала "Нашей игры", интеллектуального шоу по кибербезопасности!

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


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

Финал "Нашей игры" состоится 10 июня! Заглавной темой станет... та-дам... "Россия"! Да-да, финальную игру этого сезона мы посвятим нашей необъятной Родине и ее отрасли кибербезопасности/информационной безопасности/защиты информации. Раз уж нашу страну обуял дух импортозамещения и киберпатриотизма, то мы решили проверить, насколько наши участники (а это три команды - Steak Holders, НеSOCрушимые и Anti-APT Group) знают историю, технологии, регуляторику, имена, продукты, инновации отечественной отрасли ИБ?! 

16.05.2019

О методике ФСТЭК по поиску аппаратных уязвимостей и НДВ

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


Чуть позже, ФСТЭК выпустила ДСПшную методику выявления уязвимостей и недекларированных возможностей в программном обеспечении. Интересно то, что в этом документе ФСТЭК декларировала появление методики выявления уязвимостей и НДВ в аппаратном обеспечении. А вчера стало известно об обнаружении уязвимости в процессорах Intel, названной Zombieload. Это продолжении серии уязвимостей Spectre, Meltdown и Foreshadow, найденных в продукции главного производителя процессов за последнее время. Интересно, что исследования, позволившие найти данную уязвимость, длились больше года.


И вот тут у меня появилось ряд вопросов, которые я позволю себе просто озвучить в рамках данной заметки:
  1. Планирует ли регулятор разрабатывать свою методику с нуля или будет ориентироваться на уже существующие стандарты (AS6081, AS5553, AS6171 и ARP6178 от SAE G-19A, CTI CCAP-101, IDEA-STD-1010 и др.) в этой и смежных областях, например, в аэрокосмической? Они хоть и не посвящены целиком безопасности, но очень недурно описывают таксономию методов поиска.
  2. Будут ли методы поиска уязвимостей и НДВ в новом документе привязаны к уровням/классам защищаемой информации/систем? Допускаю, что да, но тут важно не требовать очень уж серьезных проверок на низких уровнях доверия (например, на 6-м). Учитывая, что таких методов существует немало, то это будет непростая задача.


  3. Будет ли методика учитывать различные типы аппаратных компонентов - цифровые (например, ASIC или FPGA, как это сделано в ряде иностранных средств защиты уже сейчас), аналоговые (например, АЦП и ЦАП или DAC и ACD в англоязычной литературе), дискретные (например, резисторы, диоды, транзисторы и т.п.)?
  4. Какие требования будут предъявляться к разработчикам средств защиты в части аппаратных компонентов? Особенно учитывая, что сегодня нет российских ИБ-производителей, которые бы изготавливали железо целиком сами. А уж использование чужих компонентов, часто из Китая или Тайваня, происходит сплошь и рядом.

  5. Как будет учитываться тот факт, что сегодня НДВ может быть внесена в процессе транспортировки готового изделия от производителя к потребителю? Или вообще быть внесена уже в процессе эксплуатации (если используется перепрограммируемые микросхемы). В этом случае процедура выявления на стороне производителя ничего не даст.
  6. Насколько увеличится цена работ по сертификации?
  7. Насколько увеличится длительность работ по сертификации? Она и сейчас не очень маленькая и часто срок сертификации превышает срок жизни конкретной версии оцениваемого ПО. А уж при наличии нового документа ситуации и вовсе станет аховой.
  8. Наличие оборудования для проведения соответствующих работ; особенно сертифицированного по требованиям регулятора. Во-первых, оно очень дорогое для определенного типа проверок. А, во-вторых, оно не выпускается в России.

  9. Будут ли выставлены требования по компетенциям сотрудникам испытательных лабораторий? Если да, то где им проходить обучение? А если нет, то не превратится ли процесс оценки в профанацию?
  10. Как ФСТЭК будет проверять качество проводимых работ и есть ли у самого регулятора соответствующие специалисты? 
  11. Что делать, если у ИЛ или регулятора появятся вопросы к используемым аппаратным компонентам? Недавно один из российских производителей МСЭ поделился своей болью. Для выполнения одного из пунктов методики проверки МСЭ по новым требованиям ФСТЭК, им потребовалось поменять ряд ранее используемых аппаратных модулей, из-за чего стоимость возросла в разы. И, конечно же, эти затраты будут возложены на плечи заказчиков, большая часть из которых относится к государственных органам, которые обязаны будут применять только сертифицированные средства защиты.
  12. Будут ли признаваться результаты СИ/СП, проводимых по линии ФСБ, для тех решений, которые подаются на сертификацию еще и в ФСТЭК?
  13. Готова ли ФСТЭК к существенному изменению правил игры, которые даже многие отечественные вендоры не смогут соблюдать?
Вот такая чертова дюжина вопросов к еще неразработанному документу регулятора. Вполне допускаю, что у регулятора уже есть на них ответы. Но, вспоминая песню Слепакова, "а чё, мля, если нет?" 

А напоследок вам задачка, какие из представленных ниже семплов могут представлять угрозу?

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

14.05.2019

Концепция "низковисящих фруктов" и кибербезопасность

Между майскими праздниками Verizon выпустила новую версию своего отчета 2019 Data Breach Investigations Report, который давно уже перестал быть отчетом только одной компании, - в работе над ним принимают участие многие игроки рынка ИБ, среди которых Cisco, Shodan, CERT EU, JPCERT, ФБР, Секретная служба США и т.п. Из "россиян" в подготовке отчета участвовала только Лаборатория Касперского.

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

В бизнесе есть такая часто применяемая концепция "низковисящих фруктов", которая означает получение быстрой выгоды прямо сейчас (сорвать то, что ближе всего). Зачем делать что-то очень долго и без видимого результата, когда можно сорвать куш гораздо быстрее? Тоже самое приходит в голову и злоумышленникам, которые не хотят долго кого-то ломать, а предпочитают быстрые и легкие победы. Ровно это и показывает отчет 2019 DBIR, который показывает, что большая часть всех подтвержденных взломов осуществляется всего в один-два шага.


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


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

С точки зрения стратегии безопасности концепция низковисящих фруктов также применима - нам не обязательно внедрять сразу кучу различных навороченных защитных технологий, которые стоят недешево (тем более, что 43% жертв - это малый бизнес). Достаточно начать с базовых вещей, которые описаны в таких лучших практиках как Top20 CIS Controls, Top 4/8 австралийского МинОбороны, Топ10 английского или канадского регулятора по ИБ. Обо всех них я уже говорил на прошлой РусКрипто в полуторачасовой презентации. Что характерно, эти основные меры не требуют особых затрат на реализацию. Австралийский Топ 4 включает в себя application whitelisting (замкнутая программная среда), обновления приложений и ОС, а также контроль привилегированного доступа. Все это можно реализовать с помощью групповых политик и Windows Update Service (для Windows). По оценкам одна только эта четверка обеспечивает защиту от 85% угроз.

В заключение все-таки приведу несколько интересных тенденций, упомянутых в отчете 2019 DBIR:

  • Существенно возросло число атак типа "социальный инжиниринг" (через фишинг), а человек - стал одной из популярных мишеней для злоумышленников.
  • Одним из основных способов, которые используют злоумышленники для своего первого шага (а иногда и единственного) - использование украденных учетных записей пользователей.
  • Один из основных векторов атак - Web-приложения.
  • Электронная почта остается основным вектором для получения вредоносного кода (94%). Исключение составляет сфера образования, где на первое место вышел Web-вектор заражения.
  • По-прежнему самым популярным типом файлов для вредоносного ПО является MS Office.
  • Одной из самых быстрорастущих причин успеха злоумышленников становится некорректная конфигурация серверов (особое внимание злоумышленники уделяют почтовым серверам) и пользовательских устройств.
  • Обнаружение инцидентов по-прежнему занимает месяцы в то время как на компрометацию у злоумышленников уходят минуты, а на кражу данных - от минут до дней.
В целом могу порекомендовать ознакомиться с отчетом Verizon. И пусть вас не смущает, что отчет подготовлен американским оператором связи. В подготовке участвовали компании со всего мира, включая и российскую. Поэтому можно говорить о том, что отчет отражает общую для всех картину.