STB_ISO_IEC_27035.pdf

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РЕСПУБЛИКИ БЕЛАРУСЬ

СТБ ISO/IEC 27035/ПР_1

Информационные технологии Методы обеспечения безопасности МЕНЕДЖМЕНТ ИНЦИДЕНТОВ В ОБЛАСТИ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

Iнфармацыйныя тэхналогii Метады забеспячэння бяспекi МЕНЕДЖМЕНТ IНЦЫДЭНТАЎ У ВОБЛАСЦI IНФАРМАЦЫЙНАЙ БЯСПЕКI (ISO/IEC 27035:2011, IDT)

Настоящий проект стандарта не подлежит применению до его утверждения

Госстандарт Минск

СТБ ISO/IEC 27035/ПР_1 __________________________________________________________________________________________ УДК МКС 35.040 КП 05 IDT Ключевые слова: информационная безопасность, система менеджмента информационной безопасности, инциденты в области информационной безопасности, события в области информационной безопасности, уязвимости в области информационной безопасности

Предисловие Цели, основные принципы, положения по государственному регулированию и управлению в области технического нормирования и стандартизации установлены Законом Республики Беларусь "О техническом нормировании и стандартизации". 1 ПОДГОТОВЛЕН И ВНЕСЕН научно-производственным республиканским унитарным предприятием "Научно-исследовательский институт технической защиты информации" (Государственное предприятие "НИИ ТЗИ") 2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ постановлением Госстандарта Республики Беларусь от _______________ № ______ 3 Настоящий стандарт идентичен международному стандарту ISO/IEC 27035:2011 Information technology – Security techniques – Information security incident management (Информационные технологии. Методы обеспечения безопасности. Менеджмент инцидентов в области информационной безопасности). Международный стандарт разработан подкомитетом SC 27 "Методы обеспечения безопасности информационных технологий" объединенного технического комитета по стандартизации ISO/IEC JTC 1 "Информационные технологии" Международной организации по стандартизации (ISO) и Международной электротехнической комиссии (IEC). Перевод с английского языка (en). Официальные экземпляры международного стандарта, на основе которого подготовлен настоящий государственный стандарт, и международных стандартов, на которые даны ссылки, имеются в Национальном фонде ТНПА. В разделе "Нормативные ссылки" и тексте стандарта ссылки на международные стандарты актуализированы. Сведения о соответствии государственных стандартов ссылочным международным стандартам приведены в дополнительном приложении Д.А. Степень соответствия – идентичная (IDT). 4 ВВЕДЕН ВПЕРВЫЕ

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

II

СТБ ISO/IEC 27035/ПР_1

Содержание Введение .............................................................................................................................................................. IV  1 Область применения ..........................................................................................................................................1  2 Нормативные ссылки..........................................................................................................................................1  3 Термины и определения ....................................................................................................................................2  4 Общие требования .............................................................................................................................................2  4.1 Основные понятия .......................................................................................................................................2  4.2 Менеджмент безопасности .........................................................................................................................3  4.3 Преимущества структурированного подхода ............................................................................................4  4.4 Применяемость ............................................................................................................................................5  4.5 Этапы ............................................................................................................................................................5  4.6 Примеры инцидентов в области информационной безопасности ..........................................................6  5 Этап планирования и подготовки ......................................................................................................................7  5.1 Обзор ключевых направлений деятельности ...........................................................................................7  5.2 Политика менеджмента инцидентов в области информационной безопасности .................................9  5.3 Интеграция менеджмента инцидентов в области информационной безопасности в другие политики............................................................................................................................................................10  5.4 Схема управления инцидентами в области информационной безопасности ....................................11  5.5 Создание ISIRT ..........................................................................................................................................15  5.7 Обучение и повышение осведомленности ..............................................................................................17  5.8 Тестирование системы менеджмента......................................................................................................18  6 Этап обнаружения и оповещения об инцидентах в области информационной безопасности .................18  6.1 Обзор ключевых направлений деятельности .........................................................................................18  6.2 Обнаружение события в области информационной безопасности ......................................................21  6.3 Оповещение о событии в области информационной безопасности ....................................................21  7 Этап оценки и принятия решений ...................................................................................................................22  7.1 Обзор ключевых направлений деятельности .........................................................................................22  7.2 Оценка и предварительное решение PoC...............................................................................................23  7.3 Оценка и подтверждение инцидента ISIRT .............................................................................................25  8 Этап принятия ответных мер ...........................................................................................................................26  8.1 Обзор ключевых направлений деятельности .........................................................................................26  8.2 Ответные меры ..........................................................................................................................................27  8.2.1 Немедленное реагирование ..................................................................................................................27  8.2.1.1 Общие положения ...............................................................................................................................27  8.2.1.2 Примерные действия по реагированию ............................................................................................28  8.2.1.3 Обновление информации об инцидентах .........................................................................................28  8.2.1.4 Дополнительные действия .................................................................................................................29  8.2.2 Оценка контролируемости инцидентов в области информационной безопасности ........................30  8.2.3 Последующие ответные меры...............................................................................................................30  8.2.4 Антикризисные ответные меры .............................................................................................................31  8.2.5 Экспертный анализ информационной безопасности ..........................................................................31  9 Этап извлеченные уроки ..................................................................................................................................34  9.1 Обзор ключевых направлений деятельности .........................................................................................34  9.2 Дальнейший экспертный анализ информационной безопасности .......................................................34  9.3 Идентификация извлеченных уроков ......................................................................................................34  9.4 Идентификация и усовершенствование процесса осуществления контроля над информационной безопасностью ...................................................................................................................35  9.5 Идентификация и усовершенствование процесса оценки риска информационной безопасности и результатов анализа менеджмента ............................................................................................................36  9.6 Идентификация и усовершенствование системы менеджмента инцидентов в области информационной безопасности .....................................................................................................................36  9.7 Другие усовершенствования ....................................................................................................................36  Приложение A (справочное) Таблица перекрестных ссылок ISO/IEC 27001 и ISO/IEC 27035 ....................37  Приложение B (справочное) Примеры инцидентов в области информационной безопасности и их причин ...39  Приложение C (справочное) Пример подходов к категоризации и классификации событий и инцидентов в области информационной безопасности ...................................................................................42  Приложение D (справочное) Пример отчетов о событиях, инцидентах и уязвимостях в области информационной безопасности и образец формы отчета ..............................................................................52  Приложение Д.А (справочное) Сведения о соответствии государственных стандартов ссылочным международным стандартам ..............................................................................................................................68  III

СТБ ISO/IEC 27035/ПР_1 Введение Политика информационной безопасности и средства управления сами по себе не могут гарантировать полную защиту информации информационных систем, сервисов или сетей. После внедрения средств управления, вероятно, останутся слабые стороны, которые могут сделать обеспечение информационной безопасности не эффективным, и, следовательно, инциденты в области информационной безопасности возможными. Инциденты информационной безопасности могут оказывать прямое или косвенное негативное воздействие на бизнес-деятельность организации. Кроме того, будут неизбежно выявляться новые, ранее не идентифицированные угрозы. Недостаточная готовность организации к обработке таких инцидентов делает любую реакцию на инциденты малоэффективной и это потенциально увеличивает степень негативного воздействия на бизнес. Таким образом, для любой организации, серьезно относящейся к информационной безопасности, важно применять структурированный и плановый подход к:  обнаружению, оповещению об инцидентах в области информационной безопасности и их оценке;  реагированию на инциденты в области информационной безопасности, включая активизацию соответствующих средств управления для предотвращения, уменьшения последствий и (или) восстановления после негативных воздействий (например, в поддержку областей антикризисного менеджмента);  оповещению об уязвимостях в области информационной безопасности, которые до настоящего времени недостаточно изучены, чтобы обусловить проведение мероприятий информационной безопасности и о возможных инцидентах в области информационной безопасности, их оценке и разрешении их соответствующим образом;  извлечению уроков из инцидентов в области информационной безопасности и уязвимостей, введению профилактических средств управления и улучшению общего подхода к менеджменту инцидентов в области информационной безопасности. Настоящий документ содержит рекомендации по менеджменту инцидентов в области информационной безопасности в разделах 4–9. Данные разделы состоят из нескольких подразделов, которые включают в себя подробное описание каждого этапа. Термин “менеджмент инцидентов в области информационной безопасности” используется в настоящем стандарте для обозначения менеджмента не только инцидентов в области информационной безопасности, но и уязвимостей в области информационной безопасности.

IV

СТБ ISO/IEC 27035/ПР_1

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РЕСПУБЛИКИ БЕЛАРУСЬ Информационные технологии Методы и средства обеспечения безопасности МЕНЕДЖМЕНТ ИНЦИДЕНТОВ В ОБЛАСТИ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ Iнфармацыйныя тэхналогii Метады i сродкi забеспячэння бяспекi МЕНЕДЖМЕНТ IНЦЫДЭНТАЎ У ВОБЛАСЦI IНФАРМАЦЫЙНАЙ БЯСПЕКI Information technology Security techniques Information security incident management Дата введения 20ХХ-ХХ-ХХ

1 Область применения Настоящий стандарт обеспечивает структурированный и плановый подход к: a) обнаружению, оповещению об инцидентах в области информационной безопасности и их оценке; b) реагированию на инциденты в области информационной безопасности и управлению ими; c) обнаружению, оценке и управлению уязвимостями информационной безопасности; и d) непрерывному улучшению информационной безопасности и менеджмента инцидентов в результате управления инцидентами и уязвимостями в области информационной безопасности. В настоящем стандарте содержатся рекомендации по менеджменту инцидентов в области информационной безопасности для крупных и средних организаций. Малые предприятия могут использовать базовый набор документов, процессов и процедур, описанных в настоящем стандарте, в зависимости от их размера и типа бизнеса в отношении ситуации риска информационной безопасности. В нем также приведены рекомендации для внешних организаций, обеспечивающих менеджмент инцидентов в области информационной безопасности в сфере услуг.

2 Нормативные ссылки Для применения настоящего стандарта необходимы следующие ссылочные стандарты. Для датированных ссылок применяют только указанное издание ссылочного стандарта, для недатированных ссылок применяют последнее издание ссылочного стандарта (включая все его изменения). ISO/IEC 270001Информационные технологии. Методы обеспечения безопасности. Системы менеджмента информационной безопасности. Общий обзор и словарь.

__________________________________________________________________________________________ Проект, первая редакция 1

На территории Республики Беларусь действует СТБ ISO/IEC 27000-2012

1

СТБ ISO/IEC 27035/ПР_1 3 Термины и определения В настоящем стандарте применяют термины и определения, содержащиеся в ISO/IEC 15408-1, ISO/IEC 18045, а также следующие термины с соответствующими определениями: 3.1 группа реагирования на инциденты в области информационной безопасности (information security incident response team) ISIRT: Группа квалифицированных и надежных членов организации, которая обрабатывает инциденты в области информационной безопасности на протяжении всего их жизненного цикла. Примечание – ISIRT в соответствии с текстом настоящего стандарта – это организационная функция, которая охватывает процесс реагирования на инциденты в области информационной безопасности и ориентирована в основном на инциденты, связанные с информационными технологиями. Другие общие функции (аналогичные аббревиатуры) в обработке инцидентов могут иметь несколько иную цель и область применения. Следующие общепринятые сокращения имеют смысл, аналогичный ISIRT, хотя и не точно такой же:

 CERT: Компьютерная группа быстрого реагирования, ориентированная в основном на инциденты в области информации и коммуникационных технологий (ICT). Могут быть и другие, специальные для государства, определения CERT.  CSIRT: Группа реагирования на инциденты компьютерной безопасности – это сервисная организация, которая несет ответственность за получение, рассмотрение и реагирование на сообщения об и деятельность в отношении инцидентов компьютерной безопасности. Данные услуги, как правило, предоставляются для определенного избирательного округа, который мог бы быть головным предприятием, например, корпорация, правительственная организация, или образовательная организация региона или страны; исследовательской сети; или заплатившего клиента. 3.2 инцидент в области информационной безопасности (information security incident): Одно или ряд нежелательных или непредвиденных событий в области информационной безопасности, при которых имеется значительная вероятность компрометации функционирования бизнеса и угрозы информационной безопасности. [ISO/IEC 27000:2009] 3.3 событие в области информационной безопасности (information security event): Идентифицированное возникновение состояния системы, услуги или сети, указывающее на возможное нарушение политики в области информационной безопасности или отказ средств управления, а также возникновение ранее неизвестной ситуации, которая может быть связана с безопасностью. [ISO/IEC 27000:2009] 3.4 экспертиза информационной безопасности (information security forensics): Применение методов исследования и анализа для регистрации, записи об и проведения анализа инцидентов в области информационной безопасности.

4 Общие требования 4.1 Основные понятия Событие в области информационной безопасности – это идентифицированное состояние системы, услуги или сети, указывающее на возможное нарушение политики в области информационной безопасности или отказ средств управления, а также возникновение ранее неизвестной ситуации, которая может быть связана с безопасностью. Инцидент в области информационной безопасности – это одно или ряд нежелательных или непредвиденных событий в области информационной безопасности, при которых имеется значительная вероятность компрометации функционирования бизнеса и угрозы информационной безопасности. Возникновение события в области информационной безопасности не обязательно означает, что попытка была успешной или, что есть какие-то воздействия на конфиденциальность, целостность и/или доступность, т.е. не все события в области информационной безопасности классифицируются как инциденты в области информационной безопасности. Угроза действует таким способом, чтобы использовать уязвимости (слабые стороны) информационных систем, серверов или сетей, которые заключаются в возникновении событий в области информационной безопасности и, возможно, вызывают нежелательные инциденты по отношению к информационным активам, подверженным уязвимостям. На рисунке 1 показано данное отношение между объектами в цепочке инцидентов в области информационной безопасности. Затененные объекты подвержены влиянию незатененных объектов в цепочке, что приводит к инциденту в области информационной безопасности.

2

СТБ ISO/IEC 27035/ПР_1

Угроза

вызывает

Нежелательное действие

использует

Уязвимость информационной безопасности

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

Инцидент в области информационной безопасности

Событие в области информационной безопасности

воздействия на

влияет на

Информационный актив

Затененные объекты подвержены влиянию незатененных объектов в цепочке, что приводит к инциденту в области информационной безопасности Рисунок 1 – Отношение между объектами в цепочке инцидентов в области информационной безопасности

4.2 Менеджмент безопасности В качестве основы общей стратегии информационной безопасности организации, организация должна установить необходимые средства управления и процедуры, позволяющие обеспечить структурный и спланированный подход к менеджменту инцидентов в области информационной безопасности. С точки зрения бизнеса первоочередной задачей является избежать или ослабить воздействие инцидентов в области информационной безопасности для снижения прямых и косвенных расходов, вызванных инцидентами. Основные шаги, чтобы свести к минимуму негативное воздействие инцидентов в области информационной безопасности, следующие:  остановить и ослабить;  устранить;  анализ и отчетность;  проверка исполнения. Задачи структурированного подхода должны обеспечить следующее: a) события в области информационной безопасности выявляются и обрабатываются эффективно, в частности в определении того, должны они быть категорированы и классифицированы как инциденты в области информационной безопасности или нет; b) выявленные инциденты в области информационной безопасности оцениваются, и реагирование на них происходит наиболее подходящим и эффективным способом; c) негативные воздействия инцидентов в области информационной безопасности на организацию и ее деятельность минимизируются с помощью соответствующих средств управления, как часть реагирования на инциденты; d) сообщаемые уязвимости информационной безопасности оцениваются и обрабатываются надлежащим образом; e) оперативное извлечение уроков из инцидентов в области информационной безопасности, уязвимостей и связанных с ними менеджментом. Это увеличит шансы предотвратить возникновение в будущем инцидентов в области информационной безопасности, усовершенствовать внедрение и использование средств управления информационной безопасности, а также усовершенствовать общую систему менеджмента информационной безопасности. Чтобы этого добиться, организациям следует обеспечить, чтобы инциденты в области информационной безопасности регистрировались в соответствующем порядке, используя соответствующие стандарты для категоризации и классификации инцидентов и чтобы количественные показатели создавались из обобщенных данных за определенный период времени. Это дает информацию для оказания помощи в принятии стратегических решений при инвестировании в средства управления информационной безопасностью. Подтверждено, что другой задачей, связанной с настоящим стандартом, является предоставление руководства организациям, которые стремятся соответствовать требованиям, указанным в ISO/IEC 27001 (и таким образом поддерживается руководством из ISO/IEC 27002). Это включает в себя требования, 3

СТБ ISO/IEC 27035/ПР_1 связанные с менеджментом инцидентов в области информационной безопасности. Таблица перекрестных ссылок менеджмента инцидентов в области информационной безопасности на соответствующие пункты ISO/IEC 27001 B ISO/IEC 27002 и пункты настоящего стандарта, приведена в приложении A. 4.3 Преимущества структурированного подхода Любая организация, использующая структурный подход к менеджменту инцидентов в области информационной безопасности, может извлечь из него значительные преимущества, которые можно объединить в следующие группы: a) повышение общей информационной безопасности. Структурированный подход к вопросам обнаружения, оповещения, оценки и принятия решений относительно инцидентов и событий в области информационной безопасности, позволяет быстро идентифицировать любое событие или инцидент в области информационной безопасности и реагировать на них, тем самым повышая общую безопасность за счет быстрого выявления и реализации правильного решения, а также обеспечивая средства предотвращения подобных инцидентов в области информационной безопасности в будущем. Далее будут представлены преимущества, которым поспособствовали количественные показатели, обмен информацией и статистическая обработка. Авторитет организации повышается за счет демонстрации ее внедрения лучших практик в отношении менеджмента инцидентов в области информационной безопасности; b) снижение негативных воздействий на бизнес. Структурный подход к менеджменту инцидентов в области информационной безопасности может способствовать снижению уровня потенциальных негативных воздействий, связанных с инцидентами в области информационной безопасности, на бизнес. Последствия этих воздействий могут включать в себя немедленные финансовые убытки, а также долговременные потери, возникающие от ущерба, нанесенного репутации и кредитоспособности организации (для получения руководства по проведению анализа влияния на бизнес см. ISO/IEC 27005:2008); c) усиление внимания к предотвращению инцидентов. Использование структурного подхода к менеджменту инцидентов в области информационной безопасности может способствовать усилению внимания к предотвращению инцидентов внутри организации, включая методы выявления новых угроз и уязвимостей. Анализ данных, связанных с инцидентами, позволяет определить модели и тенденции появления инцидентов, тем самым способствуя усилению внимания к предотвращению инцидентов и, следовательно, определению соответствующих действий по предотвращению возникновения инцидентов; d) усиление системы установления приоритетов. Структурный подход к менеджменту инцидентов в области информационной безопасности создает прочную основу для системы установления приоритетов при проведении расследований инцидентов в области информационной безопасности, включая использование эффективной шкалы категоризации и классификационной шкалы. При отсутствии четких процедур существует риск того, что расследования проводятся в непостоянном режиме, когда реагирование на инциденты осуществляется по мере их появления и упуская из виду необходимые виды деятельности. Это может помешать проведению расследования в последовательности, соответствующей идеальному установлению приоритетов там, где оно действительно необходимо; e) укрепление доказательной базы. Четкие процедуры расследования инцидентов могут обеспечить правильность и правовую допустимость сбора данных и их обработки. Они имеют большое значение в случае инициирования судебного преследования или дисциплинарного разбирательства. Однако следует признать вероятность того, что действия, необходимые для восстановления после инцидента в области информационной безопасности, могут подвергнуть риску целостность любых собранных доказательств такого рода; f) содействие обоснованию бюджета и ресурсов. Хорошо продуманный структурный подход к менеджменту инцидентов в области информационной безопасности способствует обоснованию и упрощению распределения бюджета и ресурсов внутри подразделений организации. Кроме того, преимущества получает и сама схема управления инцидентов в области информационной безопасности, связанная с: – использованием менее квалифицированного персонала для идентификации и фильтрации ложных сигналов тревоги; – обеспечением лучшего руководства действиями квалифицированного персонала; – привлечением квалифицированного персонала только для тех процессов, где требуются его навыки, и только на той стадии процесса, где его содействие необходимо. Еще один подход для управления и оптимизации бюджета и ресурсов предприятия заключается в отслеживании времени инцидентов в области информационной безопасности с целью количественных оценок обработки инцидентов в области информационной безопасности в организации. Это делает возможным, например, предоставление информации о времени разрешения инцидентов с различными приоритетами на различных платформах. При наличии слабых мест в процессе менеджмента инцидентов в области информационной безопасности они также должны быть идентифицируемыми; 4

СТБ ISO/IEC 27035/ПР_1 g) обновление результатов менеджмента и анализа рисков информационной безопасности на более высоком уровне. Использование структурного подхода к менеджменту инцидентов в области информационной безопасности способствует: – сбору более качественных данных для идентификации и определения характеристик различных типов угроз и связанных с ними уязвимостей; – предоставлению данных о частоте возникновения идентифицированных типов угроз. Полученные данные о негативных воздействиях инцидентов в области информационной безопасности на функционирование бизнеса будут полезны для анализа влияния на бизнес. Полученные данные о частоте возникновения различных типов угроз намного повысят качество оценки угроз. Аналогично, полученные данные об уязвимостях намного повысят качество будущих оценок уязвимостей (для получения руководства по оценке и менеджменту рисков в области информационной безопасности см. ISO/IEC 27005:2008). h) предоставление материала для программ повышения осведомленности и обучения в области информационной безопасности. Структурный подход к менеджменту инцидентов в области информационной безопасности предоставляет узконаправленную информацию о программах обеспечения осведомленности в вопросах в области информационной безопасности. Эта информация приводит реальные примеры, демонстрирующие, что инциденты в области информационной безопасности случаются с реальными организациями. Можно также показать преимущества быстрого получения информации о решениях. Более того, подобная осведомленность в вопросах в области информационной безопасности позволяет снизить вероятность ошибки или возникновения паники/растерянности у людей в случае инцидента в области информационной безопасности; i) предоставление входных данных для анализа политики в области информационной безопасности и соответствующей документации. Информация, предоставляемая системой менеджмента инцидентов в области информационной безопасности, может обеспечить ценные входные данные для анализа результативности и последующего улучшения политики в области информационной безопасности (и другой документации, связанной с информационной безопасностью). Это относится к политике и другой документации как на уровне организации, так и для отдельных систем, услуг и сетей. 4.4 Применяемость Руководство, предоставленное настоящим стандартом, обширно и, если будет принято в полном объеме, могут потребоваться значительные ресурсы для обеспечения функционирования и управления. Поэтому важно, что организация, применяя эти руководящие принципы, должна сохранять чувство перспективы и обеспечить, чтобы ресурсы, применяемые для менеджмента инцидентов в области информационной безопасности и сложность реализованных механизмов, сохранялись в следующей пропорции: a) размер, структура и деловой характер организации; b) область применения любой системы менеджмента информационной безопасности, в рамках которой инциденты обрабатываются; c) потенциальная потеря через возникающие инциденты, которые невозможно предупредить; d) цели бизнеса. Организации, использующей настоящий стандарт, следует, принять его руководство пропорционально масштабу и особенностям их бизнеса. 4.5 Этапы Для достижения задач в соответствии с подразделом 4.2 менеджмент инцидентов в области информационной безопасности состоит из пяти отдельных этапов:  планирование и подготовка;  обнаружение и оповещение об инцидентах в области информационной безопасности;  оценка и принятие решения;  ответные меры;  извлеченные уроки. Первый этап предполагает получение всего, что требуется для проведения успешного менеджмента в области инцидентов в области информационной безопасности. Остальные четыре этапа предусматривают оперативное использование менеджмента в области инцидентов в области информационной безопасности. Высокоуровневое представление этих этапов показано на рисунке 2.

5

СТБ ISO/IEC 27035/ПР_1 Планирование и подготовка  политика менеджмента инцидентов в области информационной безопасности и обязательства высшего руководства;  обновления политики в области информационной безопасности и менеджмента рисков, как на корпоративном уровне, так и на уровне системы, обслуживания и сети;  схема управления инцидентами в области информационной безопасности;  создание группы реагирования на инциденты в области информационной безопасности;  техническая и другая поддержка (включая сопровождение);  обучение и информационные брифинги в области менеджмента инцидентов в области информационной безопасности;  схема тестирования менеджмента инцидентов в области информационной безопасности

Обнаружение и оповещение об инцидентах информационной безопасности  обнаружение события информационной безопасности и оповещение о нем

Оценка и принятие решения  оценка события в области информационной безопасности и принятие решения о том, является ли оно инцидентом в области информационной безопасности

Ответные меры  ответные меры на инцидент информационной безопасности, включая экспертный анализ;  восстановление после инцидента информационной безопасности

Извлеченные уроки дальнейший экспертный анализ при необходимости; идентификация извлеченных уроков; выявление и совершенствование информационной безопасности; выявление и совершенствование результатов оценки рисков информационной безопасности и результатов анализа менеджмента;  выявление и совершенствования системы менеджмента инцидентов информационной безопасности

   

Рисунок 2 – Этапы менеджмента инцидентов в области информационной безопасности 4.6 Примеры инцидентов в области информационной безопасности Инциденты в области информационной безопасности могут быть преднамеренными или аварийными (например, вызванные ошибкой или стихийным бедствием), и могут быть вызваны техническими или физическими средствами. Их последствия могут включать в себя разглашение, модификацию, уничтожение или недоступность информации несанкционированным образом, или повреждения, или хищения организационных активов. Если события в области информационной безопасности, о которых не было сообщено, определяются как инциденты, это осложняет расследование инцидентов и взятие под контроль в целях предотвращения рецидива. Приложение B содержит описания выбранных примеров инцидентов в области информационной безопасности и их причин исключительно для информативных целей. Важно отметить, что эти примеры не являются исчерпывающими.

6

СТБ ISO/IEC 27035/ПР_1 5 Этап планирования и подготовки 5.1 Обзор ключевых направлений деятельности Эффективный менеджмент инцидентов в области информационной безопасности нуждается в надлежащем планировании и подготовке. Для продуктивности и эффективности события в области информационной безопасности, для того, чтобы менеджмент инцидентов и уязвимостей был введен в эксплуатацию, организация должна выполнить ряд подготовительных мероприятий после необходимого планирования. Организация должна гарантировать, что деятельность на этапе планирования и подготовки включает в себя следующее: a) деятельность по разработке и выработке политики менеджмента события/инцидента/уязвимости в области информационной безопасности, а также получение поддержки этой политики высшим руководством. Этому должны предшествовать анализ информационной безопасности уязвимостей организации, подтверждение необходимости системы менеджмента инцидентов в области информационной безопасности и выявление преимуществ организации в целом и ее подразделений (см. подраздел 5.2). Обеспечение непрерывной поддержки со стороны руководства является крайне необходимым для принятия структурного подхода к менеджменту инцидентов в области информационной безопасности. Персонал должен распознать инцидент, знать, что делать и понимать преимущества подхода по отношению к конкретной организации. Менеджмент должен осуществляться в поддержку системы менеджмента, чтобы гарантировать, что организация предоставляет финансовое обеспечение и поддержку потенциала реагирования на инцидент; b) деятельность по обновлению политик менеджмента информационной безопасности и рисков на корпоративном уровне и для каждой системы, сервиса и сети. Это должно включать в себя ссылки на менеджмент события в области информационной безопасности, инцидентов и уязвимостей. Политика должна регулярно пересматриваться в контексте выходных данных из системы менеджмента инцидентов в области информационной безопасности (см. подраздел 5.3); c) деятельность по определению и документированию детальной системы менеджмента инцидентов в области информационной безопасности. Документация на системы должна охватывать формы, процедуры, организационные элементы и инструменты поддержки для обнаружения и оповещения, оценки и принятия соответствующего решения, реагирования на инциденты в области информационной безопасности и извлечения уроков из инцидентов в области информационной безопасности. Темы для включения содержат: 1) для градаций событий/инцидентов должна использоваться классификационная шкала событий/инцидентов в области информационной безопасности. Решение должно быть основано на фактических или предполагаемых негативных воздействиях на бизнес-операции организации. Примечание – В приложении С показан пример подхода к категоризации и классификации событий и инцидентов в области информационной безопасности;

