Apostolis Stergiou

Working in software engineering, I have grown increasingly aware of a pervasive issue in our modern programming landscape: the risk of supply chain attacks. To explore the topic, I have decided to build an experimental methodology and a prototype implementation. Constrained Supply Chain Vetting (CSCV) is a method for identifying and mitigating supply chain threats, focusing on accommodating the needs of different business units. At the center of this method lies its ability to prioritize security metrics per the specific requirements of each organizational division. The implementation of the “Pipe Lock” system exemplifies this method.

I envisioned Pipe Lock as a multifaceted security framework, harnessing static, metadata, and dynamic analysis techniques to safeguard the software ecosystems. The primary innovation is the CSCV methodology. Imagine running an organization with diverse units, each with unique priorities and security needs. CSCV works like an adaptable security shield that accommodates these individual requirements, adding a tailored touch to an organization’s security framework.

While conventional security methodologies like Software Composition Analysis (SCA), Static Application Security Testing (SAST), and Dynamic Application Security Testing (DAST) provide valuable insights, CSCV goes one step further. It identifies open-source vulnerabilities and customizes its configuration based on business intelligence. Additionally, Pipe Lock extends its reach to both proprietary and open source code, creating a wider security blanket.

So, how does Pipe Lock work? The static analysis component is like a watchdog, sniffing out known threats in packages, such as cross-site scripting and SQL injection. Then, there’s the dynamic analysis component, which examines packages’ behavior during execution, like a detective observing a suspect. The metadata analysis component provides the context, shedding light on the package’s origin and authors. Last but not least, we have third-party feedback, which essentially crowdsources intelligence, reinforcing the power of our detection mechanisms.

Still, I am aware that no solution is perfect. The Pipe Lock implementation faces the daunting task of detecting ever-evolving supply chain attacks. It also shows limited support for package managers other than RubyGems and programming languages, but I see this as an opportunity for future expansion. There are also ethical implications, such as ensuring the protective measures do not create an intrusive monitoring culture.

The Pipe Lock system is my attempt to provide an additional layer of security in an era where software supply chain attacks are on the rise. As with any experimental project, challenges are part of the journey, but I am eager to learn from them and continuously improve this system. Ultimately, the goal is to create a resilient software ecosystem where creativity thrives without fear of supply chain attacks. Combining static, metadata, dynamic analysis, and other input sources, such as third-party tools, the CSCV methodology identifies and ranks software supply chain risks while accommodating diverse business needs.

Building on related work, such as OWASP Dependency-Check, and Grafeas, Pipe Lock introduces novel features for a customizable solution. Using CUE, an open-source constraint language and API-driven architecture enable integration with many IT systems and real-time adjustments. A possible extension is integrating machine learning techniques, large language models, and natural language processing. Recent lab results and research support the potential of large language models (LLMs) in the context of code security [Large Language Models for Code: Security Hardening and Adversarial Testing]. For instance, the research presents an approach that allows controlled code generation based on a given boolean property, steering program generation toward secure or vulnerable code. By leveraging similar approaches, the Pipe Lock system could analyze code comments and documentation using large language models, revealing hidden discrepancies between the code and its description.

Over the past few months, I had the privilege to immerse myself in Linux expert training. Guided by the expertise of Michael Kerrisk, the author of The Linux Programming Interface, I coded and philosophized my way through the first principles of the Linux world.

The first training involved the operating system architecture and low-level interfaces needed to build Linux-based systems. The five-day intensive training was an excellent opportunity to dive deep into the power of epoll, signals, Linux APIs, and multiple practical use cases, such as implementing non-blocking servers with an efficient thread count.

The second training was a journey into the depths of low-level Linux privileged applications and containers, virtualization, and sandboxing. By the end of this training, I could review Docker’s and Podman’s architecture decisions with detailed arguments (that daemon!). This intensive, four-day course was a real eye-opener. Before it, and as an example, I thought I had a low-level understanding of Linux capabilities or the UTS namespace. However, Michael’s training offered many new insights into the principles behind these features. One of the course’s highlights was building containers from scratch after understanding the workings of namespaces, cgroups, seccomp, and more.

