Наиграл стихотворение Алексея Апухтина "Три мудрых царя из полуденных стран"

Наиграл стихотворение Алексея Апухтина "Три мудрых царя из полуденных стран". Которое является практически дословным переводом стихотворения Генриха Гейне "Die heil’gen drei Könige aus Morgenland".

С наступающим Рождеством всех, кто празднует 25 декабря! 🎄🎅 Если что, сам я праздную и 25 декабря, и 7 января, и между. 🙂

Прожектор по ИБ, выпуск №17 (23.12.2023): Слово пацана или стих от Mr

Прожектор по ИБ, выпуск №17 (23.12.2023): Слово пацана или стих от Mr. X

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"

Перебрались для записи эпизода с ТГ на платформу VK Звонки. По-моему вполне удачно. В первый раз выходим в 1080p! 🙂 Это последний эпизод в этом году, следующий выпуск планируем записать уже в январе.

00:00 Здороваемся и смотрим статистику по предыдущему эпизоду
02:20 Злоумышленники получили доступ к корпоративным системам компании MongoDB
05:35 Декабрьский Linux Patch Wednesday
10:04 ФСТЭК России 50 лет
12:32 CISA BOD 23-01 и аналогичные инициативы отечественных регуляторов
20:41 Презентация POCA Мобайл и Р-ФОН
26:29 Ежегодная предновогодняя Поибешечка
32:12 Хакер, который участвовал во взломе Rockstar Games, останется в закрытой клинике до конца жизни
37:32 Сериал "Слово пацана"
40:27 Производитель косметики EOS выпустил кодовый замок для своего лосьона, чтобы мужчины не могли пользоваться им
44:56 Правительство займётся безопасностью видеоигр
48:22 Запрет на использование телeфонов в школе
51:22 В Санкт-Петербурге проведены аресты по делу о телефонном мошенничестве
53:20 Так совпало - Гарвард и ГРЧЦ Роскомнадзора поделились своими взглядами на развитие ИИ в 2024-м году
59:24 DevSecOps Maturity Model 2023
1:01:25 Прощание в стихах от Mr. X

Декабрьский Linux Patch Wednesday

Декабрьский Linux Patch WednesdayДекабрьский Linux Patch WednesdayДекабрьский Linux Patch WednesdayДекабрьский Linux Patch WednesdayДекабрьский Linux Patch WednesdayДекабрьский Linux Patch WednesdayДекабрьский Linux Patch Wednesday

Декабрьский Linux Patch Wednesday. Вчера была третья среда месяца, поэтому смотрим на уязвимости Linux. Основная беда прошлого месяца с непродетектированными продуктами практически решена. 🎉 Я реализовал детекты по сокращённому CPE-идентификатору (тип:вендор:продукт) в Vulristics. Смотрю как оптимальнее совместить детекты по CPE и по текстовому описанию, но уже гораздо информативнее. 🙂

Всего 158 уязвимостей. Только для 16 уязвимостей не определился продукт, из них 11 это пустые заглушки-кандидаты.

В топе:

🔻 RCE - Perl (CVE-2022-48522). Есть ссылка на NVD типа Exploit. CVSS 9.8.
🔻 RCE - Safari (CVE-2023-42917). В CISA KEV.
🔻 Memory Corruption - Chromium (CVE-2023-6345). В CISA KEV, Skia.
🔻 RCE - Redis (CVE-2022-24834). Эксплоит на гитхабе.
🔻 Memory Corruption - Safari (CVE-2023-42916). В CISA KEV.

Всего 29 уязвимостей с потенциальными эксплоитами. В основном это ссылки из NVD типа "Exploit", относиться к ним следует с долей скепсиса.

🗒 Vulristics report

Про резюме для ИБшника (и не только)

Про резюме для ИБшника (и не только)

Про резюме для ИБшника (и не только). У Алексея Лукацкого вышел интересный блогопост про описание опыта в резюме в терминах результата. Накину ещё своих мыслей по этому поводу.

🔹 Какое-то резюме / CV должно у вас быть. Желательно хорошее.
🔹 Хорошее резюме нужно для того, чтобы рассказать работодателю, который о вас вообще ничего не знает, что вы отличный кандидат для этой позиции и что ему следует пригласить вас на первый собес. Остальное зависит от результата собесов.
🔹 Если работодатель о вас ничего не знает - это, в принципе, фейл. Как так-то? Вы такой классный специалист и никто не в курсе? Недоработочка. 😉 Процесс трудоустройства может проходить в разы легче, когда о ваших достижениях публично известно или есть кто-то в компании, кто с вами пересекался и может вас положительно охарактеризовать. В этом случае вам даже может не понадобиться хорошее резюме. Публичность (ресерчи, блоги, выступления) и нетворкинг решают. Также решает НЕ быть токсичным чудаком, с которым раз столкнувшись больше никто не хочет иметь дел.
🔹 Не пригласить на собес вас могут по 1001 причине. Особенно если есть какие-то осложнения типа необходимости релокейта в другую страну, неидеальное знание языка и т.п. Лучше не загоняться зря по этому поводу и рассматривать отправку резюме как форму необременительной саморекламы - как флаер у метро дать. Сработало - круто, не сработало - не страшно.
🔹 На собес лучше тоже идти с установкой "я иду познакомиться и пообщаться с интересными людьми, узнать как жизнь у них в компании и обменяться опытом". Будет в итоге интересный оффер - супер, не будет - не беда, профит уже был получен в процессе. 😏
🔹 Когда будете писать резюме, то поставьте себя на место того, кто будет его читать. Что ему будет интересно прочитать о вас? 🤔 Подсказка: скорее всего ему будет интересно прочитать +- про то, что он сам написал в описании вакансии. В принципе можно брать по пунктам и рефлексировать на тему "как связан мой опыт (равно результаты) с тем, что описано в вакансии". Желательно в тех же терминах и с использованием тех же ключевых слов. Возможно есть мысли какую пользу вы можете принести компании с первого дня? Напишите! Про "легко обучаюсь" и опыт вида "была вожатой в пионерском лагере" можно тоже написать, если очень хочется, но основой должно быть что-то максимально релевантное. Даже если вам за это не платили (CTF, стажировки, open source проекты). Дайте возможность человеку, который будет читать ваше резюме, зацепиться за что-то глазами, отобрать вас на собес и в итоге сделать оффер! Ему этого тоже очень хочется! И не пихайте в резюме лишних красных флажков, по которым можно сделать вывод, что с вами потом будут проблемы.

