Завершая небольшую серию материалов о моделях компетенций в ИБ, нельзя не рассказать о самой молодой и компактной из них — ECSF, впервые представленной на 1-й конференции ENISA по кибернавыкам в сентябре 2022 года. ECSF обобщает роли, связанные с кибербезопасностью, в 12 профилей, которые с учётом обязанностей, взаимодействия и взаимозависимостей, обеспечивают единое понимание задач, навыков и знаний, и способствуют разработке программ обучения.

При всем уважении к недавно рассмотренной NIST NICE, в ней не хватает одного важного элемента — шкалы квалификации. NIST про нее не забыл, но в настоящее время уровни квалификации к компонентам TKS не привязаны. Документ с несколькими вариантами шкал был направлен в Конгресс, который по итогам рассмотрения решил, что в NICE должна быть шкала по образу и подобию уровней ответственности SFIA (Skills Framework for the Information Age), которая, как и NICE является моделью компетенций.

Давайте продолжим ход мысли недавней публикации про модели зрелости в области кибербезопасности. Допустим, провели мы оценку уровня своей защищенности по SAMM, CSF или другой модели, выбрали лучи-вектора для улучшения и целевые уровни. Ответ на вопрос «ЧТО мы строим?» у нас появился. А дальше? Вспоминая добрым словом архитектурных гуру — Джона Шервуда и его тезку-вдохновителя — Джона Закмана, когда-то задавших моду задавать (sic!) вопросы, понимаем, что нам не хватает понимания КТО у нас для этой стройки есть. И главное: КТО нам нужен, чтобы нашу «сказку сделать былью»? Под «КТО» я имею ввиду конкретных специалистов и руководителей с требуемым опытом, знаниями и умениями. И тут на сцену выходят модели компетенций.

Медленно, но верно компании движутся к кибербезопасности, основанной на оценке рисков. Этот подход признает, что в современном киберпространстве не все активы созданы равными и не могут быть одинаково защищены. Некоторые имеют исключительное значение для компании и ее бизнеса. Защита таких «бриллиантов короны» — основа эффективной стратегии защиты от киберугроз. Цифровая бизнес-модель, по сути, полностью зависит от доверия. Если взаимодействия с клиентами защищены слабо, то риск может стать существенным.

Open Web Application Security Project (OWASP) — одна из самых известных организаций, целью которой является улучшение защищённости приложений. Большинство специалистов в области информационной безопасности знакомы с OWASP Top Ten. У OWASP есть множество других проектов для различных этапов жизненного цикла разработки программного обеспечения (SDLC).

В предыдущей статье на Хабр я рассказывал о стандарте OWASP ASVS, в котором перечислены требования к безопасности web-приложений. А как убедиться в том, что эти требования выполняются? Ответ на этот вопрос даёт Web Security Testing Guide (WSTG) — Руководство по тестированию безопасности web-приложений, перевод которого я хотел бы представить вашему вниманию.

Говорят, обещанного три года ждут, но не прошло и двух, с появления первой части перевода, как я решил не ждать продолжения и перевести OWASP Application Security Verification Standard самостоятельно. В первой части помимо раздела об архитектуре было подробное введение, дающее представление о стандарте и его назначении. Всем, кто его читал, и тем, кто знаком с ASVS в оригинале, сразу даю ссылку на итоговый pdf и другие форматы, — возможно, вы откроете для себя что-то новое. Всем остальным предлагаю несколько слайдов в качестве быстрого погружения.