Skip to main content

One post tagged with "security testing"

View All Tags

ยท 4 min read
Tuomas Tonteri

While planning their information security activites, for example software product companies are at times wondering whether they should order security testing or an audit. Quite often these terms are also used interchangeably, perhaps out of ignorance on the speaker's part. Rather frequently security testing is referred to as an audit.

So, do these terms have any difference? Is a web app compliant with ISO 27001 after two weeks of security testing?

Security model

Security testing is typically investigatory, or exploratory, where the target system is gone through systematically, but the testers' attention is inevitably directed towards the most probable vulnerabilities in the system based on the prior observations made and previous experience of the testers. Software's functionality is tested by using the system and by sending modified and intentionally unexpected or broken requests to it with the aim of causing instability or other unexpected behavior that would reveal exploitable defects in the system's functions or its defences. A varying set of test cases is applied to different sections of the system. Tens of thousands of different requests may be sent per individual function to identify functional borderline cases and dimensions of the security controls. Whatever the approach, security testing can never cover all input variations, branches of functional logic or request sequences.

Of course, it is also not impossible to scope security testing to a very narrow part of the target system, such as logon only. In order to ensure its reliability, specific test cases are defined and precise automation is built to perform testing for good test coverage (logic branching and input boundaries). This can bring significant benefit for the implementation of security regression testing in the future.

In addition to the above-mentioned factors, the scope and coverage of security testing is always limited by the project's scope and the available time frame and workload. The end result is the best possible review of the target system's security in relation to the amount of work used and the scope of testing, for example from the perspective of the user interface and APIs. Target system's security testing can be approached in many different ways, e.g. by testing the software itself, its runtime environment, integrations or the entity's ability to maintain data integrity in exceptional and error situations. Naturally, coincidence also plays a part in the findings that are discovered.

If security testing is a vague and multidimensional term, auditing surely gets the better of it. More established definitions are based on the premise that an audit is typically an external event to determine whether certain criteria is met. Audits are thus a kind of a conformity assessments, in which the key is to reach an unambiguous conclusion. The requirements are either met or not. A security auditing must therefore be an assessment of the fulfillment of security-related criteria. The target of the assessment can be practically anything. In a security audit, for example, the target could be an organization with its operating methods, a company's IT infrastructure, a web service or another information system (ERP, CRM, office apps etc.), software development methods, DevSecOps policies, software architecture and so on. In addition to the subject of the assessment, it is necessary to choose which criteria or framework of requirements to use in the audit. An organization's information security management can be evaluated in accordance with ISO 27001, the activities of development teams with regard to information security by using the OWASP SAMM model or different Secure SDLC models in case cherishing information security throughout the software production process should be emphasized. OWASP's comprehensive Application Security Verification Standard (ASVS) framework provides a broad overview of secure software design, implementation and testing practices.

As with many things, the key is to maintain continuous information security work and systematically proceed with it. It is worthwhile to combine different frameworks, operating models, partners and experts so that the perspective and views are renewed in favor of more diverse and comprehensive outcome. It is often reasonable to combine practical testing and conformity assessments such that the realization of secure design principles is assessed in the architecture and the secure coding results are ensured by testing.

Performing security testing doesn't make the target compliant with e.g. the ISO standard, and passing the ISO audit doesn't make the target secure. Both approaches are needed.

Thus, security testing does not provide absolute answers about system security. The results of an audit indicate whether the selected requirements are met according to the auditor's view. So how could we, let's say ensure corporate information security? Well, at least it's clear that as an industry we still have a lot to develop and learn, but there are already good methods and tools for versatile security work.