logo

Want to learn more about FAST?

Schedule a Demo below to talk to a Solution's Engineer

Automate Security Testing in Your Build/Test Cycle with Zero-ops

FAST stands for framework for automated security testing. We want to take your existing functional tests that you're already using and automate that into hundreds or thousands of security tests. This is a security framework tech demo given by Eric Lugo on May 21st, 2019. If you’d like to learn more, please visit our website or email request@wallarm.com

Learn to:

  • Plug-and-play security into any CI/CD pipeline w/ easy integration
  • Identify API specific issues and OWASP Top 10
  • Run 1000+ security tests triggered in the pipeline w/o manual actions required
  • Test single page apps and APIs
  • Optimize testing time w/ existing functional tests and app-specific fuzzing

 


Transcript:

Thank you everybody for joining today. The reason why you joined us today is because you want to learn about security in a DevOps world. Doing security in CI/CD and in a more automated fashion.  

Little bit of background about myself. I am Eric Lugo, a security solutions architect here at Wallarm. Before Wallarm, I worked at Google Cloud working on security for some of our largest customers as well as working at CloudFlare, NGINX, and Rackspace.

So I’m going to dive in. We’re going to talk about some security testing tools that you may have seen in your time as a DevOps engineer or trying to find different testing tools for your CI/CD or the lifecycle of your applications on the development side.

Here, we have things like static tests for security analysis, which looks at the source code of your application. It's great for testing early on. However, there is a high false positive rate.

Then, there’s also dynamic testing that you can do as part of your application lifecycle. This typically has lower false positives, however it can take a little bit longer.

There's also interactive security testing. This is something similar to RASP (Runtime Application Self Protection), which we'll talk about here in a second. But, pretty much what it's doing is it lives within your application code and can find security vulnerabilities as you're deploying your code.

Today we'll be talking about FAST (framework for automated security testing) and we'll talk a little bit more about why to choose our automated security framework and how to use it in today’s demo. On the production side, you can do further testing as well in live applications. One of those being dynamic testing, which is able to be done in development as well. Same thing for interactive testing which again works similar to RASP.

There's also what we do here at Wallarm, called active threat verification which lives on the WAF or web application firewall. So what we do is we take a look at your live application traffic to find threats and attacks that are going on and we verify if that attack is finding an exploit. The last part is RASP. This also lives within your application code. So this is typically a library for something like Python or JavaScript node. Things like that to do security live in real time. We want to talk about FAST today.

The reason why we want to use FAST is because we want to shift left and do security right. What is Wallarm’s FAST? It stands for framework for automated security testing. What we're doing here is we want to take your existing functional tests that you're already using and automate them into hundreds or thousands of security tests. And, we want to make this as simple as possible without any changes to your code, your pipeline, or anything like that. So as you are going through your CI/CD pipeline you send Selenium traffic to your application. However, we have a proxy that sits in between that is generating security tests for things like cross-site scripting SQL injections, remote code execution and much more as well as being able to do fuzzy testing for things like user input or API key values. So we are thinking about DevOps. We want to have security at both ends of your DevOps pipeline. On the left side we have the FAST proxy. We have the CI/CD integration where we are creating tests and then verifying your application security policies. So we're doing monitoring and analytics on the FAST module and fitting that into your CI/CD pipeline. That way you never send traffic or an application with security vulnerabilities to your production on the right side. We have the web application firewall or the cloud native app adaptive west. Again it's doing something similar. However, this is for your application that is live.

If you ever have an application that has security vulnerabilities, which happens more often than not, we want to make sure that we are protected on both ends of your CI/CD. So how do we actually do this? We capture a baseline typically from QA or production traffic. Or, you can also use something like Selenium for more automated tests. FAST acts as a proxy and we create security tests. We do this by inserting cross-site scripts patch reversals, remote code execution, cycle injections into those APIs or applications that are being tested. We can also create thousands of tests by applying fuzzing so we can add user inputs for specific fields. And, we add hundreds or thousands of inputs to those applications trying to find anomalies and security vulnerabilities so that  you don't push vulnerabilities to production. You can also specify a test parser to detect anomalies. There's also policies for generating tests, which can be defined out of band so you can set a policy for only looking for a SQL injections and remote code executions for API as you probably don't care too much about doing cross-site scripting because this is all happening from an application rather than a browser. You'd probably not care about end user vulnerabilities at that point.

Next, we're going to start running tests so the generated tests run automatically. The running tests are retrieving results in an easily automated fashion with an API for CI/CD integration so everything that we have within our products has an open API. That way, whether you're using Jenkins or Jenkins plug-in or some other CI/CD pipeline tool, you'll be able to run these through these APIs pretty easily. What we also do is we take authentication and credentials from the request so it's inherited. There's no need to add those credentials to another testing tool. Real testing and termination criteria are explained within the application. We also do regression testing as well. We'd like to think of this as auto security in CI/CD. So, you have an automated security pipeline when you're deploying your code. On the left side, pretty standard check code and to get whatever Github code-check that you have that is then going to kick off the pipeline which is going to build docker containers. You may do lots of other things before this for security testing. Things like static analysis can be done before you ever kick off a docker build. But, this will be a simplistic overview today.

This is how we're going to go and deploy our containers. Once we have that target container build, what we're going to do is we are going to build this middle part of our development environment. We're going to kick off our Selenium functional test, which is going to then proxy all traffic to the FAST Wallarm node.Once we have that proxy traffic, the FAST proxy is going to call out to the Wallarm cloud A.I. and ask for recommendations to send security tests for. The Wallarm cloud is going to send those recommendations—those security tests, SQL injections, cross-site scripting, fuzzy testing. And, this all depends on the policies that you've created. When the FAST gets these tests generated, what it's going to do is it's going to send the FAST security test to the development application and it's going to run these tests. If it fails, the pipeline stops. If it is good, it passes all security tests and then it's deployed into the proper environment.

