Incident management (part 5)

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

InfoSecurity 2008 © 2008 Cisco Systems, Inc. All rights reserved. 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)
Нераспределенное пространство
Хвосты файлов
Корзина

 Особенности
Слабое документирование
Расположение файлов не строго определено
При удалении файлов они не удаляются, а помечаются такими

InfoSecurity 2008
Динамические связи между файлами (DLL)
© 2008 Cisco Systems, Inc. All rights reserved. 366/431

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


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

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

• Немедленно • Не выключать
выключить систему маршрутизатор
• Сделать дубликат • Выключение
системы удалить все
• Проанализировать данные
дубликат • Анализ должен
проводиться на
«живой» системе


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

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

• Подключитесь к • Не выключать
маршрутизатору через маршрутизатор
консоль • Не подключаться к
• Сохраните вашу машрутизатору через
консольную сессию сеть (Telnet или SSH)
• Запустить команду show • Не запускать команды
• Зафиксируйте время конфигурации
реальное и на
машрутизаторе
• Зафиксируйте следы
инцидента


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

• Всегда фиксируйте все, что вы делаете
• Определите время с помощью команды show clock detail


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

Конфигурация и пользователи Сетевая информация
show clock detail show ip route
show version show ip ospf {summary, neighbors,
show running-config etc)
show startup-config show ip bgp summary
show reload show cdp neighbors : Cisco
show users/who Discovery Protocol
show ip arp
Логи, процессы и память show {ip} interfaces
show tcp brief all
show log/debug show ip sockets
show stack : stack state show ip nat translations verbose
show context : stack information show ip cache flow : Netflow
show tech-support : incomplete show ip cef : Cisco Express
show processes {cpu, memory} Forwarding
content of bootflash:crashinfo show snmp {user, group, sessions}


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


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

 Зачем нужна эскалация инцидентов?
Вы не можете справиться с данным инцидентом
Вы не знаете, как сообщить об инциденте целевой
аудитории
Вам нужны новые ресурсы
Инцидент не в вашей зоне ответственности
Получена несвязанная с инцидентами информация от
важного лица


Докладывать или нет
 Многие специалисты боятся докладывать «наверх» о
произошедших инцидентах безопасности
 Результат доклада зависит от выстроенных до этого
отношений
 Не стоит отвлекать руководство по пустякам
 Выстройте для себя иерархию инцидентов по
возможному ущербу для предприятия или для
отдельных руководителей
Мелкие – решать внутри подразделения
Средние – выносить на уровень CISO/CIO
Крупные – выносить на уровень топ-менеджмента


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


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

 Реагирование - действия для защиты от атаки
Должны ли Вы отражать атаку? Где? Когда?
Никакой реакции – обоснованная форма реакции в
определенных обстоятельствах
 Стоит ли останавливать злоумышленника, если вы
его обнаружили?
Все зависит от вашей философии и стратегии!

Защитить и
забыть Задержать и
преследовать


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

 Блокирование атаку
Реконфигурация МСЭ, блокирование порта на коммутаторе,
изменение ACL, фильтрация трафика, блокирование команд…
 Отключение от сети
 Проведение контратаки
 Устранение уязвимости и удаление вредоносного ПО
 Сообщение в правоохранительные органы
 Перенаправление в honeypot/honeynet
 Восстановление из резервной копии
 Установка патчей и реконфигурация
 Перезагрузка (повторная сборка) системы

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


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

 Инцидент может быть закрыт по разным причинам
Информация о новых вирусах ничего не дает для анализа
Техническая поддержка со стороны CSIRT больше не
требуется
 Если судебное дело, связанное с инцидентом не
закрыто, то инцидент не закрывается
 Если инцидент закрыт, то необходимо уведомить об
этом все заинтересованные стороны
Чтобы не было путаницы, недопонимания и неоправданных
ожиданий
 При появлении новой важной информации инцидент
может быть открыт заново или объединен с другим
Если это не продолжение предыдущего расследования, то
InfoSecurity 2008
инцидент лучше создать заново
© 2008 Cisco Systems, Inc. All rights reserved. 380/431

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


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


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


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

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

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

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


Расследование
причин пика

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

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

Пик
полосы
пропус-
кания
Источник: http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/
Пик RTT

Разные консоли управления
 МСЭ (firewall)
 VPN
 Anti-virus
 Network IDS/IPS
 Host IDS/IPS
 Поиск уязвимостей
 Управление патчами
 Нарушения политики
 Маршрутизаторы
 Коммутаторы
 ОС, СУБД, приложения


Крупная сеть – множество СЗИ
 Точки контроля  
 
 


 

  

 


 
   
 
   
  
  
 
 
  
 
  

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

 Огромный поток информации
 Для оператора связи
> 2500 событий в секунду
1375 Мб в час
32,2 Гб в день
 Для крупной компании
500 событий в секунду
274,7 Мб в час
6,43 Гб в день
 Только для одного МСЭ (!)


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

 Большинство отделов защиты информации
Не имеют описанных политик безопасности
Не имеют описанных процедур безопасности
Не тренируются для использования инструментов и
процедур
Учатся «на ходу»
Не взаимодействуют с «контрагентами»


Что делает SOC?


От разрозненных данных к инцидентам
Firewall Log IDS Event Server Log
Switch Log
SNMP
RMON
Packet
AV Alert
App Log
ДАННЫЕ
Netflow
.
.
Capture
.
VA Scanner

Без SOC не
обойтись!

Полезная информация ИНФОРМАЦИЯ

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

 Мониторинг безопасности в режиме 24x7x365 с
