Провожу киберучения вместе с ФСБ, ФСТЭК и ЦБ

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

У нас в компании накопилось достаточно фактов и цифр о людях, работающих в SOCах по всему миру, и пришло время этой информацией поделиться. Я буду выступать во второй день SOC Forum, в секции "Люди и процессы". Доклад свой я назвал достаточно дискуссионно - "Почему первая линия SOC бесполезна? Цифры и факты", но это неслучайно. Я попробую, опираясь на статистику, показать, почему уровень L1 в современном SOCе не только не нужен, но и вреден.

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

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

Уже сформировано 6 команд, которые изъявили поучаствовать в этом интерактиве:

• Сборная Сбербанка
• Сборная "Кибер Коммандос"
• Сборная Гринатома "DROP TABLE"
• Сборная ЗащитаИнфотранса "ЦКБ" (надеюсь, не центральная клиническая больница)
• Сборная "Steak Holders", которая уже выиграла недавно проведенную интеллектуальную "Нашу игру", посвященную SOCам
• Сборная RUSCADASEC

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

Приходите на SOC Forum, будет нескучно :-)

Подробнее…

Устранение уязвимостей. Подход №2

Решил вернуться я к теме, поднятой неделю назад, относительно приоритезации устранения уязвимостей. Никита Ремезов в Фейсбуке справедливо заметил, что она ориентирована в первую очередь на госов и надо признать, что это так. К этой схеме он предложил добавить привязку к критичности сканируемых ресурсов для бизнеса. Да, и это тоже верно и контекстные метрики в CVSSv3 могут помочь это сделать. Преимуществом данной методики является ее простота. Чтобы ею воспользоваться не нужно ничего, кроме сканера безопасности, поддерживающего CVSS. Хотя даже он не нужен. Идентифицировать уязвимости можно либо путем анализа сетевого трафика

Список уязвимостей, идентифицируемых NGFW

либо использованием средств защиты ПК, которые часто имеют такие возможности.

Список уязвимостей, найденных на защищенных EDR узле

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

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

Детализация карты сети сильно не улучшает ситуацию. Описанная в прошлой заметке методика не поможет в такой масштабной сети.

А надо ли это? Надо ли устранять все уязвимости? Даже те, у которых CVSS больше 6.5? А если попробовать пойти по иному пути и в scope работ по устранению уязвимостей включать не все, а только то, что может быть использовано извне? Вспомним историю с Equifax. Злоумышленники воспользовались уязвимостью на публичном Web-портале и через нее проникли во внутреннюю сеть бюро кредитных историй. Таких уязвимостей будет на порядки меньше и именно с них можно начинать устранение (по методике или без нее).

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

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

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

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

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

Подробнее…

Видео "Нашей игры" по SOCам

Вот и подоспело видео с "Нашей игры", посвященной SOCам, которая прошла пару недель назад. Задорненько получилось. Респект операторам и монтажерам :-)



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

Подробнее…

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

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

У российских специалистов эта тема вызывает лишь улыбку - никаких серьезных доказательств не представлено, а те, что опубликованы в докладе Мюллера, докладах американской разведки, в исследованиях американских ИБ-компаний, рассматриваются с точки зрения нечестных методов геополитической борьбы, в которых все методы хороши, лишь бы удержаться на вершине геополитического Олимпа. Ну действительно, можно ли всерьез рассматривать в качестве доказательства использование в атаках российских IP-адресов, московский часовой пояс и имя "Феликс Эдмундович" в коде найденных вредоносных программ? Смешно. Но в последнее время уровень представленных доказательств изменился. В ход пошли такие факты, которые сложно выявить чисто техническими мероприятиями - ФИО, должности, звания, места дислокации, номера в/ч и т.п. Все это говорит либо о том, что у американцев и их партнеров есть и оперативная информация о том, что и кто осуществляет различные действия в киберпространстве от имени России, либо об усилении дезинформации западного общества и приведении якобы неубиенных фактов, которые должны лишний раз доказать вину России.

Лично я не знаю, какая из этих версий более реалистична (вполне возможно, что обе). Только я вижу что:

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

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

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

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