So we're going to jump into a demo, but just before we do that here's the architecture diagram of the demo. We have four different nodes. We have the server, which has the Jenkins plug-in for FAST, that looks for the FAST test results. We also have Selenium grid, which is going to be generating the functional tests. The functional tests are going to be calling out to the proxy container, which is then going to request the test. The tests are then going to be sent back to the proxy and going to request the test from the application.

Just to see what we have in our Jenkins configuration, all we're doing is we're looking for a code commit from our Wallarm Selenium repository, specifically on the master branch again. This is very simplistic for the sake of understanding. You may not have this type of setup. You may be doing lots of different triggers and builds and the like, but all we're doing here is looking for a GitHub trigger web hook for the request.

Here is what the Wallarm FAST plugin looks like. We are calling out to Wallarm API. We have our credentials. We have the node token. We have the testing that we have within our workspace that's pulling down from the GitHub repository. We also want to set what the docker machine IP address is. This is all happening local within the Jenkins pipeline so we're not changing anything here. We're looking for the Docker image as well as the policy name. If you don't have the policy name here, we'll default to the default policies, which are pretty good. But there are still things missing that you may want to modify that for your specific needs. Then what we want to do is allow the host mask or the website that we're going to be testing for. Go back to our FAST project and we can see that test it ran. We're going to just kick this off by creating a file and committing it to a task file. And that should kick off a pipeline. So we can see that the pipeline is now being built. We'll go ahead and go to the console output as well as going to take a look at what we've had previous to this because it's going to take about a couple of minutes to see the Wallarm project results. You can see all the different tasks that have failed or passed on test 47. We had five baseline requests to pass, three failed. We'll just go and jump into that while the other ones are building and we can take a look at the Wallarm build results.

Here, we can see that the different tests that were ran. We can also look within our dashboard to see everything that's going on here. But the neat thing about the dashboard that we've built here is that we can simply go into this issue and it takes us to the vulnerabilities page. This vulnerability gives it in an easily digestible way for your developers to understand. Here, we can look at the different results we found. And we can see the vulnerabilities.

Whenever we want to give our developers an easily digestible way give them this command and it should show them why exactly this was a vulnerability. This was a request to delete snip it. As long as we get a response back, it's a possible vulnerability. We can also look at other vulnerabilities that we have found here. So you can see this one actually running now. We have found a pool of vulnerabilities. Couple of vulnerabilities. And again you can click on any one of those to understand why it failed.

One of the other great things that you can do is, if for any reason these are false-positives or there's some type of issue with the pipeline that was ran, you can mark it as false. You can also do things like close this. We can also set the rest to high, medium, or low. One thing that we can also do is have integrations into adding triggers and we can have slack integration. So, anytime there is a detected vulnerability you can actually send it to a security group. You can also send daily, weekly, or monthly security reports to somebody like the CISO or CTO, who may want to have daily weekly or monthly alerts.

That is about the end of the demo. You can see that we have everything. From the console output to all the tests that were ran. Anything that may have popped up. You can always take a look and understand what's happening. You can see that the test ran. If it failed. That's why we got the read. And continue doing your test. If it passes, it should automatically send to production in your CI/CD pipeline.

That is everything. Thank you for joining. We have an email that we have set up for any questions requests@Wallarm.com. Again, I am Eric Lugo I am solutions security engineer and that's my email address.

We're going to be answering questions here. All right, so there is a question: “Are there any other plugins for anything else like CircleCI?” Right now we don't have any plugins but we do have some information on running that through CI/CD for CircleCI and other pipelines.

There's another question, “does it runs in Kube so we can run Wallarm FAST in a Kubernetes cluster?” The Kubernetes cluster can run the FAST container just fine.

“Does it support multiple Jira instances?” So I'm not quite sure I understand the question. Multiple Jira instances. What we can do is actually use our API integration if you have things like you know a Jira or two different teams or two different companies. We can use that open API and send the output to the Jira that makes the most sense. Or, we can send it to both of them. So that shouldn't be a big problem.

“You mentioned that \tests were regulated by policies. Can you talk more about that?” So what we can do with the test policies is change different rules, different security tests. So the ones that I ran were the rest API. You can change the insertion points so by default we're only getting what we want to look at. We can change those to the different headers or we can look at specific JSON on things like that. We want to look at the different types of attacks to test. On top of that we also do support a domain specific language, or DSL, where you can create your own test and I can actually show you what this looks like.

A couple two months ago, when I first started, our CEO Ivan asked for me to create a new test for a CI/CD was for specific for rails. After reading the documentation and everything, it took me about an hour total to come up with this, including the documentation. So it's not too difficult to understand, but yes, you can also add these tests for your specific type of application. And then there's also fuzzy testing, which we can turn on or off so we can add payloads. We can change the anomalies. Things like that. This product can be integrated to other vulnerability management tools such as Rapid7. So again, if we have an open API, we can integrate pretty easily with any of them through their existing tools through their management tools. Great question.

We can we can definitely push our data and attack traffic analysis to those other tools.

Any other questions?So there's another question whether highly distributed can have multiple proxies. Should be fine with any number of instances.

If you would like to know more about Wallarm and the different security solutions and test out our security protections that we do—either on the Wallarm FAST on the development side or Wallarm FAST with our active threat verification and security testing and vulnerability scanning—we can absolutely do that.