2) регистрационные формы событий/инцидентов/уязвимостей в области информационной безопасности: I) заполняемый лицом отчет о событии в области информационной безопасности (т.е., не членом подразделения менеджмента инцидентов в области информационной безопасности – ISIRT), с учетом информации, регистрируемой в базе данных о событиях/инцидентах/уязвимостях в области информационной безопасности; II) используемые персоналом, ответственным за менеджмент инцидентов в области информационной безопасности, для сбора первоначально сообщаемой информации о событии в области информационной безопасности и включения регистрации результатов оценок инцидентов, и др. за время, пока инцидент полностью разрешается. На каждом этапе, обновления регистрируются в базе данных о событиях/инцидентах/уязвимостях в области информационной безопасности. Завершенная запись базы данных о событиях/инцидентах/уязвимостях в области информационной безопасности используется затем при проведении деятельности после разрешения инцидента; III) заполняемый лицом отчет об уязвимостях в области информационной безопасности (которые еще не выступали причиной событий в области информационной безопасности, и, возможно, инцидентов в области информационной безопасности), с учетом информации, регистрируемой в базе данных о событиях/инцидентах/уязвимостях в области информационной безопасности. Рекомендуется, чтобы эти регистрационные формы были электронными (напр. на защищенной web-странице), прямая ссылка на электронную базу данных о событиях/инцидентах/уязвимостях в области информационной безопасности. В настоящее время, работа с документами на бумажной основе занимает много времени. Тем не менее, такие системы могут быть необходимы для случая, где электронные системы не могут быть использованы. Примечание – Примеры регистрационных форм представлены в приложении D;

3) документированные процедуры и действия, связанные с использованием форм, т.е. связанные с обнаружением событий, инцидентов и уязвимостей в области информационной безопасности, со 7

СТБ ISO/IEC 27035/ПР_1 ссылками на обычные процедуры использования данных и системы, обслуживания и/или сетевого резервного копирования и антикризисных планов; 4) эксплуатационные процедуры для ISIRT, с учетом документированных процессов и связанных с ними обязанностей, и распределение ролей назначенных лиц для проведения различных мероприятий (человеку может быть отведено более одной роли, в зависимости от размера, структуры и бизнесхарактера организации), например, в том числе: I) отключение поврежденных систем, сервисов и/или сетей, в некоторых случаях по согласованию, по предварительной договоренности с соответствующими информационными технологиями и/или бизнес-руководством; II) выход из поврежденных систем, сервисов и/или сетей, подключенных и работающих; III) мониторинг потока данных из, к и внутри поврежденных систем, сервисов и/или сетей; IV) активирование обычных процедур резервного копирования и антикризисного управления и действия в соответствии с политикой безопасности систем, сервисов и/или сетей; V) мониторинг и поддержка обеспечения сохранности электронных данных, в случае, если это требуется для судебного преследования или внутренних дисциплинарных действий; VI) сообщение сведений об инцидентах в области информационной безопасности внутренним и внешним лицам или организациям. В некоторых организациях эта схема может быть названа планом реагирования на инциденты в области информационной безопасности (см. подраздел 5.4); d) деятельность для создания ISIRT, с соответствующей программой обучения, спроектированной, разработанной и предоставленной для ее сотрудников. Согласно размеру, структуре и характеру бизнеса, организация может иметь ISIRT, состоящую из специализированной группы, виртуальной команды, или сочетания обоих вариантов. Специализированная группа может иметь виртуальных членов, определенных в специальных подразделениях/функциях, которые должны тесно сотрудничать с ISIRT во время разрешения инцидента в области информационной безопасности (ICT, юридические связи, связи с общественностью, аутсорсинговые компании и др.). У виртуальной группы может быть старший менеджер, руководящий группой, поддерживаемой группами лиц, специализирующихся на определенных темах, например, на обработке атак вредоносных кодов, которые будут призываться в зависимости от типа рассматриваемого инцидента (см. подраздел 5.5); e) деятельность по формированию и сохранению соответствующих взаимоотношений и связей с внутренними и внешними организациями, которые непосредственно вовлечены в менеджмент событий, инцидентов и уязвимостей в области информационной безопасности; f) деятельность по формированию, внедрению и эксплуатации механизмов технической и иной поддержки (в том числе организационной) для поддержки системы менеджмента инцидентов в области информационной безопасности (и, таким образом, работы ISIRT), и для того, чтобы предотвратить или снизить вероятность возникновения инцидентов в области информационной безопасности (см. подраздел 5.6). Такие механизмы могут включать следующее: 1) механизмы внутреннего аудита информационной безопасности для оценки уровня безопасности и выявления уязвимых систем; 2) менеджмент уязвимостей (включая обновления безопасности и внесение изменений в систему безопасности уязвимых систем); 3) обзор технологий для обнаружения новых видов угроз и атак; 4) системы обнаружения несанкционированного проникновения (для более подробной информации см. ISO/IEC 18043); 5) устройства сетевой безопасности, средства защиты и инструменты мониторинга (для более подробной информации см. ISO/IEC 27033); 6) программное обеспечение анти – вредоносного кода; 7) записи журнала аудита и журнала программного обеспечения о мониторинге; 8) документированные обязанности и операционные процедуры для работы команды поддержки; g) деятельность по проектированию и разработке учебной программы и повышения осведомленности о менеджменте событий, инцидентов и уязвимостей в области информационной безопасности. Все сотрудники организации должны быть осведомлены путем проведения брифингов и/или других механизмов о существовании системы менеджмента событий, инцидентов и уязвимостей в области информационной безопасности, ее преимуществах и о том, каким образом составлять отчетность о событиях и инцидентах в области информационной безопасности (и уязвимостях). Параллельно, соответствующее обучение должно быть предоставлено персоналу, ответственному за контролирование системы менеджмента событий, инцидентов и уязвимостей в области информационной безопасности, лицам, принимающим решения, а также являются ли события в области информационной безопасности инцидентами, и определен круг лиц участвующих в расследовании инцидентов. Учебные занятия и брифинги, направленные на повышение осведомленности, должны повторяться в соответствии со сменой персонала (см. подраздел 5.7); h) тестовая деятельность правильности использования системы менеджмента событий, инцидентов и уязвимостей в области информационной безопасности, ее процессов и процедур. Тесты 8

СТБ ISO/IEC 27035/ПР_1 должны периодически проводиться не только для тестирования системы в реальной ситуации, но и верификации, как ISIRT ведет себя под давлением серьезного сложного инцидента. Особое внимание должно быть уделено созданию тестов, сфокусированных на выявлении сценариев уязвимостей, угроз и рисков (см. подраздел 5.8). Схема должна включать стандарты, которые поддерживают обмен информацией как внутри организации, так и за ее пределами (если этого требует организация). Одним из преимуществ обмена информацией является агрегация данных в полезные показатели для помощи принятия стратегических бизнес – решений. Принадлежность к доверенному сообществу по обмену информацией также обеспечивает раннее предупреждение атак и должно поощряться в любой системе менеджмента инцидентов в области информационной безопасности и связанной с ней политикой. По завершению данного этапа организации должны быть полностью подготовлены, чтобы правильно управлять инцидентами в области информационной безопасности. Следующие пункты описывают каждый из видов деятельности, перечисленных выше, в том числе содержание каждого требуемого документа. 5.2 Политика менеджмента инцидентов в области информационной безопасности 5.2.1 Введение Организация должна документировать свою политику по менеджменту событий, инцидентов и уязвимостей в области информационной безопасности как отдельный документ. Как составная часть общей политики системы менеджмента информационной безопасности (см. пункт 4.2.1 b) из ISO/IEC 27001:2005), или как часть политики информационной безопасности (см. пункт 5.1.1 из ISO/IEC 27002:2005). Размер, структура и деловой характер организации, а также масштаб программы менеджмента инцидентов в области информационной безопасности являются решающим фактором в определении того, какой из этих вариантов принять. Каждая организация должна направить политику менеджмента инцидентов в области информационной безопасности каждому человеку, имеющему легальный доступ к ее информационным системам и связанным с ними объектам. Прежде, чем сформулировать политику предприятия, организация должна провести обзор информационной безопасности, подчеркнув ее уязвимости, подтверждение необходимости менеджмента инцидентов в области информационной безопасности, выявление преимуществ организации в целом и ее подразделений. 5.2.2 Заинтересованные стороны Организация должна гарантировать, что ее политика менеджмента инцидентов в области информационной безопасности одобрена старшим исполнительным директором организации, с подтвержденным документально обязательством всего высшего руководства. Она должна быть доступна для каждого сотрудника и подрядчика, а также должна рассматриваться при проведении обучения и брифингов по повышению осведомленности в области информационной безопасности (см. подраздел 5.7). 5.2.3 Содержание Организация должна обеспечить, чтобы содержание ее политики менеджмента инцидентов в области информационной безопасности охватывало следующие темы: a) значимость менеджмента инцидентов в области информационной безопасности для организации; b) общие положения о событиях в области информационной безопасности и их обнаружении, отчетность и сбор соответствующей информации, а также каким образом данная информация должна использоваться для выявления инцидентов в области информационной безопасности. Общие положения должны содержать краткое описание возможных типов событий в области информационной безопасности, как о них сообщить, что сообщать, куда и кому, и способ обработки совершенно новых типов событий в области информационной безопасности. Также должны содержать краткое описание отчетов и обработки уязвимостей в области информационной безопасности; c) общие положения оценки инцидентов в области информационной безопасности, включая краткое описание того, кто за это отвечает, что должно быть сделано, оповещение и эскалацию; d) краткое описание деятельности, которая следует подтверждением того, что событие в области информационной безопасности является инцидентом в области информационной безопасности; e) ссылка на необходимость обеспечения того, что все мероприятия по менеджменту инцидентов в области информационной безопасности надлежащим образом заносятся в журнал для последующего анализа, и что непрерывный мониторинг проводится с целью обеспечения безопасности хранения электронных данных, в случае, если это требуется для судебного преследования или внутренних дисциплинарных мер; f) деятельность по разрешению после инцидента в области информационной безопасности, включая изучение и совершенствование процесса после инцидента в области информационной безопасности; g) общие положения отчетов и обработки уязвимостей в области информационной безопасности; 9

СТБ ISO/IEC 27035/ПР_1 h) сведения о том, где хранится системная документация, включая распорядительные документы; i) общие положения ISIRT, охватывающие следующие темы: 1) организационная структура ISIRT, личность менеджера ISIRT и других ключевых сотрудников, включая ответственных за: I) брифинг высшего руководства на инциденты; II) решение вопросов, провоцирующих последующее расследование, др.; III) связь с внешними организациями (при необходимости); 2) устав менеджмента инцидентов в области информационной безопасности, который указывает, что ISIRT нужно делать, и орган, при котором она это делает. Как минимум, устав должен включать формулировку миссии, определение сферы деятельности ISIRT и спонсора ISIRT на уровне совета директоров и органа власти; 3) формулировка миссии ISIRT, которая фокусируется на основных направлениях деятельности группы. Для того чтобы считаться ISIRT, группа должна поддерживать оценку, реагирование на менеджмент инцидентов в области информационной безопасности до успешного завершения. Задачи и цели группы являются особенно важными и требуют четкого, однозначного определения; 4) определение сферы деятельности ISIRT. Как правило, сфера деятельности ISIRT в организации охватывает все информационные системы организации, сервисы и сети. В других случаях организация может, по какой-то причине, потребовать, чтобы сфера деятельности была меньше, в этом случае требуется четкая документация того, что входит в эту сферу деятельности, а что нет; 5) идентификация старшего исполнительного директора, члена правления или старшего менеджера, который имеет полномочия принимать решения по ISIRT, а также устанавливать уровни полномочий для ISIRT. Знание этого помогает всем сотрудникам организации понять предпосылки и установки ISIRT, и это очень важная информация для укрепления доверия в ISIRT. Следует отметить, что до обнародования данной информации, она должна быть проверена с юридической точки зрения; 6) связи с организациями, предоставляющими конкретную внешнюю поддержку, такую, как экспертные группы (см. подраздел 5.5.4); j) общие положения механизмов технической и другой поддержки; k) общие положения программы обучения и повышения осведомленности о менеджменте инцидентов в области информационной безопасности; l) краткое описание правовых и нормативных аспектов, которые должны быть решены (для более подробной информации см. приложение E). 5.3 Интеграция менеджмента инцидентов в области информационной безопасности в другие политики 5.3.1 Введение Организация должна включать в себя оценку инцидентов в области информационной безопасности в своих политиках информационной безопасности и менеджмента рисков на корпоративном уровне так же, как на уровне конкретной системы, в сфере услуг и сетевом уровне и должна соотносить это содержание с политикой менеджмента инцидентов. Интеграция должна быть направлена на достижение следующего: a) чтобы описать, почему менеджмент инцидентов в области информационной безопасности, в частности, отчетность и схема обработки инцидентов в области информационной безопасности, важен; b) чтобы обозначить обязательство высшего руководства в необходимости надлежащей подготовки и реагирования на инциденты в области информационной безопасности, т.е. схема управления инцидентами в области информационной безопасности; c) чтобы обеспечить согласованность различных политик; d) обеспечение плановой, систематической и спокойной реакции на инциденты в области информационной безопасности, тем самым сводя к минимуму неблагоприятные последствия инцидентов. Для получения руководства по оценке и менеджменту рисков информационной безопасности см. ISO/IEC 27005:2008. 5.3.2 Содержание Каждая организация должна обновлять и поддерживать свои корпоративные политики информационной безопасности и менеджмента рисков, и политики информационной безопасности конкретной системы, сервиса или сети. Эти политики должны относиться к корпоративной политике менеджмента инцидентов в области информационной безопасности и связанной с ней схеме напрямую. a) соответствующие разделы должны относиться к обязательству высшего руководства; b) соответствующие разделы должны выстроить политику; c) соответствующие разделы должны обозначить процессы системы менеджмента и соответствующую инфраструктуру; d) соответствующие разделы должны обозначить требования для обнаружения, оповещения, оценки и менеджмента событий в области информационной безопасности, инцидентов и уязвимостей; 10

СТБ ISO/IEC 27035/ПР_1 e) соответствующие разделы должны четко определить сотрудников, ответственных за разрешение и/или осуществление определенных критических действий (например, принятие режима offline информационной системы или даже ее отключение). Политики должны включать в себя требования того, чтобы соответствующие механизмы проверки были установлены. Эти механизмы должны обеспечить информацию, полученную при обнаружении, мониторинге и разрешении инцидентов в области информационной безопасности и полученную от операций с обнаруженными уязвимостями информационной безопасности. А также использовалась в качестве входных данных для обеспечения постоянной эффективной работы корпоративных политик информационной безопасности и менеджмента рисков, и политик информационной безопасности конкретной системы, сервиса или сети. 5.4 Схема управления инцидентами в области информационной безопасности 5.4.1 Введение Целью системы менеджмента инцидентов в области информационной безопасности является обеспечение подробной документации с описанием мероприятий и процедур по борьбе с событиями и инцидентами в области информационной безопасности, и коммуникация таких событий, инцидентов и уязвимостей в области информационной безопасности, вступающая в силу в случае обнаружения события в области информационной безопасности или оповещения об уязвимости в области информационной безопасности. Каждая организация должна использовать схему в качестве руководства для: a) реагирования на события в области информационной безопасности; b) определения, станут ли события в области информационной безопасности инцидентами в области информационной безопасности; c) управления инцидентами в области информационной безопасности до составления заключения; d) реагирования на уязвимости информационной безопасности, e) определения извлеченных уроков и любых усовершенствований системы и/или безопасности в целом при необходимости; f) внесения определенных улучшений. 5.4.2 Участвующие стороны Организация должна гарантировать, что информация об инцидентах в области информационной безопасности адресована всем сотрудникам и подрядчикам, ICT сервис-провайдерам, операторам связи и аутсорсинговым компаниям, таким образом, охватывающим следующие процессы: a) обнаружение и оповещение о событиях в области информационной безопасности (это обязанность любого постоянного или работающего по договору подряда персонала в организации и ее компаниях); b) оценка и реагирование на события и инциденты в области информационной безопасности, будучи вовлеченными в деятельность по разрешению после инцидента в области информационной безопасности, включая изучения и повышение информационной безопасности и совершенствование самой системы менеджмента инцидентов в области информационной безопасности (это обязанность членов PoC (точка связи), ISIRT, руководства, персонала по связям с общественностью и официальных представителей); c) оповещение об уязвимостях в области информационной безопасности (обязанность любого постоянного или работающего по договору подряда персонала в организации и ее компаниях) и борьба с ними. Схема должна также учитывать любых пользователей третьей стороны, инциденты в области информационной безопасности и связанные с ними уязвимости, о которых сообщается сторонними организациями, государственными и коммерческими организациями, предоставляющими информацию по инцидентам информационной безопасности и уязвимостям. 5.4.3 Содержание Каждая организация должна обеспечить то, чтобы содержание системы менеджмента инцидентов в области информационной безопасности включало в себя следующее: a) обзор политики менеджмента инцидентов в области информационной безопасности; b) обзор всей системы менеджмента инцидентов в области информационной безопасности; c) подробную информацию о деятельности, процедурах и сведениях, связанных со следующим: 1) планирование и подготовка: I) стандартизированный подход к категоризации и классификации событий/инцидентов в области информационной безопасности, позволяющий предоставлять согласованные результаты. В данном случае решение должно быть выработано на основе фактического или прогнозируемого неблагоприятного воздействия на бизнес – операции организации и соответствующее руководство; Примечание – Приложение C показывает пример подхода к категоризации и классификации событий и инцидентов в области информационной безопасности.

11

СТБ ISO/IEC 27035/ПР_1 II) стандартная структура базы данных о событиях/инцидентах/уязвимостях в области информационной безопасности, которая предназначена, скорее всего, для обеспечения возможности сравнения результатов, улучшения передачи информации о предупреждении и возможности более точного представления об угрозах и уязвимостях информационных систем; III) руководство для определения, степени реакции на каждый из инцидентов в области информационной безопасности. На основе представленных в документации по системе менеджмента инцидентов в области информационной безопасности руководящих принципов, любой, оценивающий событие, инцидент или уязвимость в области информационной безопасности, должен знать, в каких случаях необходимо заострять внимание на данных вопросах и для кого они должны пересматриваться. Кроме того, возникают непредвиденные ситуации, когда это может оказаться необходимым. Например, незначительный инцидент информационной безопасности может привести к значительной или кризисной ситуации, если не обрабатывается должным образом или незначительный инцидент информационной безопасности, не обработанный до конца, может стать серьезным инцидентом в области информационной безопасности. Руководство должно определить типы событий и инцидентов в области информационной безопасности, типы эскалации и кто может возбудить эскалацию; IV) процедуры, которым нужно следовать, чтобы гарантировать, что вся деятельность по менеджменту инцидентов в области информационной безопасности должным образом регистрируется в соответствующей форме, и, что анализ регистрационного журнала проводится уполномоченными сотрудниками; V) процедуры и механизмы, чтобы гарантировать, что измененный режим контроля поддерживается на уровне, охватывающем отслеживание событий, инцидентов и уязвимостей в области информационной безопасности и обновлений отчетов о событиях/инцидентах/уязвимостях в области информационной безопасности и обновлений для самой системы; VI) процедуры для проведения экспертного анализа информационной безопасности; VII) процедуры и руководство по использованию систем обнаружения вторжений (IDS), гарантируя, что связанные с ними правовые и нормативные аспекты были учтены. Руководящие принципы должны включать в себя обсуждение преимуществ и недостатков деятельности по надзору, проводимой злоумышленником. Дальнейшая информация по IDS содержится в ISO/IEC 18043:2006; VIII) руководящие принципы и процедуры, связанные с техническими и организационными механизмами, которые устанавливаются, внедряются и эксплуатируются, в целях предотвращения возникновения инцидентов в области информационной безопасности и снижения вероятности их возникновения и методов борьбы с уже возникшими инцидентами в области информационной безопасности; IX) учебные материалы для обучающей программы и повышения осведомленности о менеджменте событий, инцидентов и уязвимостей в области информационной безопасности; X) процедуры и технические характеристики для тестирования системы менеджмента инцидентов в области информационной безопасности; XI) схема организационной структуры для менеджмента инцидентов в области информационной безопасности; XII) круг полномочий и обязанностей ISIRT как в целом, так и отдельных ее членов; XIII) важная контактная информация. 2) обнаружение и оповещение: I) обнаружение и оповещение о возникновении событий в области информационной безопасности (человеком или автоматическими средствами); II) сбор информации, связанной с событиями в области информационной безопасности; III) обнаружение и оповещение об уязвимостях в области информационной безопасности; IV) полностью все записи информации, собранной в базе данных по менеджменту инцидентов в области информационной безопасности; 3) оценка и принятие решения: I) проверка концепции проведения оценок событий в области информационной безопасности (включая эскалацию при необходимости), использование согласованной классификационной шкалы событий/инцидентов в области информационной безопасности (в том числе определение последствий событий, основанных на уязвимых активах/сервисах) и принятие решения, должны ли быть события классифицированы как инциденты в области информационной безопасности; II) при оценке ISIRT событий в области информационной безопасности, должны быть подтверждены, является ли событие в области информационной безопасности инцидентом в области информационной безопасности или нет, и тогда другая оценка должна проводиться с использованием согласованной классификационной шкалы событий/инцидентов в области информационной безопасности, чтобы подтвердить сведения о типе события (возможного инцидента) и соответствующего ресурса (категоризации). Этому нужно следовать в принятии решений о том, как бороться с подтвержденным инцидентом в области информационной безопасности, кому и в какой приоритетной последовательности, а также на каких уровнях развития; 12

СТБ ISO/IEC 27035/ПР_1 III) оценка уязвимостей в области информационной безопасности (которые до сих пор не рассматривались в качестве причин событий в области информационной безопасности и потенциальных инцидентов в области информационной безопасности), с принятием решений о том, с которыми из них нужно бороться, кому, как и в какой приоритетной последовательности; IV) полностью все записи результатов оценки и связанные с ними решения касательно баз данных по менеджменту инцидентов в области информационной безопасности; 4) ответные меры: I) пересмотр ISIRT, чтобы определить, находится ли инцидент информационной безопасности под контролем, и: - если инцидент находится под контролем, провоцирует на ответные меры, либо сразу (в реальном времени или в режиме, близком к реальному времени) или в более позднее время; - если инцидент не находится под контролем или это будет иметь тяжелые последствия для основных сервисов организации, провоцируют антикризисную деятельность через эскалацию функции урегулирования кризиса; II) определение карт всех внутренних и внешних функций и организаций, которые должны участвовать в процессе менеджмента инцидента; III) Проведение экспертного анализа информационной безопасности при необходимости; IV) Эскалация по мере необходимости; V) обеспечение того, чтобы все задействованные виды работ надлежащим образом заносились в журнал для последующего анализа; VI) обеспечения того, чтобы электронные доказательства собирались и хранились доказуемо надежно; VII) обеспечение того, чтобы измененный режим контроля сохранялся, и, таким образом, чтобы сохранялась актуальная версия базы данных о событиях/инцидентах/уязвимостях в области информационной безопасности; VIII) информирование о существовании инцидента в области информационной безопасности или любых относящихся к нему данных другим внутренним и внешним лицам или организациям; IX) методы борьбы с уязвимостями информационной безопасности; X) после того, как инцидент был успешно разрешен, завершен и зарегистрирован в базе данных по менеджменту инцидентов в области информационной безопасности. Каждая организация должна гарантировать, чтобы документация по системе менеджмента инцидентов в области информационной безопасности позволяла ответные меры реагирования на инциденты в области информационной безопасности как сразу, так и в долгосрочной перспективе. Все инциденты в области информационной безопасности, должны пройти раннюю оценку потенциального негативного воздействия на бизнес-операции, как краткосрочные, так и долгосрочные (например, крупная катастрофа может произойти некоторое время после первоначального инцидента в области информационной безопасности). Далее, она должна позволить использование некоторых ответных мер, необходимые для реагирования на инциденты в области информационной безопасности, которые являются абсолютно непредвиденными, где использование специальных средств управления является обязательным. Даже для такой ситуации, организации должны включать общие руководящие принципы в документацию о системе менеджмента по шагам, которые могут быть необходимы. 5) извлеченные уроки: I) проведение дальнейшего экспертного анализа информационной безопасности при необходимости; II) определение извлеченных уроков из инцидентов и уязвимостей в области информационной безопасности; III) пересмотр, выявление и совершенствование внедрения средств управления информационной безопасности (новых и/или обновленных средств управления), а также политики менеджмента инцидентов в области информационной безопасности в результате извлеченных уроков; IV) пересмотр, выявление и, если возможно, совершенствование существующих результатов оценки рисков информационной безопасности и анализа менеджмента в результате извлеченных уроков; V) рассмотрение того, насколько эффективны были процессы, процедуры, форматы отчетов и/или организационной структуры в реагировании на оценку и восстановление от каждого инцидента в области информационной безопасности и проведен анализ соответствия методам борьбы с уязвимостями информационной безопасности, и на основе уроков, извлеченных при определении и совершенствовании системы менеджмента инцидентов в области информационной безопасности и ее документации; VI) обновление базы данных о событиях/инцидентах/уязвимостях в области информационной безопасности; VII) общение и обмен информацией о результатах пересмотра внутри надежного сообщества (по желанию организации).

13

