|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: CONTENT DECISION: Presence of Services or Applications (SA)
"Prosser, Mike" wrote: > Dave, > I am not saying don't check for a service running, we do. I believe > Aleph One says it best when he said it is a risk vice an actual > vulnerability. A client may not even realize they are running a > particular "risky" service, or they may be fully aware of it and need > it for their business. All a scanner does by checking for the service > is alert the user to the fact the service is running. Speaking for > myself, not for other vendors, having a "risky" service running or > not is a decision that the client has to make based on their needs. > We try to provide them with all the options to make that decision. > All part of risk management. A hypothetical. Let's say that I am one of your customers. Let's say my policy states that finger should not be running on any of my boundary machines. Let's say your scanner determines that finger is, in fact, running on one of my boundary machines. Question: Has your scanner just identified a vulnerability on my system? Note, if you say no, it is not a vulnerability on the grounds that finger is not flawed on its own, then you admit that vulnerabilities can be understood independant of policy. That is, you do not need to consider what my policy is to make the determination of whether finger is a vulnerability or not. On the other hand, if you say yes according to *my* restrictive policy it is a vulnerability, then you make the case for the more inclusive notion of vulnerability -- since the more inclusive notion of vulnerability will allow us to describe things that are vulnerabilities on some systems but not others depending on the respective policies. Dave ========================================================= David Mann || phone: (781) 271 - 2252 INFOSEC Engineer/Scientist, Sr || Enterprise Security Solutions || fax: (781) 271 - 3957 The MITRE Corporation || Bedford, Mass 01730 || e-mail: damann@mitre.org
|
||||