tag:blogger.com,1999:blog-4088979.post6241076846196970911..comments2023-10-16T06:06:25.012-04:00Comments on TaoSecurity Blog: Incident Severity RatingsRichard Bejtlichhttp://www.blogger.com/profile/13512184196416665417noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-4088979.post-33367697973175129792016-05-22T21:47:41.212-04:002016-05-22T21:47:41.212-04:00This is almost 10 years old, but I appreciate your...This is almost 10 years old, but I appreciate your interest. I've written a lot since then, some of which is more useful and/or applicable.Richard Bejtlichhttps://www.blogger.com/profile/13512184196416665417noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-79266983360874328412016-05-22T19:37:34.308-04:002016-05-22T19:37:34.308-04:00I think we spend far more time on "ratings/ra...I think we spend far more time on "ratings/rankings/scales/etc" than is necessary. We have to remember that the main objective of a security program is to enable our business, to keep them running, making money, providing a service or a product, etc. I think if we focus too much time on getting the perfect rating for a compromise we lose sight of that.<br /><br />That being said, I do believe it's important to have a way to objectively score an incident. I'm of the belief that less is more. Doing my own research I came across this IR plan used by a university. http://www.pcc.edu/about/policy/documents/Information-Security-Incident-Response-Plan.pdf<br /><br />I like their approach to rating an incident. I think it's simple and has potential to be effective.<br /><br />Greenthumbhttps://www.blogger.com/profile/04069528750090421681noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-44083514816945545302008-01-16T05:57:00.000-05:002008-01-16T05:57:00.000-05:00Reference: http://www.first.org/resources/guides/c...Reference: http://www.first.org/resources/guides/csirt_case_classification.htmlRichard Bejtlichhttps://www.blogger.com/profile/13512184196416665417noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-28656580519046288652007-12-21T10:54:00.000-05:002007-12-21T10:54:00.000-05:00Richard,You may want to look at the Mercalli Inten...Richard,<BR/>You may want to look at the Mercalli Intensity scale that's used to measure the impact of earthquakes. It ranges from 1-12 and I've found it to be highly accurate in assigning an impact statement or severity rating to an incident. It's much different than the richter scale for instance in that the mercalli scale recognizes that intensity and scope of damages can vary from site to site and impact has dependencies. I think you've got a fantastic start here. You could probably build what you have in to the scale pretty easily.<BR/><BR/>Hope that helps.hogflyhttps://www.blogger.com/profile/00741773109962883616noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-77230939260095883532007-12-17T16:21:00.000-05:002007-12-17T16:21:00.000-05:00Since PDCERF includes a "preparation" aspect, I mi...Since PDCERF includes a "preparation" aspect, I might also suggest something like "organizational handling/analysis preparedness level (for this incident type)":<BR/><BR/>1. Not prepared at all, no tools, training, or experience<BR/><BR/>2. Basic tools in place, but little/no training or experience<BR/><BR/>3. Experience or training in place, but little/no tools<BR/><BR/>4. Good experience/training in place and good tools in place<BR/><BR/>This is partially handled by some of the above items but it generally rolls up capabilities based on different incident types that creep up.Christopher Mallowhttps://www.blogger.com/profile/00939086973022955551noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-16556965422881536022007-12-15T20:57:00.000-05:002007-12-15T20:57:00.000-05:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-20080762511432717882007-12-13T12:48:00.000-05:002007-12-13T12:48:00.000-05:00Timely post as I've been bouncing ideas around the...Timely post as I've been bouncing ideas around the same subject. I braindumped how I'm approaching it over at http://electricfork.com/blog/37/defining-incidents<BR/><BR/>I based my system loosely on the Tornado Fujita Scale.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-54884057373386516182007-12-13T10:31:00.000-05:002007-12-13T10:31:00.000-05:00You've got a good base of factors for consideratio...You've got a good base of factors for consideration, but obviously the given categories are too complex. You've got a lot of _data_ here, but it hasn't really been channeled into information that can guide decisions.<BR/><BR/>Based on assessing these categories, I'd look at lumping things into a few buckets for management:<BR/><BR/>1) This issue will require disclosure, open us to legal proceedings, or will have financial impact in excess of N% of total corporate operational budget. This is the red bucket, the oh crap bucket, the severe bucket. The whole org will feel the impact of this one, and there will be permanent damage.<BR/><BR/>2) This issue will impact core business, will cause a noticeable issue in QoS, will cost in excess of N% departmental budget. This will hurt, but we can recover.<BR/><BR/>3) This is an issue that we can handle within the current operational budget. There may be localized issues with QoS, but this is the sort of stuff we are prepared to handle on a regular basis.<BR/><BR/>Looking back over these, organizational scope as far as where the effects will be felt seem to be the driving factor in categorizing the issue.<BR/><BR/>I'd note that management should be told what bucket things are in right now, AND how likely it is for things to escalate. This is where the skill and motivation of the attacker comes into play.<BR/><BR/>Borrowing your soapbox for a moment, any report should include information about the organization's ability to monitor further intrusion into the network.<BR/><BR/>KISS Principle!Brandon Franklinhttps://www.blogger.com/profile/09698372076913907365noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-14562518142127625742007-12-13T09:21:00.000-05:002007-12-13T09:21:00.000-05:00In the Threat section, would you want to account f...In the Threat section, would you want to account for both unmotivated and insider attackers? Unmotivated to me would be like a crime of opportunity; a computer was open, grab it. Likewise, an insider may not be particularly skilled, but might have a level of knowledge of the environment that would cause him to be more dangerous.<BR/><BR/>For Nature of the Data, would you want to know the value of the data or, if possible the classification the organization uses? A database server housing financial information may not be a grave issue, but could be valued higher than a database with help desk tickets. I can see tying this into Business Impact along with Nature of the Data, but could affect the severity of an intrusion.<BR/><BR/>Otherwise, that listing is pretty tight as is!Unknownhttps://www.blogger.com/profile/15357840241031190415noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-82231137529171714462007-12-13T08:08:00.000-05:002007-12-13T08:08:00.000-05:00Anonymous,You are definitely right about the money...Anonymous,<BR/><BR/>You are definitely right about the money part, but assigning any costs whatsoever would be a mighty WAG, so much so that I think it would be worthless.Richard Bejtlichhttps://www.blogger.com/profile/13512184196416665417noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-91193807819134393432007-12-13T05:30:00.000-05:002007-12-13T05:30:00.000-05:00nice, but its still just a scenario which has to b...nice, but its still just a scenario which has to be translated into actual costs for the enterprise.<BR/><BR/>unless we dont have a way to measure every point in terms of money, we still wont have a way to get through to them.<BR/>the people we are addressing understand work-hours and speak money.<BR/><BR/>so in my eyes the next step would have be to calculate the cost for every point...<BR/>how many work-hours are we talking about, when we take down components to check, investigate and change things if the problem is domain-wide, per machine, per account, concerns shell, api, application...<BR/><BR/>hell of a lot of work and once we actually come up with some numbers there would surely appear ppl who would gladly second guess them...<BR/>still, if one would be able to calculate these costs, it would illustrate his/her boss what the security breach is (would be) really about.<BR/>such numbers would also make life lots easier when it comes to expenses for new equipment or further training... there would be a way to show a cost-benefit improvement for the intention.<BR/><BR/>i think such a rating has to come with a cost-statement. otherwise it still would be too abstract.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-19379997186734882842007-12-12T22:10:00.000-05:002007-12-12T22:10:00.000-05:00In your last paragraph you point out 11 issues tha...In your last paragraph you point out 11 issues that would make up your worst case scenario. It can be argued that 7 or 8 of those points can be met by simply hacking an employees WinXP box with a standard malware attachment.<BR/><BR/>I really think people underestimate the risk/damage that can happen with the simplest of attacks today.Lance Spitznerhttps://www.blogger.com/profile/01302083186604441299noreply@blogger.com