СТБ ISO/IEC 27035/ПР_1 5.4.4 Процедуры Прежде чем приступить к эксплуатации системы менеджмента инцидентов в области информационной безопасности, важно, чтобы организация документально подтвердила и проверила, что процедуры доступны. Каждая процедура, по мере необходимости, должна указать группы или лица из PoC и/или ISIRT, ответственные за ее использование и менеджмент. Такие процедуры должны гарантировать, что электронные доказательства собраны и хранятся в безопасном месте и что их надежное сохранение постоянно контролируется, в случае, если это требуется для судебного преследования или внутренних дисциплинарных мер. Далее следует документировать процедуры, охватывающие не только деятельность PoC и ISIRT, но и тех, кто участвует в экспертном анализе информационной безопасности и антикризисной деятельности – если не рассматриваются в других разделах, например в плане непрерывности бизнеса или плане менеджмента кризисных ситуаций. Документированные процедуры должны находиться в полном соответствии с документированной политикой менеджмента инцидентов в области информационной безопасности и другой документацией по схеме управления инцидентами в области информационной безопасности. Важно понимать, что не все процедуры должны быть общедоступны. Например, не является необходимым для всех сотрудников организации понимать внутреннюю деятельность ISIRT, чтобы взаимодействовать с ней. ISIRT должна обеспечить доступное руководство, включая информацию, полученную в результате анализа инцидентов в области информационной безопасности, находилось в доступной форме, например, на интернет сети организации. Важным соблюдением деталей системы менеджмента инцидентов в области информационной безопасности тесно связаны с предотвращением внутреннего вмешательства в процесс расследования. Например, если сотрудник банка, который обвиняется в хищении средств, осведомлен о некоторых деталях системы менеджмента, он или она может лучше скрыть свою деятельность от следователей или иным образом затруднить обнаружение, расследование и восстановление от последствий инцидента в области информационной безопасности. Содержание операционных процедур зависит от ряда критериев, особенно в отношении к происхождению известных потенциальных событий, инцидентов и уязвимостей в области информационной безопасности и типов активов информационных систем, которые могут быть вовлечены в этот процесс и окружающей среды. Таким образом, операционная процедура может иметь отношение к определенному типу инцидента или продукта (например, брандмауэры, базы данных, операционные системы, приложения) или к конкретной продукции. Для каждой операционной процедуры должны быть четко определены шаги, которые должны быть предприняты и кем. Она должна отражать опыт работы из внешних (например, государственных и коммерческих ISIRT или аналогичных групп, и поставщиков), а также из внутренних источников. Должны быть определены процедуры для борьбы с уже известными типами событий и инцидентов в области информационной безопасности, а также уязвимостей. Также должны быть определены процедуры, которые должны соблюдаться при условии появления определенного события, которое не является никаким из ранее известных типов. В этом случае следует обратить внимание на следующее: a) процесс представления отчетности для обработки таких исключений; b) руководство в отношении сроков для получения разрешения от руководства, чтобы избежать каких-либо задержек в принятии ответных мер; c) предварительное делегирование полномочий по принятию решений без нормального процесса утверждения. 5.4.5 Доверие ISIRT играет решающую роль для общей информационной безопасности организации. ISIRT требует взаимодействия всех сотрудников организации для обнаружения, разрешения и расследования инцидентов в области информационной безопасности. Принципиально важно, чтобы ISIRT доверяли все, участники процесса. Принятие анонимности в отношении составления отчетности об уязвимостях, событиях и инцидентах в области информационной безопасности необходимо для построения системы доверия. Организация должна гарантировать, что схема управления инцидентами в области информационной безопасности учитывает ситуации, в которых важно обеспечить анонимность лица или стороны, которая составляет отчеты о потенциальных инцидентах в области информационной безопасности или уязвимостях. Каждая организация должна иметь документы, которые наглядно иллюстрируют анонимность для лиц или сторон, которые составляют отчетность о потенциальных инцидентах в области информационной безопасности или уязвимостях. ISIRT может понадобиться дополнительная информация изначально не ретранслируемая лицом или стороной, которая сообщила об этом инциденте. Кроме того, важная информация об инциденте информационной безопасности или самой уязвимости, может быть получена от того, кто обнаружил его первым. Другой подход, который может быть принят ISIRT, заключается в том, чтобы завоевать доверие пользователей за счет открытости и сформировавшихся процессов.ISIRT должна работать по обучению пользователей, чтобы объяснить, как ISIRT работает, как она защищает конфиденциальность собранной информации и то, как она управляет отчетами пользователей о событиях, инцидентах и уязвимостях. 14

СТБ ISO/IEC 27035/ПР_1 ISIRT должна быть в состоянии эффективно удовлетворять функциональные, финансовые, правовые и политические потребности организации и проявлять осторожность и осмотрительность при управлении инцидентами и уязвимостями информационной безопасности. ФункционированиеISIRT также должно независимо проверяться для подтверждения того, что все бизнес-требования эффективно удовлетворяются. Кроме того, хорошим способом достижения результативности – это отделить цепочку отчетности об инцидентах и уязвимостях от действующей линии менеджмента и сделать старшего менеджера непосредственно ответственным за управление ответными мерами реагирования на инциденты и уязвимости. Финансовые возможности также должны быть отделены, чтобы избежать чрезмерного влияния. 5.4.6 Конфиденциальность В системе менеджмента инцидентов в области информационной безопасности может содержаться конфиденциальная информация, и лицам, занимающимся инцидентами, может потребоваться доступ к ней. Поэтому во время обработки необходимо обеспечивать анонимность этой информации, или персонал должен подписать соглашение о конфиденциальности (неразглашении) при получении доступа к ней. Если события/инциденты/уязвимости в области информационной безопасности регистрируют через общую систему менеджмента качества, то конфиденциальные подробности, возможно, придется опустить. Кроме того, организация должна обеспечить, чтобы схема управления инцидентами в области информационной безопасности обеспечивала контроль над передачей сообщений об инцидентах и уязвимостях сторонними организациями, включая средства массовой информации (СМИ), партнеров по бизнесу, потребителей, правоохранительные организации и общественность. 5.5 Создание ISIRT 5.5.1 Введение Целью создания ISIRT является обеспечение организации соответствующей возможностью оценки, реагирования на инциденты в области информационной безопасности и извлечения уроков из них, а также необходимой координации, менеджмента, обратной связи и процесса передачи информации. Члены ISIRT могут участвовать в снижении физического и финансового ущерба, а также ущерба для репутации организации, связанного иногда с инцидентами в области информационной безопасности. 5.5.2 Члены группы и структура Состав и количество персонала, а также структура ISIRT должны соответствовать масштабу и структуре организации. Хотя ISIRT может представлять собой изолированную команду или отдел, члены этой группы могут выполнять и другие обязанности, а также привлекать сотрудников из различных подразделений организации. Организация должна оценить, требуется специальная группа, виртуальная группа, или сочетание двух. Организации следует руководствоваться количеством инцидентов и видами деятельности, осуществляемыми ISIRT, в данном выборе. ISIRT проходит через различные стадии зрелости и часто корректировки организационной модели приняты на основе конкретных сценариев, с которыми сталкивается организация. В обоснованных случаях, рекомендуется иметь постоянную группу реагирования, возглавляемую старшим руководством. Виртуальная ISIRT может возглавляться страшим руководством. Вышестоящему руководству оказывают помощь специалисты по конкретным вопросам, например, по отражению атак вредоносных программ, которые привлекаются в зависимости от типа инцидента в области информационной безопасности. В зависимости от численного состава, структуры и бизнес – процессы организации, член ISIRT может также выполнять несколько функций внутри ISIRT. В ISIRT могут также привлекаться служащие из различных подразделений организации (например, бизнес-операций, ICT, аудита, отдела кадров и маркетинга). Это также относится и к постоянным пользователям ISIRT; даже в случае привлечения специализированного персонала ISIRT всегда требует поддержки со стороны других ведомств. Члены группы должны быть доступны для контакта так, чтобы их имена и имена лиц, их замещающих, а также подробности о контакте с ними были доступными внутри организации. В документации по системе менеджмента инцидентов в области информационной безопасности должны быть четко указаны необходимые детали, включая любые документы по процедурам и формы отчетов. Руководство ISIRT должно, как правило, иметь отдельные каналы отчетности для высшего руководства, отдельно от бизнес-операций. Он/она должны иметь делегированные полномочия немедленного принятия решения о том, какие меры предпринять относительно инцидента, и обеспечивать необходимый уровень знаний и мастерства для всех членов ISIRT, а также поддержание этого уровня. Руководство ISIRTдолжно поручать расследование каждого инцидента наиболее компетентному члену его/ее группы, с каждым инцидентом должен быть назначен именованный руководитель (менеджер).

15

СТБ ISO/IEC 27035/ПР_1 5.5.3 Взаимодействие с другими подразделениями организации ISIRT должна нести ответственность за обеспечение разрешения инцидентов, и в этом контексте уровень полномочий руководителя ISIRT и членов его/ее группы должен позволять предпринимать необходимые действия, адекватные инциденту в области информационной безопасности. Однако действия, которые могут оказать неблагоприятное влияние на всю организацию в отношении финансов или репутации, должны согласовываться с высшим руководством. Поэтому важно уточнить, какому органу в системе обеспечения политики менеджмента инцидентов в области информационной безопасности руководитель ISIRT оповещает о серьезных инцидентах в области информационной безопасности. Процедуры общения со средствами массовой информации и ответственность за это общение также должны быть согласованы со старшим руководством и документированы. Эти процедуры должны определять представителя организации по работе со средствами массовой информации и метод взаимодействия подразделения организации с ISIRT. 5.5.4 Отношения с внешними заинтересованными сторонами Необходимо установить отношения между ISIRT с внешними заинтересованными сторонами. Внешние заинтересованные стороны могут включать в себя следующее: a) сторонний вспомогательный персонал, работающий по контракту; b) организации внешние для ISIRT; c) поставщики управляемых услуг, в том числе провайдеры телекоммуникационных услуг, интернет-провайдеры и поставщики; d) правоохранительные организации; e) аварийные службы; f) соответствующие государственные организации; g) юридический персонал; h) официальные лица по связям с общественностью и/или представителями средств массовой информации; i) бизнес-партнеры; j) клиенты; k) общественность. 5.6 Техническая и другая поддержка (включая сопровождение) Для обеспечения быстрого и эффективного реагирования на инциденты в организации, все необходимые технические и другие средства поддержки получены, подготовлены и протестированы. Это включает в себя следующее: a) доступ к деталям активов организации с обновленным перечнем активов и информацией по их связям с бизнес-функциями; b) доступ к документированным процедурам, связанным с антикризисным менеджментом; c) документированные и опубликованные процессы передачи информации; d) использование базы данных о событиях/инцидентах/уязвимостях в области информационной безопасности и технических средств для быстрого пополнения и обновления базы данных, анализа ее информации и упрощения процессов реагирования (в некоторых случаях сделанные вручную записи могут быть востребованы организацией); с доказуемо надежным сохранением базы данных; e) оборудование для сбора и анализа экспертных доказательств информационной безопасности; f) адекватные меры по обеспечению базы данных о событиях/инцидентах/уязвимостях в области информационной безопасности (руководство по менеджменту непрерывности бизнеса см. ISO/IEC 27031). Организация должна гарантировать, что технические средства, используемые для быстрого пополнения, обновления баз данных, анализируют информацию и облегчают процессы реагирования на инциденты в области информационной безопасности и должны содействовать: g) быстрому получению отчетов о событиях/инцидентах/уязвимостях в области информационной безопасности; h) уведомлению ранее отобранных соответствующих сторонних лиц подходящими для этого средствами (например, через электронную почту, факс или телефон), то есть запрашивая поддержку надежной контактной базы данных, которая должна быть всегда легкодоступной, должна включать в себя бумажные и другие копии), средство передачи информации безопасным способом при необходимости; i) соблюдению предосторожностей, соответствующих оцененным рискам, для сохранения доступности электронной связи, реализуемой через Интернет или иным образом, во время атаки на систему, сервис и/или сеть (это может потребовать заранее запланированные альтернативные механизмы коммуникаций); j) процессу сбора всех данных об информационной системе, сервисе и/или сети и всех обрабатываемых данных; k) использованию криптографического контроля целостности, если это соответствует оцененным рискам, для содействия в определении наличия изменений и того, какие части системы, сервиса и/или сети и данные подверглись изменениям; 16

СТБ ISO/IEC 27035/ПР_1 l) упрощению архивирования и защиты собранной информации (например, применяя цифровые подписи в записях в журнале регистрации или другие свидетельства перед хранением в автономном режиме на носителях, предназначенных только для чтения на устройствах CD или DVD ROM); m) подготовке распечаток (например, журналов регистрации), демонстрирующих развитие и процесс разрешения инцидента в области информационной безопасности, а также обеспечивающих сохранность информации; n) восстановлению штатного режима работы информационной системы, сервиса и/или сети с помощью следующих процедур, в соответствии с релевантным антикризисным менеджментом: 1) тестирования резервных копий; 2) контроля вредоносных программ; 3) применения исходных носителей информации с системным и прикладным программным обеспечением; 4) применения загрузочных носителей; 5) применения чистых, надежных и обновлений для систем и приложений. Все большее распространение для организаций получает создание стандартного базового образа с установочного диска и использование данного образа в качестве чистой основой для создания систем. Использование такого образа вместо оригинального носителя часто предпочтительнее, потому что образ уже был преобразован, утвержден, протестирован и др. Атакованная информационная система, сервис и/или сеть могут функционировать неверно. Поэтому работа технического средства (программного или аппаратного обеспечения), необходимого для реагирования на инцидент в области информационной безопасности, не должна быть основана на системах, сервисах и/или сетях, используемых в организации. По возможности, технические средства реагирования на инциденты должны быть полностью автономными. Примечание – Технические средства, указанные в настоящем пункте, не включают в себя технические средства, используемые для выявления инцидентов в области информационной безопасности, для вторжений сразу и автоматического уведомления соответствующих лиц. Такого рода технические средства описаны в ISO/IEC 18043.

В то время как PoC организации имеет гораздо более постоянную роль в организации для поддержки всех аспектов, связанных с информационными технологиями и обработкой соответствующей информации, она играет ключевую роль в менеджменте инцидентов в области информационной безопасности. Если о событиях в области информационной безопасности сообщается впервые, PoC борется с ними на этапе обнаружения и оповещения. В PoC следует пересматривать собранную информацию и проводить первоначальное оценивание того, следует ли классифицировать события в качестве инцидентов или нет. Если событие классифицируется как инцидент, PoC будет бороться с ним, хотя и ожидается, что в большинстве случаев ответственность за разрешение инцидента должна быть переложена на ISIRT. Желательно, чтобы сотрудники PoC являлись экспертами по безопасности. 5.7 Обучение и повышение осведомленности Менеджмент инцидентов в области информационной безопасности - это процесс, включающий в себя не только технические средства, но также персонал, и, следовательно, этот процесс должен поддерживаться лицами, соответствующим образом обученными для работы в организации и осведомленными в вопросах безопасности информации. Осведомленность и участие всего персонала организации очень важны для обеспечения успеха структурного подхода к менеджменту инцидентов в области информационной безопасности. Хотя пользователи должны участвовать, они с меньшей вероятностью могут эффективно участвовать в эксплуатации, если они не осведомлены о том, как они, а также их отделения могут получить выгоду от участия в структурном подходе к менеджменту инцидентов в области информационной безопасности. Далее, эксплуатационная эффективность и качество структурного подхода к менеджменту инцидентов в области информационной безопасности опирается на ряд факторов, в том числе обязательство уведомлять об инцидентах, качество уведомления, простоту использования, скорость и обучение. Некоторые из этих факторов имеют отношение к убеждению о том, что пользователи осведомлены о значении менеджмента инцидентов в области информационной безопасности и мотивированы сообщать об инцидентах. Роль менеджмента инцидентов в области информационной безопасности должна активно поддерживаться как часть общей программы обучения и обеспечения осведомленности в вопросах информационной безопасности. Программа обеспечения осведомленности и соответствующий материал должны быть доступны для всего персонала, включая новых служащих, пользователей сторонних организаций и подрядчиков. Должна существовать специальная программа обучения для PoC, для членов ISIRT, а при необходимости - для персонала, ответственного за информационную безопасность, и специальных администраторов. Следует заметить, что для каждой группы, непосредственно участвующей в менеджменте инцидентов, могут потребоваться различные уровни подготовки, зависящие от типа, частоты и значимости их взаимодействия с системой менеджмента инцидентов в области информационной безопасности. Брифинги по обеспечению осведомленности должны включать в себя следующее: 17

СТБ ISO/IEC 27035/ПР_1 a) преимущества, получаемые от структурного подхода к менеджменту инцидентов в области информационной безопасности, как для организации, так и для ее сотрудников; b) основы работы системы менеджмента инцидентов в области информационной безопасности, включая сферу ее действия и технологию работ по менеджменту инцидентов, событий и уязвимостей в области информационной безопасности; c) способы оповещения о событиях, инцидентах и уязвимостях в области информационной безопасности; d) содержащуюся информацию об инцидентах и выходы из базы данных о событиях/инцидентах/уязвимостях в области информационной безопасности; e) защитные меры по обеспечению конфиденциальности источников по необходимости; f) соглашения об уровнях сервиса системы; g) уведомление о результатах деятельности – на каких условиях будут информированы источники; h) любые ограничения, налагаемые соглашениями о неразглашении; i) полномочия организации менеджмента инцидентов в области информационной безопасности и ее линия оповещения; j) кто и как получает отчеты от системы менеджмента инцидентов в области информационной безопасности. В некоторых случаях желательно специально включать подробности обеспечения осведомленности о менеджменте инцидентов в области информационной безопасности в другие программы обучения (например, в программы ориентирования персонала или в общие корпоративные программы обеспечения осведомленности в вопросах информационной безопасности). Этот подход к обеспечению осведомленности может предоставить ценную информацию, связанную с определенными группами сотрудников, и может улучшить эффективность и результативность программы обучения. До ввода в эксплуатацию системы менеджмента инцидентов в области информационной безопасности весь соответствующий персонал должен ознакомиться с процедурами обнаружения и оповещения о событиях в области информационной безопасности, а специально отобранный персонал должен быть хорошо осведомлен в отношении последующих процессов. Затем проводят регулярные инструктажи по обеспечению осведомленности и курсы подготовки. Подготовка должна сопровождаться специальными упражнениями и тестированием членов группы PoC и ISIRT, а также персонала, ответственного за информационную безопасность, и специальных администраторов. Кроме того, программы обучения и повышения осведомленности должны быть дополнены созданием и функционированием поддержки "горячей линии" сотрудниками, осуществляющими менеджмент инцидентов в области информационной безопасности, чтобы минимизировать задержки в предоставлении отчетности и обработке событий/инцидентов и уязвимостей в области информационной безопасности. 5.8 Тестирование системы менеджмента Для выявления потенциальных дефектов и проблем, которые могут возникнуть в процессе менеджмента событий и инцидентов в области информационной безопасности, организации необходимо запланировать регулярные проверки и тестирование процессов и процедур менеджмента инцидентов в области информационной безопасности. Любые изменения, возникающие в результате анализа реагирований на инциденты в области информационной безопасности, должны подвергаться строгой проверке и тестированию. Организации должны гарантировать, что любые изменения, внесенные в результате после тестовых пересмотров, подлежат тщательной проверке, в том числе и дальнейшему тестированию перед тем, как заработает измененная система менеджмента.

6 Этап обнаружения и оповещения об инцидентах в области информационной безопасности 6.1 Обзор ключевых направлений деятельности Первый этап операционного использования системы менеджмента инцидентов в области информационной безопасности включает обнаружение, сбор соответствующей информации и оповещение о возникновении событий в области информационной безопасности и существовании уязвимостей в области информационной безопасности одним из сотрудников организации или автоматически. Менеджмент инцидентов в области информационной безопасности в процессе эксплуатации состоит из трех главных этапов: обнаружение и оповещение об инцидентах в области информационной безопасности, оценка и принятие решения (см. раздел 7) и ответные меры (см. раздел 8). За ними следует этап – извлеченные уроки (см. раздел 9), на котором выявляются и осуществляются совершенствования информационной безопасности и системы менеджмента инцидентов в области информационной безопасности. Данные этапы и связанные с ними виды деятельности представлены в подразделе 4.5. В следующих разделах преимущественно рассматриваются способы разрешения событий и инцидентов в области информационной безопасности. Организация должна обеспечить, чтобы соответствующий персонал боролся с известными уязвимостями в области информационной 18

СТБ ISO/IEC 27035/ПР_1 безопасности подобным образом тому, как обрабатываются неисправности неинформационной безопасности, возможно, при оценке и разрешении с помощью технического персонала (которые могут или не могут быть членами ISIRT).Вся собранная информация, касающаяся событий или инцидентов в области информационной безопасности, должна храниться в базе данных о событиях/инцидентах/уязвимостях в области информационной безопасности, управляемой ISIRT. В приложении D показан примерный образец для формы отчетности об уязвимостях в области информационной безопасности. На рисунке 3 представлены все этапы эксплуатации и связанные с ними виды деятельности. Первый этап эксплуатационного использования системы менеджмента инцидентов в области информационной безопасности включает обнаружение, сбор соответствующей информации и оповещение о возникновении событий в области информационной безопасности и существовании уязвимостей в области информационной безопасности одним из сотрудников персонала/клиентом организации или автоматически. Организация должна обеспечить то, чтобы данный этап включал в себя обнаружение уязвимостей в области информационной безопасности, которые до сих пор не рассматривались в качестве причины событий в области информационной безопасности, и возможно инцидентов в области информационной безопасности и оповещение о них. Для осуществления этапа обнаружения и оповещения организация должна обеспечить, что ключевыми направлениями деятельности являются: a) обнаружение и оповещение о возникновении событий в области информационной безопасности и существовании уязвимостей в области информационной безопасности одним из сотрудников персонала/клиентом организации или автоматически при помощи: 1) сигнала тревоги от системы мониторинга такой, как IDS/IDP, антивирусные программы, программ приманок (общий термин для системы приманки, используемый, чтобы ввести в заблуждение, отвлечь, перенаправить и стимулировать злоумышленника тратить время на информацию, которая представляется очень ценной, но на самом деле сфабрикована и не будет представлять интерес для законного пользователя [ISO/IEC 18043:2006]) или ловушек "tarpits" (системы, которые намеренно подвергаются и предназначены для задержки атак), журнал систем мониторинга, системы менеджмента информационной безопасности, системы корреляции событий и др.; 2) сигнала тревоги от систем мониторинга сети, как брандмауэры, анализ сетевого потока, веб-фильтрации и др.; 3) анализа журналов информации от устройств, сервисов, хостов, и различных систем, 4) эскалации аномальных событий, выявленных ICT; 5) эскалации аномальных событий, выявленных сервисными службами поддержки; 6) отчета пользователей; 7) внешних уведомлений, поступающих от третьих доверенных сторон, таких как другие ISIRT, сервисные службы информационной безопасности, интернет-провайдеры, поставщики телекоммуникационных услуг, аутсорсинговые компании или государственные ISIRT; b) сбор информации по событиям или уязвимостям в области информационной безопасности, c) обеспечение надлежащей регистрации всей относящейся к PoC деятельности, результатов и соответствующих решений для дальнейшего анализа; d) обеспечение сбора и защищенного хранения данных в электронном виде и постоянного мониторинга защищенного хранения этих данных на случай необходимости их использования для судебного преследования или внутреннего дисциплинарного разбирательства. Примечание – Будущий международный стандарт (ISO/IEC 27037) предоставит информацию по идентификации, сбору, приобретению и сохранению цифровых данных;

более

подробную

e) поддержка режима контроля изменений, включая отслеживание событий и уязвимостей в области информационной безопасности и обновления отчетов по ним с тем, чтобы база данных о событиях/инцидентах/уязвимостях в области информационной безопасности соответствовала действительности; f) возрастающая деятельность на требуемом основании для данного этапа для дальнейшего рассмотрения, пересмотра и/или принятия решений; g) регистрация в системе отслеживания инцидентов. Вся собранная информация, касающаяся событий или уязвимостей в области информационной безопасности, должна храниться в базе данных о событиях/инцидентах/уязвимостях в области информационной безопасности, управляемой ISIRT. Информация, сообщаемая в течение каждого процесса, должна быть как можно более полной на данный момент, чтобы обеспечить наиболее прочную основу для оценок и принятия решений, а также для предпринимаемых действий.

19

СТБ ISO/IEC 27035/ПР_1

Событие в области информационной ISIRT безопасности

Пользователь/ источник

Точка связи (24h×7d)

Внутренние ISIRT (по требованию)

Кризисная функция обработки, включая внешние, сторонние

Обнаружение и оповещение Сигнал об отклонении в развитии или аномалии

Обнаружение Оповещение

Отчет об инциденте

Контактный пункт существует?

Сбор информации Оценка

Возможный инцидент в области информационной безопасности

Сбор информации Оценка

Подтвержденный инцидент в области информационнной безопасности

Немедленное реагирование Категоризация инцидентов и классификация тяжести

Инцидент под контролем

Более позднее реагирование

Реагирование на кризисную ситуацию

Сбор цифровых данных

Коммуникация Снижение ложной тревоги

Пересмотр

Время

Совершенствование

Рисунок 3 – Блок-схема о событиях и инцидентах в области информационной безопасности Примечание – Сигнал ложной тревоги является показателем нежелательного события.

20

СТБ ISO/IEC 27035/ПР_1 6.2 Обнаружение события в области информационной безопасности События в области информационной безопасности могут быть обнаружены непосредственно лицом или лицами, заметившими что-либо, вызывающее беспокойство и имеющее технический, физический или процедурный характер. Обнаружение может осуществляться, например, детекторами огня/дыма или с помощью охранной сигнализации путем передачи сигналов тревоги в заранее определенные места (для осуществления человеком определенных действий). Технические события в области информационной безопасности могут обнаруживаться автоматически, например, это могут быть сигналы тревоги, производимые устройствами анализа записей аудита, межсетевыми экранами, системами обнаружения вторжений, инструментальными средствами антивредоносных кодов (включая антивирусные программы), в каждом случае стимулируемые заранее установленными параметрами этих устройств. Возможные источники обнаружения событий в области информационной безопасности включают следующее: a) пользователи; b) линейные руководители и руководители службы безопасности; c) клиенты; d) отдел информационных технологий, включая Центр эксплуатации сети и Операционный центр безопасности (через поддержку 2-го уровня); e) сервисная служба информационных технологий (через поддержку 1-го уровня); f) поставщики управляемых услуг (включая ISP, поставщиков телекоммуникационных услуг, и производителей); g) ISIRT-ы; h) другие подразделения и сотрудники, которые могут обнаружить аномалии во время ежедневной работы; i) СМИ – средства массовой информации (газеты, телевидение, др.); j) веб-сайты (общественные веб-сайты информационной безопасности, веб-сайты исследователей безопасности, веб-сайты архивов стирания, др.). 6.3 Оповещение о событии в области информационной безопасности Независимо от источника обнаружения события в области информационной безопасности, лицо, непосредственно обратившее внимание на нечто необычное или оповещенное автоматическими средствами, несет ответственность за инициирование процесса обнаружения и оповещения. Этим лицом может быть любой представитель персонала организации, работающий постоянно или по договору подряда. Этот представитель должен следовать процедурам и использовать форму отчета о событиях в области информационной безопасности, определенную системой менеджмента инцидентов в области информационной безопасности, с целью привлечения внимания, прежде всего, группы обеспечения эксплуатации и менеджмента. Следовательно, важно, чтобы весь персонал был ознакомлен с рекомендациями, относящимися к вопросу оповещения о возможных событиях в области информационной безопасности, включая формы отчета, имел доступ к ним и знал сотрудников, которых необходимо оповещать о каждом случае появления события в области информационной безопасности. Это включает в себя форму отчета о событиях в области информационной безопасности и сведения о сотрудниках, которые должны быть зарегистрированы относительного каждого случая (все сотрудники должны быть, по крайней мере, осведомлены о форме отчета, что способствовало бы пониманию ими системы менеджмента инцидентов в области информационной безопасности). Необходимо отметить, что стационарный, беспроводной и мобильный телефон без защитных мер от прослушивания считается небезопасным. При работе с конфиденциальной и секретной информацией должны быть предприняты дополнительные защитные меры. Следующая информация может быть использована как основа для формы регистрации в системе отслеживания инцидентов:  время/дата обнаружения;  наблюдения;  контактная информация (необязательно). Завершенная форма (представленная на бумаге или в электронной форме e-mail или web) должна использоваться сотрудниками ISIRT только при регистрации инцидентов в области информационной безопасности в системе отслеживания инцидентов. Более важным является получение знаний/отчетов о предполагаемых/уже имевших место/обнаруженных событиях в области информационной безопасности, чем завершенность со всей информацией. Отслеживание события в области информационной безопасности (возможно инцидента) должно поддерживаться, когда это возможно, автоматизированным приложением. Использование информационной системы важно для принуждения персонала следовать установленным процедурам и контрольным спискам. Также крайне полезно отслеживать "кто что сделал и когда", подробности, которые 21