1. Готов ли я строить систему ИБ своей организации на решениях, происходящих из стран - геополитических противников? Если нет, то какова альтернатива? Если да, то каковы пути отхода, если с этими решения что-то "вдруг" произойдет?
2. Если в качестве альтернативы мы рассматриваем Китай, то где гарантии безопасности со стороны этого "союзника" (союзником, кстати, его называет только Россия, - Китай по отношению к нам это слово не использует никогда)?
3. Готов ли я к тому, что российские компании, решения которых я выбрал для своей системы ИБ, будут внесены в санкционные списки и я могу столкнуться с риском вторичных санкций?
4. Готов ли я к атакам со стороны не только киберпреступников, но и целых государств и их спецслужб (если я интересен для них)?
5. Готов ли я к отключению Рунета от всемирной Сети? Можно и в более легкой форме задать этот вопрос. Что я буду делать в случае учащения случаев блокировок иностранных IP-адресов (актуально для активных пользователей XaaS-платформ)?

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

Подробнее…

Устранять или нет? Вот в чем вопрос!

Malotavr, который недавно вновь вернулся в эпистолярный жанр по ИБ, обратил свое пристальное внимание на тему управления уязвимостями (тут и тут). И это немудрено, учитывая место его работы - компанию Positive Technologies. Так сложилось, что и я недавно погрузился в эту тему, задавшись достаточно простым, на первый взгляд, вопросом - как приоритезировать уязвимости, которые надо устранять? Их могут тысячи и даже сотни тысяч в крупной инфраструктуре. Вариант "устранять все" в реальной жизни не работает. Пока мы устраняем одни уязвимости (в каком порядке? по времени? по критичности узла? по критичности уязвимости?), злоумышленники могут воспользоваться другими. Устраняя "другие", злоумышленники могут воспользоваться третьими. И так далее. Где провести ту грань, за которой уязвимость может быть отложена "на потом"?

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

• 23% опубликованных уязвимостей имеют эксплойт.
• 2% уязвимостей имеют эксплойт в диком виде.
• Вероятность уязвимости быть использованной в 7 раз выше, если эксплойт существует. 
• 50% эксплойтов публикуется в течение двух недель после обнаружения уязвимости.

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

В ней я отталкиваюсь в первую очередь от общего рейтинга CVSS; затем смотрю на наличие эксплойта (либо из Банка данных уязвмостей ФСТЭК, либо из CVSS); потом на наличие удаленной эксплуатации дыры (параметр AV в CVSS), и, наконец, на сложность получения доступа (параметр AC в CVSS). Все значения берутся из полей БДУ. В реальной жизни для проверки наличия эксплойта и подтверждения CVSS обычно используются перекрестные базы (NVD, Secunia, ExploitDB, Cisco, Vulners и т.п.), но для ряда пользователей, особенно государственных, использовать зарубежные БД было бы не совсем правильно. К сожалению, наполнение БДУ пока не идеально (особенно в части оперативной информации по наличию эксплойтов), но другой возможности у госов нет (хотя тот же Vulners имеет российские корни, но "не признан" регулятором).

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

