Security in Software development

DevOps brings about collaboration between development, testing and operations teams, in an effort to increase the speed of the software delivery cycle. Teams are constantly talking to and working closely with each other throughout the cycle, ensuring the highest quality of code, testing and infrastructure is delivered in the end product with speed.

To quote myself, “DevOps isn’t something you do, it’s something you are!”

So where does security fit into this?

Historically, security was introduced during the testing stage of the software delivery cycle which presented many challenges as the code wasn’t written with security at the core of the deliverables. Also the infrastructure ruunning the code wasn’t built for security designs which would later come in to play.

In the modern and more agile world, Security in the design stage is just as critical as any other part of planning. There should be a proactive approach to security rather than a reactive one, where, for example, a pen test is conducted towards the end of the cycle and the entire security of the software is a reaction based on the report produced by the pen testers.

Most pen tests last for a few days when hiring in a consultancy to test applications, whereas most malicious unethical hackers will more than likely spend a lot more time trying to penetrate your application and database. Though pentests are important and valuable, the results should not be the be all and end all of your security Design as it is limited in its findings due to the short length of time these tests are conducted over.

Security done well, should work with and for the team, rather than against them. When security produces barriers to team members performing their roles, it decreases productivity and promotes a culture of hacking to make things work. 

A simple example of this is when companies make it difficult for colleagues to share documents with each other. Employees will find a way, whether by sharing on personal Dropbox accounts, or copying documents and data on to a usb stick.  Once this happens, the company now has data or documents out of their control, unable to provide any audit or governance and is a huge security risk.

A lot of security architects approach to securing systems and data is to lock everything down as much as possible. This approach not only has the flaws I described earlier, but in most cases, doesn’t actually secure systems and data as stringently as intended. For example, an organisation could have a policy on corporate laptops that stops employees copying files to a usb device. Sounds sensible, until you peel back the layers. If this policy is enforced at network level rather than local laptop level, and the same laptop is permitted to join non-corporate WiFi networks, the usb policy becomes null and void as the laptop is only aware of the policy when connected to the corporate network. So why have the usb policy in the first place if you aren’t really securing anything?! Obviously this example is more suited to corporate IT security rather than software development; however, the sentiment remains the same.

Instead, I advocate for the adoption of the Secure Software Development Life Cycle methodologies (SSDLC).

SSDLC introduces a series of security practices throughout each phase of the Software Development Life Cycle (SDLC). The different phases of the SDLC are:

Planning / Design – whilst requirements gathering exercises and designing is being undertaken, this is the perfect time to introduce security. Ascertain what the attack surface would be, conduct threat modelling and alter the design to become more secure before a single price of code is written.

Development – at this stage where designs are translated into source code, the implementation of security is critical. The code needs to be written in a secure way. This phase requires close collaboration between security architects/ engineers and the development teams. Developers may need extra training and coaching on the art of secure code writing on a regular basis.

Verification / testing – this phase, from a security perspective where we can begin to see the fruits of our efforts. Pen tests can be conducted using code scanners at this stage as well as extra security code reviews with the developers, security architects / engineers and test engineers working closely together to ensure you have produced a secure application.

Release – once you have gone through the previous steps and all bugs have been fixed and vulnerabilities have been mitigated, we are now in a position to release the application into production.

There are several models of SSDLC, each with their own ways of achieving a much more secure SDLC:

• Microsoft SDL
• OWASP Software Assurance Maturity Model
• OWASP CLASP

There needs to be the same level of collaboration that DevOps encourages within Security. Architects should fully understand every job role, it’s requirements and it’s risks. They should understand every component in a pipeline and the risks they present. They should know how the product software works inside out. They should spend time with all teams to gain this insight thoroughly and once armed with this information, can produce state of the art security designs along side the teams, with policies which provide real and as close to absolute security, significantly mitigating all risks. This for me, sums what the newer phrase, DevSecOps means.

There will be trade offs that have to be made and risks that will be deemed as acceptable to the business, as is the nature of security, but these should not impact ones ability to perform their role, nor compromise the security of the software.

There are products out there that can assist in building secure and productive pipelines and software. For example, 

HashiCorp has a product called Vault which is an excellent secret management platform. It has libraries for multiple languages, allowing secret exchanges to be transparent in the background with a small code snippet, limiting the risk of credentials being written in to code.

Jfrog has an add-on product for Artifactory called X-ray. This product scans your code much like an X-Ray for vulnerabilities and malicious libraries. This product is perfect as a pipeline step and their database is updated for   Common Vulnerabilities and Exposures (CVE) daily.

Open Web Application Security Project (OWASP) has a Static Application Security Testing (SAST) tool called SonarQube Project, which is a free open source tool which provides source code analysis to find security bugs and vulnerabilities. In general, SAST tools aren’t bulletproof; however, they provide a very good start to secure code writing, especially as many of these tools are now being built into IDEs, meaning developers can scan their code as they go along during the development phase of the SSDLC.

Here we have just three examples of many applications that can assist in secure code writing and building.

Security in Pipelines is something I also strongly recommend, as security testing becomes automated and starts to change the mindset of the developers to be more security aware when writing code. PenTests can and should be integrated into pipelines and through its findings, can help increase the quality of code writing within development teams from a security perspective.

Software Development is now a very Agile business function, with requirements and specifications often changing the scope of deliverables.  As the scope changes, so too does the security risks and attack surfaces.  Keeping on top of this is a challenge to most projects.  To attempt to address this, the nomination of security champions, who are involved in discussions with clients about the changing scope and are in a position to ask the right questions, and escalate any grey areas of security concerns to Security teams. The security champions have a key role to play in communicating the changing security requirements to the wider development team.

To summarise, security should in my opinion, shift left and be introduced into the software delivery cycle in the very beginning. Security, like DevOps also isn’t something you do, it is something you are. Every team member has a role to play in the design and implementation of effective security and it should be embedded into the culture to the point where it is the culture.