• Все разделы
  • Статьи
  • Медиа
  • Новости
  • Нормативные материалы
  • Конференции
  • Глоссарий

Статьи по теме: «Информационная безопасность»

Главная Специалистам Статьи Методология и практика создания SOC

Методология и практика создания SOC

Современное представление о центре мониторинга информационной безопасности (Security Operation Center, SOC) стало результатом эволюции информационных технологий и технологий информационной безопасности, в частности - все большей популярности, которую набрала сервисная модель систем обеспечения информационной безопасности.

Методология и практика создания SOC

Мировой опыт

Все чаще в нормативных документах и стандартах СОИБ стали описывать как комплекс мер защиты (security controls), каждая из которых решает определенную частную задачу безопасности. Реализация отдельной меры защиты включает в себя определенные процессы, участники которых выполняют заранее определенные действия с использованием определенных инструментальных средств. Такие процессы можно измерять как в терминах затрат (например, в форме трудозатрат участников процесса), так и в терминах качества реализации меры защиты на основе количественных показателей. Такая измеримость реализации мер защиты позволяет рассматривать их как услугу (service), которую поставщик (структурное подразделение или внешний подрядчик) оказывает организации. Подобный сервисно-ориентированный подход к формализации мер защиты позволил перейти к аутсорсингу отдельных мер защиты и, в конце 90-х, привел к появлению сервисных компаний, специализирующихся на оказании подобных услуг (Managed Security Services Provider, MSSP).

Изначально обращение к услугам MSSP диктовалось экономическими соображениями: единовременные капитальные затраты, связанные с самостоятельным внедрением средств защиты и процессов информационной безопасности, оказываются для многих компаний более серьезной проблемой, чем ежегодные операционные расходы на услуги MSSP. Но более сильным стимулом стал взрывной рост числа компьютерных преступлений. Организации, не специализирующиеся в области информационной безопасности (в том числе кредитно-финансовые организации, торговые площадки, операторы связи, промышленные предприятия), оказываются неспособны противодействовать не только целенаправленным атакам, но даже и простым вирусным эпидемиям, таким как Conficker или WannaCry, когда для предотвращения инцидента требуется лишь своевременная установка обновлений безопасности. Анализ подобных инцидентов показывает отсутствие в пострадавших организациях и нехватку на рынке труда в целом квалифицированных специалистов, обладающих практическим опытом обнаружения компьютерных атак и реагирования на них. В результате появился платежеспособный спрос на специфическое направление услуг в области информационной безопасности, получившие название Managed Detection and Response (MDR).

Таким образом, на сегодняшний день сложилось представление о SOC как о совокупности сил и средств, которая выполняет для организации функции MSSP и MDR. К силам SOC могут относиться выделенные сотрудники и структурные подразделения организации, персонал информационных систем, привлекаемый по мере необходимости, и внешние подрядчики, при этом выполняемые функции могут распределяться между ними по-разному. Решающую роль в выполнении этих функций может играть как выделенный сотрудник или структурное подразделение компании (внутренний SOC), так и дочерняя организация в составе органа власти или корпорации (корпоративный SOC) или внешний подрядчик (внешний SOC).

Среди функций SOC наиболее «зрелищны» функции, связанные с обнаружением атак и реагированием на них: настенные экраны, цветные карты, строчки предупреждений, операторы в гарнитурах и т.п. Само название «Security Operations Center» (калька с «Tactical Operation Center») создает у потребителя услуг SOC ощущение центра оперативного управления войсковыми операциями, хотя в действительности залогом успеха деятельности SOC являются рутинная повседневная деятельность, связанная с предупреждением компьютерных атак и устранением предпосылок для инцидентов. Но об этом мы поговорим чуть позже.

Предпосылки к появлению российских SOC

Российский рынок развивается по собственным законам, обусловленным объективными экономическими причинами. Во-первых, в Российской Федерации нет такого источника дешевой квалифицированной рабочей силы, каким для мирового рынка являются Восточная Европа, Индия и Юго-Восточная Азия. Из-за этого российскому потребителю аутсорсинг услуг в сфере ИТ не дает такого заметного экономического эффекта, какой получают от него североамериканские, западноевропейские и транснациональные компании.

Во-вторых, основной платежеспособный спрос на услуги в российской сфере ИТ сконцентрирован в федеральных ведомствах и корпорациях, в том числе - государственных. Такие структуры предпочитают создавать собственные ведомственные предприятия и дочерние сервисные компании (Лукойл-Информ, РН-Информ, Гринатом, Бизон и т.п.). В результате до недавнего времени на открытом рынке в России практически отсутствовал платежеспособный спрос на услуги MSSP, а спрос на услуги в области MDR ограничивался разовыми проектами по контролю защищенности информационных систем, защите от DDoS- атак и расследованию инцидентов, уже причинивших существенный ущерб заказчику услуги.

