Compliance Is Just The Beginning

Building a security program that meets compliance requirements yet is based on risk, not reaction, is like constructing a house: It involves a number of professionals with different specialties, everyone needs a set of blueprints to work from, and ad hoc deviations from plans get very expensive very fast.

The first decision is what level of security you need, and can afford. A risk assessment to map out your assets and identify what data is most important to your organization, as well as what regulations you must comply with because of that data, is the foundation of any security program. As part of this assessment, be prepared to estimate the business and financial value of different types of information. This will help prioritize risk, so you aren't spending $8 to protect data that's only worth $5. Risk assessments may be done by outside auditing firms or internally, following various methodologies, including the NSA's Infosec Assessment Methodology; the Factor Analysis of Information Risk, or FAIR, method; and the ISO 27000 series standards.

An internal or external penetration test is the usual next step, and is encouraged by most regulations twice a year. A penetration test helps validate the findings of your risk assessment and provides evidence of whether the company is following its own policies. For example, when working with a Level 1 Payment Card Industry merchant, our organization performed a third-party risk assessment that found that the retailer was--on paper--doing everything required, from updating patches to emphasizing secure coding in the application development life cycle. However, when we performed a penetration test, we were able to break in within 15 minutes. The group was not, in fact, updating patches on all servers and didn't employ secure coding practices.

With an assessment and pen test in place, next comes the hard part: Getting business users involved in classifying their data, and getting funding to shore up your security program where needed. During the risk assessment process, you identified owners of specific data types. Our job as security professionals is to advise those owners on the risks to their data and how we would best protect it.

And yes, it's their data, not yours. Infosec groups don't own anything except the risk.

DUAL TRACKS
It's extremely important to keep moving toward the ultimate goal of a security architecture while hitting those compliance initiatives you must address. As with construction, if you don't build a structure to code, an inspector is going to come round and tell you to tear it all down and start over. That said, it's also vital not to confuse being compliant with being secure. If a building code didn't require a house to have doors, would you skimp?

Recently we spent more than two months performing a security assessment for an organization that was subject to various regulations. We documented more than 30 issues to be resolved, but instead of addressing a subpar security posture, the CIO asked, "Is there a checklist that we can go from, so we pass?"

DIG DEEPER

RISK MANAGEMENT 101

Reactive mode is no way to run a security infrastructure.

This free
InformationWeek Report will show you how to stop fighting fires.

>> See all our Reports <<

Talk about missing the point. The bad PR landscape is littered with companies that were compliant with a host of regulations and still got breached.

We're not suggesting that this CIO didn't care about protecting his corporate and customer data. But as the number of regulations increases, even well-intentioned leaders can be tempted to check compliance boxes and hope for the best rather than do the hard--and potentially expensive--work of understanding and mitigating risk.

Budget realities dictate that having dual security tracks, one implementing comprehensive security frameworks unrelated to compliance, and one working to demonstrate conformity with regulations, just isn't feasible. The good news is, the two needn't be mutually exclusive. Instead of using regulations as the final goal of your security program, use them as minimum security baselines, to which you add layers of security as needed.

Matt Franko is PR manager and Ken Stasiak is president and CEO of SecureState; contact them at [email protected]

Continue to the sidebar:
Regulation Frustration