Методические рекомендации по созданию центров ГосСОПКИ (часть 3)

Продолжим рассмотрение функций центров ГосСОПКИ согласно методических рекомендаций НКЦКИ. На очереди у нас этап анализа данных о событиях безопасности, целью которого является регистрация инцидентов. Но тут у меня возник еще один вопрос. Ведь есть еще одна функция - прием сообщений о возможных инцидентах от персонала и пользователей информационных ресурсов. И в рамках нее тоже говорится о приеме сообщений об инцидентах. Некоторая путаница возникает. На самом деле на данном этапе речь идет о SIEM, которые в автоматизированном режиме должны собирать события безопасности. Правда, написано все общими словами. Про обогащение событий с помощью Threat Intelligence, про приоритезацию и классификацию событий и другие важные аспекты работы SIEM документ не упоминает.

Следующая функция называется "Регистрация инцидентов" и у меня вновь появляется вопрос. А предыдущие две функции "анализ событий безопасности" и "прием сообщений об инцидентах" для чего? Ну да ладно. Не так уж это и важно. Функция опирается на необходимость вести карточки инцидентов, которые рассылаются по центрам ГосСОПКИ. Это предполагает унифицированный формат ведения карточек и обмена ими. Какой? STIX, TAXII, CyBOX?.. Вопросы стандартизации, к сожалению, в документе не учтены совсем и похоже авторы просто пока не знают, что брать за основу. Та же проблема и у FinCERT, который рассылает свои бюллетени в PDF/Word и которые нельзя в автоматическом режиме подцепить к SIEM/IDS/МСЭ и другим средствам защиты. На мой взгляд тут очень важно уже сейчас определяться со стандартами обмена информацией, чтобы не получилась ситуация, когда ведомственные и корпоративные центры ГосСОПКИ созданы и начинают функционировать, а обмениваться данными между собой не могут, так как используют разные форматы карточек инцидентов и разные протоколы для их обмена. Из стандартов методичка упоминает только стандарт TLP для "раскраски" информации об инцидентах, означающую круг лиц, которым эту информацию можно рассылать.

Документ ни слова не говорит о том, сколько хранятся карточки инцидентов? 3 года, как и уязвимости? А вот трафик, в котором была обнаружена атака, а также все события средств защиты и средств ГосСОПКА, включая и прикладные логи, должны храниться не менее 6 месяцев. Я надеюсь трафик DDoS хранить не придется, а то накладно будет.

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

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

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

В 7-м разделе методички приводится иерархия специалистов центров ГосСОПКИ. Выделяется 3 линии специалистов, реализующих 11 функций, описанных в трех заметках. Это достаточно распространенная схема, принятая в многих SOCах и службах реагирования на инциденты. Например, в Cisco это выглядит так (кстати, на 66 страниц методички нет ни одной картинки - не любят у нас регуляторы визуализацию, ох, не любят):

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

• Резервирование способов взаимодействия персонала и что они могут стать мишенью сами по себе.
• Регистрация и учет не только информации, получаемой центром ГосСОПКИ через Интернет, но и по телефону. В тех же рекомендациях NIPC или CERT/CC как раз приоритет отдается телефонной связи, как основному каналу взаимодействия при инциденте (так как Интернет-канал может быть под контролем).
• Лаборатория (стенд) по расследованию скомпрометированных/зараженных узлов.
• Взаимодействие с правоохранительными органами (инциденты же могут затрагивать интересы не только ФСБ, но и МВД).
• Доказательная сила собираемых доказательств. Понятно, что для ГосСОПКИ может быть достаточно того, что было собрано в рамках рекомендаций. Но что делать, если пострадавшая сторона захочет обратиться в правоохранительные органы? Допускаю, что именно под расследование будет отдельная методичка; просто включил этот пункт, чтобы не забыть.
• Эскалация инцидентов.
• Особенности сбора доказательств в случае зарубежного инцидента (в рамках ближнего зарубежья, например, в рамках ОДКБ или СНГ, где есть определенное налаженное взаимодействие, или в рамках дальнего зарубежья). Особенно актуальна эта тема для российских компаний и организаций, имеющих зарубежные представительства или дочерние компании.
• Более четкая систематизация действий в рамках инцидента. Не просто 11 функций, а пошаговая процедура (по сути некий аналог workflow). Например, в очень старой методичке SANS по реагированию на инциденты (еще 90-х годов) было прописано 6 процессов, 31 детальная процедура и 97 конкретных действий, которые необходимо было реализовать для управления инцидентами, на что и заточены центры ГосСОПКИ.
• ...

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

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

