THE Security Problem is Scale

Rich Mogull talks about real world IT security challenges today in his column, “Simple Isn’t Simple” in Dark Reading. I agree 100%. One of the Rich’s points is security has to scale or it doesn’t solve the real world problem. In most cases we know how to solve a security problem for a single instance of that problem; one SQL injection flaw in one app, for instance. The challenge is doing it at scale. If you can’t do it at scale you don’t solve the problem for the business.

Firewalls need to be on every ingress/egress point in the organization or they don’t solve the problem. Firewall technology has to scale to be manageable over every connection and work on every size pipe. Network vulnerability scanners have to scale to scan every system in the enterprise. Patch management solutions need to scale to manage every system with any OS. Likewise the only way to solve application security is to scale it to every release of every app.

At Veracode we don’t just focus on the accuracy of our application security solution. We also focus on our solution working well at large enterprise scale. Our mission is to make it possible for an organization, no matter how large, to perform security testing on all apps: every release, from every source (in house, outsourced, vendor, open source), and on every platform. We have customers that are statically scanning 1000 different applications this year. We have dynamically scanned 3000 web sites for one customer in 8 days. Scaling well is also not just the absolute number you can get to, but how quickly you can get there.

Scaling application security is a hard problem that requires automation and humans. Manual effort cannot be eliminated so it needs to be made as efficient as possible. This can be done by offloading the parts of testing that can be automated to automated solutions. Let humans find authorization issues and machines find SQL injection. If humans don’t scale well then application security experts scale less well. We should design solutions where tasks that need humans can be performed by more available resources. Let QA people crawl through business logic constraints and feed that crawl into automation rather than drive tools with application security experts. These are some of the approaches we are taking as we learn how to drive application security testing through huge application portfolios.

Veracode Security Solutions
Security Alternatives
Security Threat Guides

Andre Gironda | July 8, 2011 2:29 pm

“Scaling well is also not just the absolute number you can get to, but how quickly you can get there”

Security is more like a chess game where your strategy is often hinged on control of both time and space.

You address time-space strategies (calling them both “scalability”), but I don’t necessarily like how you address them.

If you really do scan 3k apps in 8 days, then how does your scanner benchmark against WIVET and WAVSEP? Are you getting modern levels of coverage? What is the output? How do you use that output for mapping and correction of weaknesses left to discover?

“Likewise the only way to solve application security is to scale it to every release of every app”

Then you must also scale it to every configuration change and state change. Why are you trying to solve insurmountable problems from behind-the-scenes? Get out of the Oz Closet and sing a few songs with the Cowardly Lion.

This involves being directly and always-on involved with the mock-attacking and the breach-handling of all capital assets: infrastructure, individual, social, and instructional. There is threat-modeling, there is penetration-testing, there is incident-preparation, there is incident-handling. There is technical intelligence and threat intelligence.

Can you pull out a static analysis tool when performing technical intelligence? Yes, you can. Do you stop when you’ve already run a web application security scanner with the knowledge of the static analysis and vice-versa? No, you don’t.

I’m sick of educating users and developers and so should you be. I’m sick of preventative care when we’re flooded with new patients coming into the ER for a variety of reasons that have no conclusive root-cause. It’s not just SQL injection. It’s not just social engineering.

You have to scale all security controls equally. Even firewalls, WAFs, app scanners, and static analysis tools are not going to get us to 2 out of 10 maturity. You need to jump into the game and witness the security controls first-hand from both perspectives: pen-tester and incident-handler. You need to learn the preventative measures available to those skill-sets: threat-modeling and incident-preparedness. Then you need to move each control involved up the bar based on a detailed, albeit qualitative, view of risk management: a holistic one based on a tactical engineer’s decision-making capabilities.

If you want to improve, hire/train more tactical engineers and improve your decision-making matrices and processes. Don’t do Enterprise risk management. Don’t grind through a list of apps or assets. Don’t try to standardize “everything” (but do standardize the things that pen-testers and incident-handlers find to need more standardization).

My version of scalability involves a “work smarter, not harder” approach. Of course, this means less money for the appsec and pen-test product/SaaS vendors. That’s probably why my ideas are not popular.

Arian | July 8, 2011 4:03 pm

“Let QA people crawl through business logic constraints and feed that crawl into automation rather than drive tools with application security experts.”

–> QA people are usually suboptimal at finding errors of omissions. They are decent at finding errors of commission which can include bugs with security implications (memory leaks and such, and verbose SQLi). But -

Business Logic and Design Flaw issues will never be found by handing over crawl-collection or multi-user traversal analysis to QA. Not without substantial training and entirely new process. You need qualified security engineers powering a DAST or SAST engine to find these FWIW.

Great job jumping on the Scaling Bandwagon though, we’re the only two that actually get it so far!

Andre Gironda | July 8, 2011 4:38 pm

“Great job jumping on the Scaling Bandwagon though, we’re the only two that actually get it so far!”

That’s an overly generous opinion if I ever saw one. Sounds similar to, “If Veracode or WhiteHat Security don’t sell it, then it’s not important!”.

Gotta love those vendors and how much into themselves they are!

I’m left wondering how easy it would be for Lares Consulting or Attack Research to completely own WhiteHat Security, Veracode, and Qualys — including customer information, private employee information, internal legal/financial information, intellectual property of any kind, etc. Would it be like taking candy from a baby, or perhaps email from an HBGary?

Maybe scalability isn’t such a great idea when you put it in these terms.

Chris Wysopal | July 8, 2011 5:04 pm

@Andre:

We are certainly not patting ourselves on the back. There is a lot of work to do. My goal was to point out what we see as a big security challenge, how we are trying to solve it, and what we are learning from working with our customers.

I appreciate your comments. As you know, nothing is 100% secure. We hire top boutiques to pen test us on a regular basis and we eat our own app sec dog food. We’ve had top 5 global banks and 3 letter agencies go over our security posture. Still, we must keep vigilant and working on our own security as we are trusted custodians of our customers data. We share this mission with our customers and take it very seriously.

-Chris

Amelia @ Ethical Hacking | July 9, 2011 8:45 am

As the creation of sound IT security encompasses a world of elements, I don’t quite agree that scaling security is everything there is to it in ensuring protection.

But I get your point, Christ. We need to pinpoint where we can maximize the tools and skills we have in comprehending and preparing for IT security setbacks and challenges that are sure to hit us.

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

RSS feed for comments on this post