Завтра, 8 сентября, поучаствую в проекте #ИБшныйДвиж от Код ИБ

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

Завтра, 8 сентября, поучаствую в проекте #ИБшныйДвиж от Код ИБ. Буду рассказывать про "Vulnerability Management после февраля 2022 года".

- Почему этот год особенный для Vulnerability Management процесса
- Оценка стабильности IT/ИБ вендоров
- Как продолжать использовать и обновлять ПО от вендора, которому больше не доверяешь
- Рекомендательный алгоритм НКЦКИ
- Переход на Open Source: панацея или нет?

Прямой эфир начнется в 10:00 по Москве и пройдет в видео-чате телеграмм-канала @codeibnews. Для участия нужно подписаться на канал.

Прикольный чеклист по задачам, которые должны быть реализованы в соответствии с 250-м Указом и подзаконными актами от Алексея Лукацкого и позитехов

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

Прикольный чеклист по задачам, которые должны быть реализованы в соответствии с 250-м Указом и подзаконными актами от Алексея Лукацкого и позитехов

Прикольный чеклист по задачам, которые должны быть реализованы в соответствии с 250-м Указом и подзаконными актами от Алексея Лукацкого и позитехов. Единственное, что PDF-ка по которой нельзя искать это зло. 🙂 По нашей VM-ной части основное, как я понимаю, вот это.

Там в очередной раз то ли поломали, то ли не поломали LastPass

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

Там в очередной раз то ли поломали, то ли не поломали LastPass. Поэтому не грех поворчать про менеджеры паролей. Менеджер паролей штука безусловно полезная, поскольку позволяет использовать пароли достаточной длины и сложности. Однако, к популярным, даже среди безопасников, менеджерам паролей есть вопросики.

1. Это странно, если менеджер паролей проприетарный, т.к. непонятно как фактически пароли хранятся и нет ли там бекдора/универсального ключа/тайного способа делать перебор мастер-пароля очень быстро. Если инструмент популярный и понятно кто его разрабатывает и где этот кто-то живет, то в отсутствие этого всего поверить тем более сложновато.
2. Это странно, когда менеджер паролей опенсурсный, но настолько навороченный, что просмотреть его код глазами за разумное время невозможно. Чем больше сложного кода, тем выше вероятность, что там что-то есть из п.1
3. Это странно, когда менеджер паролей хранит какие-то данные в облаке вендора.

Лично я пользуюсь своим проектом Barapass, который накидал года 2 назад (подробнее в блоге 1,2). Консольный. Работает в Windows, Linux, MacOS. Команд минимум: расшифровать и использовать файлик, искать параметр в файле с последовательным копированием найденных значений в буфер, расшифровать файл в текстовый для редактирования, зашифровать текстовый файл. Честно скажу, редактировать и добавлять новые параметры не особо удобно, но в остальном вполне норм.

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

И снова про нестабильных зарубежных 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 Завершающие слова.