February 9, 2018
TABLE OF CONTENTS
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.
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.
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:
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:
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?
Anyone interested in securing a web application or REST API should explore the OWASP (Open Web Application Security Project) website. Specifically, the OWASP Top 10 Application Security Risks 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 highlights internal, external, configuration, and intrusion use cases:
While the OWASP Top 10 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) and Dynamic Application Security Testing (DAST) 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 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.
Here are some topics we’ll be taking a look at in the next post:
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 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:
Until next time!
API design is crucial, giving structure to application interaction. Given cross-functional teams and applications, development time is reduced with a clear, intuitive way to access data. API development often follows two approaches: REST and GraphQL.
As of June 2018, the state of California passed a new privacy law that could lead to more consequences for US-based companies than the European Union’s General Data Protection Regulation (GDPR). Here's what you need to know and how to be compliant.
Before your data scientists wring value out of your reams of data, it has to be accessible and, on some basic level, coherently arranged. To harness all that brainpower, you need to keep the data wrangling to a minimum. Enter the data lake.
Legacy applications get no respect. The developers who wrote them have aged out and no new developers want to work on career-killing software stacks. But they are still faithfully doing the job they were created to do long ago. So what's the problem?