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

Сканирование на уязвимости

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

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

После выявления уязвимостей организации устраняют их, внося изменения в программное обеспечение или систему. Эти изменения называются патчами.

Сканирование на уязвимости можно разделить на несколько видов, но основные категории следующие:

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

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

Инструменты для сканирования на уязвимости

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

Nessus

Nessus был разработан как проект с открытым исходным кодом в 1998 году. Позже, в 2005 году, он был приобретён компанией Tenable и стал проприетарным программным обеспечением. Nessus предоставляет широкие возможности для сканирования на уязвимости и широко используется крупными предприятиями.

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

Qualys

Qualys был разработан в 1999 году как решение для управления уязвимостями на основе подписки. Помимо непрерывного сканирования на уязвимости, он предоставляет проверки на соответствие требованиям и управление активами.

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

Nexpose

Nexpose был разработан компанией Rapid7 в 2005 году как решение для управления уязвимостями на основе подписки. Он непрерывно обнаруживает новые активы в сети и выполняет сканирование на уязвимости для них.

Платформа присваивает оценку уровня риска уязвимостей в зависимости от стоимости актива и влияния уязвимости. Nexpose также предоставляет проверки на соответствие различным стандартам. Инструмент поддерживает как локальное развертывание (on-premises), так и гибридные режимы (облачное и локальное развертывание).

OpenVAS (Open Vulnerability Assessment System)

OpenVAS — это решение для оценки уязвимостей с открытым исходным кодом, разработанное компанией Greenbone Security. Оно предоставляет базовые функции, сканируя известные уязвимости на основе своей базы данных.

Хотя OpenVAS менее функционален по сравнению с коммерческими инструментами, он предоставляет представление о возможностях полноценного сканера уязвимостей. Этот инструмент особенно полезен для небольших организаций и индивидуальных систем.

CVE

CVE расшифровывается как Common Vulnerabilities and Exposures (Общие уязвимости и экспозиции). Представьте CVE как уникальный номер для каждой вашей заявки или жалобы. Если по какому-либо вопросу появляются обновления, вы можете легко отслеживать их с помощью уникального CVE-номера.

Если перейти от примера службы поддержки, CVE-номер представляет собой уникальный идентификатор, присвоенный уязвимости. Эта система была разработана корпорацией MITRE. Каждый раз, когда обнаруживается новая уязвимость в каком-либо программном обеспечении, ей присваивается уникальный CVE-номер, который используется как ссылка, и информация о ней публикуется онлайн в базе данных CVE.

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

Пример CVE-номера, присвоенного уязвимости, можно увидеть на изображении ниже:

• Префикс CVE: Каждый номер CVE начинается с префикса «CVE».
• Год: Вторая часть каждого номера CVE содержит год, когда уязвимость была обнаружена (например, 2024).
• Произвольные цифры: Последняя часть номера CVE содержит четыре или более произвольных цифр (например, 9374).

CVSS (Common Vulnerability Scoring System) — это Общая Система Оценки Уязвимостей. Если снова обратиться к примеру службы технической поддержки, вы всегда должны приоритизировать жалобы. Самый эффективный способ сделать это — учитывать уровень их критичности. Представьте, что каждая жалоба регистрируется с оценкой от 0 до 10, где более высокий балл указывает на более серьёзную проблему. Это бы решило задачу выделения критичных обращений. Именно такая система называется CVSS.

В мире информационных технологий каждая уязвимость, так же как и её уникальный идентификатор CVE, имеет CVSS-оценку, которая указывает на её степень серьёзности. CVSS-балл рассчитывается на основе множества факторов, включая её воздействие, лёгкость эксплуатации и другие параметры. Уровни критичности согласно оценкам CVSS можно увидеть в таблице ниже:

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

Цели обучения
Некоторые из целей обучения, рассматриваемых в данном курсе:

• Что такое SIEM и как он работает?
• Зачем нужен SIEM?
• Что такое видимость сети?
• Что представляют собой источники логов и как происходит их сбор?
• Каковы основные возможности, которые предоставляет SIEM?

Видимость сети с помощью SIEM

Прежде чем объяснять важность SIEM, давайте сначала разберемся, почему так критично иметь хорошую видимость всех действий в сети. На изображении ниже показан пример простой сети, состоящей из нескольких конечных точек на базе Linux и Windows, одного сервера данных и одного веб-сайта. Каждый компонент взаимодействует с другими или получает доступ к интернету через маршрутизатор.

