Webinar: Why Cloud-Native Applications and APIs Are at Risk

Bionic Uncensored Ep #5

Structured vs Unstructured Risk

Let’s look at a day in the life as an Application Security professional or a DevOps Architect as an executive asks you about the security and risk of your applications.

Yes – that is technically one question, but with many more questions baked into it.

It reminds me of, again a movie quote from years ago, Back to School with Rodney Dangerfield.

At the end of the movie, he had to pass a test and one of the real jerk professors came up to him and said, I just have 1 question in 27 parts. That’s really what you’re dealing with when that executive comes to you and says hey, what is the security or risk in your applications? That’s a question with 27 or 2,700 parts.

Trying to understand the difference of one question versus all the different permutations iterations of risk or security or hacking methodologies is really complicated.

Two Types of Risks

There are really two types of risk: structured and unstructured.

The structured risk is really about everything you’ve probably been looking for for years. That goes into things like, OWASP, SANS, CWE, and all the different types of ranking systems that people are out there.

Traditional AppSec tooling and scanning technologies are really looking for structure-type vulnerability. Things like SQL injection, cross-site scripting, privacy violations, which all have to have a certain kind of recipe to really be a risk and a vulnerability that fit in a box.

Well, guess what?

Security risk does not fit in a box. A lot of times the vulnerabilities that are used to execute major breaches that you’re reading about in the press are directly around something that’s unique to your applications.

It’s how you develop your code without understanding.

Unstructured risk is when you’re really opening yourself up to the potential breach because it’s not something that all of these technologies are trying to find over and over and over again. It’s something that’s very unique.

Real Example

One example – and this is a real-world example that I’ve seen – is you have a developer who connects t0 some sort of service and a database, and that database has PII data associated with it. The developer makes a very small change to that application, let’s call it a microservice.

That changes from a developer’s lens is okay because they’ve changed one little thing. But now that opens up a new data flow and communication to that PII data.

This is something that would never be found by OWASP Top 10 or SANS or CWE because it’s specific to the architecture of your application.

Final Thoughts

When you’re thinking about risk, don’t think about your structured risk think about the unstructured risk within your applications because that’s the holy grail for a hacker.

See for yourself

Visualize every architecture drift, security risk, and compliance violation that each code change introduces, in real-time.