Как оценить эффективность WAF и зачем вообще это все нужно? Часть 2
Часть 2. Одно дело про WAF говорить — другое дело WAF считать!
Все эти риски и возможность их реализации, а также необходимость защитных инструментов понятны тем, кто занимается информационной безопасностью и IT, но нужно же идею донести и до тех у кого финансы и бюджеты. А вот это, зачастую, нетривиальная задача. Первый шаг — провести анализ опубликованных приложений, планируемых к защите относительно классической свойств информации и совместно с бизнесом ответить на следующий вопросы:
Что будет, если анализируемое приложение не будет работать несколько часов? (Нарушение доступности)
Что будет, если данные, содержащиеся в приложении «утекут»? (Нарушение конфиденциальности)
Что будет, если приложение подвергнется дефейсу? (Нарушение целостности)
Что будет, если в результате атаки, будут, например, «сломаны» интеграции со смежными системами, например управления складскими запасами и тд? (Нарушение доступности)
Получается, что WAF хоть и является средством защиты информации, однако плотно связан с инфраструктурной частью функциями балансировки уровня L3, L4, а также DNS-балансировкой. А если учитывать IaC, место и роль защиты приложений вырастает кратно. Вот все эти описанные риски нарушения свойств информации можно перевести в материальные затраты.
Ориентировочная формула (в каждой отрасли могут добавляться или убираться определенные компоненты) для расчета затрат выглядит следующим образом:
Где ПНП — прямая недополученная прибыль, АО — амортизация оборудования (транспорт, станки, аренда помещений), НК — неустойки контрагентам, ПП — простой персонала, Ш — штрафы от регулятора, О — потенциальный отток покупателей/контрагентов.
Предположим, один час простоя интернет-магазина приводит к недополученной прибыли 500 тыс. рублей, а утечка данных клиентов приведет к их оттоку и снижению прибыли на 1 млн в год. Таким образом, простой интернет-магазина длительностью три часа (а по практике, это может длиться дольше), сопряженный с утечкой данных, приведет к ущербу 2,5 млн. При этом, атака на сайт может повторяться с достаточной регулярностью и по разным векторам.
Можно считать со средней вероятностью 3-х кратное повторение атаки в разных исполнениях за год, а 1 атаку с высокой вероятностью успеха. Таким образом вероятный ущерб можно верхнеуровнего оценить по такой формуле: 2,5+2,5×3\2. Это и будет пороговым значением бюджета для решения по защите такого веб-ресурса.
Теперь, когда мы определились в каких границах должен быть бюджет, нужно разобраться в вариантах поставки и внедрения. Не будет сюрпризом, что каждый из них имеет свои плюсы и минусы:
— on-premise, когда WAF внедряется внутри условного периметра компании. Главный плюс, определяемый заказчиками — управление собственными силами, минимизация вероятности атаки через цепочку поставщиков. Минусы — необходимость обучения и удержания персонала, отсутствие достаточной экспертизы, затраты на мощности для развертывания решения.
— MSSP, когда WAF находится в облаке и предоставляется в «аренду» сторонним провайдером, им же и управляется. Основные плюсы — соблюдение SLA, наличие экспертизы, возможность увеличения мощностей в случае необходимости. Минусы — отсутствие вовлеченности в процесс защиты приложений, возможность атаки через цепочку поставщиков, заказчик не контролирует процесс настройки политик, необходимость предоставления SSL-сертификатов провайдеру для расшифровки трафика.
— SECaaS, подобен MSSP, но управление производится компанией-заказчиком. Плюсы — отсутствие капитальных затрат, управление производится своими силами, есть возможность получить поддержку от производителя в сложной ситуации. Минусы здесь условные — зависимость управляемости решения от функционирования облачных мощностей производителя.
Померить веса этих потребностей можно по методике, которую когда-то делал для сравнений SIEM.
А для того, чтобы можно было эти показатели приблизить к понятиям операционных (OPEX) и капитальных затрат (CAPEX) ниже небольшая таблица.
Таблица. Сравнение вариантов внедрения WAF
Параметр | On-premise | MSSP | SECaaS |
Прямые затраты | Капитальные затраты (CAPEX) на покупку ПАК или ПО и серверов, аренда серверных мощности, серверные подписки, ФОТ сотрудников | Сервисные подписки + аренда СЗИ (OPEX) | Сервисные подписки + аренда СЗИ, ФОТ сотрудников (OPEX) |
Косвенные затраты | Затраты на электроэнергию | Отсутствуют | В зависимости от формы размещения — отсутствуют или включают в себя затраты на электроэнергию |
Профильные трудозатраты при сопровождении | Настройка оборудования, устранение false positive, установка обновлений, обучение сотрудников, выявление и реагирование на инциденты | Отсутствуют | Настройка оборудования, устранение false positive, установка обновлений, обучение сотрудников, выявление и реагирование на инциденты |
Скорость внедрения | Несколько месяцев (с учетом поставки оборудования, первичной настройки) | От 2 недель | От 2 недель |
Настройка политик | Собственными силами | Силами провайдера | Собственными силами |
Техническое обслуживание | Собственными силами | Силами провайдера | Силами провайдера или собственными силами |
SLA | В соответствии с внутренними документами. Отсутствует возможность воздействия на сотрудников — взыскание за невыполнение SLA снижает их вовлеченность | В соответствии с договором на обслуживание. Возможность воздействия на провайдера через договор на обслуживание и SLA | В соответствии с договором или внутренними документами. Взыскание за невыполнение SLA снижает вовлеченность сотрудников. |
Знание инфраструктуры, скорость реагирования | Знание инфраструктуры и ответственных сотрудников, возможность быстрого реагирования в случае необходимости. | Незнание особенностей инфраструктуры, реагирование в рамках SLA. | Знание инфраструктуры и ответственных сотрудников, возможность быстрого реагирования в случае необходимости. |
Возможность атаки типа supply chain | Нет | Да | Да |
Возможность оперативного увеличения ресурсов при их полной утилизации или необходимости кластеризации | Нет | Да | Да |
Интеграция с другими средствами ИБ | Легко, с использованием API и коннекторов | Сложно, т.к. не все провайдеры готовы обеспечивать соответствующие интеграции и их защиту, особенно если необходима интеграция с другим MSSP | Легко, с использованием API и коннекторов |
Выбор формы затрат (CAPEX — капительные затраты или OPEX — операционные затраты) зависит от политики компании, которая планирует внедрять WAF, т.к. обе формы затрат имеют свои преимущества и недостатки, и итоговое решение зависит в основном от системы финансового планирования компании. К примеру, если вы в бюджетном учреждении — то рост операционных затрат — это почти всегда особо контролируемая статья, а для растущих компаний капитальные затраты могут стать сигналом об инвестициях и росту стоимости компании. В общем тут нужно понимать именно внутри, как правильно, как удобно и как принято.
Все об API Security, Web Security. Еще немного про уязвимости и технические изыскания команды Вебмониторэкс. Никакой рекламы. Только полезные материалы. https://t.me/WMXWAS