Как мы знаем, каждый компонент сети может иметь один или несколько источников журналов, которые создают различные логи. Например, для улучшения видимости на Windows-устройствах можно настроить Sysmon вместе с журналами событий Windows. Мы можем разделить источники журналов в сети на две логические части:

1. Источники журналов, ориентированные на хост

Это источники журналов, которые фиксируют события, произошедшие на хосте или связанные с ним. Некоторые источники, генерирующие журналы, ориентированные на хост, включают журналы событий Windows, Sysmon, Osquery и т.д. Примеры таких журналов:

• Доступ пользователя к файлу
• Попытка аутентификации пользователя
• Активность выполнения процесса
• Добавление, изменение или удаление ключа или значения в реестре
• Выполнение PowerShell-скрипта

1. Источники журналов, ориентированные на сеть

Сетевые журналы создаются, когда хосты взаимодействуют друг с другом или получают доступ к интернету для посещения веб-сайта. Некоторые сетевые протоколы включают SSH, VPN, HTTP/s, FTP и т.д. Примеры таких событий:

• Подключение по SSH
• Доступ к файлу через FTP
• Веб-трафик
• Доступ пользователя к корпоративным ресурсам через VPN
• Активность сетевого обмена файлами

Важность SIEM

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

• Сбор логов в режиме реального времени
• Оповещения о подозрительной активности
• Круглосуточный мониторинг и видимость
• Защита от актуальных угроз за счет раннего обнаружения
• Аналитика данных и визуализация
• Возможность расследования прошлых инцидентов

Источники логов и сбор логов
Каждое устройство в сети генерирует определённые логи при выполнении каких-либо действий, например, когда пользователь посещает веб-сайт, подключается по SSH или входит в свою рабочую станцию. Некоторые распространённые устройства, используемые в сетевой среде, рассмотрены ниже:

Машины под управлением Windows

Windows фиксирует каждое событие, которое можно просмотреть через утилиту "Просмотр событий" (Event Viewer). Каждому типу активности присваивается уникальный идентификатор (ID), что упрощает анализ и отслеживание событий. Чтобы просмотреть события в среде Windows, введите "Просмотр событий" в строке поиска. Это откроет инструмент, в котором хранятся и отображаются различные логи, как показано ниже. Логи со всех оконечных точек Windows пересылаются в SIEM-решение для мониторинга и повышения видимости.

Рабочие станции на Linux

Операционная система Linux сохраняет связанные логи, такие как события, ошибки, предупреждения и т.д. Эти данные затем поступают в SIEM для постоянного мониторинга. Наиболее распространённые места хранения логов в Linux включают:

• /var/log/httpd: Содержит HTTP-запросы, ответы и логи ошибок.
• /var/log/cron: События, связанные с заданиями cron, хранятся здесь.
• /var/log/auth.log и /var/log/secure: Содержат логи, связанные с аутентификацией.
• /var/log/kern: Хранят события, связанные с ядром системы.

Пример лога cron:

May 28 13:04:20 ebr crond[2843]: /usr/sbin/crond 4.4 dillon's cron daemon, started with loglevel notice  
May 28 13:04:20 ebr crond[2843]: no timestamp found (user root job sys-hourly)  
May 28 13:04:20 ebr crond[2843]: no timestamp found (user root job sys-daily)  
May 28 13:04:20 ebr crond[2843]: no timestamp found (user root job sys-weekly)  
May 28 13:04:20 ebr crond[2843]: no timestamp found (user root job sys-monthly)  
Jun 13 07:46:22 ebr crond[3592]: unable to exec /usr/sbin/sendmail: cron output for user root job sys-daily to /dev/null  

Веб-сервер

Мониторинг всех запросов и ответов, проходящих через веб-сервер, крайне важен для выявления потенциальных атак на веб-приложения. В Linux логи, связанные с Apache, обычно записываются в следующих местах:

• /var/log/apache
• /var/log/httpd

Пример логов Apache:

192.168.21.200 - - [21/March/2022:10:17:10 -0300] "GET /cgi-bin/try/ HTTP/1.0" 200 3395  
127.0.0.1 - - [21/March/2022:10:22:04 -0300] "GET / HTTP/1.0" 200 2216  

Сбор логов: Методы интеграции логов в SIEM

