Hi, my name is Marius, and I'm involved in everything related to IT security that I can find. From cryptography to Android, hardware-related stuff to web development and reverse engineering, I'm always digging in. Currently, I'm dedicating a lot of time to Software Bill of Materials (SBOMs) in my master's thesis.
Currently, I'm working at the University of Applied Sciences Munich as a PhD student, where i work the RESICOMP project, looking into the Resiliency of operational Technology with a focus on power grids.
I studied IT-Security at the University of Applied Sciences Munich. There, I'm also running our CTF team called 'The Red Cube,' where we from time to time compete in Capture the Flag events. The events are mostly online, but we often meet at the university to work together on the challenges.
If you don't find me occupied with something from the above, it might be that I'm river-surfing on one of Munich's standing waves, riding my bike, playing volleyball, or it might be that I'm traveling.
Paper published at the 16th EEnergy conference ACM DOI
With the ongoing digitization of power grids, an increasing number of digital components are introduced into modern power grids. In this paper, we examine the IEEE 9-Bus system as a point of reference to highlight the process of moving from an electrical grid model to a cybersecurity model in order to identify relevant standards and protocols. We then leverage publicly accessible CVE data and a literature review to map discussed attack techniques for key protocols to the MITRE ATT&CK ICS Matrix and compare this information to identify similarities and differences between research findings and published vulnerabilities.
With the increasing complexity of modern software composition and an ever-growing software supply chain, where numerous resources are sourced from open-source projects, the need to keep track of these resources has arisen. Following the Log4j incident [29], the American Government passed Executive Order (EO) 14028, mandating a SBOM for all software products sold to federal government agencies. Similarly, the European Union passed the Cyber Resiliance Act (CRA), which requires an SBOM for all digital products in the European market. For these reasons, machine-readable SBOM formats have emerged in recent years, implemented by a wide variety of projects that produce and consume such SBOMs.
When discussing SBOMs, two prominent formats are widely recognized in the industry: SPDX (Software Package Data Exchange), backed by the Linux Foundation, and CycloneDx, supported by OWASP. Both schemas are compatible with various data types, such as XML, JSON, or YAML.
However, not all tools support both formats. Some tools can only generate, consume, or process one of the two. In some cases, they only support specific versions of these formats. As a result, there emerged a need to convert SBOMs between SPDX and CycloneDx.
While the schematics of an SPDX and a CycloneDX SBOM are defined by the standardization, the dependencies can look very different in the generated SBOM. The results depend on the phase of the software development lifecycle and how the generator that produces the SBOM supports all the functionalities.
I posted this as part of my projects because this Video was one of the first points where i got in touch with open source security and supply chain security. Open Source won. But there are downsides and this was the time where i was disillusioned and realised that there is a lot to do if we want to relly on open source for our modern infrastructure in the future.
With a market share of over 80%, Android has become an industry standard not only for mobile devices. Mostly Android is seen as an open-source project where everybody can contribute and review the code. However, in practice, a lot
of the Android kernel and kernel-environments code gets heavily customized by manufacturers, carriers, and vendors, which can be hard to access for review. Such customizations can pose a threat to the overall device security. Especially
drivers are affected by this customization process and can cause serious vulnerabilities. This paper will show different perspectives on the Android device development process, focusing on device drivers, how security research approaches drivers, and how attackers might exploit them.