Наконец, в-третьих, сказывается фактическое отставание Российской Федерации в вопросах защиты от компьютерных атак. Так, в США и Западной Европе услуги SOC, а также методические рекомендации по построению таких центров и реализации основных мер противодействия атакам, начали появляться в начале 2000-х. В России первые систематические исследования фактической защищенности информационных систем коммерческих компаний начались в 2006-2008 годах, публикации статистических данных, основанных на результатах таких исследований, начали появляться в 2009-2010 годах, а нормативные документы, включающие в себя меры противодействия компьютерным атакам (такие как методический документ ФСТЭК России «Меры защиты информации в государственных информационных системах») появились лишь в 2013-2014 годах.

В результате основным двигателем развития направления MDR в Российской Федерации стала криминогенная обстановка: заказы на подобные услуги стали поступать от банков и кредитных организаций, операторов связи, промышленных предприятий, при этом стимулом для обращения к поставщикам услуг MDR стали увеличивающиеся объемы финансовых потерь от атак на системы дистанционного и мобильного банкинга, манипуляций с телефонным трафиком и Интернет-трафиком, хищений сырья и готовой продукции с помощью фальсификаций в системах учета. Рынок услуг MSSP при этом развивается по остаточному принципу: зачастую организации осознают наличие недостатков в обеспечении собственной безопасности и свою неспособность самостоятельно их устранить лишь после того, как сталкиваются с инцидентами и видят результаты их расследования.

Таким образом, пока можно говорить только о зарождении в России рынка услуг SOC, и создаваемая инфраструктура ориентирована в основном на работу с органами государственной власти и с крупными корпорациями. Серьезным стимулом для развития направления SOC может стать вступивший в силу федеральный закон «О безопасности критической информационной инфраструктуры Российской Федерации». В сферу действия закона попадает большое количество бюджетных и муниципальных организаций, предприятий малого и среднего бизнеса, индивидуальных предпринимателей, то есть ровно та категория физических и юридических лиц, для которой капитальные затраты на самостоятельное создание систем защиты принадлежащих им информационных систем могут оказаться неподъемными.

Эту проблему можно решить силами лицензиатов в области защиты информации, но это потребует серьезной нормативной и методической поддержки со стороны ФСБ России и ФСТЭК России. В настоящее время оба ведомства, каждое в своей компетенции, ведут разработку соответствующих нормативных актов.

Какие функции может выполнять SOC?

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

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

Разработку такого перечня удобно начать с рекомендаций Национального института стандартов и технологий США (National Institute of Standards and Technology, NIST) «Концепция совершенствования кибербезопасности критической информационной инфраструктуры» (Framework for Improving Critical Infrastructure Cybersecurity). Документ разделяет деятельность по противодействию компьютерным атакам на пять областей: идентификация (Identify), защита (Protect), обнаружение (Detect), реагирование (Respond), восстановление (Recover). Каждая область включает в себя несколько направлений деятельности: так, область Detect включает в себя направления «Cобытия безопасности» (Anomalies and Events), «Непрерывный мониторинг событий безопасности» (Security Continuous Monitoring) и «Процесс обнаружения угроз» (Detection Process). Для каждого направления определяется набор целей, например - «Разработан и внедрен план менеджмента уязвимостей», «Использование отчуждаемых носителей ограничивается политикой безопасности» и т.п. Для каждой цели дается отсылка к определенным разделам стандартов и рекомендаций, описывающих меры защиты, реализация которых необходима для достижения этой цели. В документе даны ссылки на CobIT, стандарты ISO и ISA, публикации NIST SP, но точно так же может быть сделано отображение на требования нормативных документов российских регуляторов.

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

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

Второй полезный документ – рекомендации по информационной безопасности Центра интернет-безопасности (Center for Internet Security, CIS) – CIS Controls. Документ содержит двадцать мер защиты, каждая из которых описывается в виде набора простых рекомендаций («Проводите автоматизированное сканирование уязвимостей», «Регистрируйте неуспешные попытки авторизации», «Анализируйте данные аудита с помощью SIEM или автоматизированных средств анализа журналов аудита»). Несмотря на простоту формулировок, рекомендации достаточно полно определяют набор проактивных мер защиты, которые могут быть реализованы как непосредственно в защищаемых информационных системах, так и в форме услуг по управлению информационной безопасностью (Managed Security Services). При этом направление MDR документ практически не раскрывает.


Рисунок 1: Рекомендации CIS Controls

Третий полезный документ – рекомендации MITRE «10 стратегий первоклассного SOC» (Ten Strategies of a World-Class Cybersecurity Operations Center). Это подробное руководство, ориентированное на компании, создающие SOC, и первое, что оно определяет – перечень почти из сорока функций, которые, по мнению авторов документа, могут быть реализованы в таком SOC.


Рисунок 2. Функции SOC по версии MITRE

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