Все эти логи содержат ценную информацию, которая помогает выявлять проблемы безопасности. Каждое SIEM-решение имеет свои методы интеграции логов. Наиболее распространённые из них описаны ниже:

1. Agent / Forwarder:
   SIEM-решения предоставляют легковесный инструмент, называемый агентом (в Splunk используется термин "форвардер"), который устанавливается на конечной точке. Этот инструмент настраивается для захвата всех важных логов и их отправки на сервер SIEM.
2. Syslog:
   Syslog — это широко используемый протокол для сбора данных с различных систем, таких как веб-серверы, базы данных и т. д. Данные передаются в режиме реального времени на централизованный пункт назначения.
3. Manual Upload:
   Некоторые SIEM-решения, такие как Splunk, ELK и другие, позволяют пользователям загружать офлайн-данные для быстрого анализа. После загрузки данные нормализуются и становятся доступными для анализа.
4. Port-Forwarding:
   SIEM-решения могут быть настроены на прослушивание определённого порта, на который конечные точки отправляют данные. Логи затем поступают на экземпляр SIEM через указанный порт.

Пример того, как Splunk предоставляет различные методы интеграции логов, показан ниже:

Почему SIEM

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

Возможности SIEM

SIEM является важнейшим компонентом экосистемы Центра операций безопасности (SOC), как показано ниже. Работа SIEM начинается со сбора логов и анализа, соответствует ли событие или поток установленным правилам или превышает ли определённый порог.

К основным возможностям SIEM относятся:

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

Обязанности аналитика SOC

Аналитики SOC используют SIEM-решения для обеспечения лучшей видимости происходящего в сети. К их основным обязанностям относятся:

• Мониторинг и расследование инцидентов.
• Выявление ложных срабатываний (False positives).
• Настройка правил, вызывающих шум или ложные срабатывания.
• Подготовка отчётов и обеспечение соответствия нормативным требованиям.
• Выявление слепых зон в видимости сети и их устранение.

Анализ логов и оповещений

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

Дашборд

Дашборды являются ключевыми компонентами любой SIEM-системы. SIEM нормализует и обрабатывает данные, представляя их для анализа. Результаты анализа отображаются в виде полезных для действий инсайтов с помощью множества дашбордов. Каждое SIEM-решение включает стандартные дашборды и позволяет создавать пользовательские.

На дашбордах можно найти следующую информацию:

• Основные оповещения
• Системные уведомления
• Уведомления о состоянии системы
• Список неудачных попыток входа
• Количество обработанных событий
• Сработавшие правила
• Наиболее посещаемые домены

Пример стандартного дашборда в Qradar SIEM приведён ниже:

Корреляционные правила

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

• Если у пользователя зафиксировано 5 неудачных попыток входа за 10 секунд — создать оповещение о множественных неудачных попытках входа.
• Если вход выполнен успешно после нескольких неудачных попыток — создать оповещение о входе после множества попыток.
• Установить правило, создающее оповещение каждый раз, когда пользователь подключает USB-устройство (актуально, если использование USB запрещено корпоративной политикой).
• Если исходящий трафик превышает 25 МБ — создать оповещение о возможной попытке утечки данных (обычно порог зависит от корпоративной политики).

Как создаётся корреляционное правило

Для понимания работы правил рассмотрим следующие сценарии:

Сценарий 1:

Злоумышленники часто удаляют логи на этапе постэксплуатации, чтобы скрыть свои действия. Уникальный Event ID 104 фиксируется каждый раз, когда пользователь пытается удалить или очистить логи событий. Для создания правила на основе этой активности можно задать следующее условие:

Правило: Если источник логов — WinEventLog И EventID равен 104, создать оповещение: Очищены логи событий.

Сценарий 2:

После эксплуатации или эскалации привилегий злоумышленники могут использовать команды вроде whoami. Для настройки правила полезно включить следующие поля:

• Источник логов: Определяет источник, регистрирующий события.
• Event ID: Идентификатор события, связанного с выполнением процесса. Для данного случая подойдёт Event ID 4688.
• NewProcessName: Название процесса, которое стоит учитывать в правиле.

Правило: Если источник логов — WinEventLog И EventCode равен 4688 И NewProcessName содержит "whoami", создать оповещение: Обнаружено выполнение команды WHOAMI.

Корреляционные правила отслеживают значения определённых полей, чтобы сработать. Поэтому важно, чтобы лог-файлы, используемые в SIEM, были нормализованы.

