Управление инцидентами информационной безопасности

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

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

Политики информационной безопасности

Политики безопасности неразрывно связаны с явлением инцидентов. Политики определяют, что именно считать инцидентом, и какие предпринимать меры при его возникновении.

Термин «политика безопасности» характеризует два явления. С одной стороны, это регламентированные и задокументированные соглашения и своды правил. С другой, этим же термином называются наборы настроек систем предотвращения утечек данных (DLP-систем). При этом наборы настроек могут как дублировать закрепленные документально нормы, так и выступать более частными применениями общих стратегий.

Политики безопасности создаются после анализа информационной инфраструктуры предприятия, определения информации, подлежащей защите. Как настройки, они также зависят от возможностей DLP-системы, развернутой в компании. Системы на данный момент предлагают обширный инструментарий, но все же каждая компания выбирает для себя наиболее удобную. В частности, SecureTower совмещает инструменты предупреждения и расследования инцидентов с инструментами мониторинга рабочего времени.

Регистрация инцидентов информационной безопасности

Инциденты информационной безопасности регистрируются системой предотвращения утечек автоматически, в соответствии с заданными настройками.

Система может блокировать нежелательные действия, а также журналировать события и уведомлять о них сотрудников службы безопасности.

Если мы говорим о работе DLP-системы, то стоит упомянуть понятие ложного срабатывания. Суть явления понятна из названия, а причина происходит из некорректных настроек политик безопасности. На начальном этапе пользования системой ложные срабатывания практически неизбежны. Чтобы минимизировать их количество, политики нужно дорабатывать и корректировать.

Можно привести пример, когда система настроена на то, чтобы уведомлять службу безопасности, если в каком-то из мессенджеров сотрудники употребляют названия компаний-конкурентов. Совершенно понятно, что не каждое употребление происходит в контексте злонамеренных переговоров с конкурентами. Для того, чтобы понять, имел ли место злой умысел, нужно провести расследование. А в ходе анализа ложных срабатываний может проявиться необходимость уточнить политику.

Расследование инцидентов информационной безопасности

Расследования — неотъемлемая часть управления инцидентами безопасности. Поэтому DLP-системы предоставляют модули для проведения расследований. В них можно создавать дела, систематизировать информацию, в том числе об участниках расследования, результатах, ходе проверки, принятых мерах.

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

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

Другие элементы процесса управления инцидентами информационной безопасности

Расследование может проводиться не только по факту срабатывания системы на нарушение политики безопасности, но и по факту нарушения конфиденциальности или целостности информации, о которых стало известно другими путями. К примеру, конфиденциальная информация оказалась в СМИ, база данных осталась без защиты, ИТ-служба обнаружила вторжение в сеть. Все это также является инцидентами и влечет инициацию расследования.

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

Для расследования рядовых инцидентов, как правило, хватает собственных ресурсов компании. Зачастую для расследования не требуется даже участника сотрудника, из-за которого сработала система.

Процессы управления инцидентами, как и другие бизнес-процессы, нуждаются в постоянном мониторинге и совершенствовании.

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

Также в процессе работы становятся ясны детали, необходимые для внедрения в политики безопасности конкретных отделов.

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