tag:blogger.com,1999:blog-13756280.post2426669074928878035..comments2024-02-08T03:44:23.780-08:00Comments on Jeremiah Grossman: Summary: SANS WhatWorks in Web Application Security Summit 2008Jeremiah Grossmanhttp://www.blogger.com/profile/05017778127841311186noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-13756280.post-45542807796885921562008-06-06T10:50:00.000-07:002008-06-06T10:50:00.000-07:00@anonymous, that last point was really interesting...@anonymous, that last point was really interesting. You make it into their personal best interest to get better. Hmph, clever. Might be another reason to have more web security programming certifications as well. Lets not debate over their "true" value shall we. :)Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-56179206014055949162008-06-06T08:33:00.000-07:002008-06-06T08:33:00.000-07:00Wish I could have been there.In talking about web ...Wish I could have been there.<BR/><BR/>In talking about web app vulns to management I usually make the company "reputation" and "loss of customer confidence" argument, since defacement, phishing, malware download are the most likely real world attacks. Putting in links to blogposts, news articles helps too.<BR/>About getting developers to develop securely, I always am sensitive to the fact that, as a former developer and dev manager, developers HATE being told how to write code. The way to get them to do write secure code is to make them want to write secure code. So, I appeal to ego and wallet: a coder who codes securely is a better coder than one who does not code securely. And, "If you can put on your resume that you can code securely, you will beat out the guy who cannot put that on his resume." I think being able to say, "I've haven't had one of my sites hacked in x years" is a strong case for getting hired.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-5863947453954240102008-06-05T14:22:00.000-07:002008-06-05T14:22:00.000-07:00Yes, I'm sorry. I understood that portion perfectl...Yes, I'm sorry. I understood that portion perfectly, but was thrown off by the line, "even well established severity/threat ratings are not yet been developed", which made me believe there were some factors that were even more issue-specific. I suppose I misinterpreted that segment of the reply. Oh well in any event thank you for clarifying.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-64610613110499156652008-06-05T09:48:00.000-07:002008-06-05T09:48:00.000-07:00New ideas and ways to look at things are incredibl...New ideas and ways to look at things are incredible valuable, despite whatever experience someone might have. So let me throw out some things that need to be measured and taken into consideration trying to answer management’s question of "how are we doing?" And yes, each report and weight would need to be tailored to each business. Here are several things we can take into consideration:<BR/><BR/>Vulnerability Severity: If exploited how bad would it be. <BR/><BR/>Vulnerability Threat: Ease or difficulty of the vulnerability being exploited.<BR/><BR/>Likelihood: What's the probability of the vulnerability being exploited. The difference between what’s possible and probable.<BR/><BR/>Cost of mitigation/remediation: Before being exploited, how much time and money would be needed to reduce the risk by X% using X method.<BR/><BR/>Website Importance: How valuable is the website and how much of what could be lost? Brand, intellectual property, money, etc.<BR/><BR/>Recovery Cost: If exploited, how much time and money would need to be spent to recover.<BR/><BR/>Security Comparison: Describing to the business how they are doing relative to other in their market vertical or global average. <BR/><BR/>This what you were asking for?Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-55619858929855485302008-06-05T09:31:00.000-07:002008-06-05T09:31:00.000-07:00Obviously you have a lot more years and experience...Obviously you have a lot more years and experience than I have in this field, but I have given it some thought, and wouldn't it be somewhat difficult to establish such ratings on a general scale? I mean I am not too familiar with all of the possible open-source, or proprietary applications used by various corporations' developers to put together their websites, but wouldn't each assessment (risk-related) have to be tailored to each individual company rather than a de facto standard?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-54292738308036758622008-06-05T07:29:00.000-07:002008-06-05T07:29:00.000-07:00In webappsec, not typically. Website vuln reports ...In webappsec, not typically. Website vuln reports might get folded into some larger risk report, but its rare in my experience. Rare because no one knows exactly how to measure web app vulns from a loss/risk/value perspective. Even well established severity/threat ratings are not yet been developed. Corp auditors don't know what to ask for either, as no standards have been developed. Another reason is companies with anything over 5-10 websites, no one has a good idea of what they are, what they do, or how valuable they are to the business. <BR/><BR/>Obviously its still a very mature space, but people are not starting to ask for these types of things or how to go about building them.Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-35937862222251202792008-06-05T07:16:00.000-07:002008-06-05T07:16:00.000-07:00Jeremiah, on the issue with the first point you ha...Jeremiah, on the issue with the first point you have made isn't it already the responsibility of the Information Technology, or Security, staff to put together such a report anyway? I thought it was an actual and annual duty to perform such risk management exercises, and then present the findings to the "superiors" in the company via a well put together document, or series of documents, in which both likelihood and valutions were given weighted values. Does this not generally apply to Web Application Security, or at least not at the present time?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-89541123689210169112008-06-04T22:13:00.000-07:002008-06-04T22:13:00.000-07:00I'm going to do something completely out of charac...I'm going to do something completely out of character and agree with everything you wrote in points 1-4 and 6. These are really great take-aways.<BR/><BR/>With particular regards to point 5 (which I disagree with), it looks like you need some work. I think Rich was saying that you need to do better! I'm going to have to disagree with Imperva, and in particular: your statistics on how long it takes to fix vulnerabilities. I think we need more data from different sources before any of this becomes conclusive, let alone theoretical.<BR/><BR/>Since I have my head in your number 6 everyday, did anyone say anything about what does work? Sure, Microsoft SDL: good for fat apps, bad for web apps. Agile: good for web apps, but it's too fast for security. What does work for secure SDLC improvements in web applications? Did anyone have any suggestions?<BR/><BR/>RSnake and Rich Mogull's conversation would have been my favorite part of the summit. Luckily, I got to meet with Rich tonight to discuss things further. The concepts are dead right -- we need to speed things up and make them more secure (slow them down?). Can we do it? I think that we can. That's what my CPSL process and recent Software Security retrospective blog post are all about.drehttps://www.blogger.com/profile/17414510788948258195noreply@blogger.com