Расследование оповещений

Аналитики, работающие с SIEM, большую часть времени проводят на дашбордах, которые предоставляют ключевую информацию о сети в удобном виде. После срабатывания оповещения изучаются связанные с ним события/потоки, а правило проверяется на соответствие выполненным условиям. На основании расследования аналитик определяет, является ли оповещение истинным или ложным.

Дальнейшие действия зависят от результата:

1. Ложное срабатывание: Может потребоваться настройка правила, чтобы избежать подобных ложных срабатываний в будущем.
2. Истинное срабатывание: Проводится дальнейшее расследование.
3. Связь с владельцем ресурса: Для уточнения активности.
4. Подтверждение подозрительной активности: Изоляция заражённого узла.
5. Блокировка подозрительного IP-адреса.

https://t.me/mhostcu

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

Похоже, что эти следы играют большую роль в расследованиях.

А что, если что-то произошло внутри цифрового устройства? Где найти все эти следы для дальнейшего расследования?

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

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

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

Например, вам нужно проверить успешные входы в систему за вчерашний день в определенный промежуток времени в Windows. Вместо того чтобы просматривать все логи, достаточно заглянуть в Security Logs системы, чтобы найти информацию о входах. Также существуют и другие типы логов, которые помогают в расследовании различных инцидентов. Давайте рассмотрим их.

Примечание: В зависимости от различных приложений и предоставляемых ими услуг могут существовать и другие типы логов.

Теперь, когда мы понимаем, что собой представляют эти логи и как различные их типы могут быть полезны в разных ситуациях, давайте рассмотрим, как анализировать логи и извлекать из них важную информацию. Анализ логов — это метод извлечения ценных данных из логов, включающий поиск признаков аномальной или необычной активности. Найти конкретные события или аномалии в логах невооружённым глазом невозможно. Поэтому существуют различные ручные и автоматизированные методы анализа логов. В следующих заданиях мы будем вручную проводить анализ логов Windows и логов доступа веб-сервера.

Анализ журналов событий Windows:

Как и в других операционных системах, в Windows OS фиксируется множество происходящих событий. Эти записи сохраняются в отдельных файлах логов, каждый из которых относится к определённой категории логов. Некоторые из ключевых типов логов, хранящихся в Windows OS:

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

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

Security: Это самый важный файл логов в Windows OS с точки зрения безопасности. В него записываются все действия, связанные с безопасностью, такие как аутентификация пользователей, изменения учетных записей пользователей, изменения политики безопасности и т.д.

Помимо этих, в Windows OS существует ряд других файлов логов, предназначенных для записи действий, связанных с конкретными операциями и приложениями.

В отличие от других файлов логов, которые мы изучали в предыдущих заданиях и которые не имели встроенного приложения для их просмотра, Windows OS предоставляет утилиту под названием Event Viewer, представляющую графический интерфейс для просмотра и поиска информации в этих логах.

Чтобы открыть Event Viewer, нажмите кнопку "Пуск" в Windows и введите «Event Viewer». Утилита откроется, как показано ниже. В выделенной области на скриншоте ниже отображены доступные типы логов.

Вы можете нажать «Windows Logs» в выделенной области, чтобы увидеть различные типы логов, которые мы обсуждали в начале этого задания.

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

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

Вот как выглядит журнал событий в Windows. Он содержит несколько полей. Основные поля описаны ниже:

Description: Это поле содержит подробную информацию о событии. Log Name: Название журнала указывает имя файла лога. Logged: Это поле указывает время события. Event ID: Идентификаторы событий (Event IDs) представляют собой уникальные идентификаторы для конкретных событий.

В журналах событий Windows доступно множество идентификаторов событий. Мы можем использовать их для поиска определенных действий. Например, идентификатор события 4624 уникально определяет успешный вход в систему, поэтому для расследования успешных входов достаточно искать этот идентификатор события 4624.

Ниже приведена таблица с некоторыми важными идентификаторами событий в операционной системе Windows.

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

Средство просмотра событий позволяет нам искать журналы, связанные с определенным идентификатором события, с помощью функции «Фильтровать текущий журнал». Мы можем нажать на эту функцию, чтобы применить нужный фильтр.

Когда мы нажимаем на опцию «Фильтровать текущий журнал», нам будет предложено ввести идентификаторы событий, которые мы хотим отфильтровать. На скриншоте ниже я отфильтровал событие с идентификатором 4624.