Понятно, что у схемы есть и свои ограничения. Например, мы отсекаем локальные уязвимости без эксплойта с CVSS ниже 6.5, которые могут быть использованы злоумышленником, имеющим физический доступ к объекту защиты. Но тут я исхожу из предположения, что потребитель все-таки имеет хоть какие-то меры по контролю физического доступа, усложняющие эксплуатацию локальной уязвимости (хотя риск инсайдера остается). Также за двухнедельный временной зазор может быть разработан эксплойт и система может быть взломана. Можно попробовать уменьшить этот срок, но тогда мы слишком часто будем запускать цикл проверки, что для многих систем, особенно ГИС/МИС, будет непросто. Также я исхожу из того, что при отсутствии мер защиты безопасники все-таки смогут разработать компенсирующие меры (отключить уязвимую систему от сети, заменить уязвимое устройство, установить «виртуальный патч», зарезервировать систему, заблокировать использование уязвимости с помощью МСЭ или IDS и т.п.). Если нет, то тут уже ничего сделать нельзя :-(

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

Подробнее…

ФЗ коряв, но он ФЗ. Его изменят, но когда, ХЗ!

В пятницу ряд доблестных блогеров, активно, но не всегда верно, пишущих о различных законодательных инициативах и особенно о ФЗ-187, были приглашены на профилактическую, ой, беседу, целью которой было ознакомить блогерскую общественность со взглядами регулятора на безопасность критической инфраструктуры. За месяц до этого, через блогеров было собрано более 150 предельно конкретных вопросов, ответы на которые интересовали субъектов КИИ, а также интеграторов, оказывающих услуги в сфере, регулируемой ФЗ-187. Встреча состоялась, но ее результаты немного отличались от первоначальных ожиданий.

Алексей Лукацкий, Сергей Борисов, Александр Кузнецов, Алексей Комаров, Валерий Комаров (они с Алексеем не братья), Павел Луцик

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

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

1. "ФЗ коряв, но он ФЗ". Это общая мысль к тексту ФЗ-187, который содержит немалое количество ляпов, в том числе и терминологических. Но общее мнение регуляторов, законодателей и приближенных к ним - менять ФЗ сейчас неразумно. Должно пройти минимум года два, прежде чем об этом всерьез задумаются. Поэтому ни изменения понятия "объект КИИ", ни понятия "субъект КИИ", ни перечня сфер деятельности не будет в ближайшее время.
2. Подход к определению объектов КИИ от критичности процессов, которые ИС обслуживает, останется неизменным. И его поддерживает и ФСБ в том числе. Поэтому разночтений с тем, считать объектом КИИ то, что написано в ФЗ-187 или в ПП-127, у регуляторов нет.
3. Позиция некоторых субъектов, считающих, что если они могут перейти на ручной режим работы, то у них нет значимых, и вообще объектов КИИ, не является верной. Важна не только доступность ИС, но и ее влияние на критический процесс. Если в результате направленного (и этот момент достаточно важен - направленность, то есть злой умыслел) воздействия на ИС будут изменены какие-либо показатели, в результате чего будут предприняты какие-то действия, приводящие к ущербу, то такая ИС тоже должна считаться объектом КИИ. Иными словами, при категорировании надо думать не только о доступности ИС.
4. Планы по изменению нормативных актов:
• Будут изменены некоторые показатели в ПП-127 с целью уменьшения числа объектов КИИ, которых и так слишком много; даже при учете критичности процессов при категорировании. Например, изменят в сторону увеличения масштаб территории, которая может пострадать от направленного воздействия на объект КИИ.
• Будут уменьшать число сведений, которые должны будут отправляться в ФСТЭК по результатам категорирования. Например, исключат сведения об уязвимостях, а некоторые сведения будут загрублять, чтобы процесс категорирования не превращался в пытку (например, в части составления перечня угроз).
• Попробуют увеличить масштаб объектов КИИ, чтобы их число было не катастрофически большим. По озвученным оценкам ФСТЭК (странно, что это не было сделано при внесении законопроекта в Госдуму) в России насчитывается около 12000 субъектов КИИ (оценка примерная - было озвучено, что приславшие к моменту встречи перечни 590 субъектов - это 5-6% от их оценочного числа). Субъекты имеют, в среднем (по моей оценке озвученных ФСТЭК данных), около 40 объектов КИИ. Итого полмиллиона объектов КИИ - колоссальная работа для регулятора.
• Пересмотрят экономические показатели, так как некоторые субъекты начинают манипулировать показателями с целью ухода от значимых объектов. И доказать "махинации" достаточно сложно.
• Планируется ввести новую статью в КоАП, в дополнение к 13.12. Дело в том, что 13.12 наказывает только за нарушение обязательных требований по защите, но, например, за непредоставление перечня, за некатегорирование, за нарушение правил категорирования, за неотправку данных в ГосСОПКУ и пр. наказаний не предусмотрено. Этот пробел хотят устранить и повторить идею со статьей 13.11 КоАП по персональным данным. Наказывать по ней смогут и ФСТЭК, и ФСБ.
• Планируют вернуть сроки составления перечня объектов КИИ, от которого будет отсчитываться год на само категорирование. Вариантов рассматривается два - или как было (перечень с последующим категорированием), или конкретный срок (например, конец 2019-го года), к которому надо завершить категорирование.
• Новое ПП, которое планируют вносить в Правительство в первом квартале 2019-го года, обратной силы иметь не будет. То есть перекатегорировать ничего не надо будет. 
• В приказах ФСТЭК планируют учесть обеспечение ИБ в холдинговых и интегрированных структурах.
5. Наличие компенсирующих мер (например, резервирования) не является основанием для некатегорирования объекта и присвоения ему незначимой категории.
6. Сеть электросвязи - это не объект КИИ.
7. Водоканал - это... Все зависит от конкретной организации. Дело в том, что водоканал, как организация, занимающаяся водоснабжением и водоотведением, не относится к субъектам КИИ, так как такой сферы в ФЗ-187 нет (хотя в КСИИ была). А вот когда в Уставе конкретного ООО "что-тотамводоканал" написано про обслуживание электротехнических установок или про генерацию тепловой энергии (горячая вода и пар), то это уже сфера ТЭК со всеми вытекающими. Если вы введете в Google "водоканал устав", то найдете много готовых уставов различных водоканалов с различными целями существования организации, которые могут и попасть под действие ФЗ-187.
8. ОМСУ - не является госорганом, а значит и не попадает в список субъектов КИИ. 
9. Немного не в тему КИИ, но прозвучала интересная информация. Оказывается есть несколько решений судов, в которых признано, что информационные системы различных ГУПов и ФГУПов являются государственными, даже несмотря на то, что ГУП/ФГУП - это коммерческая структура. Продолжаю придерживаться позиции, озвученной мной в 2015 году, но с позицией судов спорить может только сам ГУП/ФГУП.
10. Если удаленный доступ (в контексте приказа ФСТЭК) осуществляется с помощью VPN, то это не удаленный доступ, а локальный. Не самый логичный вывод, но зато снимает ряд проблем, связанных с привлечением для проведения регламентных работ сотрудников сторонних организаций.
11. Сенсацию (для меня) я оставил на самый конец. Прозвучала позиция регулятора (я с ней не согласен), что если деятельность субъекта КИИ зависит от облака, в котором не только размещаются данные, но и ведется работа (как делают некоторые ЛПУ с облачными медицинскими ИС), то облако надо считать объектом КИИ этого субъекта! Как при этом получить информацию об уязвимостях, угрозах, мерах защиты и т.п., не совсем понятно. Рекомендация "договариваться" классная, но в реальной жизни не работает. Если логику ФСТЭК наложить на ДБО, которым пользуется нефтяная компания, которая из-за атаки на ДБО может недосчитаться денег на счете и недоплатит денег в бюджет, то получится, что ДБО банка - это объект КИИ нефтяной компании!!! Я посмотрю на попытки нефтяной компании получить информацию от банка об уязвимостях в ДБО, ее мерах защиты, модели угроз, списке допущенных лиц и другой достаточно критичной информации, требуемой для категорирования. Такая позиция ФСТЭК имеет далеко идущие и негативные последствия для многие субъектов, использующих услуги аутсорсеров.

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

ЗЫ. Да, кстати. Встреча началась с того, что Виталий Сергеевич Лютиков укорял некоторых экспертов, которые, выступая на публичных мероприятиях по КИИ, говорят не то, что говорит регулятор на своих мероприятиях, по сути перевирая слова ФСТЭК, что потом приводит к куче головной боли. В качестве примера было приведено высказывание одного из экспертов, который на большйо конференции высказал мысль, что перечени объектов КИИ надо направлять на имя Шевцова Дмитрия Николаевича, начальника 2-го Управления ФСТЭК. Это неверно! Так что стоит учитывать, что и я могу неверно трактовать те или иные высказывания регулятора :-) Но, надеюсь, если я местами не прав, мне старшие товарищи укажут на это. Отчасти именно поэтому ФСБ не практикует такие встречи - слишком много потом разгребать приходится :-) Не могу их винить за это, хотя открытость ФСТЭК мне импонирует больше.