Подробнее…

Методические рекомендации по созданию центров ГосСОПКИ (часть 2)

Продолжу вчерашнюю заметку про ГосСОПКУ. При ее создании реализуются 11 подробно описанных в методичке функций:

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

Этап инвентаризации, проводимой раз в квартал или при каждом изменении, позволяет собрать исходные данные о сегменте, контролируемом соответствующим центром ГосСОПКИ:

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

Этап выявления уязвимостей подразумевает работу по ГОСТ 56546-2015 и предлагает на выбор следующие варианты получения информации о слабых местах контролируемого ГосСОПКОЙ сегмента:

• сетевое сканирование
• системное сканирование
• пентесты
• тестирование устойчивости к DDoS
• аудит
• анализ кода (SAST/DAST).

Варианты типа использования баз данных уязвимостей (Vulners, БДУ, Cisco ISIS, NVD) не попали в список. Ситуация с пассивным анализом сетевого трафика для поиска уязвимостей осталась до конца не выясненной. В принципе, я не думаю, что есть запрет на использование каких-то иных методов поиска уязвимостей, чем те, что указаны в методичке. Для каждого из способов сканирования указана своя периодичность (что очень позитивно). При этом владельцам центров ГосСОПКИ придется готовиться к длительному хранению результатов сканирования - 3 года. При ежемесячном сканировании получается 36 “слепков” по всей инфраструктуре, попадающей под мониторинг. Крутовато будет с точки зрения объемов хранилища. И если я правильно понял, то использовать надо все методы сканирования, а не какой-то один из них. Так что серверных стоек понадобится много.

На основе проведенной инвентаризации и выявленных уязвимостей проводится анализ угроз (или векторов атак). Наверное, это один из самых важных элементов всей ГосСОПКИ, так как именно от него зависит эффективность всей конструкции. Но пока ее не запустили в полном объеме, то и всех необходимых документов пока еще нет (или они в процессе, или секретны). А документом понадобится много:

• описания компьютерных атак, актуальных для информационных ресурсов, находящихся в зоне ответственности сегмента ГосСОПКА;
• методические рекомендации по предупреждению, обнаружению и ликвидации последствий компьютерных атак;
• решающие правила средств обнаружения компьютерных атак;
• настройки средств обеспечения информационной безопасности;
• политики обеспечения информационной безопасности;
• нормативные правовые акты организации;
• дополнительные требования по обеспечению информационной безопасности для их включения в технические задания на создание новых, доработку и обслуживание существующих информационных ресурсов;
• правила корреляции событий, направленные на определение попыток реализации угроз, связанных с проведением компьютерных атак;
• инструкции для персонала информационных ресурсов по выявлению признаков проведения типовых компьютерных атак, порядку их обнаружения, действиям по ликвидации их последствий;
• инструкции по действиям пользователей информационных ресурсов в случае возникновения инцидентов, связанных с компьютерными атаками;
• требования к квалификации персонала и пользователей, необходимой для выполнения указанных выше инструкций.

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

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

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

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

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

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

Подробнее…

Методические рекомендации по созданию центров ГосСОПКИ (часть 1)

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

Документ расчитан на госорганы, решившие создавать у себя ведомственные центры ГосСОПКИ, и на тех, кто решил создавать у себя корпоративные центры ГосСОПКА. В последнем случае речь идет о госкорпорациях, операторах связи и лицензиатах в области защиты информации, которые захотят помогать госорганам, госкорпорациям и операторам связи в этом непростом деле. И, как мы все понимаем, первые кандидаты на роль таких лицензиатов у нас есть. Это Solar Security, Positive Technologies, Перспективный мониторинг, Информзащита, то есть все те компании, которые активизировались в последнее время в относительно новой для России области - Security Operations Center (SOC). А ведь английская аббревиатура SOC и отечественная ГосСОПКА - это почти близнецы-братья (или сестры).  Интересно, куда относится ЦБ? А Газпром? А Роснефть? Они не являются госорганами и госкорпорациями и что, они не смогут создать в рамках своих холдингов корпоративный центр? Скорее всего это просто недогляд со стороны авторов документа - тот же FinCERT при ЦБ все называют именно ведомственным центром ГосСОПКИ.