СТБ ISO/IEC 27035/ПР_1 могут быть пропущены по ошибке во время события в области информационной безопасности (возможно инцидента). Обработка конкретного события в области информационной безопасности зависит от того, что оно собой представляет, а также от последствий и воздействий, к которым это событие может привести. Для многих людей принятие решения о способе обработки события выходит за пределы их компетентности. Поэтому сотрудник, информирующий о событии в области информационной безопасности, должен заполнить форму отчета так, чтобы в ней было как можно больше информации, доступной ему на тот момент. При необходимости он/она связывается со своим руководителем. Эту форму нужно передать безопасным способом в надлежащую PoC (работающую 24 ч в сутки 7 дней в неделю), а копию сообщения – ответственной ISIRT. Образец формы отчета сообщения о событии в области информационной безопасности представлен в приложении A. ISIRT должны назначить одного члена команды или представителя в смену, чтобы нести ответственность за все отчеты, направленные по электронной почте, телефону, факсу, входящие формы и прямой разговор. Эта ответственность может вращаться между членами команды на еженедельной основе. Назначенный член команды делает оценку и принимает надлежащие меры для информирования ответственных и заинтересованных сторон, а также для разрешения инцидента в области информационной безопасности. Следует подчеркнуть, что не только точность, но и своевременность важна для заполнения формы отчетности в случае информационной безопасности. Уместным является задержание представления формы отчетности для того, чтобы повысить точность ее содержания. Следует также признать, что некоторые механизмы отчетности (например, электронная почта) сами по себе являются целями для атаки. Следует подчеркнуть, что при заполнении формы отчета важна не только точность содержания, но и своевременность заполнения. Не следует задерживать представление формы отчета о событии в области информационной безопасности по причине уточнения ее содержания. Если сообщающий сотрудник не уверен в данных какого-либо поля в форме отчета, то это поле должно быть помечено, а уточнение – послано позже. Также следует признать, что некоторые механизмы электронного оповещения (например, электронная почта) сами являются очевидными целями атаки. При наличии проблем или при существовании мнения о наличии проблем с установленными по умолчанию механизмами электронного оповещения (например, электронной почтой), включая случаи атаки на систему и считывание формы отчета несанкционированными лицами, должны использоваться альтернативные средства связи. Альтернативными средствами связи могут быть нарочные, телефон, текстовые сообщения. Такие альтернативные средства должны использоваться на ранних стадиях расследования, когда становится очевидным, что событие в области информационной безопасности будет переведено в категорию инцидента в области информационной безопасности, особенно если такого инцидента в области информационной безопасности, который может считаться значительным. Событие в области информационной безопасности может быть быстро определено, как ложная тревога или приведено к удовлетворительному заключению. В этих случаях форму отчетов необходимо заполнить и отправить местному руководству PoC и ISIRT с целью регистрации ее, т.е. внесения в базу данных о событиях/инцидентах/уязвимостях в области информационной безопасности. В этом случае лицо, сообщающее о закрытии события в области информационной безопасности, может предоставить информацию, требуемую для заполнения формы отчета об инцидентах в области информационной безопасности – в этом случае такая форма отчета об инциденте в области информационной безопасности должна быть заполнена и отправлена по инстанции. Использование автоматических инструментов может помочь с завершением некоторых областей, например отметки времени, а также с обменом/передачей необходимой информации.

7 Этап оценки и принятия решений 7.1 Обзор ключевых направлений деятельности Второй этап операционного использования системы менеджмента инцидентов в области информационной безопасности включает в себя оценку информации, относящейся к возникновению событий в области информационной безопасности и принятие решений, являются ли они инцидентами в области информационной безопасности. Для этапа оценки и принятия решений организация должна обеспечить следующие ключевые направления деятельности: a) деятельность PoC по оценке для определения, подходит ли данное событие под категорию инцидента в области информационной безопасности или является ложным, если оно не является ложным, то необходима эскалация. Оценки должны включать в себя использование согласованной классификационной шкалы событий/инцидентов в области информационной безопасности (включая определение последствий событий, основанных на активах/сервисах, подверженных воздействию) и принятие решений, должны ли события классифицироваться как инциденты в области информационной безопасности (см. приложение С для примерных рекомендаций). В процессе определения последствий 22

СТБ ISO/IEC 27035/ПР_1 событий в области информационной безопасности (и, следовательно, возможных инцидентов) с точки зрения воздействий нарушений конфиденциальности, целостности и доступности, организации должны обеспечить то, чтобы определялось следующее: 1) область воздействия (физическая и логическая); 2) активы, инфраструктуры, информация, процессы, сервисы и приложения, подверженные воздействию или которые будут подвержены воздействию; 3) возможные воздействия на основные сервисы организации; b) деятельность для ISIRT по оценке для подтверждения результатов оценки PoC, может ли событие определяться как инцидент в области информационной безопасности. По мере необходимости должна проводиться другая оценка с использованием согласованной классификационной шкалы событий/инцидентов в области информационной безопасности, учитывая сведения о типе события (возможно инцидента) и подверженном воздействию источнике (категоризация) (см. приложение С для примерных рекомендаций). Данные события должны сопровождаться принятием решений о том, как бороться с подтвержденными инцидентами в области информационной безопасности, кто и в какой последовательности. При этом анализ должен содержать предопределенный процесс распределения по приоритетам, чтобы позволить сосредоточиться на соответствии каждого инцидента в области информационной безопасности подходящему типу и определить необходимость обработки и реагирования на инциденты в области информационной безопасности, включая принятие немедленных ответных мер, проведения экспертного анализа информационной безопасности и коммуникационной деятельности на следующем этапе (Ответные меры – см. также раздел 8); c) возрастающая деятельность на требуемом основании в данном этапе для дальнейшего рассмотрения, пересмотра и/или принятия решений; d) обеспечение надлежащей регистрации всей вовлеченной деятельности, в частности ISIRT, для дальнейшего анализа; e) обеспечение сбора и защищенного хранения данных в электронном виде и постоянного мониторинга защищенного хранения этих данных на случай необходимости их использования для судебного преследования или внутреннего дисциплинарного разбирательства; f) поддержка режима контроля изменений, включая отслеживание событий и уязвимостей в области информационной безопасности и обновления отчетов по ним с тем, чтобы база данных о событиях/инцидентах/уязвимостях в области информационной безопасности соответствовала действительности. Вся собранная информация о событиях/инцидентах или уязвимостях в области информационной безопасности должна храниться в базе данных о событиях/инцидентах/уязвимостях в области информационной безопасности под руководством ISIRT. Вся информация, сообщаемая в процессе каждого вида деятельности должна быть максимально полной на данный момент, чтобы обеспечить хорошую базу, доступную для оценки и принятия решений, и конечно предпринятые действия. После обнаружения и оповещения о событии в области информационной безопасности, действия следующие: g) распределение обязанностей за деятельность по менеджменту инцидентов в области информационной безопасности через соответствующую иерархию сотрудников с помощью оценки, принятия решений и действия, включая персонал, как службы безопасности, так и других сотрудников; h) обеспечение формальных процедур, которым нужно следовать, для каждого уведомленного лица, включая пересмотр и исправление составленного отчета, оценку нанесенного ущерба и уведомление соответствующего персонала (учитывая отдельные действия в зависимости от типа и серьезности инцидента); i) использование руководящих принципов для составления полной документации о событиях в области информационной безопасности; j) использование руководящих принципов для составления полной документации последующих действий касательно инцидентов в области информационной безопасности, если событие в области информационной безопасности классифицируется как инцидент в области информационной безопасности; k) обновление базы данных о событиях/инцидентах/уязвимостях в области информационной безопасности. Организация должна гарантировать, что данный этап включает в себя оценку собранной информации об уязвимостях в области информационной безопасности, о которых сообщили (которые ранее не рассматривались в качестве причины событий в области информационной безопасности, и возможно инцидентов в области информационной безопасности), с принятием решений относительно того, с какими из них нужно бороться, кому и в какой приоритетной последовательности. 7.2 Оценка и предварительное решение PoC В PoC принимающее лицо должно подтвердить получение заполненной формы отчета, ввести ее в базу данных событий/инцидентов в области информационной безопасности и проанализировать данную форму отчета. Далее должностное лицо должно попытаться получить любые уточнения от сообщившего 23

СТБ ISO/IEC 27035/ПР_1 лица о событии в области информационной безопасности и собрать требуемую дополнительную информацию, считающуюся доступной, как от сообщившего о событии лица, так и из любого другого места. Затем представитель группы обеспечения эксплуатации должен провести оценку для определения, подходит ли это событие под категорию инцидента в области информационной безопасности или является ложным (включая использование согласованной классификационной шкалы инцидентов организации). Если событие в области информационной безопасности определяется как ложное, необходимо заполнить форму отчета и передать в ISIRT для записи в базу данных о событиях/инцидентах/уязвимостях в области информационной безопасности и дальнейшего анализа, а также создать копии для сообщившего о событии лица и его руководителя. Информация и другие данные, собранные на этом этапе, могут потребоваться в будущем для дисциплинарного или судебного разбирательства. Лицо или лица, выполняющие задачи сбора и оценки информации, должны хорошо знать требования по сбору и сохранению данных. Дополнительно к дате (датам) и времени выполнения действий необходимо полностью документировать: – проведенные мероприятия (включая использованные средства) и их цели; – место хранения доказательства наличия события; – способ архивирования данных (по возможности); – способ верификации данных (по возможности); – детали хранения материалов и последующего доступа к ним. Если событие в области информационной безопасности определено как вероятный инцидент в области информационной безопасности, и сотрудник PoC имеет соответствующий уровень компетентности, то проводится дальнейшая оценка. В результате чего могут потребоваться корректирующие действия, например идентификация дополнительных аварийных защитных мер и обращение за помощью в их реализации к соответствующему лицу. Событие в области информационной безопасности может быть определено как инцидент в области информационной безопасности, причем значительный (по шкале серьезности, принятой в организации), в этом случае необходимо проинформировать непосредственно руководителя ISIRT. Может потребоваться объявление кризисной ситуации и, как следствие, уведомление руководителя обеспечения непрерывности бизнеса о возможной активизации плана обеспечения непрерывности бизнеса с одновременным информированием руководителя ISIRT и вышестоящего руководства. Однако наиболее вероятна ситуация передачи инцидента в области информационной безопасности непосредственно в ISIRT для дальнейшей оценки и выполнения соответствующих действий. Каким бы ни был следующий шаг, сотрудник PoC должен заполнить форму отчета по возможности наиболее подробно. Форма отчета об инциденте в области информационной безопасности должна содержать информацию в описательном виде и, насколько это возможно, характеризовать: a) что представляет собой инцидент в области информационной безопасности; b) что явилось его причиной, чем или кем он был вызван; c) на что он влияет или может повлиять; d) реальное или потенциальное воздействие инцидента в области информационной безопасности на бизнес организации; e) указание на вероятную значительность или незначительность инцидента в области информационной безопасности (по шкале серьезности, принятой в организации); f) как инцидент в области информационной безопасности обрабатывался до этого времени. При рассмотрении потенциального или фактического негативного воздействия инцидента на бизнес организации, примерами являются следующие: a) несанкционированное разглашение информации; b) несанкционированная модификация информации; c) отказ от имеющейся информации; d) недоступность информации и/или сервиса; e) уничтожение информации и/или сервиса; f) снижение предоставления сервиса. Первым шагом нужно определить, какое из перечисленных последствий значимо. Для категорий, отнесенных к инциденту в области информационной безопасности, должны использоваться соответствующие рекомендации по категорированию потенциальных или фактических воздействий для внесения их в отчет по инцидентам в области информационной безопасности. Примеры рекомендаций приведены в приложении С. Примеры категорий следующие: a) финансовые убытки/прерывание бизнес-операций; b) ущерб коммерческим и экономическим интересам; c) ущерб информации, содержащей персональные данные; d) нарушение правовых и нормативных обязательств; e) утрата престижа организации; f) получение травмы или потеря жизни; g) социальное разрушение. 24

СТБ ISO/IEC 27035/ПР_1 Если инцидент в области информационной безопасности был разрешен, то отчет должен содержать детали предпринятых защитных мер и извлеченных уроков (например, защитные меры, которые должны быть приняты для предотвращения повторного появления подобных инцидентов в области информационной безопасности). После наиболее подробного, по мере возможности, заполнения форма отчета должна быть представлена в ISIRT для ввода в базу данных о событиях/инцидентах/уязвимостях в области информационной безопасности и анализа в будущем. Если расследование проводится больше периода времени, определенного в политике менеджмента инцидентов в области информационной безопасности, то должен быть составлен промежуточный отчет в течение времени, определенном политикой. Важно, чтобы сотрудник PoC, оценивающий инцидент в области информационной безопасности, основываясь на руководстве, содержащемся в документации системы менеджмента инцидентов в области информационной безопасности, был осведомлен о следующем: a) когда и кому необходимо направлять материалы об инциденте; b) о том, что при осуществлении всех действий, выполняемых PoC, необходимо выполнять документированные процедуры контроля изменений. Подобным образом к упомянутому в подразделах 6.2 и 6.3 выше относительно обнаружения и оповещения о событии в области информационной безопасности, должны использоваться альтернативные средства связи при наличии проблем или мнения о том, что существуют проблемы с установленными по умолчанию механизмами электронного оповещения (например, электронной почтой). 7.3 Оценка и подтверждение инцидента ISIRT Оценка и подтверждение решения относительно того, надо ли отнести событие в области информационной безопасности к инциденту в области информационной безопасности, должны входить в обязанности ISIRT. Принимающий отчеты сотрудник ISIRT должен: a) подтвердить получение формы отчета, заполненной по возможности наиболее подробно PoC; b) ввести эту форму в базу данных о событиях/инцидентах/уязвимостях в области информационной безопасности, если это не было сделано PoC, и обновить базу данных при необходимости; c) обратиться за уточнениями к PoC при необходимости; d) проанализировать содержание отчетной формы; e) отобрать дополнительную необходимую информацию и известную как доступную от PoC или лица, заполнившего отчетную форму, или из какого-либо иного источника. Если все еще остается какая-либо неопределенность относительно аутентичности инцидента в области информационной безопасности или полноты полученной информации, то сотрудник ISIRT должен провести оценку для определения реальности или ложности инцидента в области информационной безопасности (с помощью использования согласованной классификационной шкалы инцидентов организации). Если инцидент в области информационной безопасности определен как ложный, необходимо заполнить отчет о событии в области информационной безопасности, добавить его в базу данных о событиях/инцидентах/уязвимостях в области информационной безопасности и передать руководителю ISIRT. Копии отчета необходимо передать PoC, лицу, сообщившему о событии, и его/ее местному руководителю. Инцидент в области информационной безопасности должен быть соотнесен с любым другим событием/инцидентом, сообщенным в ISIRT. Эта важная деятельность нужна для того, чтобы проверить, связан ли инцидент в области информационной безопасности с любым другим событием/инцидентом в области информационной безопасности или это просто последствие другого инцидента, т.е. в атаках отказа в обслуживании (DoS) или распределенного отказа в обслуживании (DDoS).Сопоставление инцидентов также имеет важное значение в определении приоритетности усилий ISIRT. Если инцидент в области информационной безопасности определяется как реальный, то представитель ISIRT, при необходимости привлекая коллег, должен провести дальнейшую оценку. Целью оценки является максимально быстрое подтверждение: a) того, что представляет собой инцидент в области информационной безопасности, что явилось его причиной, чем или кем был вызван, на что повлиял или мог повлиять, воздействие или потенциальное воздействие инцидента в области информационной безопасности на бизнес организации, указание на вероятную значительность/незначительность инцидента (по шкале серьезности инцидентов, принятой в организации). Если инцидент вызывает серьезное негативное воздействие на бизнес, должна быть начата антикризисная деятельность (см. пункт 8.2.4); b) следующих аспектов для предумышленной технической атаки злоумышленника на некоторую информационную систему, сервис и/или сеть, например: 1) глубина проникновения злоумышленника в систему, сервис и/или сеть и степень контроля, которой он обладает; 2) данные, доступ к которым получил злоумышленник, были ли они скопированы, изменены или удалены; 25

СТБ ISO/IEC 27035/ПР_1 3) о том, какое программное обеспечение было скопировано, изменено или уничтожено злоумышленником; c) прямые и косвенные последствия (например, стал ли физический доступ возможным по причине пожара, является ли уязвимость информационной системы следствием неправильного функционирования программного обеспечения, линии связи или ошибки оператора); d) как до настоящего времени обрабатывался инцидент в области информационной безопасности и кем. При анализе потенциального или реального негативного воздействия инцидента в области информационной безопасности на бизнес организации, на основании информации и/или сервисов, представленных в подразделе 7.2, необходимо подтвердить, какие последствия имели место вследствие данного инцидента. Примеры категорий последствий представлены в подразделе 7.2 и в приложении C. Приоритетные процессы предназначены для рассмотрения инцидента в области информационной безопасности наиболее подходящему лицу или группе лиц в ISIRT с целью содействия адекватному способу реагирования на инцидент в области информационной безопасности. В частности, когда несколько инцидентов информационной безопасности решаются одновременно, приоритеты должны быть установлены для того, чтобы принять ответные меры по отношению к инцидентам в области информационной безопасности. Приоритеты должны быть установлены в соответствии с определенными неблагоприятными воздействиями на бизнес, связанными с инцидентом в области информационной безопасности и предполагаемыми усилиями, необходимыми для реагирования на инцидент в области информационной безопасности. Для инцидентов с одинаковым приоритетом, необходимое усилие – это один из показателей для определения порядка, в котором инциденты должны быть выстроены для принятия ответных мер. Например, инцидент, который легко разрешить, может быть разрешен до разрешения инцидента, требующего больших усилий. Для отнесения потенциальных или фактических воздействий к той или иной категории необходимо использовать соответствующие рекомендации, которые относили бы их к инциденту в области информационной безопасности и вносились в отчет по инцидентам в области информационной безопасности. Примеры рекомендаций представлены в приложениях C и D.

8 Этап принятия ответных мер 8.1 Обзор ключевых направлений деятельности Третий этап использования системы менеджмента инцидентов в области информационной безопасности содержит принятие ответных мер на инциденты в области информационной безопасности в соответствии с согласованными действиями на этапе оценки и принятия решений. В зависимости от принятых решений ответные меры могут быть приняты немедленно, в реальном времени или близком к реальному времени, и некоторые могут также включать экспертный анализ информационной безопасности. Для этапа принятия ответных мер на инциденты в области информационной безопасности и принятия решений организация должна обеспечить следующие ключевые направления деятельности: a) анализ ISIRT для определения, находится ли инцидент в области информационной безопасности под контролем, и деятельность, представленная ниже: 1) деятельность, инициирующая требуемую ответную реакцию на инцидент в области информационной безопасности, если находится под контролем. Это может быть немедленное реагирование, которое может включать активацию процедур по восстановлению, и/или отправление сообщений соответствующему участвующему персоналу, или более позднее более медленное реагирование (например, содействие полному восстановлению после бедствия), гарантируя, что вся информация готова для аналитической деятельности последствий инцидента; 2) деятельность, инициирующая антикризисные действия с помощью эскалации функции обработки кризисной ситуации, если она не находится под контролем или может оказать серьезное воздействие на основные сервисы организации (см. также пункт 8.2.4). Затем функция обработки кризисной ситуации отвечает за инцидент в области информационной безопасности, с полной поддержкой ISIRT (включая активацию плана менеджмента кризисной ситуации), и участие соответствующего персонала, например, руководитель и группа по антикризисному менеджменту организации (для получения рекомендаций по непрерывному менеджменту бизнеса см. ISO/IEC 27031 и ISO/PAS 22399:2007); b) назначение внутренних источников и идентификация внешних источников с целью реагирования на инцидент; c) проведение экспертного анализа информационной безопасности при необходимости и ранжирование относительно классификационной шкалы инцидентов в области информационной безопасности и изменение этого ранжирования шкалы при необходимости; d) возрастающая деятельность на требуемом основании для данного этапа для дальнейшего рассмотрения, пересмотра и/или принятия решений; 26

СТБ ISO/IEC 27035/ПР_1 e) обеспечение надлежащей регистрации всей вовлеченной деятельности, в частности ISIRT, для дальнейшего анализа; f) обеспечение сбора и защищенного хранения данных в электронном виде и постоянного мониторинга защищенного хранения этих данных на случай необходимости их использования для судебного преследования или внутреннего дисциплинарного разбирательства; g) поддержка режима контроля изменений, включая отслеживание событий и уязвимостей в области информационной безопасности и обновления отчетов по ним для того, чтобы база данных о событиях/инцидентах/уязвимостях в области информационной безопасности соответствовала действительности; h) обмен информацией о существующих инцидентах в области информационной безопасности или любых соответствующих подробностях о них другим внутренним или внешним лицам или организациям, в частности владельцам активов/информации/сервисов (определенные во время проведения анализа негативного воздействия) и внутренним/внешним организациям, которые должны участвовать в менеджменте и разрешении инцидента. Вся собранная информация о событиях/инцидентах или уязвимостях в области информационной безопасности должны храниться в базе данных о событиях/инцидентах/уязвимостях в области информационной безопасности под руководством ISIRT. Вся информация, сообщаемая в процессе каждого вида деятельности должна быть максимально полной на данный момент, чтобы обеспечить хорошую базу, доступную для оценки и принятия решений, и конечно для выбора правильных действий. После определения инцидентов в области информационной безопасности и согласования ответных мер, действия следующие: a) распределение обязанностей по менеджменту инцидентов в области информационной безопасности через соответствующую иерархию сотрудников с помощью оценки, принятия решений и действия, включая персонал, как службы безопасности, так и других сотрудников; b) обеспечение формальных процедур, которым нужно следовать, для каждого уведомленного лица, включая пересмотр и исправление составленного отчета, оценку нанесенного ущерба и уведомление соответствующего персонала (учитывая отдельные действия в зависимости от типа и серьезности инцидента); c) использование руководящих принципов для составления полной документации о событиях в области информационной безопасности; d) использование руководящих принципов для составления полной документации последующих действий касательно инцидентов в области информационной безопасности, если событие в области информационной безопасности классифицируется как инцидент в области информационной безопасности; e) обновление базы данных о событиях/инцидентах/уязвимостях в области информационной безопасности. После успешного разрешения инцидента в области информационной безопасности он должен быть формально закрыт, и это должно быть зарегистрировано в базе данных менеджмента инцидентов в области информационной безопасности. Организация должна гарантировать, что этот этап также включает в себя принятие ответных мер на зарегистрированные уязвимости в области информационной безопасности в соответствии с согласованными действиями на этапе оценки и принятия решений. После разрешения уязвимости это должно быть подробно зарегистрировано в базе данных менеджмента инцидентов в области информационной безопасности. Руководство по принятию ответных мер на инциденты в области информационной безопасности представлено в подразделе 8.2. 8.2 Ответные меры 8.2.1 Немедленное реагирование 8.2.1.1 Общие положения В большинстве случаев после подтверждения инцидента член ISIRT должен идентифицировать действия по немедленному реагированию относительно инцидента в области информационной безопасности, регистрации подробностей в форме отчета об инциденте в области информационной безопасности, введению в базу данных событий/инцидентов/уязвимостей в области информационной безопасности и уведомлению соответствующих лиц и групп о требуемых действиях. Результатом данных действий может быть принятие аварийных защитных мер (например, отключение атакованной информационной системы, сервиса и/или сети по предварительному соглашению с соответствующим руководством информационно-технического подразделения и/или бизнес-руководством) и/или определение дополнительных постоянных защитных мер и уведомление соответствующих лиц, а также групп о принятии этих мер. Если аварийные защитные меры не применены, то нужно определить значимость инцидента в области информационной безопасности по классификационной шкале, принятой в организации, и если инцидент в области информационной безопасности достаточно значимый, то об этом необходимо непосредственно уведомить соответствующее вышестоящее руководство. Если 27

СТБ ISO/IEC 27035/ПР_1 очевидна необходимость объявления кризисной ситуации, руководитель, отвечающий за менеджмент кризисной ситуации, должен быть оповещен о возможной активизации плана менеджмента кризисной ситуации, причем необходимо проинформировать руководителя ISIRT и вышестоящее руководство. Общие задачи реагирования на инциденты в области информационной безопасности следующие: a) ограничение потенциальных негативных воздействий (инцидентов в области информационной безопасности); b) совершенствование информационной безопасности. Основная цель системы менеджмента инцидентов в области информационной безопасности и связанной с ней деятельности заключается в минимизации негативного воздействия на бизнес, тогда как выявление злоумышленника должно рассматриваться как вторичная цель. 8.2.1.2 Примерные действия по реагированию Примером действий по немедленному реагированию в случае преднамеренной атаки на информационную систему, сервис и/или сеть может быть то, что они остаются подключенными к интернету или другим сетям. Это позволит критически важным бизнес-приложениям правильно функционировать и собрать как можно больше информации о злоумышленнике, при условии, что злоумышленник не знает, что он/она находится под наблюдением. Необходимо придерживаться запланированных процессов и регистрировать принятые действия. Остерегайтесь "троянов", "руткитов" и др. вирусов, которые могут привести к серьезному повреждению системы. Информационные данные должны быть защищены с помощью шифрования и специализированных протоколов передачи данных: a) при принятии такого решения следует учитывать, что злоумышленник может понять, что за ним/ней наблюдают, и может предпринять действия, которые могут стать причиной дальнейшего повреждения информационной системы, сервиса и/или сети, и соответствующих данных, и злоумышленник может удалить информацию, которая может быть полезной для его/ее отслеживания; b) важно, чтобы при принятии соответствующего решения была техническая возможность быстро и надежно отключить и/или закрыть атакованную информационную систему, сервис и/или сеть. Это служит для заполнения содержания инцидента. Предотвращение повторного проявления инцидента обычно является более приоритетной задачей. В некоторых случаях необходимо учитывать то, что нарушитель выявил слабое место, которое должно быть устранено, а выгоды от выявления нарушителя не оправдывают затраченных на это усилий. Это особенно справедливо, если нарушитель на самом деле не является злоумышленником и не нанес большого или вообще не причинил никакого ущерба. Что касается других инцидентов в области информационной безопасности, кроме преднамеренной атаки, то их источник должен быть идентифицирован. Может потребоваться отключение информационной системы, сервиса и/или сети или изоляция соответствующих их частей (после получения предварительного согласия соответствующего руководства в области информационных технологий и/или бизнес-руководителя) на время внедрения защитных мер. Для этого может потребоваться больше времени, если уязвимое место для информационной системы, сервиса и/или для сети окажется существенным или критически важным. Другим действием по реагированию может быть активизация методов наблюдения (например, ловушка "honeypots" – см. ISO/IEC 18043). Это действие должно осуществляться на основе процедур, документированных для системы менеджмента инцидентов в области информационной безопасности. Информация, которая могла быть повреждена в результате инцидента в области информационной безопасности, должна быть проверена членом ISIRT по записям резервного копирования на предмет изменения, стирания или модификации информации. Может возникнуть необходимость проверки целостности журналов регистрации, поскольку злоумышленник может подделать их с целью сокрытия следов проникновения. 8.2.1.3 Обновление информации об инцидентах Независимо от последующих действий, сотрудник ISIRT должен обновить отчет об инциденте в области информационной безопасности с максимальной детализацией, добавить его в базу данных о событиях/инцидентах/уязвимостях в области информационной безопасности, оповестив об этом руководителя ISIRT и при необходимости других лиц. Обновляют следующую информацию: a) о том, что представляет собой инцидент в области информационной безопасности; b) о том, что явилось причиной, чем или кем он был вызван; c) на что воздействует или мог воздействовать; d) о фактическом или потенциальном воздействии инцидента в области информационной безопасности на бизнес в организации; e) об изменениях в указании на вероятную значимость или незначимость инцидента в области информационной безопасности (по шкале серьезности, принятой в организации); f) о том, как он обрабатывался до этого времени. 28

