Войти в профиль iXBT.com
Можно ввести логин и пароль от конференции
Забыли пароль?
Войти или зарегистрироваться через соцсеть

Вы обнаружили ИБ-нарушение. Что делать?

Это мероприятие проводят сегодня Мария Воронова директор по консалтингу компании InfoWatch, консультант в ИБ-области Максим Анюков, компания InfoWatch и консультант в области юридических вопросов Сергей Хайрук, компания InfoWatch. Они сегодня расскажут, что нужно делать, если сотрудники информационной безопасности или DLP-система обнаружили нарушение. Как зафиксировать инцидент, как оценить его критичность для компании, что надо сделать для его разбора, как его классифицировать, как оформить инцидент, как подготовить документацию для судебного разбирательства.

Темы, которые сегодня будут рассмотрены на мероприятии, изображены на следующем слайде.

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

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

Допустим DLP-система выдает какое-либо событие, таких событий может быть множество.

Событие в DLP-системе отображается закрашенным зеленым кружочком (в левой части слайда). Событие выявлено, далее в работу должен вступать офицер мониторинга безопасности, который это событие анализирует в соответствие с предоставленным ему критериями и принимает решение является ли данное событие инцидентом, тогда есть движение по стрелке наверх, или не является инцидентом, т.е. событие не подтверждено в качестве инцидента. Если все же данное событие с высокой долей вероятности является критичным для организации инцидентом – переходим к оценке критичности. Все необходимые критерии оценки должны быть согласованы и оформлены заранее. Далее проставляем отметку критичности и отправляем инцидент на расследование.

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

Какие другие признаки могут свидетельствовать что они потенциально могут быть инцидентами? Это может быть злой умысел, мошеннические действия. Здесь каждая компания для себя детализирует данный признак по конкретике в зависимости от ее специфики. Или событие связано с другими вещами, которые запрещены нормативными документами, правилами безопасности или внутреннего этического кодекса.

Событие не подтверждается

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

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

Оценка критичного инцидента

Теперь перейдем к оценке критичности инцидента. Слово берет Максим Анюков, консультант в ИБ-области, компания InfoWatch.

DLP-система во множестве организаций выдает огромное количество срабатываний и событий, разной степени критичности, это в определенной степени зависит от ее настроек.

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

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

Компании есть большие (несколько тысяч сотрудников) и маленькие (300-500 сотрудников), причем в последних на практике именно высокоуровневые коллеги занимаются ИБ, он