Secure the Code, Prevent the Breach.
While organizations are rushing to secure their networks and infrastructure in order to gain a robust security posture that allows them to meet regulations and protect their assets. They often tend to overlook an equally important aspect of security, which is securing the software development lifecycle.
When we look at the numbers, we can get an idea of the reasons behind this disregard:
Lack of Awareness
In a survey of 400 developers conducted by Vanson Bourne and commissioned by Veracode. 25% of the developers admitted that their companies did not have an application security program in place, while 4% did not know whether their companies had such a program or not.
The same survey showed that nearly one in five developers were not at all familiar with the OWASP Top 10 web application security risks.
Lack of Time
It would make sense for companies to try to bring their product to the market as fast as possible, but this often comes at the cost of security. A SonaType survey from 2018 showed that 48% of developers do not have enough time to fix security issues, although they realize their criticality.
Lack of Skills
Adopting secure coding practices requires at least a basic knowledge of security principles, something that is lacking in the technology industry. In fact, Tripwire’s 2020 Skills Gap Survey showed that 72% of the participants think their security teams are understaffed, while hiring security professionals is becoming harder:
On top of the above-mentioned reasons, companies seem to overlook the importance of security in software development. Although, real world events have shown that securing the code is just as important as securing the infrastructure:
The recently discovered Octopus Scanner malware scanned Github repositories for NetBeans source code files, and injected itself into the code. Impacting every developer that downloaded one of the 26 affected open-source software, and bringing to light a new aspect of supply-chain attacks.
In 2018, Facebook discovered three bugs in their source code that would enable users to generate access tokens for other accounts, potentially exposing 50 million accounts.
Failing to secure the code can not only impact the end-user, but might also lead to the theft of Intellectual Property, damage the company’s reputation, and compromise the company’s network by rendering expensive security controls useless.
Secure your code!
It should have become clear by now WHY it is so important to apply security principles to the software development lifecycle. But with the lack of security skills, the HOW remains unanswered. Fortunately, there are plenty of standards, frameworks and advisories publicly available, and they mostly revolve around the following main best practices:
Secure Development Training
A company cannot expect its developers to apply secure coding practices without providing them with proper training specific to their duties. There are many software security courses available, like Defending Web Applications Security Essentials by SANS, Certified Application Security Engineer by EC-Council, and Certified Secure Software Lifecycle Professional by (ISC)².
Security by Design
To implement security by design means to involve security from the initial stages until delivery. Designing a secure application is way more effective than patching security issues at later stages and then going through testing again.
Security by design requires a threat analysis at the design stage in order to identify the threats and the types of attacks that might be used for each threat. Mitigation techniques are then selected for each threat and inserted into the design of the application.
It is important that basic security principles are applied in the design. Such as least privilege, segregation of duties, secure authentication and authorization, and secure failure.
Security by design also requires security testing at each of the development, testing and release stages. Testing includes Design Security Review at the Design stage, Application Security Testing at the Component Testing stage, System Security Acceptance Testing at the System Integration Testing stage, and finally Penetration Testing at the Deployment stage.
Secure Coding Practices
Developers are at the core of the SDLC, it is therefore necessary for them to write the code with a defensive mindset.
“All input is evil, until proven otherwise.”
― Michael Howard & David LeBlanc, Writing Secure Code
The OWASP Secure Coding Practices Quick Reference Guide sets clear instructions related to secure coding. The instructions tackle the following concepts:
- Data Validation
- Authentication and Password Management
- Authorization and Access Management
- Session Management
- Sensitive Information Storage or Transmission
- System Configuration Management
- General Coding Practices
- Database Security
- File Management
- Memory Management
Even with a security mindset, the best developers are prone to make mistakes. This is where code review comes in as an additional layer of security. Often developers are so deep into the code that they might miss a bug. Having a peer developer review another developer’s code introduces a new perspective with a fresh set of eyes that might identify mistakes overlooked by the original developer. The OWASP Code Review Guide is an excellent guidance document that focuses on the mechanics of reviewing code for certain vulnerabilities.
The source code repository can be the crown jewels of many companies, and the target of many attackers. Securing the repository with proper security controls like strict access controls and encryption is necessary to prevent intellectual property theft, or a leak that might damage the company’s reputation.
Theft of source code can also allow hackers to check the code for bugs and exploit them, thus gaining access to the company’s network or to client devices and information.
In case the software is sold to clients or made publicly available as open source. Attackers that are able to modify the code in the repository can inject malware that compromises the networks and devices of the clients or the software users. which is what happened with the Octopus Scanner malware mentioned earlier.
While change management is an integral part of the SDLC from an operational perspective. It can also serve as a strong security control.
A solid change management process can ensure that no malicious or unintended changes are made to the code during the transition from development to user acceptance testing, and then to release. It can also guarantee that no software or update is released without the sign-off of security personnel that have tested the software and cleared it for release.
The DevOps development model has proven effective to a large number of companies, when it comes to faster releases. To make things even better, the principle on which DevOps is built, which is the collaboration between developers and IT operations, can easily cater for the introduction of security. Which brings us to DevSecOps.
In traditional development processes, security was introduced at the end stage. With DevSecOps, and since developers, security professionals and IT operations work in collaboration throughout the whole process, security can easily be introduced at the design stage, and continue throughout the release.
Moreover, since DevOps relies heavily on automation tools, security professionals can introduce their own tools into the DevSecOps process, further reducing the time and effort required.
Always use up-to-date third-party libraries to avoid introducing vulnerabilities into the software.
Implement proper error handling to avoid unintended code behavior or revealing technical information to malicious users.
Use static and dynamic analysis tools to detect vulnerabilities in the code that may have been overlooked.
Security in the SDLC is a very large topic, and while it might seem complex at first, once you start going down the road things will start falling into place. The following are a few useful references to help you on your journey:
- Microsoft Security Development Lifecycle Practices
- OWASP Mobile Security Testing Guide
- OWASP Web Security Testing Guide
- OWASP Top Ten
- NIST Secure Software Development Framework
As a final note, the saying “Humans are the weakest link in the security chain” also applies to developers, most of whom are often overworked and have to meet strict deadlines. This is where communication sets in. Talk to your developers, let them understand that security is here to help and not make the work even harder, understand their concerns and try to work around them. Security works best when all concerned employees feel as part of a team, and disgruntled employees might cause intentional or unintentional security disasters. Keep your employees happy and your company will strive.