Why your software developers can't keep you secure on their own -- and how to help them
- August 24, 2021
There are two types of companies in the world: those that are afraid of becoming the next Colonial Pipeline poster child for security issues, and those that are at risk of doing just that.
It used to be that companies worried about hackers stealing credit card data or personally identifiable information and potentially selling it on the dark web. The risk seemed minimal, and limited to reputational damage.
Not anymore.
Today we live in a very different security hellscape, where businesses are vulnerable not only to the small-time hackers that have always been there, but also to both highly skilled professional hackers and state actors with the most sophisticated of tools. And worse, even those small-time hackers now have access to commoditized tools provided by the professionals.
Part of the problem is that the Black Hat community has made significant advances in recent years. There are even structures where relatively inexperienced hackers can license ransomware tools from large criminal gangs and simply share a percentage of their "take".
Even when software developers do make their best effort to be secure, there is always the risk of human error. The Colonial Pipeline hack, which shut down the supply of oil and gas to the east coast of the US earlier this year, was enabled by a single VPN password that had been left exposed.
The technology advance toward cloud computing has its advantages and disadvantages. On the one hand, you're gaining access to the considerable security talent of cloud providers such as Amazon Web Services, Google, or Microsoft Azure. On the other hand, you're also at their mercy; if they make a mistake, you're not going to even know about it, much less be able to mitigate against it. In addition, moving to a cloud architecture increases your "attack surface".
The problem gets even worse when we think about IoT and edge deployments, which have the added disadvantage that attackers can potentially gain access to the device itself.
Ultimately, the solution is to realize that security cannot be entirely the responsibility of developers. They simply don't have the training to see all of the different security failings that are hiding in your human and computer infrastructure. That's the job of security experts. And even they can't do it alone.
Many of these checklists come from the United States federal government, which understandably has an interest in keeping American businesses safe. For example, earlier this month, the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA) released their Kubernetes Hardening Guidance to help business create secure Kubernetes clusters, and several standards exist for companies that wish to do business with the Federal government, such as Fedramp and DISA STIG.
The Defense Information Systems Agency Security Technical Information Guide (DISA STIG) is actually aimed at software vendors. Becoming STIG certified involves a long, complicated, and time-intensive process that is required in order for software to be deployed by the Department of Defense, and it's a great example of how businesses can make use of these federal efforts. DISA STIG certification may not be required, but knowing that the requirements of the STIG have been met tells you that that security infrastructure is in place.
And just as hackers have ready-made tools to work with, companies can also get protection from ready-made tools, such as products that implement the Federal Information Processing Standard (FIPS 140-2).
The Secure Software Supply Chain can have a number of different features, such as a secure image registry that limits the base images developers can use to those that have been thoroughly checked and hardened, to performing static analysis of developer code, to ensuring that software cannot run in production unless it has been cryptographically signed by these processes. This way, should someone -- either inside or outside your company -- attempt to run software that has not been through this process, the attempt will fail, and can be logged so that security personnel will be made aware that a potential attack is in progress.
The important thing to understand is that the security landscape is changing rapidly, and it is only becoming more dangerous. To avoid these threats, companies both large and small must take the situation in hand, ensuring collaboration between developers, security personnel, software vendors, and providers, and focusing on best practices.
The planned meetings reported between Biden administration officials and the private sector are important to work collaboratively to combat the onslaught of cyber attacks. No one can afford to be the weakest link in the chain. We’ve seen how the attackers exploit vulnerabilities to gain access to computer networks then expand their penetration to more and more systems and information. It’s going to take all of us working together to combat this enemy.
It used to be that companies worried about hackers stealing credit card data or personally identifiable information and potentially selling it on the dark web. The risk seemed minimal, and limited to reputational damage.
Not anymore.
Today we live in a very different security hellscape, where businesses are vulnerable not only to the small-time hackers that have always been there, but also to both highly skilled professional hackers and state actors with the most sophisticated of tools. And worse, even those small-time hackers now have access to commoditized tools provided by the professionals.
Part of the problem is that the Black Hat community has made significant advances in recent years. There are even structures where relatively inexperienced hackers can license ransomware tools from large criminal gangs and simply share a percentage of their "take".
Limitations of Developers
Meanwhile, the business and software community is just starting to catch up. We are only now starting to see the entrance into the industry of developers who have grown up with (and more importantly been trained in the art of) security concerns. Instead, most developers do what they can, but they simply don't have the background to fend off every type of attack to which their code may be vulnerable. Some even unwittingly integrate vulnerable code into their own applications in the form of software libraries that are known to be vulnerable.Even when software developers do make their best effort to be secure, there is always the risk of human error. The Colonial Pipeline hack, which shut down the supply of oil and gas to the east coast of the US earlier this year, was enabled by a single VPN password that had been left exposed.
The technology advance toward cloud computing has its advantages and disadvantages. On the one hand, you're gaining access to the considerable security talent of cloud providers such as Amazon Web Services, Google, or Microsoft Azure. On the other hand, you're also at their mercy; if they make a mistake, you're not going to even know about it, much less be able to mitigate against it. In addition, moving to a cloud architecture increases your "attack surface".
The problem gets even worse when we think about IoT and edge deployments, which have the added disadvantage that attackers can potentially gain access to the device itself.
Ultimately, the solution is to realize that security cannot be entirely the responsibility of developers. They simply don't have the training to see all of the different security failings that are hiding in your human and computer infrastructure. That's the job of security experts. And even they can't do it alone.
Bridging the Disconnect between Security Personnel and Developers
What makes this situation complex is that there is often a disconnect between security personnel and developers. Developers don't understand what security is telling them to do, and security doesn't understand what developers do. Fortunately, to solve this problem, there are a number of security protocols that act as a checklist of best practices, explaining to each side what needs to be done.Many of these checklists come from the United States federal government, which understandably has an interest in keeping American businesses safe. For example, earlier this month, the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA) released their Kubernetes Hardening Guidance to help business create secure Kubernetes clusters, and several standards exist for companies that wish to do business with the Federal government, such as Fedramp and DISA STIG.
The Defense Information Systems Agency Security Technical Information Guide (DISA STIG) is actually aimed at software vendors. Becoming STIG certified involves a long, complicated, and time-intensive process that is required in order for software to be deployed by the Department of Defense, and it's a great example of how businesses can make use of these federal efforts. DISA STIG certification may not be required, but knowing that the requirements of the STIG have been met tells you that that security infrastructure is in place.
And just as hackers have ready-made tools to work with, companies can also get protection from ready-made tools, such as products that implement the Federal Information Processing Standard (FIPS 140-2).
Implementing a Secure Software Supply Chain
But perhaps easiest to implement is the idea of a Secure Software Supply Chain, in which software is checked for vulnerabilities automatically -- relieving developers of the responsibility of knowing every piece of software that has ever been hacked and every technique hackers use, and security and operations of the responsibility of checking every piece of software that goes out the door. This process can also protect against vulnerabilities that were introduced earlier in the process, such as in libraries used by developers.The Secure Software Supply Chain can have a number of different features, such as a secure image registry that limits the base images developers can use to those that have been thoroughly checked and hardened, to performing static analysis of developer code, to ensuring that software cannot run in production unless it has been cryptographically signed by these processes. This way, should someone -- either inside or outside your company -- attempt to run software that has not been through this process, the attempt will fail, and can be logged so that security personnel will be made aware that a potential attack is in progress.
The important thing to understand is that the security landscape is changing rapidly, and it is only becoming more dangerous. To avoid these threats, companies both large and small must take the situation in hand, ensuring collaboration between developers, security personnel, software vendors, and providers, and focusing on best practices.
The planned meetings reported between Biden administration officials and the private sector are important to work collaboratively to combat the onslaught of cyber attacks. No one can afford to be the weakest link in the chain. We’ve seen how the attackers exploit vulnerabilities to gain access to computer networks then expand their penetration to more and more systems and information. It’s going to take all of us working together to combat this enemy.
