Наверно они сотрудничают...

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

Облако объединяет

Безопасность - это искусство Компромисса

В прошлый раз мы узнали, что для построения своего Центра компетенции по ИБ (a.k.a. SOC) крайне полезно иметь, как минимум, сетевую доступность до всех обслуживаемых объектов, иначе, централизованно (не обязательно в одну географическую локацию) собрать все логи технически невозможно.
Тем не менее, в силу различных обстоятельств, многие территориально-распределенные корпорации разделяют не только расстояния, но и "воздушные зазоры", "однонаправленные шлюзы", "защищенные межсетевые экраны", "демилитаризованные зоны" и прочие контроли ИБ. Конечно же, резко рушить все эти старательно возведенные границы - неправильно, поскольку, действительно, более или менее без риска можно соединять только сети с одинаковым уровнем ИБ, а сети с разным уровнем ИБ рекомендуется соединять через что-то из указанного выше, например, ДМЗ. В "уровень ИБ", помимо всего прочего, следует включать и уровень сервисов ИБ, т.е. покрытие сервисами ИБ в соединяемых [без препон] сетях должно быть одинаковым. Также, в прошлый раз мы узнали, что одним из простых способов обеспечения единого уровня сервиса ИБ является реализация компонент этого сервиса одной командой. Конечно же, в каждый островок LAN можно высадить по локальной группе ИБ и всех их организовать в одну команду, но это не будет иметь экономической выгоды (ну, конечно же, не беря во внимание социальную ответственность по созданию множества рабочих мест) и едва ли сможет называться Центром компетенции по ИБ, о чем мы тоже узнали в прошлый раз.
И вот здесь - самое время на своем опыте убедиться в том, что Безопасность - это Компромисс - где для Вас больше риска: (1) в отсутствии какого-либо контроля ИБ в изолированных друг от друга островках LAN или (2) использовании облака любимого MSSP с подключением через Интернет? Несмотря на то, что выбор здесь, полагаю, для большинства очевиден, позволю себе все-таки пояснить. Поскольку в островке LAN по-любому есть Интернет, компрометация тамошних систем - риск более чем материальный, а достучаться до него со всей своей ИБ кроме как через Интернет - невозможно, следовательно, собирать логи будем через Интернет. В целом, ничего нового, - все коммерческие SOC-и так и работают - тащат логи к себе в инфраструктуру, где их всячески обрабатывают и рапортуют Заказчику инциденты. Но концептуально здесь наблюдается интересная вещь: различными способами изоляции мы вытеснили сервисы Бизнеса в Интернет, и вместе с ними - сервисы ИБ, а позже выяснили, что агрессивная среда Интернет стала для нашей инфраструктуры средой консолидации, позволяющей строить централизованные сервисы, а "Облако MSSP" - единственный быстрый вариант обеспечения одинакового уровня сервиса мониторинга ИБ для корпорации без единой инфраструктуры, состоящей из островков LAN без сетевой доступности между ними. Кроме этого, есть дополнительные "плюшки" (не беря во внимание, что единое информационное пространство надо еще построить, а на это могут уйти годы, с учетом количества задействованных участников-строителей - человеко-века):
1. Логи в Облако MSSP через Интернет уезжают быстрее, чем если бы они путешествовали по корпоративным WAN-каналам, до централизованного места сбора и анализа.
2. Если из этого же облака MSSP приезжает детектирующая логика, то из Интернет она приезжает быстрее, чем из централизованного места в корпоративной сети, проползая через все имеющиеся шлюзы и WAN-каналы.
3. Тут все преимущества MSSP, который видит не только вашу инфраструктуру, но и другие, поэтому у него тупо больше опыта - он ловит рыбу в разных частях Мирового океана, вы - только в одной своей заводи.
4. Не надо думать, что ваши логи у MSSP в больше опасности, чем у вас. Там люди не менее квалифицированы чем ваши ИТ\ИБ, дополнительно есть догворные обязательства, которые могут более полно отражать ваши риски, чем должностные инструкции ваших работников или работников на удаленных площадках.

В сухом остатке, если вы осознали необходимость операционной безопасности и даже Центра компетенции по ИБ (== SOC), но ИТ-инфраструктура не готова обеспечить вам желаемый уровень централизации, Облако MSSP - отличный быстрый старт, который позволит вам уже сейчас работать в режиме, аналогичном наличию Центра компетенции по ИБ, находясь еще в условиях сетевой "феодальной раздробленности".

Разоблачение SOC

Зри в корень!

(Козьма Петрович Прутков)

Последнее время много говорят и пишут о SOC-ах. Что ж, с традиционным для себя опозданием, попробую тоже быть в формате каналов.

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

В заключение хочется пожелать всем заниматься построением операционной безопасности, а не SOC. Достигнув определенного этапа в этой работе, SOC - будет для Вас одним из вариантов достижения компромисса между качеством и стоимостью.