Seven activities to consider at DevSecOps time
Introduction
We all have seen the benefits of Agile methodologies, but those benefits carry a great challenge for cybersecurity professionals. We can no longer spend years with a project before we deliver it. The new business paradigm asks for a quicker delivery, not longer than a few months. And cybersecurity needs to be ready to work this way. It needs to take part in the project from the beginning, and during the whole software development life cycle, providing security at every stage, instead of performing a security review at the end of the project.
This new approach comes with a new way of working: DevSecOps. What does it mean? A unique perspective of security management, that combines application development, security operations, and infrastructure as a code (IaaS) in a continuous and automated delivery.
When you are trying to work as a DevSecOps, it is important to understand that your main goal is to accelerate and facilitate the work of your colleagues. You are not there to be an auditor or to stop the process, you are there as an enabler. Your responsibility is to help the team to deliver on time a secure product with high quality. Remember this, and enjoy the article about how to do it!
This article will cover the following topics:
- Development (DEV):
Automating tools into the pipeline - Security (SEC):
Awareness
Designing the product according to regulations (Compliance)
Threat Modeling
Static and Dynamic Code Analysis and Vulnerability Management - Operations (OPS):
Monitoring
Identity Management
1- Automating tools into the pipeline
One of the most important things for a DevSecOps professional, is to be able to integrate any tool in a continuous integration and continuous delivery (CI/CD) pipeline. This automation saves human time, which can be used to perform other tasks, and, at the same time, reduces the chance of making a mistake. By implementing these automated solutions, you can be sure that at least the minimum requirements from a security perspective are being taken care of.
If you are taking your first steps in this field, I recommend you to start with a static code analysis. After that, you can add a dynamic application security testing (DAST), or third party component review.
Most of the vendors already offer on-demand solutions that could be easily implemented in the pipeline. The following are some of the tools that I have been working with: SonarQube, BlackDuck, Fortify, WebInspect and Qualys.
2- Awareness
Users are our first line of defense. All of them should add a layer of security to the company or development. In order to achieve that, they need to know basic security concepts and be able to make decisions that make the company more robust instead of expanding the attack surface.
With this in mind, the security professional needs to identify the pain points of the team and the company, and provide awareness about them.
Bear in mind that a mandatory course is not always the best approach to engage people. Sometimes, an ethical phishing campaign, a speaker that gets to people, or a message showing good practices, are useful tools for a security team.
3- Designing the product according to regulations (Compliance)
When your team is developing an application and you are advising them from a security perspective, it is very important to consider if the final product will be under any regulation’s scope, such as GDPR, PCI, HIPAA, etc. If that’s the case, you need to design it accordingly, which will save time and money to the project, due to less rework.
In many cases, what one regulation considers as Personal Identifiable Information (PII), another regulation may not. For example, GDPR (Article 4, Point 1) considers IP as personal data, and your project server logs contain it. As another example, PCI has very restrictive rules regarding encryption and storage. All of them regulate logs, identity management, authorization and authentication methods, and controls that must be executed, among others.
My two cents: pay attention to which regulations apply to your industry, geographic location, and customer’s nationality, and have that in mind at every step of the development process. In some cases, penalties for not being compliant could reach 20% of the annual billing of the company.
4- Threat Modeling
This technique allows the project to identify vulnerabilities or weak areas at the design stage, before they can be implemented. The main goal is to reach the minimum standard security level by listing all the attacks that the application could suffer, and propose security controls to mitigate them. Executing this task prevents Malware, DDoS attacks, among others.
My two cents: I recommend a game that may help you to quickly detect system threats: “Elevation of Privilege, Threat Modeling” which is a Cybersecurity Card Game. The game was created by Adam Shostack, and it is possible to find it on the internet. The game uses STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege), and the main idea is to involve the developers, and find flaws from the beginning of software development life cycle.
5- Static and Dynamic Code Analysis and Vulnerability Management
When developers write new code, they not always follow security best practices, especially in the development environment. To reduce the attack surface, secure the whole application and guarantee confidentiality, integrity and availability; the security team has to periodically execute static and dynamic analysis.
When the scan is done, it’s time to analyze the findings, identify false positives, classify real findings according to the severity, select those that represent a quick win for the project and share the information with the development team. It is really important to focus the effort in sharing all the information needed to fix those bugs or findings in a proper way. Take a screenshot of the piece of code that must be improved, share alternative solutions with them, and follow up the progress, helping them to implement the necessary changes. Remember, as a security professional, you are as responsible for delivering a secure product on time as the development team is.
There are two more very important things to consider in this topic: first of all, as I mentioned in the first item, this kind of analysis could be integrated in the pipeline so it is performed automatically. Second, the executive report or dashboard for the managers are important too, in order to provide visibility about the current security status of the application, and the effort needed to fix the bugs.
As a reference, I strongly recommend using the OWASP website (owasp.org) as a source of information. There, you can find the top ten vulnerabilities of the year, useful tools and more.
Source: https://owasp.org/Top10/
6- Monitoring
Nowadays, companies must assume that they are going to be attacked at some point in the future. This will allow them to work knowing that you can never be 100% secure, and they need to be prepared to detect and respond to incidents as quickly as possible.
With that goal set, monitoring becomes a very important topic. It is what allows companies to establish behavior patterns, identify anomalies and trigger alerts. It gives visibility about infrastructure and application. It allows us to take preventive or reactive action and make fast decisions. And it also enables us to do forensics, allowing us to learn from what happened. Being resilient and coming out stronger from those attacks is a key aspect if we want to navigate in a secure way.
7- Identity Management
Managing roles, users, permissions, groups, and service accounts, is a fundamental security practice for any development project. Finding a balance between security and usability leads to the least privilege principle. So, allowing developers to execute only what they need, without blocking their work at troubleshooting time, is a great security challenge. It is very important to take the context into account, for example, to evaluate which environment we are setting up. If we are working on the development environment, we are not going to be as restrictive as if we were on the production environment.
Another aspect to keep in mind when working as DevSecOps, is that continuous and automated tasks might require service/system accounts with high privileges (fulls access, admin access, etc). In this scenario, the recommendation, based on my experience, is not to remove those permissions. If you do it, the result will be that the project suffers delays, some processes may fail, and the deployment will become more complex. So, I recommend detecting those resources that need special attention and monitoring them carefully.
8- Conclusion
In my professional experience, being responsible for this role is really fun and diverse. You would have the opportunity to develop your technical and soft skills, as you will need both.
Security is a part of the quality. If you pursue a delivery with high quality, you have to pay attention and invest resources in security. Follow the seven steps listed above, guarantee the minimum standard to add security in each layer, have a secure code, accelerate the time to market and be on time with deadlines. As a security professional, keep in mind that security is as responsible as the rest of the team to deliver on time.
Although it seems like a lot, these are the activities that cannot be forgotten when performing in a security role, with the responsibility that it requires. Therefore, feel free to take part in the celebration when an application is up and running in production.
