Enterprise applications are now an essential foundation for business success. But do we have the right security measures in place to match their growth in numbers and speed of development?
Organisations are moving faster than ever before to adapt, seize new opportunities, and launch entirely new business models. Development of new applications and websites are at the heart of this change.
Businesses today are desperate to innovate. The big names often quoted as examples of the new “platform economy” include the likes of Amazon, Netflix, and Uber. But in truth, almost all companies across all industries are now heavily reliant on applications to compete and succeed.
Development teams have risen to this challenge as well. Agile, DevOps, and continuous delivery (CD) have revolutionised the speed of application innovation and the frequency and volume of in-life changes.
The result has been an explosion in the number of business applications to help organisations adapt. Research by McAfee, for example, suggests companies with 50,000 employees or more operate 788 custom applications, on average. Even smaller companies (1,000 employees or less) use at least 22 custom applications on average to do business.
...with the application revolution comes an important question: has security testing kept pace?”
But in this brave new world comes a severe, unavoidable problem: every new or updated application is a primary target for hackers. Web-based applications are readily available for invisible actors to probe and investigate 24/7 from the comfort of their own home or, as the cybercrime “industry” grows, from the comfort of their offices. With this in mind, it’s no surprise that application vulnerabilities remain a key route used to disrupt businesses or gain access to private (and valuable) data.
That’s why testing for vulnerabilities - finding errors in the applications themselves and the configuration of the underlying infrastructure - is so essential before the bad guys get there first. But with this application revolution comes an important question: has security testing kept pace?
In other words, can the average security testing strategy handle today’s application volumes and speed of development?
Our view is simple: no.
That’s why we have published this two-part series to explore the issues.
In this second instalment we focus on the speed challenge - with the accelerating pace of application coding and development in many organisations, are the security teams in danger of being left behind? More to the point, how do we move fast and stay secure?
Also available: Penetration Testing Re-engineered: Part one
Recent years have seen a transformation in the pace of application development and the rate of changes and updates, thanks in no small part to the adoption of DevOps.
Previously, new application releases would occur at a much slower rate: three to six months was a typical schedule. But it is now common for organisations to update applications on a weekly or daily basis. At the bleeding edge, according to New Relic, Amazon releases fresh code every 11.7 seconds, and Netflix does the same thousands of times a day.
... we are clearly faced with a missing link as we try to secure our digital worlds.”
The good news is that agile development practices allow teams to quickly produce working code by shrinking activity into small, focused release cycles. This means pipelines can grow dynamically through continuous interaction between developers and their internal customers across the business.
As a result, new features can be defined, developed, tested (functionally), and deployed within days or weeks, enabling organisations to adapt quickly to changes in customer demand and maintain their competitive edge.
But this presents a double-edged sword for security teams.
On the one hand, agile development offers significant benefits to application security. Security issues such as coding errors, vulnerabilities in third-party libraries, or new risks driven by the release of new hacking tools and methodologies, can be scheduled to be fixed in the next sprint, massively reducing the window of risk when the vulnerability is exposed.
In other words, gone is the long wait for the next six-monthly release cycle to correct an issue.
But on the other hand, this rate of change also introduces risk in its own right. Under pressure to meet the demands of the business, it is understandable why dev teams need to move fast. Coding errors are one of the largest sources of security vulnerabilities, and they can give hackers an easy route into an organisation and its data. It’s not economical to run a full pen test for each minor release, and security doesn’t want to be viewed as ‘getting in the way’, which can create a tension between security and development teams when collaboration is what’s needed.
Combine all of this and, whereas DevOps and the continuous development of business applications can fuel agility and speed, it can also introduce new risks at a volume and frequency never seen before
And in a world where 38% of software development teams said they still have inadequate security awareness and training (not to mention the 61% of non-technical staff), then we are clearly faced with a missing link as we try to secure our digital worlds.
Survey respondents who said they are developing their IT processes faster with DevOps
But less than a fifth are confident they can handle this relentless change and stay secure
With DevOps forging ahead, many security tools have been developed in an attempt to keep up.
However, the fundamental check - the backstop to all security practices - still remains the penetration test. Using a combination of tools and human skill that no approach based solely on automated scanning can replicate in full, a well-executed penetration test is still an essential defence against today’s increasing cyber threats.
But whereas the detailed methodologies of penetration testing have to keep up with the latest threat landscape, the basic approach summarised by Dan Farmer and his team over 25 years ago in Improving the Security of your Site by Breaking Into it has remained unchanged in decades.
Pen testing is generally a time-based test: booked in and undertaken over a number of days or weeks, followed by a report detailing a long list of vulnerabilities to fix and patch. Typically carried out every six months or annually, this approach - while still important as a deep-dive test - has increasingly fallen out of step with the way development teams work and applications change at speed.
Whereas the pen test ran the distance perfectly well in the past - when business applications were slow to change - dynamic application development has left security teams in the slow lane in many organisations.
We look at two possible alternative approaches in sections four and five. But first, in section three, let’s consider three examples of the issues that traditional pen testing presents for organisations aiming to win on speed and agility.
Codebases audited contained opensource components.
Open source compenents that where out of date
Cosebases contained vulnerabilities
Average number of vulnerabilities identified per codebase
Let’s look at three example issues why the pace of penetration testing needs to be re-engineered:
As CISO Magazine reported recently, cyberattacks on web applications increased by 52% in 2019.
If you release code every week and only test it once a year, issues can remain unseen in your applications for months. With timing a powerful weapon for cybercriminals, and a substantial rise in the use of automated bots to search for vulnerabilities for malicious actors to jump on, this window of risk can be devastating for any organisation.
With companies adapting at much faster speeds, a continuous Software Development Lifecycle (SDLC) is now needed to stay agile and competitive.
But, if you want to do a full pen test before launch (as with traditional release cycles) you’re likely to introduce delays to your development… shedding that speed and agility your teams have been working hard to add to the plan.
Pen tests can take days or weeks. Timelines that just don’t fit with modern agile sprints, and puts the security team in the firing line as a blocker for necessary business change at speed. It’s easy for development teams under pressure to release new code thinking “security by design” is enough.
On a day-to-day basis, pen testing overloads in-trays.
One test on an annual basis is likely to present a long list of points to pick up and deal with. This adds work to the development work stack, competing with innovation and revenue-generating improvements.
A clear example of the challenge here is one customer who told us that by the time they had worked through the list of issues raised from their last annual penetration test, it was often time to run the next one.
These sort of delays to fixing issues just add to the overall time that vulnerabilities exist within applications.
In a fast-moving world, we don’t expect a list of feature requests once a year, so why do we spend a year getting our security house in order?
“A developer in their natural habitat is often spotted in a state of deep concentration, coding awesome features to tight deadlines. Feature-building is often our favorite part of the job, and really, it’s the fundamental outcome of the software development life cycle (SDLC).
“However, security best practices are set up to be someone else’s job and adequate security training for us is limited. Penetration testing and static analysis scanning tools (SAST) are just part of the overall process to mitigate security risks, operating rather independently from what we do.
“Until the code bounces back to us for hotfixes, of course.
“It’s at that moment that many developers think, Do the pen testers hate me?”
If manual penetration testing is too cumbersome, slow, and expensive for the current speed of software development, does automation resolve the challenge?
Automated application scanning has seen significant investment in recent years, and a wide array of tools exist to:
It’s true they can play a part in spotting a range of issues, and the best can be automated into standard CI/CD pipelines. The emergence and acceptance of ‘DevSecOps’ has marked the arrival of Security in the DevOps cycle in recent years.
But the automated scanning tools available today are still never as complete or as thorough as a skilled manual penetration test, and they can miss many business logic errors that only a human can spot. They can also generate a lot of output that is often hard to act upon without expert validation.
The best DevSecOps approaches use a blend of such tools at different points in the software development lifecycle, helping to remove some of the most common errors that can populate your application. This is better, perhaps, than using an individual tool but the same issue remains: however many tools you deploy, you won’t spot all the things a manual penetration test will.
These approaches to improving application security by design are a key part of the solution. Let’s be clear, adopting DevSecOps processes can have a huge impact, but this will never be the whole answer.
Finding vulnerabilities in custom coded content management systems
Simulating attacks that need WAF/IPS/Firewall bypass for exploitation
Testing insecure business logic functionality (for example, a password reset function that doesn't ask for your old password)
Chaining of multiple vulnerabilities leading to exploitation
Understanding the context needed to identify certain vulnerabilities (for example, Insecure Direct Object Reference (IDOR) and Cross Site Request Forgery (CSRF) vulnerabilities)
Happy with the speed and frequency of your penetration testing? That’s not our experience.
Speaking to many customers over the last few years, it’s clear they are looking for the rigour of a manual pen test, but with the agility and approach that matches dynamic application development.
One that’s led by skilled manual penetration testers, working as a team, but also deploys automated scanners - running continuously - to deliver a blended and more collaborative and dynamic approach to security.
On the one hand, scanning tools can highlight potential risks which can then be investigated further by skilled pen testers. Automation can also detect change, allowing the testers - working closely in virtual or sprint teams with their developers - to see when new changes have been introduced, so that every fresh line of code or improvement to the infrastructure can be quickly checked.
But it goes further.
Manual pen testers can also have regular time allocated to take the ‘hackers view’ of your estate. This can build up a complete test of your estate over time, and also provides the experience to spot the most complex issues.
Continuously testing this way - combining the activity of people and machines - also provides numerous other benefits over a “time-boxed” pen test. For example, many techniques that a hacker would employ, such as using a “rig” to crack passwords, take too long to complete in short engagements and are commonly an unverified attack vector.
“Continuous” means that intelligence gathered is not wasted because time is expired. All potential vulnerabilities can be explored, so only real issues are flagged.
What’s more, after the common “initial spike” of findings after onboarding, the flow of vulnerability alerts becomes more manageable. Developers, system administrators, and security staff can address fixes without dramatically compromising their existing workloads. One example is the increase in the number of “medium” and “low” risk vulnerabilities being addressed that may otherwise be overlooked following an annual pen test.
Continuous Security Testing does not replace the traditional large-scale penetration test completely. In fact, in many industries, pen tests are a regulatory requirement. But Continuous Security Testing does bring pen testing into line with agile DevOps strategies, allowing organisations to adopt a more robust, agile security posture.
Continuous Security Testing also builds a greater collaboration between development and security teams. With application code changes being implemented over weeks, days, hours, and even seconds - enabling businesses to challenge and disrupt their market - the priority now is to put developers and security in the same team.
And with cyber attackers right on the heels of this velocity of change, Security has an even bigger role to play.
Eight Principles for software development and deployment to help you improve and evaluate your development practices, and those of your suppliers
Secure development is everyone's concern
Keep your security knowledge sharp
Produce clean and maintainable code
Secure your development environment
Protect your code repository
Secure the build and deployment pipeline
Continuously test your security
Plan for securtiy flaws
Performing security testing is critical in detecting and fixing security vulnerabilities. However, it should not get in the way of continuous delivery. Automating security testing where possible provides you with easily repeatable, scalable security measures. Your specialist security people can then concentrate on finding subtle and uncommon weaknesses.”
See how Continuous Security Testing can help you adapt to today’s evolving threat landscape.
Web application security review – what you need to know for 2021
Join our expert panel to take a practical look at the latest threats to web applications. Find out how you can identify and mitigate these risks in your own web application estate.Watch the webinar
Ready to talk?
Call our Security Team on 0800 640 8011, or email firstname.lastname@example.org, to find out how you can re-engineer the way you test.
See CST in Action - Click here