Understanding the Risk Associated with Open-Source Code

Before you can resolve the problems with open-source code, you need to understand the risks

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: Data Breaches | Application Security | Secure Code

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I remember coming to a new company to help them migrate to the cloud as a cloud architect and later Directory of SaaS Engineering. I reviewed their existing code base before migrating an on-premises solution to the cloud and noticed some interesting open-source libraries. One was very old and looked like it hadn’t been updated in years. It was from some no-name developer, and who knows what was in it. It existed in a security product. Perhaps the code was reviewed line for line and completely safe, but based on other experiences, likely not.

As a software professional, how do you select the open-source software you choose to use? Do you pull it off the Internet and stick it in your codebase as-is when you find something that does the job? Do you have auto-update turned on with no review, scanning, or testing when that code enters your code repository? Do you know what all those lines of code are doing? Do you monitor network traffic and system behavior after you start using it? Do you update the software? Is it even supported? Do you know who wrote it, who can update it, and how?

I’ll give you some specific strategies in this series of blog posts to reduce risk in the software you write, but first you need to understand what drives that risk.

Once someone I spoke to called me “paranoid” when I told them it was not a good idea to update Java packages straight from the Internet into production — at a bank. He was probably more respected at that company as he was, first of all, a guy and, second of all had been there longer than me. My opinion probably held little weight as I did not hold a security title at the time, nor did I advertise my past experiences with data breaches. He has since come around and sent me a message about the recognition that security is a bit challenging. He is a truly wonderful person and a friend of mine.

I probably didn’t have time to explain why it was a risk because it’s not a simple answer. People with no experience in security come at you and challenge you, and it’s like how do I explain 20 years of experience in five minutes to convince this person what they are doing is not a good idea? And even if you do, sometimes they don’t believe you, or worse, they don’t care. Sometimes politics are involved — people want to “win” instead of choosing the best solution. All these factors come into play when you are dealing with designing software systems that leverage open-source code.

Later, I had the opportunity to explain some cybersecurity basics to executives at the company in presentations related to the design of a new risky file-upload software system assigned to my team. An architect wanted to use an internal system for sensitive documents which had absolutely no encryption of the files. I also knew my team didn’t understand the risk, and obviously, neither did the architects. I was concerned with the storage of data, encryption in transit, integrity of the files, and uploaded malware, to name a few things. File uploads are one of the key areas where I often find security problems on penetration tests. I have spoken about issues in file upload systems at RSA.

In my presentation to the executives, I explained how malware works in simple terms and graphics. The architect had a bunch of smiley faces in his slides with nothing to address the security issues. That made me shake my head. Maybe I’m just too serious to appreciate the smiley faces (which I also saw in an advanced pentesting class but didn’t bother me as much there). But I didn’t want to be responsible for building a system that caused a serious data breach.

The architect was a nice and intelligent person, but he simply did not understand anything about security or how malware works. I was able to convince the executives to take an appropriate course of action. We did not use the system with zero encryption for sensitive files and several other attack vectors I would rather do without.

The problem was not with the people in my stories. I liked those people, and they were very smart. The problem was with the fact that neither one of them had any exposure to how malware or breaches work. No one ever explained it to them. They did not understand the risk, or how an attacker might leverage attack vectors inherent in their system architectures. No one ever explained to the developer or architect how attackers break into systems and the risks associated with their approaches.

The other problem was that the executives also had never been exposed to this information to make an appropriate decision. They may choose the solution from the person they know or like better, rather than selecting a solution that will actually prevent a security problem. Luckily I was able to illustrate the risk in a way that made sense to them.

Before you can make use of open-source code in a secure manner, you need to understand the risk and how attackers may use it against you.

For those who are still not aware of what those risks are, I refer you to my first book, Cybersecurity for Executives in the Cloud. I explain cybersecurity at the executive level, including how breaches and attacks work at a high level with lots of examples — including my own first breach of an e-commerce application I built. You’ll find 40 pages of references at the end if you want to dive deeper. Although the book says it is for executives, it’s mostly just written in a manner anyone can understand, including my non-technical aunt. I’ve had developers read it and write positive reviews for the book, so it is not restricted to any particular role in your organization.

