Цель SOC – не прийти с сервисом мониторинга, а найти и устранить «боль» заказчика, решить его проблему и помочь стать безопаснее.
Владимир Дрюков, директор центра мониторинга и реагирования на кибератаки Solar JSOC компании Solar Security.
Правило 1: Репутация дороже денег.
Коммерческий SOC должен уметь концентрироваться на задаче, которую перед ним ставит заказчик. Цель SOC – не прийти с сервисом мониторинга, а найти и устранить «боль» заказчика, решить его проблему и помочь стать безопаснее. И зачастую правильный подход может отличаться от коммерчески выгодного для SOC.
Например, если у заказчика не проведена сегментация сети, можно убедить его в необходимости подключения каждого хоста к мониторингу как компенсирующей меры (и хорошо заработать на этом). В итоге SOC видит и контролирует все происходящее – казалось бы, все довольны. Но правилен ли этот подход? Позволит ли он быстро противодействовать очередной вирусной эпидемии типа WannaCry или Petya даже с полным покрытием хостов мониторингом? Скорее всего, нет. В этом случае правильнее посоветовать заказчику гораздо более полезные и экономичные работы по сегментации сети, используя для аргументации выявленные в SOC инциденты и известные сценарии атаки.
SOC не должен гнаться за маркетинговыми трендами и говорить заказчикам что-то вроде: «Вам надо срочно купить песочницу, потому что всех сейчас атакуют таргетированно!» SOC должен, исходя из своей карты инцидентов, понимать, насколько те или иные угрозы актуальны для конкретной организации. Возможно, где-то мероприятия по повышению осведомленности ряда сотрудников гораздо правильнее, эффективнее и экономичнее, чем покупка дорогого AntiAPT-решения.
Мы считаем, что для выстраивания репутации на рынке SOC всегда должен ориентироваться на интересы заказчика, даже если при этом он снизит свой объем работы и потенциальный заработок. Решение «поставить все на мониторинг» не может быть универсальным. SOC должен выстраивать баланс между милитаристскими политиками безопасности там, где это необходимо, и компенсирующими мерами там, где бизнес-задачи не приемлют подхода «все запретить», но требуют сохранения контроля за безопасностью. В каждом случае SOC должен выступать не в качестве стороннего сервиса, а в качестве инструмента аналитики, помогающего в поиске наиболее правильного и бюджетного пути среди паутины предложений, присутствующих на рынке.
Правило 2: Только индивидуальный подход
Специфика российского рынка центров мониторинга в том, что заказчики ждут от SOC не предоставления атомарно-детерминированной услуги мониторинга 10-15 базовых Use-Case или сценариев, а сервиса, который будет, насколько это возможно для внешней компании, учитывать специфику работы организации. Иными словами, заказчик хочет, чтобы центр мониторинга не просто выявлял инциденты, а интерпретировал их, исходя из знания контекста, особенностей организационной структуры и бизнес-процессов конкретной компании.
Это требование вызвано, как минимум, двумя причинами.
Первая состоит в том, что уровень базовой гигиены ИБ по России в среднем чуть ниже, чем на Западе, поэтому довольно большая доля подозрений на инциденты (около 70%) – это не атаки киберпреступников, а некорректная работа внутренних пользователей, вызванная отсутствием ИТ-специалистов, внутренних регламентов, упорядоченных процессов по работе пользователей и так далее. Для того чтобы корректно анализировать возникающие подозрения на инцидент, специалисты SOC должны оценивать не только фактическое событие, но и логичность его возникновения. Например, использование технологической учетной записи на машине ИТ-администратора, скорее всего, не является инцидентом с последствием для бизнеса компании, в то время как использование такой же записи на машине бухгалтера или финансовой службы, вероятно, говорит о компрометации учетной записи и развивающейся хакерской атаке.
Вторая причина довольно тривиальна: людей, которые могут организовать процесс реагирования и расследования на стороне клиента, очень мало. В отличие от международной практики, когда в штате у заказчика может быть огромный response team, в российских компаниях реагированием на инциденты, о которых сообщает SOC, занимаются, как правило, один-два человека. При этом в их зону ответственности входят и другие задачи.
У офицеров безопасности нет ресурсов на то, чтобы разбирать логи в консоли SIEM и восстанавливать события. Получив базовое оповещение, они должны быстро вынести вердикт, является ли событие инцидентом, и немедленно начать действовать. Если судить по той практике, с которой нам приходилось сталкиваться, в западных компаниях так бывает довольно редко. Там MSSP оперируют почти исключительно базовыми уведомлениями, отдавая приличный объем аналитики на откуп заказчику.
Вследствие этого перед российскими SOC возникает задача по поддержанию глубины анализа и понимания контекста. Она накладывает на центры мониторинга серьезные требования – во-первых, в отношении экспертизы и качества работы первой линии. Она проводит первичный разбор срабатываний, и профессионализм ее специалистов должен соответствовать не службе helpdesk, а, как минимум, уровню младших аналитиков информационной безопасности.
Вторым следствием кадровой проблемы у клиентов является то, что центр мониторинга вынужден выделять отдельные ресурсы под каждый аккаунт. В западных SOC это называется technical account manager или technical account expert. Эти люди хранят контекст инфраструктуры, процессов, технических и организационных изменений заказчика. И если на Западе это отдельная опция, которая стоит очень дорого, то в России для создания эффективного и полезного заказчику сервиса она должна предоставляться по умолчанию.
Правило 3: Без права на ошибку
Одно из важных отличий внешнего SOC от внутреннего состоит в том, что у внешнего центра мониторинга цена ошибки значительно выше.
Если инженер первой линии внутреннего SOC пропустит инцидент, его уволят. Однако в нынешней ситуации кадрового голода на рынке ИБ даже с плохими рекомендациями через некоторое время он все равно найдет новую работу. В случае с коммерческим SOC пропущенная атака – это клеймо, тем более, если это произошло по вине аналитиков или из-за некачественно разработанных сценариев. Рынок информационной безопасности в России очень узкий, и сохранить произошедшее в тайне практически невозможно, а значит, важность поддержания качества сервисов SOC возводится в абсолют.
Причем если сравнивать ИТ-аутсорсинг с ИБ-аутсорсингом, последний опять оказывается в более сложном положении. В ИТ очень легко понять, качественно ли отработал сервис-провайдер: если система «лежит», то не важно, отмечено ли срабатывание как ложное. Всем очевидно, что проблема не решена. В ИБ-аутсорсинге закрытие инцидента как ложного срабатывания – это решение аналитика. Если оно ошибочно, атака может продолжить скрытно развиваться. Поэтому вес каждого такого решения огромен, особенно если ошибочно закрытый инцидент был частью таргетированной атаки, той самой хлебной крошкой, способной привести к ее детектированию и предотвращению.
Поэтому в Solar JSOC мы применяем около четырех десятков процедур, направленных на внутренний контроль качества сервисов – начиная с совместного с заказчиком тестирования сценариев и заканчивая боевыми учениями.
Среди прочего, у нас внедрена практика case review – вторая линия ежедневно отводит определенное количество времени на то, чтобы перепроверить и верифицировать часть инцидентов, разобранных первой. Разумеется, это касается не всех инцидентов – бессмысленно просто дублировать чужую работу, да и поток событий слишком большой. В первую очередь мы обращаем внимание на инциденты высокой критичности, которые были закрыты как ложные. Цель здесь не только в выявлении возможных ошибок, но и в том, чтобы дать аналитикам первой линии рекомендации по методам разбора инцидентов. Таким образом мы снижаем вероятность нашей ошибки и повышаем качество работы первой линии.
Для SOC – как внутреннего, так и внешнего – это очень дорогая процедура, ведь верификация работы относительно недорогих специалистов первой линии осуществляется за счет очень дорогих аналитиков второй линии. Но это, наверное, единственный вариант, при котором можно контролировать огромный поток инцидентов и сохранять качество.
Правило 4: Не «предоставлять сервис», а решать проблему целиком.
SOC должен предоставлять техническую услугу полного цикла. Нельзя концентрироваться на мониторинге инцидентов и заниматься только им. Если SOC не умеет реагировать на атаки и блокировать их, не в состоянии помочь заказчику в проведении аудита или целенаправленного расследования, такой SOC всегда несколько неполноценен.
Причина проста: если на заказчика идет атака, ему нужно решать проблему немедленно, здесь и сейчас. Уже в момент инцидента заказчик должен быть во всеоружии для обороны инфраструктуры, и естественно, что он либо готов делать это своими силами, либо рассчитывает на помощь той же команды, которая выявила инцидент.
Поэтому от аналитиков SOC требуется экспертиза в областях, совершенно не связанных с базовым мониторингом. Например, когда удается по косвенным признакам зафиксировать, что заражение вредоносным ПО является частью более масштабной APT-атаки, недостаточно просто перекрыть все доступы. Как правило, разбор инцидента начинается с анализа зараженных машин (поиска артефактов, скомпрометированных данных и т.д.) и анализа вредоносного ПО в ручном режиме. Это позволяет определить функциональность и способы распространения вредоноса, чтобы совместно с заказчиком разработать эффективные способы противодействия атаке, которые обычно не видны на старте.
В момент атаки у заказчика нет времени на то, чтобы приглашать третью компанию, обладающую необходимыми компетенциями, заключать договор на проведение технической экспертизы инцидента и т.д. Не говоря о том, что в случае взаимодействия разнородных подрядчиков возникает слишком много смежных зон ответственности. В результате повышается риск того, что подрядчики эффективно выполнят задачу каждый в своем поле, но потеряют рациональное зерно в серой зоне, и это полностью уничтожит результат.
Поэтому, даже если прямо сейчас заказчик не требует услугу полного цикла, нужно понимать, что такая потребность может внезапно возникнуть. И SOC должен быть всегда готов.
Правило 5: «Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее».
Как коммерческая структура, ориентированная, прежде всего, на получение прибыли, деятельность SOC зависит от того, насколько заказчики удовлетворены уровнем сервиса.
Атаки, как и средства защиты от них, постоянно развиваются, и для того, чтобы просто продолжать мониторить все те же активности в новой среде, SOC должен постоянно совершенствоваться, непрерывно и максимально быстро осваивая новое. Если SOC изо дня в день действует по одним и тем же сценариям, он даже не стоит на месте, а откатывается назад, и рано или поздно это станет очевидно рынку и заказчикам.
Данную проблему можно рассмотреть на примере тематики Threat Intelligence. Казалось бы, преимущества данного инструмента сложно переоценить: информация о новых атаках, векторах и типах вредоносного ПО, безусловно, очень полезна. Но использование TI в работе SOC требует не только прямых и тяжелых инвестиций в покупку коммерческих подписок. Когда сырых данных Threat Intelligence становится много, в полный рост встает вопрос их очистки – в любой базе, и публичной, и коммерческой, есть ошибки, ложные добавления и просто «мусор». Кроме того, на большом объеме данных возникает необходимость в своевременной очистке устаревших записей, приоритизации новых и оценке внутренней «репутации» поставщика или канала информационного обмена на предмет актуальности предоставляемой информации. В Solar JSOC на этом фронте работы в режиме, близком к fulltime, трудятся 3 человека, и трудоемкость их работы только возрастает.
Поэтому для того, чтобы хотя бы удерживать свои текущие позиции, SOC должен непрерывно развиваться и выделять на это существенные экспертные ресурсы: не только собирать обратную связь от клиентов, хотя «перекрестное опыление» сценариями тоже дает хороший эффект, но и исследовать новые вектора и способы атак, обогащаться внутренней и внешней аналитикой угроз и данными Threat Intelligence, участвовать в информационных обменах и двигаться во многих других направлениях.
Владимир Дрюков, директор центра мониторинга и реагирования на кибератаки Solar JSOC компании Solar Security.
Правило 1: Репутация дороже денег.
Коммерческий SOC должен уметь концентрироваться на задаче, которую перед ним ставит заказчик. Цель SOC – не прийти с сервисом мониторинга, а найти и устранить «боль» заказчика, решить его проблему и помочь стать безопаснее. И зачастую правильный подход может отличаться от коммерчески выгодного для SOC.
Например, если у заказчика не проведена сегментация сети, можно убедить его в необходимости подключения каждого хоста к мониторингу как компенсирующей меры (и хорошо заработать на этом). В итоге SOC видит и контролирует все происходящее – казалось бы, все довольны. Но правилен ли этот подход? Позволит ли он быстро противодействовать очередной вирусной эпидемии типа WannaCry или Petya даже с полным покрытием хостов мониторингом? Скорее всего, нет. В этом случае правильнее посоветовать заказчику гораздо более полезные и экономичные работы по сегментации сети, используя для аргументации выявленные в SOC инциденты и известные сценарии атаки.
SOC не должен гнаться за маркетинговыми трендами и говорить заказчикам что-то вроде: «Вам надо срочно купить песочницу, потому что всех сейчас атакуют таргетированно!» SOC должен, исходя из своей карты инцидентов, понимать, насколько те или иные угрозы актуальны для конкретной организации. Возможно, где-то мероприятия по повышению осведомленности ряда сотрудников гораздо правильнее, эффективнее и экономичнее, чем покупка дорогого AntiAPT-решения.
Мы считаем, что для выстраивания репутации на рынке SOC всегда должен ориентироваться на интересы заказчика, даже если при этом он снизит свой объем работы и потенциальный заработок. Решение «поставить все на мониторинг» не может быть универсальным. SOC должен выстраивать баланс между милитаристскими политиками безопасности там, где это необходимо, и компенсирующими мерами там, где бизнес-задачи не приемлют подхода «все запретить», но требуют сохранения контроля за безопасностью. В каждом случае SOC должен выступать не в качестве стороннего сервиса, а в качестве инструмента аналитики, помогающего в поиске наиболее правильного и бюджетного пути среди паутины предложений, присутствующих на рынке.
Правило 2: Только индивидуальный подход
Специфика российского рынка центров мониторинга в том, что заказчики ждут от SOC не предоставления атомарно-детерминированной услуги мониторинга 10-15 базовых Use-Case или сценариев, а сервиса, который будет, насколько это возможно для внешней компании, учитывать специфику работы организации. Иными словами, заказчик хочет, чтобы центр мониторинга не просто выявлял инциденты, а интерпретировал их, исходя из знания контекста, особенностей организационной структуры и бизнес-процессов конкретной компании.
Это требование вызвано, как минимум, двумя причинами.
Первая состоит в том, что уровень базовой гигиены ИБ по России в среднем чуть ниже, чем на Западе, поэтому довольно большая доля подозрений на инциденты (около 70%) – это не атаки киберпреступников, а некорректная работа внутренних пользователей, вызванная отсутствием ИТ-специалистов, внутренних регламентов, упорядоченных процессов по работе пользователей и так далее. Для того чтобы корректно анализировать возникающие подозрения на инцидент, специалисты SOC должны оценивать не только фактическое событие, но и логичность его возникновения. Например, использование технологической учетной записи на машине ИТ-администратора, скорее всего, не является инцидентом с последствием для бизнеса компании, в то время как использование такой же записи на машине бухгалтера или финансовой службы, вероятно, говорит о компрометации учетной записи и развивающейся хакерской атаке.
Вторая причина довольно тривиальна: людей, которые могут организовать процесс реагирования и расследования на стороне клиента, очень мало. В отличие от международной практики, когда в штате у заказчика может быть огромный response team, в российских компаниях реагированием на инциденты, о которых сообщает SOC, занимаются, как правило, один-два человека. При этом в их зону ответственности входят и другие задачи.
У офицеров безопасности нет ресурсов на то, чтобы разбирать логи в консоли SIEM и восстанавливать события. Получив базовое оповещение, они должны быстро вынести вердикт, является ли событие инцидентом, и немедленно начать действовать. Если судить по той практике, с которой нам приходилось сталкиваться, в западных компаниях так бывает довольно редко. Там MSSP оперируют почти исключительно базовыми уведомлениями, отдавая приличный объем аналитики на откуп заказчику.
Вследствие этого перед российскими SOC возникает задача по поддержанию глубины анализа и понимания контекста. Она накладывает на центры мониторинга серьезные требования – во-первых, в отношении экспертизы и качества работы первой линии. Она проводит первичный разбор срабатываний, и профессионализм ее специалистов должен соответствовать не службе helpdesk, а, как минимум, уровню младших аналитиков информационной безопасности.
Вторым следствием кадровой проблемы у клиентов является то, что центр мониторинга вынужден выделять отдельные ресурсы под каждый аккаунт. В западных SOC это называется technical account manager или technical account expert. Эти люди хранят контекст инфраструктуры, процессов, технических и организационных изменений заказчика. И если на Западе это отдельная опция, которая стоит очень дорого, то в России для создания эффективного и полезного заказчику сервиса она должна предоставляться по умолчанию.
Правило 3: Без права на ошибку
Одно из важных отличий внешнего SOC от внутреннего состоит в том, что у внешнего центра мониторинга цена ошибки значительно выше.
Если инженер первой линии внутреннего SOC пропустит инцидент, его уволят. Однако в нынешней ситуации кадрового голода на рынке ИБ даже с плохими рекомендациями через некоторое время он все равно найдет новую работу. В случае с коммерческим SOC пропущенная атака – это клеймо, тем более, если это произошло по вине аналитиков или из-за некачественно разработанных сценариев. Рынок информационной безопасности в России очень узкий, и сохранить произошедшее в тайне практически невозможно, а значит, важность поддержания качества сервисов SOC возводится в абсолют.
Причем если сравнивать ИТ-аутсорсинг с ИБ-аутсорсингом, последний опять оказывается в более сложном положении. В ИТ очень легко понять, качественно ли отработал сервис-провайдер: если система «лежит», то не важно, отмечено ли срабатывание как ложное. Всем очевидно, что проблема не решена. В ИБ-аутсорсинге закрытие инцидента как ложного срабатывания – это решение аналитика. Если оно ошибочно, атака может продолжить скрытно развиваться. Поэтому вес каждого такого решения огромен, особенно если ошибочно закрытый инцидент был частью таргетированной атаки, той самой хлебной крошкой, способной привести к ее детектированию и предотвращению.
Поэтому в Solar JSOC мы применяем около четырех десятков процедур, направленных на внутренний контроль качества сервисов – начиная с совместного с заказчиком тестирования сценариев и заканчивая боевыми учениями.
Среди прочего, у нас внедрена практика case review – вторая линия ежедневно отводит определенное количество времени на то, чтобы перепроверить и верифицировать часть инцидентов, разобранных первой. Разумеется, это касается не всех инцидентов – бессмысленно просто дублировать чужую работу, да и поток событий слишком большой. В первую очередь мы обращаем внимание на инциденты высокой критичности, которые были закрыты как ложные. Цель здесь не только в выявлении возможных ошибок, но и в том, чтобы дать аналитикам первой линии рекомендации по методам разбора инцидентов. Таким образом мы снижаем вероятность нашей ошибки и повышаем качество работы первой линии.
Для SOC – как внутреннего, так и внешнего – это очень дорогая процедура, ведь верификация работы относительно недорогих специалистов первой линии осуществляется за счет очень дорогих аналитиков второй линии. Но это, наверное, единственный вариант, при котором можно контролировать огромный поток инцидентов и сохранять качество.
Правило 4: Не «предоставлять сервис», а решать проблему целиком.
SOC должен предоставлять техническую услугу полного цикла. Нельзя концентрироваться на мониторинге инцидентов и заниматься только им. Если SOC не умеет реагировать на атаки и блокировать их, не в состоянии помочь заказчику в проведении аудита или целенаправленного расследования, такой SOC всегда несколько неполноценен.
Причина проста: если на заказчика идет атака, ему нужно решать проблему немедленно, здесь и сейчас. Уже в момент инцидента заказчик должен быть во всеоружии для обороны инфраструктуры, и естественно, что он либо готов делать это своими силами, либо рассчитывает на помощь той же команды, которая выявила инцидент.
Поэтому от аналитиков SOC требуется экспертиза в областях, совершенно не связанных с базовым мониторингом. Например, когда удается по косвенным признакам зафиксировать, что заражение вредоносным ПО является частью более масштабной APT-атаки, недостаточно просто перекрыть все доступы. Как правило, разбор инцидента начинается с анализа зараженных машин (поиска артефактов, скомпрометированных данных и т.д.) и анализа вредоносного ПО в ручном режиме. Это позволяет определить функциональность и способы распространения вредоноса, чтобы совместно с заказчиком разработать эффективные способы противодействия атаке, которые обычно не видны на старте.
В момент атаки у заказчика нет времени на то, чтобы приглашать третью компанию, обладающую необходимыми компетенциями, заключать договор на проведение технической экспертизы инцидента и т.д. Не говоря о том, что в случае взаимодействия разнородных подрядчиков возникает слишком много смежных зон ответственности. В результате повышается риск того, что подрядчики эффективно выполнят задачу каждый в своем поле, но потеряют рациональное зерно в серой зоне, и это полностью уничтожит результат.
Поэтому, даже если прямо сейчас заказчик не требует услугу полного цикла, нужно понимать, что такая потребность может внезапно возникнуть. И SOC должен быть всегда готов.
Правило 5: «Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее».
Как коммерческая структура, ориентированная, прежде всего, на получение прибыли, деятельность SOC зависит от того, насколько заказчики удовлетворены уровнем сервиса.
Атаки, как и средства защиты от них, постоянно развиваются, и для того, чтобы просто продолжать мониторить все те же активности в новой среде, SOC должен постоянно совершенствоваться, непрерывно и максимально быстро осваивая новое. Если SOC изо дня в день действует по одним и тем же сценариям, он даже не стоит на месте, а откатывается назад, и рано или поздно это станет очевидно рынку и заказчикам.
Данную проблему можно рассмотреть на примере тематики Threat Intelligence. Казалось бы, преимущества данного инструмента сложно переоценить: информация о новых атаках, векторах и типах вредоносного ПО, безусловно, очень полезна. Но использование TI в работе SOC требует не только прямых и тяжелых инвестиций в покупку коммерческих подписок. Когда сырых данных Threat Intelligence становится много, в полный рост встает вопрос их очистки – в любой базе, и публичной, и коммерческой, есть ошибки, ложные добавления и просто «мусор». Кроме того, на большом объеме данных возникает необходимость в своевременной очистке устаревших записей, приоритизации новых и оценке внутренней «репутации» поставщика или канала информационного обмена на предмет актуальности предоставляемой информации. В Solar JSOC на этом фронте работы в режиме, близком к fulltime, трудятся 3 человека, и трудоемкость их работы только возрастает.
Поэтому для того, чтобы хотя бы удерживать свои текущие позиции, SOC должен непрерывно развиваться и выделять на это существенные экспертные ресурсы: не только собирать обратную связь от клиентов, хотя «перекрестное опыление» сценариями тоже дает хороший эффект, но и исследовать новые вектора и способы атак, обогащаться внутренней и внешней аналитикой угроз и данными Threat Intelligence, участвовать в информационных обменах и двигаться во многих других направлениях.
