SOT

SOT

SOAR
Security Orchestration, Automation and Response

Автоматизация реагирования на инциденты информационной безопасности при помощи динамических плейбуков с применением СЗИ, выстраиванием цепочки атаки и объектно-ориентированным подходом

NG SOAR
Next Generation SOAR

Автоматизация реагирования на инциденты ИБ со встроенной базовой корреляцией, сбором сырых событий непосредственно с СЗИ, динамическими плейбуками, выстраиванием цепочки атаки и объектно-ориентированным подходом

AM
Asset Management

Описание ИТ-ландшафта, обнаружение новых объектов в сети, категорирование активов, инвентаризации и управления жизненным циклом оборудования и ПО на АРМ и серверах организаций

VM
Vulnerability Management

Выстраивание процесса обнаружения и устранения технических уязвимостей, сбор информации с имеющихся сканеров защищённости, платформ управления обновлениями, экспертных внешних сервисов и других решений

ГосСОПКА
Государственная Система Обнаружения Предупреждения и Ликвидации Последствий Компьютерных Атак

Двустороннее взаимодействие с Национальным координационным центром по компьютерным инцидентам (НКЦКИ), а именно передача информации об инцидентах и получение оперативных уведомлений/бюллетеней от регулятора

FinCERT
Financial Computer Emergency Response Team

Двустороннее взаимодействие с Центральным Банком (ЦБ РФ, ЦБ РБ и др.), а именно передача информации об инцидентах и получение оперативных уведомлений/бюллетеней от регулятора

Напишите нам на sales@securityvision.ru или закажите демонстрацию

GRC

GRC

КИИ
Критическая Информационная Инфраструктура

Аудит и исполнение требований ФЗ-187 «О безопасности критической информационной инфраструктуры Российской Федерации» и других нормативных документов

RM
Risks Management

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

ORM
Operational Risks Management

Учёт и фиксация событий операционных рисков (СОР), мониторинг ключевых индикаторов рисков (КИР) и проведение самооценки /контроля согласно положению №716-П ЦБ РФ

CM
Compliance Management

Аудит соответствия и комплаенса различным методологиям и стандартам (проектный)

BCP
Business Continuity Plan

Автоматизация процесса обеспечения непрерывности и восстановления деятельности (ОНиВД) после наступления чрезвычайных ситуаций

Напишите нам на sales@securityvision.ru или закажите демонстрацию

Пентесты

Пентесты
05.02.2024


Руслан Рахметов, Security Vision

 

При разработке стратегии обеспечения кибербезопасности в компании нельзя недооценивать возможности и мотивацию злоумышленников: даже, казалось бы, идеально выстроенные системы защиты успешно взламываются хакерами, данные похищаются даже из физически изолированных информационных систем, а опытные и обученные сотрудники в какой-то момент могут допустить фатальную ошибку. Поэтому и при выстраивании системы управления ИБ (СУИБ) с нуля, и при внесении изменений в существующую СУИБ следует делать допущение о том, что атакующие уже некоторое время назад успешно скомпрометировали инфраструктуру, но до сих пор никак себя не проявили, а их действия остались незамеченными для систем безопасности. Например, кто может дать гарантию, что установленное когда-то давно ПО на одном из серверов не содержало в себе программную закладку, которая с определенной периодичностью обращается к некоторому интернет-серверу и получает с него команды: до определенного момента такое поведение не будет вызывать срабатывания большинства средств защиты, поскольку формально никакие вредоносные действия не выполняются. Однако, по желанию атакующих в определенный момент сервер может передать данному ПО команду на копирование или уничтожение всей информации и на сервере размещения, и на всех элементах инфраструктуры, к которым есть доступ с данного устройства.


Если такой инцидент произойдет достаточно быстро и в нерабочее время, то у хакеров будут высоки шансы на успех. Данный пример достаточно наглядный, но не самый пугающий: есть примеры, когда вредоносным ПО были заражены прошивки различных устройств, подключенных к корпоративной сети, которые в определенный момент начинали выполнять деструктивные действия или предоставляли атакующим доступ в сеть - в подобной ситуации установить причину инцидента становится значительно сложнее. Учитывая вышесказанное, в ИБ-сообществе сформировался принцип "Assumed Breach", который означает «Считайте, что вас уже взломали» - это означает, что никто не может и не должен быть на 100% уверен в безопасности защищаемой инфраструктуры, и всегда следует допускать наличие спящей угрозы, которую только предстоит выявить.


