Про RedCheck с web-интерфейсом и агентное сканирование Windows

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

Про RedCheck с web-интерфейсом и агентное сканирование Windows

Про RedCheck с web-интерфейсом и агентное сканирование Windows. Занимался на днях разворачиванием и тестированием RedCheck-а. В принципе всё норм. Единственное, что при установке с Web-интерфейсом и Rest API требуется выполнить довольно много ручных операций:

1. Установка СУБД и создание пользователя
2. Установка Web-сервера IIS
3. Установка Microsoft .NET Framework
4. Установка Microsoft .NET Core
5. Установка серверного компонента
6. Установка консоли управления (пользовательского интерфейса)
7. Включение возможности Windows-авторизации*
8. Включение обработки HTTPS-соединений*
9. Установка службы синхронизации
10. Установка службы сканирования

Кажется, что большую часть операций можно было бы засунуть в один инсталлер. Но понятное дело, что таких доработок делать не будут, т.к. у АЛТЭКС-СОФТа сейчас в первую очередь стоит задача миграции на Linux. В целом, руководство по установке понятное и подробное. Только в одном месте была проблема с ошибкой в PowerShell-скрипте, но надеюсь поправят. Инсталлеры самих компонентов RedCheck удобные, по сути жмёшь "далее-далее". Часть операций (со *) я пропустил, т.к. для теста это не требовалось.

Теперь про агентное сканирование. Это вообще так себе термин, потому что под ним можно понимать разное:

1. Ставишь агент на таргет-хост, агент сам подключается к серверу (облачному или on-prem) и либо сам отдаёт в него какие-то данные для анализа, либо забирает у него какие-то задачки на выполнение и отдаёт результаты. Профит, что вообще не нужно париться учётками и тем доступен ли сейчас таргет-хост в сети для сканирования или нет (в первую очередь ноутбуков касается). Так работает Qualys, Tenable, Defender for Endpoint.

2. Ставишь агент на таргет-хост, агент сам ничего не делает, но когда к нему подключается сервер, то он делает аутентификацию через этого агента с использованием некоторых внутренних сертификатов. Также профит к том, что не нужно париться доменными учётками и их возможными утечками. Так работает Scan Assistant от Rapid7.

3. Ставишь агент на таргет-хост, агент сам ничего не делает, но когда к нему подключается сервер, то аутентификация проходит через локальную учётку хоста или доменную учётку. В этом случае по сути просто реализуется альтернатива традиционным безагентным транспортам WMI и WinRM.

И вот в RedCheck реализуется именно третий тип агентного сканирования. Позиционируется он так:

"Агент сканирования – компонент RedCheck, предназначенный для сканирования хостов, ограниченных политикой ИБ организации (например, запрет или ограничение использования WMI, WinRM, отсутствие возможности использовать УЗ администратора), а также для обеспечения быстродействия и повышенной надёжности сканирования. Данный компонент работает только по запросу от сервера сканирования в рамках назначенной задачи аудита."

Плюсом тут идёт быстрота, экономия канала и максимальная функциональность проверок. Сканирование идёт от имени Системы. Но для подключения учётка (локальная или доменная) всё равно нужна. Эта учётка может не иметь права администратора на хосте, но она должна быть в группе REDCHECK_ADMINS. То есть риски компрометации такой учётки будут ниже, но было бы удобнее, если бы она вовсе не требовалась. С другой стороны, в таком случае появлялись бы вопросы к процедуре аутентификации сервера на таргет-хосте с агентом, всё-таки порт агента наружу выставлен и это теоретически возможный вектор атаки. Процесс аутентификации по учётке всё-таки проще и прозрачнее. В общем, здесь вопрос спорный. 🙂 Ну и, независимо от способа аутентификации, просканировать с помощью такого "транспортного" агента можно будет только те хосты, до которых мы сможем дотянуться непосредственно во время выполнения задачи сканирования, т.е. основная проблема безагентных сканов остаётся.

Поэтому имейте в виду возможные варианты реализации агентного сканирования на уязвимости и заранее задавайте вопросы VM-вендорам. 😉

Про Apple Vision Pro

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

Про Apple Vision Pro

Про Apple Vision Pro. Я периодически возвращаюсь к концепции "мира без тайн". Что если всё что видит и слышит человек будет постоянно фиксироваться и сохраняться? Что если это станет абсолютной нормой, а отсутствие записи за какой-то промежуток времени будет считаться основанием для подозрений? Что если делать такие записи общедоступными также станет нормой?

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

Это традиционное, инстинктивное понимание privacy пока ещё сдерживает развитие "мира без тайн". Пока маркетологи американского бигтеха не внушат обывателю, что носить на голове постоянно включенные камеры это нормально и прогрессивно. Как и попадать в их объективы. У Google с их Glass в 2013-ом не получилось. Получится ли через 10 лет у Apple с их… Очками для дайвинга и батарейкой на верёвочке? 😅 В текущем виде вряд ли. Но не всё сразу. Если у кого и получится сделать подобные устройства мейнстримом, так это будут Apple с их супер-податливой фанбазой.

