## Introduction
As developers, we leverage DevOps tools to streamline verification tasks with a goal to verify that applications work correctly, but security testing is very different than testing feature functionality. Security testing identifies risks and vulnerabilities in the kernel, operating system, applications, stack, network, and infrastructure.

In this post, we will introduce how we help lock down web applications and REST API service layers using free open source tools (FOSS) with well-adopted DevOps toolchains, and if you have the budget, there are many commercial solutions available, too. 

While some of these tools can be applied to non-web technologies, things like kernel hardening or malware integration testing are just too complex to tackle at the same time as this introductory post. Stay tuned for upcoming content or reach out if you’d like to talk through how we approach automating those use cases.

2018 started with a bang for Information Security, showcasing Intel's [Spectre and Meltdown](https://spectreattack.com/) exploits. The fact that all intel chips allow Javascript to [access memory](https://github.com/IAIK/meltdown) in the kernel space is frankly incredible.

Now is the time to start putting processes with the right tools in place to help mitigate security issues to your business. This document shares how Levvel is helping some of the largest financial institutions (and companies in all industries of all sizes) address their security concerns. 

The past few months have been eye-opening with all the hacks and exploits affecting companies large and small. This post will highlight how we helped create a secure compute environment for a large financial institution’s application stack written in python and extensible to most modern programming languages.

## Where do we begin, and how much time and money is required?
*Note: This post is a small part of a larger piece of content, meaning we will not be determining your organization's overarching security strategy in this post. We’ll share how we are effective in helping our clients with FOSS tools reduce their business costs to deliver features to their customers.*

In the application development space, the adoption of DevOps toolchains is essential to keeping up with the competition. We have seen that with the right solution, security teams can reduce their costs, as well.

The scope here focuses specifically on how to lock down your applications with tried-and-tested DevOps tools integrated with the latest enterprise-grade security analysis toolchains. These tools are helping organizations automate testing while reducing the cost to launch and support features. In the spirit of DevOps, using all of these tools together for security analysis becomes just another task in your CI/CD pipeline.

For example, unit testing code paths through an application is common, so instead of just testing the code's functionality, let's audit the code from a security perspective. Taking time to work through your application and technology's custom use cases can help prevent costing your organization bad publicity, loss of customer faith, time, and money. 

Plan and test for the worst. 

In the beginning, implementing these concepts will have a certain amount of overhead (time and money), but the payoff, in terms of additional security assurance, is huge. As your organization’s practices mature, the overhead associated with implementing DevOps in the Information Security space will improve.

Let's assume we are using these popular DevOps tools and start iterating on a security testing CI/CD pipeline:

- Docker
- Jenkins
- Ansible

For background, we use these tools every day to help clients automate CI/CD pipelines for application development, and here’s why we like them:

- Docker containers are great because they are a standalone, deployment-agnostic solution that can run on a laptop on-premise or in the cloud
- Jenkins because it is so easy to set up complex, automated test jobs with almost every modern programming language
- Ansible’s IT automation engine makes it easily build a yaml playbook for cloud provisioning, configuration management, application deployment, intra-service orchestration, and more

Additionally, all of these tools have commercially-supported counterparts that enterprises can choose to adopt. While the free, open-source versions work great, many large organizations find that commercial support gives them the peace of mind that security patches will be delivered quickly, they are not dependent on community help, and that features of interest to the enterprise will be prioritized.

Combining these three technologies makes application testing easy for small and large teams, so why not use them for security, too?

## Defining Use Cases
Anyone interested in securing a web application or REST API should explore the [OWASP](https://www.owasp.org/index.php/Main_Page) (Open Web Application Security Project) website. Specifically, the [OWASP Top 10 Application Security Risks](https://www.owasp.org/index.php/Top_10-2017_Top_10) post provides a great starting point for security testing guidelines by providing an initial set of 10 use cases to secure your applications, data, and customers.

For those new to security automation, the [2017 - OWASP Top 10 Application Security Risks](https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf) highlights internal, external, configuration, and intrusion use cases:

- [A1 Injection](https://www.owasp.org/index.php/Top_10-2017_A1-Injection)
- [A2 Broken Authentication](https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication)
- [A3 Sensitive Data Exposure](https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure)
- [A4 XML External Entities](https://www.owasp.org/index.php/Top_10-2017_A4-XML_External_Entities_(XXE)
- [A5 Broken Access Control](https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control)
- [A6 Security Misconfiguration](https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration)
- [A7 Cross Site Scripting](https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)
- [A8 Insecure Deserialization](https://www.owasp.org/index.php/Top_10-2017_A8-Insecure_Deserialization)
- [A9 Using Components with Known Vulnerabilities](https://www.owasp.org/index.php/Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities)
- [A10 Insufficient Logging and Monitoring](https://www.owasp.org/index.php/Top_10-2017_A10-Insufficient_Logging%26Monitoring)

## Approach—Analysis Techniques
While the [OWASP Top 10 Cheat Sheet](https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet) is great for laying out a roadmap, it doesn't show exactly how to analyze and find vulnerabilities or threats. As you start to set up your own testing harness, we would encourage you to incorporate both [Static Application Security Testing (SAST)](https://www.owasp.org/index.php/Source_Code_Analysis_Tools) and [Dynamic Application Security Testing (DAST)](https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools) tools for increasing your testing footprint.

Most static testing tools scan code like any other static analysis tool, but the world of dynamic application testing is an arms race where previously-discovered attacks are thrown at your running application layers to see what breaks.

[DAST](https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools) tools try to emulate hackers, so by the time you have automated your DAST unit tests, you will have a better core understanding of your exposed surface area (and how to minimize it).

As time progresses, tools are updated and patched. We usually recommend setting up a quarterly review to confirm the DevOps tooling is still actively maintained (if you are not using a vendor-supported commercial solution) and check out some of the potential new players in the space. The security testing ecosystem waits for no one!

So, now let's discuss how to build a testing framework utilizing these tools that maximizes the considered use cases and minimizes the headache.

## Conclusion and What’s Next
Here are some topics we'll be taking a look at in the next post:

- Malware Integration Testing—component resiliency testing using contained threats
- Runtime Hardening—customizing the application runtime
- Network Analysis—transports, protocols, firewall and dns
- Kernel Hardening—customizing the OS

In conclusion, thanks for reading, and let us know how your security strategy fits into this approach. If your organization has an interest in using DevOps tools to automate security tests, then please reach out to us at [Levvel](http://www.levvel.io/contact) and we can get you started. Lastly, let us know which of these sound most interesting, and we might queue up a blog on how we can tackle it:

- Privilege Escalation: using kernel or container exploits to become a switch user (like root)
- API Usage Analysis: traffic modeling with AI/ML to identify bad API actors
- Penetration Testing: post-build, deployment intrusion testing

Until next time!

DevOps for Enterprise Security—Part 1

Learn how we help lock down web applications and REST API service layers using free open source tools (FOSS) with well-adopted DevOps toolchains.

DevOps for Enterprise Security—Part 1

DevOps for Enterprise Security—Part 1

Read the Blog