Как только я нажимаю кнопку «OK», я могу видеть все журналы с идентификатором события: 4624. Теперь я могу просматривать любой из этих журналов, дважды щелкнув на них.

Анализ логов доступа веб-сервера

Мы ежедневно взаимодействуем со многими веб-сайтами. Иногда мы просто просматриваем сайт, а иногда хотим войти в учетную запись или загрузить файл в доступное поле ввода. Все это — различные типы запросов, которые мы отправляем на сайт. Все эти запросы регистрируются сайтом и сохраняются в лог-файле на веб-сервере, который управляет этим сайтом.

Лог-файл содержит все запросы к сайту вместе с информацией о времени запроса, IP-адресе, типе запроса и URL. Ниже приведены поля, взятые из примера лога доступа веб-сервера Apache, который можно найти в каталоге: /var/log/apache2/access.log

IP-адрес: "172.16.0.1" — IP-адрес пользователя, который сделал запрос.

Временная метка: "[06/Jun/2024:13:58:44]" — время, когда запрос был отправлен на сайт.

Запрос: Подробности запроса.

Метод HTTP: "GET" — указывает сайту, какое действие нужно выполнить по запросу.

URL: "/" — запрошенный ресурс.

Код состояния: "200" — ответ от сервера. Различные числа указывают на разные результаты ответа.

User-Agent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, как Gecko) Chrome/58.0.3029.110 Safari/537.36" — информация о системе пользователя, браузере и т. д., при отправке запроса.

Мы можем выполнять ручной анализ логов с использованием некоторых командных утилит в операционной системе Linux. Вот некоторые команды, которые могут быть полезны при ручном анализе логов.

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

Большинство систем регулярно выполняют ротацию логов. Это помогает создавать отдельные лог-файлы для конкретных временных интервалов, а не хранить все записи в одном файле. Но иногда может потребоваться объединить два лог-файла. В этом случае командная утилита cat также может быть полезной. Мы можем объединить содержимое нескольких файлов в один файл, как показано ниже.

grep — это очень полезная командная утилита, которая позволяет искать строки и шаблоны в лог-файле. Например, вам может понадобиться проверить, присутствует ли определенный IP-адрес в вашем лог-файле. Вы можете сделать это с помощью следующей команды. Команда ниже выполнит поиск строки 192.168.1.1 в файле access.log и отобразит все строки, содержащие эту строку.

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

Используйте пробел, чтобы перейти к следующей странице, и клавишу b, чтобы вернуться к предыдущей странице.

После выполнения этой команды логи будут отображаться постранично, что упрощает их ручной анализ. Если вы хотите что-то найти в логах, введите /, затем нужный шаблон для поиска и нажмите Enter.

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

https://t.me/mhostcu

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

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

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

Что такое инциденты?

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

Количество этих событий велико, так как на устройстве одновременно работают многочисленные процессы, выполняющие различные задачи и создающие новые записи. Иногда события могут указывать на потенциально опасные процессы, происходящие на устройстве. Как же тогда разобраться в этом потоке событий и выявить возможные угрозы? Для этого существуют решения в области безопасности, которые анализируют такие события, воспринимая их как журналы логов, и позволяют находить потенциально вредоносные действия. Это значительно облегчило нашу задачу! Но настоящая сложность начинается, когда такие решения безопасности указывают на угрозы.

Итак, когда система безопасности обнаруживает событие или группу событий, связанных с возможной вредоносной активностью, она формирует оповещение. Команда безопасности затем анализирует эти оповещения. Некоторые из них могут быть False Positives, а некоторые — True Positives. Оповещения, которые указывают на опасность, но не являются вредоносными, называются ложными срабатываниями (false positives). В отличие от них, оповещения, которые сигнализируют о реальной угрозе, являются истинными срабатываниями (true positives). Ниже приведен пример для лучшего понимания:

False Positive: Система безопасности сработала на большое количество данных, передаваемых с одной системы на внешний IP-адрес. При анализе этого оповещения команда безопасности обнаружила, что система выполняла резервное копирование в облачное хранилище, что и вызвало передачу данных. Это является ложным срабатыванием.

True Positive: Система безопасности среагировала на попытку фишинга, направленную на одного из пользователей организации. После анализа оповещения команда безопасности выяснила, что это было фишинговое письмо, отправленное этому пользователю с целью скомпрометировать систему. Это является истинным срабатыванием.

