27 July 2010

When is a Vulnerability not a Vulnerability?

Until this week, I had thought this question would be answered by checking the vulnerability could be exploited and by determining whether there was any technical or business impact.

But I have just finished reading the Summer 2010 edition of Information Security Now, the quarterly magazine of the BCS Security Forum, incorporating the Information Security Specialist Group. One of the articles forced me to stop and think.

The article titled "Attack Spotting" describes the motivation for modern attackers and in particular attacks on application software. But the author introduces the idea of "non-vulnerability attacks". Just what might they be?

Non-vulnerability based threats aim to exploit weaknesses in server applications that cannot be defined as vulnerabilities.

I was even more confused. I thought a vulnerability was any weakness that could be exploited by a threat (and a similar definition). The article's author goes on to describe that in "traditional vulnerability-based attacks", there is always the possibility of creating a signature to block the attack or of developing a patch for the application. In "non-vulnerability-based attacks" the author says there is no malicious payload and therefore it is not possible to create an attack signature or patch. The author helpfully provides three examples of non-vulnerability attacks:

  • Brute force attack on authentication
  • Web application vulnerability scanning
  • Service flooding which exhaust server resources

No, no, no! These are all attacks against real vulnerabilities. These three are listed in Common Weakness Enumeration (CWE) (e.g. CWE-307, CWE-200 and CWE-410) and real examples are listed in Common Vulnerabilities and Exposures (CVE). The examples also fall into categories in the Web Application Security Consortium 's Threat Classification.

These attacks go unnoticed by existing protection technologies and can result in information theft, fraud activities and service disruption.

I have to disagree that these attack methods are new, and that they are not being detected. I may have misunderstood the article, but I believe there is plenty of guidance on building applications securely, security verification and for testing for these types of flaws. I also disagree with the article author's suggestion that the answer lies with expert systems to perform network behavioural analysis (NBA). Why bother? The application already knows right from wrong and doesn't need to guess. Implement application-based intrusion detection and prevention, on top of secure code, and benefit from very low false positives. At least, that's my view.

So, perhaps if it depends on your viewpoint. Maybe some traditional security folk see this other stuff as black magic? I hope not.

Posted on: 27 July 2010 at 09:29 hrs

Comments Comments (1) | Permalink | Send Send | Post to Twitter

Comments

Comments are filtered automatically and should appear shortly after they been checked.

Well said Colin. Our product is getting black magic accusations as well, but I would say that it is a parallel to your application-based ID/P with the advantage is that it can be used to protect vulnerabilties in apps already out there.

I think you might find it interesting.
1 Added by Rob Lewis Posted on 28 July 2010 at 01:33 hrs
Post a comment
Confirm acceptance and understanding of the terms of use
New posts to this thread will be sent to your email address
When is a Vulnerability not a Vulnerability?
http://www.clerkendweller.com/2010/7/27/When-is-a-Vulnerability-not-a-Vulnerability
ISO/IEC 18004:2006 QR code for http://clerkendweller.com

Page http://www.clerkendweller.com/2010/7/27/When-is-a-Vulnerability-not-a-Vulnerability
Requested by 38.107.179.222 on Tuesday, 7 February 2012 at 21:41 hrs (London date/time)

Please read our terms of use and obtain professional advice before undertaking any actions based on the opinions, suggestions and generic guidance presented here. Your organisation's situation will be unique and all practices and controls need to be assessed with consideration of your own business context.

Terms of use http://www.clerkendweller.com/page/terms
Privacy statement http://www.clerkendweller.com/page/privacy
© 2010-2012 clerkendweller.com