I agree, the way of thinking about these tools is faulty. I see this a lot in environments I've worked in, where the NIST 800-53 and DISA STIGs are the order o

I agree, the way of thinking about these tools is faulty. I see this a lot in environments I've worked in, where the NIST 800-53 and DISA STIGs are the order of the day. Nearly all admins and auditors both immeditally jump to the list of checks, and start going down the list. It can be manually, or with an assessment tool, but for every instance where the value in bit position "X" doesn't match what's in the book, it's a "finding, and must be changed". I think tools like these are useful, but they're almost always used in the wrong way. I tell my admins that these tools aren't to assess the risk to a system (which is far more complicated a measurement than a single checklist) but an awareness tool. The lists are to make you aware of services and entries you're exposing in the system. They're not inherently vulnerabilities if they're part of a well-conceived service who's proper operation and potential risks have been accounted for. When I read output from these, I think "Hey, this says I'm running HTTP without encryption. These are the potential implications of this decision. Is this the functionality I intended?" If so, document (if it isn't already) and move on. If it's not intended (oops, I wanted this to be HTTPS only!) then I know I have a configuration issue. I'm aggravated when I get some laundry list of "findings" and being told they need to be reduced to 0. Simply smashing the "remediate all" button is going to leave them with a broken system. It's a hard fight trying to explain that they were never intended for this.