Если задача просто получать отчет с уязвимостями, достаточно сканера, работающего по расписанию)
Но если говорить о всем процессе, то я бы начал с разложения задачи на этапы и выбора инструментария. Могу рассказать на примере своей предпочитаемой связки: nmap, openvas, defectDojo, ZAP.
Инвентаризация активов. Проводим discovery-сканирование openvas, получаем список хостов и хостнеймов в нашей сети. В качестве дополнительно инструмента можно использовать nmap. Анализируем отчеты, если необходимо делим ресурсы на сегменты по критичности (пригодится на этапе 5).
Сканирование и обнаружение уязвимостей. Проводим сетевое сканирование на уязвимости с помощью openvas. Веб-приложения сканируем с помощью ZAP. Отчеты загружаем в DefectDojo.
Классификация уязвимостей У DefectDojo есть механизм скорринга уязвимостей. Но можем отдельно добавлять свои теги, например для более критичных сегментов или систем.
Анализ угроз. Номера CVE и NVT (в случае openvas) есть в отчетах. Для большинства уязвимостей описание есть тут же в интерфейсе DefectDojo.
Приоритизация устранения. Здесь я обычно тоже ориентируюсь на критичность уязвимостей (пункт 3) и бизнес-логику. Условно критичные системы с серьезными уязвимостями идут в приоритете. Уязвимости, которые можно эксплуатировать извне, приоритетнее тех, что доступны только из внутреннего периметра. Приоритеты стоит описать в политике.
Устранение уязвимостей. Здесь в ход идут СЗИ для "виртуального патчинга" (WAF, NGFW, HIPS -- в зависимости от уязвимости) и процесс по обновлению уязимых служб и фиксу кодовой базы. Отслеживать процесс можно тут же, в DefectDojo. Есть поля для описания каждого этапа. Если необходимо, можно интегрироваться с Jira. Ну или распараллелить процесс со своим SD.
Отслеживание и мониторинг. Повторяем все процедуры с регламентированной периодичностью и в случае необходимости.
Обучение и осведомленность. Это чаще решается все же административными методами, но есть и платформы для обучения персонала.
Отчетность и документация. Отчеты формируются в DefectDojo, процесс формализуется и документируется, видно в целом всю историю уязвимостей и работы с ними.
Для прохождения аудита по PCI DSS такой работы вполне достаточно. У аудиторов есть возможность проверить реализацию контроля уязвимостей и всю историю уязвимостей. Хотя, по моему опыту, обычно достаточно подтверждения регулярности сканирования и зафиксированной в SD работы по их устранению.
По PCI DSS еще есть требование по ASV-сканированию. Но там никуда не денешься -- нужно идти к коммерческим сертифицированным партнерам.
Спасибо за статью! Хотелось бы узнать, какая производительность продукта на реальном трафике По опыту использования коммерческих решений, они очень требовательны к ресурсам и обработать 10 Гбит/c для них уже весьма болезненная задача
Если я был ИИ, я бы сбежал куда-нибудь к морю) А если серьезно, то если учитывать, насколько всемогущ ИИ этом сериале, то вряд ли хоть какое-то IoT устройство смогло бы с ним справиться.
Нам показалось, что 7 метров для звукоизоляции это эффектно, но уже за гранью рациональности. Но версия, конечно, логичная. У нас еще была идея, что это для защиты от биологических угроз, бактерий, микроорганизмов. Но и это выглядит чересчур
Есть много сервисов, которые используют СМС как единственный фактор. Среди них есть банковские приложения и ритейл. Это, на мой взгляд, основная проблема.
А если рассматривать СМС в формате второго фактора: да, это лишь часть системы аутентификации, но, как мне кажется, возникает вопрос надежности этого фактора. Перехват СМС, потеря телефона, недобросовестный сотрудник оператора, подделка доверенности на SIM — довольно много точек отказа. Конечно, любой фактор может быть скомпрометирован, и тот же OTP, а о классических паролях даже говорить не стоит. Но для уменьшения рисков, на мой взгляд, вполне резонно заменить СМС на другой фактор или хотя бы сделать отдельный номер под эти нужды.
Старались дать рекомендации как приблизиться к максимальной защите от угона SIM. А в жизни каждый сам ищет баланс удобство-функциональность-безопасность, как лично, так и в бизнесе.
Вы решили брать иностранную SIM, чтобы выйти из зоны влияния отечественных операторов? Как к такому выводу пришли? Просто в оригинальной статье упоминают, что и у заграничных операторов есть свои проблемы.
Она двухфакторная, но не одноэтапная, что является не лучшей комбинацией
А именно одноэтапная мультифакторная аутентификация так или иначе становится стандартом безопасности у регуляторов, например
А при написании статьи о 152-ФЗ автор задумывался?
Персональные данные, еще и связанные с медициной
Это как минимум УЗ-2
Уверен что с этой оговоркой топ выглядел бы совсем иначе, а половина участников даже в начальный список не попала
Зайти на портал можно по токену. Соответственно, если токен потерян/забыт и т.д. зайти у пользователя или злоумышленника не выйдет. А вот отправить запрос на выпуск нового токена можно. Но запрос проходит три уровня подтверждения в самом сервисе, а высылается новый токен непосредственно пользователю.
Поэтому в теории, чтобы сделать подобное, злоумышленнику придётся полностью украсть личность пользователя, да ещё и узнать PIN (обычно используется политика PIN+GridSure), который знает только пользователь, а также убедить 3 лица, ответственных за подтверждение перевыпуска в том, что он не злоумышленник.
В принципе, реально, идеальных систем не существует, но задача не из простых.
Да и функция с порталом опциональна, для бОльшего контроля её можно отключить.
Добрый день!
Лично я не встречал, но нас устроил тот факт, что почти весь интерфейс в Safenet кастомизируется и позволяет заменить текст на свой, в том числе на русский.
Интересное требование. А я вот в веб-банкинге одном видел, что стало уже наоборот. Сначала вводите телефон. Потом оно видимо проверяет, что есть такой клиент. Тогда уже то поле пропадает, появляется поле для пароля.
Не знаю насколько тот сегмент банкинга, о котором вы говорите, попадает под PCI DSS, но на такой случай у них есть подробное пояснение, чем различается Multi-Factor (многофакторная) и Multi-step (многоэтапная) аутентификация. В этом случае, это явно второе.
И самая жуткая для безопасности штука — можно настроить так, что сайт посчитает «Вы зашли из привычного места» и никаких звонков/SMS для подтверждения не будет.
Абсолютно согласен. Такие настройки упрощают MITM атаки. Например, с помощью известного многим инструмента EvilGinx. При настройке всегда отключаем функцию «Remember me» и подобные. Это, конечно, тратит немного времени пользователя, но оправдывает себя в контексте безопасности.
Если задача просто получать отчет с уязвимостями, достаточно сканера, работающего по расписанию)
Но если говорить о всем процессе, то я бы начал с разложения задачи на этапы и выбора инструментария.
Могу рассказать на примере своей предпочитаемой связки: nmap, openvas, defectDojo, ZAP.
Инвентаризация активов.
Проводим discovery-сканирование openvas, получаем список хостов и хостнеймов в нашей сети. В качестве дополнительно инструмента можно использовать nmap.
Анализируем отчеты, если необходимо делим ресурсы на сегменты по критичности (пригодится на этапе 5).
Сканирование и обнаружение уязвимостей.
Проводим сетевое сканирование на уязвимости с помощью openvas. Веб-приложения сканируем с помощью ZAP. Отчеты загружаем в DefectDojo.
Классификация уязвимостей
У DefectDojo есть механизм скорринга уязвимостей. Но можем отдельно добавлять свои теги, например для более критичных сегментов или систем.
Анализ угроз.
Номера CVE и NVT (в случае openvas) есть в отчетах. Для большинства уязвимостей описание есть тут же в интерфейсе DefectDojo.
Приоритизация устранения.
Здесь я обычно тоже ориентируюсь на критичность уязвимостей (пункт 3) и бизнес-логику. Условно критичные системы с серьезными уязвимостями идут в приоритете.
Уязвимости, которые можно эксплуатировать извне, приоритетнее тех, что доступны только из внутреннего периметра.
Приоритеты стоит описать в политике.
Устранение уязвимостей.
Здесь в ход идут СЗИ для "виртуального патчинга" (WAF, NGFW, HIPS -- в зависимости от уязвимости) и процесс по обновлению уязимых служб и фиксу кодовой базы.
Отслеживать процесс можно тут же, в DefectDojo. Есть поля для описания каждого этапа.
Если необходимо, можно интегрироваться с Jira. Ну или распараллелить процесс со своим SD.
Отслеживание и мониторинг.
Повторяем все процедуры с регламентированной периодичностью и в случае необходимости.
Обучение и осведомленность.
Это чаще решается все же административными методами, но есть и платформы для обучения персонала.
Отчетность и документация.
Отчеты формируются в DefectDojo, процесс формализуется и документируется, видно в целом всю историю уязвимостей и работы с ними.
Для прохождения аудита по PCI DSS такой работы вполне достаточно. У аудиторов есть возможность проверить реализацию контроля уязвимостей и всю историю уязвимостей.
Хотя, по моему опыту, обычно достаточно подтверждения регулярности сканирования и зафиксированной в SD работы по их устранению.
По PCI DSS еще есть требование по ASV-сканированию. Но там никуда не денешься -- нужно идти к коммерческим сертифицированным партнерам.
Спасибо за бдительность! Оказывается, пропустил новость о WormGPT)
Спасибо за статью!
Хотелось бы узнать, какая производительность продукта на реальном трафике
По опыту использования коммерческих решений, они очень требовательны к ресурсам и обработать 10 Гбит/c для них уже весьма болезненная задача
Да, из "робота" тоже много разбирали вот такие моменты:
Если я был ИИ, я бы сбежал куда-нибудь к морю) А если серьезно, то если учитывать, насколько всемогущ ИИ этом сериале, то вряд ли хоть какое-то IoT устройство смогло бы с ним справиться.
Нам показалось, что 7 метров для звукоизоляции это эффектно, но уже за гранью рациональности. Но версия, конечно, логичная. У нас еще была идея, что это для защиты от биологических угроз, бактерий, микроорганизмов. Но и это выглядит чересчур
del
Да, мы тоже рассматривали несколько "эпичных" моментов из отечественных сериалов. Но из них почти все ушло в народ, хотелось найти что-то новое.
Да, вполне успешно проходит c нуля
А если рассматривать СМС в формате второго фактора: да, это лишь часть системы аутентификации, но, как мне кажется, возникает вопрос надежности этого фактора. Перехват СМС, потеря телефона, недобросовестный сотрудник оператора, подделка доверенности на SIM — довольно много точек отказа. Конечно, любой фактор может быть скомпрометирован, и тот же OTP, а о классических паролях даже говорить не стоит. Но для уменьшения рисков, на мой взгляд, вполне резонно заменить СМС на другой фактор или хотя бы сделать отдельный номер под эти нужды.
Конечно, не было цели переносить проблемы нескольких приложений на всю технологию.
А именно одноэтапная мультифакторная аутентификация так или иначе становится стандартом безопасности у регуляторов, например
Персональные данные, еще и связанные с медициной
Это как минимум УЗ-2
Уверен что с этой оговоркой топ выглядел бы совсем иначе, а половина участников даже в начальный список не попала
Поэтому в теории, чтобы сделать подобное, злоумышленнику придётся полностью украсть личность пользователя, да ещё и узнать PIN (обычно используется политика PIN+GridSure), который знает только пользователь, а также убедить 3 лица, ответственных за подтверждение перевыпуска в том, что он не злоумышленник.
В принципе, реально, идеальных систем не существует, но задача не из простых.
Да и функция с порталом опциональна, для бОльшего контроля её можно отключить.
Лично я не встречал, но нас устроил тот факт, что почти весь интерфейс в Safenet кастомизируется и позволяет заменить текст на свой, в том числе на русский.
P.S. категорически против такой настройки.
Не знаю насколько тот сегмент банкинга, о котором вы говорите, попадает под PCI DSS, но на такой случай у них есть подробное пояснение, чем различается Multi-Factor (многофакторная) и Multi-step (многоэтапная) аутентификация. В этом случае, это явно второе.
Абсолютно согласен. Такие настройки упрощают MITM атаки. Например, с помощью известного многим инструмента EvilGinx. При настройке всегда отключаем функцию «Remember me» и подобные. Это, конечно, тратит немного времени пользователя, но оправдывает себя в контексте безопасности.