Why should we be concerned about security testing?
As our world is revolving more and more around web and technology, cyber security is increasingly becoming the biggest issue. As we know that, most of the software is complex in nature and can pose a lot of different types of security hazards. These issues could range from bad coding to wrongly configured servers and anything and everything which falls in between. Everyone in the periphery needs to be always well aware of these issues and what they are working on if an organization wants to solve these problems.
To get the software developers to think more seriously about the security issues, its principles and standards, a new movement called DevSecOps has been started.
It could seem daunting to developers even for an experienced one to test the security for web-based applications. The process of skill building seems a prolonged one as well as getting information on security testing.
However, security testing is, in fact, similar to functionality testing in more than one way. The main difference between testing your application for functionality and security is one of attitude or mind-set. During a functionality test, you as a developer try to find out which feature works for the end user best and which does not. You would probably try to prove that a particular set of applications are working as expected for an end-user and does not create any obstacle to completing the task seamlessly. In the next step, you would try to priorities accordingly, give more focus on the features that are used often and by more users and like that. On the other hand, as a security tester, you would try to visualize your end-user as an attacker who is trying break into your application to steal important information.
Now, the problem for a security tester is that it is much easier to prove the functionality of a feature than its vulnerability. Well, the starting point could be to take a similar approach of prioritising – like – testing only for the set of most popular or most likely or simplest form of attack for each feature.
Automated Vs Manual Testing
In the world of DevOps, the principal element is automation and any repeatable or routine task could be and should be automated to save time, money and human resource. We all know that automation actually ensures consistency in those routine tasks. However, till date, although about 40 percent of software testing is automated most of the security-related software testing is still done manually and often deployed late in the software development lifecycle.
The reasons for this are –
- Perception of the companies that, manual testing cannot be replaced by automated testing. Experts in this field say that that perception may be the truth but some amount of testing could be done automatically and this will actually help manual testing to be more focused and more value extracting.
- Another reason apart from the mindset that, automated security testing cannot be trusted, there is a general belief that deploying automated security system in the organization is very expensive which is not entirely true.
- According to the specialists, the organization seems to feel that implementing automated security testing is an overwhelming task and they put it away on their priority list.
Deploying automated security testing in practice could reap more benefits than assumed
The organization can actually benefit in multiple ways if they decide to implement automated security testing, leave aside the speed and consistency. The organization need to remember that, security testing ought to be dealt with any other software development and delivery. Those who will incorporate automated security testing into their organizational workflow experience additional benefits consistency, effectiveness and increment in velocity.
In an automated security testing environment testing is completed with the same level of efficiency every time and without any subjective influence. This also permits communication between teams which ensures that the whole company is protected and compliant.
Automated security testing could be categorised as follows
- Functional Security Tests
These tests are targeted to verify the security features such as log out and authentication work in an expected fashion. Using the existing acceptance testing automation tools like Selenium / WebDriver these could be easily automated.
- Specific or targeted non-functional tests against known vulnerabilities
Another well-suited field for automation is the area of known weaknesses and mis-configurations like the use of weak SSL suits and Ciphers or lack of the Http only flag on session cookies etc. These could be easily tested with automated testing because they could be detected up front. These tests the non-functional aspects of the software, they need access to enter the HTTP layer which is not possible by browser automation tool. So, you need to take a hybrid approach: it should be combined with browser automation together with a proxy server and probably the best combination is WebDriver with OWASP ZAP.
- Scanning of the application and infrastructure
Usually, every manual penetration tests start with an automated scan using the tools like Nessus, Burp and OWASP ZAP. However, there are significant differences between these tools. Nessus would not be able to scan any content or functionality beyond login form and cannot navigate through a web wizard. ‘
On the other hand, Burp Intruder and OWASP ZAP are true application scanners because they inspect and check at the HTTP layer by inflicting attack data into parameters and evaluate the response of the application. These tools are able to provide in-depth security scanning if used in a proper way. This means if they are used to only run an automated test then there is a chance that they may not test all the content deeply.
To successfully run an automated application scanning, it is to be ensured that all the content to be scanned is navigated and populated in the scanning tool before starting to scan the application.
- The logic of Security Testing application
Automated security testing tools can only detect flaws in the security but flaws in the logic of an application need a human intelligence at the time of writing it. An automated scanner will find no difference between an online auction and an online banking site but from a human intelligence point of view, these are two completely different beasts with different functionality. So, a human security tester may try to test –
- Can the HTTP request be manipulated after the bid for an item is ended?
- Can the HTTP request be manipulated to set a higher amount and then modify it to a lower amount before the auction ends?
- Can money be transferred to someone else’s account using a negative number value?
To find out the possibilities of the above set of queries one needs to be innovative and experienced but once the attack is defined they too can be recorded to do an automated test later on.
How can you set up before running the test?
It may seem daunting at first but it is not really necessary to deploy all the steps mentioned above. Steps 2 and 3 are the most important ones in comparison to the amount of time invested against the security value extracted and since they help to identify a lot of common security weaknesses that missed in a normal development process, implementing these two steps at the beginning will be a good start.
Secondly, the organisation could choose any testing framework to be orchestrated and run these tests but it would be always wiser to choose a framework with which development, operational and security teams are comfortable and which could be very easily integrated with the organisation’s CI/CD server. BDD framework is a good option as they use natural language to define the testing steps that means they could be understood by a large audience instantly.
When or how frequently to run the tests
Automated tests are very low cost so it is best to run them as early as possible during the development process but it is always better to run the test along with the automated acceptance tests.