ЗЗЫ. Также своим мнением о встрече поделились и коллеги:

• Алексей Комаров
• Александр Кузнецов
• Павел Луцик

Обзоры от Сергея Борисова и Валерия Комарова, надеюсь, появятся у них в блогах.

Подробнее…

Коммерческим SOCам нужна еще и лицензия ФСБ на шифрование

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

1. Согласно требованиям ФСТЭК, для оказания услуг по мониторингу ИБ (а это то, что в том числе делает центр ГосСОПКИ) в обязательном порядке необходимо иметь сертифицированные в ФСБ средства защиты каналов передачи данных, которые должны обеспечивать конфиденциальность данных, передаваемых между SOC и теми, кого этот SOC мониторит.
2. В Facebook некоторые коллеги говорили, что на совещании в ФСТЭК, когда этот вопрос обсуждался, ФСТЭК заявила, что применение СКЗИ не является обязательным, а отдается на откуп лицензиату. Я, присутствуя на двух совещаниях ФСТЭК по этому вопросу, что-то не припомню такой позиции регулятора. Как раз наоборот. Он настаивал на том, что конфиденциальность должна быть обеспечена в обязательном порядке. А иначе зачем требовать покупку того, что можно и не использовать?
3. Подход ФСТЭК по обязательному обеспечению конфиденциальности между системой управления и управляемыми решениями в последнее время становится все более жестким - в последних проектах РД на новые типы средств защиты, а также в ответах ФСТЭК на вопросы по смежным темам, явно сквозит требование по применению сертифицированных в ФСБ СКЗИ. Да и вообще, достаточно странно выглядит идея, что регулятор в области защиты информации не будет советовать обеспечивать защиту канала, в который может вмешаться злоумышленник.
4. Подход ФСБ к наличию своей лицензии на деятельность в области шифрования известен уже много лет и он не меняется. ФСБ планомерно, а иногда излишне широко трактуя законодательство, требует либо поручать работы с СКЗИ лицензиатам, либо самим получать такую лицензию. Помнится ФСБ даже отвечала, что все, что было указано в Постановлении Правительства, независимо от возмездности оказания услуг и интересов (исключая один из видов работ, про который прямо сказано, что его для собственных нужд можно и без лицензии), требует лицензии ФСБ. С тех пор сменилось и само ПП (с 957-го на 313-е), и руководство ЦЛСЗ, а подход остается неизменным. Отсюда и мои выводы о необходимости лицензии ФСБ на шифрование.

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

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

