пятница, 29 мая 2015 г.

СОИБ. Анализ. Определение угроз безопасности. Часть 3

Продолжаем разбирать «Методику определения угроз безопасности информации в информационных системах» (далее – новая методика).

Ряд экспертов, анализировавших новую методику, отметили, что ей не хватает логических схем. Я решил восполнить данный недостаток.

Общая схема процесса определения угроз безопасности информации




Схема моделирования нарушителя



Схема моделирования угроз



Большая схема с указанием зависимостей рассчитываемых показателей от исходных данных


Пока отрисовывал схемы всплыли следующие недостатки:
·        Во второй части документа используется термин “идентификация источников угроз”, а в третьей “оценка возможностей нарушителей по реализации угроз безопасности информации”. Это одно и тоже или разный анализ? Нужны пояснения или привести к единому виду
·        Во второй части документа используется термин “идентификация угроз”, а в третьей “определение угроз безопасности информации в информационной системе”. Это одно и тоже или разный анализ? Нужны пояснения или привести к единому виду
·        Из последней схемы выяснилось, что актуальные способы реализации угроз (которые мы определили в модели нарушителя) никак не участвуют в дальнейших расчетах актуальности угроз. Зачем тогда?



понедельник, 25 мая 2015 г.

Общее. SIEM в который надо верить

21 мая компания Positive Technologies провела пресс-конференцию для СМИ, блогеров и экспертов.
Позитивы собрали на выступление представителей из разных своих подразделений связанных SIEM (от продакт менеджеров, от пентестеров, от разработчиков, архитектора). Каждый рассказывал как они дошли до SIEMа, что вложили туда. 

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

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

PT рассказывали как взяли в систему всё самое лучшее от своих консалтинговых подразделений:
·         пентестеры обучали систему всевозможными сценариям атак (система обнаруживает пентестеров, а значит и хакеров обнаружит)
·         спецы по расследованию инцидентов, обучили тому как они вручную по этапам расследуют атаки, по цепочке начиная с точки вторжения в корпоративную сеть раскручивают всю последовательность действий нарушителей (автоматизировали деятельность следователя)
·         спецы ответственные за SOC на олимпиаде и универсиаде заложили свой опыт по приоретизации и выделению наиболее критических событий, заготовили сценарии по реагированию

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

Разработчики рассказывали что изначально они просто расширяли функционал MaxPatrol (по просьбам заказчиков, по своим потребностям), добавили пассивное обнаружение уязвимостей в трафике, добавили сбор логов, опять же для определения уязвимостей и нарушений настроек, и в какой-то момент поняли что у них уже получился SIEM, со 100% интеграцией со сканером безопасности и средством контроля политик. Заявляют, что они берут и используют всю информацию которую может дать MaxPatrol (обнаруженные активы, версии, уязвимости, конфигурации, корпоративные политики) а конкурентные SIEM используют не больше 40% (это они узнали из опыта интеграции с ArcSight и QRadar).

Вместо презентации самого продукта показали 2 видеоролика длиной 5-10 минут:
·         с интерфейсами MaxPatrol X (MaxPatrol SIEM), на видео погуляли по основным окошкам, показали несколько типовых задач
·         с тем как работают консалтинговые подразделения и по сути как они"обучают" SIEM

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

Давайте подведем итоги того что не удалось узнать:
·         увидеть продукт в живую. А он вообще существует?
·         какие источники данных и способы сбора поддерживаются на данный момент?
·         какой объем правил корреляции разработан и какие области он покрывает?
·         не показали простые дашборды
Техническую документацию PT готов предоставить только после первого дня PHDays, на котором будет показан в живую.

Итого – никаких достоверных данных после пресс-конференции у нас не появилось. Но ребята из Positive Technologies хорошие, в свое время сделали сканер maxpatrol на отлично и в консалтинге профи, поэтому надо им поверить и брать maxpatrol SIEM.







четверг, 21 мая 2015 г.

СОИБ. Анализ. Определение угроз безопасности. Часть 2

Продолжаем разбирать «Методику определения угроз безопасности информации в информационных системах» (далее – новая методика).

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



Сразу возник вопрос, как проводить расчет. В старой методике показатели для структурных характеристик были составлены так, что мы однозначно выбирали только один из пунктов для каждой из 7 характеристик. В новой методике по одному пункту характеристик для данной ГИС могут быть справедливы одновременно характеристики разных уровней защищенности. Например, суперкомпьютеры с виртуализацией или тонкие клиенты + ЦОД. Что делать в таком случае? Суммировать все плюсы / брать максимальный / брать минимальный? Методика требует уточнения.