If you don’t understand why inserting code straight from the Internet into production from random sources is a problem, you probably won’t invest the time and money necessary to resolve it properly. You may account for one attack vector in your use of open source code but not address many others. I am not going to reiterate all those risks in my software security series. I’m going to presume you understand the risk, and now you are seeking to do something about it.

Every role or level in an organization needs to understand the risk and work towards technical solutions and processes that minimize that risk. I often see presentations by developers and people teaching classes about the definition of DevOps and suggestions that layers of process just get in the way and are unnecessary. Clearly, those people have never dealt with a serious data breach or security incident, nor do they understand what it takes to prevent one. They likely also don’t know what it takes to deal with one after the fact.

Unfortunately, many of my customers have come to me after a security incident. I would much rather review their systems in a cloud penetration test or security assessment and make recommendations developers and DevOps teams can implement before that happens!

The problem with all these automation and DevOps solutions, books, and ideas is not that they are bad — it’s how they are implemented. They are trying to throw security processes out the window completely rather than come up with new solutions that solve all the problems in a better way.

Developers write raving reviews and clap for answers they want to hear. Of course, they do! However, the solution needs to encompass not just their own bottlenecks. It also needs to solve security governance and risk management problems. That’s also in my prior book. I’m not going to delve too much into risk assessments or governance in this series. I’m going to present some information in the upcoming posts about how an individual developer can make better use of open-source code. These things alone won’t stop data breaches. But they will help ensure you personally aren’t the root cause.

The process of explaining cybersecurity and attack vectors is not a five-minute discussion. It will likely take time to fully grasp the nature of data breaches, how and why they happen, and how to prevent them. If the security team or maybe a select number of security-minded developers in an organization are the only ones who understand this, others will still be making risky decisions. You’ll likely have developers grabbing random open-source code and sticking it into your applications all over the place. They won’t even know when something is risky.

Everyone in your organization makes decisions that impact cybersecurity risk. They need to understand how to make better decisions. I just saw an article claiming that security training isn’t working. Well, what kind of training?

Does it teach you how to think about security?
Is it the right cybersecurity training?
Who is getting the training? If only five people in your organization got security training, that’s not enough to stop a breach.
Security awareness training about phishing attacks doesn’t help you write more secure software.
Writing more secure software doesn’t help your infrastructure, networks, and overall security architecture.
Pentesting training doesn’t address governance or how you deal with security incidents.

I explain many different aspects of cybersecurity in my past book. In my 5-day training class, I tried to address all of that at a high level with a touch of software security. I’ve put that specific class on hold for a while because it was too cumbersome to maintain. A lot of the governance and risk-related material is in my book.

What I try to do now is write more frequent blog posts to help people understand the basics of security, I can do shorter security presentations on a specific topic for an organization, and I try to provide guidance developers can understand when I deliver a penetration test or security assessment report. I work with the team afterwords to explain not only what the findings mean but how to create an architecture that helps prevent them at the core rather than fixing them one at a time.

I often talk to people on security consulting calls about how to deal with open-source software from an organizational perspective. The organizational perspective has many layers. But from a software professional’s perspective, there are things you can do individually to make more secure use of open-source software.

I’m also working on some code in this series with the ultimate goal of running deployment jobs that are more secure to address supply chain risks. In addition the jobs run by the platform can be anything — such as jobs that assess security by scanning systems and configurations in your organization.

Automating Cybersecurity Metrics (ACM)

A series of blog posts on cybersecurity metrics and security automation

medium.com

In my next post I’ll walk through an example of how I use code I find online when looking to solve particular problems. But the first step to making better use of open-source software, if you haven’t done so already, is to improve your knowledge of cybersecurity in general. That way, you will better understand the risks associated with open-source software you choose to your particular application and your organization.

Next steps?

Ensure you understand the fundamentals of cybersecurity, not just the OWASP top 10 or phishing attacks.
Learn what causes data breaches and how attackers break into systems.
Learn about all the different roles in cybersecurity, as there are many.
Understand how third-party, open source, and vendor software may be used against you.
If you would like a resource that explains many of the concepts in a bit more detail but still at a level most people can understand, check out my book: Cybersecurity for Executives in the Age of Cloud.

Refactoring to reduce open source code risk

One method to make safer use scripts and code you find on the Internet