По случаю изучил прошлогодний CISA BOD 23-01 "Улучшение видимости активов и обнаружение уязвимостей в федеральных сетях"

По случаю изучил прошлогодний CISA BOD 23-01 Улучшение видимости активов и обнаружение уязвимостей в федеральных сетях

По случаю изучил прошлогодний CISA BOD 23-01 "Улучшение видимости активов и обнаружение уязвимостей в федеральных сетях". Собирался больше года назад, а возможность представилась только сейчас. Интересная тема с точки зрения контроля VM-процесса в организациях со стороны регулятора.

Допустим вы CISA, т.е. приблизительный американский аналог нашего ФСТЭКа. У вас есть подопечные - американские федеральные агентства. Их много, сложно даже сказать сколько. От 60 до 430+. Вы для них подсвечиваете критичные уязвимости в активной эксплуатации, по мере сил, устанавливаете к какому сроку их нужно фиксить. А с безопасностью и с уязвимостями у этих федералов всё равно полный швах. Что делать?

Безопасники CISA почесали голову и решили - давайте насаждать в федеральных агентствах базовые ИБ-процессы.

🔻 Во-первых, пусть ищут активы в своих сетках. Пофиг как. Хоть активным сканированием, хоть снифанием трафика, хоть через API какую. Главное регулярно, раз в неделю. Управление активами - это база.

🔻 Во-вторых, пусть эти активы сканируют на уязвимости. И чтобы не блекбоксом, а нормально, агентно или с привилегированной учёткой. Чтобы скан запускался каждые 2 недели со свежей базой детектов уязвимостей. Не успеваете всё просканить за 2 недели? А пофиг, всё равно запускайте следующий скан. Главное регулярность.

Тю? И всё? Просто рекомендации, выполнение которых никак не проверишь? 😏

Нет, не всё. 😈

🔻 В третьих, результаты сканирования активов требуют складывать в шайтан-поделье CDM Agency Dashboard не позже чем за 72 часа после завершения сканов на уязвимости. Откуда эти данные передаются в CDM Federal Dashboard для изучения аналитиками CISA. Также требуется скидывать "vulnerability enumeration performance data", т.е. по сути логи сканов, чтобы видно было насколько результаты сканирования адекватны.

Таким образом, регулятор очень оперативно видит состояние инфраструктуры органа/организаций, может самостоятельно делать выводы о выполнении требований по исправлению уязвимостей и проводить необходимые стимуляции. 🥕

Есть, конечно, и странности. Почему-то не написано напрямую, что инфу по обнаруженным активам тоже нужно CISA скидывать и что адекватность детектирования активов нужно подтверждать. Но, возможно, это подразумевается или добавят потом. Вообще документ прикольный, много тонких технических моментов разъясняется по-человечески.

Ещё в этом же документе есть тема, что агентства должны быть готовы по запросу CISA поискать у себя определенные активы или уязвимости, но эта ручка немножко про другое, как мне кажется.

Отчитал лекцию по Управлению Уязвимостями в Росатоме

Отчитал лекцию по Управлению Уязвимостями в Росатоме

Отчитал лекцию по Управлению Уязвимостями в Росатоме. Зарегистрировалось около ста человек. Раньше я этот материал читал только студентам-безопасникам. А тут мало того, что далеко не студенты, а взрослые опытные люди, так в основном ещё и из IT. Учитывая, что у меня значительная часть контента про то как мотивировать IT-шников наводить порядок в активах и как противостоять их попыткам саботажа VM-процесса ("как челобитную царю подаёшь" и "докажи-покажи") было волнительно как это зайдет на такую аудиторию. 🙂 Но прошло хорошо. Вопросы были конструктивные. VM-щики, конечно, тоже не всегда ангелы. 😈

Чтобы соответствовать названию "мастер-класс" уделил больше времени разбору примеров уязвимостей, способов их детекта и приоритизации (Vulners Linux Audit, Scanvus, OpenSCAP, ScanOVAL, Vulristics).

Большое спасибо отраслевой IT-школе Росатома за приглашение и Positive Education за организацию!

Запись буду использовать как основу для книги. 😉

ФСТЭК России 50 лет!

ФСТЭК России 50 лет!

ФСТЭК России 50 лет! Сегодня день основания Гостехкомиссии СССР (18 декабря 1973), которая в итоге превратилась во ФСТЭК. С праздником, коллеги! 🎉

ФСТЭК это главный российский регулятор в области Управления Уязвимостями:

🔸 Руководство по организации процесса управления уязвимостями в органе (организации)
🔸 Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств
🔸 База угроз и уязвимостей; регламент добавления
🔸 Бесплатный сканер уязвимостей ScanOVAL
🔸 ГОСТ Р 56546-2015 Классификация уязвимостей информационных систем
🔸 ГОСТ Р 56545-2015 Правила описания уязвимостей
🔸 Методика тестирования обновлений безопасности программных, программно-аппаратных средств