Такие истинные срабатывания иногда называют Incidents. Предполагая, что оповещение теперь классифицируется как инцидент, следующий этап — присвоить ему уровень критичности. Представьте, что вы работаете в команде безопасности и получаете сразу несколько инцидентов. С какого инцидента вы начнете реагировать? Здесь и вступает в силу понятие критичности инцидента. Инциденты можно разделить на низкие, средние, высокие и критические по степени их потенциального воздействия. Инциденты с критическим уровнем всегда являются приоритетными, затем следуют инциденты с высоким уровнем, и так далее.

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

Malware Infections: Malware представляет собой вредоносную программу, способную нанести вред системе, сети или приложению. Большинство инцидентов связано с заражением вредоносным ПО. Существует несколько типов вредоносного ПО, каждый из которых имеет уникальный потенциал для нанесения ущерба. Заражение malware обычно происходит через файлы, такие как текстовые документы, исполняемые файлы и др.

Security Breaches: Угрозы безопасности возникают, когда неавторизованный человек получает доступ к конфиденциальным данным (которые не должны быть ему доступны). Такие угрозы чрезвычайно важны, поскольку многие компании зависят от своих конфиденциальных данных, доступ к которым должен иметь только авторизованный персонал.

Data Leaks: Утечки данных — это инциденты, при которых конфиденциальная информация частного лица или организации становится доступной неавторизованным лицам. Многие злоумышленники используют утечки данных для нанесения репутационного вреда своим жертвам или чтобы шантажировать их, получая то, что им нужно. В отличие от угроз безопасности, утечки данных могут также возникать случайно из-за ошибок человека или неправильных настроек.

Insider Attacks: Инциденты, возникающие внутри организации, известны как внутренние атаки. Например, недовольный сотрудник может заразить всю сеть через USB на свой последний рабочий день. Это пример внутренней атаки. Кто-то внутри вашей организации, намеренно инициирующий атаку, попадает под эту категорию. Эти атаки могут быть особенно опасными, поскольку внутренний злоумышленник имеет больший доступ к ресурсам, чем внешний.

Denial Of Service Attacks: Доступность — один из трёх столпов кибербезопасности. Защитные решения и специалисты постоянно ищут способы защитить информацию, обеспечивая её одновременную доступность для пользователей. Ведь нет смысла защищать то, к чему мы не имеем доступа. Атаки типа "отказ в обслуживании" (DoS) — это инциденты, при которых злоумышленник перегружает систему/сеть/приложение ложными запросами, что в конечном итоге делает её недоступной для законных пользователей. Это происходит из-за исчерпания ресурсов, доступных для обработки запросов.

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

Процесс реагирования на инциденты

В задаче выше мы рассматривали различные типы инцидентов. Иногда обработка множества инцидентов в рамках одной среды может быть сложной. Ввиду различной природы инцидентов в организациях, необходим структурированный процесс реагирования на инциденты. В этом помогают структуры для реагирования на инциденты — Incident Response Frameworks. Это общие подходы, которые можно применять к любому инциденту для эффективного реагирования. Мы обсудим две широко используемые структуры для реагирования на инциденты: SANS и NIST.

SANS и NIST — популярные организации, которые вносят вклад в сферу кибербезопасности. SANS предлагает различные курсы и сертификации по кибербезопасности, а NIST сыграл свою роль в разработке стандартов и рекомендаций по кибербезопасности. Обе структуры реагирования на инциденты — SANS и NIST — схожи между собой.

Структура реагирования на инциденты NIST похожа на структуру SANS, которую мы изучили выше. Количество этапов в этой структуре сокращено до четырёх.

Ниже приведено сравнение обеих структур:

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

Ключевые компоненты этого плана включают (но не ограничиваются ими):

• Роли и обязанности
• Методология реагирования на инциденты
• План коммуникации с заинтересованными сторонами, включая правоохранительные органы
• Путь эскалации, которому необходимо следовать

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

• SIEM: Решение для управления информацией и событиями безопасности (Security Information and Event Management, SIEM) собирает все важные журналы в одном централизованном месте и сопоставляет их для выявления инцидентов.
• AV: Антивирус (Antivirus, AV) обнаруживает известные вредоносные программы в системе и регулярно сканирует вашу систему на их наличие.
• EDR: Обнаружение и реагирование на конечных устройствах (Endpoint Detection and Response, EDR) устанавливается на каждую систему и защищает её от продвинутых угроз. Это решение также может локализовать и устранять угрозу.

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

