Архивы автора: Александр Леонов

Об авторе Александр Леонов

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

Последние несколько месяцев повальное увлечение автоматической кодогенерацией с использованием LLM-агентов (Claude Code, Cursor, Devin и прочих) начало принимать формы массового помешательства

4 комментария

Последние несколько месяцев повальное увлечение автоматической кодогенерацией с использованием LLM-агентов (Claude Code, Cursor, Devin и прочих) начало принимать формы массового помешательства. При этом зачастую его апологеты пропагандируют вещи откровенно вредные. Что уметь программировать больше не нужно. Разбираться во фреймворках и библиотеках - тем более не нужно. Достаточно просто поставить задачу, даже в самом общем виде, волшебному кодогенератору да докинуть токенов облачного AI-сервиса. А дальше ОНО ВСЁ ДЕЛАЕТ САМО! 🪄 И через несколько часов получаешь нужный результат.

А главное, что это не обман. Таким образом действительно можно получить программное решение, которое РАБОТАЕТ (пусть и не с первой итерации). Правда, фиг его знает, как оно написано и какие там могут быть сюрпризы - но кого ж это волнует, правда? 😏

В результате:

🔹 В ширнармассах возникает весьма понятное ощущение - вот оно! 🤑 Теперь для того, чтобы слепить стартап, больше не нужны технари! Волшебная машинка, накормленная токенами, выдаст приложульку сама. А фаундер может целиком посвятить себя окучиванию инвесторов и получению прочих бенефитов.

🔹 Да и состоявшиеся корпорации тоже не прочь по возможности сэкономить на разработчиках. 😇

К чему это приведёт в обозримом будущем? К тому, что разработкой (генерацией) кода начнёт заниматься огромное количество новых игроков, абсолютно незрелых и безответственных. Без какого-либо понимания о процессе безопасной разработки, правильной архитектуре, способах определения уязвимостей в собственном (лол 😅) коде и зависимостях (зачастую в такой же безответственной генерёнке 🤷‍♂️), нормальном выпуске обновлений с бюллетенями безопасности, CVE-шками и прочим.

И будьте покойны, эти новые игроки нагенерят ОГРОМНОЕ количество чёрти как работающего кода. Как коммерческого, так и опенсурсного. Настолько много, что все традиционные более-менее ответственные игроки потеряются на фоне массы этой новой вайбкодерной гопоты. И либо не смогут толком конкурировать с ней, либо сами деграднут до её уровня. 😏

Мы ещё будем с ностальгией вспоминать то благословенное время, когда код писали ручками, профессиональные программисты. Решение проблем с ПО, с которыми мы сталкивались раньше, было сродни плесканию на мелководье. А сейчас на нас надвигается цунами и что с этим делать, не особенно понятно.

Коллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VM

1 комментарий

Коллеги из АЛТЭКС-СОФТ представили первый технический обзор бета-версии RedCheck VM. Я отсмотрел это видео и выписал основные моменты.

Позиционирование решения: RedCheck VM - это простая и готовая к использованию система управления уязвимостями, которая снижает сложность внедрения и настройки и позволяет сосредоточиться на закрытии уязвимостей, а не на работе с инструментом.

Анонс фич, которые следует ждать до конца года:

📊 Оценка уязвимостей по методике ФСТЭК (в релизной версии)
🔧 Анализ и контроль несоответствий конфигураций
📦 Расширенная инвентаризационная информация по хостам

Ещё будущие фичи без сроков:

🛡️ Обогащение инвентаризации аудитами в режиме Pentest
🔗 Интеграция с таск-трекерами (помимо почты)

Что по сертификату? Полнофункциональный модуль RedCheck VM планируется включить в действующий сертификат RedCheck в следующем году.

Что по лицензированию? RedCheck VM - отдельный модуль RedCheck, бесплатно доступный для старших редакций, устанавливаемый на выделенный сервер с собственной базой данных. Для доступа к бета-версии достаточно запросить тестовую лицензию в редакции "Эксперт". RedCheck VM может подключаться ко всем экземплярам RedCheck Профессиональной редакции, такая архитектура подходит для групп компаний и распределённых сетей, позволяя собирать все результаты в едином центре.