Что в итоге? Большинство текущих коммерческих SOCов не имеет лицензии ФСБ на деятельность в области шифрования и поэтому отстаивает позицию, что такая лицензия не нужна. Я их понимаю :-) Их вроде как спасает тот факт, что за шифрование у нас отвечает 8-й Центр ФСБ, который же "рулит" и ГосСОПКОЙ. Но за лицензирование у нас отвечает ЦЛСЗ, а у него не всегда взаимопонимание с другим управлением регулятора, ответственного за нацбезопасность. По крайней мере, когда представители 8-ки с открытой трибуны заявляли про собственные нужды, ЦЛСЗ говорил прямо противоположное. И я бы рассматривал этот риск - за 171-ю статью УК отвечают именно они, а не 8-й Центр. 

Клиентам коммерческого SOC вроде как ничего не угрожает - им лицензия ФСБ для выбора SOC не нужна (если ключами управляют не они). Но что делать, если к коммерческому SOC вдруг возникнут вопросы по лицензированию? Его деятельность могут приостановить! Риск это, конечно, маловероятный, но и сбрасывать со счетов его не стоит. В любом случае этот риск надо осознавать.

Запугал? Нет? Ну и прекрасно :-) А если да, то что делать; жизнь такая, непростая :-) 

Подробнее…

"Наша игра" про SOCи

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

Учитывая грядущий SOC Forum, я не стал долго думать и посвятил 61 вопрос игры именно этой теме. Первая половина вопросов далась достаточно легко, а вот над второй пришлось помучаться. Дело в том, что "Наша игра" подразумевает точные ответы на поставленные вопросы. Никакой отсебятины. Никаких размышлений, рассуждений и предположений. Одни голые факты. А это, в свою очередь, предполагает, что участники должны скорее больше "знать", чем "уметь". Опыт работы в SOC, умение выстраивать процессы, реагировать на инциденты и т.п., тут не помогут.

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

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

Тему следующей игры пока не придумал. Возможно это будет "Безопасность АСУ ТП", а может быть "Вредоносное ПО", а может быть "Хакеры", а может и вовсе "Регуляторы". Посмотрим ближе к делу. А пока жду фильма по итогам игры. Да-да, по аналогии с другими известными интеллектуальными играми, "Наша игра" тоже записывалась для ТВ. 15 ноября на канале BIS TV должен быть выложен профессионально смонтированный фильм по итогам игры.

ЗЫ. Если хотите поучаствовать в игре (в любом качестве - участник команды, зритель, спонсор и др.), то обращайтесь в медиа-группу Авангард.

Подробнее…

Из чего складывается стоимость SOC?

После проведенной на CyberCrimeCon презентации "Как создать свой SOC?" в разных соцсетях и личных беседах прозвучало несколько вопросов по ее содержанию. В целом они сводились к тому, что слайды оказались местами высокоуровневыми, а местами требующими пояснений. Как в известной иллюстрации на тему "Как нарисовать сову":

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

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