Я не буду подробно расписывать все 66 страниц документа; коснусь только того, на что, после трех бокалов красного вина, я обратил внимание в самолете, летящем по маршруту “Москва - Астана”. Сразу скажу, что описанный документ не отвечает на все вопросы, которые могут возникнуть при создании собственного SOCа. Это скорее концепция, которая затем будет расширяться и дополняться. В методичке очень много отсылок на будущие документы, регламенты, интерфейсы взаимодействия, которые только будут разрабатываться по мере развития ГосСОПКИ. Еще одной особенностью этой методички является канцеляризм. Местами приходится продираться через вновь введенные и не сразу понятные термины. Только после вдумчивого многократного прочтения (и три бокала красного не облегчают задачу) понимаешь, что вот тут речь шла о UEBA (user entity behavior analytics), а вот тут о NBAD (network-based anomaly detection), а вот тут о SIEM.

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

Например, методические рекомендации говорят, что по ходу развития ГосСОПКИ будут определены use case (в документе их называют “типовыми инцидентами”), для которых будут даны соответствующие рекомендации по реагированию на них. Также будут определены типовые атаки, для которых будут определены документы, в которых будут прописаны IoC и порядок действий персонала при ликвидации последствий атак (предположу, что речь идет о более привычном термине “Playbook”, но это вкусовщина). При этом в 8-м разделе методички четко указаны 4 группы инцидентов и их наполнение (перечень почему-то закрытый и не расширяемый). С этим перечнем у меня возникли вопросы. Почему обычный вирус уравнен с APT? И почему центр управления бот-сетью отнесен к инциденту, а не к атаке? Или тот же спам? Или перебор паролей? Если следовать терминам, то это все-таки не инциденты, а именно атаки. Я бы этот раздел переработал, взяв за основу, какую-либо из существующих таксономий атак.

Кстати, не знаю, случайно ли, но несколько дней назад сайт МинОбороны Казахстана был взломан. И вот такая(ой) атака (инцидент), имеющая явно репутационный ущерб (если не было проникновения внутрь), в перечень инцидентов из методички НКЦКИ не входит. Не считается серьезной проблемой? Или забыли, так как российские сайты давно уже не дефейсили?

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

Выделяется 7 защитных мер, реализуемых ГосСОПКОЙ:

1. анализ угроз безопасности информации и рисков их реализации;
2. контроль (анализ) защищенности информации;
3. управление конфигурацией средств защиты;
4. регистрация и анализ событий безопасности;
5. выявление инцидентов и реагирование на них;
6. обеспечение действий в нештатных ситуациях;
7. информирование и обучение персонала,

которые по ходу раскрываются в 11 функций ГосСОПКИ (им и посвящено чуть ли не половина всего документа) и уже описываются гораздо подробнее. И вот о них мы поговорим уже завтра, когда в Астане начнет работу SOC Forum, а жители России будут скучать, ожидая майских праздников.

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

Подробнее…

Государственно-частное партнерство на примере последнего документа ФСТЭК по SOC

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

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

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

Общие замечания относительно этого перечня были следующими:

• требование наличия некоторых средств защиты являются избыточными
• требование наличия некоторых инструментов для SOC являются избыточными
• требования по сертификации некоторых инструментов SOC являются избыточными
• требования по аттестации на ГИС1 являются избыточными.

В итоге:

