Да согласен учёт активов и нормализация это первое с чего начинают. У меня ситуация такая, что есть MaxpatrolVM, который позволяет инвентаризировать почти все и так же задавать динамически определенные параметры для активов, например критичность. Данные скачиваются по API в формате .csv А так как активы разные я просто подогнал PDQL-запросы в MaxpatrolVM для выгрузки разных типов активов под единую структуру: VulnDiscoveryTime, AuditTime, IpAddress, Hostname, OsName, OsVersion, Release, VulnerableEntity, VulnerableEntityVersion, EntityPath, Vulnerability, VulnerabilityIssueTime, CVE, VulnDescription, HowToFix, Patch, PatchPublishDate, Severity, CVSS3, Metrics, VulnerIsTrend, HostImportance, Status
Но есть вещи которые отсутствуют в MaxpatrolVM, например наименование системы, наименование сегмента сети и другие. Вот это можно взять из других IT или ИБ систем, где они уже учитываются(например IPAM) и потом совмещать через Python-обработку перед загрузкой в базу. Но для всех это будет разная история, может быть опишу потом как выгружать по API из MaxpatrolVM.
На самом деле управление уязвимостями — это следующий этап развития, который необходим всем крупным компаниям. В таких организациях количество уязвимостей может достигать миллионов, но реальную угрозу например представляют лишь 3% из них. Логично в первую очередь сфокусироваться именно на этих 3%, а не тратить ресурсы и время на устранение оставшихся 97% прямо сейчас.
Помню, когда я работал в одной из крупнейших компаний, была проблема обновить критические системы в сжатые сроки — это было крайне сложно. А если попытаться обновить всё подряд — это просто невозможно. Ну и нужно ли трогать бизнес критическую систему сейчас, если уязвимость не представляет угрозы.
И вот тут возникает главный вопрос: как отделить эти 3% от остальных 97%? Как раз на этот вопрос я и отвечу в своих следующих статьях.
Благодарю за обратную связь. Я рад и не сомневаюсь, что команда работает ^+-v над решением и продолжает совершенствовать систему.
Но должен подчеркнуть, что этот изъян - не из числа скрытых или сложных для обнаружения, так как здесь не требуется иметь глубокие знания и опыт в эксплуатации. Все лежит буквально на поверхности и доступно не только исследователям, но и атакующим.
И возникает вопрос:
почему, при наличии в стране десятков крупнейших клиентов, пользователей - банков из ТОП-10, ресурсодобывающих компаний и участников критической инфраструктуры страны, тратящих миллиарды на информационную безопасность, этот вопрос поднимает один человек?
По вопросу хорошее замечание, согласен заказчик часто сам определяет, что для него является чувствительной информацией, но при этом на практике часто не проверяет содержимое логов.
Я думаю, проблема ещё и в том, что пользователь системы не может реально контролировать, какие данные собираются в логах и как они формируются. А со стороны разработчика чаще всего нет ни предупреждений о чувствительной информации в логах, ни возможности отключить или фильтровать ее сбор. В итоге получается, что ответственность вроде бы на заказчике, но рычагов влияния у него почти нет.
Вендору напрямую не писал, так как вендор и так в курсе и знаком с системой лучше любого из нас. Такие вопросы важно поднимать публично, потому что открытое обсуждение способствует развитию отрасли, особенно в ИБ, где культура прозрачности пока только формируется. А эта статья мой вклад в то, чтобы сделать процессы в кибербезопасности лучше и безопаснее.
Да изначально я заметил эту пролему только в диагностических логах, которые выгружаются утилитой. Но проверив весь root / каталог на сервере, кроме конфигов нашел лог файлы с паролем к СУБД в /var/lib/deployed-roles/...... Причем владелец файла root, но права естественно как это бывает у всех -rw-r--r-- то есть читать может любой пользователь оказавшись на хосте.
Так же лог файлы с паролями создаются при установке и обновлении конфигурации на сервере с ролью deployer и к ним тоже будет иместь доступ любой пользователь, оказавшись на хосте. С точки зрения харденинга ОС это не правильно их нужно затирать.
Хорошо что нет паролей к самим, сканируемым активам, они видимо хранятся только в самой СУБД и в шифрованном виде.
Все зависит от города и места работы, если брать Москву то ЗП может быть между 200-400 руб месяц. Думаю идти нужно туда, где больше нравится, не всегда ЗП является самым важным фактором. Успеха достигаешь только в том деле, которым нравится заниматься и увлечен.
Information
Rating
Does not participate
Registered
Activity
Specialization
Threat and Vulnerability Analyst, Information Security Specialist
Добрый вечер. Да я тоже сомневался сначала =) , но проверял в словаре, судя по всему через И пишется.
https://ru.wiktionary.org/wiki/приоритизация
Думаю без ИИ человечеству с этим не справиться)
Да согласен учёт активов и нормализация это первое с чего начинают. У меня ситуация такая, что есть MaxpatrolVM, который позволяет инвентаризировать почти все и так же задавать динамически определенные параметры для активов, например критичность.
Данные скачиваются по API в формате .csv А так как активы разные я просто подогнал PDQL-запросы в MaxpatrolVM для выгрузки разных типов активов под единую структуру: VulnDiscoveryTime, AuditTime, IpAddress, Hostname, OsName, OsVersion, Release, VulnerableEntity, VulnerableEntityVersion, EntityPath, Vulnerability, VulnerabilityIssueTime, CVE, VulnDescription, HowToFix, Patch, PatchPublishDate, Severity, CVSS3, Metrics, VulnerIsTrend, HostImportance, Status
Но есть вещи которые отсутствуют в MaxpatrolVM, например наименование системы, наименование сегмента сети и другие. Вот это можно взять из других IT или ИБ систем, где они уже учитываются(например IPAM) и потом совмещать через Python-обработку перед загрузкой в базу. Но для всех это будет разная история, может быть опишу потом как выгружать по API из MaxpatrolVM.
На самом деле управление уязвимостями — это следующий этап развития, который необходим всем крупным компаниям. В таких организациях количество уязвимостей может достигать миллионов, но реальную угрозу например представляют лишь 3% из них. Логично в первую очередь сфокусироваться именно на этих 3%, а не тратить ресурсы и время на устранение оставшихся 97% прямо сейчас.
Помню, когда я работал в одной из крупнейших компаний, была проблема обновить критические системы в сжатые сроки — это было крайне сложно. А если попытаться обновить всё подряд — это просто невозможно. Ну и нужно ли трогать бизнес критическую систему сейчас, если уязвимость не представляет угрозы.
И вот тут возникает главный вопрос: как отделить эти 3% от остальных 97%? Как раз на этот вопрос я и отвечу в своих следующих статьях.
Благодарю за обратную связь.
Я рад и не сомневаюсь, что команда работает
^+-vнад решением и продолжает совершенствовать систему.Но должен подчеркнуть, что этот изъян - не из числа скрытых или сложных для обнаружения, так как здесь не требуется иметь глубокие знания и опыт в эксплуатации. Все лежит буквально на поверхности и доступно не только исследователям, но и атакующим.
И возникает вопрос:
почему, при наличии в стране десятков крупнейших клиентов, пользователей - банков из ТОП-10, ресурсодобывающих компаний и участников критической инфраструктуры страны, тратящих миллиарды на информационную безопасность, этот вопрос поднимает один человек?
Я.
Может, дело не в деньгах?
По вопросу хорошее замечание, согласен заказчик часто сам определяет, что для него является чувствительной информацией, но при этом на практике часто не проверяет содержимое логов.
Я думаю, проблема ещё и в том, что пользователь системы не может реально контролировать, какие данные собираются в логах и как они формируются. А со стороны разработчика чаще всего нет ни предупреждений о чувствительной информации в логах, ни возможности отключить или фильтровать ее сбор. В итоге получается, что ответственность вроде бы на заказчике, но рычагов влияния у него почти нет.
Вендору напрямую не писал, так как вендор и так в курсе и знаком с системой лучше любого из нас. Такие вопросы важно поднимать публично, потому что открытое обсуждение способствует развитию отрасли, особенно в ИБ, где культура прозрачности пока только формируется. А эта статья мой вклад в то, чтобы сделать процессы в кибербезопасности лучше и безопаснее.
Да изначально я заметил эту пролему только в диагностических логах, которые выгружаются утилитой. Но проверив весь root / каталог на сервере, кроме конфигов нашел лог файлы с паролем к СУБД в /var/lib/deployed-roles/...... Причем владелец файла root, но права естественно как это бывает у всех -rw-r--r-- то есть читать может любой пользователь оказавшись на хосте.
Так же лог файлы с паролями создаются при установке и обновлении конфигурации на сервере с ролью deployer и к ним тоже будет иместь доступ любой пользователь, оказавшись на хосте. С точки зрения харденинга ОС это не правильно их нужно затирать.
Хорошо что нет паролей к самим, сканируемым активам, они видимо хранятся только в самой СУБД и в шифрованном виде.
Все зависит от города и места работы, если брать Москву то ЗП может быть между 200-400 руб месяц. Думаю идти нужно туда, где больше нравится, не всегда ЗП является самым важным фактором. Успеха достигаешь только в том деле, которым нравится заниматься и увлечен.