When I was reading the observations on the challenger shuttle disaster https://science.ksc.nasa.gov/shuttle/missions/51-l/docs/rogers-commission/Appendix-F.txt, I begun wondering about the value of consensus when we are challenged to solve a wicked and novel problem. The shuttle was built using data and there was consensus on how and what to build, or at least enough consensus to create agreements on which processes to follow.

I am quoting the conclusions of the observations here:

If a reasonable launch schedule is to be maintained, engineering often cannot be done fast enough to keep up with the expectations of originally conservative certification criteria designed to guarantee a very safe vehicle. In these situations, subtly, and often with apparently logical arguments, the criteria are altered so that flights may still be certified in time. They therefore fly in a relatively unsafe condition, with a chance of failure of the order of a percent (it is difficult to be more accurate). Official management, on the other hand, claims to believe the probability of failure is a thousand times less. One reason for this may be an attempt to assure the government of NASA perfection and success in order to ensure the supply of funds. The other may be that they sincerely believed it to be true, demonstrating an almost incredible lack of communication between themselves and their working engineers. In any event this has had very unfortunate consequences, the most serious of which is to encourage ordinary citizens to fly in such a dangerous machine, as if it had attained the safety of an ordinary airliner. The astronauts, like test pilots, should know their risks, and we honor them for their courage. Who can doubt that McAuliffe was equally a person of great courage, who was closer to an awareness of the true risk than NASA management would have us believe? Let us make recommendations to ensure that NASA officials deal in a world of reality in understanding technological weaknesses and imperfections well enough to be actively trying to eliminate them. They must live in reality in comparing the costs and utility of the Shuttle to other methods of entering space. And they must be realistic in making contracts, in estimating costs, and the difficulty of the projects. Only realistic flight schedules should be proposed, schedules that have a reasonable chance of being met. If in this way the government would not support them, then so be it. NASA owes it to the citizens from whom it asks support to be frank, honest, and informative, so that these citizens can make the wisest decisions for the use of their limited resources. For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.

This reminds me of software engineering. We create agreements and processes which we follow and then we feel secure with our work if the checklist is complete. If the checklist is completed, then the system must be reliable, robust, maintainable and safe.

I disagree that consensus, checklists and data (I will name these “the agreements toolkit”) are enough for building complex reliable and fault tolerant systems. Such systems include wicked problems that require black box thinking. Definitely, the agreements toolkit is valuable as for example it enables teams to iterate fast and solve most problems fast and efficiently. But, when the agreement toolkit is all we have and trust for solving wicked problems then it leads to consensus optimisation.

What if instead we chose to optimise for decisions? Based on these observations and as an experiment I will start having post-mortems (which I will call pre-mortems) not only when things go wrong but also after successful projects and releases. Behind every success there is luck and things that were never optimised. With pre-mortems I want to find out what was the role of luck in the project’s success and what issues remained unsolved.

The SCADA acronym stands for supervisory control and data acquisition. A SCADA system, is a collection of different software and hardware components that are connected through a network. The system includes inputs and sensors, PLCS and Remote terminal units and different human machine interfaces.

A SCADA system can use communication systems over TCP, for example the IEC 104 protocol. That protocol like DNP3 does not come with the authentication and packet verification batteries included. This means it’s probably vulnerable to man in the middle attacks (hint: it is).

How would a man in the middle attack look like in such a network? We are mostly familiar with such attacks for web communications like for example we know about man in the middle attacks when a user logs into their bank web admin using an untrusted network. A man in the middle attack works similarly for SCADA systems.

Let’s suppose we have an electrical grid which uses some remote transfer units. Now let’s suppose one of these RTUs detects a faulty condition and wants to communicate the condition back to the main SCADA servers. This communication is vulnerable when it’s being done over MODBUS, DNP3 or IEC 104. An attacker with enough domain knowledge will intercept the communication and will be able to modify crucial data.

For example if the communication is over TCP with IEC 104, an attacker can intercept 104 packets, modify the SPI (status) field of one packet and then route it back to the SCADA servers. This can lead to hiding the problem from the engineers and could lead eventually to economical loss or damage to the company’s image.