Расстановка приоритетов - это искусство отвечать на вопросы «с чего начать?» и "с чего мне продолжить?"
В этой статье мы анализируем, как сравнить теорию и практику, чтобы наиболее эффективно решить проблему безопасности, с которой сталкиваются компании любого размера, порядка и уровня: средство от уязвимой поверхности.
Эта проблема обычно возникает по мере развития зрелости управления жизненным циклом уязвимостей в ИТ-среде. Когда компания решает структурировать программу для оценки, анализа и понимания своей уязвимой поверхности, отправной точкой является использование более или менее коммерческих систем для проверки своих внутренних и внешних, инфраструктурных и прикладных систем, чтобы понять степень их устойчивости. в отношении известных уязвимостей.
Этот процесс обычно начинается со сканирования с переменной периодичностью, в ходе которого создаются отчеты об обнаруженных уязвимостях. Это начало, отнюдь не являющееся отправной точкой, обычно высвечивает огромное количество проблем, потенциал которых полностью выходит за рамки возможностей компании.
Следовательно, необходимо управлять жизненным циклом этой уязвимой поверхности, исследуя различные элементы, чтобы понять, как наилучшим образом использовать возможности смягчения последствий путем минимизации остаточного риска.
Вплоть до использования расширенных контекстов, таких как информация о взломе или, в более общем плане, информация о киберугрозах. Здесь определяется эволюция от Оценка уязвимости, чтобы Управление уязвимостями и наконец Управление угрозами и уязвимостями.
Итак, давайте теоретически рассмотрим некоторые методы определения правильного приоритета действий.
Прежде чем углубляться в теорию, хорошо сделать предпосылку: расчет приоритета является частью более крупного плана, который является планом оценки риска. В этом отношении, пожалуйста, обратитесь к стандарту ISO 31010: 2019 [1] и документам NIST SP-800-37 [2] и SP-800-30 [3], в частности к элементам, составляющим оценку: идентификация, анализ и взвешивание рисков, как показано ниже.
Ключевым моментом в создании эффективного плана исправления является правильная расстановка приоритетов. Затем мы представляем подход к анализу рисков и используемый метод. NIST делит подход на: ориентированный на угрозы, ориентированный на воздействие и ориентированный на уязвимости.
Для краткости модель, ориентированная на угрозы, принята в качестве модели риска, в которой определение приоритетов риска означает оценку угроз и - после расчета матрицы рисков - получение числового значения: чем выше значение, тем выше риск.
Что касается методов оценки рисков, то они в основном делятся на качественные, количественные и полуколичественные методы.
Литература учит нас, что при качественном методе для определения приоритетности риска мне нужно подсчитывать балл для каждой угрозы, так называемый Оценка риска, определяется как Вероятность x Удар по формуле R = P x I.
La шанс указывает на возможность возникновения непредвиденного события, способного нанести ущерб, в данном случае угрозы; L 'воздействие указывает на ущерб, потенциально причиненный угрозой.
Используя матрицу рисков 5x5, каждой угрозе присваиваются вероятность и воздействие с разными качественными уровнями, как показано на рисунке ниже.
Преимущество такого подхода заключается в ранжировании рисков с упором на наиболее приоритетные.
С другой стороны, качественный анализ является субъективным и основан на восприятии заинтересованными сторонами анализируемых угроз в сочетании с их опытом и навыками.
Количественный метод имеет более структурированный подход.
Имея возможность рассчитывать на время и ресурсы, которые нужно выделить, у нас есть возможность иметь статистические данные - например. сколько раз событие происходило в году - помимо точного анализа воздействия - например. если услуга «X» неактивна, вы теряете 1000 евро / час.
Таким образом, появляется возможность «перевести» риск в значительные числа для поддержки стратегических решений.
Количественный метод использует параметры EF (фактор подверженности), SLE (ожидаемая продолжительность единичных убытков), ARO (годовая частота возникновения) и ALE (годовая ожидаемая продолжительность убытков).
Ожидаемый убыток по отдельному активу равен:
SLE = стоимость актива x EF
SLE измеряет, насколько угроза затрагивает данный актив, такой как сервер, инфраструктура или даже услуга, состоящая из программного и аппаратного обеспечения.
ARO, с другой стороны, измеряет частоту этой угрозы в течение одного года. Ожидаемые экономические потери для данного актива в течение года выражаются следующим образом:
ALE = SLE x ARO
Рассмотрим числовой пример. Предположим, что у компании есть служба электронной торговли, которая выставляет счета на 1 миллион евро в год; поэтому принимается во внимание служба продаж, состоящая из набора оборудования, программного обеспечения и людей, которые работают.
Предположим, что DDoS-атака, блокирующая продажи и активность работающих людей, имеет фактор уязвимости 5%.
Наконец, предположим, что этот тип атаки был оценен 6 раз за последние 3 года, то есть имеет ARO = 6/3 => ARO = 2.
SLE = 1.000.000 0.05 50.000 евро x XNUMX = XNUMX XNUMX евро
ALE = 50.000 2 евро x 100.000 = XNUMX XNUMX евро
Следуя описанной модели риска, компания теряет в среднем 100.000 XNUMX евро в год.
Чтобы упростить пример, план исправления может заключаться в установке межсетевого экрана нового поколения с IDS / IPS для блокирования этих DDoS-атак за 50.000 5.000 евро + XNUMX XNUMX евро в год обслуживания.
Посредством полуколичественного метода оценки выполняются в соответствии с качественными методами, чтобы немедленно определить приоритеты риска и активировать план действий, чтобы затем повторно обработать данные и преобразовать качественные термины в числа, чтобы обеспечить более точную экономическую оценку.
После этой первой теоретической части, анализируя практику управления уязвимой поверхностью в сложных ИТ-средах, мы видим, что уровень сложности возрастает: для определения приоритетов корректирующих действий необходимо действовать, комбинируя некоторые из проиллюстрированных методов, чтобы достичь более описательного восприятия, чем аналитические риски и угрозы, нанесенные на его собственную цифровую поверхность.
Как видно, риск сложно рассчитать, особенно киберриск.
Он очень отличается от других видов риска (финансового, предпринимательского), он многогранен и основан на определенных данных и представлениях разведки. Становится важным не доверять только числовому представлению серьезности, критичности в пользу описательного восприятия риска.
По сути, я должен быть в состоянии описать, что меня беспокоит, чтобы рассчитывать на систему, которая преобразует эти мои представления в факторы приоритизации.
Примеры описания:
- Периметр, то есть возможность сопоставить систему, в которой обнаружена уязвимость, с периметром, к которому она принадлежит, для увеличения (или уменьшения) объективной критичности ресурса.
- Возраст уязвимостей, учитывая время их появления на публике и их обнаружение в вашей цифровой среде.
- Влияние на бизнес: например, рассмотрите все уязвимости, которые в случае взлома могут способствовать DDoS-атаке, или заражению, распространяющемуся через червей, или даже вспышке программ-вымогателей.
- Вероятность того, что угроза превратится в атаку: например, если уязвимость уже вооружена эксплойтом, возможно, уже часть Exploit Kit, которую легко найти (даже по найму) для мотивированного злоумышленника; на самом деле вероятность того, что он будет использован для атаки, безусловно, выше, чем для неизвестной уязвимости или для которой метод взлома еще не разработан.
- Собственная поверхность атаки. Сунь-цзы говорил: «Познай себя и знай своего врага, и ты переживешь сотню битв». Знание своего цифрового ландшафта поможет вам расставить приоритеты для решения проблемы в зависимости от сетевого контекста, в котором вы должны работать.
- Например, сосредоточение внимания на устранении уязвимостей, которые присутствуют только в запущенных ядрах или службах. Или в первую очередь в системах, подключенных к Интернету.
Пример того, как технологическая платформа поддерживает это перцептивное описание риска, показан ниже на основе решения Qualys:
После описания восприятия угрозы важно иметь дополнительный контекст, касающийся исправлений: как доступных, так и уже установленных в системах, чтобы провести проверку устаревания последних.
Также важно проанализировать уязвимости, возникающие из-за неправильных конфигураций, особенно в облачных средах, где ответственность разделяется: если я создаю хранилище на AWS или Azure и забываю ограничить список IP-адресов, которые могут получить к нему доступ, я рискую очень серьезная утечка данных; если я забуду включить многофакторную аутентификацию на экземпляре, последствия могут быть еще хуже.
Часто корректирующие действия (установка исправлений, изменение конфигурации, внедрение компенсирующих мер контроля) выполняются группами компании, которые не совпадают с теми, кто отвечает за обнаружение и классификацию уязвимостей ... поэтому необходим межведомственный клей, который облегчает интеграцию и автоматизацию для избегать конфликтов и неэффективности работы. Это может привести к использованию интерфейсов прикладного программирования (API), которые могут быть активированы для преобразования информации каждой отдельной платформы / приложения в зашифрованные и защищенные информационные потоки, которые становятся факторами, обеспечивающими межведомственные операционные потоки.
Последняя тема - отслеживание статус-кво, иначе называемое наблюдаемостью.
Это выражается в изучении форм агрегирования необработанных данных в информацию, которую легче понять; это может происходить в динамическом представлении - например, в информационных панелях - или в статическом, например в отчетах в формате PDF или других форматах, что помогает отслеживать прогресс, обнаруженные аномалии и неэффективность процесса с течением времени.
Например, совокупные уязвимости, обнаруженные за последние 30 дней, от 30 до 60, от 60 до 90.
Затем для каждой категории сопоставьте наличие исправления для исправления, выделив доступность эксплойтов для этих уязвимостей.
Наконец, сделайте эту информацию динамичной, постоянно обновляемой, чтобы предоставить каждой заинтересованной стороне представление о статус-кво и эффективности процесса исправления.
Исправить уязвимую поверхность, даже очень большую и сочлененную, конечно, непросто; однако организация контролируемого и приоритезированного жизненного цикла целостным и эффективным способом позволяет ограничить остаточный риск до приемлемого уровня, избегая опасного превращения в поверхность для атаки.
Ссылки:
[1] https://www.iso.org/standard/72140.html - IEC 31010: 2019 Управление рисками - Методы оценки рисков
[2] https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final - Структура управления рисками для информационных систем и организаций: подход к обеспечению безопасности и конфиденциальности на основе жизненного цикла системы
[3] https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final - Руководство по проведению оценки рисков
