The US Department of Health and Human Services (HHS) has launched a website for its 405(d) Aligning Health Care Industry Security Approaches Program. The site offers cybersecurity resources for the healthcare sector, including recommended products, tools, and mitigations.
https://healthitsecurity.com/news/hhs-launches-new-website-to-align-healthcare-cybersecurity
https://healthitsecurity.com/news/hhs-launches-new-website-to-align-healthcare-cybersecurity
HealthITSecurity
HHS Launches New Website to Align Healthcare Cybersecurity
HHS launched a website for the 405(d) Program, which is made up of a task force focused on aligning healthcare cybersecurity approaches across the sector.
8 лет у тк 362 ушло на выпуск новой редакции гост 27001, а тут новая на подходе. ещё 8 лет?....
https://blog.ansi.org/anab/changes-new-iso-iec-27001-iso-iec-27002/
https://blog.ansi.org/anab/changes-new-iso-iec-27001-iso-iec-27002/
The ANSI Blog
Changes in the New ISO/IEC 27001 and ISO/IEC 27002 - ANAB Blog
Changes to the new ISO/IEC 27001/27002, coming in 2022 and 2023, will be vast for information security management systems.
Forwarded from Security Wine (бывший - DevSecOps Wine) (Denis Yakimov)
Vulnerability subsprition
Возвращаюсь к написанию постов после долгого перерыва. Сегодня я бы хотел поднять тему оперативного информирования о новых уязвимостях в продуктах, которые вы используете (а их, как правило, очень много, особенно в контексте разработки и DevOps).
Вариант #1 - подписаться на CVE
Есть множество сервисов, где это можно сделать. Один из них - opencve.io. Сервис абсолютно бесплатный, можно подписаться на определенного вендора или продукт с отбивками на почту. Достаточно удобно, но наблюдаются задержки в 1-2 дня.
Вариант #2 - узнавать о новых уязвимостях от первоисточника.
Информация о важных обновлениях, решающих вопросы безопасности, может содержаться в еженедельных отчетах вендоров через их официальные страницы (как, например, страница релизов на примере Gitlab). Здесь мы имеем очевидную проблему c отсутствием унификации поступающей информации. В случае, если продукт open source и он находится на Github или Gitlab, то здесь у нас есть возможность отслеживать уязвимости через страницу Issues. Так, например, чтобы узнавать раньше всех о найденных уязвимостей Kubernetes, надежнее всего подписаться на label
Вариант #3 - воспользоваться агрегатором
Другой вариант - воспользоваться сервисами вроде Vulners. Vulners, помимо возможности отслеживания CVE, предоставляет язык запросов, на результаты которого можно подписываться. Например, запрос
В заключение хочу поделиться также интересным ресурсом - cvetrends.com, который собирает информацию о "хайповых" CVE из twitter.
#dev #ops
Возвращаюсь к написанию постов после долгого перерыва. Сегодня я бы хотел поднять тему оперативного информирования о новых уязвимостях в продуктах, которые вы используете (а их, как правило, очень много, особенно в контексте разработки и DevOps).
Вариант #1 - подписаться на CVE
Есть множество сервисов, где это можно сделать. Один из них - opencve.io. Сервис абсолютно бесплатный, можно подписаться на определенного вендора или продукт с отбивками на почту. Достаточно удобно, но наблюдаются задержки в 1-2 дня.
Вариант #2 - узнавать о новых уязвимостях от первоисточника.
Информация о важных обновлениях, решающих вопросы безопасности, может содержаться в еженедельных отчетах вендоров через их официальные страницы (как, например, страница релизов на примере Gitlab). Здесь мы имеем очевидную проблему c отсутствием унификации поступающей информации. В случае, если продукт open source и он находится на Github или Gitlab, то здесь у нас есть возможность отслеживать уязвимости через страницу Issues. Так, например, чтобы узнавать раньше всех о найденных уязвимостей Kubernetes, надежнее всего подписаться на label
kind/bug (в сочетании с triage/accepted) через desktop client (как описано в этом топике). Вариант #3 - воспользоваться агрегатором
Другой вариант - воспользоваться сервисами вроде Vulners. Vulners, помимо возможности отслеживания CVE, предоставляет язык запросов, на результаты которого можно подписываться. Например, запрос
affectedSoftware.name:"nginx" OR affectedPackage.packageName:"nginx" OR cpe:nginx order:published выдаст агрегированную информацию обо всех уязвимостях, связанных с nginx.В заключение хочу поделиться также интересным ресурсом - cvetrends.com, который собирает информацию о "хайповых" CVE из twitter.
#dev #ops
NIST announces the release of a major update to Special Publication (SP) 800-160 Volume 2, Revision 1, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach.
https://csrc.nist.gov/publications/detail/sp/800-160/vol-2-rev-1/final
https://csrc.nist.gov/publications/detail/sp/800-160/vol-2-rev-1/final
CSRC | NIST
NIST Special Publication (SP) 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach
NIST Special Publication (SP) 800-160, Volume 2, focuses on cyber resiliency engineering—an emerging specialty systems engineering discipline applied in conjunction with systems security engineering and resilience engineering to develop survivable, trustworthy…
👍1
Forwarded from SecAtor
Merry Christmas!!!
В библиотеке log4j под Apache ночью вдруг нашлась 0-day уязвимость, приводящая к удаленному выполнению кода (RCE). К этому всему удовольствию прилагается рабочий PoC, опубликованный на GitHub.
На момент появления PoC у дырки не было даже CVE (сейчас уже есть - CVE-2021-44228). Известно, что уязвимость работает на куче сервисов, к примеру - Steam, iCloud и пр.
Эксплойту подвержены версии Apache log4j вплоть до 2.14.1. Сканирование сети на предмет уязвимых серверов уже идет (странно было бы ожидать другого при наличии рабочего PoC).
В качестве меры смягчения сначала предлагалось обновить log4j до версии 2.15.0-rc1, но буквально в течение нескольких часов был найден способ обхода исправления, поэтому теперь рекомендуют обновлять до 2.15.0-rc2. Кроме того, некоторые инфосек эксперты рекомендуют установить log4j2.formatMsgNoLookups в значение true.
Также LunaSec со ссылкой на китайцев говорят, что эксплойт не работает на версиях JDK выше 6u211, 7u201, 8u191 и 11.0.1.
Ну а вишенка на этом рождественском торте - эксплойт работает на всех версиях Minecraft начиная с 1.8.8.
Apache Foundation пьют валерьянку и молчат.
Merry Christmas, дорогие наши, Merry Christmas!!!
В библиотеке log4j под Apache ночью вдруг нашлась 0-day уязвимость, приводящая к удаленному выполнению кода (RCE). К этому всему удовольствию прилагается рабочий PoC, опубликованный на GitHub.
На момент появления PoC у дырки не было даже CVE (сейчас уже есть - CVE-2021-44228). Известно, что уязвимость работает на куче сервисов, к примеру - Steam, iCloud и пр.
Эксплойту подвержены версии Apache log4j вплоть до 2.14.1. Сканирование сети на предмет уязвимых серверов уже идет (странно было бы ожидать другого при наличии рабочего PoC).
В качестве меры смягчения сначала предлагалось обновить log4j до версии 2.15.0-rc1, но буквально в течение нескольких часов был найден способ обхода исправления, поэтому теперь рекомендуют обновлять до 2.15.0-rc2. Кроме того, некоторые инфосек эксперты рекомендуют установить log4j2.formatMsgNoLookups в значение true.
Также LunaSec со ссылкой на китайцев говорят, что эксплойт не работает на версиях JDK выше 6u211, 7u201, 8u191 и 11.0.1.
Ну а вишенка на этом рождественском торте - эксплойт работает на всех версиях Minecraft начиная с 1.8.8.
Apache Foundation пьют валерьянку и молчат.
Merry Christmas, дорогие наши, Merry Christmas!!!
GitHub
GitHub - tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce: Apache Log4j 远程代码执行
Apache Log4j 远程代码执行. Contribute to tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce development by creating an account on GitHub.
Forwarded from Пост Лукацкого
Интересно, что вчера, когда заканчивался SOC Forum в Москве, в Штатах прошел в онлайн-формате SOC Summit. Интересно было сравнить доклады с двух мероприятий. У нас "ура SOC", "пора покупать SOAR", "без TI SOCа нет" и все такое. У них "SOC мертв - распределенное реагирование вперед", "No Code SOAR - это реальность", "Security Intelligence вместо TI", "Автоматический анализ неструктированной информации" и т.п.