Blindly following the auditor

I recently had a customer call me who had gone through a PCI audit. One of the things found in the audit was that the management console of their data center environmental monitoring station had SSL V2 enabled. Bells began to ring, security alarms sounded, and the war horns trumpeted. Why? Well, because SSL V2 is flawed in a number of ways. It is pretty much disabled by default in any modern browser. In short, it is bad. So it is understandable that this would cause something to pop up on the audit report.

So the client called me saying that the remediation plan said SSL V2 needed to be disabled. I really didn't know much about the box, but in the spirit of trying to be helpful I asked some questions to see if I could figure out what they needed. I decided to start on the technical side (which was the wrong path) by asking what the box used for an OS. Is it a stripped Linux kernel using Apache? Is it Windows using IIS? Is it proprietary? She had inherited this box in just the last few days, so the answer was an understandable "I don't know". After a couple more paths led to no answers, I could see this was going to be fun.

So then I decided to start down a different path. I asked if this box was even accessed from outside their network. When she said that it was only accessed from within their network and that they just used plain old HTTP to manage it, I simply told her that I would remediate the issue by saying the risk was acceptable because it was not accessed outside the network. They could also answer (just to cover the bases) that they would use their SSL VPN as a portal to access it from the outside if it was ever needed.

After I delivered that answer, she was silent for a couple of seconds. I could tell she was thinking about that answer, so I thought I had the problem solved. Well, I thought wrong. She said that this was something on the remediation checklist that had to be taken care of because it was marked as a major issue. So if the list said SSL V2 had to be disabled, then SSL V2 MUST be disabled. The concept of compensating controls (I use the term indirect mitigation sometimes as well) was out of bounds.

So I had to tell her that since I had no technical information that I could use to help directly mitigate this issue, and since she was not willing to entertain the option of indirect mitigation, that I was not going to be able to help. And that is something I LOATHE saying to my customers.

Now some might say that the auditor should have seen this as well and realized that it was not a major issue. And while I agree to a point, I also have been on the receiving end of enough audits to learn that the auditor is paid to find the issues, not mitigate them. So if an issue pops up on a report, it is up to the customer to remediate. And it is also up to the customer to use common sense when doing so. A remediation report from an audit need not be followed blindly. If an issue is marked as severe (or major or whatever other adjective you want to use that means it has to be fixed NOW), then it is up to the customer to determine if that is actually the case. If it is not, then the customer should work on getting it changed. If the arguments are solid, then that should not be a problem. And if the issue can be mitigated indirectly, then that case should also be made.

The goal is to have resources focused on problems that pose a greater risk so the risk posture can be lowered more quickly. It is about working efficiently as well as effectively. If you start trying to solve each problem head on and never thinking about how to use other methods to solve problems, then you are going to end up chasing your tail.