Pratum Blog

Many an IT executive has asked me to help ensure their organization is secure.  What that actually looks like on the ground is very different based on the company and culture.  Some organizations view security from a point-in-time perspective.  In other words, on a specific date, specific systems complied with specific requirements.  Five minutes later however there can be no guarantee that changes haven’t been introduced which would impact this security posture.

I look at this from a process maturity standpoint.  If you’re always chasing the regulations, you’ll be running every day and never cross the “finish line”.  The regulations will change.  If your security program relies on meeting the letter of the law it will always be in a state of flux.

What would be a better approach would be to assess risk and then map regulatory requirements to those activities you are already doing to reduce your risk.  This methodology will do two critical things for you.
First, when the regulations change the mapping of control objectives to the regulations doesn’t require a rewrite of the controls and all the hassles that accompany this.  It also ensures that your controls are written generic enough so they could be mapped to multiple regulations.

The next thing it does is ensure your organization is taking a holistic approach to security.  If you relied on the federal or state law makers to tell you the adequate controls for your business you’d be misguided at best.  Would you trust them to tell you the best markets to go after to secure increasing profits?  I think not.  Why trust them to tell you how to secure your enterprise?

Many a company has followed the letter of the law only to find out they weren’t really “secure”.  I’d encourage you to approach security from a risk based model.  This ensures that the time and resources you devote to security will actually yield a return on your investment.  If done right, you’ll also be moving along the maturity continuum and become progressively more secure with each step.  Chasing regulations will leave you with large blind spots and gaps in your overall security posture.

Tracking the IT controls that are in place for an organization doesn’t have to be a nightmare. It also doesn’t have to be expensive. It should however be organized and easy to publish.

In the past I’ve used a custom list in a Microsoft SharePoint site for several of my clients. These clients already had a SharePoint infrastructure so it was a good starting point. While SharePoint is flexible, it is not ubiquitous. There has to be a better way.

When going into an engagement we had our trusty, dusty spreadsheet of common control objectives, the control statement, testing frequency, etc. If you’re anything like me, spreadsheets are ok for about the first two pages, then I get bored and/or frustrated. I want more.

We’ve begun developing an application which will not only track the control statements and map them to compliance objectives such as SOX, HIPAA, FISMA and PCI; it will also allow you to copy in your policy statements, control test cases and testing evidence. This information is all being stored in a backend database which can be queried and reported on.

There are tools on the market today which do this and a zillion other things with high entry points. What about the organizations that wants to start small and grow into it? Or the consultant who works primarily in the SMB market where $100K just can’t be justified? That’s the market we hope to tap with this.

As with most inventions, this started out as something we needed internally to reduce the time and effort with our engagements. It filled a void. Hopefully we’ll be able to help you fill a void as well. We’re still in the development stages on this but hope to have an alpha release shortly. If you’d be interested in testing the application drop me a line.

Mapping IT control objectives to specific standards or regulations is a daunting task. I’m currently working with an organization who wants to build their information security management program around the ISO 27001 and 270002 standards. On top of that they want to ensure compliance with Payment Card Industry – Data Security Standards (PCI-DSS) and Sarbanes-Oxley (SOX) at the same time.

In case you are wondering, there isn’t a 1:1 mapping for any of these standards and regulations. While the ISO standards are high level guidance, PCI gets pretty far into the weeds. There is however quite a bit of overlap.

Access controls is a good example. Each of these standards requires that users can be uniquely identified. A good beginning control for an organization could be something like this. “Each user of an information system must have a unique userid assigned to him or her.” This could then be placed in the organization’s control library and several compliance objectives can be satisfied and mapped to this one control. PCI may go deeper and require additional controls where the others are satisfied with this one control.

One of the problems is the sheer number of controls an organization will need just to satisfy one or two compliance frameworks. One could easily document 200 or more controls and only scratch the surface. As you are building your control library pick controls that are broad enough to encompass as much of the compliance requirement as you can. This will help limit the volume of control statements thus the amount of testing required to verify control effectiveness.

It’s important to remember that an organization may choose to implement controls in excess of the compliance requirements in order to reduce risk to levels deemed acceptable by business unit leadership. In this instance it is imperative that the risk and compliance teams clearly delineate these controls as out of scope for an audit.

Be careful not to let this become a “check the box” exercise. Developing controls should be done to mitigate risk first. If done correctly, adding controls to satisfy compliance objectives may not even be necessary. After all….PCI, SOX, HIPAA…weren’t they designed to mitigate risk?

Get our blog posts delivered to your inbox:

The information we track while users are on our websites helps us analyze site traffic, optimize site performance, improve our services, and identify new products and services of interest to our users. To learn more please see our Privacy Policy.