Now that our Application Security Trends Report Q1 2007 is out the door I want to discuss some of the major challenges we faced in putting it together and also give our audience a sense of our vision for the future of the report. Our goals for the quarterly trends report were three-fold, and some of the these goals we were able to achieve better than others: to discuss major events that affected application security during Q1 time-frame, to compile relevant and accurate statistics for the period, and to give a sense of attack patterns and events in the so-called underground. These were lofty goals to begin with, but we did our best. That being said, our first Trends Report was still our first report, and we didn't get to do everything we wanted to do. Below are a some of the areas that we hope to improve upon in the future.
1. Level of Abstraction: Its a challenge to strike a balance between an appropriate high-level overview of the vulnerability data verses a very low-level and comprehensive categorization. The more detailed your categorization system the more risk you run of confusing your audience or producing a final work that's more convoluted than informative.The OWASP Top 10, for example has 10 categories for web application vulnerability types, whereas WASC has 6 top level threat classes with 24 subcategories. Future versions of our report will utilize a list of Web Application Risks that we think strikes the best balance between detail and breadth. In other words, we were not entirely satisfied with either of the major web application vulnerability taxonomies, so we're going to come up with our own.
2. Definition of a Web Application verses Web-enabled technology. As the web becomes more diversified and dynamic in the types of applications that interact to deliver its functionality and content, web application vulnerabilities will become more diversified. This time around we used a working definition of a web application: those server-side technologies that provide for infrastructure and functionality for delivering web content to the user, plus the web browser. While I won't go into our motivation for including browser vulnerabilities in the report, its clear that when one begins to categorize things this way you have departed from a strict definition of a web-application as a pure server-side technology that you assess or scan from a black-box perspective when doing an assessment. This can cause some confusion since its a departure from the ordinary way we think of web applications.
We're ok with this departure because it makes sense, but it also doesn't go far enough or do justice to very large amounts of vulnerability data relevant to web application security. In future reports you can expect us to broaden our definition of a web application even further, which will lengthen the report, but also pull in additional security information that is important for web users. This doesn't mean that we will treat traditional web application vulnerabilities with any less importance, it means that the definition of a traditional web application is showing signs of stress, and a broader definition will be a better overall fit for the vulnerability data. To keep things clear we will create categories for types of web application vulnerabilities that exist in non server-side technologies, and detail this broader picture as vulnerabilities disclosed in web-enabled technologies. Web Applications and Web-enabled technologies will be covered in separate sections to avoid confusion. Here are a few examples:
*A cross-site scripting vulnerability in Poodle-cart 1.0 would be categorized as a web application vulnerability.
*A cross-site scripting vulnerability in Adobe Acrobat Reader would be categorized and counted under the web-enabled technology section. (This time around we did not include or count any of these types of web-enabled technology vulnerabilities).
*A web-exploitable vulnerability in Quicktime would be categorized under the web-enabled technology section.
*A Web-exploitable vulnerability in the Super-Slurp Desktop Buddy ToolBar would be categorized under the web-enabled technology section.
*Vulnerabilities in web browsers will be categorized under the web-enabled technology section.
*Web-exploitable vulnerabilities in ActiveX controls for web applications will be categorized under the web-enabled technology section.
*Vulnerabilities in web servers, web application servers, etc., will be included among web application vulnerabilities, as a subcategory (i.e. the web application pie chart will have two slices).
By covering both traditional web application vulnerabilities as well as web-enabled technology vulnerabilities we can avoid leaving out information that will help to inform and protect our readers, while at the same time keeping a clear distinction between traditional server-side applications and client-side technologies with web-based vulnerabilities.
Why do things this way? Why all the craziness? Well, (to quell the conspiratorial types) we're not trying to pad the report for length so that we can win the my Trends Report is bigger than your Trends Report contest. We're not trying to out-Symantec Symantec. Rather, its our viewpoint that all technologies which use HTTP, and have HTTP exploitable vulnerabilities, should get coverage in our Application Security Trends Report. We want to provide this coverage while still keeping traditional web application vulnerabilities front and center.
-Tom
Lorsque je démarre ma carrière en media.we sociaux sont une aide complète à savoir sur le information.As de mon Del.icio.us connaissance est le meilleur livre de la marque sociale.
Posted by: chaussures timberland loisure | November 16, 2011 at 07:04 PM