AppSec Predictions for 2020
A Customary Blogpost
I am going to NOT encompass "InfoSec Predictions" in this because "InfoSec" is a HUGE area and I am not nearly qualified enough to be making predictions without coming off like a jackass.
That said, with AppSec, I have had the privilege of:
- running a company with an active AppSec Pentesting practice, which is a major source of these predictions. My guesstimate is that we have tested north of 200 apps (web, mobile, etc) this year, not counting repeat engagements.
- Aside from pentesting, we have also morphed into implementing DevSecOps practices for our clients. This means - Automation, Security Regressions and more
- I have trained over 500 people this year (2019) alone. These are people from different backgrounds, industries and from companies with different AppSec Challenges. A lot of predictions have come from interactions with these fine people, either in class, or outside it
- Spoken at some major events (focused on AppSec) and interacted with very engaged audiences at these events.
So here goes. My AppSec Predictions for 2020:
Rise of Event-driven Architectures
When I say "event-driven", I essentially mean "serverless"
This means, a marked increase in Functions-as-a-Service (FaaS) deployments. Why? I think its a no-brainer, because of:
- Maintenance overhead in the long-run
- Better tooling => Deployment and Observability tooling has gotten a lot better in 2019
- Better Event Support and API => AWS has definitely led the way here, in making FaaS a very compelling architecture for people to consider
- Rise of the clones => Everyone from MongoDB to Atlassian is offering a serverless platforms for development. Azure with its Container Instances and Google Cloud with its Cloud Run (aside from their existing FaaS offerings)
- Reduced Friction => AWS with its Firecracker and reduced cold-starts (RE:Invent 2019) has made it a much more attractive proposition
This is going to fundamentally shift the AppSec narrative from a "on-prem" view i.e. managing servers, databases, middleware, etc to a cloud-native view, where these components (and their risks) disappear, and make way for different problems.
I'd say most AppSec Professionals are NOT YET EQUIPPED to handle the risks coming from this cloud-native view of the world.
Kubernetes - Up and down
Its no secret that Kubernetes has been adopted by several companies as a way of managing deployments and scaling container-driven architectures, sometimes with little or no understanding of its complexity.
Kubernetes is great for:
- Scaling apps with Containers
- Deploying microservices
- Managing complex network architectures with service meshes and proxies.
Kubernetes, however is a major Pain in the ass for the following reasons:
- A gazillion configuration parameters and options
- Managing complex network architectures with service meshes and proxies. Yes. Really
- Massive management overhead, that only a few companies can afford (by way of talent and being able to pay and retain them)
I suspect that some organizations are going to attempt Kubernetes adoption, fail (in about 3 years) and move to something else.
Nevertheless, its important to learn how to secure Kubernetes. And there are LOTS of configuration options and operational complexities with securing Kubernetes.
Moar DevSecOps! (AppSec Automation)
One of the cool things about 2019 is that we (as a company) saw is that nearly all our clients are buying into the need for automation as part of their SDL. This means:
- More automation embedded in the SDL, reducing the burden on security assessments pre-release.
- More Security Regressions. We converted complex pentest findings to automated regression tests instead of definitely-ignored PDF reports
- More engagement with Dev and Security. Engineering and Security teams are definitely working together more than they were before. Our efforts are working! 😀
- The need for Vulnerability Management and Correlation, and especially for Orchestron has seen a major uptick
However, there are still significant challenges in this space, including:
- Bad tools - Lots of tools for AppSec still suck at CI/CD and even automation. I am referring mostly to commercial vendors. SAST vendors - I am looking at you. Even tools like BurpSuite, which are awesome have a long way to go, to making things easy for Continuous Automation Use-cases
- Getting Security Teams working with QA Teams - This is a HUGE missed opportunity. Security Teams working with QA Teams means:
- Better E2E tests and simulations that are essential for DAST, IAST and even RASP
- Better Security Regressions to test/validate complex business-logic flaws, authorization flaws
Threat Modeling (and good sense) on the rise
Orgs and teams have started to realize that the true meaning of "shift-left" is to make a conscious change to shift all the way left. If you can identify flaws and possible security issues at requirements and design (especially in your sprint planning), then you can reduce several security vulnerabilities even making it to subsequent stages of the SDL
Threat Modeling is an essential practice when you want to scale AppSec. Orgs and teams today are starting to realize this. They see the rapid-release cycles, iterative development and security bottlenecks as a major case for pre-empting security gotchas, i.e. Threat Modeling
The next stage of Threat Modeling is to evolve to make things easier for Engineering Teams, NOT Security Teams.
Companies like IriusRisk are already doing this. In the OSS world, our project ThreatPlaybook and PyTM are also moving towards this goalpost.
The key I believe, is to not only generate Threat Models, but use them to shape your AppSec program and SDL
Rise and Decoupling of Code with "As-Code"
I am happy to see that complex architectural concepts like Authorization (AuthZ) and Authentication (AuthN) are being decoupled from core application business logic through efforts like OAuth, OIDC (been around for a while) to Policy-as-Code Enforcement frameworks like Open-Policy-Agent, SPIFFE/SPIRE, Envoy and Istio. Security being a front-running goal for these projects is a major improvement in terms of adoption and flexibility.
Now, if only Security folks understood and adopted these security frameworks, that would be great!
Conclusions and Advice to AppSec Pros
For AppSec Pros or people looking at a career in AppSec, my advice is this:
- Learn to code. In something. For all the reasons below. You dont need to be a Software Engineer, but you need to know how to write and read code.
- Start adopting and running with a cloud-native view of the world. This means, understanding Cloud API, Attack Patterns and Cloud-native services. This will serve you well in the long-run
- Automation is your friend. Most AppSec Teams are understaffed (in comparison to engineering teams and QA teams). Automation is only going to make your job and life easier. Adopt and grow with it.