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

На что похожа работа специалиста по Управлению Уязвимостями?
Я думал сначала, что на работу врача. Но к врачу обычно приходят с какими-то жалобами. К VM-щику никто сам не пойдёт. 🙂
Потом понял. Работа VM-щика близка работе инспектора из государственного органа надзора (пожарный, санитарно-эпидемиологический, строительный и т.д.).
Судите сами:
🔹 Его приходу не рады.
🔹 Все считают, что он пришёл, чтобы навязывать какие-то дурацкие надуманные требования и мешать людям нормально работать.
🔹 В его компетенции сомневаются (иногда оправдано - не всегда тривиально натянуть общие требования безопасности на монстра, которого в организации наворотили 🤯).
🔹 К опасностям, о которых он рассказывает, относятся со скепсисом, в святой уверенности, что они, конечно же, никогда не реализуются. 😏
🔹 То, что в соседней организации эти опасности реализовались и привели к недопустимым последствиям никого особо не впечатляет - у нас-то не совсем так, у нас-то ситуация чуть другая.
🔹 Его требования стараются саботировать всеми возможными способами или выполнять в наименьшем объеме.
🔹 Когда опасность реализуется, крайним становится проверяющий - куда ж он нерадивый смотрел, ату его, под суд его!
🔹 А у остальных лапки, мы же не специалисты, мы ничего не понимали. 😏
Но есть и несколько важных различий:
🔸 Работодателем инспектора является государство и у него есть власть прекратить деятельность организации к чёртовой бабушке, если требования не будут выполнены. VM-щику платит сама организация и поэтому VM-щик может только заявление на стол положить в знак протеста. 🤷♂️ Так, что инструментарий у него в основном "словесные интервенции".
🔸 Инспектор фокусируется на определенной узкой теме. У VM-щика спектр нежелательных воздействий, которые он должен учитывать, хоть и ограничен областью ИБ, но всё равно очень широк. Примерно, как если бы один инспектор оценивал возможные воздействия начиная от пожаров, наводнений, эпидемий, вооруженных налетов бандитов, заканчивая вторжением инопланетян.
🔸 Инспектор выполнил проверки и ушёл другую организацию проверять. VM-щик окучивает одну организацию глубоко, постоянно и непрерывно.
🔸 Инспектору вряд ли могут сказать "покажи, что у нас самого плохого и там мы, так уж и быть, поправим, а для остальных мест обоснуй сам почему там исправлять не нужно, ты же профессионал; а везде мы исправить не можем - у нас таких ресурсов нет". 🙂
🔸 К счастью, и уязвимости ИБ реже приводят к реальным человеческим жертвам. Во всяком случае пока.
Сравнение, конечно, грубое и скорее юмористическое, но основной вайб VM-а, как мне кажется, передаёт. 😉


На днях прошла новость об RCE уязвимости в FortiOS и FortiProxy (CVE-2023-42789). Она "позволяет злоумышленнику выполнять несанкционированный код или команды с помощью специально созданных HTTP-запросов". Уязвимость эксплуатируется в captive portal, который, по идее, не должен быть доступен из Интернет. Поэтому в бюллетене Fortinet пишут про "inside attacker". Признаков эксплуатации вживую пока нет. Вендор отмечает, что уязвимость найдена исследователями Fortinet Product Security Team.
На GitHub есть репозиторий якобы с PoC-ом, но достоверность его сомнительная. Выложенный код только реализует проверку доступности портала, пейлоада там нет. Репозиторий создал пользователь без какой-либо репутации и предыдущей активности. Полный код эксплоита он предлагает приобрести за ~$262. Выглядит это как скам, но если вдруг это действительно рабочий эксплоит, то вполне вероятно, что он быстро утечет в паблик.
В любом случае стоит обновляться/импортозамещаться.
Что я планирую на второй день SafeCode.
🔹 Досмотреть 2 доклада, которые я в первый день не успел посмотреть: про рекон и уязвимости мобильных приложений.
🔹 Посмотреть 2 доклада, которые изначально намечал: про архивы уязвимостей и про своё решение для безопасности контейнерных сред.
🔹 Посмотреть, что новенького в сканилке образов Яндекса и панельку с Андреем Масаловичем. 🙂
Планирую просмотренное также описывать в постах, но скорее растяну это на несколько дней, а то и недель. Доклады на конфах это хорошо, но уж больно много всего происходит сейчас по части критичных уязвимостей. 😇
Послушал доклад Татьяны Куцовол (ГК «Солар») про безопасность Supply Chain на SafeCode и сделал небольшой конспект.
❓SCA и Supply Chain - в чём разница?
🔹 Software Composition Analysis (SCA) - выявление и исправление известных уязвимостей (CVE)
🔹 Supply Chain - текущих проблем нет, но в будущем с кодом могут быть проблемы
📔 Стандарты
🔸 SLSA (Supply-chain Levels for Software Artifacts). 4 уровня. В основном про билды. 🫤
🔸 OWASP SCVS (Software Component Verification Standard). 6 кратких контролей. 😒
🔸 CIS SSCSG (Software Supply Chain Security Guide). 100 рекомендаций в 5 категориях. 👍
😡 Техники злодеев
🔻 Хактивизм и создание токсичных репозиториев
🔻 Starjacking
🔻 Typosquatting
🔻 Dependency Confusion
🔻 Become Maintainer
📊 Метрики для оценки опенсурсных проектов
➕ Популярность
➕ Авторский состав
➕ Активность сообщества
➕ Заинтересованность в безопасности (есть )
➖ Библиотека создана недавно
➖ Первая версия подозрительно высокая
Антон Жаболенко (CISO Wildberries) рассказывает про комплексный Continuous Vulnerability Management в сессии "Как устроена безопасность в технологически зрелой компании?" на SafeCode.
Процесс включает в себя:
🔸 различные сканирования уязвимостей (как из Интернета, так и из внутренней сети)
🔸 внутренний RedTeam
🔸 пентесты (внешние подрядчики)
🔸 RedTeam (внешние подрядчики)
🔸 внутренние аудиты
🔸 публичное bug bounty
Это источники, которые генерят поток продетектированных проблем компании, чтобы Defense команда могла итеративно и циклично эти проблемы исправлять.
Такой подход применяется преимущественно в технологически зрелых компаниях, потому что он
🔻 дорогой
🔻 сложный
🔻 тяжело найти экспертов для выстраивания
Но только таким образом можно смотреть комплексно на проблемы, которые есть в компании с точки зрения ИБ.
Если использовать одну команду исследователей (подрядчиков или in-house), у неё неизбежно будет "замыливаться глаз".
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.