СТБ ISO/IEC 27035/ПР_1 Если инцидент в области информационной безопасности разрешен, то отчет должен содержать подробности предпринятых защитных мер и извлеченных уроков (например, дополнительные защитные меры, которые следует предпринять для предотвращения повторного появления данного инцидента в области информационной безопасности или подобных ему инцидентов в области информационной безопасности). Обновленный отчет следует добавлять в базу данных событий/инцидентов/уязвимостей в области информационной безопасности и уведомлять руководителя ISIRT и других лиц по их требованию. Следует подчеркнуть, что ISIRT отвечает за обеспечение безопасного хранения информации, относящейся к данному инциденту в области информационной безопасности, с целью возможного проведения дальнейшей экспертизы и возможного использования судом в качестве доказательства. Например, для инцидента в области информационной безопасности, ориентированного на информационные технологии, должны быть предприняты следующие действия. После первоначального обнаружения инцидента в области информационной безопасности все непостоянные данные должны быть собраны до отключения пораженной системы информационных технологий, сервиса и/или сети до проведения судебного расследования. Предназначенная для сбора информация содержит сведения о любых функционирующих процессах и хранит в памяти, кэше и регистрах, подробности о любой предпринимаемой деятельности, и следующее: a) в зависимости от характера инцидента в области информационной безопасности провести полное дублирование пораженной системы или резервное копирование журналов и важных файлов; b) собрать и проанализировать журналы соседних систем, сервисов и/или сетей, например, маршрутизаторов и межсетевых экранов; c) всю собранную информацию хранить на носителях только для чтения; d) при выполнении дублирования на случай судебного разбирательства обеспечить присутствие не менее двух лиц для утверждения и подтверждения того, что все действия были выполнены согласно действующему нормативному законодательству; e) документировать и хранить вместе с исходными носителями технические характеристики и описания инструментальных средств и сервисных команд, которые используются для дублирования на случай судебного разбирательства. Представитель ISIRT также является ответственным, если это возможно на данном этапе, за возвращение в безопасное рабочее состояние пораженных устройств (имеющих или не имеющих отношение к информационным технологиям) в интересах исключения атак на эти устройства. 8.2.1.4 Дополнительные действия При определении членом ISIRT реальности инцидента в области информационной безопасности его дополнительными действиями должны быть: a) проведение экспертного анализа информационной безопасности; b) информирование лиц, ответственных за передачу информации внутри организации и за ее пределами, о фактах и предложениях по информации, которую надо передать, в какой форме и кому. После возможно наиболее подробного заполнения отчета об инциденте в области информационной безопасности отчет вводится в базу данных событий/инцидентов/уязвимостей в области информационной безопасности и передается руководителю ISIRT. Если время расследования превышает время, ранее согласованное внутри организации, то составляется промежуточный отчет. Член ISIRT, оценивающий инцидент в области информационной безопасности, на основании руководства, содержащегося в документации системы менеджмента инцидентов в области информационной безопасности, должен знать: a) когда и кому необходимо направлять материалы; b) что при осуществлении любой деятельности ISIRT необходимо следовать документированным процедурам контроля за внесением изменений. При наличии проблем или если считается, что существуют проблемы в отношении электронных средств связи (например, с электронной почтой или web), включая случаи, когда система, возможно, подвергается атаке, то следует, в первую очередь, сообщить об инциденте в области информационной безопасности ответственным лицам лично, по телефону или текстовым сообщением. При необходимости руководитель ISIRT совместно с руководителем обеспечения безопасности в области информационной безопасности организации и соответствующим руководителем организации или членом совета директоров правления должны связаться со всеми отделами, которые вовлечены в инцидент в области информационной безопасности как внутри организации, так и за ее пределами. Для быстрой и эффективной организации связи необходимо заранее установить надежный метод передачи информации, не зависящий полностью от системы, сервиса и/или сети, на которые может воздействовать инцидент в области информационной безопасности. Такие меры предосторожности могут включать в себя назначение резервных консультантов или представителей организации на случай отсутствия кого-либо из ее основных руководителей.

29

СТБ ISO/IEC 27035/ПР_1 8.2.2 Оценка контролируемости инцидентов в области информационной безопасности После инициирования членом ISIRT немедленного реагирования, проведения соответствующего экспертного анализа информационной безопасности и действий по передаче информации необходимо срочно убедиться, находится ли инцидент в области информационной безопасности под контролем. При необходимости член ISIRT может проконсультироваться с коллегами, руководителем ISIRT и/или другими лицами или группами. Если подтверждается, что инцидент в области информационной безопасности находится под контролем, то член ISIRT должен перейти к другим дальнейшим необходимым действиям по реагированию, проведению экспертного анализа и передаче информации с целью ликвидации инцидента в области информационной безопасности и восстановления нормальной работы пораженной информационной системы. Если не подтверждается, что инцидент в области информационной безопасности находится под контролем, член ISIRT должен инициировать антикризисные действия. Если инцидент в области информационной безопасности связан с потерей доступности, показателем оценки, находится ли инцидент в области информационной безопасности под контролем, может быть время до возвращения к нормальной ситуации после возникновения инцидента в области информационной безопасности. Организация должна определить для каждого актива, на основе результатов оценки рисков информационной безопасности, допустимое окно прерывания, которое поддерживает цель времени восстановления перед возобновлением обслуживания или оценки информации. Как только реагирование превышает допустимое окно прерывания предназначенного актива, инцидент в области информационной безопасности может больше не контролироваться и должно быть принято решение обработать инцидент в области информационной безопасности. Для инцидентов в области информационной безопасности, связанных с потерей конфиденциальности, целостности, др., необходимо определить другие типы суждений, если ситуация находится под контролем и возможные, имеющие отношение к ней, показатели в соответствии с антикризисным планом менеджмента организации. 8.2.3 Последующие ответные меры Определив, что инцидент в области информационной безопасности находится под контролем и не является предметом антикризисной деятельности, представитель ISIRT должен определить необходимость и вероятные способы дальнейшего реагирования в отношении данного инцидента. Реагирование может включать в себя восстановление пораженных информационных систем(ы), сервисов(а) и/или сетей(и) до нормального рабочего состояния. Он/она должен занести детали в форму отчета об инциденте в области информационной безопасности и базу данных событий/инцидентов/уязвимостей в области информационной безопасности, а также проинформировать об этом лиц, ответственных за завершение соответствующих действий. Подробности успешного завершения этих действий необходимо внести в форму отчета об инциденте в области информационной безопасности и базу данных событий/инцидентов/уязвимостей в области информационной безопасности, а затем инцидент в области информационной безопасности должен быть закрыт и соответствующий персонал должен быть проинформирован об этом. Некоторые ответные меры должны быть направлены на предотвращение повторения подобного инцидента в области информационной безопасности. Например, если определено, что причиной инцидента в области информационной безопасности является отказ аппаратной части или программного обеспечения информационных технологий из-за отсутствия доступных обновлений, то в этом случае необходимо немедленно связаться с поставщиком. Если причиной инцидента в области информационной безопасности была известная уязвимость в области информационных технологий, то она должна быть устранена соответствующим обновлением защиты информационной безопасности. Необходимо также решить любые проблемы, связанные с конфигурацией информационных технологий и выявленным инцидентом в области информационной безопасности. Другими мерами уменьшения возможности повторения или появления такого инцидента в области информационной безопасности или подобного ему инцидента могут быть изменение системных паролей и отключение неиспользуемых сервисов. Другая область деятельности по реагированию на инцидент в области информационной безопасности может включать в себя мониторинг системы, сервиса и/или сети информационных технологий. Вслед за оценкой инцидента в области информационной безопасности может оказаться целесообразным ввести дополнительные защитные меры мониторинга для содействия в обнаружении необычных или подозрительных событий, которые могут оказаться признаками инцидентов в области информационной безопасности. Такой мониторинг поможет также глубже раскрыть инцидент в области информационной безопасности и идентифицировать другие системы информационных технологий, которые подверглись компрометации. Может возникнуть необходимость в активизации специальных ответных мер, документированных в соответствующем антикризисном плане менеджмента, которые можно применить к инцидентам в области информационной безопасности как связанным, так и не связанным с информационными технологиями. Такого рода ответные меры должны быть предусмотрены для всех аспектов бизнеса, связанных не только 30

СТБ ISO/IEC 27035/ПР_1 непосредственно с информационными технологиями, но также с поддержкой ключевых функций бизнеса и последующего восстановления с помощью соответствующих речевых телекоммуникаций, уровней персонала и физических устройств. Последней областью реагирования является восстановление пораженных информационных систем(ы), сервисов(а) и/или сетей(и) до нормального рабочего состояния. Восстановление пораженных систем(ы), сервисов(а) и/или сетей(и) до безопасного рабочего состояния может быть осуществлено применением обновлений для известных уязвимостей или отключением скомпрометированных элементов. Если вследствие уничтожения журналов регистрации во время действия инцидента в области информационной безопасности исчезает весь объем информации об инциденте в области информационной безопасности, может потребоваться полная перестройка системы, сервиса и/или сети. Также может потребоваться активизация части соответствующего антикризисного плана менеджмента. Если инцидент в области информационной безопасности, не связанный с информационными технологиями, например, спровоцирован пожаром, наводнением или взрывом, то выполняются действия по восстановлению, документированные в соответствующем антикризисном плане менеджмента. 8.2.4 Антикризисные ответные меры Может случиться так (см. пункт 8.2.2), что при определении ISIRT контролируется ли инцидент в области информационной безопасности, группа придет к выводу, что инцидент в области информационной безопасности не находится под контролем и должен обрабатываться в антикризисном режиме, используя предварительно разработанный план. Лучшие варианты обработки всех возможных типов инцидентов в области информационной безопасности, которые могут повлиять на доступность и, в некоторой степени, на целостность информационной системы, должны быть определены в антикризисном плане менеджмента организации. Эти варианты должны быть непосредственно связаны с приоритетами бизнеса организации и соответствующими временными рамками восстановления бизнес-процессов и, следовательно, с максимально приемлемым временем простоя информационных технологий, речевой связи, персонала и размещения. В стратегии должно быть определено следующее: a) необходимые предупреждающие, поддерживающие и антикризисные меры менеджмента; b) необходимая организационная структура и обязанности, связанные с антикризисным реагированием; c) необходимая структура и основные положения антикризисного плана (планов) менеджмента. Антикризисный план(ы) менеджмента и защитные меры для поддержки активизации этого (этих) плана(ов), протестированные и признанные удовлетворительными, должны создать основу для борьбы с большинством возрастающих по силе инцидентов. В зависимости от типа инцидента и его контролируемости, эскалация может привести к проведению серьезных мероприятий по борьбе с инцидентами и активизировать антикризисный план менеджмента при его наличии. Такие действия могут включать, но не ограничиваются, активизацию: a) средств пожаротушения и процедур эвакуации; b) средств предотвращения наводнения и процедур эвакуации; c) средств предотвращения взрыва бомбы и соответствующих процедур эвакуации; d) работы специалистов по расследованию фактов мошенничества в информационных системах; e) работы специалистов по расследованию технических атак. 8.2.5 Экспертный анализ информационной безопасности Если в ходе предыдущей оценки была определена необходимость экспертного анализа в целях доказательства значимости инцидента в области информационной безопасности, экспертный анализ проводит ISIRT. В целях проведения более подробного экспертного анализа конкретного инцидента в области информационной безопасности необходимо применять следственные методы и средства, основанные на информационных технологиях и поддерживаемые документированными процедурами, не используемые ранее в процессе менеджмента инцидентов в области информационной безопасности. Такую экспертизу проводят структурным методом и определяют, что может использоваться в качестве доказательства при внутренних дисциплинарных разбирательствах или в ходе судебных процессов. Для проведения экспертного анализа могут использоваться технические (например, средства и методы аудита, средства восстановления данных) и программные средства, защищенные служебные помещения, а также соответствующий персонал. Каждое действие информационного экспертного анализа должно быть полностью документировано, включая представление соответствующих фотографий, составление отчетов об анализе результатов аудита, проверку журналов восстановления данных. Квалификация лица или лиц, проводившего(их) экспертный анализ, должна быть документирована так же, как результаты квалификационного тестирования. Необходимо также документировать любую другую информацию, способную продемонстрировать объективность и логический характер экспертного анализа. Все записи о самих инцидентах в области информационной безопасности, деятельности, связанной с экспертным анализом этих инцидентов, и т.д., а также соответствующие носители информации должны храниться в физически защищенной среде и контролироваться соответствующими процедурами для 31

СТБ ISO/IEC 27035/ПР_1 предотвращения доступа к ним неавторизованных лиц с целью модификации записей. Средства экспертного анализа, основанные на применении информационных технологий, должны точно соответствовать стандартам с целью исключения возможности оспаривания этого соответствия в судебном порядке и, в то же время, в них должны учитываться все текущие изменения в технологиях. В физической среде ISIRT необходимо создавать необходимые условия, гарантирующие неоспоримость обработки данных. В любое время для обеспечения реагирования на инцидент в области информационной безопасности число персонала должно быть достаточным. Со временем, несомненно, возникнет необходимость разработки требований к анализу данных в контексте многообразия инцидентов в области информационной безопасности, включая мошенничество, кражу и акты вандализма. Следовательно, для содействия ISIRT потребуется большее число средств, основанных на информационных технологиях, и вспомогательных процедур для раскрытия информации, скрытой в информационной системе, сервисе и/или сети, включая информацию, которая, на первый взгляд, кажется стертой, зашифрованной или поврежденной. Эти средства должны учитывать все аспекты, связанные с известными типами инцидентов в области информационной безопасности и должны быть документированы в процедурах ISIRT. В современных условиях в экспертный анализ часто включают сложные среды с сетевой структурой, в которых расследование распространяется на всю операционную среду, включая множество серверов (например, файловый сервер, серверы печати, коммуникации, электронной почты и т.д.), а также средства удаленного доступа. Существует много инструментальных средств, включая средства поиска текстов, программное обеспечение формирования изображений и пакеты программ для экспертного анализа. Главной целью процедур экспертного анализа является сохранение неприкосновенности данных, их проверка на предмет противостояния любому оспариванию в суде. Следует подчеркнуть, что экспертный анализ должен проводиться на точной копии исходных данных с тем, чтобы избежать сомнений в целостности исходных носителей в ходе аналитической работы. Общий процесс правовой экспертизы должен охватывать следующие виды деятельности: a) обеспечение защиты целевой системы, сервиса и/или сети в процессе проведения правовой экспертизы от превращения их в недоступные, изменения или от иной компрометации, включая введение вредоносных кодов (в том числе вирусов), и обеспечение защиты от воздействий или минимальных воздействий на их нормальную работу; b) назначение приоритетов сбора доказательств, то есть рассмотрение их от наиболее до наименее изменчивых (что в значительной степени зависит от характера инцидента в области информационной безопасности); c) идентификация всех необходимых файлов в предметной системе, сервисе и/или сети, включая нормальные файлы, защищенные паролем или иным образом, и зашифрованные файлы; d) восстановление как можно большего числа стертых файлов и других данных; e) раскрытие IP-адресов, имен хостов, сетевых маршрутов и информации web-сайтов; f) извлечение содержимого скрытых, временных файлов и файлов подкачки, используемых как программное обеспечение операционной системы, так и как прикладное программное обеспечение; g) доступ к содержимому программного обеспечения защищенных или зашифрованных файлов (если это не запрещено законодательством); h) анализ всех возможно значимых данных, найденных в специальных (обычно недоступных) областях памяти на дисках; i) анализ времени доступа к файлу, его создания и модификации; j) анализ журналов регистрации системы/сервиса/сети и приложений; k) определение деятельности пользователей и/или приложений в системе/сервисе/сети; l) анализ электронной почты на наличие исходной информации и ее содержания; m) проведение проверок целостности файлов с целью обнаружения файлов, содержащих "троян", и файлов, изначально отсутствовавших в системе; n) по возможности, анализ физических доказательств ущерба имуществу, например, отпечатков пальцев, результатов видеонаблюдения, журналов регистрации системы сигнализации, журналов регистрации доступа по пропускам и опроса свидетелей; o) обработка и хранение добытых потенциальных доказательств так, чтобы избежать повреждения, приведения в негодность и предотвращения просмотра конфиденциального материала неавторизованными лицами. Следует подчеркнуть, что сбор доказательств должен проводиться всегда в соответствии с правилами судопроизводства или слушания дела, для которых данные доказательства могут предоставляться; p) получение выводов о причинах инцидента в области информационной безопасности, необходимых действиях и времени их выполнения с приведением доказательств, включая список соответствующих файлов, включенных в приложение к главному отчету; q) обеспечение экспертной поддержки для любого дисциплинарного или правового действия при необходимости. Метод(ы) выполнения вышеуказанных действий должен(ы) документироваться в выполняемых процедурах ISIRT. 32

СТБ ISO/IEC 27035/ПР_1 ISIRT должна обладать разнообразными навыками в обширной области технических знаний (включая знание средств и методов, которые, возможно, будут использоваться злоумышленником), опытом проведения анализа/расследования (с учетом защиты используемых доказательств), знанием правовых и нормативных положений и постоянной осведомленностью о тенденциях, связанных с инцидентами в области информационной безопасности. Должны быть приняты следующие положения: a) у некоторых организаций все эти источники могут и не быть доступными, и может быть необходимым проведение экспертного анализа информационной безопасности для специалистов; b) сбор материала по экспертизе информационной безопасности может быть только ресурсом (т.е. оправданные усилия и расходы), в котором обнаружена серьезная потеря и/или возможно уголовное судопроизводство; c) неиспользование источников специалистов для охвата материала по экспертизе информационной безопасности может представить результаты как недопустимые при необходимости проведения судебного иска. 8.2.6 Коммуникации Во многих случаях, при подтверждении реальности инцидента в области информационной безопасности ISIRT, возникает необходимость информирования конкретных лиц как внутри организации (вне обычных линий коммуникации между ISIRT и руководством), так и за ее пределами, включая прессу. Для этого могут потребоваться несколько этапов, например: подтверждение реальности инцидента в области информационной безопасности и его подконтрольности, определение инцидента в области информационной безопасности как объекта антикризисной деятельности, закрытие и завершение анализа инцидента в области информационной безопасности и формирование вывода об инциденте в области информационной безопасности. При необходимости обмена информацией необходимо должным образом позаботиться о том, чтобы обеспечить, кому необходимо знать, что именно и когда. Следует определить заинтересованные лица, на которые оказано влияние, и желательно разделить их на группы, такие как: a) совладельцы внутри организации (кризисное руководство, управленческий штат и пр.); b) внешние совладельцы (владельцы, клиенты, партнеры, поставщики, пр.); c) другие внешние контакты, такие как пресса и/или другие СМИ. Для каждой группы может потребоваться специальная информация, поступающая по соответствующим каналам связи в организации. Одно из наиболее важных заданий коммуникации после инцидента в области информационной безопасности – гарантировать, что непосредственно внешние и внутренние совладельцы имели информацию, соответствующую той, которая поступает через другие внешние контакты, как пресса. Для оказания содействия такой деятельности целесообразно заранее подготовить конкретную информацию с целью быстрой адаптации ее к обстоятельствам возникновения конкретного инцидента в области информационной безопасности и предоставления этой информации прессе и/или другим СМИ. Если прессе предоставляется неполная информация, относящаяся к инцидентам в области информационной безопасности, то она должна быть предоставлена в соответствии с политикой распространения информации организации. Информация, подлежащая распространению среди общественности, должна быть проанализирована соответствующими лицами, например высшим руководством, координаторами по связям с общественностью и персоналом в области информационной безопасности. Примечание – Коммуникации инцидента в области информационной безопасности могу варьировать в зависимости от инцидента и его воздействия в согласовании между отношениями организации и типом бизнеса. Тип бизнеса может также устанавливать конкретные правила о том, каким образом коммуникация должна осуществляться, например, если организация перечислена в списке на общественном фондовом рынке.

8.2.7 Расширение области принятия решений (эскалация) При чрезвычайных обстоятельствах, вероятно, придется поднимать вопросы по адаптации неконтролируемых инцидентов и потенциальной опасности недопустимого воздействия на бизнес. Эти инциденты необходимо разрешить, чтобы активировать план непрерывности бизнеса, если такой имеется, информируя высшее руководство, другую группу внутри организации или лица/группы сторонней организации. Речь может идти о принятии решения относительно рекомендуемых действий, относящихся к разрешению инцидента в области информационной безопасности, или дальнейшей оценке с целью определения требуемых действий. Расширение области принятия решений может потребоваться вслед за деятельностью по оценке, описанной выше в подразделах 7.2 и 7.3, или происходить в ходе процессов оценки, если проблема становится очевидной на ранней стадии ее обнаружения. Для тех, кому придется принимать решение о расширении области принятия решений, т.е. для PoC и членов ISIRT, необходимо иметь доступное руководство в документации системы менеджмента инцидентов в области информационной безопасности. 33

СТБ ISO/IEC 27035/ПР_1 8.2.8 Регистрация деятельности и контроль за внесением изменений Следует подчеркнуть, что все, кто причастен к оповещению о возникновении и менеджменту инцидентов в области информационной безопасности, должны надлежащим образом регистрировать все свои действия для их дальнейшего анализа. Информацию об этих действиях вносят в форму отчета об инцидентах в области информационной безопасности и в базу данных событий/инцидентов/уязвимостей в области информационной безопасности, непрерывно обновляемую в течение всего цикла действия инцидента в области информационной безопасности, от первой формы отчета до завершения анализа инцидента в области информационной безопасности. Эта информация должна храниться по возможности с применением средств защиты и обеспечением соответствующего режима резервного копирования. Кроме того, изменения, вносимые в процессе отслеживания инцидента в области информационной безопасности, обновления форм отчета и баз данных событий/инцидентов/уязвимостей в области информационной безопасности, должны вноситься в соответствии с формально принятой системой контроля за внесением изменений.

9 Этап извлеченные уроки 9.1 Обзор ключевых направлений деятельности Четвертый этап операционного использования системы менеджмента инцидентов в области информационной безопасности наступает после разрешения/закрытия инцидентов в области информационной безопасности и включает в себя извлечение уроков из того, каким образом инциденты (уязвимости) были обработаны и разрешены. Для этапа извлеченных уроков организация должна обеспечить следующие ключевые направления деятельности: a) проведение дальнейшего экспертного анализа при необходимости; b) идентификацию уроков, извлеченных из инцидентов и уязвимостей в области информационной безопасности; c) анализ, идентификацию и внесение усовершенствований в процесс осуществления контроля над информационной безопасностью (новые и/или обновленные защитные меры), а также в политику менеджмента инцидентов в области информационной безопасности как результат извлеченных уроков, как из одного, так и нескольких инцидентов в области информационной безопасности (или в действительно от оценки уязвимостей в области информационной безопасности, о которых сообщили). Этому способствует метрика, предоставленная в стратегии организации, куда инвестировать, в отношении защитных мер в области информационной безопасности; d) анализ, идентификацию и внесение усовершенствований в существующую в организации оценку рисков в области информационной безопасности и результаты анализа менеджмента в качестве результата извлеченных уроков; e) анализ того, насколько эффективны процессы, процедуры, форматы отчетов и/или организационная структура в процессах реагирования, оценки и восстановления после каждого инцидента в области информационной безопасности и разрешение уязвимостей в области информационной безопасности. И на основе извлеченных уроков идентификация и совершенствования системы менеджмента инцидентов информационной безопасности и ее документация; f) обновление базы данных событий/инцидентов/уязвимостей в области информационной безопасности; g) передачу и обмен информацией о результатах анализа внутри сообщества, которому доверяют (по желанию организации). Следует подчеркнуть, что деятельность по менеджменту инцидентов в области информационной безопасности повторяется, следовательно, организация должна регулярно совершенствовать ряд элементов информационной безопасности с течением времени. Эти усовершенствования должны предлагаться на основе анализа данных касательно инцидентов в области информационной безопасности и ответных мер в их отношении, а также на основе известных уязвимостей в области информационной безопасности и тенденций с течением времени. 9.2 Дальнейший экспертный анализ информационной безопасности Иногда после разрешения инцидента в области информационной безопасности может попрежнему сохраняться необходимость проведения экспертного анализа информационной безопасности с целью определения доказательств. Он должен проводиться ISIRT с использованием той же совокупности средств и процедур, которая предложена в пункте 8.2.5. 9.3 Идентификация извлеченных уроков После завершения инцидента в области информационной безопасности для организации важно быстро идентифицировать уроки, извлеченные из его обработки, и гарантировать, что заключения действуют. Далее уроки, извлеченные из процессов оценки и разрешения известных уязвимостей в области информационной безопасности. Они могут рассматриваться с точки зрения: 34

