Архив за месяц: Август 2022

И снова про нестабильных зарубежных IT/ИБ вендоров и обновления, которые могут содержать закладки

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

И снова про нестабильных зарубежных IT/ИБ вендоров и обновления, которые могут содержать закладки.

Очень интересный конкурс на госзакупках от ФСТЭК. "Информационная инфраструктура, обеспечивающая проведение тестирования обновлений безопасности программного обеспечения, страной происхождения которого являются недружественные государства, и программного обеспечения с открытым кодом (далее — зарубежные разработчики), а также предоставление доступа государственным органам (организациям) и субъектам критической информационной инфраструктуры (далее — органы (организации)) к результатам тестирования."

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

1. Если все будет удачно, то к концу года у ФСТЭК будут первые результаты тестирования обновлений для наиболее популярных софтов, который в гос-ах используются (перечень тоже в рамках задачи нужно будет определить). А процесс будет постепенно совершенствоваться ещё 3 года.
2. Интересно, что будет разработана не только "методика проведения работ по тестированию обновлений программного обеспечения" (что логично), а также будет "разработана методология определения критичности уязвимостей программного обеспечения, для устранения которых требуется установка обновлений безопасности и проведения работ по их тестированию". 🧐Насколько я понял это затем нужно, что тестировать будут не все патчи, а только для критичных уязвимостей и только их будут рекомендовать к установке. Возможно будет что-то напоминающее рекомендательный алгоритм НКЦКИ, но это не точно.
3. Прикольно, что ещё сделают руководство по Patch Management-у для организаций. Требуют "разработку руководства по управлению обновлениями программного обеспечения в органе (организациями), в том числе включающего дифференциацию обновлений, описание процессов получения обновлений, тестирования обновлений, установку обновлений, оценку и совершенствование процесса управления обновлениями." Давно топлю за то, чтобы было больше детальных руководств по Patch & Vulnerability Management, а тут ещё и от регулятора. 🔥

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

Итак, вы решили начать разработку своего Vulnerability Management решения

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

Итак, вы решили начать разработку своего Vulnerability Management решения. Часть 2. А может лучше специализироваться?

Первая часть зашла хорошо, так что продолжим. Если мы говорим, что полноценному VM вендору придется создавать отделы под

* поддержку разных видов таргетов (все ОС, все third-party софты для этих ОС, ERP, базы данных, разнообразнейшие сетевые устройства, любые технологии виртуализации и прочее)
* разработку конкретные фич ("пентест-сканирование" без аутентификации, визуализация и приоритизация уязвимостей и прочее)

то может лучше не замахиваться на все сразу, а взять конкретный кусочек функциональности полноценного VM-продукта и выпустить специализированное решение? Если в большом VM вендоре кусочек функциональности пилит команда из 3-4 человек, то и для стартапа команда разработчиков понадобится примерно сопоставимая. И возможно за счёт фокусирования, конечный результат будет даже лучше.

Давайте на примерах:

1. Сканирования сетевого периметра без аутентификации. Тот самый EASM. Периметр у любой организации есть. Легко продавать как облачный сервис. Хорошо и для старта, и для дальнейшего развития в облачный VM (при желании). Из решений с российскими корнями можно посмотреть Metascan, ScanFactory. Из нероссийских ImmuniWeb. У Vulners есть бета такого сервиса, можете тоже заценить. 😉
2. Детектирование уязвимостей Linux-хостов по бюллетеням. Linux-овой инфраструктуры сейчас в компаниях много, будет ещё больше. Задача более-менее подъемная. Для каждого Linux дистриба необходимо разобраться с бюллетенями безопасности, научиться корректно сравнивать версии. Инвентаризацию хостов можно делать самим, а можно оставить самим клиентам и предоставить только API для проверки. Как пример Vulners Linux API и Vulns.io VM.
3. Сканирование сетевых устройств. Linux хосты можно проверять по пакетам, Windows хосты можно проверять дополнительной функциональностью, реализуемой в антивирусах (у Kaspersky например). А что делать с устройствами на которые агента не поставишь? Тут либо полноценный VM брать, либо самим что-то писать, либо брать решение специализирующееся на сетевых устройстах. С этого начинали Газинформсервис с продуктом Efros Config Inspector. Давно их не смотрел, сейчас, судя по описанию, они стали полноценным VM решением.
4. Сканирование ERP и других систем критически важных для бизнеса. Чем сложнее ПО, тем выше вероятность, что VM-решения не будут поддерживать его в достаточной мере. Взять например SAP. Из полноценных VM решений его только MaxPatrol 8 умеет сканировать, а TOP-3 мировых VM вендора нет и им норм. Поэтому и есть ниша, для специализированных решений, например ERPScan. Пример очень эффектной фишечки в ERPScan это возможность проэксплуатировать некоторые найденные уязвимости проямо из интерфейса.
5. Приоритизация уязвимостей. Существует масса решений, которые даже не пытаются сами детектировать уязвимости, а занимаются только агррегацией уязвимостей из сторонних продуктов-сканеров и последующей их приоритизацией. Как пример Kenna Security (теперь Cisco). Можно глянуть Faraday Security, у них есть бесплатная опенсурсная версия.
6. Фиды по уязвимостям. Каждый Vulnerability Management продукт это база уязвимостей + правила детектирования. Собрать хорошую базу уязвимостей, обогащенную данными об эксплоитах (и их зрелости), малварях и признаках эксплуатации вживую совсем не просто. Тут можно отметить платные фиды Vulners, Kaspersky, Vuldb, Risk Based Security VulnDB.

Ниш в которых традиционные VM вендоры показывают себя недостаточно хорошо можно накинуть много. Конечно и продавать такие решения придется по-другому. Не получится сказать, что мы как MP8, только лучше и дешевле. Нужно будет доказать, почему клиенту полноценный VM либо совсем не нужен, либо он будет эффективно дополнен этим нишевым решением. Задачка творческая. 🙂

Если эта часть хорошо зайдет по лайкам и репостам, следующая будет про то как по-быстрому сделать (или сымитировать 😉) VM решение, собрав его из того, что есть в паблике.

Посмотрел недавний вебинар по Аврора ОС и пару вебинаров для разрабов

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

Посмотрел недавний вебинар по Аврора ОС и пару вебинаров для разрабовПосмотрел недавний вебинар по Аврора ОС и пару вебинаров для разрабовПосмотрел недавний вебинар по Аврора ОС и пару вебинаров для разрабовПосмотрел недавний вебинар по Аврора ОС и пару вебинаров для разрабовПосмотрел недавний вебинар по Аврора ОС и пару вебинаров для разрабовПосмотрел недавний вебинар по Аврора ОС и пару вебинаров для разрабов

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

У ОМП прям очень четкий фокус на гос-ы и окологос-ы. "Вам нужны полностью управляемые мобильные терминалы с отечественной криптой и всеми гос. сертификатами соответствия? Их есть у нас! Ещё и приложения поможем написать на C++, если надо". В новом релизе: электронная подпись КриптоПро CSP в браузере, поддержка NFC токенов для аутентификации (чтобы в usb-порт токен постоянно не тыкать), улучшение поддержки WebRTC в браузере (шустро заработали видеочатики), в Аврора Центр (Enterprise Mobility Management) теперь поддерживаются и устройства на Android. Важные улучшения? Да конечно! Но понятно на кого именно ориентированные. И так-то правильно, это понятная стратегия для устойчивого развития окологосударственного бизнеса.

С другой стороны, это ли ожидалось от эпичной истории приведшей к появлению в России своей мобильной ОС? Nokia Maemo для легендарного N900 -> MeeGo -> Mer -> Jolla Sailfish -> Работы Jolla по локализации Sailfish в 2015 -> победа в конкурсе Минкомсвязи 2015 -> Лицензирование и форк Sailfish в Sailfish Mobile OS RUS (с переименованием в Аврора ОС) -> получение контроля над финской Jolla "По данным на 2018 год, «Ростелеком», через «Вотрон», владел 61,5% долей Sailfish Holding Ltd. (Гонконг), которая в свою очередь контролировала почти 83,2% Jolla". Еще ролик есть про эту историю прикольный.

