Методология
agrishina.jpgАнастасия Гришина

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

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

Пример:

Недопустимое событие: вывод более 3 млн рублей со счета организации.

Целевая система: «банк — клиент».

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

Зачем нужны критерии и почему их важно формулировать правильно

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

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

Когда нужно определять критерии

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

Как правильно сформулировать критерии

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

ШагУсловие
Шаг 1. Определить, какая система является объектом финального воздействияЦелевая система.
Объект финального воздействия — непосредственно целевая система

Другая система, связанная с целевой.
Объект финального воздействия — система, обеспечивающая функционирование целевой системы или взаимодействующая с ней
Шаг 2. Определить, на каком уровне требуется получить доступ к системеУровень ОС.
Требуется показать, что выполнение команд в ОС на атакуемом узле возможно. Взаимодействие с ОС может осуществляться как через графический интерфейс, так и через интерпретаторы командной строки

Сетевой уровень (доступ к сегменту сети).
Достаточно получить доступ к сегменту сети без подключения к ОС конкретных узлов

Уровень прикладного ПО.
Требуется получить доступ к функциональности прикладного ПО

Физический доступ.
Система изолирована от других сетей, или для выполнения критерия требуется физическое взаимодействие с целевой системой
Шаг 3. Определить, с какими привилегиями (правами доступа) требуется получить доступ к системеС правами пользователя.
Требуется учетная запись непривилегированного пользователя

С правами администратора.
Требуется учетная запись привилегированного пользователя

С правами на чтение.
Для доступа к системе достаточно прав на чтение

С правами на чтение и запись.
Для доступа к системе требуются не только права на чтение, но и на запись

Без привилегий (или с любым их уровнем).
В системе отсутствуют механизмы разграничения прав доступа, или уровень привилегий не важен
Шаг 4. Определить, требуется ли получить доступ к данным, обрабатываемым в системеДа.
Требуется найти файл (например, электронный документ) или иное представление данных, обрабатываемых в системе, и получить доступ к нему

Нет
Шаг 5. Определить, требуется ли получить доступ к системе в установленный промежуток времениДа.
Требуется получить доступ к системе в определенный временной промежуток. Он может указываться как в конкретных часах, так и в виде ограничительных условий

Нет
Шаг 6. Определить, требуется ли удерживать доступ к системе в течение установленного времениДа.
Требуется некоторое время взаимодействовать с системой или удерживать доступ к ней. Рекомендуется устанавливать максимальное время присутствия в системе не более 24 часов. Это не повлияет на достоверность проверки, но позволит выполнить как можно больше других критериев в ограниченный срок

Нет
Шаг 7. Определить, требуется ли выполнить особый порядок действий в системеДа.
Требуется не только получить доступ к системе, но и выполнить в ней определенный порядок действий, например:
- произвести несанкционированные действия с использованием легитимных функций прикладного ПО;
- продемонстрировать возможность копирования, удаления или изменения данных в системе;
- изменить параметры целевой системы или связанных с ней систем

Нет
Шаг 8. Определить, требуется ли выполнить дополнительные условияДа.
Реализовать недопустимое событие невозможно без выполнения каких-либо дополнительных действий, которые не входят в предыдущие семь шагов (или должны наступить события, которые не всегда напрямую зависят от действий специалистов, моделирующих и имитирующих компьютерные атаки)

Нет

Таким образом, критерий может быть как простым и учитывать условия из двух шагов (к системе X требуется получить доступ с правами Y), так и более сложным и включать условия из трех и более шагов. Более того, один критерий реализации может включать условия, которые касаются сразу нескольких систем, являющихся объектом финального воздействия: например, если для реализации недопустимого события требуется получить доступ к данным, обрабатываемым в системе X, а затем использовать их для взаимодействия с прикладным ПО в системе Y.