Почему такой разброс? А все просто! Технологии бывают разные. Возьмем к примеру SIEM, который часто рассматривается как ядро SOC (что не совсем так). Мы можем купить Splunk Enterprise, MicroFocus Arcsight или PT SIEM, а можем воспользоваться бесплатным Apache Metron (бывший Cisco OpenSOC), SIEMonster, Prelude или вообще строить все на стеке ELK (Elasticsearch, Logstash, Kibana, Beats). Капитальные затраты в этом случае будут отличаться на порядке - от десятков и сотен тысяч долларов за коммерческий SIEM до бесплатного решения. Да, безусловно, для работы с бесплатным ПО потребуются специалисты немного иной квалификации, но зарплата - это отдельная статья затрат, которую я тоже рассматривал в презентации и которой я посвящу отдельную заметку.

При оценке стоимости создания SOC я бы посоветовал сделать табличку и заполнять ее по мере  необходимости. Пример таблички ниже:

На что стоит обратить внимание, заполняя табличку, и что влияет на итоговую стоимость технологического стека? Во-первых, кто владеет решением? Например, у вас в сети уже может стоять Cisco Stealthwatch, используемый для мониторинга сетевых аномалий. Значит мы исключаем статью затрат на решение класса Network Traffic Analysis, которое является частью современного SOC. А если ваши айтишники уже используется Splunk, то возможно не стоит покупать новый SIEM, а воспользоваться уже имеющимся решением, чуть расширив лицензию или докупив дополнительные модули "по ИБ".

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

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

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

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

Подробнее…

Интересное исследование по SOCам

Продолжу вчерашнюю тему про SOC. Тем более, что близится как SOC Forum, так и Cisco Security Operations Virtual Summit (последнее мероприятие пройдет онлайн 12-го ноября и будет бесплатным) и я готовлюсь к обоим событиям по теме мониторинга ИБ. Наткнулся на интересное исследование 148 специалистов, работающих в SOC; преимущественно американских, но также и в европейских. В данном отчете анализировались внутренние процессы, реализуемые в SOC, и делались прогнозы и выводы на будущее.

2 года назад я уже приводил распределение времени на выполнение различных задач у аналитиков SOC. В рассматриваемом исследовании распределение схожее. Нет какой-то явной активности - время распределяется равномерно между десятком задач, стоящих перед специалистами SOC. Если у вас есть SOC и у вас не так, то стоит задуматься, почему у вас перекос. Нельзя считать данное распределение эталоном, но все-таки данные от 100 SOCов могут рассматриваться в качестве некой точки отсчета.

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

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

То есть надо выстраивать программу повышения квалификации своих специалистов. И тут впору вспомнить вчерашнюю презентацию про то, как построить SOC. Я там привожу упрощенную пирамиду навыков и примерную стоимость обучения специалистов SOC разного уровня. За основу брал стоимость ряда курсов SANS - потому что в России многим вещам просто не учат. Возможно где-то есть и менее дорогие курсы - я не искал, ориентируясь на самый известный институт в мире. Но, возможно, Академия кибербезопасности Сбербанка или позавчера анонсированная Group-IB Cyber School смогут закрыть этот пробел. На самом деле карта обучения и повышения квалификации - это неотъемлемая часть любого проекта по SOCу (по крайней мере мы ее всегда делаем для заказчиков). Без нее куча затраченных на инструментарий денег превращается в пустышку. Не хочется вспоминать аналогию про обезьяну с гранатой, но она напрашивается. По ту сторону баррикад арсенал и TTP меняются постоянно, а, следовательно, и по эту знания должны обновляться также постоянно.

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

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

Подробнее…

Как создать свой SOC? (презентация)

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

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

Как построить SOC? from Aleksey Lukatskiy

ЗЫ. А еще на CyberCrimeCon раздавали классную сувенирку - экранирующие чехлы для смартфонов и банковских карт.

Подробнее…

Говорите на бизнес-языке?.. А что это?

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

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

Ну и если уж начали говорить про бизнес-язык, то могу посоветовать еще и книжку "Сам себе MBA", которая является неплохим руководством для тех, кто хочет понимать основы бизнеса, но не может потратить 2 года на программу MBA.

Подробнее…

А вы можете назвать все вектора атак на свою организацию?

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

В итоге достаточно легкого на первый взгляд задания большинство участников составило следущий перечень векторов атак:

• E-mail
• Web
• USB
• Личные устройства (например, руководства)
• Подрядчики
• Общие ресурсы (shared resources)
• Корпоративные мобильные устройства.

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

