Найти тему
REPLY-TO-ALL Information Security Blog

Эволюция требований к анализу защищенности

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

Безопасность не существует изолированно, а является важной бизнес-функцией, как и ИТ, причем эта поддержка взаимная: ИТ - поддерживает ИБ (выполняя контроли ИБ), а ИТ и ИБ - совместно поддерживают Бизнес, который генерит прибыль, обеспечивающую существование ИТ и ИБ. Исходя из этого риски Безопасности должны находить отражение в рисках Бизнеса и обратно, а анализ защищенности должен не просто находить технические уязвимости, а в итоге давать ответ на вопрос как риски эксплуатации технических уязвимостей могут привести к материализации Бизнес-рисков, т.е. к получению ущерба.
Безопасность не существует изолированно, а является важной бизнес-функцией, как и ИТ, причем эта поддержка взаимная: ИТ - поддерживает ИБ (выполняя контроли ИБ), а ИТ и ИБ - совместно поддерживают Бизнес, который генерит прибыль, обеспечивающую существование ИТ и ИБ. Исходя из этого риски Безопасности должны находить отражение в рисках Бизнеса и обратно, а анализ защищенности должен не просто находить технические уязвимости, а в итоге давать ответ на вопрос как риски эксплуатации технических уязвимостей могут привести к материализации Бизнес-рисков, т.е. к получению ущерба.
Синее облако - это автоматизируемый бизнес-процесс (БП), а зеленое болото - это его автоматизация в ИТ. В любом бизнес-процессе есть какие-либо риски, которые могут потенциально материализоваться в ущерб, ну и, конечно, в информационных системах (ИС), автоматизируемых БП, есть уязвимости. Пунктирные красные линии - это функция Безопасности: четкое понимание какие риски БП материализуются за счет каких уязвимостей в ИС - понимание "сверху", но также важно и понимание "снизу", когда Безопасность имеет представление о том какие уязвимости ИС материализуют какие риски БП. Как правило, бизнес-подразделения и внутренний аудит неплохо разбираются в БП и его рисках, а ИТ - в ИС, а важна именно связь - это и есть функция ИБ.
Синее облако - это автоматизируемый бизнес-процесс (БП), а зеленое болото - это его автоматизация в ИТ. В любом бизнес-процессе есть какие-либо риски, которые могут потенциально материализоваться в ущерб, ну и, конечно, в информационных системах (ИС), автоматизируемых БП, есть уязвимости. Пунктирные красные линии - это функция Безопасности: четкое понимание какие риски БП материализуются за счет каких уязвимостей в ИС - понимание "сверху", но также важно и понимание "снизу", когда Безопасность имеет представление о том какие уязвимости ИС материализуют какие риски БП. Как правило, бизнес-подразделения и внутренний аудит неплохо разбираются в БП и его рисках, а ИТ - в ИС, а важна именно связь - это и есть функция ИБ.
Понимая связь Риск БП <-> Уязвимость ИС, можно понять приоритет исправления уязвимостей. Какие-то уязвимости определяют возможность материлизации нескольких рисков БП, возможно, очень критичных, поэтому их стоит стремиться исправить в первую очередь.
Понимая связь Риск БП <-> Уязвимость ИС, можно понять приоритет исправления уязвимостей. Какие-то уязвимости определяют возможность материлизации нескольких рисков БП, возможно, очень критичных, поэтому их стоит стремиться исправить в первую очередь.
Уязвимости, приводящие к материализации меньшего количества или менее приоритетных рисков БП, можно исправлять позже.
Уязвимости, приводящие к материализации меньшего количества или менее приоритетных рисков БП, можно исправлять позже.
Вполне возможно, найдутся уязвимости, которые вовсе не надо исправлять: либо они не эксплуатируемы (https://dzen.ru/a/ZPxYaLZlbXaph-6P), либо их эксплуатация не ведет к материальному риску.
Вполне возможно, найдутся уязвимости, которые вовсе не надо исправлять: либо они не эксплуатируемы (https://dzen.ru/a/ZPxYaLZlbXaph-6P), либо их эксплуатация не ведет к материальному риску.
Этот слайд взят из презентации на CISO Forum 2014 года - https://reply-to-all.blogspot.com/2014/04/ciso-forum-2014.html. Здесь приведены 4 уровня развития самосознания подразделения ИБ на предприятии. Анализ защищенности применим только к последним трем: "Против ИТ" - когда ИБ еще не переросла ощущение "конфликта интересов с ИТ", так как толкаются задами на одном поле; "Сервис ИТ" - когда ИБ с ИТ "поделили поляну", как правило это разделение проходит посистемно: ИТ - занимается инфраструктурой и бизнес-системами, а ИБ занимается выделенными системами безопасности - IDS/IPS, DLP, сканеры уязвимостей, и т.п. + сбор логов и их анализ; "Сервис бизнеса" - когда ИБ перестает заниматься исключительно администрированием и использованием своих "штук", а ощущает себя бизнес-функцией и занимается как раз тем, что ведет к материализации бизнес-рисков.
Этот слайд взят из презентации на CISO Forum 2014 года - https://reply-to-all.blogspot.com/2014/04/ciso-forum-2014.html. Здесь приведены 4 уровня развития самосознания подразделения ИБ на предприятии. Анализ защищенности применим только к последним трем: "Против ИТ" - когда ИБ еще не переросла ощущение "конфликта интересов с ИТ", так как толкаются задами на одном поле; "Сервис ИТ" - когда ИБ с ИТ "поделили поляну", как правило это разделение проходит посистемно: ИТ - занимается инфраструктурой и бизнес-системами, а ИБ занимается выделенными системами безопасности - IDS/IPS, DLP, сканеры уязвимостей, и т.п. + сбор логов и их анализ; "Сервис бизнеса" - когда ИБ перестает заниматься исключительно администрированием и использованием своих "штук", а ощущает себя бизнес-функцией и занимается как раз тем, что ведет к материализации бизнес-рисков.
В зависимости от зрелости самосознания подразделения ИБ формируются и их требования на аудит. На более ранних стадиях, к сожалению, аудит проводят "чтобы отчитаться" или продемонстрировать, что у ИТ есть проблемы (этакая невидаль!) и этим отчитаться, или, опять же, отчитаться за выполнение требований каких-либо регуляторов. На следующем этапе ИБ уже имеет свои "штуки" и хочет увидеть как типовой взлом может быть замечен в их "штуках", чтобы потом такой взлом находить самостоятельно\быстрее\лучше\легче\тп. Ключевой момент, что здесь не ставится цель приоритезации уязвимостей от потенциального бизнес-ущерба - приоритет вычисляется от критичности уязвимости для ИС и простоты ее эксплуатации, например, просто реализуемый RCE будет всегда High/Critical, не смотря на то, что ущерба для какого-либо ИБ это не несет. На третьем, последнем этапе, явно заметна работа подразделения ИБ (помните красные пунктиры между синим небом и зеленым болотом?) , так как выявленные уязвимости поднимаются на уровень БП, приоритезация выявленных в ходе аудита уязвимостей производится в привязке к ущербу для БП.
В зависимости от зрелости самосознания подразделения ИБ формируются и их требования на аудит. На более ранних стадиях, к сожалению, аудит проводят "чтобы отчитаться" или продемонстрировать, что у ИТ есть проблемы (этакая невидаль!) и этим отчитаться, или, опять же, отчитаться за выполнение требований каких-либо регуляторов. На следующем этапе ИБ уже имеет свои "штуки" и хочет увидеть как типовой взлом может быть замечен в их "штуках", чтобы потом такой взлом находить самостоятельно\быстрее\лучше\легче\тп. Ключевой момент, что здесь не ставится цель приоритезации уязвимостей от потенциального бизнес-ущерба - приоритет вычисляется от критичности уязвимости для ИС и простоты ее эксплуатации, например, просто реализуемый RCE будет всегда High/Critical, не смотря на то, что ущерба для какого-либо ИБ это не несет. На третьем, последнем этапе, явно заметна работа подразделения ИБ (помните красные пунктиры между синим небом и зеленым болотом?) , так как выявленные уязвимости поднимаются на уровень БП, приоритезация выявленных в ходе аудита уязвимостей производится в привязке к ущербу для БП.
На последнем слайде я все сказанное ранее просто повторил кратко. Может создаться  ощущение, что подъем уязвимостей ИС на уровень рисков БП требует компетенций от внешнего аудитора, которых у него нет и быть не может (так как он едва ли хорошо осведомлен о БП и их рисках), однако здесь хорошо работают совместные команды из ИБ (они хорошо знают связи - пунктирные красные линии), Департамент внутреннего контроля и\или Внутренний аудит (они хорошо знаю бизнес-риски и что их материализует в ущерб). Их совместная работа может быть построена параллельно, когда корп ИБ динамически управляет ходом работы пентестеров, приоритезируя их в проработку "правильных" векторов, либо последовательно, когда пентестеры выдают свои уязвимости ИС, а ИБ поднимает их до уровня синего облака с бизнес-рисками.
На последнем слайде я все сказанное ранее просто повторил кратко. Может создаться ощущение, что подъем уязвимостей ИС на уровень рисков БП требует компетенций от внешнего аудитора, которых у него нет и быть не может (так как он едва ли хорошо осведомлен о БП и их рисках), однако здесь хорошо работают совместные команды из ИБ (они хорошо знают связи - пунктирные красные линии), Департамент внутреннего контроля и\или Внутренний аудит (они хорошо знаю бизнес-риски и что их материализует в ущерб). Их совместная работа может быть построена параллельно, когда корп ИБ динамически управляет ходом работы пентестеров, приоритезируя их в проработку "правильных" векторов, либо последовательно, когда пентестеры выдают свои уязвимости ИС, а ИБ поднимает их до уровня синего облака с бизнес-рисками.

Крайне важны последнее и первое предложения: нам очень важно понимать бизнес-процессы, и с Бизнесом нам надо общаться в терминах защиты бизнес-процессов - это будет нашим мостиком в Бизнес, повысит нашу прозрачность.