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

Об авторе Alexander Leonov

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

Продолжу тему о критериях успеха в работах по Анализу Защищённости (АЗ)

Продолжу тему о критериях успеха в работах по Анализу Защищённости (АЗ)

Продолжу тему о критериях успеха в работах по Анализу Защищённости (АЗ). Если провести детектирование уязвимостей в любой достаточно большой организации, неизбежно обнаружатся критические уязвимости. И это абсолютно нормально, ЕСЛИ для всех обнаруженных уязвимостей выполняются следующие условия:

🔹 В организации уже знали про уязвимость на активе, т.е. обнаруживали её с помощью собственных средств детектирования.
🔹 Уязвимость уже была оценена и ей была присвоена степень критичности.
🔹 Для устранения уязвимости уже была заведена задача на конкретного исполнителя с зафиксированным сроком выполнения (в соответствии с принятым SLA) и этот срок ещё не вышел.

Это значит, что VM-процесс в организации успешно функционирует (по БОСПУУ 😉), и АЗ успешно пройден. 🥇👏

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

Я являюсь большим сторонником использования статьи 274.1 УК РФ (ч.3 нарушение правил эксплуатации КИИ) в качестве ультимативного аргумента в разговорах об устранении уязвимостей инфраструктуры

Я являюсь большим сторонником использования статьи 274.1 УК РФ (ч.3 нарушение правил эксплуатации КИИ) в качестве ультимативного аргумента в разговорах об устранении уязвимостей инфраструктуры

Я являюсь большим сторонником использования статьи 274.1 УК РФ (ч.3 нарушение правил эксплуатации КИИ) в качестве ультимативного аргумента в разговорах об устранении уязвимостей инфраструктуры. Не стоит начинать любой разговор с "давай быстро патчься, а то посадят 😡". Достаточно ненавязчиво упомянуть, что такая статья существует. И зачем под этой статьёй ходить, если можно пропатчиться и спать спокойно. 🤷‍♂️😉

Эту статью хотят обновить:

🔹 Довольно размытый "вред КИИ" хотят уточнить как "уничтожение, блокирование, модификация или копирование информации в КИИ".

🔹 Добавят освобождение от уголовной ответственности, тем, кто "активно способствовал раскрытию и расследованию преступления". Возможно, в том числе тем, кто первый расскажет про грешки коллег. 😉

🔹 Добавят аналогичную статью в КоАП РФ, если нарушение не содержит признаков преступления. Будут штрафовать граждан от 5 до 10 тыс. р., должностных лиц от 10 до 50 тыс. р., юрлица от 100 до 500 тыс. р.

Сегодня покрутил идею SOVA - проекта упрощённого аналога OVAL, о котором я писал в октябре

Сегодня покрутил идею SOVA - проекта упрощённого аналога OVAL, о котором я писал в октябре

Сегодня покрутил идею SOVA - проекта упрощённого аналога OVAL, о котором я писал в октябре. В итоге набросал тестовый дефинишен, описывающий проверку отключения аутентификации по паролю на SSH-сервере.

Как можно видеть, здесь комбинация двух тестов, выполняющих bash-скрипты, статусы которых объединяются по И. Всё сразу наглядно читается и, как я подозреваю, такие дефинишены будет очень просто генерить нейронкой по тексту из руководств по харденингу а-ля CIS Benchmarks. 😉

Проект завёл на платформе GitVerse от Сбера. Буду потихоньку его вайб-кодить в свободное время. 🙂 GitVerse, кстати, вполне норм. На мой неискушённый взгляд, ничем GitHub-у не уступает, можно пользоваться. 😉

На сайте ФСТЭК 16 января был опубликован документ с рекомендациями по харденингу SAP-систем

На сайте ФСТЭК 16 января был опубликован документ с рекомендациями по харденингу SAP-систем

На сайте ФСТЭК 16 января был опубликован документ с рекомендациями по харденингу SAP-систем. В документе 6 страниц текстовых рекомендаций и таблица на 9 страниц, содержащая объекты контроля (параметры, роли, сервисы и учетные записи), действия, безопасные значения/результаты и наименования продуктов, требующих настройки.

Рекомендации разделены на 12 групп:

1. Управление обновлениями
2. Учётные записи и пароли по умолчанию
3. Неиспользуемая функциональность и сервисы
4. Открытые интерфейсы и администрирование
5. Параметры профиля и конфигурации безопасности
6. Шифрование и защита каналов связи
7. Контроль доступа и разделение полномочий
8. Доверенные соединения и RFC
9. Логирование и аудит
✳️ 10. Безопасность данных
✳️ 11. Управление доступом и безопасной разработки
✳️ 12. Использование отладчика

Последние 3 группы ✳️ не отражены в таблице, только в тексте документа.

Документ интересный и, на фоне медленного импортозамещения ERP-систем, более чем актуальный. 👍

Сходили сегодня на концерт Meldis

Сходили сегодня на концерт MeldisСходили сегодня на концерт Meldis

Сходили сегодня на концерт Meldis. Последний раз ходили с жёнушкой на концерт Анастасии со товарищи ещё до рождения нашей крохи, лет 8-9 назад. И вот уже ходим втроём. 😊 Как время летит.

Концерт прошёл душевно. Послушали и в меру сил поподпевали разному кельтскому и "толчковому". 🙂 Моего любимого Мирквуда, правда, не было, надеюсь, что в следующий раз… 😉 Но было много чего ранее неслышанного. 👍 Доченька в процессе сделала рисунок и получила автограф. 😇

ТОН 71 как площадка тоже понравился, комфортно и вкусно. Можно ходить при случае.

Тут можно сказать - а какое нам дело до западных ИБ-вендоров, нам их запрещать не нужно, они же сами из России сбежали из-за санкций

Тут можно сказать - а какое нам дело до западных ИБ-вендоров, нам их запрещать не нужно, они же сами из России сбежали из-за санкций

Тут можно сказать - а какое нам дело до западных ИБ-вендоров, нам их запрещать не нужно, они же сами из России сбежали из-за санкций. Да, западные вендоры сбежали, а инсталляции их продуктов остались. И они либо вообще без лицензий используются, либо используются с лицензиями, закупаемыми через третьи страны. Даже в VM-ной сфере частенько слышу "а мы продолжаем на Nessus-ах работать". Это ведь не запрещено. 😏

И так повсеместно. В IT даже более выражено, чем в ИБ. Иностранный корпоративный софт все еще используют 72% российских компаний. И даже в регулируемом сегменте на отечественный софт перешли только 40-45% субъектов КИИ. 🤦‍♂️ А законодательный пушинг всё не усиливается. 🤷‍♂️

Какой уж там "технологический остров". Всё та же "технологическая колония" с чахлыми суверенными росточками, как правило на тех же западных стандартах и западном опенсурсе. Но некоторые агитируют и эти росточки растоптать, сохранив прямую "двухконтурную" зависимость от американского бигтеха. 🙄

Зачем запрещать продукты иностранных ИБ-вендоров?

Зачем запрещать продукты иностранных ИБ-вендоров?

Зачем запрещать продукты иностранных ИБ-вендоров? В той же статье про запрет в Китае западных ИБ-вендоров Reuters прямо пишут:

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

И продолжают, что "подозрения относительно происхождения и мотивов" к компании Kaspersky привели к удалению их ПО из сетей правительства США в 2017 году и запрету продаж на территории США в 2024 году.

Если американцы видят потенциальную угрозу своей национальной безопасности - тут же зачищают полянку для своих. 👌 Умные, хитрые, рациональные. Читайте то, что они транслируют для внутреннего потребления, а не экспортные благоглупости. 😉