С учетом высказанного, при построении СУИБ важно переходить от реактивной, пост-инцидентной кибербезопасности, когда на инцидент реагируют только после наступления последствий, к проактивному выявлению инцидентов в целях поиска и устранения скрытых киберугроз. Такой переход можно начать с помощью внедрения процессов аналитики киберугроз (англ. Cyber Threat Intelligence) - проактивного поиска вредоносных или подозрительных действий в информационной инфраструктуре, которые не удалось выявить стандартными способами. Аналитика киберугроз, или киберразведка, базируется на анализе индикаторов компрометации (сокращенно IoC, от Indicator of Compromise) - объектов или артефактов, наличие которых с высокой долей вероятности может свидетельствовать о готовящейся, совершающейся или уже осуществленной компьютерной атаке. Классическими примерами IoC будут IP-адреса, домены, URL, значения хэш-сумм – однако, все эти признаки легко модифицируются атакующими для каждой новой атаки, поэтому они достаточно быстро устаревают и не всегда надежны.


Еще один способ работы с данными киберразведки - это анализ индикаторов атак (сокращенно IoA, от Indicator of Attack), которые представляют из себя последовательность действий и шагов, а также набор тактик, техник и процедур атакующих (сокращенно TTPs, от Tactics, Techniques, Procedures). Примеры IoA: запуск утилит и команд в определенной последовательности, необычное поведение учетных записей (создание, включение в высокопривилегированные группы с последующим удалением), изменение характера сетевой активности устройств (резкий рост ICMP или DNS трафика, например). Однако, для наиболее качественного выявления скрытых киберинцидентов следует внедрять процесс непрерывного поиска киберугроз (англ. Cyber Threat Hunting) - т.е. поиска угроз внутри сети с анализом потенциальных признаков заражений, поиском следов активности киберпреступных групп, поиском признаков заражений, анализом сообщений на профильных ИБ-ресурсах и в киберпреступной среде (на форумах, в соцсетях и мессенджерах).


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


При внедрении процесса поиска киберугроз в компании важно разработать политику Threat Hunting, в которую следует включить правила разработки и документирования гипотез (например, на основе регулярного анализа обновлений матрицы MITRE ATT&CK ответственный формирует вероятные новые способы атак и релевантные TTPs атакующих, которые будут проверяться), порядок формирования плана поиска признаков не обнаруженных иными способами атак, плана выполнения действий при успешном подтверждении разработанной гипотезы, способы улучшения процесса поиска киберугроз при завершении очередной проверки гипотезы, способы передачи полученных знаний и предложений по повышению уровня защищенности компании заинтересованным лицам. В документе также следует перечислить необходимые ресурсы (персонал, инструменты, инфраструктура) для выполнения процесса поиска киберугроз, определить ожидаемые результаты и формы отчетности, способы передачи обнаруженных угроз команде реагирования, закрепить полномочия ответственных и исполнителей, а затем согласовать разработанную политику у руководителя структурного подразделения. Важно иметь в виду, что поиск киберугроз не может заменить общий процесс управления киберинцидентами, однако может послужить хорошим к нему дополнением, давая возможность закрыть «белые пятна» при выявлении инцидентов ИБ. Кроме того, для успешной реализации процесса Threat Hunting требуется глубокое понимание бизнес-процессов компании для достоверного обнаружения аномалий и отклонений в нормальном поведении систем и пользователей, взаимодействие с ИТ и ИБ-департаментом или SOC-центром для обмена знаниями, опытом, инструментами и полученной информацией, а также проведение регулярного анализа обработанных инцидентов ИБ, релевантных данных киберразведки, информации из матрицы MITRE ATT&CK и других источников об актуальных TTPs хакеров. В заключении отметим, что процесс поиска киберугроз является достаточно сложным и дорогостоящим и может оправдать вложения в него и принести существенную пользу тем компаниям, у которых высока зрелость других процессов ИБ - в противном случае больше пользы принесут инвестиции в повышение базового уровня киберзащищенности компании.


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


