Управление информационной безопасностью. Стандарты СУИБ
Шрифт:
Если аварийные защитные меры не применены, то нужно определить серьезность инцидента ИБ, используя заранее разработанную в организации шкалу классификации, и если инцидент ИБ достаточно серьезен, то об этом необходимо непосредственно уведомить вышестоящее руководство. Если очевидна необходимость объявления кризисной ситуации, менеджер кризисного управления должен быть оповещен о возможной активизации плана кризисного управления, причем об этом необходимо проинформировать руководителя ГРИИБ и вышестоящее руководство.
Процесс реагирования
– ограничение их неблагоприятных влияний,
– улучшение ИБ.
Первоначальной целью схемы управления инцидентами ИБ должна быть минимизация неблагоприятных влияний на бизнес, в то время как идентификация нападающего нужно рассматривать второстепенной целью.
ГРИИБ также является ответственным за возвращение поврежденных устройств в такое безопасное рабочее состояние (при возможности), которое исключит повторное возникновение инцидента, а также за соответствующее обновление базы данных событий / инцидентов / уязвимостей ИБ.
Примерные действия
Первой реакцией на преднамеренную атаку на ИС, сервис и/или сеть может быть ее неотключение от Интернета или другой сети, что даст возможность функционирования критически важных бизнес-приложений и сбора информации о нарушителе при условии, если он не знает, что находится под наблюдением.
1) Однако при принятии такого решения нужно учитывать, что нарушитель может почувствовать, что находится под наблюдением, и предпринять действия, наносящие дальнейший ущерб атакованной ИС, сервису и/или сети и данным, а также разрушить информацию, которая способствует его отслеживанию.
2) Важно, чтобы при принятии соответствующего решения была техническая возможность быстро и надежно изолировать атакованную ИС, сервис и/или сеть. Это даст возможность локализовать инцидент.
Предотвращение повторного возникновения инцидента является более приоритетной задачей. Кроме того, необходимо учитывать то, что нарушитель выявил уязвимость, которую необходимо устранить так быстро, чтобы он не успел нанести значительного ущерба. Это очень важно в том случае, когда нарушитель не является злоумышленником и не хочет нанести ущерба.
Что касается других инцидентов ИБ, кроме преднамеренной атаки, то их источник должен быть идентифицирован. Может потребоваться отключение ИС, сервиса и/или сети или изоляция соответствующим их частей (после получения предварительного согласия руководства подразделения ИТ и/или управления бизнесом) на время внедрения защитных мер. Для этого может потребоваться больше времени, если уязвимость ИС, сервиса и/или сети окажется существенной или критически важной.
Второй реакцией на преднамеренную атаку может быть активация дополнительных методов отслеживания действий нарушителя (например, honeypots – «приманки» для хакеров в виде виртуальных ресурсов). Это действие должно осуществляться на основе процедур, задокументированных в схеме управления инцидентами ИБ.
Информация, которая могла
Обновление информации об инцидентах
Независимо от последующих действий ГРИИБ должна обновить отчет об инциденте ИБ с максимальной детализацией, добавить его в базу данных событий / инцидентов / уязвимостей ИБ и оповестить об этом руководителя ГРИИБ.
Необходимо обновлять следующую информацию об инциденте:
– что собой представляет;
– как, чем или кем был вызван;
– на что повлиял или мог повлиять;
– как изменялась его серьезность;
– как обрабатывался до сих пор.
Если инцидент ИБ разрешен, то отчет должен содержать подробности предпринятых защитных мер и полученных уроков (например, дополнительные защитные меры, которые следует предпринять для предотвращения повторного события или подобных событий). Обновленный отчет следует добавлять в базу данных событий / инцидентов / уязвимостей ИБ и уведомлять руководителя ГРИИБ и других лиц по их требованию.
ГРИИБ должна обеспечить безопасное хранение информации об инциденте ИБ с целью проведения дальнейшей правовой экспертизы и возможного использования в суде как доказательств.
Для инцидента ИБ, повлившего на ИТ, необходимо выполнить следующие действия.
После первоначального обнаружения инцидента ИБ все непостоянные данные должны быть собраны до момента отключения пораженной системы, сервиса и/или сети. Предназначенная для сбора информация должна содержать сведения о памяти, кэше, регистрах и деталях любых функционирующих процессов.
При этом необходимо:
– в зависимости от характера инцидента ИБ провести полное дублирование свидетельств правовой экспертизы пораженной системы, сервиса и/или сети на случай судебного разбирательства или резервное копирование логов и важных файлов;
– собрать и проанализировать журналы (логи) соседних систем, сервисов и/или сетей, например, маршрутизаторов и межсетевых экранов;
– всю собранную информацию хранить только на неперезаписываемых носителях;
– при выполнении копирования свидетельств правовой экспертизы обеспечить присутствие не менее двух лиц для подтверждения того, что все действия были выполнены согласно действующему законодательству:
– документировать и хранить вместе с исходными носителями спецификации и описания сервисных команд, которые используются для дублирования свидетельств правовой экспертизы.
Дальнейшая деятельность
После определения реальности инцидента ГРИИБ должна выполнить и другие важные действия: