ФИНАНСОВЫЙ УНИВЕРСИТЕТ ПРИ ПРАВИТЕЛЬСТВЕ РОССЙСКОЙ ФЕДЕРАЦИИ Кафедра информационной

ФИНАНСОВЫЙ УНИВЕРСИТЕТ ПРИ ПРАВИТЕЛЬСТВЕ РОССЙСКОЙ ФЕДЕРАЦИИ Кафедра информационной безопасности ИНЦИДЕНТЫ И ЭСКАЛАЦИИ В ПРАКТИКЕ ЗАЩИТЫ ИНФОРМАЦИИ ЛЕКЦИЯ 25 апреля 2013 г. ДЕРБИН Евгений Анатольевич, профессор кафедры, доктор военных наук тел. : 8 -926 -754 -13 -75

2 Учебные вопросы: 1. Инциденты и реагирование на них. 2. Эскалации в практике защиты информации Литература: 1. Международный стандарт ISO/IEC 27001: 2005. «Информационные технологии. Методы защиты. Системы менеджмента защиты информации. Требования» . 2. Международный стандарт ISO/IEC 27002: 2005(E) «Информационные технологии. Свод правил по управлению защитой информации» . 3. ГОСТ Р ИСО/МЭК ТО 18044 -2007. «Информационная технология. Методы и средства обеспечения безопасности. Менеджмент инцидентов информационной безопасности» . 4. ISO 13335 -1: 2004 Информационные технологии. Руководство по управлению ИТ безопасностью. Концепции и модели для управления безопасностью информационных и телекоммуникационных технологии) 5. Британский стандарт BS 25999 -1: 2006. Управление непрерывностью бизнеса – Ч. 1: Практические правила. 6. http: //csrc. nist. gov/publications/nistpubs/index. html

ITIL SERVICE SUPPORT-МОДЕЛЬ ОБЕСПЕЧЕНИЯ НЕПРЕРЫВНОСТИ ПРОЦЕССА 3 Information Technology Infrastructure Library (ITIL)

4 ITIL SERVICE SUPPORT-МОДЕЛЬ УПРАВЛЕНИЯ Information Technology Infrastructure Library (ITIL)

ITIL SERVICE SUPPORT-МОДЕЛЬ В ПОДХОДАХ К УПРАВЛЕНИЮ ОБСЛУЖИВАНИЕМ Инцидент – любое событие, которое не является частью стандартных операций сервиса и вызывает, или может вызвать, прерывание обслуживания или снижение качества сервиса Примеры : пользователь не может получить e-mail; средство мониторинга сети указывает, что канал связи вскоре переполнится; пользователь ощущает замедление работы приложения Проблема – неизвестная причина одного или более инцидентов. Одна проблема может породить несколько инцидентов. Причина выявляет ошибку Управление инцидентами – деятельность по восстановлению нормального обслуживания с минимальными задержками и влиянием на бизнес-операции, являющаяся реактивным, сфокусированным на краткосрочную перспективу сервисом восстановления. Включает в себя: выявление и регистрацию инцидентов; классификацию и начальную поддержку; исследование и диагностику; решение и восстановление; закрытие; владение, мониторинг, отслеживание и связь 5 Известная ошибка – инцидент или проблема, для которой выявлена причина и разработано решение по ее обходу или устранению Примеры: неправильная сетевая конфигурация компьютера; средство мониторинга неверно определяет статус канала в момент занятости маршрутизатора Управление проблемами – деятельность по минимизации воздействия проблем, которые вызываются ошибками в ИТ-инфраструктуре, и по предотвращению повторения инцидентов, связанных с такими ошибками, которая выявляет причины проблем, идентифицирует решения по их обходу или устранению. Включает в себя: контроль проблем; контроль ошибок; предотвращение проблем; анализ основных проблем

СОДЕРЖАНИЕ УПРАВЛЕНИЯ ПРОБЛЕМАМИ КОНТРОЛЬ ПРОБЛЕМ Цель контроля проблем - найти причину проблемы, выполнив следующие шаги: v идентификация и регистрация проблем; v классификация проблем и определение v приоритетов их решений; v исследование и диагностика причин ПРЕДОТВРАЩЕНИЕ ПРОБЛЕМ 6 КОНТРОЛЬ ОШИБОК Контроль ошибок обеспечивает исправление проблем за счет следующих действий: v идентификация и регистрация известных ошибок; v оценка способов устранения и расстановка приоритетов; v регистрация по временному обходу ошибки в средствах службы поддержки; v закрытие известных ошибок путем осуществления исправлений; v мониторинг известных ошибок для определения необходимости в изменении приоритетов АНАЛИЗ ПРОБЛЕМ Цель анализа проблем состоит в улучшении процессов управления инцидентами и управления проблемами, что достигается изучением качества результатов деятельности по устранению основных проблем и инцидентов Information Technology Infrastructure Library (ITIL)

7 1. ИНЦИДЕНТЫ И РЕАГИРОВАНИЕ НА НИХ