СТБ ISO/IEC 27035/ПР_1 a) новых или изменившихся требований к мерам защиты информационной безопасности. Это могут быть технические или нетехнические (включая физические) меры защиты. В зависимости от извлеченных уроков требования могут включать в себя необходимость быстрого обновления материалов и проведения брифингов с целью обеспечения осведомленности в вопросах безопасности (для пользователей, а также для другого персонала) и издания руководств и/или стандартов по безопасности; b) новой и измененной информации об угрозах и уязвимостях и, следовательно, внесенных изменений процесс оценки рисков информационной безопасности, существующий в организации, и результатов анализа менеджмента; c) изменений в системе менеджмента инцидентов в области информационной безопасности и ее процессах, процедурах, форматах отчетов и/или организационной структуре, и в базе данных событий/инцидентов/уязвимостей в области информационной безопасности. Организации следует рассматривать полученный опыт не только в рамках отдельного инцидента или уязвимости в области информационной безопасности, но и проводить проверку наличия тенденций/моделей, которые могут быть способствовать определению потребности в защитных мерах или изменениях подходов к устранению инцидента в области информационной безопасности. Целесообразно также проведение тестирования информационной безопасности, в частности оценки уязвимостей, после ориентированного на информационные технологии инцидента в области информационной безопасности. Поэтому организация должна регулярно анализировать базы данных событий/инцидентов/уязвимостей в области информационной безопасности, чтобы: a) определить тенденции/модели поведения; b) выявить проблемные области; c) проанализировать, в каких областях можно предпринять предупредительные меры для снижения вероятности появления инцидентов в будущем. Информация, получаемая в процессе обработки инцидента в области информационной безопасности, должна направляться для анализа тенденций/моделей поведения (аналогично способу обработки известных уязвимостей в области информационной безопасности), что может в значительной мере способствовать ранней идентификации инцидентов в области информационной безопасности и обеспечить предупреждение о том, какие инциденты в области информационной безопасности могут возникнуть в будущем на основе предшествующего опыта и документов. Необходимо также использовать информацию об инцидентах в области информационной безопасности и соответствующих им уязвимостях, полученную от государственных и коммерческих ISIRT и поставщиков. Тестирование безопасности и оценка уязвимостей информационной системы, сервиса и/или сети, следующие за инцидентом в области информационной безопасности, не должны ограничиваться только информационной системой, сервисом и/или сетью, пораженных этим инцидентом в области информационной безопасности. Тестирование безопасности и оценку уязвимостей необходимо распространить на любые связанные с ними информационные системы, сервисы и/или сети. Детальная оценка уязвимостей используется для того, чтобы в ходе инцидента в области информационной безопасности выявить существование уязвимостей на других информационных системах, сервисах и/или сетях, и исключить вероятность появления новых уязвимостей. Важно подчеркнуть, что оценка уязвимостей должна проводиться регулярно и повторная оценка уязвимостей, проводимая после инцидента в области информационной безопасности, должна быть частью, а не заменой непрерывного процесса оценки. Необходимо опубликовывать итоговый анализ инцидентов и уязвимостей в области информационной безопасности для обсуждения их на каждом совещании руководства организации по вопросам обеспечения информационной безопасности и/или на других форумах, касающихся вопросов общей организационной политики информационной безопасности. 9.4 Идентификация и усовершенствование информационной безопасностью

процесса

осуществления

контроля

над

В процессе анализа инцидентов или уязвимостей в области информационной безопасности, проведенного после разрешения одного или нескольких инцидентов, новые или измененные защитные меры могут быть определены как необходимые для системы. Рекомендации и соответствующие им требования к защитным мерам могут оказаться такими, что их немедленное внедрение будет невозможно по финансовым или эксплуатационным причинам. В этом случае они должны быть предусмотрены в более долгосрочных целях организации. Например, по финансовым соображениям невозможно за короткое время осуществить переход к более совершенным межсетевым экранам, тем не менее, решение этого вопроса необходимо внести в долговременные цели информационной безопасности организации. В соответствии с согласованными рекомендациями, организация должна внедрять обновленные и/или новые защитные меры. Это могут быть технические (включая физические) меры защиты, и могут включать в себя необходимость быстрого обновления материалов и проведения брифингов с целью обеспечения осведомленности в вопросах безопасности (для пользователей, а также для другого персонала) и издания руководств и/или стандартов по безопасности. Далее информационные системы, 35

СТБ ISO/IEC 27035/ПР_1 сервисы и/или сети организации должны быть предметом регулярных оценок уязвимостей, способствуя, таким образом, идентификации уязвимостей и обеспечению процесса непрерывного повышения надежности системы/сервиса/сети. В дополнение, хотя анализ процедур и документации, относящихся к информационной безопасности, может проводиться непосредственно сразу после инцидента в области информационной безопасности или разрешенной уязвимости, вероятнее всего это требуется как последующее реагирование. После разрешения инцидента или уязвимости в области информационной безопасности при необходимости организация должна обновлять свою политику информационной безопасности и процедуры, чтобы учесть подобранную информацию и любые проблемные вопросы, выявляемые в процессе менеджмента инцидентов. Долговременная цель ISIRT в согласовании с менеджером информационной безопасности организации заключается в гарантировании того, что эти обновления политики информационной безопасности и процедур распространяются на всю организацию. 9.5 Идентификация и усовершенствование процесса оценки риска информационной безопасности и результатов анализа менеджмента В зависимости от серьезности инцидента в области информационной безопасности и степени его воздействия при оценке результатов анализа рисков информационной безопасности и менеджмента информационной безопасности (или серьезности и вероятности воздействия в отношении известных уязвимостей в области информационной безопасности), возможно, понадобится учитывать новые угрозы и уязвимости. В результате завершения обновленного анализа рисков информационной безопасности и анализа менеджмента информационной безопасности может возникнуть необходимость внесения изменений в существующие или выработка новых защитных мер (см. подраздел 9.4). 9.6 Идентификация и усовершенствование системы менеджмента инцидентов в области информационной безопасности После разрешения инцидента руководитель ISIRT или назначенное вместо него лицо должны проанализировать все произошедшее с целью оценки и определения степени результативности реагирования на инцидент в области информационной безопасности. Подобный анализ предназначен для выявления успешно задействованных элементов системы менеджмента инцидентов в области информационной безопасности и определения потребности в любых совершенствованиях. Важным аспектом анализа, проводимого после реагирования на инцидент, является возвращение информации и полученных знаний в систему менеджмента инцидентов в области информационной безопасности. Если инцидент в области информационной безопасности достаточно серьезен, то вскоре после разрешения инцидента необходимо провести совещание всех заинтересованных сторон, владеющих информацией о нем. На этом совещании должны рассматриваться следующие вопросы: a) Работали ли должным образом процедуры, принятые в системе менеджмента инцидентов в области информационной безопасности? b) Существуют ли процедуры или методы, которые способствовали бы обнаружению инцидентов? c) Были ли определены процедуры или средства, которые использовались бы в процессе реагирования? d) Применялись ли процедуры, помогающие восстановлению информационных систем после идентификации инцидента? e) Была ли передача информации об инциденте всем участвующим сторонам в процессе обнаружения, сообщения и реагирования? Результаты совещания должны быть документированы. Организация должна гарантировать, что области системы менеджмента инцидентов в области информационной безопасности, предназначенные для совершенствования, должны быть проанализированы, а обоснованные изменения внесены в обновленный вариант документации системы. Изменения в процессах, процедурах и формах отчета системы менеджмента инцидентов в области информационной безопасности должны быть тщательно проверены и протестированы перед применением на практике. 9.7 Другие усовершенствования Другие усовершенствования могут быть идентифицированы на этапе извлеченных уроков, например, изменения в политиках, стандартах и процедурах информационной безопасности, а также изменения в конфигурациях аппаратного и программного обеспечения информационных технологий. Организация должна гарантировать должное функционирование всех пунктов.

36

СТБ ISO/IEC 27035/ПР_1

Приложение A (справочное) Таблица перекрестных ссылок ISO/IEC 27001 и ISO/IEC 27035 Пункт ISO/IEC 27001:2005 4.2.2 Внедрение и эксплуатация СМИБ Организация должна: h) внедрить процедуры и другие средства управления, позволяющие обеспечить быстрое обнаружение событий и реагирование на инциденты в области безопасности

4.2.3 Мониторинг и анализ СМИБ Организация должна: a) выполнять процедуры мониторинга и анализа и применять другие средства управления, для того чтобы: 2) своевременно идентифицировать неудавшиеся и успешные попытки нарушения и инциденты в области безопасности; 4) способствовать обнаружению событий в области безопасности и таким образом предотвращать инциденты в области безопасности по средствам использования показателей; b) регулярно проводить анализы результативности СМИБ (включая оценку соответствия политике и целям СМИБ и анализ средств управления), принимая во внимание результаты аудитов безопасности, инциденты, результаты измерений результативности, предложения и обратную связь от всех заинтересованных сторон 4.3.3 Контроль составления отчетов Записи должны отражать выполнение процессов, определенных в соответствии с 4.2, и все случаи возникновения инцидентов в области информационной безопасности, связанных со СМИБ А.13 Менеджмент инцидентов в области информационной безопасности

А.13.1 Отчетность о событиях в области информационной безопасности и ее уязвимостях Цель: Обеспечить оповещение о событиях в области информационной безопасности и

Пункт ISO/IEC 27035 4 (Общие положения) для краткого обзора внедрения менеджмента инцидентов в области информационной безопасности. 5 (Планирование и подготовка) – содержание пункта может помочь во внедрении менеджмента инцидентов в области информационной безопасности. 6 (Обнаружение и оповещение). 7 (Оценка и принятие решения). 8 (Ответные меры) и 9 (Извлеченные уроки) – содержание пунктов может помочь в осуществлении менеджмента инцидентов в области информационной безопасности 9 (Извлеченные уроки) – содержание пункта может помочь в проведении мониторинга и анализа менеджмента инцидентов в области информационной безопасности

5.1 (Обзор ключевых направлений деятельности), 6 (Обнаружение и оповещение) и приложение D (Пример отчетов о событиях, инцидентах и уязвимостях в области информационной безопасности и образец формы отчета) – содержание пунктов может помочь в определении области действия отчетов 4 (Общие положения) для краткого обзора внедрения менеджмента инцидентов в области информационной безопасности. 5 (Планирование и подготовка) – содержание пункта может помочь во внедрении менеджмента инцидентов в области информационной безопасности 5 (Планирование и подготовка) (в частности, см. 5.4 Система менеджмента инцидентов в области информационной безопасности, 5.5 Создание ISIRT, 5.6 Техническая и другая поддержка, 5.7 Обучение и повышение осведомленности и 5.8 Тестирование системы менеджмента) 37

СТБ ISO/IEC 27035/ПР_1 Пункт ISO/IEC 27001:2005

Пункт ISO/IEC 27035

уязвимостях, связанных с информационными системами, для принятия своевременных корректирующих действий.

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

А.13.1.10 Средство управления: о событиях в области информационной безопасности должно быть сообщено по соответствующим каналам управления настолько быстро, насколько это возможно. А.13.1.2 Отчетность безопасности

об

уязвимостях

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

А.13.2 Менеджмент инцидентов в области информационной безопасности и ее усовершенствования Задача: обеспечить согласованный и результативный подход к менеджменту инцидентов в области информационной безопасности.

Приложение D.2.1 (Пример элементов отчета о событиях в области информационной безопасности) и приложение D.4.1 (Пример из отчета о событиях в области информационной безопасности) для приведения примера формы отчета. Приложение D.2.3 (Пример формы отчета об уязвимостях в области информационной безопасности) для приведения примера формы отчета 7 (Оценка и принятие решений), 8 (Ответные меры), 9 (Извлеченные уроки) и приложение B (Пример инцидентов в области информационной безопасности и их причин), приложение С(Пример подходов к категоризации и классификации событий в области информационной безопасности и инцидентов) и приложение Е (Нормативноправовые аспекты).

А.13.2.1 Ответственность и процедуры Средство управления: должны быть установлены ответственность руководства и процедуры, позволяющие обеспечить быстрое, результативное и последовательное реагирование на инциденты в области информационной безопасности А.13.2.2 Извлечение уроков из инцидентов в области информационной безопасности Средство управления: должны быть определены механизмы, позволяющие осуществлять количественную оценку и мониторинг инцидентов в области информационной безопасности по типам, объемам и стоимостям

7 (Оценка и принятие решений), 8 (Ответные меры), приложение D.2.2 (Пример элементов отчета об инцидентах в области информационной безопасности) и приложение D.4.2 (Образец формы отчета об инцидентах в области информационной безопасности) – содержание пунктов может помочь в определении обязанностей и процедур 9 (Извлеченные уроки), приложение B (Пример инцидентов в области информационной безопасности и их причин) и приложение С (Пример подходов к категоризации и классификации событий в области информационной безопасности и инцидентов) – содержание пунктов может помочь в обучении при рассмотрении инцидентов в области информационной безопасности.

А.12.2.3 Сбор доказательств Средство управления: если инцидента в области информационной безопасности может привести к судебному разбирательству (гражданскому или уголовному) против лица или организации, доказательства должны быть собраны, сохранены и представлены согласно правилам оформления доказательств, определенным соответствующими юрисдикциями 38

7 (Оценка и принятие решений), 8 (Ответные меры) (в частности, см. 8.2.5 Экспертный анализ в области информационной безопасности) и приложение Е (Нормативно-правовые аспекты) – содержание пунктов может помочь в определении необходимых для сбора доказательств процедур

СТБ ISO/IEC 27035/ПР_1

Приложение B (справочное)

Примеры инцидентов в области информационной безопасности и их причин В.1 Атаки Существует несколько способов, с помощью которых аудитор может продемонстрировать свои знания и опыт, например, посредством использования общепризнанных квалификаций. Регистрация, например под IRCA (International Registerof Sertificated Auditors – Международная организация по сертификации аудиторов систем управления) или любой другой признанной формой регистрации аудитора, также может использоваться для демонстрации требуемых знаний и опыта. Требуемый уровень компетентности для аудиторской группы должен быть установлен в соответствии с промышленной/технологической областью организации и фактором сложности. В.1.1 Отказ в обслуживании Отказ в обслуживании (DoS) и Распределенный отказ в обслуживании (DDoS) – широкие категории инцидентов, имеющие общую направленность. Такого рода инциденты являются причиной того, что система, сервис или сеть не будут продолжать работать с учетом своих предполагаемых возможностей, чаще всего с полным отказом в доступе для легальных пользователей. Существует два основных типа инцидентов DoS/DDoS, вызванных техническими средствами: ликвидация источника или его голодание. Некоторые типичные примеры намеренных технических инцидентов DoS/DDoS включают:  проверку с помощью ping-запросов сетевой передачи с целью заполнить сетевой диапазон ответным трафиком;  отправку данных в неизвестном формате в систему, сервис или сеть, предпринимая, таким образом, попытку разрушить ее или прервать ее нормальное функционирование;  открытие сети санкционированных сессий с конкретной системой, сервисом или сетью, предпринимая, таким образом, попытку исчерпать ее ресурсы (т.е., замедление, закрытие или отказ от их использования). Такие атаки часто осуществляются через бот-сеть, через программных роботов (вредоносные коды), которые управляются автономно и автоматически. Бот-сети могут иметь отношение к сотням, к миллионам пораженных компьютеров. Некоторые технические инциденты DoS могут быть вызваны случайно, например неверной конфигурацией оператора или несовместимостью прикладного программного обеспечения, но в большинстве случаев они являются намеренными. Некоторые технические инциденты DoC запускаются преднамеренно с целью разрушения системы или сервиса, закрытия сети, в то время как другие являются просто побочными продуктами другой злонамеренной деятельности. Например, некоторые из более общих методов идентификации и сканирования могут вызвать разрушение старых или с неверной конфигурацией систем или сервисов во время сканирования. Следует отметить, что многие технические инциденты DoS часто запускаются анонимно (т.е. источник атаки фальсифицирован). Инциденты DoS, вызванные не техническими средствами, заканчивающиеся потерей информации, сервиса и/или средств, могут быть вызваны, например:  нарушениями мер физической безопасности, заканчивающимися кражей, преднамеренным повреждением или выведением из строя оборудования;  случайным повреждением аппаратных средств (и/или места их расположения) в результате пожара или наводнения;  чрезвычайными условиями окружающей среды, например, высокие рабочие температуры (т.е., из-за сбоя в работе кондиционера воздуха);  системными сбоями или перезагрузкой;  неконтролируемыми изменениями системы;  сбоями программного обеспечения или аппаратных средств. В.1.2 Несанкционированный доступ Эта категория инцидентов состоит из реальных попыток несанкционированного доступа и использования системы, сервиса или сети. Некоторые примеры инцидентов технически стимулированного несанкционированного доступа включают в себя:  попытки восстановить файлы паролей;  атаки переполнения буфера обмена, чтобы получить привилегированный (например, системный администратор) доступ к объекту;  попытки повысить уровень привилегий на ресурсы или информацию сверх того, чем пользователь или администратор уже на законных основаниях владеет. 39

СТБ ISO/IEC 27035/ПР_1 Инциденты несанкционированного доступа, вызванные нетехническими средствами в результате прямого или косвенного разглашения или модификации информации, нарушений подотчетности или неправильного использования информационных систем, могут быть вызваны, например:  нарушениями механизмов физической безопасности в результате несанкционированного доступа к информации;  плохой и/или неправильной настройкой операционных систем из-за неконтролируемых изменений системы или сбоев программного или аппаратного обеспечения. В.1.3 Вредоносные коды Вредоносный код идентифицирует программу или часть программы, вставленную в другую программу с целью изменения ее первоначальной модели поведения, как правило, для выполнения потенциально опасных видов деятельности, как кража информации и личных данных, уничтожение информации и ресурсов, отказ в обслуживании, спам и др. Атаки вредоносного кода могут быть разделены на пять категорий: вирусы, черви, "троян", мобильный код и смешанные программы. Хотя несколько лет назад вирусы писались для создания уязвимой зараженной среды, сегодня вредоносные коды используются для выполнения целевых атак. Это осуществляется изменением существующего вредоносного кода, созданием прототипа, который часто не распознается технологиями обнаружения вредоносного кода. В.1.4 Несоответствующее использование Такого рода инцидент происходит, когда пользователь нарушает политики безопасности информационной системы организации. Подобные инциденты не являются атаками в строгом смысле слова, но зачастую оповещаются как инциденты и должны находиться под руководством ISIRT. Несоответствующим использованием может быть:  загрузка и установка программы для взлома;  использование корпоративного e-mail для спама или продвижение личного бизнеса;  использование корпоративных ресурсов для настройки несанкционированного веб-сайта;  использование распределенной сети для приобретения или распространения пиратских файлов (музыка, видео, программное обеспечение).

В.2 Сбор информации Категория сбора информации инцидентов включает в себя виды деятельности, связанные с выявлением потенциальных целей и пониманием принципа работы сервисных служб, направленных на достижение этих целей. Этот тип инцидента предполагает ознакомление с информацией, с целью выявления:  наличия цели и понимания топологии сети, окружающей его, и с кем объект регулярно взаимодействует;  потенциальных уязвимостей объекта или его непосредственной сетевой среды, которая может быть использована. Типичные примеры атак сбора информации с помощью технических средств, включают в себя:  демпинг отчетов DNS для целевого интернет-домена (передача зон DNS);  проверку сетевых адресов, чтобы найти системы, которые являются действующими;  проверку системы для определения (например, отпечатки пальцев) хостинговой операционной системы;  сканирование доступных сетевых портов системы для выявления соответствующих сервисов (например, e-mail, FTP, web и др.) и версии программного обеспечения этих сервисов;  сканирование одного или нескольких известных уязвимых сервисов в диапазоне адресов сети (горизонтальное сканирование). В некоторых случаях сбор технической информации распространяется на получение несанкционированного доступа в случае, например, когда злоумышленник, как часть поиска уязвимостей, также предпринимает попытки получения несанкционированного доступа. Обычно это происходит с помощью автоматизированных средств взлома, которые занимаются не только поиском уязвимостей, но и автоматически предпринимают попытки эксплуатации обнаруженных уязвимых систем, сервисов и/или сетей. Сбор информации инцидентов, вызванных нетехнических средств, приводит к:  прямому или косвенному разглашению или модификации информации;  краже интеллектуальной собственности, которая хранится в электронном виде;  нарушениям подотчетности, например, в учетной записи журнала;  неправильной эксплуатации информационных систем (например, противоречие закону или политике организации); может быть вызвано, например: 40

СТБ ISO/IEC 27035/ПР_1  нарушениями механизмов физической безопасности в результате несанкционированного доступа к информации, а также кражи оборудования для хранения данных, которое содержит важные данные, например, ключи шифрования;  плохой и/или неправильной настройкой операционных систем из-за неконтролируемых изменений системы или сбоев программного или аппаратного обеспечения, в результате получения доступа к информации специалистами внутри или за пределами организации, на что у них нет полномочий.

41

СТБ ISO/IEC 27035/ПР_1

Приложение C (справочное)

Пример подходов к категоризации и классификации событий и инцидентов в области информационной безопасности С.1 Введение В приложении представлены примерные подходы к категоризации и классификации инцидентов в области информационной безопасности. Данные подходы позволяют персоналу и организациям последовательно документировать инциденты в области информационной безопасности таким образом, что способствует следующим преимуществам:  обеспечению обмена информацией относительно инцидентов в области информационной безопасности;  облегчению процесса автоматизации составления отчетности об инцидентах в области информационной безопасности и принятию ответных мер;  повышению эффективности обработки инцидентов в области информационной безопасности и менеджмента;  облегчению сбора и анализа данных относительно инцидентов в области информационной безопасности;  идентификации уровней серьезности инцидентов в области информационной безопасности с помощью последовательных критериев. Данные примерные подходы к категоризации и классификации могут также применяться и к событиям в области информационной безопасности, но они не охватывают уязвимости в области информационной безопасности.

С.2 Категоризация инцидентов в области информационной безопасности Инциденты в области информационной безопасности могут быть вызваны намеренными или случайными действиями человека, и могут быть вызваны техническими или физическими средствами. Данный подход ранжирует инциденты в области информационной безопасности рассматривая угрозы как фактор категоризации. (Для угроз, ISO/IEC 27005:2008, приложение С. Пример типичных угроз, на которые ссылаются). Список категорий инцидентов в области информационной безопасности представлен в таблице С.1. Таблица С.1 – Категории инцидентов в области информационной безопасности согласно угрозам Категория инцидента Стихийное бедствие Общественные беспорядки Материальный ущерб

Нарушение функционирования инфраструктуры

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

42

Описание

Пример

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

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

Потеря информационной безопасности вызвана сбоями в работе базовых систем и сервисов, которые поддерживают функционирование информационных систем Потеря информационной безопасности вызвана волнением из-за радиации

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

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

СТБ ISO/IEC 27035/ПР_1 Категория инцидента Технические неполадки

Вредоносные программы

Описание

Пример

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

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

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

43

СТБ ISO/IEC 27035/ПР_1 Категория инцидента Технические атаки

Описание

Пример

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

Сканирование сети, эксплуатация уязвимости, эксплуатация "backdoor", попытки входа в систему, попытки несанкционированного доступа, DoS, пр. Сетевое сканирование использует сетевое программное обеспечение для сканирования, чтобы получить информацию о конфигурациях сети, портах, сервисах и существующих уязвимостях. Эксплуатация уязвимостей использует информационные системы, дефекты, такие как конфигурации, протоколы или программы. Эксплуатация "backdoor" использует "черные ходы" или вредоносные программы в процессах проектирования системы программного и аппаратного обеспечения. Попытки входа в систему путем угадывания, взлома или грубым выпытыванием паролей. Попытки несанкционированного доступа затрудняют работу компьютерных сетей, телеграфированных или беспроводных радио- или телевизионных сетей связи, спутниковых радио- и телесигналов, с помощью технических средств. DoS вызван чрезмерным использованием информационной системы или источников сети, как CPU, память, пространство диска или пропускная способности сети, и таким образом воздействует на функционирование информационных систем, например, SYS-a, PING-заполнение, бомбардировка электронной почты Несанкционированное использование ресурсов, нарушение авторского права, пр. Несанкционированное использование ресурсов получает доступ к ресурсам в несанкционированных целях, включая рентабельные предприятия, например использование электронной почты для отправления незаконных писем счастья с целью получения прибыли или построения финансовых пирамид. Нарушение авторского права является результатом продажи или установки копий нелицензионного коммерческого ПО или других, защищенных авторским правом продуктов Злоупотребление правами, подделывание прав, опровержение действий, неправильное выполнение операций, нарушение доступности персонала, пр. Злоупотребление правами предполагает использование прав вне сферы действий. Подделывание прав предполагает создание ложных прав с целью обмануть. Опровержение действий – когда кто-нибудь отрицает то, что он/она сделал (а). Неправильное выполнение операций предполагает неправильное или неумышленное проведение операций. Нарушение доступности персонала является результатом нехватки или отсутствия человеческих ресурсов

Нарушение правила

Потеря информационной безопасности вызвана намеренным или случайным нарушением правил

Компрометация функций

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

44

СТБ ISO/IEC 27035/ПР_1 Категория инцидента Несанкционирова нный доступ к информации

Вредоносный контент

Другие инциденты

Описание

Пример

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

Перехват информации, слежка, подслушивание, разглашение, маскировка, социальная инженерия, "фишинг" сети, хищение данных, утрата данных, их фальсификация, ошибка данных, анализ потока данных, определение местонахождения др. В ходе перехват захватываются данные, прежде чем они смогут попасть к получателям. Слежка предназначена для тайного сбора и сообщения информации о деятельности другой организации. Подслушивание – значит, слушать беседу сторонних организаций без их ведома. Разглашение информации предназначено для того, чтобы сделать конфиденциальную информацию общеизвестной. Маскировка – это, когда одна организация претендует на другую. Социальная инженерия – это сбор информации от человека нетехническим способом, например, с помощью лжи, хитрости, подкупа или угроз. "Фишинг" сети – это использование фальсифицированных компьютерных сетевых технологий, чтобы побудить пользователей разглашать важную информацию, как получение реквизитов банковского счета пользователей и паролей обманным путем через e-mail. Хищение данных предназначена для кражи данных. Фальсификация данных – это возможность доступа и внесения изменений в данные без авторизации. Ошибка данных допускает ошибки при вводе или обработке данных. Определение местонахождения – обнаружение положения конфиденциальной информации или систем Незаконный контент, вызывающий панику контент, вредоносный контент, оскорбительное содержимое и т.д. Незаконный контент – это опубликованный контент, который нарушает международные или национальные Конституции, законы и правила, например, детская порнография, прославление насилия, подделка, обман. Контент, вызывающий панику – злонамеренное сенсационное обсуждение или комментарии на щекотливые вопросы в интернете, приводящие к таким событиям, как социальное беспокойство или паника. Вредоносный контент предполагает распространение контента, который умышленно атакует общество или лица, например, обман, домогательство. Оскорбительное содержимое предполагает вещание контента, который не был предоставлен получателями, например, спам

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

Не входящие в любую из выше представленных категорий инцидентов

45

СТБ ISO/IEC 27035/ПР_1 С.3 Классификация инцидентов в области информационной безопасности Два примерных подхода к классификации инцидентов в области информационной безопасности представлены в следующем. Подчеркнуто, что примеры следующие. Есть другие, такие как FIRST/Объединенная общая система оценки уязвимостей (CVSS) и Структурированный формат предупреждающей информации (SWIF). С.3.1 Примерный подход 1 С.3.1.1 Классификационные факторы С.3.1.1.1 Введение Согласно данному подходу инциденты в классифицируются на основе следующих трех факторов:  значимость информационной системы;  снижение деловой активности;  социальное воздействие.

области

информационной

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

