https://blog.pcisecuritystandards.org/pci-dss-v4.0-a-preview-of-the-standard-and-transition-training
blog.pcisecuritystandards.org
PCI DSS v4.0: A Preview of the Standard and Transition Training
This episode previews the much-anticipated release of the PCI Data Security Standard (DSS) version 4.0, scheduled to debut at the end of March 2022.
Forwarded from RPPA PRO: Privacy • AI • Cybersecurity • IP
Forwarded from Vulnerability Management and more
Hello everyone! In this episode, I would like to talk about #Github and how to remove sensitive information that was accidentally uploaded there.
This is a fairly common problem. When publishing the project code on Github, developers forget to remove credentials: logins, passwords, tokens. What to do if this becomes known? Well, of course, these credentials must be urgently changed.
What was publicly available on the Internet cannot be completely removed. This data is indexed and copied by some systems. But wiping it from github.com is real.
Why is it not enough to just delete the file in the Github repository? The problem is that the history of changes for the file will remain and everything will be visible there. Surprisingly, there is still no tool in the Github web interface to remove the history for a file. You have to use third-party utilities, one of them is git-filter-repo.
Video: https://youtu.be/FugrD23ix50
Video2 (for Russia): https://vk.com/video-149273431_456239077
Blogpost: https://avleonov.com/2022/03/27/how-to-remove-sensitive-information-from-github-repository/
This is a fairly common problem. When publishing the project code on Github, developers forget to remove credentials: logins, passwords, tokens. What to do if this becomes known? Well, of course, these credentials must be urgently changed.
What was publicly available on the Internet cannot be completely removed. This data is indexed and copied by some systems. But wiping it from github.com is real.
Why is it not enough to just delete the file in the Github repository? The problem is that the history of changes for the file will remain and everything will be visible there. Surprisingly, there is still no tool in the Github web interface to remove the history for a file. You have to use third-party utilities, one of them is git-filter-repo.
Video: https://youtu.be/FugrD23ix50
Video2 (for Russia): https://vk.com/video-149273431_456239077
Blogpost: https://avleonov.com/2022/03/27/how-to-remove-sensitive-information-from-github-repository/
YouTube
How to remove sensitive information from a Github repository
Hello everyone! In this episode, I would like to talk about Github and how to remove sensitive information that was accidentally uploaded there.
This is a fairly common problem. When publishing the project code on Github, developers forget to remove credentials:…
This is a fairly common problem. When publishing the project code on Github, developers forget to remove credentials:…
Forwarded from Пост Лукацкого
MITRE, конечно, молодцы. Они не только 11-ю версию ATT&CK запланировали, в которой добавятся подтехники для мобильных угроз, а также новые техники для Linux и macOS (на последнюю основной акцент), но уже имеют планы и на 12-ю. В частности, к процедурам, ПО и группам, они добавят еще и кампании с указанием пострадавших стран и вертикалей, использованных в кампании групп и ПО и т.п.
Защитные меры (mitigations) и источники данных (data sources) были ранее трансформированы в отдельные объекты матрицы ATT&CK для облегчения работы с ними - анализа, фильтрации, выборки и т.п. В 11-й версии планируется добавить новый объект - методы обнаружения (detections), которые сейчас присутствуют в описаниях техник в свободной текстовой форме. Это позволит для каждой техники облегчить получение как источников данных, которые позволят обнаруживать технику, так и список методов обнаружения и нейтрализации техники. В свою очередь это поспособствует оперативному выбору как защитных мер, так и пониманию, насколько технологиями обнаружения покрыты все нужные источники и не требуется ли включить в стратегию мониторинга что-то новое.
Также в октябре матрица ATT&CK будет расширена за счет АСУ ТПшной тематики. В частности, по примеру платформ для Enterprise-версии, будут добавлены Assets, то есть специфичные для разных вертикалей промышленные системы и типы устройств. Наконец у MITRE есть планы в 12-й версии матрицы найти способы комбинировать разные матрицы (Enterprise и Mobile, Enterprise и ICS, Linux и контейнеры и т.п.).
Защитные меры (mitigations) и источники данных (data sources) были ранее трансформированы в отдельные объекты матрицы ATT&CK для облегчения работы с ними - анализа, фильтрации, выборки и т.п. В 11-й версии планируется добавить новый объект - методы обнаружения (detections), которые сейчас присутствуют в описаниях техник в свободной текстовой форме. Это позволит для каждой техники облегчить получение как источников данных, которые позволят обнаруживать технику, так и список методов обнаружения и нейтрализации техники. В свою очередь это поспособствует оперативному выбору как защитных мер, так и пониманию, насколько технологиями обнаружения покрыты все нужные источники и не требуется ли включить в стратегию мониторинга что-то новое.
Также в октябре матрица ATT&CK будет расширена за счет АСУ ТПшной тематики. В частности, по примеру платформ для Enterprise-версии, будут добавлены Assets, то есть специфичные для разных вертикалей промышленные системы и типы устройств. Наконец у MITRE есть планы в 12-й версии матрицы найти способы комбинировать разные матрицы (Enterprise и Mobile, Enterprise и ICS, Linux и контейнеры и т.п.).
Forwarded from k8s (in)security (D1g1)
Буквально вчера вышел замечательный
Авторы в документе задаются вопросом: "Is it possible, though, to have a base image without vulnerabilities?" и помогают грамотно подойти к выбору базового образа для ваших контейнеров. Основными критериями выбора/поиска являются:
- Наличие малого или нулевого количества известных уязвимостей в образе
- Плюсом будет наличие SBOM
- Плюсом будет наличие цифровой подписи
Все это в первую очередь помогает бороться с "шумом" от сканеров уязвимостей. Ведь никто не хочет разбираться с тысячами уязвимостей и еще при том, что разработчики далеко не сразу буду браться за их устранение.
whitepaper “All About That Base Image”, который посвящён безопасности популярных базовых образов - image security если хотите и уязвимостям в них.Авторы в документе задаются вопросом: "Is it possible, though, to have a base image without vulnerabilities?" и помогают грамотно подойти к выбору базового образа для ваших контейнеров. Основными критериями выбора/поиска являются:
- Наличие малого или нулевого количества известных уязвимостей в образе
- Плюсом будет наличие SBOM
- Плюсом будет наличие цифровой подписи
Все это в первую очередь помогает бороться с "шумом" от сканеров уязвимостей. Ведь никто не хочет разбираться с тысячами уязвимостей и еще при том, что разработчики далеко не сразу буду браться за их устранение.
Forwarded from ATT&CK® COMMUNITY RUSSIA CHANNEL
Релиз утилиты Control Validation Compass (CVC) — поиск аналитики из открытых проектов по техникам ATT&CK. На текущий момент в базе 9000+ правил обнаружения (Sigma, Splunk Security Content, etc) и 2100+ тестов эмуляции (Atomic Red Team, Prelude Community, etc).
Forwarded from Kubernetes и кот Лихачева
Бесплатный вебинар «Open Policy Agent», 4 апреля в 19:00.
🛡В прямом эфире поговорим про:
— Что такое Open Policy Agent (OPA) и почему за ним будущее;
— Как можно валидировать все объекты, которые создаются в Kubernetes, при помощи одного admission-controller;
— Как и чем заменить устаревший PSP, получив при этом дополнительные полезные функции;
— Как внедрить Gatekeeper в большой работающий кластер на продакшн и ничего не сломать;
— Какие подводные камни есть при внедрении OPA/Gatekeeper;
🦸♂️Спикер: Марсель Ибраев, CTO Слёрм
Инженер с 8-летним стажем, Certified Kubernetes Administrator, спикер курса Kubernetes: Мега-поток.
Дата: 4 апреля в 19.00 (мск), прямая трансляция будет в чате.
🔥Ccылка на чат вебинара: https://news.1rj.ru/str/KubernetesFree
🔥Продвинутый курс по Kubernetes: https://slurm.club/3uLEzr3
🛡В прямом эфире поговорим про:
— Что такое Open Policy Agent (OPA) и почему за ним будущее;
— Как можно валидировать все объекты, которые создаются в Kubernetes, при помощи одного admission-controller;
— Как и чем заменить устаревший PSP, получив при этом дополнительные полезные функции;
— Как внедрить Gatekeeper в большой работающий кластер на продакшн и ничего не сломать;
— Какие подводные камни есть при внедрении OPA/Gatekeeper;
🦸♂️Спикер: Марсель Ибраев, CTO Слёрм
Инженер с 8-летним стажем, Certified Kubernetes Administrator, спикер курса Kubernetes: Мега-поток.
Дата: 4 апреля в 19.00 (мск), прямая трансляция будет в чате.
🔥Ccылка на чат вебинара: https://news.1rj.ru/str/KubernetesFree
🔥Продвинутый курс по Kubernetes: https://slurm.club/3uLEzr3
Forwarded from SecAtor
Встречайте, Spring4Shell. Правда, если сравнивать обнаруженную RCE в Java Spring Framework с Log4Shell, эффект которой можно назвать бомбой, то новая 0-Day скорее всего на этом фоне будет выглядеть как связка петард.
Уязвимость удаленного выполнения кода была обнаружена в среде Spring вскоре после того, как некий китайский исследователь, который выпустил на GitHub соответствующий PoC, который вскоре после этого удалил вместе со своими аккаунтами.
Spring - достаточно популярная платформа для создания приложений на основе Java EE (Enterprise Edition), которая позволяет быстро и легко их разрабатывать, а затем и разворачивать на серверах, в том числе Apache Tomcat, в виде автономных пакетов со всеми необходимыми зависимостями.
По данным Praetorian, непропатченная уязвимость затрагивает Spring Core в Java Development Kit (JDK) версии 9 и более поздних и является обходом другой уязвимости, отслеживаемой как CVE-2010-1622, что позволяет злоумышленнику, не прошедшему проверку подлинности, выполнять произвольный код в целевой системе.
Дополнительные сведения о новой уязвимости не разглашаются, специалисты по поддержке фреймворка Spring.io, дочерняя компания VMware, вовсю работают над исправлением.
Новая бага отличается от двух предыдущих уязвимостей, раскрытых в структуре приложения на этой неделе, включая DoS-уязвимость выражений Spring Framework (CVE-2022-22950) и уязвимость доступа к ресурсам выражений Spring Cloud (CVE-2022-22963). Spring RCE вызвана небезопасной десериализацией переданных аргументов.
Praetorian также подтвердила, что ошибка зависит от определенных конфигураций для правильного использования. Для эксплуатации требуется конечная точка с включенным DataBinder (например, запрос POST, который автоматически декодирует данные из тела запроса) и сильно зависит от контейнера сервлетов для приложения.
Например, когда Spring развернут на Apache Tomcat, доступен WebAppClassLoader, что позволяет злоумышленнику вызывать геттеры и сеттеры, чтобы в конечном итоге записать вредоносный JSP-файл на диск. Однако, если Spring развернут с использованием встроенного контейнера сервлетов Tomcat, загрузчик классов — это LaunchedURLClassLoader, доступ к которому ограничен.
В некоторых конфигурациях эксплуатация этой проблемы проста, поскольку для этого требуется, чтобы злоумышленник отправил созданный запрос POST в уязвимую систему.
По мнению специалистов Flashpoint, первоначальный анализ новой уязвимости выполнения кода в Spring Core предполагает, что ее влияние может быть несерьезным. Для эксплуатации уязвимости злоумышленникам необходимо будет найти и идентифицировать экземпляры веб-приложений, которые на самом деле используют DeserializationUtils.
Кроме того, несмотря на общедоступность эксплойтов, Rapid7 утверждают, что в настоящее время неясно, какие реальные приложения используют уязвимую функциональность. ISAC заявили, что еще не завершили свои тесты и не могут однозначно подтвердить действительность PoC для ошибки RCE.
Вместе с тем, согласно заключению аналитика Уилла Дорманна из CERT/CC, эксплойт Spring4Shell в дикой природе все же функционирует и существуют реальные уязвимые приложения. Вообще, по данным источников BleepingComputer, уязвимость активно используется в атаках.
Поскольку для этой уязвимости в настоящее время нет исправления, настоятельно рекомендуется как можно скорее реализовать меры по смягчению атак, связанных с ограничениями функционала Spring Core DataBinder.
Уязвимость удаленного выполнения кода была обнаружена в среде Spring вскоре после того, как некий китайский исследователь, который выпустил на GitHub соответствующий PoC, который вскоре после этого удалил вместе со своими аккаунтами.
Spring - достаточно популярная платформа для создания приложений на основе Java EE (Enterprise Edition), которая позволяет быстро и легко их разрабатывать, а затем и разворачивать на серверах, в том числе Apache Tomcat, в виде автономных пакетов со всеми необходимыми зависимостями.
По данным Praetorian, непропатченная уязвимость затрагивает Spring Core в Java Development Kit (JDK) версии 9 и более поздних и является обходом другой уязвимости, отслеживаемой как CVE-2010-1622, что позволяет злоумышленнику, не прошедшему проверку подлинности, выполнять произвольный код в целевой системе.
Дополнительные сведения о новой уязвимости не разглашаются, специалисты по поддержке фреймворка Spring.io, дочерняя компания VMware, вовсю работают над исправлением.
Новая бага отличается от двух предыдущих уязвимостей, раскрытых в структуре приложения на этой неделе, включая DoS-уязвимость выражений Spring Framework (CVE-2022-22950) и уязвимость доступа к ресурсам выражений Spring Cloud (CVE-2022-22963). Spring RCE вызвана небезопасной десериализацией переданных аргументов.
Praetorian также подтвердила, что ошибка зависит от определенных конфигураций для правильного использования. Для эксплуатации требуется конечная точка с включенным DataBinder (например, запрос POST, который автоматически декодирует данные из тела запроса) и сильно зависит от контейнера сервлетов для приложения.
Например, когда Spring развернут на Apache Tomcat, доступен WebAppClassLoader, что позволяет злоумышленнику вызывать геттеры и сеттеры, чтобы в конечном итоге записать вредоносный JSP-файл на диск. Однако, если Spring развернут с использованием встроенного контейнера сервлетов Tomcat, загрузчик классов — это LaunchedURLClassLoader, доступ к которому ограничен.
В некоторых конфигурациях эксплуатация этой проблемы проста, поскольку для этого требуется, чтобы злоумышленник отправил созданный запрос POST в уязвимую систему.
По мнению специалистов Flashpoint, первоначальный анализ новой уязвимости выполнения кода в Spring Core предполагает, что ее влияние может быть несерьезным. Для эксплуатации уязвимости злоумышленникам необходимо будет найти и идентифицировать экземпляры веб-приложений, которые на самом деле используют DeserializationUtils.
Кроме того, несмотря на общедоступность эксплойтов, Rapid7 утверждают, что в настоящее время неясно, какие реальные приложения используют уязвимую функциональность. ISAC заявили, что еще не завершили свои тесты и не могут однозначно подтвердить действительность PoC для ошибки RCE.
Вместе с тем, согласно заключению аналитика Уилла Дорманна из CERT/CC, эксплойт Spring4Shell в дикой природе все же функционирует и существуют реальные уязвимые приложения. Вообще, по данным источников BleepingComputer, уязвимость активно используется в атаках.
Поскольку для этой уязвимости в настоящее время нет исправления, настоятельно рекомендуется как можно скорее реализовать меры по смягчению атак, связанных с ограничениями функционала Spring Core DataBinder.
Forwarded from AlexRedSec
ISACA в марте выпустила интересный и объемный отчет о состоянии дел в сфере кибербезопасности. Рассказали об уровне подготовки кадров, образовании, бюджетах, киберугрозах и ожиданиях.
Главные выводы:
🔶 У 63% опрошенных организаций имеются сложности с закрытием вакансий по направлению КБ.
🔶 60% организаций сообщают, что испытывают проблемы с удержанием специалистов по КБ.
🔶 Софт-скиллы и облачные вычисления - проблема у современных специалистов по КБ.
🔶 Все чаще организации не обращают внимание на наличие высшего образования в области КБ.
🔶 42% опрошенных заявили, что удовлетворены финансированием программ КБ, а 55% ожидают увеличения бюджетов.
🔶 82% респондентов говорят, что руководство видит ценность в проведении оценки рисков, но только 41% организаций проводит ежегодную оценку киберрисков.
🔶 Только 51% опрошенных допускает, что их компания столкнется с кибератаками в будущем. Оптимистичненько...
Главные выводы:
🔶 У 63% опрошенных организаций имеются сложности с закрытием вакансий по направлению КБ.
🔶 60% организаций сообщают, что испытывают проблемы с удержанием специалистов по КБ.
🔶 Софт-скиллы и облачные вычисления - проблема у современных специалистов по КБ.
🔶 Все чаще организации не обращают внимание на наличие высшего образования в области КБ.
🔶 42% опрошенных заявили, что удовлетворены финансированием программ КБ, а 55% ожидают увеличения бюджетов.
🔶 82% респондентов говорят, что руководство видит ценность в проведении оценки рисков, но только 41% организаций проводит ежегодную оценку киберрисков.
🔶 Только 51% опрошенных допускает, что их компания столкнется с кибератаками в будущем. Оптимистичненько...
👍1