Завершив прошлую заметку математическими выкладками, я решил проверить, а насколько сама MITRE ATT&CK пропагандирует такой подход с перебором всех возможных комбинаций. В документе " Getting Started With ATT&CK " приводится 4 основных сценария применения этой матрицы:
Но что-то я отвлекся от методики моделирования. Отложим пока эту практически нерешаемую задачу и посмотрим, что нам проект новой методики подготовил дальше. Переходим к 3-му разделу, который впервые в практике регулятора столь глубоко говорит о важности риск-ориентированного подхода и необходимости оценки ущерба от негативных последствий в результате реализации угроз ИБ. Правда, уже в разделе 3.2 мы вновь скатываемся к технике. Если сами по себе негативные последствия вытекают из решаемых конкретной ИС задач и для их определения достаточно просто сесть и подумать (экспертная группа и метод Дельфи, упомянутые вчера, тут хорошо помогают), то методика зачем-то требует от меня выявить все компоненты ИС, включая все флешки, все десятки тысяч сенсоров и датчиков в промышленной сети, все виртуальные машины и т.п., а затем проанализировать их взаимодействие на 5-ти уровнях (железо, система, приклад, сеть и пользователи).
Я попробовал применить это к системе удаленного доступа в Cisco (кому интересно, как это устроено, мы в четверг будем проводить вебекс на эту тему) и понял, что не могу - у нас только активных IP-устройств в сети около полумиллиона, несколько сотен тысяч рабочих станций, десятки тысяч пользователей, тысячи серверов и виртуальных машин, а также тысячи приложений. Как вы думаете какое количество комбинаций взаимодействия будет в такой конфигурации? Да, у нас есть средства автоматизации анализа взаимодействия на уровне ОС, приложений, сети и пользователей, но работают они у нас преимущественно для ЦОДов и облачных сред, то есть только там, где обрабатываются данные и работают критичные для нас приложения.
Дальше, согласно пункту 3.3, мы должны определить для каждого компонента виды неправомерного доступа, которые могут привести к негативным последствиям. ДЛЯ КАЖДОГО. Не для целой системы или процесса, не для группы ресурсов или компонентов, а для каждого. Чем виды неправомерного (хотя, наверное, должно было быть "несанкционированного") доступа для моего ноутбука отличаются от таких же видов НСД для еще несколько тысяч моих коллег по компании, имеющих те же привилегии, что и я, я не знаю. Также как и негативные последствия. Я еще могут понять, когда ущерб считается для всех бухгалтеров, для всех имеющих доступ к ПДн, для всех, имеющих доступ к конфиденциальной информации, для всех коммутаторов в ЦОДе и т.п. Такое группирование логично. Но оценивать это для КАЖДОГО?.. То есть я еще не закончил процесс вычисления всех комбинаций тактик и техник, не завершил процесс вычисления всех комбинаций взаимодействия компонентов ИС на пяти уровнях, а тут мне еще и все виды несанкционированного доступа для всех этих компонентов надо определить.
Причем, дальше по тексту, в п.3.4 и таблице 1, ФСТЭК демонстрирует пример уже для групп компонентов, а не для каждого из них. Налицо нестыковка. Похоже тут чисто стилистическая недоработка и авторы проекта методики сами не прошли по каждому пункту, попробовав смоделировать перечень угроз для какой-либо из систем, даже для самой ФСТЭК. Я бы порекомендовал авторам внимательно посмотреть на использование слов "каждый", "все", "всех" и т.п., и разрешить активно использовать группирование сущностей, которые используются при моделировании угроз. Ну и чисто для себя определился бы с тем, что именно мы вкладываем в термин "негативные последствия (ущерб)". Если мы говорим об ущербе в понимании риск-ориентированного подхода, то это понятие достаточно высокоуровневое и определяется оно для достаточно высокоуровневых объектов, а не для каждого аппаратного компонента, который есть у меня на комьютере или у меня дома и который участвует в удаленном доступе. Если DDoS-атака на VPN-кластер удаленного доступа может повлечь за собой невозможность оказания услуг всей организации - это одно, а если использование уязвимостей Spectre/Meltdown в процессорах Intel может повлечь за собой кражу ключей шифрования, то это уже совсем другое. Но в обоих случаях у нас есть негативные последствия.
Кстати, в перечислении шести видов неправомерного доступа упоминаются и негативные последствия. Например, в примере 2, утечка - это негативные последствия, а в п.3.3 - это уже неправомерный доступ. Также к неправомерному доступу относится отказ в обслуживании и нарушение функционирования, что, на мой взгляд, скорее относится к последствиям.
И вот подошел к концу третий раздел проекта методики. Смогли ли мы определить возможные негативные последствия? Мне кажется нет. Этот раздел оказался не доведен до конца. Мне казалось бы полезным привести перечень возможных видов ущерба (негативных последствий), из которого можно было бы выбирать подходящее. Тем более, что в майской версии проекта методики 2015-го года такой перечень был (таблица 6). Без этого, соотнесение (mapping) ущерба, компонента и видов неправомерного доступа, которые в таблице 1 почему-то названы возможными угрозами безопасности информации, будет очень нетривиальной задачей. Учитывая, что эта тема, оценка ущерба, для регулятора и его поднадзорных организаций совсем новая, этот раздел стоило бы проработать детальнее. Иначе будет куча разных мнений, которые, как известно будут трактоваться в пользу проверяющих, что приведет к росту коррупционной составляющей при проведении аттестационных и надзорных мероприятий. А также будет использовано различными лицензиатами в своих целях.
- Threat Intelligence
- Обнаружение и аналитика
- Эмуляция нарушителей и red team'инг
- Оценка и инжиниринг.
Но что-то я отвлекся от методики моделирования. Отложим пока эту практически нерешаемую задачу и посмотрим, что нам проект новой методики подготовил дальше. Переходим к 3-му разделу, который впервые в практике регулятора столь глубоко говорит о важности риск-ориентированного подхода и необходимости оценки ущерба от негативных последствий в результате реализации угроз ИБ. Правда, уже в разделе 3.2 мы вновь скатываемся к технике. Если сами по себе негативные последствия вытекают из решаемых конкретной ИС задач и для их определения достаточно просто сесть и подумать (экспертная группа и метод Дельфи, упомянутые вчера, тут хорошо помогают), то методика зачем-то требует от меня выявить все компоненты ИС, включая все флешки, все десятки тысяч сенсоров и датчиков в промышленной сети, все виртуальные машины и т.п., а затем проанализировать их взаимодействие на 5-ти уровнях (железо, система, приклад, сеть и пользователи).
Я попробовал применить это к системе удаленного доступа в Cisco (кому интересно, как это устроено, мы в четверг будем проводить вебекс на эту тему) и понял, что не могу - у нас только активных IP-устройств в сети около полумиллиона, несколько сотен тысяч рабочих станций, десятки тысяч пользователей, тысячи серверов и виртуальных машин, а также тысячи приложений. Как вы думаете какое количество комбинаций взаимодействия будет в такой конфигурации? Да, у нас есть средства автоматизации анализа взаимодействия на уровне ОС, приложений, сети и пользователей, но работают они у нас преимущественно для ЦОДов и облачных сред, то есть только там, где обрабатываются данные и работают критичные для нас приложения.
Дальше, согласно пункту 3.3, мы должны определить для каждого компонента виды неправомерного доступа, которые могут привести к негативным последствиям. ДЛЯ КАЖДОГО. Не для целой системы или процесса, не для группы ресурсов или компонентов, а для каждого. Чем виды неправомерного (хотя, наверное, должно было быть "несанкционированного") доступа для моего ноутбука отличаются от таких же видов НСД для еще несколько тысяч моих коллег по компании, имеющих те же привилегии, что и я, я не знаю. Также как и негативные последствия. Я еще могут понять, когда ущерб считается для всех бухгалтеров, для всех имеющих доступ к ПДн, для всех, имеющих доступ к конфиденциальной информации, для всех коммутаторов в ЦОДе и т.п. Такое группирование логично. Но оценивать это для КАЖДОГО?.. То есть я еще не закончил процесс вычисления всех комбинаций тактик и техник, не завершил процесс вычисления всех комбинаций взаимодействия компонентов ИС на пяти уровнях, а тут мне еще и все виды несанкционированного доступа для всех этих компонентов надо определить.
Причем, дальше по тексту, в п.3.4 и таблице 1, ФСТЭК демонстрирует пример уже для групп компонентов, а не для каждого из них. Налицо нестыковка. Похоже тут чисто стилистическая недоработка и авторы проекта методики сами не прошли по каждому пункту, попробовав смоделировать перечень угроз для какой-либо из систем, даже для самой ФСТЭК. Я бы порекомендовал авторам внимательно посмотреть на использование слов "каждый", "все", "всех" и т.п., и разрешить активно использовать группирование сущностей, которые используются при моделировании угроз. Ну и чисто для себя определился бы с тем, что именно мы вкладываем в термин "негативные последствия (ущерб)". Если мы говорим об ущербе в понимании риск-ориентированного подхода, то это понятие достаточно высокоуровневое и определяется оно для достаточно высокоуровневых объектов, а не для каждого аппаратного компонента, который есть у меня на комьютере или у меня дома и который участвует в удаленном доступе. Если DDoS-атака на VPN-кластер удаленного доступа может повлечь за собой невозможность оказания услуг всей организации - это одно, а если использование уязвимостей Spectre/Meltdown в процессорах Intel может повлечь за собой кражу ключей шифрования, то это уже совсем другое. Но в обоих случаях у нас есть негативные последствия.
Кстати, в перечислении шести видов неправомерного доступа упоминаются и негативные последствия. Например, в примере 2, утечка - это негативные последствия, а в п.3.3 - это уже неправомерный доступ. Также к неправомерному доступу относится отказ в обслуживании и нарушение функционирования, что, на мой взгляд, скорее относится к последствиям.
И вот подошел к концу третий раздел проекта методики. Смогли ли мы определить возможные негативные последствия? Мне кажется нет. Этот раздел оказался не доведен до конца. Мне казалось бы полезным привести перечень возможных видов ущерба (негативных последствий), из которого можно было бы выбирать подходящее. Тем более, что в майской версии проекта методики 2015-го года такой перечень был (таблица 6). Без этого, соотнесение (mapping) ущерба, компонента и видов неправомерного доступа, которые в таблице 1 почему-то названы возможными угрозами безопасности информации, будет очень нетривиальной задачей. Учитывая, что эта тема, оценка ущерба, для регулятора и его поднадзорных организаций совсем новая, этот раздел стоило бы проработать детальнее. Иначе будет куча разных мнений, которые, как известно будут трактоваться в пользу проверяющих, что приведет к росту коррупционной составляющей при проведении аттестационных и надзорных мероприятий. А также будет использовано различными лицензиатами в своих целях.
