Зри в корень!
(Козьма Петрович Прутков)
Последнее время много говорят и пишут о SOC -ах. Что ж, с традиционным для себя опозданием, попробую тоже быть в формате каналов .
В, с каждым днем все более далеком, 2009-ом, я трудился в замечательной нефтяной компании, имеющей более 20-и региональных представительств. Достигнув определенной зрелости процессов и технологий ИБ, мы задумались над оптимизацией своих операционных затрат с одновременным усилением контроля ИБ... Тогда мы пришли к очевидному и одновременно гениальному в своей простоте решению: значительно дешевле посадить централизованное подразделение из ~10-и человек в одном из регионов, чем в каждом из ~20-и нанять на работу, минимум, по два безопасника. Это подразделение было названо Центром управления безопасностью (кстати, на слайде 65 фоном дан, немного обфусцированный, один из отчетов этого подразделения), и, постепенно, на него были переведены почти все операционные задачи ИБ: мониторинг и сопровождение СЗИ, управление инцидентами ИБ, контроль соответствия требованиям к стандартной операционной среде (стандарты АРМ), контроль доступа к информационным активам, управление уязвимостями, и пр.
Чем это не SOC? Все те же плюшки с концентрацией знаний и ответственности, обеспечением единого уровня операционной ИБ по всему интерпрайзу, что особенно важно в условиях единой инфраструктуры... Да, вот то, что выделено, является одновременно и требованием к такой централизации, поскольку единое ИТ требует единого уровня ИБ (помним, что ИБ - свойство ИТ), а самый простой способ обеспечения однообразия - сконцентрировать ответственность в одних руках - в созданном Центре [компетенции], а также - обязательным условием возможности реализации такой централизации, так как удаленное обслуживание трудноосуществимо в нецентрализованной инфраструктуре (~ нет единой аутентификации и авторизации, например, через единый домен AD, или, вообще, без сетевой доступности).
В целом, создание центров компетенции, и не только по ИБ (== SOC) - дело хорошее, как минимум, с позиции оптимизации затрат.
Таким образом, разговаривая про разные аспекты SOC, важно понимать следующие, очевидные и, на мой взгляд, логичные, вещи:
1. Если у вас нет операционной безопасности - желание построить SOC вас не спасет. Курсивом выделил не случайно, так как при таком раскладе сделать SOC, скорее, не получится (одного желания, к сожалению, не достаточно), - велик риск споткнуться на первом же этапе - определении выполняемых SOC-ом сервисов, поскольку эти сервисы - сервисы существующей операционной ИБ, а если ее нет, нет и ее сервисов.
2. SOC - не что иное как ваша операционная ИБ, или ее часть (трансформированные с целью оптимизации стоимости функции, с одновременным повышением эффективности, за счет сокращения затрат на внутренние коммуникации) - вопрос только в том, какие сервисы ИБ централизовать можно, а какие нельзя (ну, например, сопровождение железа ИБ (если это почему-то делают не ИТ) полностью делать удаленно не всегда получится, поэтому эта функция частично выпадет на локальных людей (не вижу причин почему это не могут быть коллеги из ИТ), аналогично - реагирование на инциденты, которое не всегда можно сделать исключительно удаленно и т.п.)
3. Для работы Центров компетенции вообще, и SOC, в частности, нужна зрелая ИТ-инфраструктура, хотя... , - но об этом поговорим в одном из следующих постов.
4. Наличие других Центров компетенции (в частности, в ИТ) упрощает схемы коммуникацийэскалаций SOC в рамках работы над инцидентами.
В заключение хочется пожелать всем заниматься построением операционной безопасности, а не SOC. Достигнув определенного этапа в этой работе, SOC - будет для Вас одним из вариантов достижения компромисса между качеством и стоимостью.