ДОКУМЕНТЫ, ОТРАЖАЮЩИЕ СПЕЦИФИЧЕСКИЕ ВОПРОСЫ УПРАВЛЕНИЯ ИНЦИДЕНТАМИ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ 8 ISO/IEC 27001: 2005 Information security management system. Requirements выдвигаются общие требования к построению системы управления информационной безопасности, относящиеся в том числе и к процессам управления инцидентами. ISO/IEC TR 18044 Information security incident management - описывает инфраструктуру управления инцидентами в рамках циклической модели PDCA. Даются подробные спецификации для стадий планирования, эксплуатации, анализа и улучшения процесса. Рассматриваются вопросы обеспечения нормативно-распорядительной документацией, ресурсами, даются подробные рекомендации по необходимым процедурам. CMU/SEI-2004 -TR-015 Defining incident management processes for CISRT - описывает методологию планирования, внедрения, оценки и улучшения процессов управления инцидентами. Основной упор делается на организации работы CISRT (Critical Incident Stress Response Team) - группы или подразделения, обеспечивающего сервис и поддержку предотвращения, обработки и реагирования на инциденты информационной безопасности. Вводится ряд критериев, на основании которых можно оценивать эффективность данных сервисов, приводятся подробные процессные карты. NIST SP 800 -61 Computer security incident handling guide - представлен сборник «лучших практик» по построению процессов управления инцидентами и реагирования на них. Подробно разбираются вопросы реагирования на разные типы угроз, такие как распространение вредоносного программного обеспечения, НСД и др.

