ГОСТ Р ИСО/МЭК ТО 18044—2007
ние о конфиденциальности (неразглашении) при получении доступа к ней. Если события ИБ регистри
руют через общую систему менеджмента проблем, то конфиденциальные подробности, возможно,
придется опустить.
Кроме того, система менеджмента инцидентов ИБ должна обеспечивать контроль за передачей
сообщений об инцидентахсторонними организациями, включая СМИ. партнеров по бизнесу, потребите
лей. регулирующие организации и общественность.
5.2.7 Независимость деятельности группы реагирования на инциденты информационной
безопасности
Группа менеджмента инцидентов ИБ должна быть способна эффективно удовлетворять функцио
нальные, финансовые, правовые иполитические потребности конкретнойорганизации и быть в состоя
нии соблюдать осторожность при управлении инцидентами ИБ. Деятельность группы менеджмента
инцидентов ИБ должна также подвергаться независимому аудиту с целью проверки эффективности ее
функционирования. Эффективным способом реализации независимости контроля является отделение
цепочки сообщений о реагировании на инцидент ИБот общего оперативного руководства и возложение
на вышестоящего руководителя непосредственных обязанностей по управлению реагированием на ин
циденты. Финансирование работы группы, во избежание чрезмерного влияния на нее со стороны, также
должно быть отдельным.
5.2.8 Типология
Общая типология, отражающая структуру подхода к менеджменту инцидентов ИБ. являетсяодним
из ключевых факторов обеспечения последовательных надежных результатов. Типология1), наряду с
общепринятыми метриками и стандартной структурой баз данных, обеспечивает возможность сравни
вать результаты, улучшать предупреждающую информацию и получать более точное представление
об угрозах для информационных систем и их уязвимостях.
6 Примеры инцидентов информационной безопасности и их причин
Инциденты ИБ могут быть преднамеренными или случайными (например, являться следствием
какой-либо человеческой ошибки или природных явлений) и вызваны как техническими, так и нетехни
ческими средствами. Их последствиями могут быть такие события, как несанкционированные раскры
тие или изменение информации, ее уничтожение или другие события, которые делают ео недоступной, а
также нанесение ущерба активам организации или их хищение. Инциденты ИБ. о которых не было со
общено. но которые были определены как инциденты, расследовать невозможно и защитных мер для
предотвращения повторного появления этих инцидентов применить нельзя.
Ниже приведены некоторые примеры инцидентов ИБ и их причин, которыедаются только с целью
разъяснения. Важно заметить, что эти примеры не являются исчерпывающими.
6.1 Отказ в обслуживании
Отказ в обслуживании является обширной категорией инцидентов ИБ, имеющих одну общую чер
ту. Подобные инциденты ИБ приводят к неспособности систем, сервисов или сетей продолжатьфункци
онирование с прежней производительностью, чаще всего при полном отказе вдоступе авторизованным
пользователям.
Существует два основных типа инцидентов ИБ, связанных с отказом в обслуживании, создавае
мых техническими средствами: уничтожение ресурсов и истощение ресурсов.
Некоторыми типичными примерами таких преднамеренных технических инцидентов ИБ «отказ в
обслуживании» являются:
- зондирование сетевых широковещательных адресов с целью полного заполнения полосы про
пускания сети трафиком ответных сообщений:
- передача данных в непредусмотренном формате в систему, сервис или сеть в попытке разру
шить или нарушить их нормальную работу:
- одновременное открытие нескольких сеансов с конкретной системой, сервисом или сетью в по
пытке исчерпать их ресурсы (то есть замедление их работы, блокирование или разрушение).
Определение общей типологии не является целью настоящего стандарта. Рекомендуется обращение к
другим источникам за этой информацией.
10