• Средства контроля целостности были убраны из требований к лицензированию SOC.
• Средства, предназначенные для пентестов, WAF, МСЭ, антивирус, IDS были удалены совсем, так как изначально было непонятно, для чего они нужны. Для защиты SOC или для мониторинга с помощью SOC?
• Средства автоматизированного реагирования на инциденты объединили с другими инструментами.
• Поменяли местами формулировки. Например, раньше мониторили средства и системы информатизации, а сейчас информационные системы; добавили термин "песочница", "системы" заменили на "средства" и т.д.
• Сертификаты должны быть только у сканеров безопасности, SIEM и средств защиты каналов связи. Остальные решения могут обойтись формулярами, составляемыми разработчиками или лицензиатами ФСТЭК. Это было сделано для тех случаев, когда используются различные open source или freeware решения. Требования к составу и содержанию формуляра описаны в ГОСТ 19.501-78.
• Убрали требование по нахождению SOC по адресу осуществления данного вида деятельности (виртуальные SOC вновь могут жить).

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

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

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

Схожая деятельность ведется и другими регуляторами (исключая, пожалуй, РКН, который идею консультативного совета превратил в фикцию), но, может быть, не так активно. Тот же Банк России активно собирает мнения от участников отрасли в рамках ТК122. ФСБ пытается работать с частным бизнесом через ТК26, но туда попасть могут не все и взаимодействие, как мне кажется, не является равноправным. Как собственно и другие направления сотрудничества ФСБ.

ЗЫ. Были и другие поправки в перечне контрольно-измерительного оборудования, которые не имели отношения к SOC:

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

Подробнее…

PlayStation 4 могли использовать для общения террористов, экстремистов и шпионов

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

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

Например, больше года назад (или уже два?) заказанная мной из Amazon электронная книжка Kindle была отправлена назад, так как на нее еще не было нотификации. Хорошо, что служба доставки тогда меня предупредила об этом и получив ответ, что заниматься оформлением нотификации я не буду, отправила Kindle обратно, а мне пришлось покупать ее срочно в Москве (дороже, как водится). А могли бы и оштрафовать... Когда я вез с SANSовского тренинга промышленный ИБ-симулятор Cybati с встроенным Arduino (а у него есть встроенная криптография), я тоже не особо задумыался о том, что у меня могут его изъять на границе (на него не то, что не было нотификаций, но, боюсь, и не будет никогда). А всяческая электроника с AliExpress, которая массово закупается у китайских умельцев? На нее подчас тоже нет никакой разрешительной документации.

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

ЗЫ. Вообще PlayStation 4 имеет нотификацию, но заказанная модель нет.

ЗЗЫ. Перечитал заметку и удивился. Как это мне удалось написать про эту тему и ни разу не упомянуть ФСБ :-) Да-да, куратором изменений в данное законодательство у нас является ФСБ и я не предвижу в текущих условиях изменений ситуации в лучшую сторону.

Подробнее…

Борьба с фишингом. Пошаговая инструкция

Выкладываю презентацию с мастер-класса по борьбе с фишингом, которую читал на CISO Forum 2017 в Москве. Это чуть более подробная версия, чем та, что читалась (часть слайдов в рамках выступления я скрыл, чтобы хватило времени за час все рассказать). Но есть и более полная версия, раскрывающая в деталях вопросы использования отдельных инструментов злоумышленников (тот же Social Engineering Toolkit, Evilginx, Punycode и др.) и защитных мер (фишинговые симуляторы, обучение сотрудников и т.п.). Полный вариант у меня занимает около 4-х часов.

Борьба с фишингом. Пошаговая инструкция from Aleksey Lukatskiy

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

Анатомия атаки:


Подбор фальшивых доменов с помощью URLcrazy:



Сбор контактных данных с помощью TheHarvester:



Сбор контактных данных с помощью Recon NG:



Поиск фальшивых и вредоносных доменов с именем sberbank в названии доменов:



Клонирование сайта с помощью Clone Zone:



Клонирование сайта с помощью SET:



Организация Spear Phishing с помощью SET:

Подробнее…

Accenture покупает iDefense

Компания Accenture объявила 3 апреля о завершении сделки по приобретению у VeriSign подразделения iDefense Security Intelligence Service, которая была анонсирована в феврале.

Подробнее…

Тенденции в области кибербезопасности Industrial IoT (презентация)

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

Кибербезопасность Industrial IoT: мировые тенденции и российскиие реалии from Aleksey Lukatskiy

