Ten years ago, you could kind of get away with not paying much attention to security. This worked if you were not in certain sectors or didn’t have a certain profile, and if you were lucky. Until a few years ago.
Read our earlier article to understand how for everyone, the impact and likelihood of potential security incidents has increased drastically. Now, preventing an incident has a lot more appeal than it used to, including for those organisations that traditionally didn’t need to pay a lot of attention. As a result, more organisations are now testing their preventive security measures, with more depth.
At Securify, we see this reflected in the way that we help our customers choose the most effective security testing strategy. This is usually a combination of testing at the level of code, application, infrastructure, or organisation. Read on and find out about building blocks for a good security testing strategy. The bottom line: testing early and continuously will give you peace of mind because it results in a more resilient foundation for your organisation.
Test at the level of code
If your organization produces code of any kind, or has it produced by a third party, this is absolutely where you need to test. We’re talking automated and manual code reviews. Testing at this level has increased, because it provides real-time feedback on code quality and allows for quick turn-around of fixes. And when we say “code of any kind” we mean it. Treat “infrastructure as code” as actual code and have it tested early and regularly.
Most tools are rules based and don ’t usually pick op business logic flaws or other app specific problems. Fill this gap with code reviews. Traditional full code reviews still work in the case of periodic releases of code, for example for firmware. But for most web applications, organizations need agile code reviews that integrate into their development process and report without delay.
Testing at the level of code is by far the best bang for your buck:
- Early fixing is cost effective. Feedback when code is still fresh gives developers a leg up and reduces their time to fix an issue.
- Immediate feedback about code quality is superior to isolated secure coding trainings.
- It will reduce the number of tests required and will reduce the number of findings.
Test at the level of the application
This is traditionally the place where organizations periodically test web or mobile applications, APIs, embedded or IoT devices. Almost all the application tests that we carry out are white box tests. And these application penetration tests make sense.
- They can pick up weaknesses in a full stack production-like environment that a code review cannot find.
- They can be increased or reduced in intensity and frequency depending on the changes in your code.
- As part of defense-in-depth, they complement agile code reviews periodically, provided they are white box tests.
Remember, there are very few good reasons to opt for a black box penetration test, and if your development team produces a lot of code and you want it to be secure, you are wasting money if you only test your code periodically.
Test at the level of infrastructure
Testing at the level of infrastructure has changed tremendously. The norm used to be periodic penetration testing and regular vulnerability scanning. These have now all but converged: many organizations opt for a variation and combination of continuous vulnerability monitoring and continuous penetration testing.
- They help you identify continuous quick fixes and more structural improvements in core processes such a change management, identity management and vulnerability management,
- They put weaknesses in perspective. Multiple lower risk findings could add up to be quite urgent to fix, something individual tests of components cannot always spot,
- They don’t make exceptions for cloud and on prem, because neither do attackers.
Breach and Attack simulation has emerged and bug bounty programs have grown in maturity, which, depending on your definitions, both occupy a space near continuous vulnerability monitoring and continuous penetration testing, overlapping a bit with both.
Remember infrastructure testing will result in a combination of short term and longer term action items. And organizations that handle their infrastructure as code would do best to also test their infrastructure as code and submit it to periodic reviews.
Putting it all together: test at the level of the organization
For a truly comprehensive and all-encompassing security test of your organization, the right choice is a security test where in terms of scope and MO, “nothing is off limits”. The most common form used to be a red team exercise, but more and more organizations choose for the more effective purple variant that includes active participation of defenders.
- Purple is almost always preferred over Red, and threat intelligence should be consulted to make the exercise realistic.
- Scaled down versions, such as scenario-based penetration tests are more suitable for smaller organizations or when a higher frequency is preferred.
- The ideal frequency of purple team exercises depends on the organization. It is influenced by factors such as maturity level, the size of the organisation and the ability to effectuate changes. We see anything from monthly to once every three years.
Do you want to discuss specific security tests or discuss your own security testing strategy? Give us a call.
Are you looking for more information about developing your own security strategy? Read our Case Study with De Vereende here or feel free to get in touch via the links below.