Что такое критерий реализации недопустимого события
Критерий — условие (или несколько условий), демонстрирующее, что в повседневной операционной деятельности организации возможно наступление недопустимого события. Вместе с тем выполнение критериев не должно приводить к негативным последствиям, если иное заранее не согласовано с высшим руководством. При их определении рекомендуется останавливаться за один шаг до наступления недопустимого: например, получить в финансовых системах привилегии, достаточные для вывода денежных средств с расчетного счета, но не выводить эти средства; получить доступ к системе резервного копирования с правами на удаление информации, но не удалять резервные копии; получить возможность подменять содержимое на главном сайте организации, но не менять контент.
Пример:
Недопустимое событие: вывод более 3 млн рублей со счета организации.
Целевая система: «банк — клиент».
Критерий реализации недопустимого события: получение привилегий в системе «банк — клиент», позволяющих создавать, редактировать платежные поручения и отправлять их в банк.
Зачем нужны критерии и почему их важно формулировать правильно
Достоверно проверить на практике, возможна ли реализация недопустимых событий, можно, смоделировав и сымитировав компьютерные атаки. При этом важно не навредить организации. Чтобы избежать пагубных последствий и подтвердить возможность наступления недопустимых событий, рекомендуется использовать критерии. Они формулируются так, что исключается возможность нанести вред ИТ-инфраструктуре и бизнес-процессам и повышается эффективность действий специалистов, которые моделируют и имитируют компьютерные атаки.
Критерии могут также применяться при построении системы защиты информации и при обеспечении связанных с ней процессов. С помощью критериев легко определить, какие важные для бизнеса ресурсы нужно защищать и от какого воздействия. Это позволяет более эффективно организовать мониторинг инцидентов информационной безопасности и реагирование на них.
Когда нужно определять критерии
Критерии реализации недопустимых событий определяются после утверждения списка недопустимых событий и их сценариев, а также связанных с этими сценариями целевых систем. Сформулированные критерии необходимы для начала работ по оценке возможности реализации недопустимых событий путем моделирования и имитации компьютерных атак.
Как правильно сформулировать критерии
Чтобы сформулировать критерии реализации недопустимых событий, нужно выполнить восемь шагов.
| Шаг | Условие |
|---|
| Шаг 1. Определить, какая система является объектом финального воздействия | Целевая система.
Объект финального воздействия — непосредственно целевая система
Другая система, связанная с целевой.
Объект финального воздействия — система, обеспечивающая функционирование целевой системы или взаимодействующая с ней |
| Шаг 2. Определить, на каком уровне требуется получить доступ к системе | Уровень ОС.
Требуется показать, что выполнение команд в ОС на атакуемом узле возможно. Взаимодействие с ОС может осуществляться как через графический интерфейс, так и через интерпретаторы командной строки
Сетевой уровень (доступ к сегменту сети).
Достаточно получить доступ к сегменту сети без подключения к ОС конкретных узлов
Уровень прикладного ПО.
Требуется получить доступ к функциональности прикладного ПО
Физический доступ.
Система изолирована от других сетей, или для выполнения критерия требуется физическое взаимодействие с целевой системой |
| Шаг 3. Определить, с какими привилегиями (правами доступа) требуется получить доступ к системе | С правами пользователя.
Требуется учетная запись непривилегированного пользователя
С правами администратора.
Требуется учетная запись привилегированного пользователя
С правами на чтение.
Для доступа к системе достаточно прав на чтение
С правами на чтение и запись.
Для доступа к системе требуются не только права на чтение, но и на запись
Без привилегий (или с любым их уровнем).
В системе отсутствуют механизмы разграничения прав доступа, или уровень привилегий не важен |
| Шаг 4. Определить, требуется ли получить доступ к данным, обрабатываемым в системе | Да.
Требуется найти файл (например, электронный документ) или иное представление данных, обрабатываемых в системе, и получить доступ к нему
Нет |
| Шаг 5. Определить, требуется ли получить доступ к системе в установленный промежуток времени | Да.
Требуется получить доступ к системе в определенный временной промежуток. Он может указываться как в конкретных часах, так и в виде ограничительных условий
Нет |
| Шаг 6. Определить, требуется ли удерживать доступ к системе в течение установленного времени | Да.
Требуется некоторое время взаимодействовать с системой или удерживать доступ к ней. Рекомендуется устанавливать максимальное время присутствия в системе не более 24 часов. Это не повлияет на достоверность проверки, но позволит выполнить как можно больше других критериев в ограниченный срок
Нет |
| Шаг 7. Определить, требуется ли выполнить особый порядок действий в системе | Да.
Требуется не только получить доступ к системе, но и выполнить в ней определенный порядок действий, например:
- произвести несанкционированные действия с использованием легитимных функций прикладного ПО;
- продемонстрировать возможность копирования, удаления или изменения данных в системе;
- изменить параметры целевой системы или связанных с ней систем
Нет |
| Шаг 8. Определить, требуется ли выполнить дополнительные условия | Да.
Реализовать недопустимое событие невозможно без выполнения каких-либо дополнительных действий, которые не входят в предыдущие семь шагов (или должны наступить события, которые не всегда напрямую зависят от действий специалистов, моделирующих и имитирующих компьютерные атаки)
Нет |
Таким образом, критерий может быть как простым и учитывать условия из двух шагов (к системе X требуется получить доступ с правами Y), так и более сложным и включать условия из трех и более шагов. Более того, один критерий реализации может включать условия, которые касаются сразу нескольких систем, являющихся объектом финального воздействия: например, если для реализации недопустимого события требуется получить доступ к данным, обрабатываемым в системе X, а затем использовать их для взаимодействия с прикладным ПО в системе Y.
АГАнастасия Гришина