Becoming Unbreakable: DevSecOps Tips & Tricks

Have you ever suffered a hack on one of your personal accounts – email, Facebook, OLX, Bitcoin wallet, or something else? Getting hacked can happen to anyone. In fact, even as a DevOps professional, my OLX account was hacked two years ago and I only came to notice it when fake ads were posted on my behalf.

I know from personal and professional experience that it’s not only large companies that are victims of hacker attacks. Small and medium-sized organizations are often targeted as well.

The top three industries hit hardest include:

• Healthcare
• Energy
• Financial Services

Here, we’ll review the ins and outs of DevSecOps, take a deeper dive into Azure’s DevSecOps tools, learn more about implementing a Shift Left strategy, and summarize how all these tools can help save time in software development.

How Can DevSecOps Help with Computer Security?

The Weakest Link: A Real World Example

To provide some context, let me begin with a personal, real-world example. Several years ago at a previous employer, our CFO received an email from our CEO asking her to send $50,000 to a client’s account. This was a fairly typical request. However, something compelled our CFO to pause for a moment and ask the CEO about the urgency around the request. Thankfully, the CEO replied immediately that he’d not sent any such request and they were able to quickly recognize that the company had been victim to a hack.

Following this incident, as the company’s DevOps specialist, I was asked to conduct an internal investigation to determine exactly what happened and what needed to be implemented to prevent future attacks.

Here is a quick rundown on how it all went down: A few weeks prior to the event, an office manager received a phishing email, allegedly from the CEO, asking him to log in via a link in corporate mail and send a report. The hackers were then able to gain access to the corporate email system and create a fake CEO account. And you know what happened next!

This story eloquently illustrates how people themselves are one of the weakest links in the corporate security chain. Follow up measures included an IT security training for all employees, which involved reminders about discussing assignments with team members in person before carrying them out and the need for keen attention to detail.

What Are the Key Components for Software Security?

DevSecOps is a trend that has grown in recent years. While having a well trained DevOps team is a prerequisite to implementing DevSecOps, DevSecOps is really a philosophy of integrating tools, practices, and a culture of security. However, before we start looking at DevSecOps tools, let’s take a step back to review the Shift Left strategy and how it’s influenced DevOps practices.

Until recent years, security testing was conducted at the end of the development cycle. Today, the concept of software security testing has changed with the introduction of Shift Left. The term “Shift Left” originated in the early 2000s and literally implies “pushing testing to the left” (i.e. earlier). The intent is to identify and resolve bugs as early as possible in the development process to improve software quality and reduce time spent resolving issues that tend to become more difficult later down the line.
Getting back to DevSecOps, how can it help with computer security? Let’s start with the basics.
DevSecOps tools can be divided into four categories:

1. Tools used in the system design/development process
2. Tools used in the continuous integration (CI) process
3. Tools used in the continuous delivery (CD) process
4. Tools used in production

1. Design / Development

The Microsoft Threat Modeling Tool is an important element of a Shift Left strategy. It helps to check releases, solutions, and security levels during each stage of software development. Previously, this tool was used only during testing but it’s now also used during the design phase of software architecture.

Before deploying the infrastructure and software in Azure, you’re required to draw your architecture in the Microsoft Threat Modeling Tool and simulate potential threats. It’s very important to know in advance what vulnerabilities and threats exist and how to neutralize them in Azure services.

2. Continuous Integration (CI)

We’ll review the top three tools used for CI – SonarQube, GitHub, and Trivy.

SonarQube is the first CI tool to be used for static code analysis. SonarQube measures the quality of software code according to seven software quality indicators, which developers refer to as the Seven Axes of Quality:

1. Potential errors
2. Programming style
3. Tests
4. Repetition of code sections
5. Comments
6. Architecture and design
7. Complexity

When implementing this tool, special attention is required to avoid false-positive results. For example, SonarQube’s default settings will signal an error if the code has a variable named “password.” Developers simply will not take into consideration the messages from SonarQube because of many false-positive static analysis results.

GitHub is the second tool used to look for vulnerabilities in dependent packages. The GitHub dependency graph is a simple, free, and very useful mechanism that helps detect vulnerabilities in third-party open-source packages used in your program. By default, the GitHub dependency graph is not active, but you can enable it in the repository settings. It’s a good idea to create pull requests in your repository if it finds vulnerabilities in the open-source sources you’re using. Just click the “merge pull request” button to do so.

Trivy is the third tool and is a simple, functional vulnerability scanner for Docker containers. It helps to detect vulnerabilities in operating system packages (e.g. Alpine, RHEL, CentOS, Ubuntu, and others) as well as package dependencies (npm, yarn, and others). It works the same with Infrastructure as Code (IaC) Terraform files. Trivy can very easily be integrated into any continuous integration tool.

3. Continuous Delivery (CD)

During this stage, it’s important to pay attention to the Azure infrastructure. Using Tfsec and Azure Policy Compliance will help.

Tfsec is a common tool for testing Terraform code to identify potential security issues. It protects storage with passwords, tokens, and other sensitive data in the control system version (GitHub, GitLab, and others).

Azure Policy Compliance is a useful tool that helps the user adhere to organizational standards by setting up policies for Azure Subscription. As examples, you can allow Azure services to work only using HTTPS, prohibit the creation of Azure resources that you don’t plan to use, or restrict changes to Azure resource settings.

4. Production

OWASP is one of the tools used for penetration testing. OWASP is a set of guidelines that must be followed to minimize the risk of breakage. It retains publicly available resources like documentation, methodologies, and articles, so anyone can find the information they need very quickly. OWASP, along with other tools, is used by audit firms to determine what vulnerabilities are present in their systems.

OWASP also automates the process of testing vulnerabilities with the OWASP Zed Attack Proxy tool, which can simulate the most common attacks on services and help identify the most dangerous types of threats.

Also, this tool is easily integrated into the continuous delivery process. All OWASP tools are free and help the developer community around the world prevent incidents and vulnerabilities.

What Other Tools May Be Helpful?

We’ve taken a look at DevSecOps tools that integrate into the SDLC process and help increase overall IT security. But what other Azure tools can help maintain security on a project?

If you need to scan the current status of the project without wasting time, you can do so in the Azure Security Center. The Azure Security Center highlights the main threats posing an issue to software in Azure Resource settings. It also provides change options that detail the vulnerability and the steps you can take to avoid the threat.

In Summary

In wrapping up, we encourage you to consider the following indicators regarding the security of your system while in production:

• Bugs and other vulnerabilities are detected
• A critical mass of problems are detected
• Security reports (bugs for a certain period of time)
• Metrics, logs, and events that appear in production

Finally, remember that DevSecOps is everyone’s responsibility. Although implementing a culture of security measures can be a tiring process, it’s critical to do so before building a new structure. That culture change can take time – six months, a year, and maybe longer.

Security is not just information – it’s a way of thinking! So always think before you click. 😉

Used Materials:

1. https://owasp.org/www-project-web-security-testing-guide/stable/
2. https://azsk.azurewebsites.net/
3. https://docs.sonarqube.org/latest/
4. https://azure.microsoft.com/en-us/solutions/devsecops/#solution-architectures
5. https://media.webteam.puppet.com/uploads/2019/11/2019-state-of-devops-report-puppet-circleci-splunk_sml-1-1.pdf
6. https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-getting-started
7. https://github.com/tfsec/tfsec