С.3.1.1.2 Значимость информационной системы На значимость информационной системы, на которую воздействуют инциденты в области информационной безопасности, определяется путем рассмотрения значимости бизнес-операций организации при поддержке информационных систем. Значимость может выражаться в отношении к национальной безопасности, социальному порядку, экономическому развитию и общественному интересу и зависимости бизнеса от информационных систем. Согласно данному подходу значимость информационной системы подразделяется на три широких уровня: особенно важная информационная система, важная информационная система и обычная информационная система. С.3.1.1.3 Снижение деловой активности Снижение деловой активности организации, вызванное инцидентами в области информационной безопасности, определяется путем рассмотрения серьезности воздействия прерывания деловой деятельности из-за повреждения программного обеспечения или аппаратных средств, функций или данных информационных систем. Серьезность воздействия может зависеть от расходов на восстановление деловой активности и возвращение к ее нормальному функционированию и других неблагоприятных воздействий инцидентов в области информационной безопасности, включая потерю прибыли и/или возможности. Согласно данному подходу снижение деловой активности подразделяется на четыре широких уровня: особенно серьезное снижение деловой активности, серьезное снижение деловой активности, значительное снижение деловой активности и незначительное снижение деловой активности, как описано ниже: a) особенно серьезное снижение деловой активности означало бы крупный бизнес-паралич степени потери деловой способности, и/или очень серьезный ущерб конфиденциальности, целостности и доступности ключевых бизнес-данных. Это будет означать огромные расходы на возвращение бизнеса в нормальный режим работы и устранения негативных последствий. Организация не сможет выдержать этот уровень коммерческих потерь; b) серьезное снижение деловой деятельности будет означать прекращения деловых операций в течение долгого времени или паралич местного бизнеса до степени, которая серьезно влияет на бизнесвозможности, и/или серьезное повреждение конфиденциальности, целостности и доступности ключевых бизнес-данных. Это будет означать высокую стоимость возвращения бизнеса в нормальный режим работы и устранения негативных последствий. Организация сможет выдержать этот уровень коммерческих потерь; c) значительное снижение деловой деятельности будет означать прекращения деловых операций до степени, существенно влияющей на бизнес-возможности, и/или значительный ущерб конфиденциальности, целостности и доступности важных бизнес-данных. Это будет означать значительные затраты на возвращение бизнес в нормальный режим работы и устранения негативных последствий. Организация сможет полностью выдержать этот уровень коммерческих потерь; d) незначительное снижение деловой активности будет означать прерывание бизнес-операций на короткое время до степени некоторого воздействия на бизнес-возможности, и/или незначительные воздействия на конфиденциальность, целостность и доступность важных бизнес-данных. Это будет означать незначительные затраты на возвращение бизнеса в нормальный режим работы и устранения негативных последствий. С.3.1.1.4 Социальное воздействие Социальное воздействие, вызванное инцидентами информационной безопасности, определяется с учетом масштабов и степени воздействия на обеспечение национальной безопасности, общественного 46

СТБ ISO/IEC 27035/ПР_1 порядка, экономического развития и общественного интереса. Согласно этому подходу социальное воздействие подразделяется на четыре уровня: особенно важное социальное воздействие, важное социальное воздействие, значительное социальное воздействие и незначительное социальное воздействие, как описано ниже. I) особенно важное социальное воздействие будет означать пагубное воздействие, распространяющееся на большинство районов одной или нескольких провинций/государств, в значительной мере угрожающее национальной безопасности, вызывающее социальную турбулентность, принося крайне неблагоприятные последствия для экономического развития и/или серьезный ущерб общественным интересам; II) важное социальное воздействие будет означать пагубное воздействие, распространяющееся на большинство районов одного или нескольких городов, угрожающее национальной безопасности, вызывающее панику в обществе, принося значительные неблагоприятные последствия для экономического развития, и/или подрывающее общественный интерес; III) значительное социальное воздействие будет означать пагубное воздействие, распространяющееся на большинство районов одного или нескольких городов, с ограниченной угрозой национальной безопасности, с некоторыми нарушениями общественного порядка, принося некоторые неблагоприятные последствия для экономического развития, и/или влияющее на общественный интерес; IV) незначительное социальное воздействие будет означать пагубное воздействие, распространяющееся на частичный район одного города и маловероятную угрозу национальной безопасности, общественному порядку, экономическому развитию и общественному интересу, но с нанесением ущерба интересам отдельных лиц, корпораций и других организаций. С.3.1.2 Классы С.3.1.2.1 Введение На основе классификационных факторов инциденты в области информационной безопасности должны быть классифицированы по серьезности, используя шкалу. Такая шкала может быть простой, как деление на "значительный" или "незначительный" инцидент, или более подробной, как:  чрезвычайное происшествие: серьезное воздействие;  критический: среднее воздействие;  предупреждающий: низкий уровень воздействия;  информационный: не влияет, но анализ может быть использован для совершенствования политик в области информационной безопасности, процедур или средств управления. Согласно приведенным выше классификационным факторам в рамках данного подхода инциденты в области информационной безопасности подразделяются на четыре класса:  очень серьезные (IV класс);  серьезные (III класс);  не очень серьезные (менее серьезные) (II класс);  небольшие (I класс). Следует подчеркнуть, что серьезность классов является примером. В некоторых подходах наиболее серьезный класс представлен как наивысший уровень шкалы. В других подходах наиболее серьезный класс представлен как самый низкий уровень шкалы. С.3.1.2.2 Очень серьезные (IV класс) Очень серьезные инциденты – это те, которые: a) воздействуют на особенно важные информационные системы; b) приводят к особенно серьезным потерям бизнеса; c) приводят к особенно важному социальному воздействию. С.3.1.2.3 Серьезные (III класс) Серьезные инциденты – это те, которые: a) воздействуют на особенно важные или важные информационные системы; b) приводят к серьезным потерям бизнеса; c) приводят к важному социальному воздействию. С.3.1.2.4 Менее серьезные (II класс) Менее серьезные инциденты – это те, которые: a) воздействуют на важные или ординарные информационные системы; b) приводят к значительным потерям бизнеса; c) приводят к значительному социальному воздействию. С.3.1.2.5 Небольшие (I класс) Небольшие инциденты – это те, которые: 47

СТБ ISO/IEC 27035/ПР_1 a) b) c) d)

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

С.3.1.3 Категория инцидента и класс серьезности Категория инцидента в области информационной безопасности и класс степени серьезности часто связаны между собой. Одна и та же категория инцидента в области информационной безопасности может иметь различные степени серьезности класса в зависимости не только от бизнеса, но и от характера инцидента в области информационной безопасности, такого как:  умышленный инцидент;  целевой;  временной;  масштабный. Некоторые примеры категорий инцидентов в области информационной безопасности, которые могут иметь различные степени серьезности классов, в зависимости от их характера, представлены в таблице С.2. Таблица С.2 – Примеры категорий инцидентов и класса серьезности Класс серьезности Категория инцидента

Небольшие Неудачные попытки

Менее серьезные Один обычный (компромисс пользователя)

Технические атаки

Раздражение (поверхностное повреждение)

Технические атаки

Вредоносные программы

Единственно известный (обнаружен и блокирован антивирусной системой)

Один неизвестный

Серьезные Несколько (компромисс пользователя). Один важный (приложение, корневой компромисс) Массовые беспорядки (пропускная способность воздействия) Несколько инфекций. Заражение сервера

Очень серьезные Массовый (приложение, корневой компромисс)

Недоступность (остановка сервисов) Массовое заражение

С.3.2 Примерный подход 2 С.3.2.1 Введение В рамках данного подхода представлены примерные рекомендации по оценке и категорированию негативных последствий инцидентов в области информационной безопасности, где каждая рекомендация имеет шкалу от 1 (низкий) до 10 (высокий). (На практике могут использоваться другие шкалы, например, с градацией от 1 до 5, и каждая организация должна использовать шкалу, наиболее подходящую для ее окружающей среды). Перед изучением рекомендаций необходимо рассмотреть следующие пояснения:  в некоторых из рекомендаций, представленных ниже, содержится примечание "Нет записи". Это происходит из-за того, что рекомендации сформулированы так, что негативные последствия, приведенных для каждой градации инцидента в области информационной безопасности (от 1 до 10) в целом аналогичны для всех шести типов, представленных в приложении С.3.2.2 через приложение С.3.2.7. Однако на некоторых градациях (по шкале от 1 до 10) для конкретных инцидентов в области информационной безопасности считается, что из-за отсутствия больших различий в записях о последствиях инцидента в области информационной безопасности на более низких градациях делать запись нецелесообразно и в этом случае делается примечание "Нет записи". Аналогично, при более высоких градациях инцидента в области информационной безопасности считается, что негативные последствия для них не могут быть серьезнее негативных последствий, показанных для самой высокой

48

СТБ ISO/IEC 27035/ПР_1 градации, и, следовательно, для этих градаций действует примечание "Нет записи". (Таким образом, было бы неправильно исключить указания с пометкой "Нет записи" и сужать градацию шкалы). Таким образом, при использовании перечисляемых рекомендаций для расследования негативных последствий инцидента в области информационной безопасности для бизнеса организации, являются следствием  несанкционированного разглашения информации;  несанкционированной модификации информации;  отказа от информации;  недоступности информации и/или сервиса;  уничтожения информации и/или сервиса. В первую очередь необходимо определить, какая из следующих категорий является соответствующей. Необходимо применять рекомендации по категорированию для определения реального негативного воздействия на бизнес-процессы (или значимость) с целью занесения в форму отчета об инциденте в области информационной безопасности. С.3.2.2 Финансовые убытки/нарушение хода бизнес-операций Последствия несанкционированного разглашения, модификации и искажения смысла переданной информации, а также недоступности и уничтожения такой информации могут привести к финансовым убыткам, например, в результате снижения цен на акции, мошенничества или разрыва контракта по причине бездействия или запоздалых действии в отношении этих последствий. Последствиями недоступности или уничтожения любой информации может быть также нарушение бизнес-процесса. На исправление ситуации и/или восстановление бизнес-процесса после таких инцидентов в области информационной безопасности потребуются время и усилия. Эти последствия в некоторых случаях могут быть значительными и должны обязательно приниматься во внимание. Для расчетов последствий необходимо, чтобы время восстановления вычислялось в единицах рабочего времени персонала и пересчитывалось в финансовые затраты. Эти затраты должны быть вычислены, исходя из средней стоимости 1 чел./мес. по соответствующей градации/уровню, принятой/принятому внутри организации. Предлагается руководствоваться следующими рекомендациями: 1) результат в финансовых убытках/затратах x1 или менее, 2) результат в финансовых убытках/затратах между x1+1 и x2; 3) результат в финансовых убытках/затратах между x2+1 и x3; 4) результат в финансовых убытках/затратах между x3+1 и x4; 5) результат в финансовых убытках/затратах между x4+1 и x5; 6) результат в финансовых убытках/затратах между x5+1 и x6; 7) результат в финансовых убытках/затратах между x6+1 и x7; 8) результат в финансовых убытках/затратах между x7+1 и x8; 9) результат в финансовых убытках/затратах более x8; 10) организация выходит из бизнеса, где xi (i = 1, 2, ..., 8) представляет собой финансовые убытки/расходы в восемь градаций/уровней, которые определяются организацией в ее контексте. С.3.2.3 Коммерческие и экономические интересы Коммерческая и экономическая информация нуждается в защите и оценивается с учетом ее значимости для конкурентов или по воздействию, которое оказывает ее компрометация на коммерческие интересы. Следует руководствоваться следующими рекомендациями по обеспечению защиты информации, представляющей интерес: 1) для конкурента, но не имеет коммерческой ценности; 2) для конкурента при значении параметра ценности информации, равном y1 или менее (товарооборот); 3) для конкурента при значении параметра ценности информации, находящегося в диапазоне y1+1 и y2 (товарооборот) или является причиной финансовых убытков, или потери заработка, или облегчает получение незаконной прибыли, или вызывает нарушение обязательств для поддержания достоверности информации, предоставленной третьими сторонами; 4) для конкурента при значении параметра ценности информации, находящегося в диапазоне y2+1 и y3 (товарооборот); 5) для конкурента при значении параметра ценности информации, находящегося в диапазоне y3+1 и y4 (товарооборот); 6) для конкурента при значении параметра ценности информации более y4+1 (товарооборот); 7) нет записи1); 1)

Термин "Нет записи" означает, что для этой градации последствий инцидента в области информационной безопасности соответствующая запись отсутствует. 49

СТБ ISO/IEC 27035/ПР_1 8) нет записи; 9) может существенно повлиять на коммерческие интересы или подорвать финансовое состояние организации; 10) нет записи, где yi (i = 1, 2, ..., 4) предоставляет значения конкуренту с точки зрения оборотов в четырех градациях/уровнях, которые определяются организацией в ее контексте. С.3.2.4 Персональные данные В местах хранения и обработки информации, содержащей персональные данные физических лиц, считают моральной и этически корректной, а при некоторых обстоятельствах юридически необходимой защиту этой информации от несанкционированного разглашения, которое может привести в лучшем случае к созданию дискомфорта у юридического лица, а в худшем – к судебному преследованию лица, раскрывшего информацию, в соответствии с требованием законодательства в части защиты персональных данных. В равной степени необходимо, чтобы информация, содержащая персональные данные, была всегда правильной, поскольку ее несанкционированная модификация, приводящая к появлению некорректных данных, может иметь такое же последствие, что и ее несанкционированное разглашение. Важно, чтобы информацию, содержащую персональные данные, нельзя было сделать доступной или уничтожить, поскольку это может привести к принятию неправильных решений юридическими лицами или их бездействию во время инцидента в области информационной безопасности, что может иметь такое же воздействие, что и несанкционированное разглашение или модификация информации. Следует руководствоваться следующими рекомендациями по градации нанесения ущерба информации, содержащей персональные данные: 1) нанесение незначительного ущерба (беспокойства) конкретному лицу (гнев, расстройство, разочарование), но не нарушение правовых или нормативных требований; 2) нанесение ущерба (беспокойства) конкретному лицу (гнев, расстройство, разочарование), но не нарушение правовых или нормативных требований; 3) нарушение правовых, нормативных или этических требований, а также опубликование намерения относительно нарушения защиты информации, приводящее к незначительному дискомфорту конкретного лица или группы лиц; 4) нарушение правовых, нормативных или этических требований, а также опубликование намерений относительно нарушения защиты информации, приводящее к чувству значительного дискомфорта для конкретного лица или к незначительному дискомфорту группы лиц; 5) нарушение правовых, нормативных или этических требований, а также опубликованных намерений относительно защиты информации, приводящее к серьезным проблемам конкретного лица; 6) нарушение правовых, нормативных или этических требований, а также опубликование намерений относительно нарушения защиты информации, приводящее к серьезному дискомфорту для группы лиц; 7) нет записи; 8) нет записи; 9) нет записи; 10) нет записи. С.3.2.5 Правовые и нормативные обязательства Данные, хранимые и обрабатываемые организацией, могут подчиняться правовым и нормативным обязательствам или храниться и обрабатываться с целью обеспечения соответствия организации данным обязательствам. Несоблюдение таких обязательств, намеренное или ненамеренное, может привести к принятию правовых или административных мер к лицам, работающим в данной организации. Результатом принятия данных мер могут быть штрафы и/или тюремное заключение. Предлагается руководствоваться следующими рекомендациями: 1) нет записи; 2) нет записи; 3) предупреждение о правонарушении, гражданский иск или уголовное преступление, приводящее к финансовым убыткам/штрафу z1 или меньше; 4) предупреждение о правонарушении, гражданский иск или уголовное преступление, приводящее к финансовому ущербу/штрафу между z1+1 и z2; 5) предупреждение о правонарушении, гражданский иск или уголовное преступление, приводящее к финансовым убыткам/штрафу между z2+1 и z3 или тюремному заключению сроком до двух лет; 6) предупреждение о правонарушении, гражданский иск или уголовное преступление, приводящее к финансовым убыткам/штрафу между z3+1 и z4 или тюремному заключению сроком от двух до 10 лет; 7) предупреждение о правонарушении, гражданский иск или уголовное преступление, приводящее к финансовым убыткам/штрафу или тюремному заключению сроком более 10 лет;

50

СТБ ISO/IEC 27035/ПР_1 8) нет записи; 9) нет записи; 10) нет записи. С.3.2.6 Менеджмент и бизнес-операции Информация может быть такой, что ее компрометация способна нанести ущерб эффективности работы организации. Например, будучи раскрытой, относящаяся к внесению изменений в политике информация может спровоцировать такую общественную реакцию, что реализация данной политики станет невозможной. Модификация, изменение смысла переданной информации или недоступность информации, касающейся финансовых аспектов или компьютерного программного обеспечения, могут также иметь серьезные последствия для работы организации. Кроме того, отказ от обязательств по обеспечению в области информационной безопасности может иметь негативные последствия для бизнеса. Предлагается руководствоваться следующими рекомендациями по оценке последствий: 1) неэффективная работа одного подразделения организации; 2) нет записи; 3) нарушение деятельности по эффективному руководству организацией и ее работы; 4) нет записи; 5) создание препятствий для эффективной разработки или функционирования политик организации; 6) причинение ущерба организации при коммерческих или политических переговорах с другими организациями; 7) создание препятствий для разработки или функционирования главных политик организации, отключение или значительное прерывание важных операций каким-либо другим способом; 8) нет записи; 9) нет записи; 10) нет записи. С.3.2.7 Утрата престижа Несанкционированное разглашение информации, отказ от обязательств по обеспечению информационной безопасности или модификация информации, а также недоступность информации могут привести к потере престижа организации с последующим возможным нанесением ущерба ее репутации, к потере доверия и другим негативным последствиям. Предлагается руководствоваться следующими рекомендациями по оценке престижа организации: 1) нет записи; 2) создание атмосферы недовольства внутри организации; 3) негативное влияние на отношения с акционерами, потребителями, поставщиками, регулирующими органами, правительством, с другими организациями или общественностью, приводящее к нежелательным последствиям местного/регионального масштаба; 4) нет записи; 5) негативное влияние на отношения с акционерами, потребителями, поставщиками, регулирующими органами, правительством, с другими организациями или общественностью, приводящее к нежелательным последствиям национального масштаба; 6) нет записи; 7) значительное негативное влияние на отношения с акционерами, потребителями, поставщиками, регулирующими органами, правительством, с другими организациями или общественностью, приводящее к нежелательным последствиям; 8) нет записи; 9) нет записи; 10) нет записи.

51

СТБ ISO/IEC 27035/ПР_1

Приложение D (справочное)

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

D.2 Примерные пункты в регистрационных формах D.2.1 Примерные пункты регистрационной формы события в области информационной безопасности Включает в себя основную информацию о событии в области информационной безопасности, когда, какое, как и почему событие наступило, так же, как контактные данные о сообщающем лице. Основная информация. Дата события. Номер события. Соответствующие идентификационные номера события и/или инцидента (если требуется). Сведения о сообщающем лице. Имя. Контактная информация, в том числе адрес, организация, подразделение, телефон и e-mail. Описание события в области информационной безопасности. Что произошло. Как произошло. Почему произошло. Первоначальные мнения о пораженных компонентах/активах. Негативное воздействие на бизнес. Любые идентифицированные уязвимости. Сведения о событии. Дата и время наступления события. Дата и время обнаружения события. Дата и время сообщения о событии. D.2.2 Примерные пункты регистрационной формы инцидента в области информационной безопасности Включает в себя основную информацию об инциденте в области информационной безопасности, когда, какой, как и почему инцидент произошел, так же, как категорию инцидента, воздействие и результат реагирования на инцидент. Основная информация. Дата инцидента. Номер инцидента. Соответствующие идентификационные номера события и/или инцидента (если требуется). Сведения о сообщающем лице. Имя. Контактная информация, в том числе адрес, организация, подразделение, телефон и e-mail. Сведения о сотруднике PoC. Имя. Контактная информация, в том числе адрес, организация, подразделение, телефон и e-mail. Сведения о сотруднике ISIRT. Имя. Контактная информация, в том числе адрес, организация, подразделение, телефон и e-mail. Описание инцидента. Что произошло. Как произошло. Почему произошло. Первоначальное мнение о пораженных компонентах/активах. 52

СТБ ISO/IEC 27035/ПР_1 Негативное воздействие на бизнес. Любые идентифицированные уязвимости. Сведения об инциденте. Дата и время возникновения инцидента. Дата и время обнаружения инцидента. Дата и время сообщения об инциденте. Категория инцидента. Пораженные компоненты/активы. Негативное воздействие на бизнес/последствия инцидента. Общие расходы на восстановление после инцидента. Разрешение инцидента. Участвующее лицо (а)/исполнитель (и) (если инцидент вызван человеком). Описание исполнителя. Фактическая или предполагаемая мотивация. Принятые для разрешения инцидента действия. Запланированные для разрешения инцидента действия. Прочие действия. Заключение. Физические/юридические лица внутри организации, получившие уведомление Сторонние физические/юридические лица, получившие уведомление D.2.3 Примерные пункты регистрационной формы уязвимости в области информационной безопасности Включает в себя основную информацию об уязвимости в области информационной безопасности, когда, какая и как уязвимость была выявлена, так же, как потенциальное воздействие и разрешение. Основная информация. Дата выявления уязвимости. Номер инцидента. Соответствующие идентификационные номера события и/или инцидента (если требуется). Сведения о сообщающем лице. Имя. Контактная информация, в том числе адрес, организация, подразделение, телефон и e-mail. Описание уязвимости. Разрешение уязвимости.

D.3 Как использовать формы D.3.1 Формат даты и времени Даты должны быть введены в формате CCYY-MM-DD (и, если требуется, HH-MM-SS).Если это уместно, UTC следует использовать готовым для сравнения, когда многие события могут происходить в разных часовых поясах (и, по крайней мере, установить смещение UTC, применимое ко времени). В.3.2 Рекомендации по заполнению Назначением формы отчета о событиях и инцидентах в области информационной безопасности является обеспечение информацией о событии в области информационной безопасности, а затем, если оно определено как инцидент в области информационной безопасности, то и об инциденте в области информационной безопасности, для определенных лиц. Если предполагается, что событие в области информационной безопасности развивается или уже свершилось, особенно событие, которое может привести к существенным потерям, ущербу собственности или репутации организации, то необходимо немедленно заполнить и передать форму отчета (см. первую часть настоящего приложения) о событии в области информационной безопасности в соответствии с процедурами, описанными в системе менеджмента инцидентов в области информационной безопасности организации. Предоставленная информация будет использована для инициирования соответствующего процесса оценки, который определит, должно ли это событие категорироваться как инцидент в области информационной безопасности и (в случае положительного ответа), какие корректирующие меры, необходимые для предотвращения или ограничения потерь или ущерба, следует предпринять. Поскольку процесс оценки по своему характеру является краткосрочным, то в данный момент необязательно заполнять все поля формы отчета. Если сотрудник является членом PoC, анализирующим полностью/частично заполненные формы отчета, то он должен принять решение, надо ли отнести данное событие к категории инцидента в области информационной безопасности. При положительном решении сотрудник должен внести в форму отчета об инциденте в области информационной безопасности как можно больше информации и передать 53

СТБ ISO/IEC 27035/ПР_1 формы отчетов о событии и инциденте в области информационной безопасности в ISIRT. Независимо от того, будет ли событие в области информационной безопасности отнесено к категории инцидента в области информационной безопасности, база данных событий/инцидентов/уязвимостей в области информационной безопасности должна быть обновлена. Если сотрудник является сотрудником ISIRT, анализирующим формы отчетов о событиях и инцидентах в области информационной безопасности, переданные членом PoC, то форма отчета об инциденте в области информационной безопасности должна обновляться по ходу расследования и, соответственно, должна обновляться база данных событий/инцидентов/уязвимостей в области информационной безопасности. Целью отчета об уязвимостях в области информационной безопасности является предоставление информации о выявленных уязвимостях, и возможность выступать в качестве хранилища информации о уязвимостях, о которой сообщалось. При заполнении форм следует соблюдать следующие рекомендации:  по форме отчеты должны заполняться и передаваться в электронном виде1. (в случае существования проблемы или если считается, что существуют проблемы с принятыми по умолчанию механизмами электронного оповещения (например, электронная почта), включая случаи, когда система может подвергаться атаке и отчеты могут быть прочитаны неавторизованными пользователями, должны использоваться альтернативные средства связи. Альтернативными средствами связи могут быть телефон или текстовые сообщения, а также использование курьеров);  следует предоставить информацию, основанную на фактах, в которой сотрудник уверен – не следует что-либо придумывать для того, чтобы заполнить все формы. Если сотрудник считает уместным включить иную информацию, которую не может подтвердить, следует указать, что это неподтвержденная информация, и причину убежденности в ее достоверности;  следует предоставить полную контактную информацию. Немедленно или спустя некоторое время может возникнуть необходимость связаться с сотрудником для получения дальнейшей информации, касающейся его отчета. Если позднее сотрудник обнаружит, что какая-либо представленная им информация неточна, неполна или ошибочна, то следует внести поправки в отчет и представить его повторно.

1

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

54

СТБ ISO/IEC 27035/ПР_1 D.4 Образец формы отчета D.4.1 Пример формы отчета о событии в области информационной безопасности

ОТЧЕТ О СОБЫТИИ В ОБЛАСТИ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ 1. Дата события 2. Номер события1 3. Соответствующие идентификационные номера события и/или инцидента 4. Сведения о сообщающем лице 4.1 Имя__________________ 4.2 Адрес___________________ 4.3 Организация__________________ 4.4 Подразделение___________________ 4.5 Телефон__________________4.6 E-mail___________________ 5. Описание события в области информационной безопасности 5.1      

Описание события: Что произошло Как произошло Почему произошло Первичные данные о пораженных компонентах/активах Негативные последствия для бизнеса Любые выявленные уязвимости 6. Подробности события в области информационной безопасности

6.1

Дата и время наступления события

6.2

Дата и время обнаружения события

6.3

Дата и время сообщения о событии

6.4

Завершился процесс реагирования на данное событие?

да

нет

(отметить нужное)

6.5

Если "да", то уточнить длительность события в днях/часах/минутах

1

Номера событий назначаются руководителем ISIRT организации. 55

СТБ ISO/IEC 27035/ПР_1

D.4.2 Пример формы отчета об инциденте в области информационной безопасности

ОТЧЕТ ОБ ИНЦИДЕНТЕ В ОБЛАСТИ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ 1. Дата события 2. Номер события1 3. Соответствующие идентификационные номера события и/или инцидента 4. Сведения о сотруднике PoC 4.1 Имя __________________ 4.3 Организация __________________ 4.5 Телефон __________________

4.2 Адрес ___________________ 4.4 Подразделение ___________________ 4.6 E-mail ___________________

5. Сведения о сотруднике ISIRT 4.1 Имя __________________ 4.3 Организация __________________ 4.5 Телефон __________________

4.2 Адрес ___________________ 4.4 Подразделение ___________________ 4.6 E-mail ___________________

6. Описание инцидента в области информационной безопасности 6.1      

Дополнительное описание инцидента: Что произошло Как произошло Почему произошло Первичные данные о пораженных компонентах/активах Негативные последствия для бизнеса Любые выявленные уязвимости 7. Подробности события ИБ

7.1

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

7.2

Дата и время обнаружения инцидента

7.3

Дата и время сообщения об инциденте

7.4

Закончился ли инцидент?

да

нет

(отметить нужное)

7.5

1

Если "да", то уточнить длительность инцидента в днях/часах/минутах

Номера инцидентов назначаются руководителем ISIRT организации и привязываются к номеру(ам) соответствующих событий. 56

СТБ ISO/IEC 27035/ПР_1 ОТЧЕТ ОБ ИНЦИДЕНТЕ ИБ 8. Категория инцидента ИБ (Отметьте один, затем заполните соответствующий раздел ниже).

8.1 Фактический (возникновение инцидента)

(Один из) 8.3 Стихийное бедствие Землетрясение Извержение вулкана Молния Цунами

8.2 Предполагаемый (предположение возникновения инцидента без подтверждения)