• Site-to-Site VPN (то есть проникновение из удаленных филиалов и допофисов по доверенному каналу)
• Remote Access VPN (то есть проникновение от домашних и мобильных работников, которые могли что-то подцепить за пределами компании)
• Wi-Fi
• Warez (сайты с пиратским ПО, откуда нередко скачиваются обновления, если заканчивается договор с производителем)
• Waterhole (заражение сайта производителя ПО, как доверенного источника, и получение вредоноса с него)
• DevOps (сопряжение тестовой сети и рабочей)
• Инкапсуляция (проникновение через разрешенный на МСЭ протокол). Вроде бы и E-mail с Web сюда же ложатся, - ведь внутри них может быть все, что угодно. Но это ловушка сознания - с Web и E-mail мы постоянно имеем дело, а вот про другие протоколы, в которые можно что-то инкапсулировать, забываем.
• DNS (частный случай предыдущего варианта), но учитывая как часто его использует вредоносное ПО, стоило выделить отдельно.
• Внедренный на этапе поставки вредоносный код в ПО или "железо". О, это замечательный вектор, о котором вообще мало кто думает и о котором я уже писал.
• Уязвимости на портале, через которые проникает злоумышленник внутрь (как в кейсе с Equifax)
• Шифрованный клиент-сервер (представьте, что клиент, за пределами периметра, отправил вам зараженный файл через шифрованный канал, предоставленный клиент-серверным приложением типа ДБО или госуслуг).

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

Подробнее…

Возрастающая роль OSINT

На прошлой неделе голландская разведка "раскрыла" миру очередные проделки "русских хакеров", которые пытались через Wi-Fi взломать Организацию по запрещению химического оружия (ОЗХО). А до этого в течение полугода мы наблюдаем за историей с разоблачением "сотрудников ГРУ", которые поехали смотреть шпили Солсберийского собора. А до этого было расследование крушения малазийского Боинга. Все эти истории объединяет одно - возросшая роль OSINT (Open Source Intelligence), позволяющей по открытым источникам собирать информацию и делать выводы в пользу той или иной версии.

Например, вот три слайда из презентации разведки Нидерландов, которые должны доказать связь пойманных и выдворенных россиян с ГРУ. Первый слайд показывает место активации мобильного телефона, изъятого у подозреваемых (определеяется по базовой станции). На втором слайде показано местоположение ближайшей к общежитию ГРУ базовой станции и оно совпадает с местом активации мобильника. На еще одном из слайдов презентации был показан чек на такси, на котором подозреваемые добирались до Шереметьево в начале своей поездки в Голландию. А третий слайд на картинке показывает применение Google Maps для идентификации места, куда было вызвано такси. Оно оказывается находится аккурат там, где проживают сотрудники ГРУ и выход из общежития ГРУ находится как раз на том переулке, куда было вызвано такси.

А вот еще пример. По фотографии из СМИ на исследовательском судне "Янтарь" обнаружены какие-то установки для проведения спецопераций.

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

Очень интересным оказалось расследование Bellingcat и The Insider двух фитнес-бизнесменов Петрова и Боширова, которых называют сотрудниками ГРУ. Очень яркий пример того, как можно использовать открытые источники (вплоть до фотографий с сайтов военных ВУЗов, где на досках почета оказываются лица, "похожие на") для сбора разведывательной информации. Вообще таких источников много. Например, недавно была выпущена вот такая карта инструментов для OSINT, одним из авторов которой является как раз Bellingcat.

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

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

Подробнее…

Сказка про трех хакерят

Жили-были в России три поросенка хакера. Три друга. Все одинаковые - молодые, активные, розовощекие. Даже имена у них были похожи - исконно русские, - Емеля, Ерема и Евлампий. Все свое отрочество они дурачились в банковских сетях, куролесили в Интернет, пользовались украденными у рядовых граждан деньгами, бахвались размерами своего стека, мерялись числом имеющихся у них "зеродеев", мнили себя мировыми звездами, ездили на всякие европейские тусовки - себя показать, да и других почморить. Но вот наступила ненастная пора.

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

- Пора нам подумать о будущем, - сказал как-то Евлампий своим друзьям, сидючи после беcсонной ночи за банкой "Adrenalin Rush". - Неровен час загремим мы в места не столь отдаленные и будем валить лес мачтовый на благо своей Родины. Может пора завязывать?

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

