|
6.5 Классификация инцидентов
Для оценки событий и инцидентов следует использовать шкалу классификации событий и инцидентов ИБ. В любом случае, решение должно основываться на фактическом или прогнозируемом неблагоприятном воздействии на бизнес-процессы организации.
Примечание - В приложении B приведены примеры подходов к категоризации и классификации событий и инцидентов ИБ.
6.6 Формы отчетов о событиях и инцидентах
Формы отчетов о событиях и инцидентах, если они используются, должны быть созданы до того, как они понадобятся. Количество, тип и формат форм должны определяться ГРИИБ и периодически пересматриваться для обеспечения их актуальности. Необходимо наличие дополнительного типа формы с описанием определенной информации. Его цель - предоставить механизм для сбора информации в случаях, когда существующие формы недостаточны или соответствующая форма еще не создана.
Персонал, сообщающий о событиях и инцидентах информационной безопасности, должен быть оповещен о наличии форм отчетов о событиях и инцидентах, должен получить эти формы и ознакомиться с ними.
Примеры форм показаны в приложении C.
Рекомендуется использовать общепризнанные стандартизированные форматы электронного обмена и ввода информации об инцидентах, связанных непосредственно с электронной базой данных ИБ. Использование стандартизованного формата электронного обмена позволяет увеличить автоматизацию обработки данных и может уменьшить усилия по корреляции информации, когда несколько групп сотрудничают при обработке инцидента. Бумажная схема может потребоваться для случая, когда электронная схема не может быть использована.
6.7 Процессы и процедуры
Прежде чем приступить к работе над планом управления инцидентами ИБ важно, чтобы организация документировала и проверяла наличие необходимых процессов и процедур.
Примечание - Для удобства, в нижеследующем тексте термин «документ» будет использоваться для обозначения как процессов, так и процедур, если различие между процессом и процедурой не является значительным.
В каждом документе должны указываться группы или лица, ответственные за его использование и управление.
Важно понимать, что не все документы должны быть легко доступны как внутри организации, так и для широкой общественности. Например, всему персоналу организации не обязательно понимать внутреннюю работу ГРИИБ для взаимодействия с ней. ГРИИБ должна обеспечить, чтобы имеющееся руководство, включая информацию, полученную в результате анализа инцидентов ИБ, находилось в легкодоступной форме, например, на корпоративном портале организации и/или на общедоступном веб-сайте, в зависимости от ситуации. Также может быть важно сохранить в тайне некоторые детали плана управления инцидентами ИБ для предотвращения вмешательства инсайдера в процесс расследования. Например, если сотрудник банка, расхищающий его средства, осведомлен о каких-либо подробностях проведения расследования, он может быть в состоянии лучше скрыть свою деятельность от следователей или иным образом препятствовать обнаружению, расследованию и восстановлению после инцидента ИБ.
Содержание операционных процедур зависит от ряда критериев, в особенности связанных с характером известных потенциальных событий, инцидентов и уязвимостей ИБ, а также типов активов информационной системы, которые могут быть задействованы, и их среды. Таким образом, операционная процедура может быть связана с конкретным типом инцидента или продукта (например, межсетевыми экранами, базами данных, операционными системами, приложениями) или конкретным продуктом. Каждая операционная процедура должна четко определять шаги, которые необходимо предпринять и ответственное за них лицо. Она должна отражать опыт внешних (например, государственных и частных ГРИИБ, поставщиков) и внутренних источников.
Необходимо наличие операционных процедур для борьбы с типами событий и инцидентов ИБ, которые уже известны, а также уязвимостями. Также должны быть соблюдены рабочие процедуры, когда идентифицированное событие, инцидент или уязвимость ИБ не имеют какого-либо известного типа. В этом случае необходимо рассмотреть следующее:
а) процесс отчетности для обработки таких исключений;
b) руководящие указания по срокам получения разрешения от руководства организации во избежание любой задержки реагирования;
c) предварительно уполномоченное делегирование принятия решений при отсутствии нормального процесса разрешения.
Эксплуатационные процедуры для ГРИИБ должны разрабатываться с учетом документированных процессов и связанных с ними обязанностей и распределения ролей назначенным лицам для проведения различных мероприятий (физическому лицу может быть выделено более одной роли в зависимости от размера, структуры и организационной деятельности), в том числе:
- прекращение работы затронутой системы, службы и/или сети при определенных обстоятельствах, согласованных по предварительной договоренности с соответствующим ИТ-отделом и/или руководством;
- поддержание затронутой системы, службы и/или сети в подключенном и работающем состоянии;
- мониторинг данных (поступающих, исходящих и циркулирующих внутри) затронутой системы, службы и/или сети;
- активация шаблонных процедур и мероприятий резервного копирования и антикризисного управления в соответствии с политикой безопасности системы, службы и/или сети;
- мониторинг и поддержание безопасного хранения цифровых доказательств для случаев следственных действий или внутренних дисциплинарных мер;
- передача информации о деталях инцидента ИБ внутренним и внешним организациям. Это может включать в себя взаимодействие с несколькими внешними сторонами, такими как другие группы реагирования на инциденты, организации по обмену информацией, провайдеры интернет-услуг, поставщики программного обеспечения и технической поддержки, правоохранительные органы, клиенты, средства массовой информации и другие причастные стороны. Все контакты и взаимодействие с внешними сторонами должны быть задокументированы в целях обеспечения ответственности и доказательств.
Do'stlaringiz bilan baham: |
