Incident management (part 5)

© 2008 Cisco Systems, Inc. All rights reserved.InfoSecurity 2008 333/431

Обработка информацииНа стыке обработки инцидентов и артефактов


Обработка информации

Обработка инцидентов всегда связана с обработкой информации

Вопросы управления обработкой информацией

Сбор информации

Проверка и подтверждение информации

Категорирование информации

Защита информации

Хранение информации

Уничтожение информации

Раскрытие информации


Сбор информации

Какая информация нам нужна?

Откуда берется информация?

Открытые источники или по обмену?

Как обеспечить качество собираемой информации?

И ее целостность

Как распознать ошибки, нестыковки и неточные данные?


Как собирать информацию?Интервью

Каков уровень квалификации пользователя?

Каков уровень защиты устройства?

Кто владелец оборудования?

Какие логи доступны?

Какова частота использования?

Как используется устройство?

Где хранилище информации?

Как происходит взаимодействие и с кем?

Какие операторы связи используются?

…


Как и где собирать информацию?Местонахождение устройств, людей, данных

Примененные рабочие, личные или публичные устройства и системы

Компьютерное оборудование (ПК, КПК, принтер, носители информации…)

Компьютерные аксессуары (зарядка, держатели/чехлы, батареи, сумки…)

Могут свидетельствовать о наличии скрытых или спрятанных устройств

Носители информации

Бытовая электроника (автоответчики, мобильные телефоны, копиры, сканеры, фотоаппараты, игровые приставки, USB-плейеры…)


Как и где собирать информацию?Местонахождение устройств, людей, данных

Интернет-устройства (USB-модемы, PCMCIA-модемы, ADSL-модемы, маршрутизаторы, Wi-Fi-точки…)

Документы и записи, содержащие информацию о доступе

Книги, руководства, гарантия, коробки от ПО

Свидетельствует о наличии спрятанного или скрываемого ПО

Мусор

Чеки, связанные с приобретением ПО и оборудования


Как и где собирать информацию?Публично доступная информация

Интернет-поиск

Новостные группы

Форумы

Блоги

Чаты

IRC-каналы

Сайты

WHOIS


Как и где собирать информацию?Коммуникации

Электронная почта (в т.ч. и на смартфонах)

SMS (в т.ч. и через компьютер)

Мобильная связь

АОН, автоответчик и голосовая почта

IM и чаты

P2P

Web-сайты

Skype

Контроль звонков на корпоративной АТС или логидомашнего телефона


Как и где собирать информацию?Видеонаблюдение

Корпоративное видеонаблюдение

Ближайшие к объекту видеокамеры других организаций

Web-камеры


Как и где собирать информацию?Мониторинг

Анализ телефонных переговоров на корпоративной АТС

Анализ сетевого трафика

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

Включая локализацию беспроводных точек и клиентов

Видеонаблюдение

Микрофоны

Контроль ввода с клавиатуры


Как и где собирать информацию?Другие местонахождения

Системы контроля доступа

С целью определить местонахождение подозреваемого в нужное время в нужном месте

GPS

Местоположение подозреваемого в нужное время в нужном месте (например, iPhone сохраняет местоположение сделанных фотографий)

Диктофоны


Сбор доказательств


Методология сбора доказательств

Подготовка

Документирование инцидента

Проверка политик

Стратегия сбора доказательств

Инициация процесса сбора доказательств

Сбор доказательств


1. Подготовка

Инструментарий

ПО (например, EnCase или Sysinternals)

Оборудование

Создание или проверка наличия политик сбора доказательств для подозреваемых систем


Специализированное ПО EnCase

Разработано для нужд Секретной службы МинФинаСША, ФБР и АНБ

Сейчас предлагается в открытой продаже

Контекстный поиск и анализ информации

FAT12, FAT16, FAT32, NTFS, Linux, UNIX, Mac, RAID…