Подробнее…

АБС и финансовые приложения должны быть сертифицированными. Так сказал ЦБ

Ну и чтобы уж завершить начатую вчера тему с требованиями ЦБ по обязательной сертификации, покажу еще один фрагмент из проекта ГОСТа, который я упомянул во вчерашней заметке:

Тут все предельно понятно - АБС, мобильный банковское ПО, приложения для ведения брокерской деятельности, ПО страховщиков (в том числе на сайте - для выписки ОСАГО) и др. должно быть сертифицировано на отсутствие уязвимостей по ОУД4 по ГОСТ Р ИСО/МЭК 15408-3. Это то, что прописано в дорожной карте Банка России на 2016-2018 годы.

Позиция ЦБ понятна - разработчики АБС не спешат повышать качество своего ПО с точки зрения безопасности, чем и пользуются злоумышленники. Поэтому ЦБ, уже по традиции, устанавливает требования для своих подопечных, которые должны будут заставить разработчиков прикладного ПО выполнить требования ГОСТа. Такой же фокус был проделан и в 552-П, который обязал перенести функцию электронной подписи из АРМ КБР в АБС.

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

Требования ОУД4

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

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

Подробнее…

ЦБ вводит обязательную сертификацию средств защиты информации

Хочу вернуться к недавно мной описанному проекту ГОСТа ЦБ с набором базовых защитных мер для финансовых организаций. На днях на сайте ТК122 появился практически финальный проект этого документа, который 13-го апреля будет обсуждаться в ЦБ и, возможно, будет вынесено на голосование его принятие.

По сравнению с предыдущей в новую версию проект проникло очень интересное дополнение, которое обязывает финансовые организации применять только сертифицированные в ФСТЭК средства защиты информации. И речь идет не о пресловутых СКЗИ, уровень сертификации которых установлен классом КС2 (знакомая по СТО БР конструкция), а именно о всех остальных средствах защиты - МСЭ, IPS, антивирусы, DLP, сканеры безопасности, средства контроля доступа, системы идентификации и аутентификации, а также множество других защитных средств, описанных в ГОСТе. Выглядит этот фрагмент таким вот образом:

Надо признать, что на прошлом заседании ПК1 ТК122 эта тема также озвучивалась, так как в первом проекте также было указано про сертифицированные средства защиты, но не про все, а только про СВТ, МСЭ, IDS и антивирусы (то, на что у ФСТЭК были соответствующие РД).

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

На мой взгляд, сюрприз неприятный, так как заставит все финансовые организации, включая малые банки, микрофинансовые организации, страховые, ломбарды, брокеров, негосударственные пенсионные фонды, операторы платежных систем и другие, выбросить то, что ими применялось до сих пор (а в массе своей оно было несертифицированным, исключая СКЗИ и некоторые крупные кредитные организации) и искать продукты, которые будут не просто сертифицированы как МСЭ или IDS или еще что-то, а искать продукты, проверенные на отсутствие НДВ (у МСЭ - это требование с 5-го класса, у IDS - пока с 4-го). Много ли у нас таких продуктов на рынке? И если с МСЭ или IDS еще можно поискать, то вот что делать с другими типами средств защиты, упомянутыми в проекте ГОСТа, но которые даже на ТУ не сертифицировались, не говоря уже про отсутствие НДВ.

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

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

ЗЫ. И самое интересное, что в дорожной карте Банка России с переченем мер по повышению уровня защищенности финансовой системы Российской Федерации эта норма (по сертификации средств защиты) отсутствует :-(

Подробнее…

Моя презентация с BIS Summit SPb 2017 (по критической инфраструктуре)

Моя презентация с BIS Summit SPb 2017 с обзором положений законопроекта по безопасности критической инфраструктуры и сопутствующих документов ФСТЭК, ФСБ, Минкомсвязи, Минэнерго, а также планов по ним. Было всего 20 минут на выступление, так что пробежался по верхам, хотя в более полной версии каждый упомянутый документ расписан более подробно.

Что нам ждать от законодательства по безопасности критической инфраструктуры from Aleksey Lukatskiy

Подробнее…