Архив метки: VMprocess

Вышел номер журнала InformationSecurity со спецпроектом по Управлению Уязвимостями

Вышел номер журнала InformationSecurity со спецпроектом по Управлению Уязвимостями

Вышел номер журнала InformationSecurity со спецпроектом по Управлению Уязвимостями. Я сам в нём участия не принимал, но постараюсь на досуге почитать и покомментировать. Темы выглядят очень занимательно. 🙂

🔹 Павел Попов. Управление уязвимостями в новых реалиях: что изменилось и как перестроить процесс
🔹 Андрей Селиванов. Приоритизация – ключ к эффективному управлению уязвимостями организаций в условиях большого количества активов
🔹 Сергей Уздемир. Управление уязвимостями: ожидание, реальность, рекомендации
🔹 Александр Дорофеев. Подходы к поиску уязвимостей: хороший, плохой, злой
🔹 Владимир Тележников. Управление уязвимостями при разработке ОС Astra Linux
🔹 Владимир Михайлов. Современные технологии в решениях для управления уязвимостями
🔹 Ольга Гурулева. Главное, чтобы исследователь не ушел от нас с негативной реакцией
🔹 Андрей Макаренко. Управление уязвимостями с помощью ИИ
🔹 Любовь Ермилова. Управляем поверхностью атаки: лучшие практики и подводные камни
🔹 Николай Степанов. Attack Surface Management: с чего начинать управление уязвимостями
🔹 Александр Подобных. Управление уязвимостями в криптокошельках

🔸 Таблица российских решений класса Vulnerability Management
🔸 Эволюция систем управления уязвимостями. Круглый стол.

Что делать VM-щику, чтобы быть эффективным?

Что делать VM-щику, чтобы быть эффективным?

Что делать VM-щику, чтобы быть эффективным? Исходя из того, что он должен выполнять в организации роль инспектора без каких-либо реальных полномочий, а коллеги из IT в основном считают, что он творит дичь. 🤔

🔻 1. Досконально знать требования и рекомендации регуляторов в части управления уязвимостями. Парадоксально, но именно это самый надёжный инструмент VM-щика и самый недооцененный. 😏 Вряд ли в организации кто-то будет разбираться в этом лучше. Кроме, возможно, методологов ИБ, но они естественные союзники и с ними проблем обычно не бывает. Конечно, не стоит постоянно потрясать выписками из регуляторики и грозить неизбежными карами. Это глупо, а главное вызывает привыкание и уменьшает эффект. Ну либо наоборот приводит к тому, что коллеги из IT начинают осознавать степень своей реальной ответственности в случае инцидента и бегут массово увольняться, чего тоже хотелось бы избежать. 😉 Поэтому лучше приберегать такие аргументы на случай серьезного конфликта. Чтобы, когда договориться по-хорошему не получается, эффектно и адресно бахнуть из всех стволов. Понимание, что такие железобетонные аргументы есть и они заранее заготовлены, даёт опору и уверенность. Это даже в качестве аутотренинга неплохо работает. "- Кто ты? - Vulnerability Management специалист. - Что ты здесь делаешь? - Внедряю в организации Vulnerability Management процесс согласно лучшим практикам, рекомендациям и требованиям регуляторов в целях повышения уровня защищенности организации."

🔻 2. Разбираться в уязвимостях, инструментах детектирования и эксплуатации. Этот пункт как раз ожидаем. 🙃 Раз VM-щик, то значит должен разбираться в "vulnerability", очевидно. Но тут важно делать акценты: а для чего? Для того чтобы самому находить цепочки атак и демонстрировать реальную эксплуатабельность уязвимостей инфраструктуры? Так это задача внутреннего пентеста/redteam-а. Для того чтобы эффективней убеждать админов? Возможно иногда и имеет смысл, но главное не скатиться в "докажи-покажи" и исправление только тех уязвимостей, которые получается эффектно продемонстрировать. Для того чтобы детектировать все уязвимости, лучше их приоритизировать и выделять те, которые представляют наибольшую опасность для организации? Вот это пожалуй самое главное. Не теряем фокус на том, что мы здесь для того, чтобы внедрять работающий процесс детектирования и исправления уязвимостей, а остальное вторично (ещё раз см. п.1).

🔻 3. Стараться творить поменьше дичи. 🙂 Это значит, что для того, чтобы эффективно коммуницировать с админами, девопсами, разработчиками нужно и самому иметь сопоставимую квалификацию. Иначе требования сделать харденинг или установить обновления будут парироваться простым раздражённым "это невозможно сделать, у нас всё сломается". 😱 Возможно с добавлением какой-то тарабарщины из незнакомых терминов. Задача VM-щика понимать предметную область настолько, чтобы отличать, когда тебе вешают лапшу на уши, а когда за этим реально что-то есть. То есть самому быть в какой-то степени админом/девопсом/разрабом, но с расширенными знаниями в области уязвимостей систем и ИБ вообще. 😉

Скинули мою лекцию по VM-у распознанную нейронкой: довольно забавные каламбуры выдаёт, ошибаясь в терминах

Скинули мою лекцию по VM-у распознанную нейронкой: довольно забавные каламбуры выдаёт, ошибаясь в терминах

Скинули мою лекцию по VM-у распознанную нейронкой: довольно забавные каламбуры выдаёт, ошибаясь в терминах. 😆

