Follow @techarcis

Never send a human to do a machine’s job – This is the key principle driving continuous and automated testing in the DevOps world.

The key to agile methodologies lies in continuous and automated testing software during the development phase. To run a continuous delivery pipeline or continuous, reliable integration, automated integration, unit and acceptance tests are indispensable quality controls. Sadly, security tests are often left outside the ambit of this procedure due to some flawed belief.

Is automating security testing a good move?

Yes, it sure is. Just think about the scenario where you just need to examine if known flaws have crept into your software codes or its functionality and have a person to run these checks manually. Wouldn’t it be a sheer wastage of manpower as these routine tests can be done easily and efficiently by automation? True that you will always need intelligent professionals for ensuring top-notch quality and testing certain aspects of the software, but engaging people for routine security tests isn’t economically feasible, more so when you can easily automate the process and put the freed human resources to better use somewhere else.

Compared to penetration testing of yesteryears, the need of the hour is continuous and automated testing as continuous deployment demands continuous configuration, development and testing.

Bringing the developers and testers together

In DevOps world, you need a secure SDLC (Software Development Life Cycle) approach. Remember – you just can’t ignore or compromise with security. But as it happens in small increments, you can start small without feeling overwhelmed, in case you haven’t started running continuous and automated testing.

Step-by-step approach

1. The first step is to plan, where you will have to –

• spot unsecured frameworks and APIs
• map parts of security sensitive codes such as user authentication/password changes mechanism
• understand User roles and their level of authentication at each level of application
• foresee regulatory problems and chart out a way to overcome them

2. The second step is to get your developers involved and connect them to security. You should encourage an open door approach and if necessary, opt for online collaboration and communication solutions like Confluence, Jive etc.

3. The third step would be to empower your developers by asking the testers to provide them with secure frameworks and Service Component Architecture (SCA) tools that can offer rapid, frequent security feedback on pre-commit stage. This should be followed by automation where you integrate within your build (Bamboo, Jenkins, TeamCity etc) and leverage SAST, DAST and IAST. You should mark the build a “failure” if it doesn’t pass the security bars.

Security testing levels

You can classify security tests with respect to automation as given below:

• Functional Security Tests: Used to verify and test if security features such as log out and authentication are functioning as expected. You can use existing acceptance testing browser automation tools like WebDriver/Selenium to automate these.
• Application and Infra Security Tests: Open Source tool OWASP ZAP is ideal for such exhaustive security scanning.
• Non-functional Security Tests: Misconfigurations and known weaknesses can be tested and automated as the glitches are known already (even when the Dev Team doesn’t know, the Security Team will know it for sure). Thus, whether it’s using weak SSL ciphers and suites, or not using HttpOnly flag on session cookies, you can test them by leveraging a fusion approach where browser automation and a proxy server is used to examine and inject requests.

Many believe that you can’t use automation to test application logic. It’s true to some extent as finding errors in the logic of the application would need a human brain at work. That’s because automated tools can’t deal with the different functions that need to be tested in such cases, by drawing upon past experiences and skills. However, once the glitches have been noted (say, how an attacker may attempt to transfer funds from a bank account to his/her accomplice’s accounts), you can define the parameter and record them as automated tests. These can then become a component of the security regression tests.

Setting up security goals and their implementation

In the DevOps world, security goals must be stated clearly and driven by the business objectives. Since all teams work as a close-knit unit in DevOps, there should be open communication and collaboration and the security tests must be understandable by all stakeholders.

In other words, you should be ready to –

• expose your processes to testing
• record routine manual security tests and automate them
• ensure that the security tests fit into DevOps workflow and CI/CD (Continuous Integration and Deployment) pipelines
• make sure the security tests’ logic are independent of navigation code
• check for test errors and test failures
• keep a close eye on test maintenance
• perform regular sanity checks along the way
• ask your testers to provide you with a starting point of ready-to-use security tests

Integrating security testing into your automated build process also needs you to use regular methods like WAF, periodicpen testing, reviewing the code for security-sensitive portions. The basic principle is to get everyone on the team involved in the process and bring developers, testers, QAs and IT-Infra people together so that it’s a team effort and there isn’t any “them”…it’s only “us”.

TechArcis is an organization specializing in the area of Security Testing Solution that has a team of highly skilled, co-located software testing professionals who ensure delivery of quality products that help quicker go-to-market and also control efforts and expenses.

More Related Blog