Введение

Привет! Меня зовут Данила, и я занимаюсь менеджментом, рисками и всем тем, что называют бумажной безопасностью.

Любой крупный бизнес рано или поздно задумывается о написании стратегии своего развития. Если вы CISO такой компании, то написание стратегии однажды затронет и вас.

Создание стратегии — творческий процесс, не имеющий верного или неверного результата, а поэтому может загнать в ступор любого специалиста. Я же хочу предложить идею, как можно подойти к выполнению этой задачи.

Для начала стоит объяснить, что такое стратегия информационной безопасности в частном бизнесе.

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

Стратегия ИБ — аналитический бизнес‑план, который должен хорошо описать, с чем мы имеем дело сейчас, с чем будем иметь дело в будущем, что мы хотим делать, почему мы хотим это делать, какие инвестиции нам нужны, и в идеале, должны быть просчитаны показатели ROSI (Return on Security Investment) для каждого домена стратегии. Этот документ, как правило готовится для мажоритария, а значит и требования к нему соответствующие.

Стратегия ИБ, что же писать

Первоначально стратегия — описание того, как нам из точки А (настоящее) прийти в точку Б (будущее). Для этого сначала эти точки нужно описать. Разделы с 1 по 6 описывают настоящее, а разделы с 7 по 9 — будущее. А вот раздел 10 — это наша стратегия.

Также очень важным моментом является связанность: все прописанные разделы должны дополнять друг друга.

Раздел 1. Ожидания заинтересованных сторон.

Фиксация желаний и договоренностей — всегда полезная практика. Она позволяет нам делать процесс более прозрачным и скоординированным. Вполне возможно, что планы CEO вашей компании и CISO материнской компании расходятся, и далеко не факт, что они знают про идеи друг друга. Поэтому, чтобы эта ситуация однажды не «разорвала» вас, лучше сделать эти планы прозрачными уже сейчас.

В разделе мы отражаем как непосредственно сами заинтересованные стороны (далее ЗС), так и их ожидания.

ЗС могут быть:

1. Мажоритарии (основные владельцы компании);

2. Представители материнской компании (например, функция ИБ материнской компании);

3. CEO (генеральный директор);

4. Директора иных направлений компании (в основном это ИТ);

5. и т. д.

А чтобы узнать про ожидания, нужно просто проинтервьюировать ЗС. Также, возможно, их идеи уже сформулированы (протоколы стратегических сессий, встреч, переговоров; что‑то зафиксировано в почте или корпоративном мессенджере) что будет плюсом к интервью. Осталось собрать эту информацию и прописать в разделе стратегии. Может быть и так, что ИБ в вашей компании нужно только для увеличения продаж SaaS‑решения крупным клиентам, для которых ИБ может стать стоп‑фактором покупки (да, такое тоже есть, и это нормально), и важно чтобы все стороны были согласны с этой позицией.

Раздел 2. Описание компании

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

Есть 2 подтемы, которые нужно раскрыть:

Описание бизнеса

Например, здесь мы фиксируем:

1. направление бизнеса;

2. его размер;

3. наличие филиалов;

4. основные способы получения денег;

5. разрабатываемые продукты;

6. и т. д.

Описание ИТ

А здесь фиксируем:

1. размер и сложность инфраструктуры;

2. наличие собственной или заказной разработки;

3. используем ли облака;

4. наличие старых, неподдерживаемых операционных систем (не надо их перечислять, просто зафиксируйте тезис, если он актуален);

5. перечень и кол‑во обрабатываемой информации (например, 200 тысяч строк персональных данных специальной категории);

6. и т. д.

Раздел 3. Комплаенс

Хотим мы этого или нет, но комплаенс идет рядом с CISO всегда. Будь то государственное регулирование, стандарты b2b‑клиентов или материнской компании. Это нужно учитывать при разработке стратегии.

В данном разделе следует отобразить перечень стандартов, которые вы должны выполнять в рамках выполнения ожиданий заинтересованных сторон (ISO27, SOC2, внутренние стандарты и т. д.) или в рамках деятельности самой компании (152-ФЗ, 187-ФЗ, PCI DSS, 250 указ президента и т. д.).

Также важно дать краткое описание почему мы должны соответствовать этому стандарту (обосновать необходимость нам помогут 1 и 2 разделы), и насколько мы соответствуем ему сейчас.

Раздел 4. Факторы и тренды сферы

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

Первое что необходимо отразить — факторы уровня государства.

Геополитика, санкции, импортозамещение, боевые действия, стихийные бедствия, пандемии — все это прямо или косвенно влияет на деятельность компании и ее информационной безопасности. Например, уход вендоров СЗИ.

Второе что необходимо отразить — факторы уровня внешнего регулирования.

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

Третье что необходимо отразить — ключевые элементы аналитических отчетов.

Расположите в разделе несколько ключевых графиков с краткими описаниями (рост атак, рост утечек и т. д.), а самое главное — зафиксируете, из каких аналитических отчетов вы взяли эти цифры или выводы. Нужно отразить как общие цифры, присущие среде в целом, так и цифры, применительные к вашей компании (например, разделение по секторам экономики или иным признакам, которые зафиксированы во 2 разделе). Осознание того, что происходит в среде — очень важный фактор для формирования стратегии. Необходимо продемонстрировать, что тот «волк в лесу», которым CISO пугает руководство, действительно существует.

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

1. https://www.ptsecurity.com/ru‑ru/research/analytics/;

2. https://jetcsirt.su/analytics/;

3. https://rt‑solar.ru/analytics/reports/.

Четвертое что необходимо отразить — бизнес факторы.