При проведении аудитов важно определиться с нормативным обеспечением - это может быть политика компании в области проведения аудитов ИБ, в которой прописаны цели, порядок проведения аудита, роли и обязанности ответственных, формы отчетности, методы устранения выявленных недостатков и способы обработки полученных результатов для улучшения СУИБ в компании. Важно проводить плановые внутренние аудиты по сформированному плану, в котором могут быть прописаны основные аспекты работ: проверка основных внутренних нормативных документов по ИБ (политики, регламенты, инструкции), проверка реализации задокументированных положений на практике (настройки и результаты работы СЗИ, инфраструктурных компонентов), анализ отчетности (отчеты по закрытым инцидентам ИБ, перечень проведенных проверок и тренингов, отчеты по показателям работы ИБ-департамента). В качестве формы проверки могут использоваться чек-листы с перечнем вопросов, на которые ответственные дают исчерпывающие ответы, подкрепляя их отчетами и выгрузками из ИБ-систем. В случае проведения аудитов на соответствие применимым требованиям проверку проводит, как правило, внешняя организация - это требуется, например, для получения сертификата соответствия требованиям стандарта PCI DSS или стандартов серии ISO 27000, а также для понимания топ-менеджментом того, насколько компания соответствует законодательству в области защиты информации. В случае проведения добровольных (необязательных) аудитов ИБ проверяющие могут дополнительно выдавать технические рекомендации по устранению выявленных недостатков, которые целесообразно оперативно отрабатывать и затем повторять проверку. В целом, можно заключить, что аудит ИБ - это проверка состояния ИБ компании в лабораторных, «тепличных» условиях: проверяются организационно-распорядительные документы, настройки СЗИ, отчеты о выполненных работах, закрытых инцидентах и устраненных киберугрозах, а также качество работы департамента ИБ.


Для того, чтобы выполнить проверку состояния ИБ компании в реальных, «боевых» условиях, можно воспользоваться услугой проведения тестирования на проникновение (пентест, от английского penetration test, сокращенно pentest). Пентесты проводятся независимыми ИБ-экспертами (пентестерами), которые имитируют действия атакующих для обнаружения слабых мест в киберзащите компании. По сути, пентест - это проведение контролируемой кибератаки с целью повышения общего уровня защищенности компании. Пентесты проводятся методами черного, серого и белого ящиков:


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

  • Gray-box пентест означает, что пентестеры заранее получают ограниченную информацию о проверяемой инфраструктуре, которая дает им ограниченное представление о возможных способах атаки;

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


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


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


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

Аудит информационной безопасности Threat Hunting Пентесты

Рекомендуем

Нормативные документы по ИБ. Часть 9. Обзор российского законодательства в области защиты критической информационной инфраструктуры - продолжение
Нормативные документы по ИБ. Часть 9. Обзор российского законодательства в области защиты критической информационной инфраструктуры - продолжение
Автоматизация безопасности с разнообразием матриц MITRE
Автоматизация безопасности с разнообразием матриц MITRE
Динамический анализ исходного кода
Динамический анализ исходного кода
Статический анализ исходного кода
Статический анализ исходного кода
Искусство следопыта в корпоративной инфраструктуре
Искусство следопыта в корпоративной инфраструктуре
Нормативные документы по ИБ. Часть 2. Стандарты ГОСТ Р 57580.1-2017 и ГОСТ Р 57580.2-2018
Нормативные документы по ИБ. Часть 2. Стандарты ГОСТ Р 57580.1-2017 и ГОСТ Р 57580.2-2018
Практика ИБ. Централизованный сбор логов с Windows-устройств
Практика ИБ. Централизованный сбор логов с Windows-устройств
Практика ИБ. Политики аудита безопасности Windows
Практика ИБ. Политики аудита безопасности Windows
«Фишки» Security Vision: навигация и поиск
«Фишки» Security Vision: навигация и поиск
Нормативные документы по ИБ. Часть 1. Стандарты ГОСТ Р 57580.1-2017 и ГОСТ Р 57580.2-2018
Нормативные документы по ИБ. Часть 1. Стандарты ГОСТ Р 57580.1-2017 и ГОСТ Р 57580.2-2018
Как научиться выстраивать килчейн
Как научиться выстраивать килчейн
Тестирование на проникновение
Тестирование на проникновение

