Pratum Blog

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?

The Department of Homeland Security (DHS) stated recently that the agency will hire up to 1000 cybersecurity professionals over the next three years. This is good and bad.

Let’s start with the good. Anytime an organization realizes they have a significant a deficiency in a skill set and then commits to remedying it, I give them credit. The fact that DHS recognizes it is lacking professionals skilled in information security undoubtedly comes from the poor grades they received on their Federal Information Systems Management Act (FISMA) reports in earlier years. While last year the official score was a "B", the agency stated they felt they were closer to a "C" grade.

While FISMA isn’t really a good assessment of security in an organization, it is helping to identify some gaps. They don’t always get fixed because fixing it may or not improve their overall grade. Let’s face it; we do the things that allow us to check the box and get the passing grade.

So while the idea of hiring more security professionals sounds good, I have to wonder what roles those positions will play in effecting significant change in the organization. Will these roles be just added worker bees that identify gap after gap, only to have it de-prioritized by management? Or will these people actually be given responsibility AND authority to bring about change? Will they sit in key management positions or individual contributor roles? If so, I think this could be a great boost for the organization. If all they do is increase the bureaucracy by generating more reports and intelligence which is never acted on then they have failed.

I wish them all the best but history is not on their side.

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.