Процессная модель является важной составляющей любого SOC (Security Operation Center, Центр управления безопасностью), оказывая большое влияние на качество его работы. Как следует подходить к разработке процессной модели SOC on premise / in-house (на стороне заказчика)? Автор предлагает способ на основе собственного опыта. Статья будет полезна CISO (Chief Information Security Officer, директорам по информационной безопасности), CSO (Chief Security Officer, директорам по безопасности).
- Введение
- Место процессной модели в SOC
- Подход к созданию SOC
- Процессная модель не может быть статична
- Выводы
Введение
Не секрет, что интересные результаты исследований зачастую возникают на стыке областей знаний. В данном случае одной из таких областей точно будет безопасность, а результатом — управляемая деятельность SOC. Будем рассматривать SOC как классическую связку людей, процессов и технологий, т. е. в терминологии отечественного ГОСТ SOC — это автоматизированная система. Добиться с помощью этой системы поставленных целей возможно только в том случае, если мы ею управляем. Как управленцам, нам в последнюю очередь хотелось бы воздействовать на каждый компонент системы в отдельности. Гораздо интереснее получить систему, настроенную изнутри, выполняющую свои задачи с минимальным нашим участием. Добиться такого результата от SOC можно при помощи выстраивания процессов.
Об этом мало кто пишет. Процессы часто путают с услугами. Кроме Cobit for Information Security от ISACA, автор не встречал серьезных непроприетарных методологий, которые можно использовать для выстраивания процессов в SOC. Но и Cobit будет непросто, а иногда почти невозможно «приземлить» на деятельность конкретной компании. Основная проблема будет в негибкости. Вы начнете выкидывать неприменимые к вам кусочки Cobit, а в итоге окажется, что оставшееся уже неработоспособно. В таких реалиях автор предлагает не готовую процессную модель, а подход к созданию своей уникальной модели под конкретный SOC.
Место процессной модели в SOC
Зачем вообще нужна процессная модель? Ключевое слово — модель. С ней проще всего работать, так как она наглядна, легко изменяема, предоставляет возможность использования большого количества инструментов. Человечество всю свою историю работает исключительно с моделями, отражающими действительность в каком-то приближении. Хороший выпускник MIT на вопрос о том, чему там учат, ответит: «Работать с моделями». Всем известные три закона Ньютона по сути являются не законами природы, а обобщением большого количества опытов, дающих возможность прогнозировать результаты в рамках классической механики.
С SOC все ровно так же: мы создаем модель его работы под заданные условия. Еще никто не получил ни одного бита, не увидел ни одного дашборда, а мы уже сможем отлаживать работу целого подразделения внутри компании.
Самое интересное, что даже если никто не разрабатывал процессную модель, процессы никуда не делись. Просто мы про них почти ничего не знаем. Если по-простому, то процесс — это какая-то деятельность. Аналитики ведь на работу ходят, в мониторы смотрят, зарплату получают, регулярно отчитываются всякими графиками статистики об инцидентах. А для чего они это делают? А они это делают хорошо или плохо? А если плохо, то как сделать чтобы делали лучше? А тот SOC, который есть сейчас, достаточен или, может, избыточен? Может, он вообще не нужен, и проще все отдать MSSP или MDR? В итоге мы почти ни на один вопрос уверенно ответить не сможем, а бизнес регулярно выделяет бюджет на безопасность, который иногда нужно обосновывать.
Подход к созданию SOC
Цепочка, приводящая к созданию SOC-ов, формально выглядит следующим образом:
Требования бизнеса (он оплачивает создание) -> Реализация требований через предоставление услуг с заданными SLA –> Реализация услуг (через процессный подход).
Один программист говорил, что его лучший помощник в решении сложных задач — кот. Программист рассказывает коту о своей проблеме и, проговаривая ее, находит решение. Так давайте используем аналогичный подход для создания процессной модели — будем рассуждать вслух.
Нам нужно выполнить требования бизнеса. Чего хочет бизнес? Чтобы ему не мешали зарабатывать деньги. Он хочет быть в безопасности и спокойно заниматься своим делом. Значит, одним из основных требований для нас будет повышение уровня защищенности. Да, оно верхнеуровневое, и дальше нам придется самим спускаться до конкретики, но, собственно, за это нам бизнес и платит.
Как мы будем повышать уровень защищенности? Для начала определимся, что мы будем защищать и что этому может угрожать. Т. е. фактически мы будем делать то, что обычно называют управлением рисками. Если мы не управляем рисками, то маловероятно, что нам необходим SOC.
Хорошо. Мы провели соответствующую работу (сами или с привлечением сторонних организаций), и у нас на руках есть перечень мер, с помощью которых мы будем управлять выявленными рисками. Часть из этих мер будет связана с операционной деятельностью в области безопасности. Вот как раз этим и занимается SOC. Он осуществляет операционную деятельность в безопасности.
Для получения списка услуг, которые внутреннему заказчику (бизнесу) предоставляет SOC, нам осталось сгруппировать меры, придумать названия услуг и разработать под них SLA. Пример такой группировки приведен на рисунке ниже (основа взята из «Ten Strategies of a World-Class Cybersecurity Operations Center», Carson Zimmerman, MITRE).
Рисунок 1. Пример услуг SOC
Услуги есть. Осталось формализовать, как они будут предоставляться, т. е. детализировать и представить в виде моделей.
Здесь начинается самое сложное, так как некоторые вещи практически нельзя алгоритмизировать, а некоторые требуют знаний не из области безопасности или просто какой-либо специфичной безопасности, например, фрода. В первом случае можно привести пример с деятельностью аналитиков. У вас не получится выдать им регламент реагирования на все случаи жизни. Это сработает только с тривиальными инцидентами. Если вы все еще используете деление аналитиков на линии, то речь идет про регламенты для первой. Все остальное может быть формализовано до уровня рабочего процесса: заступил на смену, проверил потоки событий от источников, взял в работу, передал следующей смене, создал запрос на внесение изменений, самостоятельно принял решения о блокировке из-за экстренного случая, отписался, почему это было действительно необходимо, закрыл и т. п.
В качестве примера для сложностей, связанных с использованием знаний из смежных областей, умышленно приведу подход к реализации такой малопопулярной услуги, как повышение осведомленности. Кто-то на основе собственного опыта, связанного с реагированием на инциденты, доносит до персонала информацию о фишинговых письмах, личных сменных носителях, резервных копиях, требованиях политик и т. д. Кто-то закупает соответствующее программное обеспечение, которое «натаскивает» аудиторию, повышая культуру ИБ в компании. И все это хорошо, если вы вообще этим занимаетесь, но кто оценит эффективность? Периодические опросы? Статистика на основе собранных машинных данных? Отсутствие громких нарушений по вине персонала, обнаруженных (а не обнаруженных?) в течение года? Возможно. Но суть повышения осведомленности — вложить в головы людей несколько важных мыслей таким образом, чтобы они ими руководствовались в своих действиях, практически не задумываясь. Можно было бы позаимствовать соответствующие знания у жрецов, глав вероисповеданий, правительства или «мирового закулисья», но они ими обычно не делятся, а вот маркетологи — другое дело. Если бы к задаче повышения осведомленности привлекли маркетолога, он сделал бы примерно следующее. Во-первых, изучил целевую аудиторию, поделил ее на группы со схожими характеристиками. Во-вторых, для каждой группы выделил наиболее действенные каналы воздействия. Аудитория иногда даже не догадывается, что ею манипулируют, подталкивая к определенным действиям. Мелочи на кассе супермаркета видели? Невольно задумываешься, не взять ли. А почему магазины с игрушками обычно на верхних этажах торговых центров? Маркетологи. Думаю, дальше процесс можно не описывать, мысль должна быть понятна: эксперты в области безопасности обычно работают иначе.
В итоге мы доберемся до конкретики, и каждая услуга обрастет основными процессами (процессом). В свою очередь, вокруг основных процессов появятся поддерживающие, которые при необходимости (если таковая действительно возникнет) можно дальше группировать. Между процессами появятся связи и узкие места. Наша модель готова.
Нужно ли нам отображать их в какой-либо нотации? Не обязательно. Если ваш SOC мал и только строится, то в нем не может / не должно быть большого количества услуг, а следовательно, процессов и людей. Управлять чем-то маленьким можно и без бюрократии. Но если ваш SOC велик и вы хотели бы эффективно им управлять, то формализация процессов вам в этом поможет. Разумеется, если вы CISO, то схемы в нотации IDEF или UML отрисовывать будет кто-то другой. Даже анализировать узкие места будете не вы. Вы получите минимум подробностей, максимум показателей (метрик). Но вы же — CISO и именно так управляете безопасностью в своей компании, думая не о технических деталях, а о цели существования компании — получении прибыли.
Не зря говорят, что нельзя управлять тем, что нельзя измерить. Кстати, а как мы будем измерять наш SOC? Я бы использовал одну из моделей зрелости возможностей (например, открытая SOC CMM), адаптировав ее под себя. Именно возможностей, так как можно быть зрелым, но при этом не выдавать требуемого результата.
Процессная модель не может быть статична
Применяя такой подход к разработке процессной модели, в каждом случае мы получим уникальный результат, который отражает особенности заказчика. Но лишь в том случае, если мы не будем на каждом шаге бездумно использовать шаблоны. Например, в рамках идентификации рисков мы воспользуемся моделированием угроз как самым простым способом и везде будем брать базовую модель угроз для защиты персональных данных. Отдельные исполнители иногда доходят до абсурда, используя такой подход. Автор был свидетелем использования обозначенной модели при защите АСУ ТП после появления Приказа ФСТЭК России от 14 марта 2014 г. N 31. Причем исполнитель был в курсе, что регулятор рекомендовал использовать в данном случае базовую модель угроз из КСИИ. Причина, конечно, банальная — лень-матушка, так как использование честной модели было гораздо сложнее.
SOC можно сравнить с живым организмом. Он так же изменяется в процессе своего существования. Так как модель процессов полезна только в том случае, когда она отражает действительность, вам придется пересматривать ее на регулярной основе. При желании можно применять для этого модный ныне цикл Шухарта-Деминга (он же PDCA). А можно и не применять — главное, чтобы вас устраивал результат.
Выводы
В настоящее время тема создания SOC является хайпом (привлекает к себе много внимания и поднимает шумиху). К сожалению, много внимания уделяется вопросам технической архитектуры, которые являются самыми простыми. Выстроить работу людей гораздо сложнее. Надеюсь, что данная статья послужит одним из ориентиров в данном вопросе.
Многие назовут описанный подход идеальной картиной мира, которая в жизни не работает по ряду причин. Сократ по этому поводу сказал примерно следующее: «Кто хочет — ищет способ, кто не хочет — ищет причину».
