This first chapter will discuss the challenges of security automation and take an overview of security automation tools and frameworks. The required skills, security tools, and automation frameworks will also be introduced. This will help you to gain the foundational knowledge required to build security automation measures in the coming chapters. Finally, we will also set up some sample vulnerable source code, as well as an application, for practicing security scanning in the coming chapters. This will include an illustration of dynamic security testing techniques (OWASP ZAP, NMAP, and fuzz) and static code inspection with automation frameworks (such as Selenium, Robot Framework, JMeter, and behavior-driven development (BDD)), as well as a look at mobile security testing framework integration in several hands-on case studies. In the later chapters, we will be using a project to apply all the security testing tools and automation frameworks discussed in this book.

We will explore the following topics in this chapter:

• The purposes and myths of security automation
• The required skills and suggestions for security automation
• General environment setup for coming labs

The purpose of security automation is to discover all potential security defects before any software release by applying both open source security tools and automation testing frameworks. However, security automation doesn't mean to completely replace manual security testing. Security automation aims to reduce the amount of repeated manual testing and increase testing coverage in an efficient manner. Potential security flaws can exist anywhere, from the source code and third-party components to an insecure configuration or vulnerable infrastructure. As the release cycles of cloud services and software development are getting shorter, the development team needs not only functional testing but also automated security testing. If your team is planning on implementing security automation, it's suggested that you begin with the following resources:

Security testing can be a tedious and repetitive process. The functional testing may only need to ensure the functionality, but the security testing needs to cover various kinds of the testing scenarios, such as authentication, authorization, XXE, injection, deserialization, and more (see the OWASP resource mentioned in the previous table). Therefore, a certain level of automation would be helpful, considering security testing's repetitive nature, scope, and importance. Be reminded that our goal is not to automate 100% of security testing cases, but to focus on those testing cases that are manually executed and repeated, and so can be done more efficiently by automation. By automating those repeated security testing cases, penetration testers can take time to exploit in-depth weaknesses and logic flaws or review security requirements (all of which can't be done by automation).

When it comes to security automation, there are some challenges and some myths. A lack of proper security or automation knowledge leads to some misunderstanding of security automation. Here are some general suggestions and clarification. We will explore more through the different hands-on case studies in the coming chapters.

Our first myth is that security testing requires highly experienced penetration testers and automation testing can't find serious issues.

If we can guide the automation properly, serious security issues can be identified. On the other hand, automated security testing can also result in false-positive issues that need further manual verification. However, there are certain kinds of security testing scenarios that would be ideal for automation; some of those are listed here:

• Detecting the use of banned functions, risky APIs, or weak encryption algorithms. Automated systems can do a good job of scanning code for security issues if we properly define the patterns we are looking for.
• Weak RESTful API authentication and authorization behaviors, such as bypassing authorization vulnerabilities.
• Data input validation may require massive amounts of random testing data input. This kinds of data input testing technique is also called fuzz testing which the prepared data and payload are dynamically generated for the test subject in an attempt to make it crash.
• Repeated UI walk-through, sign-in, sign-out, and form fill are good examples of where web UI automation is required.
• Insecure misconfiguration of software components, databases, or web services.
• Known third-party vulnerabilities.

Our second myth is that it takes too much time to build an automation framework and that daily development changes may break the automation.

For a development team with mature security testing practices, the adoption of an automation framework such as BDD, data-driven testing (DDT), or Selenium can help with seamless security integration and improve security testing coverage. Adding security testing cases based on these existing automation frameworks won't necessarily take lots of effort and time, so long as the right tools and integration approaches are selected.

For security automation relating to UI flow, daily development changes may or may not break certain UI automation testing cases. It depends on how the UI components are located by the automation testing program. As a general rule of thumb, so long as the UI components are located by the automation testing framework, UI layout changes won't impact the automation.

Our third myth is that there is no single automation framework that can cover the variety of security testing cases.

Now, due to the variety of security testing scenarios, it's true that there is no one single automation framework that can cover all security testing cases. Depending on the security testing scenario, however, we can plan related automation approaches with proper integration of security testing tools and an automation framework. The following table shows examples of security testing scenarios with different automation approaches:

Automating web UI operations doesn't necessarily take lots of implementation effort or require you to be an expert in Selenium scripts. The Selenium IDE extension will help you to generate automated scripts when you operate UI flows:

• Kantu Selenium IDE: This generates HTML-format scripts. It supports parameterized testing by CSV, takes screenshots of each step for visual review, and can be executed from the command line.
• Katalon Recorder (Selenium IDE for Chrome/Firefox): The key advantage of Katalon is being able to generate various kinds of automation scripts, including Java, Python, Robot Framework, C#, and Ruby scripts. This makes Katalon very flexible for further integration with other tools. It can also support screenshots and DDT by importing CSV files.

Security team developers and automation testing developers require different skill sets. Naturally, the core skills of automation testing developers and pentesters are different. However, achieving security testing automation won't be too difficult for anyone, so long as the appropriate tools and frameworks are adopted to reduce the learning curve and ensure consistent delivery quality. For example, the adoption of web UI automation will help security testing to explore the blind side of the user flows. However, web UI automation and the adoption of the Selenium automation framework can be a big challenge for the security testing team. This issue can be solved with the help of proper automation testing tools, which will be introduced in the coming chapters.

The skills that penetration testers and automation testing developers have in common are as follows:

• Familiar with a programming language, such as Python, PHP, Java, or C/C++
• Familiar with Windows, Linux and TCP/IP (Transmission Control Protocol/Internet Protocol), and HTTP networking

Those were some similar skills; the following table lists some key differences:

For coming hands-on practices, it's suggested that you prepare the following tools for the system environment. Please also refer to the official website for the installation or quick start guide of every tool:

• Git: https://git-scm.com/downloads
• Python 2.7 (Python 3.4 may also work): https://www.python.org/downloads/
• PyCharm: https://www.jetbrains.com/pycharm/download/
• Vulnerable C/C++ and Java source code: https://samate.nist.gov/SRD/testsuite.php#standalone
• Insecure Bank APK: https://github.com/dineshshetty/Android-InsecureBankv2/tree/master/InsecureBankv2/app
• GoatDroid APK: https://github.com/linkedin/qark/blob/master/qark/sampleApps/goatdroid/goatdroid.apk

In this chapter, we discussed the objective of security automation: to reduce repeated manual testing and increase testing coverage in an efficient manner. The OWASP Top 10 list for web application security issues and the CWE Top 25 list for secure coding issues were suggested as resources.

We also discussed some misunderstandings of security automation, such as the need for highly skilled penetration testers, the time it takes to build automation frameworks, and the perceived limitations of automation testing's effectiveness. Security automation testing can even identify serious security defects, and won't require lots of implementation efforts, so long as the right security tools and automation frameworks are integrated properly.

Last but not least, we also discussed the skills of security developers and automation testing developers. The common ground required between these two roles includes only knowledge of networking, HTTP/HTTPS protocols, an operating system, and at least one programming language. The automation test developer may focus more on automation testing frameworks such as BDD, DDT, Selenium, unit testing, and so on. On the other hand, the security tester may focus on using security tools and techniques to identify security issues. In the coming chapters, we will demonstrate how security and automation can integrate properly to identify security issues in a more effective manner.

1. Which of the following provides a list of the most common software coding errors and can be a good checklist for the team to do code-security reviews?
   1. OWASP Top 10 Application Security risks
   2. CWE Top 25 Software Errors
   3. SDL
2. Which one of the following statements is true?
   1. Security automation testing can't identify serious security issues
   2. Elements of the UI flow, such as sign-in and sign-out, can't be done by automation security testing
   3. Web UI automation can be done by using Selenium IDE (Kantu or Katalon) to reduce implementation effort

3. Which of the following automation frameworks does not do web UI automation?
   1. Robot Framework
   2. Selenium
   3. VCG
4. Which of the following is not a required skill for an automation testing developer?
   1. Familiar with OWASP Top 10
   2. Familiar with Python and Java
   3. Understanding of Windows and Linux
5. Which one of the following is not an automation testing framework?
   1. Robot Framework
   2. Selenium
   3. SQLMap

• CWE Top 25: https://cwe.mitre.org/data/index.html
• OWASP Top 10: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
• Robot Framework: http://robotframework.org/
• Kantu Selenium IDE user manual: https://a9t9.com/kantu/docs
• Katalon Recorder: https://www.katalong.com/resources-center/blog/katalong-automation-recorder/