Good security conversations benefit all involved. The more we share, discuss, and challenge each other, the more we advance our industry. Thankfully, I have the benefit of working closely with a brigade of information security professionals and we banter at every opportunity, for the sheer pleasure and insights. In that same spirit, we hosted our first Blog-Talk radio session. This was a general discussion of the problems of measuring security.
The 30 minute discussion can be replayed here
Two other internet chats are planned. Everyone is welcome to participate or just listen in. Details can be found here.
Tags:
security,
roi,
value,
measure,
rosi,
information_security,
optimal_security,
model,
risk,
tim_casey,
matthew_rosenquist,
rosenquist,
casey


"SlashPump" submitted a question during the radio show, but was cut off. So here is his question and a response by the Intel IT SOx Compliance Manager:
"I have question re compliance reporting.
Not the "normal" upper-case-C Compliance issues (SOX, PCI, etc.), but about assessing compliance (lower-case-c) to established policy and procedures.
We've been assessing our deployed platforms to ensure they are compliant to p&p for such things as minimum password length, etc.... then we report these compliance stats to Management.
This is a time-consuming item, and is often mis-understood by recipients as being mandatory to achive Compliance for SOX, PCI, and etc. Even external auditors are (erroneously) using these stats as evidence of a configuration management control.
I've not been able to find any literature that identifies this (internal) compliance assessment requirement. What are best practices and experiences of the audience in this area?
Does anyone else report such statistics?"
The Intel IT SOx Compliance Manager provided insights:
"Regulations like SOx typically do not get to this level of granularity (e.g. law doesn't mandate specific control or metrics like this, it's up to the company to determine what they place reliance on). If the metric is something one of the regulatory compliance efforts relies on (e.g. metric identifies exceptions that then triggers a process to resolve the exception and SOx relies on that process) then it needs to continue; however, if it's not relied on for compliance--then it's an operational metric that could be removed if management isn't asking for this data and/or if no other group is doing anything with it (e.g. resolving exceptions, improving processes)."
Thanks to both "SlashPump" for the question.