Под настроение решил наиграть вам своё любимое стихотворение Николая Гумилёва - Дочь Змия. А то давно музыкальных пауз не было. И в поддержание 4-го варианта в голосовании. 😉 Стихотворение, к слову, может быть и не Гумилёва вовсе, т.к. находится только в одном конспекте его лекций. Но хуже оно от этого, разумеется, не становится. Целый мир в 9 четверостишиях.
1. Мне кажется целеполагание "я делаю это для людей" хоть и имеет право на существование, но не особо эффективное и устойчивое, т.к. сводит процесс самовыражения в бесконечную погоню за расширением аудитории/лайками/подписками/репостами. Сам я как-то не размышляю о том, что будет лучше восприниматься аудиторией, текст или аудио/видео. Что хочу, то и делаю. В первую очередь для себя. 🙂
2. Для меня мои телеграмм-каналы и блог это прежде всего расшаренная записная книжка. Что-то показалось интересным - записал. Если вдруг понадобилось - нашёл и как-то использовал. Частенько приходят ко мне с каким-то вопросом, а я к краткому ответу добавляю "а вот у меня посты на эту тему были". Удобненько. То, что кто-то это читает и кому-то заходит, это безусловно приятное, но побочное явление.
3. Я вообще человек необщительный. Насколько я понимаю, некоторым людям нравится собираться, тусить, общаться, публично выступать и т.д. Они от этого заряд энергии получают. Вообще не моя тема. 🙂 Я на общение энергию только трачу, а потом в условной изоляции восстанавливаюсь. Поэтому энергию на общение я стараюсь экономить. Прожектор по ИБ в этом отношении идеален для меня. Созваниваюсь в онлайне на час и обсуждаю с интересными мне людьми интересные темы. Как побочный продукт получается видяшка, которой (после минимальной редактуры) можно поделиться. Т.е. у меня, как думаю и моих собеседников, основная мотивация приятно провести время в разговоре. А если это ещё и кто-то другой вдруг послушает и ему понравится, так вообще же отлично. Милости просим на наши посиделки. 🙂
4. Насколько я могу судить со стороны, КиберДуршлаг это более амбициозная активность. В этих разговорах с гостями-VMщиками, как мне кажется, нарабатывается общая база знаний российского Vulnerability Management-а, которая может быть затем осмыслена, переработана и использована в рамках множества интересных и полезных инициатив. Такие интервью это возможность вынести пласты скрытых знаний на поверхность, что, как мне кажется, было бы гораздо сложнее сделать в оффлайновой текстовой форме, без живой дискуссии и проговаривания. Так что очень жду этого подкаста в паблике. 🙂
Посмотрел подкаст двух Александров Герасимовых про Vulnerability Management. Больше контента по VM-у хорошего и разного! 👍 Сгруппировал для себя некоторые тезисы в части VM-а для инфраструктуры. По VM для приложений там тоже было, но мне это не так близко и я отметил, только то, что необходимо интегрировать SAST/DAST/SCA в процессы разработки и деплоя. И чтобы были security approver-ы. Не поспоришь.
По инфраструктуре:
1. Пока не выстроены базовые процессы, такие как инвентаризация активов, сегментация сети, patch management (регулярные обновления), заниматься Vulnerability Management-ом рановато. Нужно понимать какие есть активы, кто эти активы сопровождает, что эти активы из себя представляют (на уровне операционной системы и на уровне ПО), какие активы являются для организации критичными (Mission Critical, Business Critical, Office Productivity). В зависимости от этого настроить риски, недопустимые события, SLA по исправлению для типов активов и критичности уязвимостей, модель угроз ИБ.
2. Сканирования инфраструктуры недостаточно для VM-процесса. Безопасники должны выступать контролерами над уязвимостями: реагировать на критичные 0day уязвимости, отслеживать выполнение циклов регулярно патчинга со стороны IT. У актива должен быть функциональный администратор, бизнес-владелец и технический администратор. Накатывает патч технический администратор, через него идёт взаимодействие и он ответственен за патчинг. ИБ выступает как контроль и руками ничего не делает. Перед установкой патчи должны тестироваться, чтобы работа не нарушалась. При невозможности обновления используем компенсирующие меры (в т.ч. виртуальный патчинг).
3. VM на основе open source, какие могут быть проблемы? Сканеры имеют ограниченную пропускную способность, необходимо масштабировать сканеры и опредялять скоуп серверов, которые можно покрыть одним решением. Должен быть единый центр управления для разбора отчётов. Нужно понимать какие активы есть в организации и есть ли у нас средства детектирования под все типы активов (например, Oracle, российские ОС или сетевые устройства). От меня: основная часть VM-а это средства детектирования уязвимостей. Если вы уверены, что можете покрыть всю инфраструктуру адекватными детектами уязвимостей с помощью бесплатного средства - замечательно. Но постарайтесь это проверить, скорее всего обнаружите активы для анализа которых вам понадобится коммерческое решение.
4. Важно, чтобы VM-продукты имели возможности по интеграции. Для снижения риска утечек паролей из VM-решения, лучше организовывать доступ к кредам для безагентного сканирования через системы а-ля CyberArk. Для отслеживания выполнения заявок на исправление уязвимостей можно использовать интеграцию с SOAR и IRP системами.
Awillix делают периметровый сервис Continuous vulnerability monitoring (CVM), считают это очень востребованной темой. От меня: периметровые сервисы это очень конкурентная область. Со стороны клиента важно оценивать качество детектирования, хоть делать это, как правило, непросто.
