How to strengthen Supply Chain Security: Practical Exchange and Roadmap
Join an open, practitioner-focused roundtable for direct exchange on supply chain security. This session offers a concise overview of core concepts, e.g. SBOM, CSAF, and VEX and digs into the processes behind them: how to obtain, process and apply information to improve security across the supply chain.
We will examine:
How SBOM, CSAF and VEX relate and why version-level detail matters.
The practical value of an SBOM and why it’s increasingly required by law and IT procurement.
How to create and consume SBOMs?
Methods to identify dependencies in the context of vulnerabilities.
Approaches to triage: not all vulnerabilities affect every stakeholder equally.
Techniques to analyze vulnerabilities and identify affected products and product families.
Sources of vulnerability information and how to map data unambiguously to products and specific software versions.
Reporting obligations: where and how to disclose vulnerabilities.
Tools and automation that help manage information volume and complexity.
Technical, organizational and personnel challenges to achieving end-to-end supply chain security.
The role of AI in supply chain security.
How do we protect ourselves from malicious actors / infected dependencies?
The Cyber Resilience Act (CRA): implications for companies, products and consumers, the CRA roadmap, and concrete deadlines and actions.
We will show a live demonstration of the whole process, e.g. covering the consumption of SBOMs, vulnerability identification and assessment, creation of VEX documents.
This roundtable is designed for security practitioners, product owners, compliance officers and decision-makers who want actionable guidance and peer discussion. Expect candid conversation, real-world examples and next steps you can take to strengthen resilience across your supply chains.
After seven years, we’re publishing a new macOS hardening guide. Fully updated,
modernized, and now publicly available on
GitHub
as
Markdown
and on our website as
PDF.
The previous guide, written for macOS Mojave (10.14), reflected a very different
macOS security model. At the time, hardening often meant working around the
operating system, manually enforcing controls, and compensating for missing
platform guarantees. That guide served its purpose, but the platform has
fundamentally changed since then.
In this blog post, we are sharing summaries of talks from the Hack in the Box
Conference in Amsterdam (HITBSecConf2023), the final HITB conference in
Amsterdam. Before we do that, however, we would like to extend a heartfelt thank
you to the organizers of the conference for putting together such an insightful
and engaging event.
Dr. Bramwell Brizendine – Windows Syscalls in Shellcode: Advanced Techniques for Malicious Functionality
The talk by Bramwell Brizendine covered the topic of syscall usage in shell
code. The general idea here is to hide from AV/EDR systems by not using APIs
such as CreateProcessA, which may be monitored, but to directly call into the
corresponding kernel functions. This can be accomplished for example with the
syscall CPU instruction (see 1, 2 and 3 for more information). While
this technique is not perfectly stealthy and can still be detected (e.g., with a
kernel driver), it circumvents at least inline-hooks in user space. Another
downside is the effort of building shell code that directly uses syscalls.
Besides more overhead in preparing everything for the syscall (for example
manually creating appropriate structs), the correct syscall ID must be gathered,
which can change between kernel versions.
The Federal Office for Information Security (BSI) aims to sensitize
manufacturers and the public regarding security risks of networked medical
devices in Germany. In response to the often fatal security reports and press
releases of networked medical devices, the BSI initiated the project
Manipulation of Medical Devices (ManiMed) in 2019. In this project, a security
analysis of selected products is carried out through security assessments
followed by Coordinated Vulnerability Diclosure (CVD) processes. The project
report was published on December 31, 2020, and can be accessed on the BSI
website
[1].
The Federal Office for Information Security (BSI) aims to sensitize
manufacturers and the public regarding security risks of networked medical
devices in Germany. In response to the often fatal security reports and press
releases of networked medical devices, the BSI initiated the project
Manipulation of Medical Devices (ManiMed) in 2019. In this project, a security
analysis of selected products is carried out through security assessments
followed by Coordinated Vulnerability Diclosure (CVD) processes. The project
report was published on December 31, 2020, and can be accessed on the BSI
website 1.
The Federal Office for Information Security (BSI) aims to sensitize
manufacturers and the public regarding security risks of networked medical
devices in Germany. In response to the often fatal security reports and press
releases of networked medical devices, the BSI initiated the project
Manipulation of Medical Devices (ManiMed) in 2019. In this project, a security
analysis of selected products is carried out through security assessments
followed by Coordinated Vulnerability Diclosure (CVD) processes. The project
report was published on December 31, 2020, and can be accessed on the BSI
website1.
The Federal Office for Information Security (BSI) aims to sensitize
manufacturers and the public regarding security risks of networked medical
devices in Germany. In response to the often fatal security reports and press
releases of networked medical devices, the BSI initiated the project
Manipulation of Medical Devices (ManiMed) in 2019. In this project, a security
analysis of selected products is carried out through security assessments
followed by Coordinated Vulnerability Diclosure (CVD) processes. The project
report was published on December 31, 2020, and can be accessed on the BSI
website1.
The Federal Office for Information Security (BSI) aims to sensitize
manufacturers and the public regarding security risks of networked medical
devices in Germany. In response to the often fatal security reports and press
releases of networked medical devices, the BSI initiated the project
Manipulation of Medical Devices (ManiMed) in 2019. In this project, a security
analysis of selected products is carried out through security assessments
followed by Coordinated Vulnerability Diclosure (CVD) processes. The project
report was published on December 31, 2020, and can be accessed on the BSI
website1/
The Federal Office for Information Security (BSI) aims to sensitize
manufacturers and the public regarding security risks of networked medical
devices in Germany. In response to the often fatal security reports and press
releases of networked medical devices, the BSI initiated the project
Manipulation of Medical Devices (ManiMed) in 2019. In this project, a security
analysis of selected products is carried out through security assessments
followed by Coordinated Vulnerability Diclosure (CVD) processes. The project
report was published on December 31, 2020, and can be accessed on the BSI
website1.
With this blog post I am pleased to announce the publication of a new ERNW White Paper about the HL7 FHIR communication standard.
Introduction
Digital networking is already widespread in many areas of life. More and more medical devices are also being networked in the healthcare industry. This growth makes the development and use of new medical communication standards necessary since existing solutions can only meet the changing requirements with great effort. The HL7 FHIR standard is an example of such a medical communication standard. FHIR is said to have increased the interoperability between different medical contexts,e.g., administration, billing, and clinical care, to enable data exchange of various systems. The FHIR standard addresses the security risks associated with strongly networked communication from a large number of systems across the trust and organizational boundaries only indirectly because FHIR does not define mandatory security controls or requirements.