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

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

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

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

У ОМП прям очень четкий фокус на гос-ы и окологос-ы. "Вам нужны полностью управляемые мобильные терминалы с отечественной криптой и всеми гос. сертификатами соответствия? Их есть у нас! Ещё и приложения поможем написать на 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-ов это конечно все замечательно, но основное это патчинг и прежде всего нужно разобраться именно с ним.

Записал традиционный расширенный вариант отчета по августовскому Patch Tuesday

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

Записал традиционный расширенный вариант отчета по августовскому Patch Tuesday. Кратко и на русском было здесь.

И ещё по поводу интервью Натальи Касперской

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

И ещё по поводу интервью Натальи Касперской. Там был такой тезис: "смартфоны нам массово заблочат, но не беда - продолжим пользоваться кнопочными телефонами, выживем". С одной стороны это конечно правда, телефоны без ОС недружественному вендору контролировать сложнее. Но тут стоит обратить внимание, что не во всех кнопочных телефонах, а корректнее называть это "фичафонами", нет ОС. Сейчас уже скорее наоборот. Например, в KaiOS, успешном форке Firefox OS, есть и браузер, и приложения, и магазин приложений. Эта OC используется в современных телефонах Nokia от HMD Global и много где ещё. KaiOS Technologies между прочим калифорнийская. Так что хоть и есть кнопки, а проблемы +- как со смартфонами. С другой стороны и в телефонах без ОС могут быть всякие сюрпризы. Вот например мой прошлогодний пост:

——

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

1. Сообщать о факте покупки
2. Сообщать об использовании телефона передавая IMEI телефона и IMSI SIM-карт
3. Отправлять платные сообщения на короткие номера, загружая необходимый текст с сервера
4. Пересылать входящие смс на сервер злоумышленника

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

Что делать? Видимо действительно не брать совсем уж noname в сомнительных магазинах. Звонилка от Nokia (уже китайской, но все ещё большой) купленная в магазине крупной сети должна быть относительно безопасна.

В целом же это такая вульгарная вариация атаки на цепочку поставок. И решения должны быть примерно схожими."

——

В текущих реалиях все же очень желательно, чтобы такое устройство было спроектировано и произведено в России. Только это делает его насколько возможно доверенным. Кажется в эту сторону Касперские сейчас и работают. По моему мнению за это вполне имеет смысл переплачивать. И какие-то функциональные ограничения устройства на фоне существующих угроз уже перестают играть существенную роль, а возможно даже в плюс идут.