Демо бета-версии продукта

Интерфейс. Стандартный веб-интерфейс. Светлая/тёмная тема.

Дашборды. На данный момент есть девять стартовых выборок: Хосты, Хосты на периметре, Уязвимости, Уязвимости на периметре, Уровни критичности по статусам, Хосты по сетевым зонам, Просроченные уязвимости по ответственным, Актуальность сканирования, Динамика хостов. Новые информеры будут добавляться с обновлениями, и в дальнейшем можно будет их переключать, сохраняя фокус внимания на важном.

Интеграция со сканерами RedCheck. Настройка начинается с указания адреса, порта Rest API и учетных данных сканера RedCheck. Все полученные данные агрегируются в выбранной сетевой зоне, при этом интерфейс позволяет создавать новые объекты напрямую из меню. Ключевым этапом является настройка расписания синхронизации в формате cron (секунды, минуты, часы, дни, месяцы, дни недели). По умолчанию в бета-версии установлен ежечасный опрос, однако его можно изменить (например, на ежедневный запуск в 23:00). Стоит учитывать, что экземпляр RedCheck сохраняет собственный регламент работы и может параллельно использоваться другими сотрудниками для внутренних задач. Отдельно управлять учётными записями можно в соответствующем списке.

Справочники. Позволяют редактировать различные сущности. В настоящее время доступны справочники: Теги хостов, Теги уязвимостей, Сетевые зоны, Ответственные, Почтовые адреса.

Хосты. После синхронизации со сканерами RedCheck данные о хостах импортируются в RedCheck VM. Каждому объекту присваиваются соответствующие параметры: сетевые зоны, ответственные лица и теги. В карточке хоста отображаются результаты инвентаризации и перечень выявленных уязвимостей. В таблице уязвимостей видны колонки: ALTXID, Уязвимость, Эксплойт (наличие эксплойта - пиктограмма восклицательный знак; использование в атаках - пиктограмма стрелка), Тип уязвимости, Теги уязвимости, Тип устранения, Статус обработки (Не обработана, В работе IT), Ответственный.

Карточка уязвимости. Карточка уязвимости (в примере уязвимости Firefox) содержит идентификаторы CVE и сведения об эксплойте. В ней указаны уязвимые компоненты, рекомендации по обновлению для различных ОС и меры по смягчению последствий (mitigation), если оперативное исправление невозможно.

Политики устранения. При создании политики устанавливается допустимый срок устранения уязвимостей - период с момента их обнаружения до исправления. Назначается ответственное лицо, которое получает единый сводный отчет с руководством к действию вместо разрозненных уведомлений. В настройках также определяются область действия политики (теги хостов) и критичность обрабатываемых уязвимостей.

Рабочий стол контроля устранения. Позволяет фильтровать задачи. Для фильтрации доступны следующие параметры: FQDN, IP-адрес, Дата публикации, Теги хоста, ALTXID, Уязвимость, Критичность, Тип уязвимости, Теги уязвимости, Статус, Тип устранения, Статус SLA, Ответственный ИТ. Так, Статус может быть в значении: В работе ИТ, Требует проверки, Просрочена, Устранена, Принят риск.

Рабочий стол управления рисками. Уязвимости, которые не обрабатываются политиками, переходят в управление рисками, где необходимо оценить их влияние на инфраструктуру и вручную передать на устранение или сформировать новую политику по общим признакам и запустить её в работу. "Например, можно отфильтровать все хосты с оценкой уязвимостей до четырёх баллов, выбрать хост и принять риск для него". Поддерживаются массовые операции: можно сделать выбор действия как на отображаемой странице, так и всех хостов, попавших под фильтр.