2.       После определения показателя проектной защищенности ИС но до абзаца с определением уровня защищенности информационной системы при эксплуатации есть такой абзац
“В соответствии с требованиями о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, до ввода в эксплуатацию информационной системы должны быть реализованы меры защиты информации, направленные на блокирование (нейтрализацию) актуальных угроз безопасности информации. Таким образом, ввод в эксплуатацию информационной системы осуществляется при условии достижения высокого уровня исходной защищенности информационной системы от  нарушителя с заданным потенциалом.”
 Что это за уровень исходной защищенности информационной системы на этапе ввода в эксплуатацию? Далее никак не разъясняется как его посчитать, но есть требование чтобы он был высоким. Если речь про проектный уровень защищенности, то для ряда систем он никогда не будет высоким (такие уж введены формулы).

3.       Всплыла ещё одна проблема связанная с актуальностью угроз.
Давайте пойдем “от противного” и посмотрим, в каких случаях угроза может быть неактуальной?

В соответствии с таблицей 8, при высокой возможности реализации угрозы, угроза будет актуальна. Следовательно нас интересуют случаи со средней и низкой возможностью. -> Посмотрим на таблицу 4. Средний уровень  возможности реализации угрозы достижим уровне проектной защищенности не ниже среднего (и при этом при низком потенциале нарушителя). -> Средний уровень проектной защищенности получается если не менее 90% характеристик информационной системы соответствуют уровню не ниже «средний». Всего 10 характеристик. А значит должно быть не более 1 характеристики оцененной по низкому уровню защищенности.

Давайте посмотрим что за системы не попадают в средний уровень проектной защищенности:
·         Пункт 7 таблицы 3. “7. По режимам обработки информации в информационной системе”.   95 % из встреченных мной ГИС были многопользовательскими. Следовательно это дает нам одно гарантированный пункт низкого уровня защищенности
·         Кроме этого достаточно попадания хотя бы одной характеристики из перечня ниже чтобы заработать ещё один пункт низкого уровня защищенности:
o   подключена к сети Интернет,
o   взаимодействует с другими ИС,
o   применяется ЦОД,
o   применяется виртуализация,
o   распределенная система

Опять же, все ГИС, кроме небольших муниципальных ИС и подавляющее большинство ИСПДн попадают на как минимум 2 пункта низкого уровня защищенности и получают в итоге низкий уровень проектной защищенности что автоматически влечет расчет ВСЕХ угроз как актуальных.

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


среда, 20 мая 2015 г.

СОИБ. Анализ. Определение угроз безопасности. Часть 1

7 мая 2015 г. ФСТЭК России выложила на рассмотрение «Методику определения угроз безопасности информации в информационных системах» которую мы так долго ждали. До 10 июня 2015 года принимают предложения и замечания. Но скорее всего существенных изменений не будет. Поэтому можно брать в работу. Пока появилось свободное время буду разбирать и публиковать частями. По самым проблемным местам напишу в ФСТЭК.

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

1.       Первое что бросается в глаза – большая трудоемкость при применении методики определения угроз в лоб (для тех что берется за моделирование впервые).  Давайте посмотрим какие решения нужно принять для каждой угрозы:
·         определить достаточны ли возможности  нарушителя (актуального в соответствии с моделью нарушителя ) для реализации угрозы безопасности информации
·         определить могут ли иметься в информационной системе потенциальные уязвимости, которые могут быть использованы при  реализации данной угрозы безопасности информации;
·         не исключают ли структурно-функциональные характеристики и особенности функционирования информационной системы возможности применения способов, необходимых для реализации данной угрозы безопасности информации (существует реальный сценарий реализации угрозы безопасности);
·         определить что реализация угрозы безопасности информации приведет к нарушению конфиденциальности, целостности или доступности информации, в результате которого возможно возникновение неприемлемых негативных последствий (ущерба).
·         определить вероятность угрозы,
·         определить потенциала нарушителя, необходимый для реализации этой угрозы безопасности информации в информационной системе с заданными структурно-функциональными характеристиками и особенностями функционирования
·         определить возможный результат реализации угрозы безопасности информации в информационной системе
·         определить вид ущерба, к которому может привести реализация угрозы безопасности информации
·         определить степень негативных последствий от нарушения конфиденциальности, целостности или доступности каждого вида информации, содержащейся в информационной системе от реализации угрозы
-> степень последствий от реализации угрозы безопасности информации для каждого вида ущерба
Все эти решения необходимо принимать группой из не менее 3х экспертов для каждой из 161 угрозы. (Так как БДУ будет дополняться, то лучше ориентироваться на 200 угроз).

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

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

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