Не успели решить что же делать с необходимостью откуда-то брать Temporal и Environmental метрики CVSS 3 (3.1) для оценки критичности по ФСТЭК, как грядет CVSS 4.0, где всё переделали

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

Не успели решить что же делать с необходимостью откуда-то брать Temporal и Environmental метрики CVSS 3 (3.1) для оценки критичности по ФСТЭК, как грядет CVSS 4.0, где всё переделалиНе успели решить что же делать с необходимостью откуда-то брать Temporal и Environmental метрики CVSS 3 (3.1) для оценки критичности по ФСТЭК, как грядет CVSS 4.0, где всё переделали

Не успели решить что же делать с необходимостью откуда-то брать Temporal и Environmental метрики CVSS 3 (3.1) для оценки критичности по ФСТЭК, как грядет CVSS 4.0, где всё переделали. 😅 Доступно краткое описание изменений и более детальная презентация. На скрине калькулятора не показали групп Temporal (теперь называется Threat) и Environmental, но они остались в несколько измененном виде. Новая Supplemental Metric Group не влияет на общий расчёт скора CVSS-BTE (Base + Threat + Environmental). Ждем подробностей после 8 июня.

Посмотрел карту компетенций специалиста по ИБ от Positive Technologies

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

Посмотрел карту компетенций специалиста по ИБ от Positive TechnologiesПосмотрел карту компетенций специалиста по ИБ от Positive TechnologiesПосмотрел карту компетенций специалиста по ИБ от Positive Technologies

Посмотрел карту компетенций специалиста по ИБ от Positive Technologies. Что там с VM-специалистами? Карту презентовали 13 марта, но мне она только сейчас на глаза попалась. К сожалению, по PDF-ке нельзя искать, поэтому приходится смотреть только глазками.

Есть 4 специализации как-то связанные с уязвимостями:
- "Аналитик по оценке уязвимостей (пентенстер)" в группе "Мониторинг событий ИБ и реагирование на события ИБ"
- "Аналитик данных в области эксплуатации уязвимостей информационных систем" в группе "Аналитика ИБ"
- "Аналитик данных об уязвимостях эксплуатируемого ПО (разведка)" в группе "Аналитика ИБ"
- "Аналитик данных об уязвимостях эксплуатируемой сетевой инфраструктуры (разведка)" в группе "Аналитика ИБ"

2 последние специализации можно было бы определить как Vulnerability Intelligence, но обязанности там какие-то совсем загадочные. Что-то на редтимовском видимо. 🙂

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

Поэтому я бы сделал так:

1. Приписку "пентестер" перенес в специальность "Аналитик данных в области эксплуатации…"
2. Обязанности "Измеряет эффективность многослойной архитектуры защиты" тоже перенес бы в специальность "Аналитик данных в области эксплуатации…". Оценивать эффективность EDR-ов тоже пентестерская тема.
3. "Аналитик по оценке уязвимостей" переименовал бы в "Специалист по управлению уязвимостями". Если есть специалист по реагированию на инциденты, то чего бы не быть специалисту по управлению уязвимостями. 😉
4. Добавил бы этому "Специалисту по управлению уязвимостями" обязанностей по работе с уязвимостями в рамках руководства ФСТЭК: мониторинг известных уязвимостей, оценка применимости, оценка критичности уязвимостей, определения методов и приоритетов устранения, постановка задач на устранение, контроль устранения. Также добавил бы того, что нет в этом руководстве, но что критично: оценка качества детектирования уязвимостей средствами анализа защищенности и оценка покрытия инфраструктуры организации VM-процессом.
5. Обязанности "Выполняет оценку систем и сетей…" дополнил бы фразой "в части процесса управления уязвимостями", а то слишком общо получается и напоминает уже IT-аудит.

И вот в таком виде можно было бы жить. 🙂

Давайте вам лучше покажу чем я в свободное время люблю заниматься помимо ИБ

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

Давайте вам лучше покажу чем я в свободное время люблю заниматься помимо ИБ

Давайте вам лучше покажу чем я в свободное время люблю заниматься помимо ИБ. А то ж вы меня совсем не знаете. Мне, например, очень нравится сидеть и наигрывать стихотворения на укулельке. 🙂 Вот сегодня у меня Александр Блок.

Что в итоге делать с Триангуляцией?

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

Что в итоге делать с Триангуляцией?

Что в итоге делать с Триангуляцией? Имхо, это зависит от вашего отношения к утверждению, что Apple намеренно добавили уязвимость в iMessage.

1. Если это действительно так, то Apple это откровенно враждебный вендор и от всех их продуктов нужно планомерно и оперативно избавляться. Не только от айфонов, но и от mac-ов и т.д. Начиная, естественно с наиболее критичных мест.

2. Если же у вас есть основания полагать, что Apple здесь ни при чём, то тогда действуем как в любом кейсе с малварями. Мониторим подключения к C&C, проверяем iOS устройства с помощью утилиты от Kaspersky, если заражены, то вайпаем их, iMessage от греха отключаем, ждём и форсим обновления Apple, сотрудникам выдаём общие рекомендации по кибергигиене.

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