помощью систем Security Information Management
System (SIMS)
 Отражение угроз в реальном режиме времени
 Сканирование уязвимостей
 Анализ и корреляция собираемых данных с целью
управления инцидентами безопасности
 Централизованное управление средствами защиты
 Генерация периодических и в реальном времени
отчетов о состоянии защищенности и результатах
аудита

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

2
Событие: Сетевое
сканирование ICMP

Событие:
WWW IIS .ida – Переполнение
сервиса индексирования

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

Пример SOC (продолжение)
Две возможные точки подавления, в
которых мы можем действовать

Выбор:
1. Устройство подавления
2. Предпочтительная
команда:
Block host
Block connection
Shun


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

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



В моей сети
найдены
вирусы Вирусы
не вылечены

Пример SOC (окончание)
Не соответствует
политике
безопасности

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

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

 Обнаружение аномалий
 Управление изменениями (конфигурации, патчи и
т.д.)
 Security Dashboard
 Управление рисками
 Сбор и обеспечение доказательств
несанкционированной активности
 Контроль информационных ресурсов
 Интеграция c Service Desk (генерация ticket)


Пример SOC

Пред-вирусная
активность Фактическая
атака
вируса


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


Эволюция SOC
Функции SOC
Отчеты периодически и в
реальном времени –
 Аудит
Инциденты,
соответствие, SLA Технологии + соответствия
процессы +  Устранение риска
 Защищенный портал
интеграция с
 Улучшенный
Service Desk анализ
Управление:
(ITIL)
Инцидент, Проблема, Анализ и
Изменение корреляция
 Отчеты - периодично Эксперты
 Контроль SLA
Расширенные
функции Построение эталона
Процесс и инструментарий
Внедрение контроля защиты
Видимость Управление инцидентами
Оценка
уязвимостей
Политика безопасности
Базовые Планирование управления
функции рисками
Установление SLA
Бизнес-активы Сложность систем защиты

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

«Чужой Переход «Свой»
» SOC ный SOC SOC

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

Анализ рисков в
Security Experts режиме 24x7

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

Анализ и корреляция для
Tools управления инцидентами


SOC Вымпелкома


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


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

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

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

 Кто должен это делать, когда и где?
Процедуры

 Как это делать?
Инструкции

 С помощью чего это делать?
Люди и инструменты


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

 Максимальное покрытие
Получать данные из всех возможных источников
Агрегировать данные для последующего анализа
 Корреляция
Максимальное покрытие
Встроенные и пользовательские правила
Подключение собственных источников
 Ускорение
Быстрое реагирование
«Робот-консультант» (помощник)


Слагаемые успеха: процессы
Подготовка
Подготовка сети
Создание инструментария
Разбор полетов Тестирование Идентификация
Что было сделано? Подготовка процедур Что вы знаете об атаках?
Что еще можно было Тренинг команды Какие средства вы
сделать? SLA используете?
Какие уроки можно извлечь в Как вы взаимодействуете?
будущем?

Реагирование
Как реагировать на атаки?
Как это может повлиять на
Классификация
сеть? Что это за атака?
Отслеживание Нарушение SLA?
Откуда исходит атака?
Где и как атаки влияют на сеть?


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

 Квалифицированные специалисты
 Регулярные тренинги и ролевые игры
 Взаимодействие с
Другими подразделениями
Операторами связи
Правоохранительными структурами
Производителями
 Круглосуточная работа
 Документирование
 Извлечение уроков


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



 Низкий уровень зрелости
Люди «не готовы»
 Люди – не автоматы и не всегда следуют «лучшим
практикам»
Специалист SOC мог не инициировать разбор инцидента,
потому что он может повлиять на его друга или у него «нет
времени» или не собрана полная информация
 Нет ресурсов для выполнения работ
 Не установлены цели или они не приоритезированы
 Попытка «съесть слона» целиком
 Дело не доведено до конца



 Не хватает людей для внедрения и управления
SOC
Одним-двумя людьми проблему не решить
 Отсутствие четких инструкций
 Отсутствие владельца процесса
Очень важно для безопасности, которая пересекает
границы многих подразделений в компании
 Концентрация на технологиях в ущерб процессам и
людям
 Отсутствие технологической инфраструктуры
МСЭ, антивирусы, ID&PS и т.д.



 Отсутствие взаимодействия с другими участниками
процесса управления ИБ
Включая внутренние подразделения (ИТ, HR и т.д.)

 Психология
Единая точка контакта, как стена, отделяет ИТ от
пользователя и он не прощает то, что простилось бы при
личном контакте
Формализация требует более высокого качества
обслуживания


Заключение


100% исключение инцидентов
 Инциденты у вас уже были, есть и будут в будущем!
 Исключить инциденты на 100% невозможно
Слишком дорого и никому не нужно
 Если вы будете стремиться к 100%
Первый удачный инцидент приведет вас в ступор
Ваши затраты превысят все преимущества
Вы поставите крест на своей карьере профессионала
 Необходимо создать условия, в которых вероятность
инцидентов снижается, наносимый ущерб
минимизируется, число инцидентов сводится к
определенному минимуму, а реакция на
свершившиеся инциденты будет предсказуемой


Вопросы?

Дополнительные вопросы Вы можете задать по электронной
почте security-request@cisco.com
или по телефону: +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


Incident management (part 5)

Incident management (part 5)

More Related Content

What's hot

Viewers also liked

Similar to Incident management (part 5)

More from Aleksey Lukatskiy

Incident management (part 5)