Архивы автора: Alexander Leonov

Об авторе Alexander Leonov

Привет! Меня зовут Александр. Я специалист по Управлению Уязвимостями. Подробнее обо мне можно прочитать здесь. Приглашаю подписаться на мой канал в Telegram @avleonovrus. Я обновляю его чаще, чем этот сайт. Вы можете обсудить мои посты или задать вопросы в @avleonovchat или в группе ВКонтакте. And I invite all English-speaking people to another telegram channel @avleonovcom.

Трансформировал свой англоязычный сайт avleonov.com

Трансформировал свой англоязычный сайт avleonov.com

Трансформировал свой англоязычный сайт avleonov.com. Русскоязычный сайт avleonov.ru я сразу задумывал как автоматизированное зеркало телеграм-канала @avleonovrus. А с развитием англоязычного сайта было непонятно. 🤔

Я его веду с 2016 года. Долгое время это была моя основная площадка для VM-ного контента. С февраля 2020 я выкладывал там посты исключительно с видео. 🪧 Выпустил 94 видяшки. Но постепенно мне жутко надоел этот формат. 😮‍💨 Интереснее и проще было делать ролики на русском (сначала в "Прожекторе по ИБ", потом в SecLab "В тренде VM"). А на английский их, при необходимости, переводить.

С марта 2024 на англоязычном сайте посты не выходили. 🤷‍♂️ Выходили только на канале @avleonovcom. В итоге я решил, что и англоязычный сайт станет зеркалом Telegram-канала. 🪞

✅ Доработал скрипты и залил на сайт 117 постов из ТГ, вышедшие с марта 2024. Весь контент, который я добавлял до этого руками остался без изменений.

A6СПК: как делать больше, а напрягаться меньше

A6СПК: как делать больше, а напрягаться меньше

A6СПК: как делать больше, а напрягаться меньше. Сформулирую способ ведения задач, который у меня выработался за последний год-два.

Основные моменты:

🔻 Держать задачи и идеи в голове очень вредно. Мало того, что они забываются в самый неподходящий момент, так это ещё и ОЧЕНЬ энергозатратно. Тут отсылаю к концепции "мыслетоплива" Максима Дорофеева. Я считаю его джедайские техники какими-то излишне замороченными, но базовые вещи про "мыслетопливо" и "обезьянку" я разделяю. Если есть идея или задача, важно её записать. Я пришёл к тому, что удобнее всего записывать на листочках формата A6 (четверть A4 или половина листа из стандартного мерчёвого блокнота с конференции 😅). Необязательно сразу садиться работать над этой задачей, можно отложить листок в стопочку и вернуться к ней в более удобное время. Но записать следует обязательно. И задачи без такого листочка в работу не брать.

🔻 Когда начали работать над задачей, берём соответствующий листочек A6 и начинаем разбивать эту большую задачу на последовательность конкретных простых микрозадач в прямоугольничках, последовательно связанных стрелочками. Длительность микрозадачи не должна быть больше 5-10 минут. Чем проще и конкретнее микрозадача, тем лучше. Не экономьте бумагу в ущерб своему мыслетопливу! Необязательно расписывать задачу на микрозадачи полностью, но 3-4 микрозадачи лучше сразу зафиксировать. Чтобы этап планирования и этап выполнения были разнесены. Закончили планировать - без рефлексий берём первую микрозадачу в работу.

🔻 Когда начинаем работать с микрозадачей, ставим в соответствующий прямоугольничек точку, рисуем от него стрелочку и кружочек, в который вписываем время, когда планируем закончить работу с микрозадачей. Если сейчас 18:10, пятиминутную задачку планируем выполнить в 18:15, пишем в кружочке крайнее время - 15. Начиная с текущего момента и до крайнего времени в кружочке делаем только эту микрозадачу. Выполняем её ни на что не отвлекаясь. Какое бы срочное дело ни было, уж 5-10 минут оно подождёт. И на 5-10 минут сохранить полный фокус не так сложно. Ни над чем, что не оформлено как микрозадача в принципе не работаем.

🔻 По завершении микрозадачи с чувством глубокого морального удовлетворения перечёркиваем прямоугольничек и кружочек (отмечая, что по времени уложились 👍; но если не уложились - не беда). И без рефлексии сразу переходим к следующей микрозадаче. И так далее пока вся задача не будет выполнена. Тогда перечёркиваем листок, рвем его на кусочки (с удовлетворением от того, что задача выполнена) и берём следующую задачу в работу.

Может показаться, что всё это какая-то излишняя фигня и проще делать задачи без какой-либо фиксации, просто в состоянии потока. Меня самого такие мысли неоднократно посещали, но пока каждый раз оказывалось, что вдолгую без фиксации поддерживать рабочий темп ГОРАЗДО сложнее. Это приводило к потерям времени и сил несопоставимо большим, чем любое планирование на листочке. 🤷‍♂️

Мини-отпуск в Сергиевом Посаде прошёл успешно

Мини-отпуск в Сергиевом Посаде прошёл успешно