В общем, казалось, что весь Jolla Sailfish прям наш. И все плюшечки типа своих устройств (ну ладно, у Jolla с этим было не очень, но они были), официальных портов (для Sony Xperia) и неофициальных портов на сторонние устройства будут либо будут повторены в Аврора ОС, либо основная Jolla обрусеет и перестанет уже пользователей из России дискриминировать и станет альтернативой для физиков.

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

А с Jolla что-то странное. В марте Samuli Simojoki, председатель правления Jolla, написал воззвание в соцсеточке, что Jolla ищут покупателей на российскую долю и хотят все связи с Россией порвать. Правда судя по профилю в соцсеточке в том же марте Samuli Simojoki в Jolla работать перестал ("Jolla, Chairman of The Board May 2018 - Mar 2022"). 🙂 Похоже кризис по-тихому купировали и больше новостей про Jolla в паблике не было. Ни хороших, ни плохих. Но как это дальше будет развиваться не ясно. Хочется надеяться, что Ростелек контроль над глобальной Jolla в каком-то виде сохранит и грамотно им воспользуется. Увидеть продвижение контролируемой Ростелекомом ОС (Sailfish, Аврора - не суть важно) в странах БРИКС было бы интересно.

К слову, немного потыкал в Аврора ОС. Если поставить SDK, то в Virtualbox создается пустая виртуалка для отладки приложений. можно меню настройки поглядеть. Довольно симпатично. Но конечно было бы гораздо прикольнее потыкать в полноценный образ ОС, как в Genymotion, но такого я пока не нашел.

Часть 2 таймкодов Код ИБ Безопасная Среда "Управление уязвимостями" (в один пост не помещалось)

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

Часть 2 таймкодов Код ИБ Безопасная Среда "Управление уязвимостями" (в один пост не помещалось)

52:58 - 1:04:42 Взаимодействие ИБ и ИТ в части управления уязвимостями. Волчков, Родыгин, Кузнецов, Хлапов
1:04:54 - 1:07:35 Автоматизация и централизованный менеджмент конфигураций. Волчков, Ермаков, Кузнецов
* 1:07:35 - 1:13:34 Инвентаризация ассетов и инвентаризация софтов как основа для Vulnerability и Compliance Management-а. Ермаков, Волчков, Кузнецов, Хлапов, Леонов, Родыгин
* 1:13:58 - 1:17:05 Конкретные решения на рынке для VM и CM. Леонов, Кузнецов, Хлапов
1:17:47 - 1:20:16 Решение SpaceBIT для CM. Волчков
1:21:06 - 1:33:59 Вопросы
-> 1:21:06 - 1:22:40 Как считать вероятность эксплуатации уязвимости? Кузнецов
* -> 1:23:20 - 1:24:44 Патчинг "ушедших" вендоров. Алгоритм НКЦКИ. Леонов, Родыгин, Кузнецов
-> 1:24:44 - 1:28:24 Внедрение CIS стандарта. Хлапов, Ермаков, Кузнецов, Волчков
-> 1:28:24 - 1:29:30 Кто должен заниматься безопасной настройкой. Кузнецов
* -> 1:29:30 - 1:33:59 Насколько можно доверять аудиту Windows хостов по аналогии с аудитом Linux хостов? Ограничения детектов сканеров. Леонов, Кузнецов, Родыгин
1:33:59 Завершающие слова.

Видяшечка по мероприятию Код ИБ Безопасная Среда "Управление уязвимостями" успешно вышла

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

Видяшечка по мероприятию Код ИБ Безопасная Среда "Управление уязвимостями" успешно вышла. На самом деле ещё 2 дня назад, но только сейчас дошли руки посмотреть и разметить. Отдельно выделил фрагменты, где, имхо, * самое огнище 🔥. Приглашаю заценить полностью или частично. Также посмотрите мои впечатления по мероприятию, если не читали.