Если заинтересованные стороны действительно рассматривают ИБ как козырь в продажах SaaS‑решения, то все довольно просто. Попросите продажников и маркетологов подготовить аналитику: сколько лидов имеют требования к безопасности, сколько из них не купили наш продукт из‑за ИБ, какая потенциальная потеря в деньгах и что нужно сделать, чтобы увеличить конверсию. Этой аналитики будет достаточно.

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

Раздел 5. Оценка рисков существующей системы

Фундаментально оценка рисков должна показать нам, что те мифические угрозы и тренды (из 4 раздела), которые применимы к нашему бизнесу, несут реальный ущерб компании. Риски помогают нам приоритизировать и обосновывать наши проекты и бюджет. В идеале нужно иметь количественную оценку рисков (основанную на деньгах). Она позволит нам просчитать ROSI. Если выразить риски в деньгах вам сложно, то может помочь White paper «Quantitative Risk Analysis Step‑By‑Step» от организации SANS Institute (найти можно тут).

Зафиксируйте тут табличку с рисками, которая у вас есть. Можно внести не все, а только самое актуальное, на что будет сфокусировано основное внимание.

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

Также большим плюсом в этом разделе будет являться оценка сильных и слабых сторон компании с точки зрения ИБ (тут может помочь 4 пункт 4 раздела и 2 пункт 2 раздела). Например, у вас сильное DevOps/SRE направление (все автоматизировано, отказоустойчивая инфраструктура, все покрыто мониторингом, и каждая ошибка разбирается очень тщательно), то это очевидно сильная сторона, которая сама по себе уже снижает ряд рисков. А теперь представьте, что ИТ не имеет схем сети и продакшена, не имеет нормального мониторинга и все разрозненно; так еще админы склонны к саботажу инициатив ИБ, что очевидно не только не снижает риски, но и усиливает их.

Раздел 6. Информационная безопасность компании

Раздел‑отчет. Укажите существующие активы команды и ее обязательства, чтобы было лучше понятно тонкие места существующей системы.

Фиксируем:

1. Состав процессов и их зрелость;

2. Состав технических средств;

3. Структуру команды;

4. Компетенции команды;

5. Бюджет последних лет;

6. Оценку насколько существующая система не справляется с рисками и почему;

7. и т. д.

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

Если у вас достаточно денег, то лучше заказать услугу независимой оценки ваших процессов у независимых экспертов. Очевидно, что это «опасно» для CISO, ведь на руках будет независимая оценка его работы. Но если вы готовы к результатам такой оценки, то ее лучше провести.

Раздел 7. Планируемые изменение внутренних факторов

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

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

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

Раздел 8. Оценка рисков планируемых изменений

Этот раздел мало чем отличается от 5-го. Единственная разница — мы просчитываем риски для будущего, а не настоящего. Важно осознать: если ИБ не успевает за изменениями бизнеса, то образуется слепая зона. Слепая зона — совокупность изменений в процессах компании или ее информационной инфраструктуре, о которых не знает ИБ. Опасность слепой зоны в том, что она рождает неизвестное количество неконтролируемых угроз. А как мы знаем «предупрежден — значит вооружен».

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

Раздел 9. Проработка требований ИБ

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

Итак, у нас есть разделы 3, 4, 5 и 6 (комплаенс, риски и тренды). Теперь нам необходимо зафиксировать подоменные требования. Требования должны быть верхнеуровневыми и фиксировать общее направление без привязки к конкретным решениям. Доменами в данном случае считаются направления нашей деятельности: мониторинг, сетевая защита, управление контрагентами и т. д.

Например, в 6 разделе (ИБ в компании) мы зафиксировали, что у нас есть процесс мониторинга в режиме 8/5, единого хранилища логов нет, компетенций в команде по развертыванию SIEM и его настройке нет. Основываясь на трендах, рисках и комплаенсе, мы понимаем, что сейчас нужно усилить это направление. Начинаем фиксировать наши ожидания: мы хотим внедрить сборщик логов, который будет собирать данные со всех ИС и СЗИ и имеет возможность создания правил корреляций, и хотим чтобы мониторинг был 12/7. Вот мы и создали верхнеуровневые требования для домена «мониторинг». Фактически это наша маленькая стратегическая цель, которую нужно достичь.

Раздел 10. Создание программ

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

Например, мы можем воспользоваться коммерческим SOC (нужно расписать, какие есть варианты на рынке и какие коммерческие предложения), можем внедрить свой SIEM (точно также зафиксировав цены), можем посмотреть на что‑то опенсорсное или написать самим (а почему нет). Если мы рассматриваем покупку SIEM, то нужно сюда заложить и стоимость СХД. А кто будет разворачивать наш SIEM? Сразу фиксируем предложения разных интеграторов (ведь у нас нет компетенций, как мы и зафиксировали в 6 разделе). А может просто нанять себе специалиста который будет лидировать сопровождение системы? А может взять аутсорс? А кто будет заниматься непосредственно мониторингом (смотреть в дашборды)? Есть ли ресурсы? Нужно ли нанимать новых людей? Собственно каждый новый вариант ответа это и есть опция, и эти опции стоят разных денег.

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

Такое же упражнение необходимо провести и со всеми остальными доменами.

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

Заключение

В конце хочется сказать, что написание стратегии очень сильно отличается от компании к компании, а также зависит от целей. Где‑то вам хватит и таблички эксель, а где‑то придется писать работу в 3 томах. Я лишь предложил один из вариантов, который вы можете адаптировать под себя как угодно. Добавляйте разделы, если нужно, и убирайте, если нужно. Это своего рода конструктор, который, как я надеюсь, будет полезен для вас.