Что делать VM-щику, чтобы быть эффективным? Исходя из того, что он должен выполнять в организации роль инспектора без каких-либо реальных полномочий, а коллеги из IT в основном считают, что он творит дичь. 🤔
🔻 1. Досконально знать требования и рекомендации регуляторов в части управления уязвимостями. Парадоксально, но именно это самый надёжный инструмент VM-щика и самый недооцененный. 😏 Вряд ли в организации кто-то будет разбираться в этом лучше. Кроме, возможно, методологов ИБ, но они естественные союзники и с ними проблем обычно не бывает. Конечно, не стоит постоянно потрясать выписками из регуляторики и грозить неизбежными карами. Это глупо, а главное вызывает привыкание и уменьшает эффект. Ну либо наоборот приводит к тому, что коллеги из IT начинают осознавать степень своей реальной ответственности в случае инцидента и бегут массово увольняться, чего тоже хотелось бы избежать. 😉 Поэтому лучше приберегать такие аргументы на случай серьезного конфликта. Чтобы, когда договориться по-хорошему не получается, эффектно и адресно бахнуть из всех стволов. Понимание, что такие железобетонные аргументы есть и они заранее заготовлены, даёт опору и уверенность. Это даже в качестве аутотренинга неплохо работает. "- Кто ты? — Vulnerability Management специалист. — Что ты здесь делаешь? — Внедряю в организации Vulnerability Management процесс согласно лучшим практикам, рекомендациям и требованиям регуляторов в целях повышения уровня защищенности организации."
🔻 2. Разбираться в уязвимостях, инструментах детектирования и эксплуатации. Этот пункт как раз ожидаем. 🙃 Раз VM-щик, то значит должен разбираться в "vulnerability", очевидно. Но тут важно делать акценты: а для чего? Для того чтобы самому находить цепочки атак и демонстрировать реальную эксплуатабельность уязвимостей инфраструктуры? Так это задача внутреннего пентеста/redteam‑а. Для того чтобы эффективней убеждать админов? Возможно иногда и имеет смысл, но главное не скатиться в "докажи-покажи" и исправление только тех уязвимостей, которые получается эффектно продемонстрировать. Для того чтобы детектировать все уязвимости, лучше их приоритизировать и выделять те, которые представляют наибольшую опасность для организации? Вот это пожалуй самое главное. Не теряем фокус на том, что мы здесь для того, чтобы внедрять работающий процесс детектирования и исправления уязвимостей, а остальное вторично (ещё раз см. п.1).
🔻 3. Стараться творить поменьше дичи. 🙂 Это значит, что для того, чтобы эффективно коммуницировать с админами, девопсами, разработчиками нужно и самому иметь сопоставимую квалификацию. Иначе требования сделать харденинг или установить обновления будут парироваться простым раздражённым "это невозможно сделать, у нас всё сломается". 😱 Возможно с добавлением какой-то тарабарщины из незнакомых терминов. Задача VM-щика понимать предметную область настолько, чтобы отличать, когда тебе вешают лапшу на уши, а когда за этим реально что-то есть. То есть самому быть в какой-то степени админом/девопсом/разрабом, но с расширенными знаниями в области уязвимостей систем и ИБ вообще. 😉