Анализ уязвимостей. Это перечень всех уязвимостей в базе RedCheck VM, в том числе, с распределением обнаружения на хостах в системе. Здесь отдельно можно поработать с уязвимостями по необходимым фильтрам, например, по дате обнаружения в инфраструктуре или дате публикации уязвимости. "Например, пятнадцатого января и с информацией об эксплоите".

Сходили вчера в Третьяковскую галерею на детскую экскурсию по выставке "Арктика. Полюс цвета"

1 комментарий

Сходили вчера в Третьяковскую галерею на детскую экскурсию по выставке "Арктика. Полюс цвета". Попали аккурат в последний день. Выставка проходила в новом корпусе на Кадашёвской набережной, открывшемся осенью 2024 года. Очень красивое современное здание. Внутри просторно, много естественного света (даже в пасмурный день), доминирующий белый цвет в сочетании с красным кирпичом. Люблю такое. 😇👍

Выставка была посвящена тому, как менялось восприятие Арктики с XVIII века до наших дней - от романтизированных образов далёкого и загадочного Севера к более точному, документальному взгляду эпохи освоения и современным художественным интерпретациям. Через живопись, графику, скульптуру, фотографию и мультимедиа показано, как художники, исследователи и участники экспедиций по-разному осмысляли этот регион, превращая его из мифа в пространство реального опыта и культурного значения. На выставке были представлены произведения художников, скульпторов и фотографов конца XIX - начала XXI века, многие из которых лично бывали в Арктике и вдохновлялись её природой и атмосферой. Среди авторов — Александр Борисов, Константин Коровин, Фёдор Решетников, Фёдор Конюхов и другие. Наибольшее впечатление на меня произвела работа Климента Редько "Полуночное солнце" (1925).

На детской экскурсии рассказывали о народах Крайнего Севера и их образе жизни в суровых арктических условиях. Ребятам объясняли, кто такие "самоеды" - историческое название, которым раньше обозначали ненцев и некоторые другие народы, и чем они отличаются от поморов - русских жителей северных побережий, традиционно занимавшихся морским промыслом и торговлей. Особое внимание уделялось тому, как по-разному эти группы приспосабливались к жизни на Севере. Ребята узнавали о традициях и быте коренных народов: кочевом оленеводстве, устройстве чумов, одежде из оленьих шкур, особенностях питания и уважительном отношении к природе. Также обсуждалось, как климат и окружающая среда формируют культуру, транспорт и уклад жизни, и почему выживание в Арктике требует глубокого знания местных условий и навыков, передающихся из поколения в поколение.

Также детям рассказывали о знаменитой экспедиции челюскинцев - участниках арктического плавания на пароходе "Челюскин", которое завершилось его гибелью во льдах Чукотского моря в 1934 году. Ребята узнали, как люди оказались на дрейфующей льдине и как затем их спасали советские полярные лётчики, что стало одной из самых известных историй освоения Арктики.

Выставка прошла при поддержке крупных компаний, связанных с развитием Арктического региона: Росатом, НОВАТЭК и Транснефть. В экспозиции упоминалось современное освоение Арктики: развитие транспортной и энергетической инфраструктуры, использование природных ресурсов и технологии, позволяющие работать в условиях Крайнего Севера.

На прошлой неделе западные ИБ-шники активно обсуждали очередное заявление руководителей NIST NVD, что "у них лапки", и они будут обогащать ещё меньше уязвимостей

1 комментарий

На прошлой неделе западные ИБ-шники активно обсуждали очередное заявление руководителей NIST NVD, что "у них лапки", и они будут обогащать ещё меньше уязвимостей. Хотя, казалось бы куда уж меньше. 😏 Суть обращения, опубликованного NIST 15 апреля, в том, что из-за резкого роста числа CVE они меняют подход к ведению National Vulnerability Database: вместо анализа всех уязвимостей база переходит на риск-ориентированную модель. Полноценно обогащаться будут только приоритетные уязвимости:

🔥 уже эксплуатируемые (из каталога CISA KEV) - обещают обрабатывать за сутки
🏛️ относящиеся к ПО, используемому в госсекторе США (федеральным правительством)
🛠️ относящиеся к критическому ПО, определённому в Executive Order 14028

