Introduction

Here at Comsec we spend a lot of our time working on Application Security projects as well as monitoring emerging trends in the industry.

Personally, I keep a close eye on ongoing events and the knowledge being shared at Industry conferences. In particular, I was lucky enough to be at the OWASP AppSecUSA Conference in San Jose, CA, this past October. Some of the most prominent people and companies in the Application Security industry were exhibiting and speaking there and this provided an excellent opportunity to see the state of the industry and the direction in which the leaders in the industry are going.

In this post, I want to give a quick overview of five key trends in the field of Application Security which I have identified. Anyone in the Software Development, DevSecOps and general Application Security industries should be keeping a close eye on these areas.

0: Traditional Application Security Testing

I have included this as item “0” not to make a zero-based array joke but rather because it isn’t a key trend or a new trend. On the other hand, it isn’t going away. A lot of the enquiries and requests we receive are for this style of hands-on security testing of the application once it is nearly finished. I spoke to various other security consultancies at AppSecUSA and they see a similar picture.

My talk at that conference was probably one of the only ones which discussed such a “legacy” topic. However, the underlying goal of my talk was to encourage people to think more widely than just about security testing. My hope is that it will lead to considering security earlier on in the process.

When we are asked to do a test like this, we usually try to include an initial design review stage. During this stage, we interview the developers/architects to understand what is going on behind the scenes. Invariably we come up with a lot of suggestions for areas they need to improve which we would have just not seen from a grey or black box test but which could also easily result in a significant security compromise. Again, this helps demonstrate the value of considering security at the requirements/design stage.

Like I said, this isn’t going away but it may start appearing in a different form soon as we will see later in the article.

1: “Pushing Left” and “Building Security In”

This is of course not a new trend but it is certainly gathering pace and momentum. More and more organisations are recognising the need to ensure that security is included in the Software Development Lifecycle. Security should be considered from initiation through to deployment and onwards through maintenance as well.

Once, Application Security was synonymous with doing traditional Application Security Testing (as I mentioned above) or running some sort of vulnerability scanner. However, now many organisations have now begun integrating security processes such as threat modelling, design review and security unit testing into the development process. This means they see value earlier on and avoid having to fix security issues late on in the process.

Similarly, the developers of application vulnerability scanners are all heavily focused on allowing organisations to integrate their tools into their automated build and deployment pipelines. See, for example, the release of Burp Suite Enterprise a few months back as part of their 2.0 release.

We would certainly urge all organisations to start thinking about how they can start integrating security earlier on, albeit in an incremental way.

In particular, we would expect that dependency security checking will start to become the norm. We have already seen multiple attacks on the dependency “supply chain” where malicious code is smuggled into libraries used by many projects.

2: Application Monitoring, Alerting and Response

Network level security monitoring, detection and response has been long considered an important and key control. However, application level security monitoring has had a far lower rate of take up. Web Application Firewalls (WAF) can be used to assist with this but the WAF generally sits outside of the application. As such, whilst a WAF may be able to address generic attacks or recognise standard attack patterns, it won’t necessarily have the application specific knowledge to be able to recognise attacks on vulnerabilities in the logic of the application.

At the same time, as the size of applications bases grows, it gets harder to protect the application from these types of vulnerabilities and detection gets more important.

I have written previously about how detection can mitigate the exploitation of security vulnerabilities. We are starting to see more progress in monitoring and response solutions that sit alongside or within the application and have some insight into how the application works. We would also expect to start seeing this built into new products.

3: The rise of “Serverless”

The concept of “Serverless” whereby an application only exists as programming code in a cloud environment or where backend services are entirely provided by a 3rd party has been on the rise for a few years. We are seeing it implemented in new applications using “Backend as a Service” such as Google Firebase or “Functions as a Service” such as AWS Lambda.

As with every new technology, it brings some old and some new security concerns which companies have to be aware of. Larger organisations should be particularly concerned with the ease with which it is possible to start using these services. Often, they can be used in a way which is not obvious to the IT and security departments. Even if these departments have just started to get to grips with their R&D departments working in the major public cloud providers, they are now faced with multiple backend providers who may now be storing the company’s data.

The flexibility which these concepts provide allows developers to abstract away a lot of the complexity of backend infrastructure. As such, we would certainly expect to see this becoming widespread in the near future.

4: Bug Bounty platforms move to offering Penetration Testing

The major bug bounty platforms have invested significant time and energy into building a pool of highly talented, manual applications security testers. This pool comes with rankings, examples of past findings, publicity, etc, and has acted as a way to highlight some of the most sophisticated security testers in the world. It now appears that they will be leveraging this pool to enter the crowded “pay for effort ” Penetration Testing market rather than just offering a “pay for results” alternative as they did previously. The interviews which Bugcrowd did with the Risky Business podcast in episodes 524 and 531 are a “must listen” for any application security testing provider.

For organisations requesting testing, it has always been a challenge to decide who to engage and how to assess their work. The Bug Bounty platforms come boasting a known methodology, a quality guarantee and most importantly, a set of known testers with verifiable skills and achievements. If you are an application security tester who has not previously spent time building up a rating on a bug bounty platform, it seems possible that in the future you will be seen as less capable than testers who have.

For testers who don’t have the time or inclination to do build up that status in their spare time, now would seem like a good time to start skilling up in the “push left” or “application monitoring” areas highlighted above. This “pay for effort ” bug bounty approach looks like it could be the future of “traditional” Application Security Testing.

In the short term, organisations will have to assess the maturity of this approach and the suitability to their business and budget.

5: The Need for Product Security experts

The rise of Serverless and “cloud native” leads to applications which no longer comply to the old “web server”, “application server”, “database server” architecture. Rather, applications are built from a number of separate services, some of which will be entirely managed and hosted by 3rd parties.

As such, whereas there may once have been an infrastructure security team and an application security team, those roles will effectively merge together. Going forward it will become impossible to manage and secure these applications without understanding both how to develop secure code and how to deploy and operate securely in a cloud-native environment.

Similarly, there has been a shift to deploying applications using code and configuration files to control the process. This together with the need to automate deployment and ongoing maintenance and monitoring processes by writing code to work with a diverse set of APIs from different services also contributes to this merging of roles.

Here at Comsec we have strong infrastructure and application security teams. As more companies move to a “cloud native” model which needs the combined knowledge-set described above, we are frequently delivering projects which involve a combination of effort from both teams in a highly coordinated way. As such, we are able to deliver a combined “product security” approach which considers all aspects of deploying and maintaining a software product.

Organisations should ensure that they are covering the full Product Security spectrum required for cloud applications rather than just aspects of it. Attackers are already finding ways to exploit the combination of applications and cloud infrastructure.

Conclusion

These are certainly not the only topics which are going to be important in the upcoming year but you are unlikely to get through the year without encountering them.

If you are interested in hearing more of our thoughts on these topics or discussing how we can help you address your challenges in these areas or any area of Product Security, feel free to get in touch with us.

Josh Grossman

Thanks to Mikael Levy for reviewing and providing feedback on this post.