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

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

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

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

Начнем с процессов

Широко используемой методологией оценки зрелости процесса является методология, базирующаяся на модели Capability Maturity Model Integration (CMMI). Для наглядности сведем значение, уровни и описание в таблицу.

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

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

• cоздать документацию с четким описанием самого процесса;
• cформировать технические требования для систем, которые необходимы для реализации процесса;
• сформировать команду участников процесса и описать их зоны ответственности (идеальным инструментом тут является RACI-матрица);
• запустить процесс согласно описанию и всем требованиям к ресурсам.

Допустим, у нас имеется описание процесса, его постоянное выполнение и все необходимые для него средства и ресурсы.

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

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

А что же с "требованиями"?

Для начала надо определиться, какие требования нам необходимо обязательно выполнять, в первую очередь это относится к законодательству и сфере деятельности компании. Например, вы медицинское учреждение, наверное, тут будет особо важным соблюдение ФЗ-152 о персональных данных. Вы работаете с платежными картами? Будьте добры соответствовать PCI DSS.

Во вторую очередь, нужно определиться, каким сторонним стандартам мы хотим соответствовать (например, в перспективе рассчитываете сертифицироваться по ISO).

В третью очередь, определить специфику используемых в компании средств и определить перечень рекомендаций для них. У той же всем известной компании Microsoft есть множество рекомендаций по всем их продуктам и инфраструктуре в целом. К сожалению, зачастую далеко не все они выполняются. Ярким примером тут может служить обеспечение безопасности привилегированного доступа¹. Каждый уважающий себя вендор имеет рекомендации по обеспечению высокого уровня ИБ, и по ним можно сформировать целевые требования. Требования могут появиться и просто со стороны экспертизы и опыта конкретных людей. Важно найти грань детализации этих требований.

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

Динамика

Вернемся ко второй составляющей аспекта оценки показателей уровня защищенности. Как же нам получать динамический срез того, что происходит в инфраструктуре, и как нам видеть динамические риски? Тут нам помогут технические средства, их события и системы отчетности. В частности, такими метриками могут быть отчеты периметрового межсетевого экрана/IPS/ NGFW/Proxy (с детализацией атак, статистикой посещений определенных категории сайтов, скачиваний, да и в целом использования сети Интернет), антивирусные средства с их отчетностью, срабатывания DLP-систем, периодические отчеты сканера уязвимостей, события с контроллера домена, события с конечных хостов в целом – примеров можно привести много.

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

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

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

Подведем итог

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