CD-ROM, DVD-R, Jaz, Zip, IDE, SCSI, магнитооптика

Встроенный макроязык для автоматизации

Анализ файлов без их изменения

Сохранение и восстановление образа диска

Предварительный анализ компьютера (без следов) через параллельный порт или сетевую плату


Специализированное ПО EnCase(окончание)

Поиск стандартных скрытых следов

Swap-файл, «корзина»…

Продвинутая система генерации отчетов

Комментарии и заметки следователя

Логи не анализирует!


2. Документирование

Профиль инцидента

Как был зафиксирован инцидент

Когда он произошел?

Кто или что зафиксировал инцидент?

Какое ПО и железо задействовано?

Кто контакт?

Насколько критичен подозреваемый ресурс?

Дневник сбора доказательств

Фиксируйте все, что вы делаете во время расследования

Фиксация результатов сбора доказательств

Логи и т.п.


3. Проверка политик

У вас есть полномочия для сбора доказательств?


4. Стратегия сбора доказательств

Что собираем? Типы данных?

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

Где хранить результаты сбора доказательств?

Какой доступ нужен? Права администратора?

Типы периферийных устройств

Подключение к сети


Где хранятся данные?

Оперативная память (RAM)

Постоянное запоминающее устройство (ПЗУ)

НЖМД

НГМД

«Флешки», Zip, Jazz, Firewire (IEEE 1394)

Карты памяти (включая PCMCIA)

Оптические носители

Магнитные носители

«Нестандартные» устройства

Смартфоны, iPod (и другие плейеры), Xbox, PSP, USB-часы…


Что надо помнить о носителях данных?

Любые носители данных категорически «не любят»

Потерю питания

Электромагнитное воздействие (например, мониторы)

Высокие и низкие температуры

Повышенную влажность

Воздействие света

Статическое электричество (например, в пластиковых пакетах)

Исследуйте и храните их в надежном месте

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


Что надо помнить о питании?

Многие места хранения/нахождения доказательств требуют постоянного электропитания

В случае его отключения доказательства могут быть потеряны

На ПК рекомендуется осуществить мгновенное отключение системы после чего сделать дубликат системы, который и подвергнуть анализу

Мгновенное отключение можно осуществить выдергиванием питания (убедитесь, что нет ИБП)


5. Инициация сбора доказательств

Доверенная загрузка

Методы передачи и хранения

Целостность результатов

Неизменность среды анализа


6. Сбор доказательств

Фиксируйте все действия

Дата, время, история вводимых команд…

Отслеживайте время и дату старта всех команд и инструментов

Для последующего анализа логов

Соберите всю необходимую информацию

Исходя из типа анализируемой системы – ОС, приложение, СУБД, сетевое оборудование, мобильные устройства, принтеры…


Управление отдельными видами инцидентов


Где можно найти артефакты?

На персональном компьютере

В локальной вычислительной сети

В Интернет

В электронной почты

В Web

На мобильных устройствах

На неуправляемых устройствах

Анализ исходных кодов

Контент


Сбор доказательств в Интернет


Трекинг IP-адреса

Сервис whois позволяет определить владельца IP-адреса

Он может быть статическим или динамическим (злоумышленник находится в сети провайдера или Интернет-кафе)

Злоумышленник может работать через серию промежуточных прокси-серверов

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

Сервис traceroute позволяет отследить путь до злоумышленника

В т.ч. понять несанкционированное изменение таблиц маршрутизации


Сбор доказательств в e-mail


Заголовок электронной почты


Сбор доказательств на ПК


Где искать следы на ПК?

Реестр и кэш (буфер обмена)

Таблицы маршрутизации, ARP кэш, таблица процессов, статистика ядра, соединения

Временные и удаленные файлы

Жесткий диск и другие внешние носители

Открытые файлы, запущенные процессы, файлы автозагрузки

Данные мониторинга и регистрации

Физическая конфигурация и сетевая топология