ОБЕСПЕЧЕНИЕ СЕРВИСОВ 9 ДЕЯТЕЛЬНОСТЬ ПО ОБЕСПЕЧЕНИЮ СЕРВИСОВ Процессы – последовательность шагов, направленная на достижение определенной цели или результата Собственник (владелец) процесса – физическое лицо, отвечающее за сквозное выполнение процесса Набор метрик Взаимные расчеты Инциденты и риски Инцидент в системе защиты информации (англ. information security incident) – одно или серия нежелательных или неожиданных событий в системе защиты информации, которые имеют большой шанс скомпрометировать деловые операции и поставить под угрозу защиту информации. (ISO/IEC 27001: 2005(E) Инцидент - отказ или повреждение технических устройств, применяемых на опасном производственном объекте, отклонение от режима технологического процесса, нарушение положений настоящего Федерального закона, других федеральных законов и иных нормативных правовых актов РФ, а также нормативных технических документов, устанавливающих правила ведения работ на опасном производственном объекте. (Закон «О промышленной безопасности опасных производственных объектов» )

ОБЕСПЕЧЕНИЕ СЕРВИСОВ И УПРАВЛЕНИЕ ИНЦИДЕНТАМИ 10 Обеспечение процесса управления инцидентами Управление инцидентами (Incident Management). Цель: как можно более быстрое восстановление сервиса. Метрики процесса: продолжительность инцидентов, число зарегистрированных инцидентов Прием запросов (Accept calls) Регистрация инцидентов (Log incidents) Категоризация инцидентов (Categorize incidents) Приоритизация инцидентов (Prioritize incidents) Изоляция инцидентов (Isolate incidents) Эскалация инцидентов (Escalate incidents) Отслеживание развития (Track incident progress) Разрешение инцидентов (Resolve incidents) Уведомление клиентов (Notify customers) Закрытие инцидентов (Close incidents) Обеспечение процесса управления проблемами Управление проблемами (Probem Management). Проблема – инцидент или группа инцидентов, имеющих общую неизвестную причину. Цели: минимизация негативного влияния инцидентов на бизнес; уменьшение количества инцидентов, за счет предотвращения возможных причин Анализ тенденций инцидентов (Analyze incident trends) Регистрация проблем (Log problem) Идентификация корневых причин инцидентов (Identify root cause) Отслеживание изменений проблем (Track problem progress) Выявление известных ошибок (Verify known errors) Управление известными ошибками (Control known errors) Решение проблем (Resolve problems) Закрытие проблем (Close problems)

ОБЕСПЕЧЕНИЕ СЕРВИСОВ И УПРАВЛЕНИЕ КАЧЕСТВОМ Управление качеством Определение системы управления инцидентами (Establish incident control system). Разработка управленческих отчетов (Develop management reports). Непрерывное улучшение процесса (Perform continuous process improvement). Управление конфигурациями (Configuration Management) отвечает за поддержание информации о взаимоотношениях между Конфигурационными Единицами (КЕ), за их стандартизцию, мониторинг информации о статусе КЕ, их местоположении и всех изменениях Управление активами учетный процесс мониторинга амортизации активов, который отвечает за поддержку записей в базе данных о цене, амортизации и подразделениях, владеющих этими активами 11 Обеспечение процесса управления качеством (Quality Control Activities) – это организация: системы управления проблемами/известными ошибками (Establish problem/known error control system); превентивных процедур поддержки (Establish preventive maintenance procedures); способов верификации известных ошибок (Establish known error verification facilities); интерфейса поддержки поставщиком (Establish supplier support interfaces), также Разработка отчетов для управления (Develop management reports). Постоянное усовершенствование процесса (Perform continuous process improvement) Цель: оказание помощи в управлении экономическим значением (economic value) ИТ-сервисов (комбинация требований клиентов, качества и затрат) за счет поддержания логической модели инфраструктуры ИТ и ИТсервисов, а также предоставление информации о них другим бизнес-процессам путем идентификации, мониторинга, контроллинга и обеспечения информации о (КЕ) и их версиях. Планирование: определение стратегии, правил и целей для реализации процесса, определение инструментария и ресурсов, определение интерфейсов с другими процессами, проектами, поставщиками и т. д. Идентификация: разработка модели данных для записи в базу конфигураций всех компонент инфраструктуры ИТ, отношений между ними, а также информации о владельцах этих компонент, их статусе и соответствующей документации

ПРИНЦИПЫ ЭФФЕКТИВНОЙ ПОЛИТИКИ РЕАГИРОВАНИЯ НА ИНЦИДЕНТЫ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ 12 1. Руководство организации должно способствовать созданию необходимых условий для внедрения процедуры расследования инцидентов информационной безопасности внутри организации vсоздание формализованной политики реагирования на инциденты; vразработка процедур обработки инцидентов; vурегулирование юридических аспектов обращения информации в процессе расследования; vутверждение структуры команды реагирования на инциденты; vналаживание внутриорганизационных контактов команды по расследованию инцидентов с профиль-ными специалистами; vопределение зон ответственности команды расследования, обучение и техническое оснащение 2. Сокращение инцидентов ИБ путём эффективного использования современных средств защиты сетей, компьютерных систем, программного обеспечения и приложений vпревентивные меры (предотвращение проблем до наступления события инцидента) - менее дорогостоящи, чем работы по ликвидации последствий инцидентов, и являются неотъемлемой частью политики реагирования на инциденты ИБ; vпроцедура реагирования на инциденты и расследование по факту их происшествия будет более эффективной, если определённым видам информационных ресурсов будут поставлены в соответствие адекватные средства технической защиты информации

ПРИНЦИПЫ ЭФФЕКТИВНОЙ ПОЛИТИКИ РЕАГИРОВАНИЯ НА ИНЦИДЕНТЫ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ 13 3. Руководство организации должно способствовать созданию необходимых условий для внедрения процедуры расследования инцидентов информационной безопасности внутри организации vсоздание формализованной политики реагирования на инциденты; vразработка процедур обработки инцидентов; vурегулирование юридических аспектов обращения информации в процессе расследования; vутверждение структуры команды реагирования на инциденты; vналаживание внутриорганизационных контактов команды по расследованию инцидентов с профиль-ными специалистами; vопределение зон ответственности команды расследования, обучение и техническое оснащение 4. Сокращение инцидентов ИБ путём эффективного использования современных средств защиты сетей, компьютерных систем, программного обеспечения и приложений vпревентивные меры (предотвращение проблем до наступления события инцидента) - менее дорогостоящи, чем работы по ликвидации последствий инцидентов, и являются неотъемлемой частью политики реагирования на инциденты ИБ; vпроцедура реагирования на инциденты и расследование по факту их происшествия будет более эффективной, если определённым видам информационных ресурсов будут поставлены в соответствие адекватные средства технической защиты информации

ПРИНЦИПЫ ЭФФЕКТИВНОЙ ПОЛИТИКИ РЕАГИРОВАНИЯ НА ИНЦИДЕНТЫ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ 5. Документирование руководящих принципов и процедур расследования инцидентов ИБ для обеспечения внутриорганизационного взаимодействия и формирования представлений в органы государственной власти 14 vв процессе расследования инцидента, возможно, потребуется общаться со сторонними организациями с целью доведения расследования до логичного завершения (СМИ, органы правопорядка, пострадавшие со стороны третьих лиц); vв случае несоразмерного разглашения конфиденциальной информации, связанной с результатами расследования инцидента, ущерб от может быть соизмерим или превышать ущерб, нанесённый вследствие самого инцидента; vурегулированию проблемы несоразмерного разглашения служит создание контактных позиций (POC - point of contact), структура и правомочность которых оговаривается на этапе формирования политики расследования инцидентов и представляет собой юридически закреплённую доверительную среду участников информационного обмена 6. Информирование о результатах расследования инцидента своих сотрудников и партнёров 7. Структуризация и приоритизация потока информации о v средства IDS ежедневно фиксируют множество возможных инцидентах ИБ, событий, единицы из которых отражают уязвимости поступающей от технических либо попытки их реализации средств мониторинга и сбора данных

ПРИНЦИПЫ ЭФФЕКТИВНОЙ ПОЛИТИКИ РЕАГИРОВАНИЯ НА ИНЦИДЕНТЫ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ 8. Формализация принципов приоритизации событий информационной безопасности 9. Анализ инцидентов и обработка результатов с целью получения практического опыта 15 vопределение степени критичности рассматриваемого ресурса и степени критичности воздействия на рассматриваемый ресурс (эффект инцидента); vучет популярности (востребованности) ресурса; vпредставление предположений о критичности активов в матричной форме, когда действия команды по расследованию инцидентов формализуются и представляются в виде Соглашения об уровне обслуживания (SLA - Service Level Agreement), где подробно определяются действия каждого сотрудника и время реакции на определённые события vпосле обработки инцидента результаты расследования должны быть документированы и внесены в базу данных инцидентов ИБ; vзавершение расследования должно сопровождаться совместным обсуждением его результатов со всеми привлечёнными и заинтересованными сторонами; vгруппа расследования инцидентов должна сделать выводы об уязвимостях, классифицировать их и принять меры к недопущению; vобеспечить понимание причинно-следственных связей в процессе расследования инцидентов vк расследованию сложных инцидентов привлекаются специалисты из различных подразделений, решающим фактором проведения успешного расследования является консолидация действий сотрудников и внедрение практики ролевого управления расследованием

ОТКАЗ В ОБСЛУЖИВАНИИ ИНЦИДЕНТ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ 16 Два основных типа: уничтожение ресурсов и истощение ресурсов могут возникать случайно, например в результате ошибки в конфигурации, допущенной оператором, или из-за несовместимости прикладного программного обеспечения, а другие – преднамеренными, с целью разрушения системы, сервиса и снижения производительности сети, тогда как другие - всего лишь побочными продуктами иной вредоносной деятельности. Например, некоторые наиболее распространенные методы скрытого сканирования и идентификации могут приводить к полному разрушению старых или ошибочно сконфигурированных систем или сервисов при их сканировании. Некоторыми типичными примерами «отказа в обслуживании» являются: - зондирование сетевых широковещательных адресов с целью полного заполнения полосы пропускания сети трафиком ответных сообщений; - передача данных в непредусмотренном формате в систему, сервис или сеть в попытке разрушить или нарушить их нормальную работу; - одновременное открытие нескольких сеансов с конкретной системой, сервисом или сетью в попытке исчерпать их ресурсы (то есть замедление их работы, блокирование или разрушение). Инциденты ИБ «отказ в обслуживании» , создаваемые нетехническими средствами и приводящие к утрате информации, сервиса и (или) устройств обработки информации, могут вызываться следующими факторами: - нарушениями систем физической защиты, приводящими к хищениям, преднамеренному нанесению ущерба или разрушению оборудования; - случайным нанесением ущерба аппаратуре и (или) ее местоположению от огня или воды/наводнения; - экстремальными условиями окружающей среды, например высокой температурой (вследствие выхода из строя системы кондиционирования воздуха); - неправильным функционированием или перегрузкой системы; - неконтролируемыми изменениями в системе; - неправильным функционированием программного или аппаратного обеспечения. ГОСТ Р ИСО/МЭК ТО 18044 -2007

СБОР ИНФОРМАЦИИ ИНЦИДЕНТ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ 17 Инциденты «сбор информации» подразумевают действия, связанные с определением потенциальных целей атаки и получением представления о сервисах, работающих на идентифицированных целях атаки, и предполагают проведение разведки с целью: - определения наличия цели, получения представления об окружающей ее сетевой топологии и о том, с кем обычно эта цель связана обменом информации; - вскрытия потенциальных уязвимостей цели или непосредственно окружающей ее сетевой среды, которые можно использовать для атаки. Типичными примерами таких атак являются: - сбрасывание записей DNS (системы доменных имен) для целевого домена Интернета; - отправка тестовых запросов по случайным сетевым адресам с целью найти работающие системы; - зондирование системы с целью идентификации (например, по контрольной сумме файлов) операционной системы хоста; - сканирование доступных сетевых портов на протокол передачи файлов системе с целью идентификации соответствующих сервисов (например электронная почта, протокол FTP, сеть и т. д. ) и версий программного обеспечения этих сервисов; - сканирование одного или нескольких сервисов с известными уязвимостями по диапазону сетевых адресов (горизонтальное сканирование). В некоторых случаях технический сбор информации расширяется и переходит в НСД С применением автоматизированных средств взлома, которые не только производят поиск уязвимости, но и автоматически пытаются использовать уязвимые системы, сервисы и(или) сети. Инциденты такого вида приводят к: - прямому или косвенному раскрытию или модификации информации; - хищению интеллектуальной собственности, хранимой в электронной форме; - нарушению учетности, например, при регистрации учетных записей; - неправильному использованию информационных систем (например, с нарушением закона или политики организации). Инциденты «сбор информации» могут вызываться следующими факторами: - нарушениями физической защиты безопасности, приводящими к несанкционированному доступу к информации и хищению устройств хранения данных, содержащих значимые данные, например ключи шифрования; - неудачно и (или) неправильно конфигурированными операционными системами по причине неконтролируемых изменений в системе или неправильным функционированием программного или аппаратного обеспечения, приводящим к тому, что персонал организации или посторонний персонал получает доступ к информации, не имея на это разрешения. ГОСТ Р ИСО/МЭК ТО 18044 -2007

НЕСАНКЦИОНИРОВАННЫЙ ДОСТУП ИНЦИДЕНТ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ 18 Несанкционированный доступ как тип инцидента включает в себя инциденты, не вошедшие в первые два типа, и состоит из несанкционированных попыток доступа в систему или неправильного использования системы, сервиса или сети. Примеры несанкционированного доступа с помощью технических средств: v v попытки извлечь файлы с паролями; атаки переполнения буфера с целью получения привилегированного (например, на уровне системного администратора) доступа к сети; v использование уязвимостей протокола для перехвата соединения или ложного направления легитимных сетевых соединений; v попытки расширить привилегии доступа к ресурсам или информации по сравнению с легитимно имеющимися у пользователя или администратора. Инциденты несанкционированного доступа, создаваемые нетехническими средствами, которые приводят к прямому или косвенному раскрытию или модификации информации, нарушениям учетности или неправильному использованию информационных систем, могут вызываться следующими факторами: разрушением устройств физической защиты с последующим несанкционированным доступом к информации; неудачной и (или) неправильной конфигурацией операционной системы вследствие неконтролируемых изменений в системе или неправильного функционирования программного или аппаратного обеспечения ГОСТ Р ИСО/МЭК ТО 18044 -2007

ПОЛИТИКА МЕНЕДЖМЕНТА ИНЦИДЕНТОВ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ 19 v значимость менеджмента инцидентов ИБ для организации, а также обязательства высшего руководства относительно поддержки менеджмента и его системы; v общее представление об обнаружении событий ИБ, оповещении о них и сборе соответствующей информации, а также о путях использования этой информации для определения инцидентов ИБ (перечень возможных событий ИБ, а также информацию о том, как сообщать о ней, что, где и кому сообщать, а также как обращаться с совершенно новыми событиями ИБ); v общее представление об оценке инцидентов ИБ (перечень ответственных лиц, необходимые для выполнения действия, уведомления об инцидентах и дальнейшие действия ответственных лиц); v краткое изложение действий после подтверждения того, что событие является инцидентом ИБ, включающее: немедленное реагирование; правовую экспертизу; передачу информации соответствующему персоналу или сторонним организациям; проверку, находится ли инцидент ИБ под контролем; объявление «кризисной ситуации» ; определение критериев усиления реагирования на инциденты ИБ; определение ответственного за инцидент лица; ссылку на необходимость правильной регистрации всех действий для дальнейшего и непрерывного мониторинга на случай их востребования для судебного разбирательства или дисциплинарного расследования; действия, следующие за разрешением инцидента, включая извлечение урока и улучшение процесса; v подробности места хранения документации о системе, включая процедуры хранения; v общее представление о деятельности ГРИИБ, включающее в себя: организационную структуру ГРИИБ и весь основной персонал группы, включая лиц, ответственных за краткое информирование высшего руководства об инцидентах; проведение расследований и другие действия персонала группы после объявления «кризисной ситуации» ; связь со сторонними организациями (при необходимости); положение о менеджменте ИБ, область деятельности ГРИИБ и полномочия, в рамках которых она будет ее осуществлять. Это положение должно включать в себя, как минимум, формулировку целевого назначения, определение области деятельности ГРИИБ и подробности об учредителе ГРИИБ и его полномочиях; формулировку целей ГРИИБ применительно к основной деятельности группы персонала; определение сферы деятельности ГРИИБ - все информационные системы, сервисы и сети организации. В некоторых случаях для организации может потребоваться сужение сферы действия ГРИИБ; личность учредителя ГРИИБ - старшего должностного лица (член правления, старший руководитель), который санкционирует действия ГРИИБ и устанавливает уровни полномочий, переданных ГРИИБ; v общее представление о программе обеспечения осведомленности и обучения менеджменту инцидентов ИБ; v перечень правовых и нормативных аспектов ГОСТ Р ИСО/МЭК ТО 18044 -2007

ПОЛИТИКА РАССЛЕДОВАНИЯ ИНЦИДЕНТОВ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ 20 vпонимание руководством организации необходимости реагирования на инциденты информационной безопасности; vуправление процедурой расследования инцидентов информационной безопасности; vопределение целей и места политики расследования инцидентов в общей структуре процессов управления безопасностью и организацией в целом (политика расследования инцидентов является частью процесса обеспечения непрерывности функционирования организации); vопределение понятий «инцидент информационной безопасности» и «последствия инцидента информационной безопасности» в контексте сферы деятельности организации; vописание состава, структуры, функциональных обязанностей, зон ответственности, ролей, правил внутриорганизационного взаимодействия, порядка внешних контактов команды по расследованию инцидентов информационной безопасности; vпорядок установления приоритетов инцидентов и оценки серьёзности последствий инцидентов информационной безопасности; vоценка критериев качества работы команды по расследованию инцидентов; vразработка форм отчётности и регламента оповещений об инциденте; vразработка набора процедур, описывающих действие сотрудников организации в случае инцидента (выделенный телефон, адрес электронной почты); vразработка стандартных операционных процедур (SOPs – Standard Operating Procedures), подробно описывающих действия сотрудников команды реагирования в процессе обработки инцидента информационной безопасности; vпорядок пересмотра, тестирования и актуализации стандартных операционных процедур ГОСТ Р ИСО/МЭК ТО 18044 -2007

МОДЕЛИ КОМАНДЫ ПО РАССЛЕДОВАНИЮ ИНЦИДЕНТОВ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ Централизованная модель – в виде единственной на всю организацию структуры, состоящей из трёх линий поддержки: call center (телефон горячей линии), специалисты технической поддержки (управление средствами сбора и анализа данных), группа расследования (аналитическая служба) Распределённая модель – в отличие от централизованной модели имеет дочерние структуры в крупных филиалах или удалённых ВЦ. В данном случае структура команды реагирования головного офиса дополняется службой координации и централизованного хранения данных об инцидентах ИБ 21 Корпоративная модель – реализуется по принципу центра компетенции. Координационный совет по вопросам реагирования на инциденты ИБ обрабатывает консолидированную информацию от юридичес-ких лиц, входящих в корпорацию, и координирует действия дочерних структур Для поддержания процедуры обработки инцидентов ИБ организация должна проводить следующую политику в отношении команды реагирования на инциденты: vфинансирование процедуры обработки инцидентов; vобучение сотрудников профилирующим и смежным дисциплинам; vвовлечение специалистов в процесс обучения сотрудников, написания нормативной и технической документации; vштат команды должен быть полностью укомплектован, должен соблюдаться принцип сегрегации обязанностей; vдолжна поддерживаться практика ротации персонала; vперманентное вовлечение в процесс экспертов по профилирующим областям деятельности с целью поднятия уровня компетенции сотрудников; vпроведение тренингов и тестирования сценариев обработки инцидентов; vвовлечение в процесс расследования инцидентов специалистов др. подразделений: управления, ИБ, телекоммуникации, IT-поддержки, юристов, отдела по связям и общественностью и СМИ, отдела по работе с персоналом и т. д.

РЕСУРСЫ И ИНСТРУМЕНТАРИЙ РАССЛЕДОВАНИЯ ИНЦИДЕНТОВ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ 22 Этап подготовки к расследованию инцидентов заключается в сборе и анализе информации об инцидентах ИБ, обучении персонала и подготовке необходимого инструментария для реагирования на инцидент и его расследования: контактная информация сотрудников подразделения реагирования; телефоны служб технической поддержки; открытый или анонимный канал связи для сообщений о подозрительных действиях; номера мобильных телефонов сотрудников; криптографические средства для обмена информацией в команде реагирования; защищённое переговорное помещение; база данных для хранения свидетельств и результатов расследования инцидентов. В состав инструментария должны входить, также, средства программного обеспечения и аппаратные средства сбора данных: компьютерная система для хранения свидетельств расследования инцидентов; мобильные компьютеры, для удобства работы команды расследования инцидентов; испытательная лаборатория для анализа возможного развития инцидента; комплекты чистых дискет, CD и DVD носителей; принтеры; программное обеспечение для анализа состояния дисковой подсистемы; анализаторы протоколов для анализа сетевого трафика; загрузочные диски всех используемых в организации операционных сред; сопутствующие устройства (диктофоны, цифровые фото и видеокамеры). В процессе анализа инцидента команда реагирования должна иметь доступ ко всем необходимым для анализа ресурсам информационной системы: просмотру состояния портов операционной среды; свидетельству работы операционных систем, приложений, протоколов, систем обнаружения вторжений, сигнатур антивирусов; просмотру статистических журналов работы сети наиболее критичных устройств (WEB – серверы, серверы электронной почты, протоколы работы FTP - серверов); просмотру журналов активности приложений; журналам криптографических средств; операционным системам, для анализа журнальных файлов, в том числе, с правами администратора; данным об загружаемых обновлениях в операционных средах; информации о регламентах резервного копирования и тестировании резервных носителей для возможности реагирования на инцидент (jump kit).

МОДЕЛИ КОМПЛЕКТАЦИИ ПЕРСОНАЛОМ КОМАНДЫ РЕАГИРОВАНИЯ Организация выполняет всю работу по обработке инцидента самостоятельно силами собственного персонала 23 Факторы, влияющие на выбор модели: требуемая доступность информационной системы - 24 часа в сутки, 7 дней в неделю; полная или частичная занятость сотрудников с возможностью экстренной связи с ними; квалификация персонала; стоимость сопровождения инцидентов ИБ; организационная структура предусматривает существование самостоятельных команд по расследованию инцидентов ИБ в составе каждого юридического лица и создание координационного центра в головном представительстве Факторы, влияющие на выбор моделей : процедура перманентного контроля качества оказания услуг с мониторингом событий ИБ, сбор статистических данных об инцидентах с целью отслеживания динамики роста (падения) числа событий и способности системы безопасности пресекать попытки вторжения; разделение полномочий в части администрирования: приоритет принятия решений о перезагрузке оборудования, смены учётных данных пользователей, прочих действий, необходимость в которых возникает в процессе реагирования на инциденты, должен быть оговорен и формализован в виде руководящего документа; разграничение доступа к информации: сторонняя организация не должна иметь достаточных оснований для проведения анализа структуры организации, персональных данных сотрудников, деловой переписки, распределённых каталогов хранения документов организации, прочих критичных активов. Процедура понимание инфраструктуры организации: организация формирует реагирования представления о своей деятельности для фирмы-поставщика услуг с целью правильного понимания инцидентов ИБ, формулирует и и обработки инцидентов полностью формализует в виде руководящего документа своё видение инцидентов, регулярно актуализирует и обновляет информацию; передаётся на корреляция свидетельств инцидентов; обслуживание профилирующей фирме обработка инцидентов с присутствием представителя фирмыпоставщика услуг в процессе расследования; способность реагировать на инциденты самостоятельно. Для данной ситуации разрабатывается аварийный план выхода из инцидента В состав команды расследования инцидентов привлекаются сотрудники профилирующих фирм, а расследование инцидента внутри осуществляет местная команда реагирования

24 2. ЭСКАЛАЦИИ В ПРАКТИКЕ ЗАЩИТЫ ИНФОРМАЦИИ

УРОВНИ ОРГАНИЗАЦИОННЫХ РОЛЕЙ И РАСПРЕДЕЛЕНИЯ ОТВЕТСТВЕННОСТИ – ПЕРВЫЙ УРОВЕНЬ ПОДДЕРЖКИ Организация (подразделение), представляющая первый уровень поддержки обычно относится к оперативным службам. Как правило, она называется диспетчерской службой, Call Center, Help Desk, Service Desk 25 Первый уровень поддержки устанавливает и поддерживает хорошо определенный, единообразно исполняемый, измеряемый соответствующим образом, эффективный процесс управления инцидентами. Предпринимается первая попытка разрешить вопрос с обслуживанием, о котором сообщил конечный пользователь. Задачи: точная регистрация инцидентов (карточка инцидента содержит точное и достаточно детальное описание проблемы; гарантирован правильный выбор важности/приоритета инцидента; определена природа проблемы, контакты пользователя, влияние на бизнес и ожидаемое время решения); владение каждым инцидентом (гарантируется своевременное решение вопросов за счет: разработки и управления планом действий по решению вопроса; инициации конкретных назначений заданий для персонала и бизнес-партнеров; эскалации инцидента, если требуется, когда цель не достигается во время; обеспечения внутреннего взаимодействия в соответствии с целями обслуживания; защиты интересов вовлеченных бизнес-партнеров); использование базы данных управления проблемами для сопоставле-ния инцидентов известным ошибкам и применения ранее найденных способов разрешения инцидентов (цель - в разрешении 80% инцидентов. Остальные передаются (эскалируются) на второй уровень); непрерывное улучшение процесса управления инцидентами (посредст -вом оценки эффективности данного процесса и таких механизмов поддержки, как отчеты, виды связи и форматы сообщений, процедуры эскалации; разработ-ки специфических для подразделений отчетов и процедур; поддержки и совершенствования взаимодействия и списков эскалации); участие в процессе анализа проблем. Способности и навыки персонала: 1. Навыки межличностного общения первостепенны. Персонал первого уровня поддержки вовлечен главным образом в расстановку приоритетов и управление проблемами. На этом уровне поддержки проводятся лишь незначительные технические изыскания. 2. Способность применять «консервированные» решения. Персонал первого уровня должен уметь распознавать симптомы, применять поисковые инструменты для обнаружения ранее разработанных решений и помогать конечным пользователям в применении таких решений Information Technology Infrastructure Library (ITIL)

УРОВНИ ОРГАНИЗАЦИОННЫХ РОЛЕЙ И РАСПРЕДЕЛЕНИЯ ОТВЕТСТВЕННОСТИ – ВТОРОЙ УРОВЕНЬ ПОДДЕРЖКИ Организация (подразделение), представляющая второй уровень поддержки обычно относится к оперативным службам 26 Второй уровень поддержки: изучает, диагностирует и решает большинство инцидентов, которые не были решены на первом уровне и указывают на новые проблемы; обеспечивает эффективный процесс управления проблемами; использует инструменты и процессы, чтобы гарантировать упреждающее управление инфраструктурой. Задачи: решение инцидентов, переданных с первого уровня (второй уровень решает 75% инцидентов, переданных ему первым уровнем, т. е. 15% от числа зарегист-рированных инцидентов - остальные передаются на третий уровень); определение причин проблем (решение проблем передается на третий уровень, когда причина заключается в архитектурном или техническом вопросе, который превышает их уровень квалификации); обеспечение реализации исправлений и устранений проблем (иницииро -вание проектов в организациях-разработчиках для реализации планов устране-ния известных ошибок, документирование найденных решений, сообщение о них персоналу первого уровня и их реализацию). постоянный мониторинг инфраструктуры (идентификация проблемы до возникновения инцидентов посредством наблюдения за компонентами инфраструктуры и принятия корректирующих действий при обнаружении дефектов или ошибочных тенденций). заблаговременный анализ тенденций инцидентов (определить не свидетельствуют ли они о наличии проблем, которые бы вызвали новые инциденты). постоянное совершенствование процесса управления проблемами (гарантируется, что процесс и имеющиеся возможности адекватны и улучшаются при необходимости; проводится анализ проблем). Способности и навыки персонала: 1. Технически компетентны по всем поддерживаемым технологиям, включая сети, сервера и приложения с разумными навыками общения. Общим дефицитом являются знания в области операционных систем и приложений. 2. Знание сетей, серверов и приложений, способность решить инциденты и проблемы по всему спектру технологий, используемых в компании

УРОВНИ ОРГАНИЗАЦИОННЫХ РОЛЕЙ И РАСПРЕДЕЛЕНИЯ ОТВЕТСТВЕННОСТИ – ТРЕТИЙ УРОВЕНЬ ПОДДЕРЖКИ 27 Третий уровень поддержки относится к группе разработки приложений и сетевой инфраструктуры и осуществляет: планирование и проектирование ИТ-инфраструктуры (группа поддержки третьего уровня играет небольшую роль в управлении инцидентами и проблемами, так как занята планированием и конструированием ИТ-инфраструктуры и реализацией бездефектной инфраструктуры, которая не является источником проблем и инцидентов); использование последнего рубежа в эскалации (если инцидент или проблема оказывается выше возможностей группы поддержки второго уровня, то группа поддержки третьего уровня принимает ответственность за поиск решения). Задачи: решение инцидентов, переданных со второго уровня (большинство инцидентов вызывается известными ошибками не более 5% проходит через второй уровень на третий); участие в деятельности по управлению проблемами (поиск причин, способов обхода и устранения ошибок); реализация мер по устранению ошибок из инфраструктуры (планирование, конструирование и реализация проектов по устранению недостатков инфраструктуры, ее развитие ). Способности и навыки персонала: Эксперты в соответствующих областях, планирующие и проектирующие ИТ-инфраструктуру Information Technology Infrastructure Library (ITIL)

Параметр процесса ПРОЦЕСС УПРАВЛЕНИЯ ИНЦИДЕНТАМИ 28 Описание Назначение Восстановить сервис для конечного пользователя, поддерживая высокую степень удовлетворенности Владелец Команда поддержки первого уровня Вход Обращение пользователя с сообщением о прерывании сервиса Выход Сервис восстановлен. Конечный пользователь оповещен. Создана запись об инциденте. Создана запись о возможной проблеме Типичные числовые параметры Количество открытых инцидентов, сгруппированных по уровню серьезности, прошедшему времени, группам ответственности. Количество инцидентов, сгруппированных по времени (помесячно/поквартально). Количество инцидентов, переданных и решенных на каждом уровне. Среднее время, затраченное на инцидент в каждой группе. Среднее время восстановления сервиса. Процент инцидентов, решенных в заданное время. Инциденты по технологиям. Инциденты по пользовательским группам Information Technology Infrastructure Library (ITIL)

ПРОЦЕСС КОНТРОЛЯ ПРОБЛЕМ Параметр процесса 29 Описание Назначение Определить причину проблемы и способ временного или постоянного решения Владелец Команда поддержки второго уровня Вход Инцидент высокого уровня серьезности Инциденты, переданные для решения на третий уровень поддержки Инциденты, выделенные на совещании Выход Документированная причина Сообщение о временных решениях на все уровни поддержки Типичные числовые параметры Количество проблем, сгруппированных по времени (помесячно/ поквартально). Количество проблем, где анализ причин отложен. Количество открытых проблем (причина не выявлена). Среднее время, затраченное на рас -смотрение проблемы на каждом уровне. Среднее время для определения причины. Проблемы по технологиям. Проблемы по пользовательским группам Information Technology Infrastructure Library (ITIL)

ПРОЦЕСС КОНТРОЛЯ ОШИБОК Параметр процесса 30 Описание Назначение Оповещение о методах обхода известных ошибок и обеспечение исправления этих ошибок командами разработки; документирование способов преодоления неисправностей и оповещения о них персонала поддержки; поддержание связи с другими техническими и разрабатывающими организациями и влияние на разработчиков с целью реализации исправлений известных ошибок Владелец Команда поддержки второго уровня Вход Проблемы, причины которых выявлены. Известные ошибки, реализованные через процесс управления изменениями Выход Документированные методы обхода ошибок для различных групп поддержки. Приоритизированный список проектов по исправлению известных ошибок Типичные числовые параметры Количество известных ошибок Количество инцидентов, вызванных известными ошибками Количество проектов, основанных/ реализованных для исправле-ния известных ошибок Стоимость всех проектов по исправлению известных ошибок Information Technology Infrastructure Library (ITIL)

СОДЕРЖАНИЕ И ВИДЫ ЭСКАЛАЦИИ 31 Эскалация проблемы означает вынос проблемы на обсуждение на более высокий уровень при невозможности её решения на текущем. Механизм эскалации помогает своевременно решить инцидент путем увеличения возможностей персонала, уровня усилий и приоритета, нацеленных на решение этого инцидента. Средства управления инцидентами используются для автоматической передачи ответственности на все возрастающий уровень поддержки в соответствии с временными рамками и сложностью. Временные рамки и ответственность в рамках эскалации различаются в зависимости от организации, вида деятельности и уровня сложности проблем. Практикуются переговоры с конечными пользователями для определения подходящих временных рамок и эскалации ответственности. Результат таких переговоров реализуются в виде соглашений об уровне сервиса, автоматизированных средств, списков, шаблонов Функциональная эскалация – передача инцидента на более высокий уровень поддержки, когда знаний или опыта недостаточно или истек согласованный интервал времени. В передовых организациях определяется матрица уровней важности, основанная на степени влияния на бизнес, временных рамках разрешения инцидента и интервалах времени, в которые инцидент должен быть передан в более продвинутую группу. В большинстве организаций группы поддержки первого и второго уровней, ориентированы на эксплуатацию существующей инфраструктуры, тогда как третий уровень поддержки предоставляется обычно группами, которые отвечают за планирование развития инфраструктуры, ее проектирование Иерархическая эскалация – вовлечение в процесс разрешения проблемы руководства, чтобы обеспечить предоставление инциденту соответствующего приоритета и выделение необходимых ресурсов до того, как будут перекрыты временные рамки его разрешения. Иерархическая эскалация может выполняться на любом уровне поддержки, а эскалация к руководству в передовых организациях происходит автоматически в соответствии с предопределенной процедурой на основе серьезности проблемы. После того, как эскалация произошла, ожидается, что соответствующий менеджер активно управляет решением проблем и становится единым контактом для сообщений о статусе

МАТРИЦА ЭСКАЛАЦИИ ПРОБЛЕМЫ Уровень инцидента Описание 1 Свыше 50 пользователей не могут выполнять бизнестранзакции 2 От 10 до 49 пользователей не могут выполнять бизнестранзакции 3 От 1 до 9 пользователей не могут выполнять бизнестранзакции Начальный Срок уровень решения 2 часа 4 часа 8 часов 1 -й уровень поддержки Первая эскалация Вторая эскалация 32 Третья эскалация 0 мин. 30 мин. 2 -й уровень 3 -й уровень поддержки 30 мин. 1 -й менеджер. Экстренное совещание 0 мин. 60 мин. 2 -й уровень 3 -й уровень поддержки 60 мин. 1 -й менеджер. Экстренное совещание 30 мин. 120 мин. 2 -й уровень 3 -й уровень поддержки 120 мин. 1 -й менеджер. Экстренное совещание Information Technology Infrastructure Library (ITIL)