2022-11-27

Schrödingers Software Bill of Materials (SBOMs)

 

Schrödingers Software Bill of Materials (SBOMs) or the Emperors new Clothes

Let me start saying that the work done by several individuals and companies on SBOMs is extremely valuable and impressive. The archaeology on ancient stuff where the source code no longer exist is important work that we all should support. An example of that is EMBA [1]

 

 

Software Bill of Materials. From the CISA website [2]:

A “software bill of materials” (SBOM) has emerged as a key building block in software security and software supply chain risk management. A SBOM is a nested inventory, a list of ingredients that make up software components. 

 

Having said that, we really need vendors to openly share what building blocks they’re using while at the same time realizing that they will fight it tooth and nail as it is likely to be a) problematic for a lot of them as they sometimes don’t know themselves* and b) will highlight that a huge percentage is based on repackaged open source tools and that some vendors are in violation of licensing agreements and don’t support the maintainers.

 

So the onus is on us – the companies and individuals relying on those vendors – to make them contractually obliged to provide complete and detailed SBOMs every time and not let them get away with manipulating the authorities into accepting that it’s something that a third party maintains - providing, what they would call, assurance that everything is secure and well maintained. Otherwise we’ll end up with “Schrödingers SBOM” and pay extra for it.

 

And sorry, I don’t buy the “we need to protect our intellectual property” argument, especially not for critical infrastructure – some of us want to protect critical infrastructure and would still buy the knowledge and products that help us do just that – problem is we might realize that some vendors really do not provide much added value, but that's a good thing as it’ll boost quality and fair competition.

We should have learned by now that Security through Obscurity isn't working** 

All in my opinion of course.


* Remember HeartBleed, Log4Shell, J4Shell, and so on.

** Unless used actively for deception but that is something completely different.

 

[1] EMBA from securefirmware.de: https://www.securefirmware.de/

[2] https://www.cisa.gov/sbom

2022-11-12

Live Remote Packet Analysis

WireShark and TcpDump over SSH

Quick and dirty bash script to start TCPDump on remote host and shovel the data back to WireShark over SSH.

Note: Don't do this over links that are already saturated, and ESPECIALLY not on networks running deterministic and/or real time systems/processes.
 

 

How to use

The script is rather simple but may take up to 5 inputs

.\WoS.sh RemoteHost RemoteInterface RemotePort RemoteUser RemoteKey

Only the first is required. However they all are:

RemoteHost: The host you want to capture packets on.

RemoteInterface: The interface on the remote host on which you want to capture packets. Uses "any" if not specified.

RemotePort: The SSH port. Uses Port 22 if not specified.

RemoteUser: The user that runs tcpdump on RemoteHost.

RemoteKey: The SSH needed to access RemoteHost

Prerequisites

You'll need the following on these systems, respectively:
Remote Host: tcpdump
Install with sudo apt -y install tcpdump, sudo yum install tcpdump, sudo pacman -S tcpdump, or whatever works on your distro.

Your System: WireShark (and SSH).
See above, however replace tcpdump with wireshark.

BASH Script on GitHub