🔸 4 место. "СПЕшки" вместо "CPE-шки"
🔸 3 место: "в лабиринте Management" вместо "Vulnerability Management"
🔸 2 место: "CISO Non-Exploited Vulnerability Catalog" вместо "CISA Known Exploited Vulnerabilities Catalog"
🔸 1 место: "BDOF-стек" вместо "БДУ ФСТЭК".

Коммент к предыдущему посту, который подтверждает, что отношение к нашему брату VM-щику со стороны коллег из IT, как правило, не очень

Коммент к предыдущему посту, который подтверждает, что отношение к нашему брату VM-щику со стороны коллег из IT, как правило, не очень

Коммент к предыдущему посту, который подтверждает, что отношение к нашему брату VM-щику со стороны коллег из IT, как правило, не очень. 🤷‍♂️😅 У всех своя правда.

На что похожа работа специалиста по Управлению Уязвимостями?

На что похожа работа специалиста по Управлению Уязвимостями?

На что похожа работа специалиста по Управлению Уязвимостями?

Я думал сначала, что на работу врача. Но к врачу обычно приходят с какими-то жалобами. К VM-щику никто сам не пойдёт. 🙂

Потом понял. Работа VM-щика близка работе инспектора из государственного органа надзора (пожарный, санитарно-эпидемиологический, строительный и т.д.).

Судите сами:

🔹 Его приходу не рады.
🔹 Все считают, что он пришёл, чтобы навязывать какие-то дурацкие надуманные требования и мешать людям нормально работать.
🔹 В его компетенции сомневаются (иногда оправдано - не всегда тривиально натянуть общие требования безопасности на монстра, которого в организации наворотили 🤯).
🔹 К опасностям, о которых он рассказывает, относятся со скепсисом, в святой уверенности, что они, конечно же, никогда не реализуются. 😏
🔹 То, что в соседней организации эти опасности реализовались и привели к недопустимым последствиям никого особо не впечатляет - у нас-то не совсем так, у нас-то ситуация чуть другая.
🔹 Его требования стараются саботировать всеми возможными способами или выполнять в наименьшем объеме.
🔹 Когда опасность реализуется, крайним становится проверяющий - куда ж он нерадивый смотрел, ату его, под суд его!
🔹 А у остальных лапки, мы же не специалисты, мы ничего не понимали. 😏

Но есть и несколько важных различий:

🔸 Работодателем инспектора является государство и у него есть власть прекратить деятельность организации к чёртовой бабушке, если требования не будут выполнены. VM-щику платит сама организация и поэтому VM-щик может только заявление на стол положить в знак протеста. 🤷‍♂️ Так, что инструментарий у него в основном "словесные интервенции".
🔸 Инспектор фокусируется на определенной узкой теме. У VM-щика спектр нежелательных воздействий, которые он должен учитывать, хоть и ограничен областью ИБ, но всё равно очень широк. Примерно, как если бы один инспектор оценивал возможные воздействия начиная от пожаров, наводнений, эпидемий, вооруженных налетов бандитов, заканчивая вторжением инопланетян.
🔸 Инспектор выполнил проверки и ушёл другую организацию проверять. VM-щик окучивает одну организацию глубоко, постоянно и непрерывно.
🔸 Инспектору вряд ли могут сказать "покажи, что у нас самого плохого и там мы, так уж и быть, поправим, а для остальных мест обоснуй сам почему там исправлять не нужно, ты же профессионал; а везде мы исправить не можем - у нас таких ресурсов нет". 🙂
🔸 К счастью, и уязвимости ИБ реже приводят к реальным человеческим жертвам. Во всяком случае пока.

Сравнение, конечно, грубое и скорее юмористическое, но основной вайб VM-а, как мне кажется, передаёт. 😉

Наверняка старая шутка, но я раньше не слышал

Наверняка старая шутка, но я раньше не слышал

Наверняка старая шутка, но я раньше не слышал. Единственный безопасник в организации как агент 007:
🔸 0 сотрудников,
🔸 0 бюджета на инструменты безопасности,
🔸 7 инцидентов в неделю.

Алексей Федулаев на SafeCode сегодня рассказал. 🙂
Жиза. 😅

Антон Жаболенко (CISO Wildberries) рассказывает про комплексный Continuous Vulnerability Management в сессии "Как устроена безопасность в технологически зрелой компании?" на SafeCode

Антон Жаболенко (CISO Wildberries) рассказывает про комплексный Continuous Vulnerability Management в сессии Как устроена безопасность в технологически зрелой компании? на SafeCode

Антон Жаболенко (CISO Wildberries) рассказывает про комплексный Continuous Vulnerability Management в сессии "Как устроена безопасность в технологически зрелой компании?" на SafeCode.

Процесс включает в себя:

🔸 различные сканирования уязвимостей (как из Интернета, так и из внутренней сети)
🔸 внутренний RedTeam
🔸 пентесты (внешние подрядчики)
🔸 RedTeam (внешние подрядчики)
🔸 внутренние аудиты
🔸 публичное bug bounty

Это источники, которые генерят поток продетектированных проблем компании, чтобы Defense команда могла итеративно и циклично эти проблемы исправлять.

Такой подход применяется преимущественно в технологически зрелых компаниях, потому что он

🔻 дорогой
🔻 сложный
🔻 тяжело найти экспертов для выстраивания

Но только таким образом можно смотреть комплексно на проблемы, которые есть в компании с точки зрения ИБ.

Если использовать одну команду исследователей (подрядчиков или in-house), у неё неизбежно будет "замыливаться глаз".