Остальные CVE останутся в базе, но получат низкий приоритет и будут долго оставаться без детального анализа. При этом NVD отказываются от дублирования CVSS-оценок (если CVSS пришёл от CNA, ему будут доверять, а свой CVSS рассчитывать не будут), будут реже перерабатывать записи, по которым изменилась ситуация, и фактически законсервируют накопившийся бэклог, чтобы сосредоточиться на наиболее опасных уязвимостях ценой снижения полноты и единообразия данных по остальным.

В целом, у меня такие новости вызывают сплошные фейспалмы. 🤦‍♂️ От NIST, которые, по-видимому, разогнали всех адекватных IT/ИБ-специалистов и превратились в синекуру для бюрократов, тратящих огромное финансирование непонятно на что. От CISA, которые не могут навести порядок в базовом ИБ-сервисе, критичном и для США, и для мира в целом. От американской администрации, которая тратит совершенно астрономические суммы на дикие геополитические прожекты, но совершенно не заботится о том, что происходит (разваливается) у них дома. MAGA? Лол, что? 😅

Ну а в практическом плане это означает, что если вы полагаетесь ТОЛЬКО на бесплатную NVD, то совершаете фатальную ошибку. Адекватность этой базы год от года стремительно снижается. Учитывайте альтернативные источники: Vulners, DBugs, VulnCheck, GCVE, БДУ ФСТЭК и прочие. Единственной мировой базы уязвимостей больше нет.

Ниже привожу полный перевод сообщения NIST.
Читать далее →

Ну раз КУ, значит КУ (3 раза)

1 комментарий

Ну раз КУ, значит КУ (3 раза!). Извините, не удержался. 😅

"Владимир Николаевич, у тебя на периметре дыра, админ - бездельник, AD-шка не пропатчена, а ты тут мозги пудришь. Плохо кончится, родной…"

"- Ну вот у вас в организации, как вы определяете - кто уязвимости фиксить должен и в какой срок?
- Ну, это на глаз…
- Дикари!"

"- У меня такое предложение, родной. Ты нам сервак сейчас запатчишь, а мы тебе потом VM-ный мерч привезём, идёт?"

"- Стой! Стой, я говорю! Ты кто? Я спрашиваю: ты кто?
- Lead DevOps Engineer.
- Нет. Ты ITшник. А ты кто?
- Я ведущий разработчик.
- Не-ет, ты тоже ITшник. Ты ITшник, ты ITшник и он ITшник. А я VM-щик, и они VM-щики! Так что ты репорт открой и уязвимости фикси, ясно?"

На сайте ФСТЭК 12 апреля выложили методический документ "Мероприятия и меры по защите информации, содержащейся в информационных системах"

3 комментария

На сайте ФСТЭК 12 апреля выложили методический документ "Мероприятия и меры по защите информации, содержащейся в информационных системах". Проект этого документа выкладывали в феврале.

Несколько упрощая и перефразируя п. 1.2, документ определяет как нужно защищать информацию (за исключением вопросов, связанных с криптографией):

🔹 в ИС, АСУ и сетях госорганов, ГУП, госучреждений и организаций, включая субъектов КИИ
🔹 в Тех. средствах, ПО и БД, используемых для создания и эксплуатации ГИС и иных ИС госорганов, доступ к которым предоставляется по сети
🔹 в ИТ-инфраструктурах общего назначения, обеспечивающих функционирование указанных ИС, а также обеспечивающих безопасность ЗОКИИ, принадлежащей органам (организациям)

Фактически это детализация 117-го приказа ФСТЭК и замена методического документа ФСТЭК России от 11 февраля 2014 года "Меры защиты информации в государственных информационных системах".

Документ объёмный, 255 страниц (по файлу в формате ods). Я посмотрел, в каких разделах встречается слово "уязвимости" в различных формах (звёздочками условно отметил частоту упоминания):