Объединив функции, описанные в рекомендациях CIS и MITRE, и отобразив их на области и цели, определенные в рекомендациях NIST, мы получим максимально полный перечень функций, который мог бы выполнять «идеальный» SOC. Но так ли необходимо делегировать все эти функции выделенному структурному подразделению или, тем более, внешнему подрядчику?

Какие функции должен выполнять SOC?

Как уже упоминалось выше, почти каждая из возможных функций SOC может быть реализована как непосредственно в самой защищаемой информационной системе, так и отдана на внутренний или внешний аутсорсинг. Какому варианту отдать предпочтение? А главное – нужна ли эта функция вообще?

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

Основная проблема небольших организаций заключается в том, что они часто неспособны в полном объеме использовать те ресурсы, которые приходится оплачивать. Так, компания, в которой работает менее 1000 человек, неспособна обеспечить постоянную ежедневную загрузку компьютерного криминалиста, так как в компании просто не случается такого количества инцидентов, требующих расследования. В этом случае приходится или загружать собственного специалиста дополнительными обязанностями, зачастую не соответствующими его специализации, или отказаться от этой штатной единицы, обращаясь по мере необходимости к услугам профильных сервисных компаний. Этими же соображениями обусловлена популярность такой формы аутсорсинга, как «оказание услуг на оборудовании заказчика», когда потребитель услуги приобретает или арендует технические или программные средства, необходимые для реализации меры защиты, а их эксплуатацию и обслуживание обеспечивает сервисная компания.

Согласно результатам исследования, проведенного в 2017 году институтом SANS, в компаниях с численностью сотрудников до 10,000 человек функции SOC выполняет команда в среднем из 4-7 человек, и в среднем лишь две трети своих функций такая команда выполняет самостоятельно, отдавая остальные полностью или частично на аутсорсинг внешним подрядчикам. При этом исследование показало, что это распределение практически не зависит от характера исследовавшейся функции: оно с небольшими отклонениями характерно для всех функций SOC. Таким образом можно сказать, что в мировой практике нет «табу» на передачу каких-либо функций SOC внешним подрядчикам.

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

Уже упоминавшиеся выше рекомендации MITRE предлагают другой подход к определению необходимого состава функций SOC, основанный на целесообразном размере структурного подразделения, выполняющего эти функции. Рекомендации выделяют пять типоразмеров SOC: виртуальный, малый, большой, иерархический и национальный. Типоразмер SOC выбирается из соображений экономической и управленческой целесообразности. Для каждой функции в зависимости от типоразмера SOC рекомендации определяют, следует ли реализовывать такую функцию в полном объеме, частично или она является опциональной. При этом, согласно исследованию SANS, свыше 70% SOC можно отнести к виртуальным и малым.


Рисунок 3. Пример зависимости нужности функции от типоразмера SOC (A – нужна в полном объеме, B – нужна частично, O – опциональна)

Варианты архитектуры SOC

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

Начиная с малых SOC, насчитывающих от двух до пяти выделенных специалистов, появляется возможность выделить в их структуре первую и вторую линии реагирования. Специалисты первой линии обеспечивают первичную обработку событий безопасности и сообщений об атаках и инцидентах, диагностируют ложные срабатывания средств обнаружения атак, собирают дополнительную информацию о контексте зарегистрированных событий, т.е. создают условия, позволяющие не распылять силы SOC и концентрироваться на реальных атаках и инцидентах. Специалисты второй линии выполняют повседневные операции по администрированию средств защиты, относящиеся к компетенции SOC, а также реагирование на сообщения об атаках и инцидентах, эскалированные первой линией. Как правило, малые SOC способны самостоятельно реагировать только на типовые компьютерные атаки, используя опыт, наработанный в процессе собственной деятельности. Этого, как правило, достаточно для компаний, насчитывающих до 10,000 единиц защищаемого оборудования при режиме работы 8x5. Для выполнения «продвинутых» функций SOC, реагирования на неизвестные атаки и работы в режиме 24x7 такому SOC приходится привлекать внешних подрядчиков.

Кадровый состав больших SOC (до 25 человек) позволяет обеспечить специализацию своих сотрудников, а также возможность экспертной поддержки для противодействия неизвестным атакам и работы первой линии в режиме 24x7. При этом большие SOC способны самостоятельно реализовать большую часть функций SOC для организаций, насчитывающих до 50,000 единиц защищаемого оборудования при централизации сил и средств.

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

Национальные SOC – это особый вид центра кибербезопасности уровня государства (US-CERT, НКЦКИ) или отрасли (ICS-CERT). Как правило, такие структуры занимаются только организацией и координацией деятельности SOC организаций в вопросах, затрагивающих интересы государства, и лишь в исключительных случаях они принимают непосредственное участие в реагировании на масштабные инциденты. Ввиду их исключительности каких-либо общих принципов построения таких центров нет.
Методики управления рисками информационной безопасности и их оценки (часть 2) Интервью с экспертом: «Экспертное сообщество помогает строить цифровую экономику России»