Quoting Matthew F. Caldwell ([EMAIL PROTECTED]): > I think you will find that, out of those products 90% plus where > created by non-security professionals. And those created by security > companies, security analyst had very little input into the creation of > how things should be done. And about 2% do what they say they can do.
I think the most important question here is: What is a _Risk_. Sure, Incidents are easily defined, Vulnerabilities, too, sometimes expert systems even analyze Policies and Standards based on a probability database, but Risk is much more than that. I aggree with you. Would I want to travel the Amazon Rainforest, I'd certainly not hire the someone who wrote the book on "Growth of Trees in the Amazon Region" but someone who's been there for a while and seen the dangers of this particular area with his own eyes. Professionalism, multiple years of experience and "been there, done that" are definitely the most important factors when Risk is to be analyzed, qualified and quantified. But this is where my questions start. Maybe we're discussing two different things here, but while I can see how a tool would assess vulnerabilities (Nessus, etc.) and incidents (snort et al), I fail to understand how Risk is being assessed. Risk is a predictive term, it's bound to psychological factors, technical incertainities (such as routing loops, IP-address similarities between the assessed site and a more likely target, joe-job likelyhood, etc.), policies and their inforcement, etc. As I wrote in my email to you, I am certain you guys have a great product. I just don't see how "Risk" can be assessed automatically or even with the help of automated tools. Sure, technical aid is needed, I personally like to use netcat, lynx (for bugtraq-queries, etc.), telnet and a set of python scripts, but so far I have not found this magical "one size fits all" software that would assess Risk for me. As a good example let me tell the story of this week: There's this company that just recently conducted a "Risk" assessment via a third party. Said third party used several scanners to scan for vulnerabilities and installed a sniffer at the central Catalyst SPANning the whole internal network and DMZ. One of the findings was "Your telnet port is open, this is a HIGH RISK". The finding referred to the Cisco 75xx router in front of the network. Now, is this a) A Risk? Not necessarily. What the tool failed to assess was the question if anybody ever used this telnet port. And if there were rate limits in place to prevent someone from connecting a couple of thousand times to this port exploiting a remote DoS vulnerability in this special IOS version. Unless someone was stupid enough to log in to the route via Telnet (there's a console attached to it, too, sporting SSH login capabilities) and NOT to use the SecureID setup, I don't see a big Risk here. b) A vulnerability? Not necessarily. If SecureID can be positively proven predictable (I saw a few reference implementations which failed for these 4-digit-keypunch versions), this looks different, sure, same if someone finds a buffer-overflow or something else in Cisco's IOS telnet implementation, but in general ... well. c) An incident? Was the port open for everyone before? Are there access-lists in place to prevent this kind of connection, usually? BUT, and here it comes, there IS a high risk associated with this router. A risk, no tool in the world could assess - the router was running a flawed version of IOS which allowed for the arbitrary injection of falsified BGP statements. An attacker with the right tolls could easily falsify some routes, pose as zonelabs.com, wait until some of the internal users download a supsected "upgrade" to their Personal Firewall Software and - boingo - roam the internal network. In the world of vulnerability scanning, the process of obtaining version information on open ports and matching them against a list of patterns, tools have their place. Risk assessments, however, go so much deeper into a predictive and psychological area that tools can not even begin to compliment the work that needs to be done there. Risk Analysis, at least for me, is the process of correlating human- and technical data with predictive statements, a good portion of psychological evaluations, business requirements, "best practice" analysis, and a lot of knowledge about the inner workings of the infrastructure in question. I guess, what i boils down to is: You're right. In the hands of a skilled Risk Analyst a good tool can do a lot of good things. But that's only if the same analyst could have obtained the same results with the help of netcat, tcpdump and perl. A tool cannot replace expertise and it can only so much compliment existant expertise. If you found out how to increase the aid a tool can offer, cool. If it's not too intrusive, I am sure some of us would like to learn about it and how we could use it, in technical terms not the marketing way :) jonas