Часть 1
* 1:05 - 2:32 Управление мисконфигурациями и управление уязвимостями, можно ли делать в рамках одного процесса? Леонов
* 2:32 - 3:45 А уязвимость процесса это часть VM? Какая функциональность входит в VM? Можно ли отталкиваться от функциональности САЗ? Родыгин, Леонов
* 3:45 - 6:15 А есть ли устоявшаяся терминология в VM? Пример: что такое Compliance Scan? Assessment и Mitigation plan. Ермаков
6:20 - 6:38 Smart Install в Cisco это уязвимость или мисконфигруация? Хлапов
6:42 - 7:34 Vulnerability, Weakness и Misconfiguration. О доверии экспертному мнению. Кузнецов
7:53 - 9:44 Уровни уязвимостей. Мисконфигурации это уязвимости. Волчков
* 10:12 - 14:53 А всякая ли небезопасная настройка приводит к уязвимости? На примере CIS Benchmarks. Нам нужны более лучшие стандарты. Кузнецов, Волчков, Леонов, Ермаков
14:55 - 15:44 Реализуемость уязвимости для конкретной системы. Родыгин
* 16:15 - 22:37 Трендовые эксплуатируемые уязвимости. Кузнецов, Леонов, Хлапов, Ермаков, Родыгин
22:50 - 26:27 Стандарты и требования по безопасной конфигурации: регуляторные и корпоративные. Волчков
* 26:27 - 27:55 Требования по управлению уязвимостями. Методичка по управлению патчами и уязвимостями для MaxPatrol на 300 страниц. Кузнецов
28:00 - 29:30 Стоит ли вообще устранять уязвимости? Родыгин, Волчков
29:30 - 52:58 Стоит ли устранять все уязвимости? Кузнецов, Леонов, Ермаков, Волчков, Хлапов, Родыгин
* -> 29:30 - 30:33 Не стоит устранять все, фокусироваться на детекте и реагированием на действия злоумышленника. Кузнецов
* -> 30:41 - 36:16 Нужно исправлять все уязвимости, если вы доверяете вендору. Леонов. Оппонируют Ермаков, Кузнецов, Родыгин
-> 36:16 - 36:55 Уязвимости могут становиться нереализуемыми из-за изменения архитектуры. Родыгин, Кузнецов
-> 36:55 - 38:41 Нужно ли оценивать реализуемость? Родыгин - да, Кузнецов - нет
-> 38:41 - 39:47 Все патчить невозможно. Хлапов, Родыгин
* -> 39:47 - 41:15 А почему нам больно патчиться? Леонов
-> 41:30 - 42:41 Пример кейса, когда патчиться не вариант. Кузнецов
-> 42:41 - 44:06 Переконфигурирование как способ ремедиации. Волчков
-> 44:06 - 47:07 Архитектурные изменения лучше патчинга. Родыгин. Оппонирует Кузнецов
* -> 47:07 - 48:19 Комментируем результаты опроса. Леонов, Родыгин, Волчков
-> 48:50 - 50:51 Автоматическая приоритизация на основе сетевых сегментов и ассетов. Хлапов, Кузнецов
* -> 50:51 - 52:58 Патчить нужно всё, потому что хорошая качественная сетевая сегментов это иллюзия. Ермаков

Итак, вы решили начать разработку своего Vulnerability Management решения

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

Итак, вы решили начать разработку своего Vulnerability Management решения. Часть 1. Подводные камни.

Где-то с периодичностью раз в полгода ко мне приходят из какой-нибудь компании и говорят: "мы хотим разрабатывать свое решение по Управлению Уязвимостями как у ZZZ, расскажи что как и не хочешь ли поучаствовать?" Я на это обычно не то, чтобы отговариваю, но стараюсь подсветить сложности. Кажется пора уже это сформулировать в виде текста. Думаю будет полезно и тем, кто хочет запилить самописный VM в конкретной организации.