Архивные и резервные данные/копии


Где искать следы на ПК? (окончание)

Базы данных, электронные таблицы, картинки и документы

Cookies, данные авторегистрации, закладки

Логи (чаты, ICQ и т.п.)

Электронная почта (включая Web-почту)

P2P-приложения

IM-приложения


Файловая система

Файловая система

Разные файловые системы (FAT12, FAT16, FAT32, NTFS, Linux, UNIX, Mac, RAID)

Скрытые данные (swap)

Нераспределенное пространство

Хвосты файлов

Корзина

Особенности

Слабое документирование

Расположение файлов не строго определено

При удалении файлов они не удаляются, а помечаются такими

Динамические связи между файлами (DLL)


Сбор доказательств на маршрутизаторе


Расследование на маршрутизаторе

ПК

• Немедленно выключить систему

• Сделать дубликат системы

• Проанализировать дубликат

Маршрутизатор

• Не выключать маршрутизатор

• Выключение удалить все данные

• Анализ должен проводиться на «живой» системе


Что делать и чего не делать?

Что делать?

• Подключитесь к маршрутизатору через консоль

• Сохраните вашу консольную сессию

• Запустить команду show

• Зафиксируйте время реальное и на машрутизаторе

• Зафиксируйте следы инцидента

Чего не делать?

• Не выключать маршрутизатор

• Не подключаться к машрутизатору через сеть (Telnet или SSH)

• Не запускать команды конфигурации


Подключение к маршрутизатору

• Всегда фиксируйте все, что вы делаете

• Определите время с помощью команды show clock detail


Команды для анализа

show clock detail

show version

show running-config

show startup-config

show reload

show users/who

Конфигурация и пользователи

show log/debug

show stack : stack state

show context : stack information

show tech-support : incomplete

show processes {cpu, memory}

content of bootflash:crashinfo

Логи, процессы и память

show ip route

show ip ospf {summary, neighbors,

etc)

show ip bgp summary

show cdp neighbors : Cisco

Discovery Protocol

show ip arp

show {ip} interfaces

show tcp brief all

show ip sockets

show ip nat translations verbose

show ip cache flow : Netflow

show ip cef : Cisco Express

Forwarding

show snmp {user, group, sessions}

Сетевая информация


Эскалация инцидента


Эскалация инцидента

Зачем нужна эскалация инцидентов?

Вы не можете справиться с данным инцидентом

Вы не знаете, как сообщить об инциденте целевой аудитории

Вам нужны новые ресурсы

Инцидент не в вашей зоне ответственности

Получена несвязанная с инцидентами информация от важного лица


Докладывать или нет

Многие специалисты боятся докладывать «наверх» о произошедших инцидентах безопасности

Результат доклада зависит от выстроенных до этогоотношений

Не стоит отвлекать руководство по пустякам

Выстройте для себя иерархию инцидентов по возможному ущербу для предприятия или для отдельных руководителей

Мелкие – решать внутри подразделения

Средние – выносить на уровень CISO/CIO

Крупные – выносить на уровень топ-менеджмента


Реагирование на инциденты


Реагирование

Реагирование - действия для защиты от атаки

Должны ли Вы отражать атаку? Где? Когда?

Никакой реакции – обоснованная форма реакции в определенных обстоятельствах

Стоит ли останавливать злоумышленника, если вы его обнаружили?

Все зависит от вашей философии и стратегии!

Защитить и забыть Задержать и

преследовать


Сценарии реагирования

Блокирование атаку

Реконфигурация МСЭ, блокирование порта на коммутаторе, изменение ACL, фильтрация трафика, блокирование команд…

Отключение от сети

Проведение контратаки

Устранение уязвимости и удаление вредоносного ПО

Сообщение в правоохранительные органы

Перенаправление в honeypot/honeynet

Восстановление из резервной копии

Установка патчей и реконфигурация

Перезагрузка (повторная сборка) системы


