Сегодня мы поговорим о Security Operations Center (SOC) со стороны людей, которые не создают и настраивают его, а проверяют, как это сделали другие. Под проверку попадает эффективность работы SOC, построенного для вашей компании самостоятельно или кем-то со стороны. Проверка дает ответ на вопрос “Выполняет ли SOC поставленные перед ним задачи или нет, и насколько он эффективен?”. Ведь наличие SOC не говорит о том, что он работает как надо и вы в курсе любых возможных инцидентов и других проблем безопасности. Мы расскажем о своем опыте проверки SOC в разных компаниях в рамках наших проектов.
Тем, кто уже знает что такое SOC и с чем его пьют, предлагаем сразу перейти ко второй части статьи. Остальным предлагаем прочитать статью целиком.
Защита информационных систем выходит на первое место практически в любой индустрии. Любой несанкционированный доступ к информации может привести к серьезным проблемам для компании.
Информационная система любой, даже самой маленькой компании, сложносоставная, и все её части должны защищаться по одному и тому же принципу — сначала организационные, затем превентивные меры, потом средства наблюдения, детектирующие аномалии, и инструменты реагирования. На последнем по порядку, но не по значимости, этапе борьбы с угрозами стоят люди, хотя случается, что проблему безопасности можно решить не привлекая людей, например путем автоматической блокировки портов или отключения машины от общей сети. Инструменты, используемые для защиты каждого из компонентов системы, могут быть разными от компании к компании, но прослеживается общая тенденция — постепенно компании, независимо от их размера, приходят к идее внедрения SOC — Security Operation Center.
Для этого есть несколько причин:
SOC — это инфраструктура со множеством взаимосвязанных компонентов, его основа — SIEM (Security information and event management). SIEM — это система сбора, нормализации и корреляции данных, которая собирает логи с веб-серверов, хостовых машин и других инфраструктурных компонентов, а также со средств защиты информации, установленных на устройствах сети организации, коррелирует и обрабатывает их, чтобы привести в нормализованный вид. Это и есть основная задача SIEM — привести к единому формату огромное количество логов от разных источников для удобства обнаружения взаимосвязей между ними. Это нужно для ещё одной составляющей SOC — аналитиков SOC, которые глядя на огромные списки логов из SIEM, должны на какие-то из событий реагировать самостоятельно или же передавать их в работу специалистам по безопасности.
Не бывает двух одинаковых SOC-ов потому, что его настройка индивидуальна для каждой организации. Основные этапы создания SOC следующие:
Даже после того, как всё будет определено, установлено и настроено, никто не гарантирует того, что теперь SOC работает так, как вам этого хотелось бы или как показано на красивых презентациях у разработчиков SIEM. Фундаментальная проблема использования любых средств защиты в том, что практически никто не знает насколько эффективно они работают. Важно не только установить и запустить их, сколько удостовериться в том, что принятые меры эффективны. Также крайне важен уровень зрелости компании в вопросах безопасности.
Так как SOC — сложная и многосоставная структура, важно понимать, что на каждом из перечисленных этапов его создания что-то может пойти не так. А это с большой вероятностью повлияет на общую защищенность системы и эффективность работы самого SOC-а.
Начнем с того, что что-то может пойти не так, даже при малейших изменениях в инфраструктуре организации. А они происходят достаточно часто — кто-то увольняется, приходят новые люди, что-то ломается, происходит обновление техники и программного обеспечения и многое другое. В таком случае настройки СЗИ и правила корреляции должны быть оперативно изменены, но часто об этом забывают, а когда вспоминают, оказывается слишком поздно.
Следующая часть SOC, где могут возникнуть ошибки — средства защиты, с которых информация попадает в SIEM, могут быть настроены неверно и пропускать действия, направленные на систему извне. А если действие атакующего не будет обнаружено ни одним из имеющихся СЗИ, то оно не попадет в логи и не окажется в SIEM, и скорее всего служба безопасности узнает о нем не скоро.
Проблема может оказаться в SIEM-е. Он может работать не так, как хотелось бы вам. События, попадающие в него, могут коррелироваться неверно из-за ошибок в правилах корреляции, что приведет к пропуску действий атакующего. Здесь стоит уточнить, что не всегда достаточно данных от одного источника. Бывают случаи, когда для определения инцидентов безопасности необходимо объединить данные сразу из нескольких источников, чтобы получить цельную картину происходящего в системе. Но может оказаться, что правило настроено так, что для определения случившегося инцидента может не хватить данных от одного источника, которые и указывают на факт его свершения. Т.е. не сложится паззл, состоящий из данных от нескольких источников. Также правила для каких-то событий безопасности могут отсутствовать вовсе.
На этапе корреляции событий в SIEM может возникнуть сразу несколько проблем. Одной из них может быть задержка передачи событий от некоторых источников, что может помешать успешной корреляции.
Правила отнесения событий к инцидентам в SIEM могут быть настроены неверно сами по себе или же они могут отсутствовать для каких-либо событий. Также обычно инциденты имеют уровень важности, неверное определение которого может привести к большим проблемам.
Люди, работающие с SIEM, чьей задачей является реагирование на инциденты безопасности, также могут быть причиной пропущенных атак и последующих проблем с информационной безопасностью. Они могут пропускать какие-то сигналы от SIEM-а или неправильно реагировать на действия атакующего в силу разных причин. Есть также проблема в том, что люди рано или поздно увольняются, а новым сотрудникам требуется время на обучение.
Учитывая вышеперечисленное, тестирование SOC для проверки эффективности работы чрезвычайно важно как на этапе внедрения SOC, так и по прошествии времени. Так как специалисты нашей компании уже имеют опыт в этом деле, мы решили описать основные моменты и нюансы.
Тестирование SOC в компании может быть проведено по нескольким сценариям. Расскажем о тех, которые нам кажутся наиболее эффективными.
К задачам тестирования SOC относится проверка защищенности путем воспроизведения типовых сценариев поведения, присущих злоумышленникам. К ним можно отнести:
Подобный перечень проверок можно продолжать достаточно долго. Наиболее важно руководствоваться реальными потребностями клиента и реализованными у него проверками.
Тестирование SOC может проводиться двумя путями:
Подробнее о каждом из них.
В первую очередь следует проверить работу SOC в режиме blackbox-тестирования. Его суть в том, что сотрудники отдела SOC не знают о проводимых работах и реагируют на все события в боевом режиме. Аудиторам/пентестерам предоставляется доступ в корпоративную сеть, а также могут быть даны учетные записи от наиболее широко используемых в компании сервисов.
Такая модель предполагает, что не располагающий никакой дополнительной информацией злоумышленник неизвестным путем получил доступ к сети компании и какой-либо из имеющихся в ней учетной записи. Действия такого злоумышленника характеризуются высокой степенью хаотичности и “шумности”. Он активно сканирует сеть, перебирает директории, учётные записи, рассылает на все порты все известные ему эксплойты, забрасывает веб-приложения XSS, SQLi, RCE, SSTI, NoSQLi, etc векторами. В общем, ведёт себя крайне агрессивно в надежде взломать хоть что-то. Аудиторы во время проверки имитируют действия такого злоумышленника, поддерживая заданный градус безумия, но готовые остановиться в любой момент по просьбе службы SOC или при возникновении технических неполадок. Кстати, неожиданным и приятным результатом может стать обнаружение уязвимых сервисов и приложений в инфраструктуре компании.
Другая модель тестирования — whitebox. В этом случае отрабатывается сценарий недобросовестного сотрудника. Обычно к этому моменту аудиторы хорошо ориентируются в сети заказчика и могут играть такую роль. Поведение потенциального злоумышленника в данном случае можно характеризовать высокой избирательностью как средств, так и целей атаки. Тут уже можно провести некоторые параллели с APT-атаками. Аудиторы атакуют только наиболее слабые на их взгляд места и используют продуманные и узконаправленные вектора атак, а также пытаются получить доступ к чувствительной информации вне зоны компетенции роли их учётной записи с последующей попыткой выкачивания её за пределы защищенного периметра. Все действия они стараются совершать таким образом, чтобы остаться незамеченными службой безопасности компании.
После тестирования обычно начинается разбор и сопоставление результатов, полученных аудиторами, и инцидентов, обнаруженных сотрудниками SOC. Данный этап позволит получить общую картину эффективности текущей работы SOC и может служить отправной точкой для всех дальнейших планов по расширению имеющихся проверок и подходов.
Наконец, когда представление о защищенности тестируемой инфраструктуры составлено, аудиторы могут с помощью whitebox тестирования проанализировать имеющийся набор правил, а также события, на основе которых, эти правила сформированы. Такое взаимодействие между аудиторами и аналитиками SOC может оказаться очень продуктивным, и в ходе консультации поможет обнаружить логические ошибки и упущения в настройке компонентов SOC. Корнем их обычно является недостаточное понимание аналитиками SOC, как же может действовать реальный злоумышленник и какие трюки он может совершать на системах.
Наиболее критичные сервисы, заслуживающие более пристального внимания, тестируются отдельно с использованием двух моделей нарушителей.
Подобный комплекс мероприятий позволяет:
За помощь в написании статьи выражаю благодарность Денису _ttffdd_ Рыбину и Ивану Чалыкину.
Тем, кто уже знает что такое SOC и с чем его пьют, предлагаем сразу перейти ко второй части статьи. Остальным предлагаем прочитать статью целиком.
Часть 1. Немного о SOC для начинающих
Защита информационных систем выходит на первое место практически в любой индустрии. Любой несанкционированный доступ к информации может привести к серьезным проблемам для компании.
Информационная система любой, даже самой маленькой компании, сложносоставная, и все её части должны защищаться по одному и тому же принципу — сначала организационные, затем превентивные меры, потом средства наблюдения, детектирующие аномалии, и инструменты реагирования. На последнем по порядку, но не по значимости, этапе борьбы с угрозами стоят люди, хотя случается, что проблему безопасности можно решить не привлекая людей, например путем автоматической блокировки портов или отключения машины от общей сети. Инструменты, используемые для защиты каждого из компонентов системы, могут быть разными от компании к компании, но прослеживается общая тенденция — постепенно компании, независимо от их размера, приходят к идее внедрения SOC — Security Operation Center.
Для этого есть несколько причин:
- использование SOC сокращает затраты на ручное отслеживание инцидентов безопасности;
- события системы собираются в одном месте, меньше шансов, что какое-то из них потеряется;
- SOC позволяет настраивать правила отнесения событий к инцидентам безопасности в соответствии с нуждами и особенностями работы конкретной компании;
- SOC позволяет минимизировать время обнаружения и реагирования на инциденты безопасности, тем самым уменьшая потенциальный ущерб компании;
- логи, попадающие в SOC, приводятся к единому виду, что позволяет эффективно расследовать инциденты безопасности, даже в случае попытки заметания злоумышленником следов своего присутствия в системе.
SOC — это инфраструктура со множеством взаимосвязанных компонентов, его основа — SIEM (Security information and event management). SIEM — это система сбора, нормализации и корреляции данных, которая собирает логи с веб-серверов, хостовых машин и других инфраструктурных компонентов, а также со средств защиты информации, установленных на устройствах сети организации, коррелирует и обрабатывает их, чтобы привести в нормализованный вид. Это и есть основная задача SIEM — привести к единому формату огромное количество логов от разных источников для удобства обнаружения взаимосвязей между ними. Это нужно для ещё одной составляющей SOC — аналитиков SOC, которые глядя на огромные списки логов из SIEM, должны на какие-то из событий реагировать самостоятельно или же передавать их в работу специалистам по безопасности.
Не бывает двух одинаковых SOC-ов потому, что его настройка индивидуальна для каждой организации. Основные этапы создания SOC следующие:
- определение защищаемой инфраструктуры, как на организационном, так и на техническом уровне;
- установка всех возможных/необходимых средств защиты и мониторинга, а также их настройка;
- выбор подходящей SIEM и её настройка в зависимости от особенностей компании;
- создание правил корреляции событий;
- подбор команды SOC — людей, работа которых будет заключаться в мониторинге событий и внесении исправлений в правила корреляции, а также в реагировании на события безопасности.
Даже после того, как всё будет определено, установлено и настроено, никто не гарантирует того, что теперь SOC работает так, как вам этого хотелось бы или как показано на красивых презентациях у разработчиков SIEM. Фундаментальная проблема использования любых средств защиты в том, что практически никто не знает насколько эффективно они работают. Важно не только установить и запустить их, сколько удостовериться в том, что принятые меры эффективны. Также крайне важен уровень зрелости компании в вопросах безопасности.
Так как SOC — сложная и многосоставная структура, важно понимать, что на каждом из перечисленных этапов его создания что-то может пойти не так. А это с большой вероятностью повлияет на общую защищенность системы и эффективность работы самого SOC-а.
Часть 2. Что же произойдет, если не проверять эффективность работы SOC-а, а оставить всё как есть?
Начнем с того, что что-то может пойти не так, даже при малейших изменениях в инфраструктуре организации. А они происходят достаточно часто — кто-то увольняется, приходят новые люди, что-то ломается, происходит обновление техники и программного обеспечения и многое другое. В таком случае настройки СЗИ и правила корреляции должны быть оперативно изменены, но часто об этом забывают, а когда вспоминают, оказывается слишком поздно.
Следующая часть SOC, где могут возникнуть ошибки — средства защиты, с которых информация попадает в SIEM, могут быть настроены неверно и пропускать действия, направленные на систему извне. А если действие атакующего не будет обнаружено ни одним из имеющихся СЗИ, то оно не попадет в логи и не окажется в SIEM, и скорее всего служба безопасности узнает о нем не скоро.
Проблема может оказаться в SIEM-е. Он может работать не так, как хотелось бы вам. События, попадающие в него, могут коррелироваться неверно из-за ошибок в правилах корреляции, что приведет к пропуску действий атакующего. Здесь стоит уточнить, что не всегда достаточно данных от одного источника. Бывают случаи, когда для определения инцидентов безопасности необходимо объединить данные сразу из нескольких источников, чтобы получить цельную картину происходящего в системе. Но может оказаться, что правило настроено так, что для определения случившегося инцидента может не хватить данных от одного источника, которые и указывают на факт его свершения. Т.е. не сложится паззл, состоящий из данных от нескольких источников. Также правила для каких-то событий безопасности могут отсутствовать вовсе.
На этапе корреляции событий в SIEM может возникнуть сразу несколько проблем. Одной из них может быть задержка передачи событий от некоторых источников, что может помешать успешной корреляции.
Правила отнесения событий к инцидентам в SIEM могут быть настроены неверно сами по себе или же они могут отсутствовать для каких-либо событий. Также обычно инциденты имеют уровень важности, неверное определение которого может привести к большим проблемам.
Люди, работающие с SIEM, чьей задачей является реагирование на инциденты безопасности, также могут быть причиной пропущенных атак и последующих проблем с информационной безопасностью. Они могут пропускать какие-то сигналы от SIEM-а или неправильно реагировать на действия атакующего в силу разных причин. Есть также проблема в том, что люди рано или поздно увольняются, а новым сотрудникам требуется время на обучение.
Учитывая вышеперечисленное, тестирование SOC для проверки эффективности работы чрезвычайно важно как на этапе внедрения SOC, так и по прошествии времени. Так как специалисты нашей компании уже имеют опыт в этом деле, мы решили описать основные моменты и нюансы.
Часть 3. Проверка эффективности SOC
Тестирование SOC в компании может быть проведено по нескольким сценариям. Расскажем о тех, которые нам кажутся наиболее эффективными.
К задачам тестирования SOC относится проверка защищенности путем воспроизведения типовых сценариев поведения, присущих злоумышленникам. К ним можно отнести:
- перебор учетных записей других пользователей с помощью брутфорса, а также используя технику password spraying. Использование этой техники возможно при наличии доступа к списку существующих в системе учетных записей, например, через адресную книгу почтового клиента. По нашему опыту, зачастую про технику password spraying забывают и, соответственно, такую атаку с трудом обнаруживают правила SOC;
- выкачивание данных с веб-ресурса, будь-то корпоративная вики или менеджер задач. Такая атака может быть осуществлена том числе с использованием различных web crawling и directory brute механизмов. Отдельно аудиторы уделяют внимание API сервисам и их возможностям;
- многократные попытки обращения к ресурсам или проектам, находящимся вне области компетенций роли, от имени которой работает злоумышленник. Простой пример — попытки авторизации пользователя из группы разработчиков на ресурсах сетевых администраторов и службы безопасности;
- попытки скачивания большого объема информации из корпоративной сети с использованием техник обхода фильтрации передаваемых данных. Речь идет в первую очередь о dns и icmp туннелях, но иногда имеет смысл начать с более простых проверок, например, попробовать поискать открытый наружу tcp или udp порт, а также дополнительный шлюз (gateway). Для поиска шлюзов, кстати, есть доработанная реализация одного популярного инструмента от одного из сотрудников.
Подобный перечень проверок можно продолжать достаточно долго. Наиболее важно руководствоваться реальными потребностями клиента и реализованными у него проверками.
Тестирование SOC может проводиться двумя путями:
- вслепую — blackbox;
- со знанием инфраструктуры — whitebox.
Подробнее о каждом из них.
В первую очередь следует проверить работу SOC в режиме blackbox-тестирования. Его суть в том, что сотрудники отдела SOC не знают о проводимых работах и реагируют на все события в боевом режиме. Аудиторам/пентестерам предоставляется доступ в корпоративную сеть, а также могут быть даны учетные записи от наиболее широко используемых в компании сервисов.
Такая модель предполагает, что не располагающий никакой дополнительной информацией злоумышленник неизвестным путем получил доступ к сети компании и какой-либо из имеющихся в ней учетной записи. Действия такого злоумышленника характеризуются высокой степенью хаотичности и “шумности”. Он активно сканирует сеть, перебирает директории, учётные записи, рассылает на все порты все известные ему эксплойты, забрасывает веб-приложения XSS, SQLi, RCE, SSTI, NoSQLi, etc векторами. В общем, ведёт себя крайне агрессивно в надежде взломать хоть что-то. Аудиторы во время проверки имитируют действия такого злоумышленника, поддерживая заданный градус безумия, но готовые остановиться в любой момент по просьбе службы SOC или при возникновении технических неполадок. Кстати, неожиданным и приятным результатом может стать обнаружение уязвимых сервисов и приложений в инфраструктуре компании.
Другая модель тестирования — whitebox. В этом случае отрабатывается сценарий недобросовестного сотрудника. Обычно к этому моменту аудиторы хорошо ориентируются в сети заказчика и могут играть такую роль. Поведение потенциального злоумышленника в данном случае можно характеризовать высокой избирательностью как средств, так и целей атаки. Тут уже можно провести некоторые параллели с APT-атаками. Аудиторы атакуют только наиболее слабые на их взгляд места и используют продуманные и узконаправленные вектора атак, а также пытаются получить доступ к чувствительной информации вне зоны компетенции роли их учётной записи с последующей попыткой выкачивания её за пределы защищенного периметра. Все действия они стараются совершать таким образом, чтобы остаться незамеченными службой безопасности компании.
После тестирования обычно начинается разбор и сопоставление результатов, полученных аудиторами, и инцидентов, обнаруженных сотрудниками SOC. Данный этап позволит получить общую картину эффективности текущей работы SOC и может служить отправной точкой для всех дальнейших планов по расширению имеющихся проверок и подходов.
Наконец, когда представление о защищенности тестируемой инфраструктуры составлено, аудиторы могут с помощью whitebox тестирования проанализировать имеющийся набор правил, а также события, на основе которых, эти правила сформированы. Такое взаимодействие между аудиторами и аналитиками SOC может оказаться очень продуктивным, и в ходе консультации поможет обнаружить логические ошибки и упущения в настройке компонентов SOC. Корнем их обычно является недостаточное понимание аналитиками SOC, как же может действовать реальный злоумышленник и какие трюки он может совершать на системах.
Заключение
Наиболее критичные сервисы, заслуживающие более пристального внимания, тестируются отдельно с использованием двух моделей нарушителей.
Подобный комплекс мероприятий позволяет:
- значительно повысить осведомленность руководителей, отвечающих за безопасность о состоянии своей инфраструктуры;
- провести боевые учения для отдела SOC с возможностью получить консультацию от специалистов в области проведения аудита;
- обнаружить и исправить имеющиеся ошибки в работе SOC, а также в целом повысить защищенность компании.
За помощь в написании статьи выражаю благодарность Денису _ttffdd_ Рыбину и Ивану Чалыкину.
