Привет! Спасибо за вопрос. Действительно, цену рассчитываем на основе анкеты, ориентируемся на количество Nodes. Можно сделать запрос через форму на сайте и получить всю информацию!
Как вы считаете, должен ли мониторинг уязвимостей быть частью Observability?
На мой взгляд да. Список CVE это просто один из типов сигналов для observability системы.
И поддается ли он автоматизации с k8s?
Посмотрите тот же упоминаемы мной Starboard operator, он при изменении ReplicaSet запускает скан прописанных там images и результат оформляет в Custom Resources под названием VulnerabilityReport. И появление данного отчета у вас в системе и есть сигнал, который вы далее уже можете обрабатывать, как хотите.
Вот опубликованы новые CVE для компонента, активно использующегося в некоторых частях нашей системы. С одной стороны, система вроде бы не изменилась (как была дырявой, так и осталась). С другой стороны, реагировать-то надо.
Хорошо собирать SBOM (тоже может быть как сигнал) для images и периодически его перепроверять, так как вы верно отметили, что со временем появляется все больше уязвимостей. Или по старинке периодически пере сканируйте свой image registry, чтобы понять какие на данный момент там есть известные уязвимости.
От бессистемной подборки инструментов, мне кажется, сам смысл подборки теряется. Очень много что можно добавить — банально то что есть в CNCF Cloud Native Interactive Landscape
А по какому принципу собирался данный список инструментов? Тут перемешаны и бесплатные утилиты и платные большие продукты (+ много чего еще нет более известного). Можно было бы предположить что это то что используется у вас внутри, но описания/переводы заставляют в этом усомниться.
Тоесть убрать из привязанного джейлбрейка (tethered jailbreak) функциональность отвечающую за mount и соотвественно стадию установки софта. Смысл в том что сделать из более мощного JB, менее мощный.
После прочтения данной статьи у меня сложилось впечатление, что можно взять привязанный джейлбрейк (tethered jailbreak) и врезать из него все что он доставляет (включая Cydia) кроме SSH и это и будет вариация rootless.
Но я соглашусь, что на последних версиях iOS для создания вариации rootless нужно меньше уязвимостей, меньшей критичности.
У вас в статье приведено деление JB на классические и Rootless. Честно я впервые вижу такое деление и привык к делению на непривязанный (untethered jailbreak) и привязанный джейлбрейк (tethered jailbreak). Я могу предположить что это одно и тоже, только у вас своя терминология. Так?
По мне данная схема логичнее и более полно отображает суть мониторинга за событиями в SOC. Есть механизмы, что собирают информацию с сети, с машин и с пользователей и это уже отправляется в SIEM:
Существует несколько подходов к категоризации атак, например, набирающая популярность MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK), но этот домен мы не будем рассматривать в наших статьях.
А не могли бы вы немного рассказать про специфику вот этого домена?
А в политике написано:
Тоесть не для "какому-либо файлу", а конкретно для "/bin/cat".
Ну и обойти эту политику можно очень просто, переименовав "/bin/cat" или скопировав или и т.д. Но это вообще проблема сигнатурного подхода в целом.
Не за что!
Привет! Спасибо за вопрос. Действительно, цену рассчитываем на основе анкеты, ориентируемся на количество Nodes. Можно сделать запрос через форму на сайте и получить всю информацию!
Почему на одну роль?
Kubernetes состоит из множества операторов и каждй из них решает свою задачу.
На мой взгляд да. Список CVE это просто один из типов сигналов для observability системы.
Посмотрите тот же упоминаемы мной Starboard operator, он при изменении ReplicaSet запускает скан прописанных там images и результат оформляет в Custom Resources под названием VulnerabilityReport. И появление данного отчета у вас в системе и есть сигнал, который вы далее уже можете обрабатывать, как хотите.
Хорошо собирать SBOM (тоже может быть как сигнал) для images и периодически его перепроверять, так как вы верно отметили, что со временем появляется все больше уязвимостей. Или по старинке периодически пере сканируйте свой image registry, чтобы понять какие на данный момент там есть известные уязвимости.
От бессистемной подборки инструментов, мне кажется, сам смысл подборки теряется. Очень много что можно добавить — банально то что есть в CNCF Cloud Native Interactive Landscape
Еще раз спасибо за материал!
После прочтения данной статьи у меня сложилось впечатление, что можно взять привязанный джейлбрейк (tethered jailbreak) и врезать из него все что он доставляет (включая Cydia) кроме SSH и это и будет вариация rootless.
Но я соглашусь, что на последних версиях iOS для создания вариации rootless нужно меньше уязвимостей, меньшей критичности.
У вас в статье приведено деление JB на классические и Rootless. Честно я впервые вижу такое деление и привык к делению на непривязанный (untethered jailbreak) и привязанный джейлбрейк (tethered jailbreak). Я могу предположить что это одно и тоже, только у вас своя терминология. Так?
А не могли бы вы немного рассказать про специфику вот этого домена?