Закрытие инцидента


Закрытие инцидента

Инцидент может быть закрыт по разным причинам

Информация о новых вирусах ничего не дает для анализа

Техническая поддержка со стороны CSIRT больше не требуется

Если судебное дело, связанное с инцидентом не закрыто, то инцидент не закрывается

Если инцидент закрыт, то необходимо уведомить об этом все заинтересованные стороны

Чтобы не было путаницы, недопонимания и неоправданных ожиданий

При появлении новой важной информации инцидент может быть открыт заново или объединен с другим

Если это не продолжение предыдущего расследования, то инцидент лучше создать заново


Стандарты управления инцидентами


ISO/IEC TR 18044

ISO/IEC TR 18044 Information security incident management

Принят как ГОСТ Р ИСО/МЭК

Высокоуровневый стандарт

Предварительная информация (исходные данные)

Планирование и подготовка

Эксплуатация системы управления инцидентами

Анализ

Улучшение


Стандарты управления инцидентами

Соответствующие разделы в ГОСТ Р ИСО/МЭК20000-200х, BS 25999, ГОСТ Р ИСО/МЭК 17799:2005

RFC 2350. Expectations for Computer Security Incident Response

ITU-T E.409 Организация по реагированию на инциденты и обработка инцидентов безопасности: Руководство для организаций электросвязи


ГОСТ Р ИСО/МЭК 18044 vs. ITU-T E.409

Событие ИБ

Инцидент ИБ

Ложный сигнал

Событие

Инцидент

Инцидент ИБ

Катастрофа, кризис

ГОСТ Р ИСО/МЭК 18044 ITU-T E.409


ITU-T E.409

Инцидент - событие, которое может привести к явлению или эпизоду, не являющемуся серьезным

ITU-T E.409

Инцидент безопасности – это любое неблагоприятное событие, в результате которого некий аспект безопасности может подвергнуться угрозе

ITU-T E.409

Инцидент безопасности инфокоммуникационныхсетей (ICN) - любое фактическое или предполагаемое неблагоприятное событие в отношении безопасности ICN

ITU-T E.409


Управление инцидентом по E.409


Документы CERT

Defining Incident Management Processes for CSIRTs: A Work in Progress

Handbook for Computer Security Incident Response Teams (CSIRTs)

State of the Practice of Computer Security Incident Response Teams

Incident Management Capability Metrics

Incident Management Mission Diagnostic Method

Staffing Your Computer Security Incident Response Team – What Basic Skills Are Needed?

Action List for Developing a Computer Security Incident Response Team (CSIRT)

http://www.cert.org/csirts/


Другие стандарты

NIST SP 800-86 Guide to Integrating Forensic Techniques into Incident Response

NIST SP 800-61 Computer Security Incident Handling Guide

NIST SP 800-3 Establishing a Computer Incident Response Capability (CSIRT)

ISO/PAS 22399. Guidelines for incident preparedness and operational continuity management

NFPA 1600. Standard on Disaster/Emergency Management and Business Continuity Programs

National Fire Protection Association – 25 стандартов


SOC это российский CSIRT


Аномалия: червь или еще что-то?


Источник: Cisco Systems, Inc.

Аномалия: DoS или еще что-то?


Аномалия: червь или еще что-то?

Источник: www.mrtg.org

http://www.mrtg.org/


Расследование

причин пика

Идентифицированная причина

временной неработоспособностиИсточник: Университет Висконсина



Источник: http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/

Пик

полосы

пропус-

кания

Аномалия для запросов DNS

Пик RTT


http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/


Разные консоли управления

МСЭ (firewall)

VPN

Anti-virus

Network IDS/IPS

Host IDS/IPS

Поиск уязвимостей

Управление патчами

Нарушения политики

Маршрутизаторы

Коммутаторы

ОС, СУБД, приложения


Точки контроля

Крупная сеть – множество СЗИ