1. Основная сложность для вката в VMный рынок в устоявшемся ожидании, что VM решения должны детектировать уязвимости вообще во всем: все ОС (Linux дистрибы, Unix-ы, Windows, MacOS), все third-party софты для этих ОС, ERP, базы данных, разнообразнейшие сетевые устройства, любые технологии виртуализации и прочее. Все, что может встретиться у заказчика должно быть покрыто этим VM решением. Причем не только при сканировании с аутентификацией, но и без. И желательно ещё и смежные области тоже зацепить: AppSec DAST/SAST, DevOps, облака, IOT, SCADA, встраиваемые системы. Это даже не конкурентные преимущества, это база, нижняя планка для входа в рынок, что-то само собой разумеющееся.
2. Естественно абсолютного покрытия быть не может. Но если ожидания клиентов не будут биться с реальностью, если это будет заметно, особенно если в результате расследования инцидента, то маркетинговая иллюзия рухнет. Как и позиции вендора. Поэтому VM вендоры очень стараются соответствовать. Хотя бы для текущих и потенциальных заказчиков.
3. Необходимость покрытия всего значит, что вам, новому игроку, придется скопировать кадровую структуру больших VM вендоров. То есть под каждое направление из п.1. завести отдел как минимум из 2-3 человек. Они будут на фулл-тайме ресерчить где можно получить данные по уязвимостям для конкретных систем, как для этих систем устроен патчинг, будут писать проверки и автоматические генераторы проверок, тестить, что ничего не отъехало, дорабатывать при необходимости. Работа непростая, специфическая. Сам года 3 этим занимался. Людей под это нужно много ещё и с учётом того, что нужно догнать существующих VM вендоров с их десятками и сотнями тысяч проверок.
4. Всех этих людей нужно кормить. Откуда денег столько взять? Это подводит нас к тому, что конечное решение будет стоить дорого. Невозможно поддерживать такое хозяйство продавая безлимитный а-ля Nessus Professional за $3k в год. Это уже из серии демпинга. Вот продавая а-ля Tenable SC крупным компаниям с лицензированием по хостам - уже можно жить.
5. Такие продукты сами себя не продают. Поэтому также придется завести армию сейлов, пресейлов и маркетологов. А работа последних во многом и привела к ситуации из п.1, когда все с покерфейсом пытаются соответствовать невыполнимым требованиям при этом отмахиваясь, что качество детектирования это ерунда, не нужно на это обращать внимание, лучше на дашборды наши посмотрите. 🙂

В общем, невероятный вывод: чтобы делать полноценный VM нужно обладать командой и ресурсами как у Tenable, Qualys, Rapid7, Positive Technologies. 🙂 Ну или хотя бы как у Altx-soft, Secpod, Outpost24, F-Secure.

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

В полку Linux уязвимостей позволяющих поднять привилегии до root-а прибыло

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

В полку Linux уязвимостей позволяющих поднять привилегии до root-а прибыло. Встречаем DirtyCred (CVE-2021-4154 - февральская, есть PoC; CVE-2022-2588 - свежая, пока нет PoC-а). 8 лет уязвимость никто не замечал. Или замечали и использовали, но помалкивали. Естественно NVD как обычно тормозит и там нового идентификатора пока нет, но он во всю используется в бюллетенях безопасности.

Судя по описанию это уязвимость ядра, похожая на мартовскую Dirty Pipe (CVE-2022-0847), только круче, т.к. работает стабильнее:

"The novel exploitation method, according to the researchers, pushes the dirty pipe to the next level, making it more general as well as potent in a manner that could work on any version of the affected kernel."

И контейнеризация не спасает:

"Second, while it is like the dirty pipe that could bypass all the kernel protections, our exploitation method could even demonstrate the ability to escape the container actively that Dirty Pipe is not capable of."

Ну и так-то уязвимости позволяющие получить в Linux root-а появляются достаточно регулярно. Из громких можно ещё вспомнить Dirty Cow (CVE-2016-5195 - обалдеть 😱, 6 лет назад, помню как вчера как тестил) и Qualys-овские PwnKit (CVE-2021-4034) и Sequoia (CVE-2021-33909).

А что делать? Имхо, патчить. Лучше в рамках регулярного процесса, а не в пожарном режиме. Но если регулярного патчинга Linux-ов нет, то лучше разово обновиться, махая этой уязвимостью (или даже более старыми с публичными эксплоитами) как флагом. После разового упражнения будет видно какие есть проблемы с внедрением регулярного процесса, а где-то возможно получится его внедрить с наскока.

Ну или можно не патчить, обосновывая тем, что оно (вроде) не эксплуатабельно, а где эксплуатабельно, то там не критично или туда не доберутся. И из контейнера не выберутся. И вообще можно внедрить EDR на линуксах. И ещё можно попробовать мандатку настроить.

Но, имхо, оценка эксплуатабельности, харденинг и внедрение СЗИ для Linux-ов это конечно все замечательно, но основное это патчинг и прежде всего нужно разобраться именно с ним.