In this case involving a large craft retailer, the plaintiff made a purchase with their credit card and, during the process, was prompted to give the cashier their zip code. Not unlike myself, the customer felt uneasy about giving out this personal information, but handed it over based on the belief that it was necessary to complete the transaction. Allegedly, the company then combined the zip code with other information to obtain the plaintiff’s home mailing address, and began sending unwanted marketing materials.

While the case was ultimately dismissed, the court’s decision to designate zip codes as PII is significant, because according to the Massachusetts court, zip codes now fit within the definition of PII and are therefore no different than PIN numbers used in debit card transactions, because both could be used to fraudulently to assume the identity of the cardholder.

Here at McAfee, many of our customers focus on the probability of a data breach and its perceived business impact to justify the addition of security controls. As privacy laws continue to evolve, I predict that similar cases to the above will follow in other states, prompting businesses to adjust and adapt. This has significant implications for the enterprise as well as the consumer. Only organizations that have the ability to address where their data resides – and who and what applications can access that data – will be able to smoothly adjust to these types of changes, and ensure that their database is secure.

Our Security Connected Reference Architecture can provide the framework and details for more efficient ways to manage the security and compliance of your organization’s data.

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.