Большое число событий

Огромный поток информации

Для оператора связи

> 2500 событий в секунду

1375 Мб в час

32,2 Гб в день

Для крупной компании

500 событий в секунду

274,7 Мб в час

6,43 Гб в день

Только для одного МСЭ (!)


Наша цель и что делать при атаке?!

Большинство отделов защиты информации

Не имеют описанных политик безопасности

Не имеют описанных процедур безопасности

Не тренируются для использования инструментов и процедур

Учатся «на ходу»

Не взаимодействуют с «контрагентами»


Что делает SOC?


От разрозненных данных к инцидентам

Полезная информация

Netflow

Firewall Log

SNMP

Switch Log

Server Log

AV Alert

App Log

VA Scanner

RMON

Packet

Capture

IDS Event

...

ДАННЫЕ

Без SOC не

обойтись!

ИНФОРМАЦИЯ


Мониторинг безопасности в режиме 24x7x365 с помощью систем Security Information Management System (SIMS)

Отражение угроз в реальном режиме времени

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

Анализ и корреляция собираемых данных с целью управления инцидентами безопасности

Централизованное управление средствами защиты

Генерация периодических и в реальном времени отчетов о состоянии защищенности и результатах аудита

Стандартные функции SOC


Событие: Сетевое

сканирование ICMP

Событие:

построение/разрыв/разрешено IP-соединение

Событие:

WWW IIS .ida – Переполнение

сервиса индексирования

1

3

2

Графическое представление временной последовательности вектора атаки

Пример SOC


Пример SOC (продолжение)

Две возможные точки подавления, в

которых мы можем действовать

Выбор:

1. Устройство подавления2. Предпочтительная

команда:Block host

Block connection

Shun



От отчетов высокого уровня для быстрого и простого чтения…

…до деталей конкретного исходного сообщения, полученного консолью


Вирусы

не вылечены


В моей сети

найдены

вирусы


Пример SOC (окончание)

Не соответствует политике безопасности

Общая ситуация с соответствием политике ИБ


Обнаружение аномалий

Управление изменениями (конфигурации, патчи и т.д.)

Security Dashboard

Управление рисками

Сбор и обеспечение доказательств несанкционированной активности

Контроль информационных ресурсов

Интеграция c Service Desk (генерация ticket)

Расширенные функции SOC


Пример SOC

Пред-вирусная

активностьФактическая

атака

вируса


Архитектура SOC


Эволюция SOC

Сложность систем защиты

Управление:

Инцидент, Проблема,

Изменение

Отчеты - периодично

Контроль SLA

Построение эталона

Процесс и инструментарий

Внедрение контроля защиты

Управление инцидентами

Расширенные

функции

Анализ и

корреляция

Эксперты

безопасности

Функции SOC

Технологии +

процессы +

интеграция с

Service Desk

(ITIL)

Аудит

соответствия

Устранение риска

Улучшенный

анализ

Отчеты периодически и в

реальном времени –

Инциденты,

соответствие, SLA

Защищенный портал

Политика безопасности

Планирование управления

рисками

Установление SLAБизнес-активы

Базовые

функции

Оценка

уязвимостей

Видимость


Чужой SOC или свой?

Анализ и корреляция для

управления инцидентамиTools

«Чужой

» SOC

Переход

ный SOC

«Свой»

SOC

Аутсорсинг Инсорсинг

Процессы по ITIL и COBiT для

управления рискамиПроцессы

Анализ рисков в

режиме 24x7Security Experts


SOC Вымпелкома






Как сделать SOCуспешным


Этапы процесса управления ИБ

Какие цели мы хотим достичь?

Политика

Что надо сделать для достижения целей?

Процесс

Кто должен это делать, когда и где?

Процедуры

Как это делать?

Инструкции

С помощью чего это делать?

Люди и инструменты


Максимальное покрытие

Получать данные из всех возможных источников

