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