Руководители хотели бы видеть точные данные, но какие метрики действительно могут показать снижение риска? Многие организации фокусируются на количестве обнаруженных дефектов или на их критичности, но эти метрики не в состоянии привлечь внимание высшего руководства. Выбор метрик, которые имели бы значение как для IT, так и для высшего руководства вполне возможен. Оценка изменений в уровне риска в значительной степени может помочь руководству понять значение информационной безопасности. Это также может помочь IT-организации оправдать средства, вложенные в информационную безопасность.
Теория чисел
На протяжении веков метрики использовались для доказательства или опровержения теорий; в корпоративном мире наилучшими метриками зачастую являются ключевые показатели эффективности (key performance indicators, KPI). Но выявление полезных KPI может оказаться задачей не из легких. Например, метрики патчей могут включать время на разработку патча, область покрытия патча и долю отказов патча, ни одна из которых в действительности не демонстрирует, успешна ли эта стратегия. В безопасности веб-приложений ситуация аналогична: существует огромное количество различных типов метрик. Многие организации могут начать подсчитывать количество уязвимостей в приложении, потому что это самый легкий метод, но они быстро обнаружат, что это весьма неэффективный способ продемонстрировать руководству успехи своей работы. Здесь мы сфокусируемся на метриках рисков для оценки прогресса организации в обеспечении безопасности ее веб-приложений. Далее описаны пять KPI безопасности веб-приложений, методы их оценки и их значение для организации.
Окно исправления дефектов (Defect Remediation Window, DRW)
Определение: DRW определяет, насколько долго организация исправляет документированный, засвидетельствованный дефект. С помощью окна исправления дефектов оценивается ответная реакция организации, что может послужить отличным представлением организационной зрелости. Эту метрику не следует путать с окном незащищенности, которое показывает, как долго дефект существует «в диком виде», пока его исправят. Окно незащищенности намного сложнее оценить, и оно имеет меньшую ценность для организации.
Значение для организации: Эта метрика определяет ответную реакцию организации на дефекты безопасности веб-приложений. Она оценивает, насколько серьезно организация относится к безопасности и располагает ли она соответствующими ресурсами. Более зрелые организации должны быть способны сокращать DRW с течением времени.
Метод оценки: DRW лучше всего оценивать, используя систему формального отслеживания дефектов, которая может собирать данные о дефектах, такие как время обнаружения, время документирования, время повторного тестирования и время исправления. По мере созревания организации в плане подхода к безопасности ПО метрика DRW должна уменьшаться.
Показатель повторяемости дефектов (Rate of Defect Reccurence, RDR)
Определение: RDR — это показатель, в котором учитываются дефекты безопасности, ранее исправленные, но появившиеся повторно в том же месте и в той же манере в последующих релизах. Отмечу, что конкретная реализация дефекта значения не имеет. Например, если XSS, использующий некоторую символьную строку, удален из приложения, но заменен в последующей версии тем же дефектом, использующим немного измененную символьную строку, это считается повтором. Цель этой метрики — заставить разработчиков постоянно устранять ранее исправленные дефекты.
Значение для организации: RDR оценивает способность организации постоянно исправлять дефекты. Между тем, это не означает, что дефект, подобный исправленному, не возникнет в другом приложении или где-нибудь еще в том же коде в более поздней версии. RDR строится как функция от времени и должен, насколько это возможно, стремиться к нулю, все время уменьшаясь.
Метод оценки: RDR лучше всего оценивать, используя инструменты формального отслеживания дефектов с возможностью отслеживать конкретные их типы (SQL-инъекции, активные XSS) в конкретном месте кода во всех версиях приложения. RDR строится как количество повторяющихся дефектов приложения после каждого его релиза.
Метрика реального покрытия (Specific Coverage Metric, SCM)
Определение: SCM наиболее полно отвечает на вопрос «Какая часть приложения протестирована на безопасность?» Эта метрика измеряет отношение числа протестированных компонентов к общему числу компонентов в рассматриваемом приложении. Отмечу, что SCM относится к компонентам, рассматриваемым в данный момент, и нет необходимости брать в расчет всё приложение.
Значение для организации: Измерение SCM количественно характеризует покрытие тестирования безопасности, сообщая, полностью ли было протестировано приложение или только частично. Если оно было протестировано частично, SCM предоставляет информацию, какие потоки или компоненты были пропущены и, что более важно, почему они были пропущены. Прямое обоснование тестового покрытия придает безопасникам больше убедительности. Сами безопасники при этом убеждаются, что их действия приводят к созданию приложений с более высоким уровнем безопасности.
Метод оценки: SCM — это процентное отношение компонентов приложения, охваченных тестированием безопасности, к общему числу тестируемых компонентов. Общее число тестируемых компонентов берется из спецификаций. Организации функционального тестирования обычно предоставляют эту метрику командам тестировщиков безопасности.
Отношение «безопасность-качество» (Security to Quality defect Ratio, SQR)
Определение: SQR — это отношение числа дефектов безопасности к общему числу дефектов, обнаруженных в процессе тестирования. Оно количественно характеризует влияние дефектов безопасности на приложение. Эту метрику лучше всего представлять дробью «Дефекты безопасности/Дефекты качества».
Значение для организации: SQR может помочь принять решение о выпуске релиза приложения, основываясь на его безопасности. Кроме того, эту метрику можно сравнивать с другими метриками, чтобы понять, в каком направлении следует развиваться.
Метод оценки: SQR лучше всего оценивать, используя инструменты тестирования качества и безопасности.
Весовая характеристика риска (Weighted Risk Trend, WRT)
Определение: Вместо простого подсчета количества уязвимостей, найденных в каждом приложении, WRT показывает степень риска, связанного с ними. Если программа безопасности приложений работает должным образом, эта метрика должна с течением времени уменьшаться. WRT применяет применяет две весовых оценки: основанную на уровне риска приложения и основанную на критичности каждой уязвимости, найденной в приложении. Уровень риска приложения определяется на основании следующих факторов:
- является ли оно приложением для внутреннего пользования;
- обрабатывает ли оно конфиденциальные данные.
Значение для организации: WRT позволяет количественно охарактеризовывать риск безопасности приложения в течение всего процесса разработки. Она позволяет определить, как должны быть распределены ресурсы, чтобы уменьшить наибольшие риски безопасности, и может быть использована для оценки эффективности новых программ, инициатив или затрат. Эта метрика с течением времени должна уменьшаться.
Метод оценки: WRT — это график функции количественно оцененного риска от времени. У каждой организации формула этой функции может выглядеть по-разному. Неплохим примером может послужить следующая формула:
где 
— оценка риска, W — значимость приложения, C — критичность дефекта, N — количество дефектов, i — класс критичности дефекта (0 — Низкий, 1 — Средний, 2 — Высокий, 3 — Критический).
Пример:
Значимость приложения (0-1.0): 0.75
Баллы, соответствующие степени критичности дефекта: Критический — 10, Высокий — 5, Средний — 3, Низкий — 1
Обнаружено дефектов: Критический — 10, Высокий — 7, Средний — 30, Низкий — 39 
По материалам статьи Рафала Лоса «Measure by measure», Infosecurity Professional #11.
Спасибо! Мы проверили свою организацию, получилось 123,7666
Это хорошо?
Метрика WRT не показывает абсолютный уровень риска. Важно то, что, когда вы в следующий раз проведете оценку, эта метрика должна получиться меньше. Если не получится, то, вероятно, у вас какие-то проблемы.