Агрегировать данные для последующего анализа

Корреляция

Максимальное покрытие

Встроенные и пользовательские правила

Подключение собственных источников

Ускорение

Быстрое реагирование

«Робот-консультант» (помощник)

Слагаемые успеха: техника


Подготовка

Подготовка сети

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

Тестирование

Подготовка процедур

Тренинг команды

SLA

Идентификация

Что вы знаете об атаках?

Какие средства вы

используете?

Как вы взаимодействуете?

Классификация

Что это за атака?

Нарушение SLA?Отслеживание

Откуда исходит атака?

Где и как атаки влияют на сеть?

Реагирование

Как реагировать на атаки?

Как это может повлиять на

сеть?

Разбор полетов

Что было сделано?

Что еще можно было

сделать?

Какие уроки можно извлечь в

будущем?

Слагаемые успеха: процессы


Квалифицированные специалисты

Регулярные тренинги и ролевые игры

Взаимодействие с

Другими подразделениями

Операторами связи

Правоохранительными структурами

Производителями

Круглосуточная работа

Документирование

Извлечение уроков

Слагаемые успеха: люди


Причины неудач



Низкий уровень зрелости

Люди «не готовы»

Люди – не автоматы и не всегда следуют «лучшим практикам»

Специалист SOC мог не инициировать разбор инцидента, потому что он может повлиять на его друга или у него «нет времени» или не собрана полная информация

Нет ресурсов для выполнения работ

Не установлены цели или они не приоритезированы

Попытка «съесть слона» целиком

Дело не доведено до конца



Не хватает людей для внедрения и управления SOC

Одним-двумя людьми проблему не решить

Отсутствие четких инструкций

Отсутствие владельца процесса

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

Концентрация на технологиях в ущерб процессам и людям

Отсутствие технологической инфраструктуры безопасности

МСЭ, антивирусы, ID&PS и т.д.



Отсутствие взаимодействия с другими участниками процесса управления ИБ

Включая внутренние подразделения (ИТ, HR и т.д.)

Психология

Единая точка контакта, как стена, отделяет ИТ от пользователя и он не прощает то, что простилось бы при личном контакте

Формализация требует более высокого качества обслуживания


Заключение


100% исключение инцидентов

Инциденты у вас уже были, есть и будут в будущем!

Исключить инциденты на 100% невозможно

Слишком дорого и никому не нужно

Если вы будете стремиться к 100%

Первый удачный инцидент приведет вас в ступор

Ваши затраты превысят все преимущества

Вы поставите крест на своей карьере профессионала

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


Вопросы?

Дополнительные вопросы Вы можете задать по электронной почте [email protected]или по телефону: +7 495 961-1410



Версия 1.1

Аналогия с автомобилем

Интеллект-карта курса

Вопросы, которые заставляют нас задуматься

Пошаговая процедура SANS

Систематизация материала и более логичные переходы между темами

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

Примеры инцидентов

Пример отчета об инциденте

Стратегии управления инцидентами

Детальный план создания CSIRT


Версия 1.1

Сколько человек надо в CSIRT?

Оборудование CSIRT

Политики CSIRT

Как общаться с неизвестным абонентом?

Показатели качества для CSIRT целиком

Реагирование на инциденты

Модели существования CSIRT

Бизнес-модели CSIRT

Бизнес-план CSIRT руководству

Управление проектом создания CSIRT в MS Project


Версия 1.1

Статистика опроса по различным CSIRT

Стоимость инцидента

Состав CSIRT

ПО трекинга инцидентов

Приоритезация инцидентов

Где можно собирать доказательства?

Как собирать информацию?

Где хранятся доказательства?

Где искать следы на ПК?

Что надо помнить о носителях данных?


Версия 1.1

Что надо помнить о питании?

Управление отдельными видами инцидентов

ПК, маршрутизатор Cisco, Интернет, e-mail

Self Improvement

Incident management (part 5)