2.7.19

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

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

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


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

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

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

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

1.7.19

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

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


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

26.6.19

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

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


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

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

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

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

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

25.6.19

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

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

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


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


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


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

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


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


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


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

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

24.6.19

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

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

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

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


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

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

17.6.19

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.6.19

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

4.6.19

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

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

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


3.6.19

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

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



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

31.5.19

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

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



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


29.5.19

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

Как-то российская блогосфера и отечественные СМИ обошли вниманием интереснейшую историю, которая творится в американском Балтиморе, недалеко от которого расквартировано Агенство национальной безопасности США. Так вот 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.5.19

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

После того, как осенью прошлого года ЦБ получил новые полномочия по установлению требований по безопасности не только в рамках НПС, но и вообще для кредитных и некредитных организаций, финансовой регулятор выпустил сразу несколько новых нормативных актов:
  • 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.5.19

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

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

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



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

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

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




22.5.19

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

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



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

17.5.19

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

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


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

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

16.5.19

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

На фоне обвинений Китая в закладках на уровне материнских плат, которые звучали в начале года, я прошел обучение по теме тестирования аппаратной части современных ИТ-решений на предмет поиска различных уязвимостей - от контрафакта или клонирования до закладок и временных бомб в кремнии. Это было очень познавательный тренинг, который расширил мои знания в области тестирования не только программной, но и аппаратной части средств обеспечения безопасности. Кстати, рынок такого контрафактного оборудования (включая и содержащего закладки) оценивался в 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.5.19

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

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

13.5.19

Ответьте на вопрос: "что такое информационная безопасность", не подглядывая в блог

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


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

8.5.19

Второе наблюдение на СВОП: Китай нам не товарищ, но и автаркия - не вариант

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

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

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

К слову об автаркии. Это экономическая политика, замкнутая целиком на себя, с отсутствием внешних экономических связей. Целиком и полностью суверенная экономика. В мире было несколько примеров стран, которые в определенные моменты своей истории стремились стать автаркиями (тот же СССР во времена противостояния с США или Германия, Италия и Япония во время Второй мировой войны). Сегодня абсолютное большинство экспертов признают, что полная автаркия невозможна и даже такая изолированная от внешнего мира страна как Северная Корея не является автаркичной, активно развивая внешние торговые связи. Другое наблюдение экспертов - автаркия обычно означает, что государство готовится к войне и стремится снизить риски от внешних поставок. При этом, и тут мнение почти единогласное, автаркия означает отсталость государства ее принявшего в экономическом и, что важнее в контексте нашей тематики, технологическом плане.

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

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