I have often heard, and been told, there is a difference between security and compliance. This is true but also doesn’t the measurements of compliance generally establish the products and methods we deploy to ensure security and thus also our compliance?

How often has an agency or bureau implemented a product or method of security based upon a single compliance mandate? Once implemented, how does this new product or method get integrated into the compliance reporting?

Even if we back out the methods and specific policies, quite often we see a myriad of security based products we have implemented to maintain our commitment to mandates, regulations and overall compliance.

Seeking a solution
So, how do we view compliance at a higher level that allows us to implement functionality and policy instead of point products and methods that provide little to no integration into our well thought-out compliance reporting plan? The answer is not a simple one and may require procuring products with broader capabilities around IT security, policy definition and compliance reporting as integrated functionality.

Why should we have to separately report on FDCC compliance for a set of our hosts, when actually a common operating environment for our operating systems should be a foundation of our overall end node security plan? Should we not be integrating the FDCC scan into our host based scanning policies, our host based security auditing policy and our host firewall policies? Maybe we can even utilize some of these policies to define our Network Access Control for our managed systems to ensure full and “continuous compliance” before allowing them onto the network and periodically afterwards? Then we can start defining the other technical requirements from FISMA, PII, HIPAA, OMB mandates and agency based policy into our integrated continuous compliance plan.

Once we determine we have non-compliant devices, shouldn’t we have the capability to remediate against those devices, re-scan and have a defined workflow to audit them as now compliant against the various technical requirements from numerous policies, mandates and regulations? A product that is focused on only one measure of compliance has little to do with a comprehensive plan.

As we are beginning to define our high-level compliance plan, we should also determine how other security events and our prevention or handling of these might effect our compliance reporting.

Do we have the right network security in place to support our plan? Can we adequately report on network security events and how we handle these events as integrated components into our overall security plan? How do we define if these events require any remediation to our end node devices and if these events could have negative impact on our compliance reporting? Again, there are many attributes to network based security and these do not directly correlate to compliance. However, network based attacks, if not prevented, can inject the capability to lose confidential information protected by regulation. This does indeed have a negative effect on our compliance functionality. What about our e-mail and the risk of Web based traffic on the network and end node devices?

Of course, there is much to IT security compliance than just those issues previously listed. There are many non-technical requirements, and the process definition we must also integrate into our compliance reporting.

I have purposely raised many questions and not provided the answers, as there are many ways to solve these items. The key point is to determine what level of “compliance” is adequate and how to build this into your security framework. The most important question is how to define a continuous compliance plan that benefits from your security strategy.