✳️✳️✳️✳️✳️ 3.3. Управление уязвимостями (КУ)
✳️✳️✳️✳️✳️ ЗКО.8 Выявление и устранение уязвимостей в контейнерной среде
✳️✳️✳️✳️ II. ФАКТОРЫ, ВЛИЯЮЩИЕ НА СОСТОЯНИЕ ЗАЩИТЫ ИНФОРМАЦИИ, СОДЕРЖАЩЕЙСЯ В ИНФОРМАЦИОННЫХ СИСТЕМАХ
✳️✳️✳️ 3.18. Обеспечение защиты информации при использовании искусственного интеллекта (ИИ)
✳️✳️ 3.4. Управление обновлениями (КО)
✳️✳️ 3.12. Обеспечение разработки безопасного программного обеспечения (БР)
✳️✳️ ЗИВ.4 Контроль целостности
✳️ 3.1. Выявление и оценка угроз безопасности информации (ВУ)
✳️ 3.19. Проведение периодического контроля уровня защищенности информации, содержащейся в информационных системах (ПК)
✳️ РСБ.2 Анализ событий безопасности и реагирование на них
✳️ ЗСВ.1 Доверенная загрузка средств виртуализации и виртуальных машин
✳️ ЗКО.2 Регистрация событий безопасности в контейнерных средах
✳️ ЗБД.3 Защита пользовательских данных
✳️ ЗБД.4 Контроль целостности

Ниже привожу полную структуру документа.
Читать далее →

Небольшой оффтоп про то, как я кардинально упростил себе подготовку MAX-постов

Добавить комментарий

Небольшой оффтоп про то, как я кардинально упростил себе подготовку MAX-постов. Форматирование постов в MAX долгое время оставалось для меня весьма мучительной задачей. Судите сами: текстовую разметку (markdown) MAX пока не поддерживает, доступ к API для постинга пока есть только у юрлиц. Конечно, уже есть сервисы, предоставляющие услуги постинга (фактически обёртки над API), но они все какие-то мутные и просят денег буквально за каждый пост. Бесплатных ботов-конвертеров, аналогичных ТГ-шным пока нет. И чего с этим делать? Каждый раз форматировать пост ручками, используя редактор постов в приложении MAX? Ну, такое себе. Но решение, оказывается, всё время было рядом и было очень простым.

Всё началось с того, что я заметил: в веб-версии MAX форматированный текст можно копировать и вставлять без потери форматирования. 👀 А это значит, что веб-приложение MAX кладёт текст в буфер в форматированном виде. Что в свою очередь значит, что форматированный текст в таком же виде можно положить в буфер самостоятельно. 😉 Оказалось, что в Linux это можно сделать буквально вот так с помощью xclip:

cat post.html | xclip -selection clipboard -t text/html

Как-то специально заморачиваться с html не нужно. Если там используются простые теги (a, b, i, br) - всё работает. 🙂 Форматированный текст копируется в буфер и его достаточно вставить в веб-интерфейс MAX. 😇

Важно: это работает именно с веб-клиентом! Десктопный клиент хранит форматированный текст в буфере несколько иначе и там нужно больше танцев с бубном, чтобы достичь +- того же результата. Поэтому лучше работать именно с веб-клиентом.

А что если нам наоборот нужно копировать посты из MAX с сохранением форматирования? Это может быть полезно, если мы изначально пишем посты в MAX, а потом хотим выложить их куда-то ещё с сохранением форматирования. Всё аналогично. Копируем форматированный текст поста в веб-клиенте MAX и читаем буфер (в Linux) с помощью того же xclip:

xclip -selection clipboard -t text/html -o

Но есть проблема, что html-код там навороченный. Чтобы упростить его до простых тегов (a, b, i, br), я навайбкодил скриптик. В том же проекте доступны bash-обвязки, которыми я пользуюсь: HTML2MaxBuffer.sh, MaxBuffer2HTML.sh, show_all_buffers.sh.

Пользуйтесь и рекомендуйте друзьям, которым это может быть актуально.