Рекомендуем

Нормативные документы по ИБ. Часть 9. Обзор российского законодательства в области защиты критической информационной инфраструктуры - продолжение
Нормативные документы по ИБ. Часть 9. Обзор российского законодательства в области защиты критической информационной инфраструктуры - продолжение
Автоматизация безопасности с разнообразием матриц MITRE
Автоматизация безопасности с разнообразием матриц MITRE
Динамический анализ исходного кода
Динамический анализ исходного кода
Статический анализ исходного кода
Статический анализ исходного кода
Искусство следопыта в корпоративной инфраструктуре
Искусство следопыта в корпоративной инфраструктуре
Нормативные документы по ИБ. Часть 2. Стандарты ГОСТ Р 57580.1-2017 и ГОСТ Р 57580.2-2018
Нормативные документы по ИБ. Часть 2. Стандарты ГОСТ Р 57580.1-2017 и ГОСТ Р 57580.2-2018
Практика ИБ. Централизованный сбор логов с Windows-устройств
Практика ИБ. Централизованный сбор логов с Windows-устройств
Практика ИБ. Политики аудита безопасности Windows
Практика ИБ. Политики аудита безопасности Windows
«Фишки» Security Vision: навигация и поиск
«Фишки» Security Vision: навигация и поиск
Нормативные документы по ИБ. Часть 1. Стандарты ГОСТ Р 57580.1-2017 и ГОСТ Р 57580.2-2018
Нормативные документы по ИБ. Часть 1. Стандарты ГОСТ Р 57580.1-2017 и ГОСТ Р 57580.2-2018
Как научиться выстраивать килчейн
Как научиться выстраивать килчейн
Тестирование на проникновение
Тестирование на проникновение

Похожие статьи

Как научиться выстраивать килчейн
Как научиться выстраивать килчейн
Нормативные документы по ИБ. Часть 8. Обзор российского законодательства в области защиты критической информационной инфраструктуры
Нормативные документы по ИБ. Часть 8. Обзор российского законодательства в области защиты критической информационной инфраструктуры
Принципы информационной безопасности
Принципы информационной безопасности
Что за зверь Security Champion?
Что за зверь Security Champion?
IoCs / Индикаторы компрометации / Indicators of Compromise
IoCs / Индикаторы компрометации / Indicators of Compromise
Защита критической информационной инфраструктуры (конспект лекции)
Защита критической информационной инфраструктуры (конспект лекции)
Нормативные документы по ИБ. Часть 1. Стандарты ГОСТ Р 57580.1-2017 и ГОСТ Р 57580.2-2018
Нормативные документы по ИБ. Часть 1. Стандарты ГОСТ Р 57580.1-2017 и ГОСТ Р 57580.2-2018
Обзор Security Vision 3.4 — российской платформы SGRC
Обзор Security Vision 3.4 — российской платформы SGRC
Практика ИБ. Централизованный сбор логов с Windows-устройств
Практика ИБ. Централизованный сбор логов с Windows-устройств

Похожие статьи

Как научиться выстраивать килчейн
Как научиться выстраивать килчейн
Нормативные документы по ИБ. Часть 8. Обзор российского законодательства в области защиты критической информационной инфраструктуры
Нормативные документы по ИБ. Часть 8. Обзор российского законодательства в области защиты критической информационной инфраструктуры
Принципы информационной безопасности
Принципы информационной безопасности
Что за зверь Security Champion?
Что за зверь Security Champion?
IoCs / Индикаторы компрометации / Indicators of Compromise
IoCs / Индикаторы компрометации / Indicators of Compromise
Защита критической информационной инфраструктуры (конспект лекции)
Защита критической информационной инфраструктуры (конспект лекции)
Нормативные документы по ИБ. Часть 1. Стандарты ГОСТ Р 57580.1-2017 и ГОСТ Р 57580.2-2018
Нормативные документы по ИБ. Часть 1. Стандарты ГОСТ Р 57580.1-2017 и ГОСТ Р 57580.2-2018
Обзор Security Vision 3.4 — российской платформы SGRC
Обзор Security Vision 3.4 — российской платформы SGRC
Практика ИБ. Централизованный сбор логов с Windows-устройств
Практика ИБ. Централизованный сбор логов с Windows-устройств