Прочитал очередной документ по управлению инсайдерской угрозой ИБ о CERT.
Insider Threat Security Reference Architecture (2012)
Документ является логичным продолжением исследований Common Sense Guide to Mitigating Insider Threats и Management and Education of the Risk of Insider Threat: System Dynamics Modeling of Computer System Sabotage, которые я также рассматривал на своем блоге.
Итак, Insider Threat Security Reference Architecture от CERT.
По документу ясно, что авторы решили упорядочить свои знания по противодействию инсайду в более четкую методологию, по образу и подобию методологий и стандартов управления ИТ и ИБ.
В работе выделены 4 основных уровня безопасности:
1. Уровень бизнеса
2. Уровень информации
3. Уровень данных
4. Уровень приложений
Подобное деление, правда с другими уровнями, можно встретить в CobiT 5 или даже в старой статье Алексея Лукацкого.
Вот как CERT определяет данные уровни:
Уровень бизнеса: высокоуровневые требования бизнеса, такие как миссия организация, политики и процедуры.
Уровень информации: сеть и компоненты сети, железо и софт (другими словами, ИТ-инфраструктура).
Уровень данных: информационные активы организации.
Уровень приложений: приложения, поддерживающие бизнес, наподобие ERP или CRM.
Причем авторы документа утверждают, что невозможно полноценно защититься от той или иной угрозы ИБ, не внедрив меры защиты на всех четырех уровнях.
С данным постулатом я согласен, но уровни я бы расположил в другой последовательности (с учетом того, как эти уровни понимает CERT):
1. Уровень бизнеса
2. Уровень данных
3. Уровень приложений
4. Уровень информации (онной инфраструктуры).
Вообще, в этом отношении мне импонирует модель ИТ-инфраструктуры из СТО БР ИББС. Ее можно красиво объединить с моделью из CobiT и получить более точную и взвешенную архитектуру. Авторы явно взяли модель из NIST и зачем-то поменяли уровни местами. Но не об этом речь.
Для каждого уровня авторы приводят примеры рекомендуемых к применению стандартов и методологий ИБ.
Для уровня бизнеса: SABSA, NIST 800-37, Six Sigma (Как сюда ложится Six Sigma я не понимаю).
Для уровня информации: Open Security Architecture, Cisco Safe, NIST 800-53.
Для уровня данных: CDSA, Oracle Database Security.
Для уровня приложений: разумеется OWASP, CERT Security Coding Standards, Microsoft Appication Security.
С точки зрения управления инсайдерской угрозой авторы выделяют три основные типа деятельности:
1. Предотвращение (возможных в будущем инцидентов)
2. Обнаружение (инсайдерской деятельности)
3. Противодействие (обнаруженной инсайдерской деятельности)
Индикаторы инсайдерской деятельности бывают техническими и социальными. Ключевой момент в грамотном управлении инсайдерской угрозе - корреляция как раз технических и социальных данных.
CERT в своей работе выделяют также три фундаментальных принципа защищенности организации от инсайдерской угрозы:
1. Принцип авторизованного доступа.
2. Принцип допустимого использования.
3. Принцип непрерывного мониторинга.
На базе данных принципов и деления безопасности на 4 уровня, авторы разработали таблицу ключевых мер защиты, которые необходимо внедрить для минимизации рисков инсайдерской угрозы ИБ (они назвали ее ITSRA Matrix):
Табличка мне нравится, данный подход к структуризации мер защиты видится мне весьма гармоничным, даже более гармоничным, чем подход, приведенный в стандарте ISO 27001. Но с тем, что приведенные в табличке меры защиты полностью охватывают все аспекты борьбы с инсайдом, можно поспорить. Поэтому авторы статьи скромно заявляют, что данная матрица приведена для примера.
Статья заканчивается демонстрацией того, как правильно защититься от конкретной угрозы ИБ с использованием предложенной архитектуры.
Документ, несмотря на некоторые недостатки, мне понравился. Он очень логично дополняет предыдущие исследования CERT и является шагом к построению полноценной методологии борьбы с инсайдерской угрозой ИБ.
Еще на тему защиты от инсайдеров читайте:
Лучшие практики защиты от инсайдеров от CERT
Управление риском ИТ-саботажа от CERT
Шпионаж и ИТ-саботаж: сходства и различия
В сентябре 2013 года вышла новая версия самого известного стандарта по управлению информационной безопасностью - ISO/IEC 27001 Information technology - Security techniques - Information security management systems - Requirements
Наконец-то нашел время ознакомиться с новой версией документа и написать короткий обзор!
Документ состоит из повествовательной части, в которой описываются требования к построению системы управления информационной безопасностью, и приложения А, в котором содержатся основные цели информационной безопасности и меры, которые необходимо применять, чтобы этих целей достигнуть.
Более подробно цели и меры ИБ описаны в стандарте ISO 27002, который также обновился в сентябре 2013 года.
В качестве основы для СУИБ ISO 27001 предлагает использовать процесс управления рисками ИБ. Причем в версии 2013 года процесс управления рисками ИБ приведен в соответствии с серией стандартов по управлению рисками ISO 31000.
В новой версии стандарта построение СУИБ начинается с определения того, как ИБ может повлиять на достижения бизнес-целей организации, понимания потребностей заинтересованных сторон и внешних обязательств.
Появление подобной главы не может не радовать, но необходимо отметить, что в других стандартах и методологиях процесс целеполагания рассмотрен гораздо более подробно и гармонично (взять, к примеру, CobiT 5 или O-ISM3)
В качестве основной движущей силы СУИБ стандарт позиционирует лидерство (то, что ранее называлось приверженность руководства). Необходимость инициативы и приверженности высшего руководства организации обозначена более четко в новой версии стандарта. Причем высшее руководство должно разработать политику информационной безопасности и организационную структуру для СУИБ.
В главе, посвященной планированию, описан процесс управления рисками ИБ, состоящий из следующий стадий:
1. Оценка рисков ИБ:
1.1 Установление критериев принятия рисков и критериев для проведения оценки рисков ИБ.
1.2 Определение рисков и владельцев рисков.
1.3 Анализ рисков:
1.3.1 Определение последствий возникновения рисков
1.3.2 Определение вероятности возникновения рисков
1.3.3 Определение уровня рисков
1.4 Непосредственно оценить риски: сравнить с критериями и произвести приоритезацию
2. Обработка рисков ИБ:
2.1 Выбрать вариант по обработке риска.
2.2 Определить меры, которые необходимо использовать для реализации варианта обработки
2.3 Сравнить с каталогом целей и мер в Приложении А.
2.4 Разработать положение о применимости мер ИБ с обоснованием.
3.5 Разработать план по обработки рисков.
3.6 Согласовать с владельцами рисков план и получить согласие на принятие остаточных рисков.
Согласно стандарту, на стадии планирования организации также необходимо определить цели ИБ и меры для их достижения.
Основными факторами, необходимыми для поддержки СУИБ, согласно ISO 27001:2013, являются:
1. Ресурсы
2. Компетенция
3. Осведомленность
4. Коммуникации
5. Документирование
Причем документирование рассмотрено в стандарте более подробно.
Процесс оценки и обработки рисков должен производится регулярно в течение эксплуатации СУИБ, наряду с оперативным планированием и контролем.
В качестве основных способов для оценки результативности СУИБ являются:
1. Мониторинг, измерение, анализ и оценка.
2. Внутренний аудит.
3. Анализ со стороны руководства, базирующийся в том числе на результатах мониторинга и внутреннего аудита.
В конце повествовательной части даны требования по улучшению СУИБ при выявлении несоответствий, в том числе постулирована необходимость постоянного улучшения.
Каталог целей ИБ и мер по их достижению состоит из следующих доменов:
А.5 Политики ИБ
А.6 Организация ИБ
А.7 Безопасность, связанная с персоналом
А.8 Управление активами
А.9 Управление доступом
А.10 Криптография
А.11 Физическая безопасность и защита от окружающей среды
А.12 Безопасность при обработке информации
А.13 Безопасность связи
А.14 Приобретение, разработка и поддержка систем
А.15 Взаимоотношения с поставщиками
А.16 Управление инцидентами ИБ
А.17 ИБ при управлении непрерывностью бизнеса
А.18 Соответствие требованиям
Мне особенно понравились домены А.7 и А.15. Но, безусловно, необходимо отметить, что они более подробно рассмотрены в том же CobiT или лучших практиках CERT
На мой взгляд, про управление инцидентами ИБ необходимо было упомянуть и в основной части стандарта, т.к. этот процесс наряду с управлением рисками ИБ является основным в СУИБ.
Новая версия стандарта мне понравилась, видно развитие, хотя не такое сильное как в других методологиях, стандартах и лучших практиках.
Недавно ознакомился с документом CERT
Management and Education of the Risk of Insider Threat: System Dynamics Modeling of Computer System Sabotage,
разработанном в рамках CERT Insider Threat Study (см. Лучшие практики защиты от инсайдеров от CERT)
В рамках данной работы CERT проанализировали случаи ИТ-саботажа из своей базы инцидентов, выделили типичные зависимости и разработали "эталонный" пример ИТ-саботажа.
Данный эталонный пример был смоделирован с помощью системной динамики Форрестера.
Полученную модель предлагается использовать для обучения сотрудников организации обнаружению. и противодействию ИТ-саботажу, а также для анализа конкретной ситуации ИТ-саботажа.
В работе рассмотрены основные технические и психологические аспекты ИТ-саботажа.
Немного статистики.
Был проведен анализ 49 случаев ИТ-саботажа. Из них в 81 процентах случаев организация понесла финансовые потери, в 75 процентах пострадали бизнес-операции, в 21 процентах случаев пострадала репутация организации.
Как правило, причиной инцидента являлось недовольство сотрудника (57%), причем из них 84% были исполнены чувством мести, а 92% инсайдеров атаковали после негативного события на работе (увольнение, ссора, понижение, перевод по службе).
80% инсайдеров вели себя подозрительно перед атакой. 86% занимали должность технического характера. 90% из них - привилегированные пользователи системы.
59% инсайдеров атаковали после увольнения.
Для анализа крайне важны именно моменты, связанные с понижением и увольнением. ИТ-саботаж не характерен для периода времени после найма сотрудника.
Необходимо представлять себе пути доступа (access paths) инсайдера к критическим ресурсам.
Существует 2 типовых шаблона ИТ-саботажа:
1. Инсайдер предполагает, что имеет определенные возможности в системе, но организация дает ему выговор и урезают полномочия.
2. Инсайдер предполагает какое-либо продвижение по службе, но его не происходит.
Причем моделируется только первый шаблон.
Основным индикатором атаки является недовольство сотрудника.
В зависимости от доступных ему путей доступа и уровня аудита в организации у инсайдера различные возможности по проведению атаки.
Санкции зачастую лишь увеличивают недовольство сотрудника и делают лишь хуже.
Альтернатива - вмешательство в ситуацию и попытка помочь.
Существуют технические и социальные индикаторы надвигающегося ИТ-саботажа.
Социальные, как правило, проявляются раньше.
Существуют инсайдеры, которые стремятся замести следы саботажа, а существуют такие, которые об этом не заботятся.
Модель красива, показательна, но, на мой взгляд, не практична.
Многие элементы модели сложно вычислить. Например, склонность инсайдера к раздражению или предрасположенность к ИТ-саботажу.
Поэтому модель хороша для анализа конкретной ситуации и обучения.
Вероятно, в рамках конкретной организации с хорошей статистикой, возможно рассчитать все коэффициенты, предлагаемые CERT.
Но сами CERT явно каким-то образом получили коэффициенты и даже рисуют красивые полученные графики.
Но как модель откалибровать, как выставить верные коэффициенты и какие использовать метрики - они умалчивают.
Полученную модель можно использовать как четкую систематизацию знаний об ИТ-саботаже или как основу для процессов управления инцидентами и рисками, но до этого ее необходимо существенно проработать и адаптировать.
Еще на тему защиты от инсайдеров читайте:
Лучшие практики защиты от инсайдеров от CERT
Архитектура борьбы с инсайдом от CERT
Шпионаж и ИТ-саботаж: сходства и различия
