Защита сетевой инфраструктуры предприятия

Операционные центры информационной безопасности или SOC (Security Operations Center), они же центры мониторинга кибератак и реагирования на киберинциденты — фундамент, который обеспечивает устойчивость полностью «оцифрованных» и напрямую связанных с информационными технологиями процессов предприятия. С помощью программно-аппаратных средств и экспертизы специалистов они позволяют производить мониторинг ИТ-инфраструктуры и аккумулируют данные о событиях информационной безопасности, выявляют аномалии, реагируют на угрозы. Они же на основе собранной информации расследуют инциденты, оказывают помощь ИТ-службе в процессе инвентаризации информационных ресурсов, в зависимости от зрелости процессов могут выполнять множество других задач.  Об оценке эффективности SOC, выборе средств защиты, о том, какой модели отдать предпочтение: собственному SOC или коммерческому, рассказывает директор по продуктам компании «Гарда Технологии» Павел Кузнецов.

• Какие метрики использовать для оценки эффективности SOC
• Обязательные, желательные, второстепенные средства защиты
• SOC: свой или чужой
• Как выбрать коммерческий SOC

Какие метрики использовать для оценки эффективности SOC

Тема оценки эффективности SOC обширна, и подходы к такой оценке могут быть различными. Как правило, в базовый набор метрик входит выполнение всех прописанных SLA. Причем, временные параметры разнятся по классификации отрабатываемых процессов. Для инцидентов на критических для компании ресурсах эта метрика может быть максимально сжата и требование по времени реагирования и предоставления заинтересованным подразделениям информации, как правило, не превышает узких окон — в 5-15 минут. В случае же с отработками низкоприоритетного характера может быть установлено требование по формированию общего отчета за период. Это применимо, к примеру, для выявленной атаки, не подтвержденного инцидента, а только попытки проникновения, малоопасного и максимального распространенного, типа сканирования сервисов на периметре инфраструктуры. В Интернет сканируют «все и всех», поэтому экстренное реагирование на каждую попытку — это сжигание ресурсов. Важно удостовериться лишь, что такие попытки фиксируются автоматизированными средствами, не оставаясь незамеченными, на случай дальнейшего развития атаки. 

Временной параметр можно также декомпозировать на три основные составляющие: 

• время обнаружения;
• время оценки;
• время реагирования. 

Для одних зафиксированных событий актуальны все три параметра, для каких-то достаточно и первого.

Вместе с тем, есть, на что обратить внимание, даже имея прописанную процессную модель с сопутствующими SLA и их контролем, ведь достижение состояния защищенности — постоянная игра «в догонялки» с не стоящими на месте атакующими. Именно поэтому любой SOC должен развиваться и быть готовым гибко реагировать на изменение ландшафта угроз.  С точки зрения тех же временных параметров, имеет смысл проводить сравнение затраченных на обнаружение, оценку и реагирование человеко-часов за различные периоды ДО и ПОСЛЕ внедрения новых средств защиты информации, средств автоматизации и оркестрации кибербезопасности. 

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

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

Однако наиболее качественно оценить эффективность работы SOC возможно только «в бою» — запустив процесс red team’инга (постоянной проверки инфраструктуры «на прочность» силами обособленного подразделения специалистов по тестированию на проникновение), либо организуя регулярные полноценные учения с привлечением внешней команды red team. С помощью такой проверки можно быстро оценить и понять все основные слабые места центра мониторинга: увидеть, где наблюдаются недостатки покрытия — «видимости» активов и событий, где сотрудники испытывают проблемы с корректным реагированием, и даже выяснить, что в сети появился в обход установленных процедур новый актив. 

Это, во-первых, может явиться причиной для пересмотра процессов взаимодействия с ИТ-подразделением и, во-вторых, впоследствии поможет избежать серьезных потерь при реальной атаке злоумышленников, так как SOC уже будет полностью готов к ее отражению, отработав соответствующие действия множество раз.

Обязательные, желательные, второстепенные средства защиты

