I look to the MITRE CWE to determine what’s wrong with software. If a pen-tester wants to update that list with new techniques or weaknesses, then I’m ok with that. Keep it in the lab.

@ windexh8er:
Layered defenses are only good up until the point where they become redundant. I hate to get in another separate argument about routers vs. firewalls, but I am a firm believer that routers can do more with receive-only ACLs and null routes to help security than any firewall ever could.

Monitoring is great. Intrusion detection is great. I would just rather see these things baked into an application than layered into the network or on top, or through a hypervisor introspection layer. Agility in app development is much more easier to execute than in operations, even with standardized products and straightforward instructional resources. While this is not true in all organizations today, it can be true with the correct organizational change and organizational development.

I already knew that “Certainly not Microsoft, and even today their SDL appears to be failing by some, but imagine if it did not exist at all” was my weakest argument, and would probably be a source of controversy in any comment thread. I build a lot of strawman arguments up to see how people will knock them down. There are a few problems with your reasoning. An operator can surely do many things to temporarily prevent adversaries, even with automation — and some are more obvious to the adversary than others. I prefer subtlety.

Almost every organization is facing intelligent, organized, unstoppable, dedicated adversaries. Blocking their IP is akin to telling them that you know that they are there, but that you have no idea how to stop them. It just steps up the game. It’s best to simply let them get away with cracking a few passwords or trying a few SQL statements, while at the same time tracking them down, striking back at their applications and infrastructure (two can play at the SQLi game… they probably have their own database of sorts… and if they want passwords or customer data, just feed their database a list from http://fakenamegenerator.com – who knew that their attacker tools worked so well!), and then working with a take-down service or law enforcement (or military in some cases) to remove the adversaries’ capability to attack permanently. It’s called “Intelligence” and “War Strategy” for a reason. Know your enemy.

It doesn’t even have to be that obvious even. You could simply gather a list of successfully cracked accounts and then flag those accounts to require an extra step when logging in. Something that the real user would know that the new-owner of a user/pass pair would not. However, “lock-down” capabilities must usually be written into the application. I consider this a good thing.

“I guess I don’t see how moving everything to an API in VM and “eliminating the physical network layer” buys you anything but a flawed trust model… I think it is a component of an overarching process when designing new architectures, but I don’t think it’s an end-all-be-all solution as portrayed”.

I’m actually going to have to agree with you on this point. I’m just trying to explain where the industry is headed. Also see: cloud security: the biggest oxymoron the technology industry has ever heard. If security is the removal of all assets from all threats, and cloud computing brings all assets to all threats, then we’re talking about a major problem we’re going to have to address. Maybe application security can help?

I agree that OWASP Scrubbr is one of the best projects out there today for getting to the temporary source of attackers’ new agenda: to take over the web application layer. Certainly we can do even better than this. SpyBye and Scrubbr technology should be merged and automated.. this would make for an interesting project.

You said, “In the end this article reads like there’s a holy grail that has yet to be found. When really it’s just a smart culmination of current and future technologies”. I don’t know about a holy grail, but I like DAST+SAST+Expert-Review. I like the concept of a Secure Software Group that creates a self-service Application Assessment Factory, which indexes findings based on real risk analysis such as OCTAVE, NSA IAM, OSSTMM 3.0, Certified Secure Web, NIST SP 800-30/39 and FAIR.

You also said, “VMsafe API: just another same solution to a newer technology, nothing new”. Again, agreed, and I explicitly stated that XenAcess has had this for quite some time.

As a final point, you stated, “ME proving that MY applications are secure? It’s impossible”. It is not impossible. Pete Herzog clearly defines “Perfect security” is attainable, and he attempts to prove this scientifically through his work with his fellows at ISECOM. Perfect security is “just enough security”. The Microsoft SDL is probably 4SIGMA to getting to 6SIGMA, and while the SDL Pro Network and the SDL-IT are in 2SIGMA, they will also quickly gain highly quality and operational excellence in process and by design.

If you read the Microsoft SDL approach to the SANS/CWE Top 25 programming errors of all time, you will see a very well thought-out execution of “perfect security” where the application security program attempts to stay one or two steps ahead of any adversary. When you put the SDL up against people like Charlie Miller, Jacob Honoroff, Sean Fay, and Geoff Morrison and/or Mark Daniel, Shane Macaulay, Derek Callaway, and Alexander Sotirov, you actually have what looks to be a fairly solid foundation of prevention.

Application security is like Hallmark: when you care enough to prevent the very best.

The clincher for me is the hypocrisy stated here: “Certainly not Microsoft, and even today their SDL appears to be failing by some, but imagine if it did not exist at all.” Read it again: “…imagine if it did not exist at all”. Sure, a firewall at a perimeter may not be able to address a SQL injection attack. But, like you said all you need to do is monitor, so XYZ WAF sees it coming across the wire (not inline, but off of one of your taps), and tells said SIEM solution of which tells the firewall to drop the state and block that IP until it’s reapproved by a knowledgeable admin. Sure, the attacker can source elsewhere, but it may be just frustrating enough and slow them down that much, or pushes them to try a different approach / path that leads them to expose him/herself.

I guess I don’t see how moving everything to an API in VM and “eliminating the physical network layer” buys you anything but a flawed trust model… I think it is a component of an overarching process when designing new architectures, but I don’t think it’s an end-all-be-all solution as portrayed.

“OWASP Scrubbr is not going to save us all by itself.” — no, but it helps. In the end this article reads like there’s a holy grail that has yet to be found. When really it’s just a smart culmination of current and future technologies. VMsafe API: just another same solution to a newer technology, nothing new.

ME proving that MY applications are secure? It’s impossible (the wording of it). Unless you have and understand every piece of information that everyone else knows there’s no way to qualify that. The first person to do this will abolish any need for any additional security because if one could actually prove that then the “proven one” wouldn’t need any external security measures.

We don’t live in a vacuum. We can’t predict the future. And it’s all f’in software. The flaw is in and of itself.