Управление информационной безопасностью. Стандарты СУИБ (СИ)

Менее серьёзные инциденты – те, которые:

– воздействуют на важные или обычные ИС,

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

– вызывают значительные социальные проблемы (митинги).

Несерьёзные инциденты – те, которые:

– воздействуют на обычные ИС,

– приводят к незначительным бизнес-потерям или их отсутствию,

– вызывают незначительные социальные проблемы или их не вызывают,

– не требуются никаких действий и нет последствий.

Взимосвязь категорий и классов

Категория и класс серьёзности инцидента ИБ часто взаимосвязаны. Одна категория инцидента ИБ может иметь различные классы серьёзности в зависимости как от бизнеса, так и природы инцидента ИБ, например, мотива, цели, времени, уровня.

Формы отчета об инцидентах

Формы отчета об уязвимости / инциденте / событии ИБ ведутся для:

1) полноты персонального описания события ИБ (не членом группы управления инцидентами ИБ), которое вносится в базу данных уязвимости / инцидента / события ИБ;

2) использования персоналом управления инцидентами ИБ для изначального оповещения о событии ИБ и дальнейших записей по оценке инцидента и т. п. до тех пор, пока инцидент не будет разрешен.

В базе данных уязвимости / инцидента / события ИБ записывается каждая стадия обновления. Полнота записи в базе данных уязвимости / инцидента / события ИБ затем облегчает деятельность по разрешению инцидента;

3) полноты персонального описания уязвимости ИБ (которая еще не вызвала события ИБ и потенциальный инцидент ИБ), которое вносится в базу данных уязвимости / инцидента / события ИБ.

Рекомендуется использовать международные стандартизированые форматы для электронного обмена и ввода данных об инциденте, интегрированные в электронну базу данных уязвимости / инцидента / события ИБ. В современном мире черчение схемы на бумаге занимает много времени. Однако нарисованная на бумаге схема может понадобиться в случае, когда невозможно использовать ее электронный вариант.

Процедуры

Перед тем, как приступить к работе с схемой управления инцидентами ИБ, необходимо иметь в наличии документированные и проверенные процедуры. В документации по каждой процедуре должны указываться лица из группы поддержки и/или ГРИИБ, ответственные за использование и управление этой процедуры. Такие процедуры должны обеспечить сбор и безопасное хранение электронных доказательств, что должно непрерывно контролироваться на случай судебного разбирательства или внутреннего дисциплинарного расследования.

Более того, должны существовать документированные процедуры, включающие в себя не только действия группы поддержки и ГРИИБ, но и процедуры, задействованные в правовой экспертизе и кризисных действиях, если они не задействованы где-либо еще, например, в плане обеспечения непрерывности бизнеса. Очевидно, что эти документированные процедуры должны полностью соответствовать документированной политике управления инцидентами ИБ и другой документации схемы управления инцидентами ИБ.

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

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

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

Для обработки уже известных типов событий и инцидентов ИБ должны существовать оперативные процедуры. Необходимы также оперативные процедуры, которым надо следовать, если тип обнаруженного инцидента ИБ или события неизвестен.

В этом случае рассматривают следующие аспекты:

– процесс оповещения для обработки таких исключительных случаев;