(указать три типа задействованных) Наводнение Сильный ветер Обвал Другое

Определить: (Один из) Вторжение

8.4 Общественные беспорядки (указать три типа задействованных) Террористическая атака Война Другое

Определить: (Один из) 8.5 Материальный ущерб (указать три типа задействованных) Огонь Вода Электростатический разряд Окружающая среда (как загрязнение, пыль, коррозия, замерзание) Выведение из строя оборудования Уничтожение носителей Хищение оборудования Хищение носителей Утрата оборудования Утрата носителей Порча оборудования Порча носителей Другое Определить: (Один из) 8.6 Сбой в работе инфраструктуры (указать три типа задействованных) Сбой питания Отказ сети Сбой в работе кондиционера Нарушение водоснабжения Другое Определить: (Один из) 8.7 Радиационное волнение (указать три типа задействованных) Электромагнитное излучение Электромагнитный импульс Радиопомехи Колебания напряжения Тепловое излучение Другое Определить: (Один из) 8.8 Технические неполадки (указать три типа задействованных) Аппаратный сбой Сбой ПО Перегрузка (насыщения потенциала информационных систем) Нарушение ремонтопригодности Другое Определить:

57

СТБ ISO/IEC 27035/ПР_1 ОТЧЕТ ОБ ИНЦИДЕНТЕ ИБ 8. Категория инцидента ИБ (Один из) 8.9 Вредоносные программы (указать три типа задействованных) Сетевой червь Троян Бот-сеть Смешанные атаки Web-страница со встроенным вредоносным кодом Сайт, на котором размещен вредоносный код Другое Определить: (Один из) 8.10 Технические атаки (указать три типа задействованных) Сканирование сети Эксплуатация уязвимости Эксплуатация"backdoor" Попытки входа в систему Попытки несанкционированного доступа (DoS) Другое Определить: (Один из) 8.11 Нарушение правила Несанкционированное использование ресурсов Нарушение авторского права Другое

(указать три типа задействованных)

Определить: (Один из) 8.12 Компрометация функций (указать три типа задействованных) Злоупотребление правами Подделывание прав, опровержение действий Неправильное выполнение операций Нарушение доступности Определить: персонала Другое Определить: (Один из)

8.13 Несанкционированный доступ к информации (указать три типа задействованных) Перехват информации Слежка, подслушивание Разглашение Маскировка, социальная инженерия Фишинг сети Хищение данных Утрата данных Фальсификация данных Ошибка данных Анализ потока данных Определение местонахождения Другое Определить: (Один из) 8.14 Вредоносный контент (указать три типа задействованных) Незаконный контент Вызывающий панику контент Вредоносный контент Оскорбительное содержимое Другое Определить: 8.15 Другие Определить:

58

(если Вы еще не установили принадлежность инцидента к одной из категорий, отметьте здесь)

СТБ ISO/IEC 27035/ПР_1 ОТЧЕТ ОБ ИНЦИДЕНТЕ ИБ 9. Пораженные компоненты/активы1 Пораженные компоненты/активы (предоставить описание компонентов/активов, пораженных (если есть) инцидентами ИБ или связанных с ними, включая при необходимости серийные, лицензионные номера и номера версий) 9.1 9.2 9.3 9.4 9.5 9.6 9.7

Информация/данные_____________________________________________ Аппаратные средства____________________________________________ Программное обеспечение________________________________________ Средства связи__________________________________________________ Документация___________________________________________________ Процессы_______________________________________________________ Другое__________________________________________________________

10. Негативное воздействие/влияние инцидента на бизнес Сделать отметку в соответствующих квадратах для указанных ниже нарушений, затем в колонке "значимость" указать степень негативного воздействия на бизнес, охватывающего все стороны, затронутые инцидентом, по шкале от 1 до 10, используя следующие указатели категорий: финансовые убытки/прерывание бизнес-операций, коммерческие и экономические интересы, персональные данные, правовые и нормативные обязательства, менеджмент и бизнес-операции и утрата престижа организации. (см. приложение С.3.2 для примеров). Записывайте кодовые буквы в колонке "указатель" (и), а если известны фактические издержки, указать их в колонке "издержки". Значимость

Указатель(и)

Издержки

10.1 Нарушение конфиденциальности (т.е. несанкционированное разглашение) 10.2 Нарушение целостности (т.е. несанкционированная модификация) 10.3 Нарушение доступности (т.е. недоступность) 10.4 Нарушение безотказности 10.5 Уничтожение

11. Общие расходы на восстановление после и инцидента (Там, где возможно, необходимо указать общие расходы Значимость на восстановление после инцидента в целом по шкале от 1 до 10 для "значимости" и в деньгах для "расходов").

Указатель(и)

Издержки

1

Это для получения более подробной информации о пораженных компонентах/активах, доступной как расследования и анализ полученных средств. 59

СТБ ISO/IEC 27035/ПР_1 ОТЧЕТ ОБ ИНЦИДЕНТЕ ИБ 12.

Разрешение инцидента

12.1 Дата начала расследования инцидента _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ 12.2 Фамилия(и) лица(лиц), проводившего(их) расследование инцидента _ _ _ _ _ __ _ __ _ _ _ __ 12.3 Дата завершения инцидента __ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ 12.4 Дата окончания воздействия _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 12.5 Дата завершения расследования инцидента _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 12.6 Ссылка и местонахождение отчета о расследовании _ _ _ _ _ _ _ _ _ _

13. (Один из)

(Если инцидент вызван людьми) Причастные к инциденту лица/исполнители Лицо Организованная группа

Законно созданная организация/учреждение Случайность Нет исполнителя

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

14. 15. (Один из)

Описание исполнителя

Фактическая или предполагаемая мотивация

Криминальная/финансовая выгода Политическая выгода/терроризм

Досуг/Хакерство Месть

Другое

Определить:

16.

Предпринятые действия для разрешения инцидента

(например, "никаких действий", "подручными средствами", "внутреннее расследование", "внешнее расследование с привлечением ...")

17.

Запланированные мероприятия для разрешения инцидента

(например, см. приведенные выше примеры)

18.

Прочие действия

(например, по-прежнему требуется проведение расследования, но другим персоналом)

60

СТБ ISO/IEC 27035/ПР_1 ОТЧЕТ ОБ ИНЦИДЕНТЕ ИБ 19.

Заключение

(отметьте один из пунктов, чтобы установить, является ли инцидент значительным или нет; приложить краткое обоснование этого заключения)

Значительный

Незначительный

(указать любые другие заключения) __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _

20.

Физические/юридические лица внутри организации, получившие уведомление

(Этот пункт заполняется соответствующим лицом, на которое возложены обязанности в сфере ИБ, устанавливающий требуемые действия. Как правило, этим лицом является руководитель ИБ подразделения организации или другое ответственное должностное лицо)

Руководитель службы ИБ/ответственное должностное лицо Менеджер сайта (установить, какой сайт)

Руководитель ISIRT

Автор отчета

Руководитель автора отчета Другие лица (например,

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

справочная служба, отдел кадров, руководство, служба внутреннего аудита)

Определить:

21.

Сторонние физические/юридические лица/организации, получившие уведомление

(Этот пункт заполняется соответствующим лицом, на которое возложены обязанности в сфере ИБ, устанавливающий требуемые действия. Как правило, этим лицом является руководитель ИБ подразделения организации или другое ответственное должностное лицо)

Полиция

Другие (например, регулятивный внешняяISIRT)

орган,

Определить:

22. АВТОР Подпись ФИО________________ Должность__________ Дата________________

Привлеченные лица

АНАЛИТИК АНАЛИТИК Подпись Подпись ФИО____________ ФИО_________ Должность______ Должность______ Дата____________ Дата____________

61

СТБ ISO/IEC 27035/ПР_1 D.4.3 Пример формы отчета об уязвимости ИБ

ОТЧЕТ ОБ УЯЗВИМОСТИ ИБ 1. Дата выявления уязвимости 2. Номер уязвимости1 3

Сведения о сообщающем лице

3.1 Имя________________ 3.3 Организация______________ 3.5 Телефон______________ 4

3.2 Адрес___________________ 3.4 Подразделение_______________ 3.6 E-mail___________________

Описание уязвимости ИБ

4.1 Дата и время сообщения об уязвимости 4.2 Описание в повествовательной форме выявленной уязвимости ИБ  Как уязвимость была обнаружена  Характеристики уязвимости – физическая, техническая, пр.  Если техническая, какие IT/сетевые компоненты/активы она затрагивает  Компоненты/активы, которые могут быть затронуты, если воспользоваться уязвимостью  Потенциальное неблагоприятное влияние на бизнес, если воспользоваться уязвимостью

5

Разрешение уязвимости ИБ

5.1 Была ли уязвимость подтверждена?

Да

Нет

(отметьте соответствующее)

5.2 Дата и время подтверждения уязвимости 5.3 Фамилия уполномоченного лица

5.4 Адрес

5.5 Организация 5.6 Телефон

5.7 E-mail

5.8 Каким образом уязвимость была разрешена?

Да

Нет

(отметьте соответствующее)

5.9 Описание в повествовательной форме того, как уязвимость ИБ была разрешена, учитывая дату и фамилию уполномоченного лица, отвечающего за авторизацию разрешения

1

Номер уязвимости назначается руководителем ISIRT организации.

62

СТБ ISO/IEC 27035/ПР_1

Приложение E (справочное)

Нормативно-правовые аспекты Следующие нормативно-правовые аспекты менеджмента инцидентов в области информационной безопасности должны быть рассмотрены в политике менеджмента инцидентов в области информационной безопасности и соответствующей системе: 1. Достаточный уровень защиты данных и конфиденциальности личной информации. В тех странах, где существует специальное законодательство, которое охватывает конфиденциальность и целостность данных, зачастую ограничивается контролем персональных данных. Так инциденты в области информационной безопасности, как правило, должны быть отнесены к отдельному лицу или организации, сведения личного характера, возможно, таким образом, должны регистрироваться и использоваться соответственно. В рамках структурированного подхода к менеджменту инцидентов в области информационной безопасности необходимо учитывать соответствующую защиту конфиденциальности данных. Это включает в себя следующее: - лица, имеющие доступ к персональным данным, не должны знать лично человека(людей), находящегося(ихся) под следствием, - должно быть подписано соглашение о неразглашении информации лицами, имеющими доступ к персональным данным, до их допуска к ним, - информация должна использоваться только для конкретной цели, для которой она была получена, т.е. для расследования инцидентов информационной безопасности. 2. Ведется соответствующий учет. Некоторые национальные законы требуют, чтобы компании вели учет своей деятельности, для пересмотра в ежегодном процессе аудита организации. Аналогичные требования существуют и в отношении государственных организаций. В некоторых странах организации обязаны сообщать или создавать архивы для правоохранительных органов (например, о любом случае, который может включать серьезное преступление или проникновение в важные правительственные системы). 3. Средства управления для обеспечения выполнения коммерческих договорных обязательств. Там, где существуют обязательные требования по обеспечению службы менеджмента инцидентов в области информационной безопасности, охватывающие необходимые временные промежутки для принятия ответных мер, организация должна обеспечить соответствующую информационную безопасность для гарантии того, что такого рода обязательства могут быть выполнены при любых обстоятельствах. (В связи с этим, если организация заключает договора с доверенной третьей стороной для поддержки, например внешняя ISIRT, затем она должна обеспечить содержание в договоре с доверенной третьей стороной всех требований, включая временные промежутки для принятия ответных мер.) 4. Правовые вопросы, касающиеся политик и проводимых процедур. Политики и процедуры в рамках системы менеджмента инцидентов в области информационной безопасности, должны быть проверены на предмет возможных правовых и нормативных вопросов, например, есть ли формулировки дисциплинарных и/или правовых мер против тех, которые вызывают инциденты в области информационной безопасности. В некоторых странах не так легко расторгнуть трудовой договор. 5. Все оговорки проверяются на юридическую силу. Все оговорки относительно действий, предпринимаемых командой менеджмента инцидентов в области информационной безопасности, и любым персоналом, оказывающим поддержку со стороны, должны быть проверены на законность. 6. Все договора с персоналом, оказывающим поддержку со стороны, должны охватывать все необходимые аспекты. Договора с персоналом, оказывающим поддержку со стороны, например, с внешней ISIRT, должны быть тщательно проверены в отношении отказа от ответственности, неразглашения, доступности обслуживания и последствий неправильных рекомендаций. 7. Соглашения о неразглашении информации и исполнению. От членов команды, осуществляющей менеджмент инцидентов в области информационной безопасности, может потребоваться подписание соглашения о неразглашении, как при устройстве на работу, так и при увольнении. 8. Правоохранительные требования. Вопросы, связанные с возможностью, что правоохранительные органы могут легально запрашивать информацию от системы менеджмента инцидентов в области информационной безопасности, должны быть четко сформулированы. Может быть, что четкость требуется на минимальном уровне, требуемым по закону, согласно которому инциденты должны быть документально зафиксированы, и определен срок ее хранения.

63

СТБ ISO/IEC 27035/ПР_1 9. Четко определенные аспекты ответственности. Вопросы возможной ответственности и связанных с ней необходимых средств управления необходимо уточнять. Примеры событий, которые могут касаться вопросов ответственности: - если инцидент может повлиять на другую организацию (например, раскрытие общей информации), и о нем не было сообщено вовремя, при этом другая организация имеет последствия от этого негативного влияния; - если обнаружена новая уязвимость в продукте, и поставщик не уведомлен о ней; - если, в конкретной стране, отчет не сделан организацией, которая обязана сообщать или создавать архивы для правоохранительных органов в отношении любых случаев, которые могут повлечь серьезные преступления или проникновения в важные правительственные системы или системы, критически важные для национальной инфраструктуры; - что не раскрывается информация, которая указывает на то, что кто-то, или организации, могут быть задействованы в атаке. Это может отрицательно сказаться на репутации и развитии бизнеса участвующего лица или организации; - разглашение информации о том, что могут быть проблемы с конкретным элементом ПО, что не является правдой;  рассматриваются конкретные нормативные требования. Где это необходимо в соответствии с конкретными нормативными требованиями, об инцидентах следует сообщать уполномоченному органу, например, как требуется в атомной промышленности, телекоммуникационных компаниях и провайдеров интернет-услуг во многих странах;  судебные преследования или внутренние дисциплинарные процедуры могут быть успешными. Соответствующие средства управления информационной безопасностью, включая доказуемо защищенные от несанкционированного доступа журналы аудита, чтобы обеспечить успешное уголовное преследование, либо провести внутренние дисциплинарные процедуры против "нападавших" вне зависимости от того, являются ли атаки техническими или физическими. В поддержку этого, доказательства, как правило, должны быть собраны таким образом, чтобы они были приняты в соответствующих национальных судах или на других дисциплинарных форумах. Должно быть возможным показать, что: - записи являются полными и не были изменены; - копии электронных данных доказуемо идентичны оригиналам; - любая IT-система, из которой данные были собраны, функционировала правильно на момент записи данных;  правовые аспекты, связанные с методами мониторинга. Последствия использования методов мониторинга должны рассматриваться в контексте соответствующего национального законодательства. Законность различных методов будет различаться в зависимости от страны. Например, в некоторых странах необходимо, чтобы люди были осведомлены о том, что проводится мониторинг деятельности, в том числе с помощью методов наблюдения. Факторы, которые необходимо учитывать, включают в себя: кто/что претерпевает изменения, как они/она контролируются и когда мониторинг осуществляется. Следует также отметить, что мониторинг/наблюдение в контексте IDS, в частности, обсуждается в ISO/IEC 18043;  политика допустимого использования определена и передается. Допустимая практика/использование в организации должны быть определены, представлены документально и сообщены всем пользователям (например, пользователи должны быть проинформированы о политике допустимого использования и получить запрос предоставить письменное подтверждение, что они понимают и принимают данную политику, когда они присоединяются к организации или получают доступ к информационным системам).

64

СТБ ISO/IEC 27035/ПР_1

Библиография [1]

[2] [3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

ISO/IEC 18043

Information technology – Security techniques – Selection, deployment and operations of intrusion detection systems (Информационные технологии. Методы обеспечения безопасности. Выбор, применение и операции с системами обнаружения вторжения) ISO/IEC 2000 (все части) Information technology — Service management (Информационные технологии. Менеджмент сервисов) ISO/PASS 22399, Societal security — Guidelines for incident preparedness and operational continuity management (Социальная безопасность. Societal security Рекомендации по обеспечению готовности к инциденту в области информационной безопасности и менеджмента непрерывности работы) ISO/IEC 27001 Information technology — Security techniques — Information security management systems — Requirements (Информационные технологии. Методы обеспечения безопасности. Системы менеджмента информационной безопасности. Требования) ISO/IEC 27002 Information technology — Security techniques — Code of practice for information security management (Информационные технологии. Методы обеспечения безопасности. Кодекс практики для менеджмента информационной безопасности) ISO/IEC 27003 Information technology — Security techniques — Information security management system implementation guidance (Информационные технологии. Методы обеспечения безопасности. Руководство по применению системы менеджмента информационной безопасности) ISO/IEC 27004 Information technology — Security techniques — Information security management — Measurement (Информационные технологии. Методы обеспечения безопасности. Менеджмент информационной безопасности. Измерения) ISO/IEC 27005 Information technology – Security techniques – Information security risk management (Информационные технологии. Методы обеспечения безопасности. Менеджмент рисков информационной безопасности) ISO/IEC 27031 Information technology — Security techniques — Guidelines for information and communication technology readiness for business continuity (Информационные технологии. Методы обеспечения безопасности. Руководство по готовности информационнокоммуникационных технологий к обеспечению непрерывности бизнеса) ISO/IEC 27033-1 Information technology — Security techniques — Network security — Part 1: Overview and concepts (Информационные технологии. Методы обеспечения безопасности. Безопасность сети. Часть 1: Обзор и концепции) ISO/IEC 27033-2 Information technology — Security techniques — Network security — Part 2: Guidelines for the design and implementation of network security (Информационные технологии. Методы обеспечения безопасности. Безопасность сети. Часть 2: Руководящие указания по проектированию и внедрению безопасности сети) ISO/IEC 27033-3 Information technology — Security techniques — Network security — Part 3: Reference networking scenarios — Threats, design techniques and control issues (Информационные технологии. Методы обеспечения безопасности. Безопасность сети. Часть 3: Эталонные сетевые сценарии – Угрозы, методики проектирования и вопросы управления) Internet Engineering Task Force (IETF) Site Security Handbook (Справочное пособие по безопасности сети IETF (открытого международного сообщества проектировщиков, ученых, сетевых операторов и провайдеров)), http://www.ietf.org/rfc/rfc2196.txt?number=2196 65

СТБ ISO/IEC 27035/ПР_1 [14] [15]

[16]

[17] [18] [19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

66

NISTSpecialPublication 800-61

Ожидаемые для компьютера ответные меры на инцидент в области информационной безопасности, mailto:http://www.ietf.org/rfc/rfc2350.txt?number=2350 NISTSpecialPublication Руководство по компьютерной обработке инцидентов в области 800-61 информационной безопасности (2004), mailto:http://csrc.nist.gov/publications/nistpubs/800-61-rev1/SP80061rev1.pdf TERENA's Incident Object Description Exchange Format Data Model and XML Implementation (IODEF) (produced by IETF), RFC 5070 (Модель формата обмена данных относительно описания объекта инцидента TERENA’S и Реализации XML (IODEF) (производство IETF), RFC 5070) IETFRFC 3227 Руководящие указания по сбору и архивации данных IETF RFCCESG Руководящие принципы реагирования на инциденты (2008), GOVCERTUK http://www.govcertuk.gov.uk/pdfs/incident_response_guidelines.pdf Software Engineering Institute at Carnegie Mellon “CERT Coordination Centre”, Incident Management Capability Metrics Version 0.1 (2007) (“Координационный Центр CERT” Software EngineeringInstitute (SEI) на территории студенческого городка Университета Карнеги-Меллона, Показатели возможностей менеджмента инцидентов Версия 0.1 (2007)) http://www.cert.org/archive/pdf/07tr008.pdf Software Engineering Institute at Carnegie Mellon “CERT Coordination Centre”, Incident Management Mission Diagnostic Method Version 1.0 (“Координационный Центр CERT” Software EngineeringInstitute (SEI) на территории студенческого городка Университета Карнеги-Меллона, Метод диагностики предназначения менеджмента инцидентов Версия 1.0) http://www.cert.org/archive/pdf/08tr007.pdf Software Engineering Institute at Carnegie Mellon “CERT Coordination Centre”, Defining Incident Management Processes for CSIRTs: A Work in Progress (“Координационный Центр CERT” Software EngineeringInstitute (SEI) на территории студенческого городка Университета Карнеги-Меллона, Определение процессов менеджмента инцидентов для CSIRTs: В стадии разработки) http://www.cert.org/archive/pdf/04tr015.pdf Software Engineering Institute at Carnegie Mellon “CERT Coordination Centre”, Handbook for Computer Security Incident Response Teams (CSIRTs) (“Координационный Центр CERT” Software EngineeringInstitute (SEI) на территории студенческого городка Университета Карнеги-Меллона, Справочное пособие для групп реагирования на инциденты компьютерной безопасности (CSIRTs)) mailto:http://www.cert.org/archive/pdf/csirt-handbook.pdf Software Engineering Institute at Carnegie Mellon “CERT Coordination Centre”, State of the Practice of Computer Security Incident Response Teams (“Координационный Центр CERT” Software EngineeringInstitute (SEI) на территории студенческого городка Университета Карнеги-Меллона, Состояние практики CSIRTs) mailto:http://www.cert.org/archive/pdf/03tr001.pdf Software Engineering Institute at Carnegie Mellon “CERT Coordination Centre”, CSIRT Services (“Координационный Центр CERT” Software EngineeringInstitute (SEI) на территории студенческого городка Университета Карнеги-Меллона, Сервисы CSIRT) mailto:http://www.cert.org/csirts/services.html Software Engineering Institute at Carnegie Mellon “CERT Coordination Centre”, Action List for Developing a Computer Security Incident Response Team (CSIRT) (“Координационный Центр CERT” Software EngineeringInstitute (SEI) на территории студенческого городка Университета Карнеги-Меллона, Список действий для формирования группы реагирования на инциденты компьютерной безопасности (CSIRT)) mailto:http://www.cert.org/csirts/action_list.html Software Engineering Institute at Carnegie Mellon “CERT Coordination Centre”, Staffing Your Computer Security Incident Response Team – What Basic Skills Are Needed? (“Координационный Центр CERT” Software EngineeringInstitute (SEI) на территории студенческого городка Университета Карнеги-Меллона, Подбор персонала в Вашу группу реагирования на инциденты компьютерной безопасности- Какие основные навыки необходимы?) mailto:http://www.cert.org/csirts/csirt-staffing.html Software Engineering Institute at Carnegie Mellon “CERT Coordination Centre”, Steps for Creating National CSIRTs (“Координационный Центр CERT” Software EngineeringInstitute (SEI) на территории

СТБ ISO/IEC 27035/ПР_1

[28]

[29] [30] [31] [32] [33] [34] [35] [36]

[37] [38] [39] [40]

[41] [42]

[43]

[44] [45]

студенческого городка Университета Карнеги-Меллона, Этапы создания национальных CSIRTs) mailto:http://www.cert.org/archive/pdf/NationalCSIRTs.pdf SANS Institute, An approach to the ultimate in-depth security event management framework, 2008 (SANS институт, Подход к созданию окончательной всесторонней структуры менеджмента инцидентов в области информационной безопасности) SANS Institute, Mining gold, A primer on incident handling and response, 2008 (SANS институт, Добыча золота, Учебник по обработке инцидентов и реагированию) SANS Institute, Incident Handling for SMEs (Small to Medium Enterprises), 2008 (SANS институт, Обработка инцидентов для SME (малых и средних предприятий)) SANS Institute, Breach Notification in Incident Handling, 2008 (SANS институт, Нарушение уведомления в процессе обработки инцидента) SANS Institute, Baselines and Incident Handling, 2008 (SANS институт, Базовые показатели и процесс обработки инцидента) SANS Institute, Documentation is to Incident Response as an Air Tank is to Scuba Diving, 2007 (SANS институт, Документация для процесса реагирования на инцидент определена ATSD) SANS Institute, Creating and Managing an Incident Response Team for a Large Company, 2007 (SANS институт, Создание и управление группой реагирования на инциденты для большой компании) SANS Institute, An Incident Handling Process for Small and Medium Businesses, 2007 (SANS институт, Процесс обработки инцидента для малого или среднего бизнеса) SANS Institute, Incident Management 101 Preparation & Initial Response (aka Identification), 2005 (SANS институт, Менеджмент инцидентов 101 подготовительная и первичная реакция (aka Идентификация)) SANS Institute, Building an Incident Response Program To Suit Your Business, 2003 (SANS институт, Построение программы реагирования на инцидент с учетом особенностей Вашего бизнеса) ISACA, COBIT 4.1 ( DS5.11), www.isaca.org/cobit ENISA, A step-by-step approach on how to set up a CSIRT (ENISA, Пошаговый подход о том, как создать CSIRT) mailto:http://www.enisa.europa.eu/act/cert/support/guide ENISA, CERT cooperation and its further facilitation by relevant stakeholders (ENISA, Сотрудничество CERT и дальнейшее содействие с ней со стороны соответствующих) субъектов деятельности) mailto:http://www.enisa.europa.eu/act/cert/background/coop ENISA, A basic collection of good practices for running a CSIRT (ENISA, Основное обобщение передового опыта работы CSIRT) mailto:http://www.enisa.europa.eu/act/cert/support/guide2 TERENA's Incident Object Description and Exchange Format Requirements (IODEF) (produced by IETF), RFC 3067 (Описание объекта инцидента TERENA и требования формата обмена (IODEF) (производство IETF), RFC 3067) CVSS — A complete Guide to the Common Vulnerability Scoring System (Version 2.0), FIRST, 20 June 2007 (CVSS – Полное руководство по общей системе поиска уязвимостей (Версия 2,0)) mailto:http://www.first.org/cvss/cvss-guide.html SWIF — Structured Warning Information Format (Version 2.3), ITsafe, 9 May 2008 (SWIF – Структурированный формат предупредительной информации (Версия 2,3), безопасный с точки зрения IT) ITIL, ITIL framework document (ITIL, ITIL основной документ) mailto:http://www.itil-officialsite.com/home/home.asp

67

СТБ ISO/IEC 27035/ПР_1

Приложение Д.А (справочное)

Сведения о соответствии государственных стандартов ссылочным международным стандартам Таблица Д.А.1 Обозначение и наименование международного стандарта

Степень соответствия

Обозначение и наименование государственного стандарта

ISO/IEC 27000:2009 Информационная технология. Методы обеспечения безопасности. Системы менеджмента информационной безопасности. Общие положения и определения

IDT

СТБ ISO/IEC 27000-2012 Информационные технологии. Методы обеспечения безопасности. Системы менеджмента информационной безопасности. Общий обзор и словарь

68

СТБ ISO/IEC 27035/ПР_1

Директор государственного предприятия "НИИ ТЗИ"

В.Ф.Картель

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

Д.А.Комликов

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

И.В.Юнкевич

Ответственный исполнитель, ведущий инженер-конструктор

В.В.Белявский

Техник

А.В.Сенюк

Ведущий инженер по стандартизации

В.М.Кравцова

69