Playbooks представляют собой руководства для комплексного реагирования на инциденты.

Пример Playbook для инцидента: фишинговое письмо

Изображение, показывающее Playbook.

1. Уведомить всех заинтересованных лиц об инциденте с фишинговым письмом
2. Определить, было ли письмо вредоносным, проведя анализ заголовка и содержания письма
3. Проверить наличие вложений к письму и проанализировать их
4. Определить, открывал ли кто-либо вложения
5. Изолировать заражённые системы от сети
6. Заблокировать отправителя письма

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

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

1. Подготовка окружения

Убедись, что Kali Linux обновлен: Открой терминал и запусти команды:

sudo apt update && sudo apt upgrade -y

Установи необходимые инструменты: Мы будем использовать такие инструменты, как npm (Node.js package manager), nmap, и OWASP ZAP/Burp Suite.

Установи npm:

sudo apt install npm

Установи nmap:

sudo apt install nmap

Установи OWASP ZAP (если еще не установлен):

sudo apt install zaproxy

Проверь Handlebars: Handlebars — это шаблонизатор JavaScript, который подвержен уязвимости XSS (CVE-2021-23369). Уязвимость возникает, когда в шаблонах Handlebars неправильно экранируются данные, что может позволить злоумышленнику внедрить произвольный код в приложение.

2. Как использовать уязвимость CVE-2021-23369

Для проверки уязвимости ты можешь использовать следующие методы:

Использование nmap для предварительного сканирования домена

Проведи базовое сканирование домена https://xxxxxxxxx.com, чтобы понять, какие порты и сервисы открыты:

nmap -sV https://xxxxxxxxx.com

Эта команда покажет тебе, какие сервисы запущены на сервере.

Проверка наличия Handlebars

Чтобы проверить, использует ли сайт Handlebars.js, можно проанализировать исходный код страниц сайта или проверить JavaScript файлы:

• Открой сайт в браузере.
• Просмотри исходный код страницы (Ctrl+U в браузере).
• Найди упоминание библиотек, например:

<script src="path-to-handlebars.js"></script>

Если Handlebars используется, ты сможешь найти соответствующую библиотеку.

Использование OWASP ZAP для проверки уязвимостей

Если Handlebars обнаружен, используй OWASP ZAP для проведения анализа:

Открой OWASP ZAP:

zaproxy

Добавь URL для сканирования (https://xxxxxxx.com) и запусти автоматическое сканирование.OWASP ZAP автоматически проверит сайт на различные уязвимости, включая XSS.

3. Пример эксплойта

Если Handlebars.js уязвим, ты можешь попытаться внедрить JavaScript код в шаблон. Пример эксплойта:

{{#with "foo"}}{{/with}}
<script>alert('XSS')</script>

Этот код может вызвать выполнение произвольного скрипта на уязвимой странице.

4. Составление отчета

Для отчета тебе нужно:

1. Включить описание уязвимости: что такое CVE-2021-23369, и почему это важно.
2. Детализировать процесс проверки: как ты проверял сайт, какие инструменты использовал, и что нашел.
3. Рекомендации по устранению: предложи обновить библиотеку Handlebars.js до последней версии, где эта уязвимость исправлена.

Отчет можно создать в любом текстовом редакторе (например, gedit):

gedit report.txt

Шаблон отчета:

### Отчет по проверке безопасности: xxxxxxxx.com

1. **Дата проверки**:
2. **Описание уязвимости**:
Handlebars CVE-2021-23369 — уязвимость, связанная с внедрением XSS через некорректное экранирование данных.

3. **Шаги проверки**:
- Проведено сканирование nmap.
- Использован OWASP ZAP для автоматического анализа.
- Проведена ручная проверка исходного кода на наличие библиотеки Handlebars.js.

4. **Результаты**:
- Найдено наличие уязвимости (или не найдено).

5. **Рекомендации**:
- Обновить библиотеку Handlebars.js до последней версии.

5. Финальные шаги

После составления отчета и проверки сайта, тебе нужно:

1. Обсудить результаты с заказчиком.
2. Убедиться, что уязвимость устранена.

https://t.me/mhostcu