- Успеется, - говорили они. - Слабы наши "кашники" поймать нас. И фсбшники слабы. Они пока десять бумажек напишут, да согласуют, мы уже давно все следы подотрем и будем и дальше радоваться жизни.
- Когда нужно будет, я выйду из дела и никто ничего не докажет, - говорил Ерема.
- И я, - вторил ему Емеля.
- Лучше поедем на Black Hat европейский и опять надерем задницу этим америкосам и бритым бритам. Пусть знают наших, - зазывали Евлампия его товарищи по ту сторону баррикад.
- Ну как хотите. Тогда я сам пойду и сдамся, чтобы потом не жалеть, - сказал Евлампий. Не буду ждать, когда вы одумаетесь. Как бы поздно не было.

С каждым днем ситуация накалялась все больше и больше. Но Емеля и Ерема не торопились. Им и думать не хотелось о прекращении своих темных делишек. Они хакерили от рассвета до заката и сот заката до рассвета.

Ближе к осени ситуация стала развиваться стремительно. Емеля был приглашен в США на августовкий Black Hat, где и был задержан сотрудниками американской Фемиды. И долго Емеля бил он себя пяткой в грудь доказывая, что он белый и пушистый. Но объяснили ему агенты USSS и ФБР, что срок давности по таким делам большой и ответить всем равно придется. И грозил Емеле тюремный срок. И даже красивая оранжевая роба американского заключенного не радовала привыкшего к хорошему хакера. И сел этот мегаизвестный в узких кругах хакер-безопасник на много-много лет, жалея, что поехал в эту Америку себя показать вместо спокойного отдыха на Баренцевом море. А через год согласился он сотрудничать; и сдал он всех своих знакомых и незнакомых. И умер он внезапно от передозировки.

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

А Евлампию не повезло еще раньше. В него ударила молния!

ЗЫ. Это старая заметка, которая с 2012-го года пылилась в черновиках блога. Решил "чего добру пропадать" и опубликовал, немного подредактировав.

Подробнее…

С гендиректором в лифте один на один

- Подождите, подождите, подержите лифт, пожалуйста...
- Спасибо. Ой, Степан Петрович.
- Привет, Сергей! Что-то рано ты сегодня?!..
- Да вот, запускаем с утра программу повышения осведомленности сотрудников. Хотел все проверить еще раз.
- Это хорошо. Тебе ведь пятый? А скажи-ка мне.
- Да, Степан Петрович...
- Мы защищены?
- ... (Вот ведь блин. Скажешь "да", сразу напомнит про историю с SOCом, который ничего не видит. Скажешь "нет", это скажется на мне и повлияет на бюджет управления. Что же делать, что делать? Ой, к моему этажу уже подходит..)

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

Я бы выделил пять типичных вопросов, которые вам могут быть заданы генеральным директоров, правлением или иными большими начальниками:

1. Мы защищены?
2. Как мы узнаем, что нас взломали?
3. Как мы соотносимся с конкурентами?
4. Мы тратим достаточно на обеспечение нашей безопасности?
5. Насколько эффективно мы инвестируем в безопасность?

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

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

Третий вопрос, при всей своей "дурацкости", очень важен именно для топ-менеджмента, так как они любят оценивать каждый вложенный рубль в сравнении с другими компаниями в том же сегмента рынка. В России не очень развит security benchmarking и поэтому ответить на этот вопрос будет непросто. Тем более, что сумма расходов на ИБ ничего не говорит о качестве вашей системы защиты. Но интерес руководства есть интерес и к нему надо быть готовым. Поэтому так важен так называемый networking, общение с коллегами по цеху на различных мероприятиях, особенно в неформальной обстановке. Если не получится узнать бюджеты коллег (а многие их завышают для придания себе значимости), то можно попробовать "меряться" уровнями зрелости. Но тут тоже есть засада - свою зрелость считают не все, а если считают, то завышают, не имея внешней, независимой оценки. Да и что считать точки отсчета для измерения зрелости? ISO 27001? ГОСТ 57580.1/2? NIST CSF? О том как измеряет себя служба ИБ Cisco я надеюсь написать на этой неделе.

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

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

А причем тут лифт? А это из области менеджмента. Есть такое упражнение, которое заключается в том, что вы должны себе представить, как будто вы попали со своим руководителем в лифт и у вас есть всего 1 минута, чтобы донести до него свои нужды и чаяния. Поэтому вам нужно уметь говорить быстро, четко и по делу. А для этого надо знать примерные вопросы, которые вам могут задать.

Подробнее…

ИБ и зона комфорта

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

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

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

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

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

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

Выводов не будет :-)

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

Подробнее…