In the cloud technology arena, Software as a Service (SaaS) is quickly becoming the preferred way to consume applications for many businesses.The takeaway for the businesses are in the advantages that come with SaaS which are: low up-front costs, accessibility, scalability, quick setup and deployment among many other advantages. Though, among the key concerns that SaaS brings with it are of security. In this blog we talk about our team's approach to reducing Backup Ninja's security vulnerabilities.
Shifting Left
For a long time, application security has been bogged down by the challenge of software developers not effectively working with security teams and vice versa. Considering this challenge, it has brought about an industry wide initiative to mobilize security teams to work proactively with software developers when building applications - commonly referred to as shifting left - which I mentioned in a previous blog. Also, other buzzwords like DevSecOps have also come up with the notion of having development, security and operations teams working together; that is, following the upsurge of many organizations shifting towards a DevOps culture.
These buzzwords, shifting left and DevSecOps, have come up as a result of the need to see security and application teams work together to find and reduce security defects on applications way earlier in the application development lifecycle. The point of all this is that, in the past, not "shifting left" has brought about the sheer amount of software vulnerabilities - being exploited in the wild - that we hear and see everyday; simply because a lot of software is being built with security defects due to the varying security awareness levels among developers. Question is then, how do we begin to shift left? We look into the activities and controls that can help in building a secure SaaS application in the next section. But even before, we list four questions that should be answered when thinking about securely building a SaaS application.
1. What are we working on?
This question helps us to essentially think about the business requirements, the application design/architecture and the business logic behind the application.
2. What can go wrong?
Based on the business requirements/logic, you may need to take a risk/threat-centric approach to address what security issues might hamper the business requirements from being achieved. Threat modeling is ideal, at this stage, to be able to identify the potential security requirements to ensure the business requirements are met.
3. What can we do about it?
Following through what can go wrong, this will help us define our security controls to effectively thwart any potential security issues to enable us to achieve the security and business requirements.
4. How can we keep on improving?
It is essential to think about how to maintain and improve the security of the SaaS solution considering that we may lose the security quality due to changes in the software as we continuously develop it. Also, we may not necessarily be able to identify and cater for all the potential security issues during the first iteration when building the application.
By answering the questions above, it curates the controls and activities that are needed to secure a SaaS application. We look at the actual controls and activities that help with reducing vulnerabilities for Backup Ninja.
Reducing Backup Ninja's Vulnerabilities
The Backup Ninja team uses the set of activities and controls listed below to ensure that there are minimal vulnerabilities in the product.
1. Application security awareness training
The team is constantly training, learning and researching about existing application vulnerabilities and threats. Awareness training helps reinforce a “human firewall” so as to stay ahead of the curve in taking precautions to secure the application by reducing vulnerabilities. More so, it goes a long way in training the team to write code in a secure way.
2. Threat modeling
Creating a threat model helps evaluate the attack points of an application by laying down and analyzing its business logic and architecture. Threat modeling has been done from the inception of the project and it is also done after significant changes are made to Backup Ninja so as to help with identifying new attack points on the application and subsequently implementing the respective controls to help with reducing vulnerabilities.
3. Static application security testing (SAST)
SAST tools such as linting tools and generally security code analyzers are incorporated into the build process. These tools statically inspect the code and give early warning signs of flaws and weaknesses in the code that need to be fixed.
4. Dynamic application security testing (DAST)
DAST tools are used to find vulnerabilities in the application while it is running in the testing and pre-production phases of the development process.
5. Peer code reviews
Peer code reviews are done by having two or more members of the team inspect a newly written piece of code so as to disambiguate the manner in which the code has been written in the event that the code presents potential security flaws or weaknesses.
6. Vulnerability and patch management program
If security vulnerabilities are found at any point during development and in production, they are escalated based on their severity and fixed. The fixes are oftenly published in the Backup Ninja's blog series. Also, vulnerabilities in third party components of the Backup Ninja application are identified and patched using automated third-party vulnerability scanners. The third-party component scanners inspect Backup Ninja's code and cached dependency repositories to find outdated and vulnerable dependencies.
7. Penetration tests
The product goes through regular penetration tests to identify security holes in the application and its underlying infrastructure.
Industry Best Practices
The above security activities and controls can be implemented and matured by any of the industry standards and best practices listed below. Using these standards and best practices gives you a reference point for all the security concerns that may need to be addressed during development, testing, pre-production, production and maintenance phases in the lifecycle of your SaaS application.
- Open Software Assurance Maturity Model (OpenSAMM)
- OWASP Software Assurance Maturity Model (SAMM)
- OWASP DevSecOps Maturity Model (DSOMM)
- Microsoft Security Development Lifecycle (SDL)
- NIST DoD Enterprise DevSecOps Reference Design
- Sonatype's DevSecOps Reference Architectures
- Building Security in Maturity Model (BSIMM)
- OWASP Top 10
Final Thoughts
Backup Ninja is built and maintained using industry security best practices. With this knowledge, it gives you the assurance of a secure and reliable SaaS service for database backups.