Проверка обработки событий безопасности и управления инцидентами

Для комплексной системы ситуационного контроля проектировался программный контур управления инцидентами. Проверка была сосредоточена на том, что происходит с событием безопасности после его возникновения: предусмотрено ли автоматическое реагирование, как инцидент регистрируется и обрабатывается, как ведутся его учёт и классификация и каким образом информация доводится до уполномоченных сотрудников и ответственных структур.

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

От события безопасности к управляемому инциденту

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

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

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

Регистрация, обработка, учёт и классификация

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

• регистрация — наличие проектной функции фиксации возникшего инцидента;
• обработка — предусмотренная работа с зарегистрированным инцидентом;
• учёт — сохранение инцидента в системе управления соответствующими событиями;
• классификация — отнесение инцидента к предусмотренной проектом категории обработки.

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

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

Информация об инцидентах в реальном времени

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

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

Поэтому при проверке проектного решения рассматривается не только наличие терминов «инцидент» или «оповещение», а связанная схема работы. Событие должно попасть в контур обработки, получить предусмотренные функции регистрации, учёта и классификации, а информация о нём — доводиться до уполномоченных сотрудников в установленном проектом режиме.

Оповещение ответственных структур о нарушениях безопасности

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

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

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

Чем управление инцидентами отличается от управления доступом

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

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

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

Что подтверждено и где заканчивается результат

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

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

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

Следующий кейс рассматривает уже другой тип профессиональной задачи — вариантный расчёт нагрузки от шлюзовых кабин. Остальные утверждённые примеры представлены в разделе «Кейсы».