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

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

Второй реакцией на преднамеренную атаку может быть активация дополнительных методов отслеживания действий нарушителя (например, honeypots – «приманки» для хакеров в виде виртуальных ресурсов). Это действие должно осуществляться на основе процедур, задокументированных в схеме управления инцидентами ИБ.

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

Обновление информации об инцидентах

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

Необходимо обновлять следующую информацию об инциденте:

– что собой представляет;

– как, чем или кем был вызван;

– на что повлиял или мог повлиять;

– как изменялась его серьезность;

– как обрабатывался до сих пор.

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

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

Для инцидента ИБ, повлившего на ИТ, необходимо выполнить следующие действия.

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

При этом необходимо:

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

– собрать и проанализировать журналы (логи) соседних систем, сервисов и/или сетей, например, маршрутизаторов и межсетевых экранов;

– всю собранную информацию хранить только на неперезаписываемых носителях;

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

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

Дальнейшая деятельность

После определения реальности инцидента ГРИИБ должна выполнить и другие важные действия:

– проведение правовой экспертизы;

– информирование ответственных лиц за передачу информации о фактах и предложениях (для чего, в какой форме и кому).

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

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

Член ГРИИБ при оценке инцидента ИБ должен на основании руководящей документации схемы управления ими знать следующее:

– когда и кому направлять материалы,

– действовать согласно процедур контроля изменений.

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

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

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

4.2. Оценка контроля инцидентов ИБ

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

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

Если не подтверждается, что инцидент ИБ находится под контролем, член ГРИИБ должен инициировать кризисные действия.

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

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

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

4.3. Последующее реагирование

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

Последующее реагирование может включать в себя следующие действия:

– восстановление пораженных систем;

– предотвращение повторного возникновения инцидента;

– активация дополнительных средств мониторинга систем.

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