Consider the scenario where your software development group has created a new application for your finance team. They have been coding for four months and now have what they believe is a useful tool that they would like to roll out to the whole company. However, as the information security manager, you are concerned that there may be problems with this code. You need assurance that the new software is secure and won’t cause a security risk that is deemed unacceptable by the management. Therefore, once this new software package has been created, and prior to rolling it out, there is much value in having it properly tested prior to deployment. This kind of security testing provides your management with the required level of confidence that this new system doesn’t introduce vulnerabilities into your infrastructure that could leave your company exposed.

So, how do you go about testing such a system? There are various methods that can be employed, with the most common being a hybrid regime, comprising aspects of all available methodologies. This provides a holistic approach to evaluating the security posture of your new application, ensuring the most common coding errors and mistakes are eradicated before it’s rolled out to end users. Testing from a business perspective allows you to test what a typical user might be able to exploit in the software. This kind of testing can include running through various workflows that mimic how a typical user would use the software. You can then instruct your tester to perform ad-hoc testing where he uses his initiative to attempt to break the system, using only the interfaces that are available to the user. In support of this, you would perform vulnerability analysis, code reviews and targeted penetration testing, all of which we’ll cover in more detail shortly.

TEST SCHEDULES

Maintenance of your testing regime is essential to ensure that you both update your testing as the application evolves, and you perform repeat testing, based on the knowledge of new vulnerabilities and methods that may have been unknown when you last performed the application testing process. The frequency of testing applications is determined based on the frequency of updates to the code base, what the extent of the updates are, and if supporting environments have changed. For example, even if your code base has not changed over the last 12 months, the underlying Java Runtime Environment (JRE) might have changed, forcing your IT support team to update your Windows 10 tablet PCs. As a result, the supporting infrastructure in the Java modules may have introduced some unknown vulnerability that a repeat test might find. On a similar vein, vulnerabilities in the current Java Runtime Environment might have been discovered that now leave your application exposed, even though 12 months ago that vulnerability was unknown to you. Therefore, you need to update the JRE and retest the application to ensure that it still works. Testing frequency should be defined in policy and detailed in your operational security plan. This will cover all aspects of your system, including bespoke solutions, infrastructure components, configuration, access control systems, and can even include testing physical security and administrative processes.