Базовый набор инструментов описан достаточно давно в виде «триады видимости SOC» и включает в себя:

1. Решения сетевого мониторинга и реагирования (network traffic analysis/network detection & response, NTA/NDR);
2. Решения для работы с «конечными точками» в инфраструктуре (endpoint detection & response, EDR);
3. SIEM-системы (Security information and event management), исторически ставшие ядром современных SOC. 

Последние используются зачастую как решение для onboarding’а на мониторинг всего того, что подключить к EDR и NTA/NDR пока что невозможно, либо трудозатратно с точки зрения непосредственно сбора и анализа событий и организации корректного реагирования. 

Для «зрелой» части системы информационной безопасности организации можно порекомендовать уделить дополнительное внимание защите именно критических активов. Например, в случае опасений, связанных с утечками информации, применить решения, защищающие хранилища и базы данных, классов DAM/DBF, а в случае критической необходимости обеспечить стабильность периметровых ресурсов — anti-DDoS решения. 

Зрелый подход к обеспечению киберустойчивости также предполагает проактивность, поэтому нелишне будет рассмотреть возможность подключения сервиса threat intelligence (TI, «проактивная аналитика киберугроз»). Это поможет лучше понимать ландшафт релевантных для защищаемой инфраструктуры угроз и получить возможность готовиться к атаке еще до ее начала, а также проводить на основе аналитических данных периодический compromise assessment — проверки на предмет возможно уже произошедшего, но пропущенного проникновения злоумышленника в сеть. А это, к сожалению, не редкость. Особенно если речь идет о квалифицированных атакующих, которые классифицируются как advanced persistent threat — в прямом переводе «устойчивая угроза продвинутого уровня». Подобные группы атакующих после успешного проникновения в сеть могут оставаться незамеченными даже годами.

SOC: свой или чужой

Свои плюсы и минусы есть и у внутреннего, и у внешнего, коммерческого SOC. Так, у совсем небольшого количества компаний, особенно не относящихся к отрасли ИТ, имеется достаточный ресурс на набор в штат команды действительно квалифицированных специалистов по кибербезопасности. Также необходимо принять во внимание сложную ситуацию с квалифицированными специалистами на рынке труда. Для многих компаний внешний SOC — очевидное решение, однако же степень знания инфраструктуры, погруженности в особенности процессов и контекста бизнеса у штатного сотрудника всегда будет выше. В этом случае рекомендуется комбинировать подходы. Внутренний специалист по кибербезопасности, погруженный в контекст организации, необходим ей с того момента, когда в ней появляется хотя бы минимальная зависимость стабильности бизнес-процессов от ИТ. Этот специалист (а в дальнейшем — растущее подразделение) может выступать интерфейсом взаимодействия с внешним SOC на всех этапах зрелости ИТ в компании, а затем, по мере появления ресурсов, можно начинать перенимать мониторинг от сервиса, следуя итеративному подходу. Поэтому какую-то конкретную точку принятия решения вида «свой SOC или сервис» назвать сложно. Однако, если мы ведем речь об активах, содержащих, к примеру, информацию ограниченного распространения, охраняемую законом, то внешний сервисный мониторинг безопасности таких активов будет затруднен, если не невозможен — и поэтому при их наличии строить свой SOC придется сразу же.

Как выбрать коммерческий SOC

При выборе коммерческого SOC следует обращать внимание на следующие параметры: 

• наличие подтверждаемых компетенций в обеспечении кибербезопасности; 
• соответствие предлагаемого набора услуг потребностям организации; 
• репутационный фактор, в том числе наличие рекомендаций от текущих клиентов; 
• степень зрелости и детализации предлагаемых SLA; 
• готовность брать на себя ответственность в случае их нарушения.

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

По всем вопросам обращайтесь:
Иван Романенко,
Менеджер по развитию бизнеса вендора Гарда Технологии
ivan.romanenko@softline.com
+79896114370
+7 (495) 2320023 ext. 5314

Получайте новые статьи моментально в Telegram по ссылке: https://t.me/sldonline_bot.