Мини-отпуск в Сергиевом Посаде прошёл успешно. 👍 Лавру посетили, про историю этого важнейшего религиозного центра послушали. ☦️ Съездили на производство матрёшек и поучились их расписывать. 🎨 Добрались до Богородского на фабрику резных деревянных игрушек. В кухмистерской XIX века поучаствовали в приготовлении карамели. 😅 И много ещё чего интересного поделали.

Теперь с новыми силами буду возвращаться в VM-ный контекст. 😇

VM Dev Tasks: Разработка консольной утилиты - сканера уязвимостей

VM Dev Tasks: Разработка консольной утилиты - сканера уязвимостей

VM Dev Tasks: Разработка консольной утилиты - сканера уязвимостей. Сканер уязвимостей взаимодействует с сетевыми хостами в инфраструктуре организации и определяет для них известные (CVE, БДУ) уязвимости. Взаимодействие может подразумевать выполнение команд на самом хосте (подключение к установленному на хосте агенту или безагентное подключение по SSH, WinRM и т.д.) или не подразумевать этого (взаимодействие с сервисами на открытых портах хоста).

В рамках проекта потребуется реализовать:

🔹 парсеры для источников информации об уязвимостях для некоторого набора софтов/ОС/сетевых устройств (лучше выбирать не самое очевидное и распространённое, но при этом востребованное); на основе этой информации сгенерировать формальные правила детектирования уязвимостей (например, на языке OVAL)
🔹 скрипты инвентаризации состояния хоста
🔹 скрипты детектирования уязвимостей по сгенерированным ранее правилам

В идеале попробовать реализовать генерацию правил детектирования с помощью LLM.

В Штатах победил Трамп, но, имхо, для нашего дела это мало чего изменит

В Штатах победил Трамп, но, имхо, для нашего дела это мало чего изменит

В Штатах победил Трамп, но, имхо, для нашего дела это мало чего изменит. Будь там хоть Трамп, хоть Харрис, хоть Байден, хоть сам чёрт лысый. 😈

🔻 Как использовали США свой взращённый нерыночными методами бигтех как инструмент глобального доминирования, так и будут использовать. Как распространяли NSA-ные закладки под видом уязвимостей, так и продолжат распространять. Новые "оспенные одеяла" для нового времени. 🤷‍♂️

🔻 Наиболее негативным сценарием сейчас, как ни парадоксально, было бы снятие всех ограничений со стороны США и схлопывание импортозамещения у нас. Думаю, что это очень маловероятно. Памятуя о первой каденции Трампа, стоит ждать усиления санкционных ограничений в области экспорта IT-продуктов и сервисов. 🌚

🔻 Бардака в NVD, при Трампе, конечно, было куда меньше. Но и обещаний навести там порядок за 2 дня никто не озвучивал. 😅 Так что в части американской инфраструктуры для описания и оценки уязвимостей ничего кроме дальнейшей деградации я не жду.

Возможно ли использовать AI для детектирования уязвимостей?

Возможно ли использовать AI для детектирования уязвимостей?

Возможно ли использовать AI для детектирования уязвимостей? Думаю да, но тут нужно определиться, что мы под этим понимаем.

🔻 Если речь идёт об обнаружении ранее неизвестных уязвимостей, о ресёрче, то здесь AI инструменты работают уже сейчас. Буквально на днях, 1 ноября, исследователи из Google Project Zero обнаружили первую реальную эксплуатабельную уязвимость с помощью своего LLM проекта Big Sleep. Это была stack buffer underflow в SQLite. Очень круто и многообещающе. 👍

🔻 Если же речь идёт об известных (CVE) уязвимостях, то задача сводится к генерации чётких правил их детектирования в инфраструктуре. AI должен взять на вход имя продукта и вендора, обнаружить источник данных об уязвимостях, понять структуру данных и как можно из них сгенерировать формальные правила для детектирования (например, на языке OVAL), произвести генерацию и оценить корректность правил. Не выглядит как что-то невероятное, но практических реализаций этого я пока не встречал. 🤷‍♂️

На предложение спрашивать с вендоров за уязвимости можно возразить, что они просто начнут свои уязвимости замалчивать

На предложение спрашивать с вендоров за уязвимости можно возразить, что они просто начнут свои уязвимости замалчивать

На предложение спрашивать с вендоров за уязвимости можно возразить, что они просто начнут свои уязвимости замалчивать. И сейчас отечественные вендоры не любят сообщать об уязвимостях в своих продуктах, а так совсем ягнятки замолчат. 🤐

И тут я сформулирую предложение, без которого первое не работает. Если вендор знает об уязвимости в версии своего продукта, используемой у клиентов, и этот факт замалчивает, то это должно классифицироваться как КРАЙНЕ серьёзное нарушение. Если такая ситуация вскрывается, то

🔹 сертификат продукта должен отзываться, лицензия вендора анулироваться, назначаться крупный штраф

🔹 ответственный (гендир) должен лично нести за это уголовную ответственность

По какой статье? Имхо, стоит расширить 274.1, т.к. такое замалчивание создаёт риски для КИИ.

Следует сделать так, чтобы между публикацией информации об уязвимости (и последующим объяснением с регулятором) и замалчиванием вендору ВСЕГДА рационально было бы сделать выбор в пользу первого.