SAIJE Thoughts

or SUCKING UP ISN’T HARD TO DO

An Old Friend of Mine, Pete,  told me I should start blogging. Which is why I’ve been blogging at light-speed the last couple months (this IS my third post). In any case, my previous post was on the need for maps but also caution in not solely using the mapping as a substitute for knowledge. I occasionally look at Pete’s blog (Spire Security Viewpoint) to see what I’m missing and areas to work on. A couple weeks ago he had a post called “For Pete’s Sake” and one of the key points was the need for contextual mapping. Other than the word mapping, there isn’t likely any similarities in our points, but I just wanted to keep working on all the blogging tools out there and this gave me an opportunity to Trackback Pete’s entry. After spending the last 4 hours trying to bring this site back up and it being very early in the morning I figured a post is more appropriate than doing more work that could bring my site down again. (Sidebar: When switching domain names and following WordPress directions where it says “Delete Cache only if you are running WordPress 2.0″ and you are running WordPress 2.3.x, DON’T Delete the Cache.) (Side Sidebar - any major migration like a new domain is not wise when you are operating on about 4 hours of sleep in the last 48 hours) If you read Pete’s entire entry you will see he has a new column coming out. I look forward to it.

PS - I also added this blog to Technorati. You can add it with the Technorati button to the right in the sidebar. I’m currently ranked in the 4 million or so mark (of the top blogs) so get in early. If I get a couple links on that, I’ll be one of the fastest growing blogs, growing hundreds of percents in the course of a day or two. Of course going from 1 link to 3-4 links makes that statistic a Little misleading…..

OR MUCH ADO ABOUT MAPPING 

Within the IT Governance and Information Security fields there are many requests for mapping one standard to another to ease implementation of standards and provide additional guidance where needed. However, one caution is that not all mapping is created equal and in no case should  one blindly follow the mappings provided without understanding the standards themselves and how they are implemented. In other words, mappings should only be used as a touchstone or starting point and not th e definitive guidance for implementation. 

COBIT 4.1 , ISO 27002:2005 (formerly ISO 17799:2005) and NIST SP 800-53 Rev 2 all are mapped to each other in various documents. For brevity, these standards will be referred to COBIT, ISO and NIST for the rest of this post. Luckily the COBIT mappings also provide a qualitative assessment of how well ISO control objectives and controls and NIST controls fufill the COBIT Control Objectives. The NIST mapping does not provide that qualitative assessment, however they provide similar cautions that I am discussing.

A short illustrative example of the dangers in blindly following mapping is illustrated below:

In the COBIT Mappings I selected three simple control objectives that both NIST and ISO fufilled completely. The image below illustrates the mappings. (Click to Open the Image Fully)

I selected those COBIT Control Objectives as the each have only one NIST and one ISO control that completely fills the COBIT Control Objective and should be easy to compare.  One would expect that at a minimum, mapping the same NIST Controls to ISO would show the same ISO  Controls and Objectives as those listed under the COBIT mapping. The table below shows the NIST mapping of those same controls (CP-3, CP-4 and CP-5) to ISO. (Click to Open the Image Fully)

Note that the ISO Control 14.1.5 that was listed as completely fufilling COBIT Control Objective DS4.6  is not present at all in the NIST Control CP-3, which was also listed as completely fufilling COBIT Control Objective DS4.6.  The other two NIST Controls list additional ISO controls and objectives, but that MAY be OK. It may be that those additional ISO Control Objectives are truly not part of the COBIT control objective listed above and are not needed to be identified. This was simply to illustrate the dangers of blindly accepting mapping. There obviously is a difference of opinion in the mappings of the COBIT standards to ISO and NIST and the mappings of NIST to ISO as shown in this example (specifically NIST CP-3). Which is why there is no substitute to understanding the standards and applying them as you understand your requirements.

Mapping is not without value, but it should be used as a starting point to understanding, not as a replacement for understanding.

Without going too far down this rabbit hole, here is a slightly more complex mapping. In this case the single COBIT Control Objective is completely fufilled by a list of NIST Controls and a list of ISO Control Objectives/Controls. The assumption would be that every NIST Control should have at least one, if not more of the ISO Control Objectives/Controls mapped to it as well. However, only TWO of the NIST controls (those highlighted in Green) map to ONE of the ISO Control Objectives/Controls listed. The others (those hightlighted in Yellow) have different ISO Control Objectives/Controls and vice versa. (Again, Click to Open Image Fully)

For Further Information on Mapping these Standards Visit http://www.isaca.org and http://www.nist.gov

Feel Free to Contact Me with Any Additional Questions.

Or A SAS70 Apologist

In preparing for SAS70 Audits and assisting other companies for their audits, I came across a document that summarizes well the criticisms of the SAS70. Below, I answer from a non-auditor perspective the misconceptions in each argument.

1. No Objective Standard.  The complaint is that the audited company gets to create their own controls and are only graded on those controls. For example: if the company does not put in a control on having passwords, then they will not get graded on that. Unfortunately, that may be the case if one has hired a poor auditor to validate controls, but in the SAS70s I have been through, there are checks and balances. Specifically, at the beginning of the audit period, the auditor reviews the controls themselves to make sure they are sufficient. While indeed there is not a single objective standard, that is acceptable. The controls for a financial institution should be different than the controls of a software development company, for instance.
2. The SAS 70 Audit Process is Designed to Drive Billable Hours.  There are several complaints rolled into one here. The primary complaint is that audits are expensive because auditors are there the whole time because the controls have to be tested over time. This is not the case. Controls can be tested over time by a thorough review of the evidence near the end of the testing period. One may want an auditor in several times so there are no end-of-the-period surprises, but there is no need to be auditing the during the whole period.  The cost for SAS70 was listed as $100,000 to $300,000 or even greater. This may be the case for some audits, but for smaller companies, I’ve seen audits that are a tenth of that estimate.

   

3. Other Audits Can Serve Better Than SAS70.  The idea here is that you can work with a company that has asked for a SAS70 and provide them other audits or information that will serve just as well. This may work OK when one only has a few customers, but in the light of Sarbanes-Oxley and companies that provide services to hundreds or thousands of customers, the SAS70 is the most viable option. Instead of having to negotiate on an annual basis to ensure each companies’ audit needs are met (imagine having to do this 1000 times a year for example!) , one can complete a SINGLE SAS70 and meet the needs of all your customers on an annual basis. If a customer has a specific need, add that as a control for the SAS70 and solve the need for any future requests as well.
4. ISO17799, NIST SP-800-53, COBIT, etc. provide better controls.  Of course they can, provided they fit your company’s operations and business. However, again, these do not fulfill the need a SAS70 does. The Best Option is to take one or more of those frameworks and use those as the basis for your controls in the SAS70. In that way you get the best of both worlds. I know of one company that used the entire 17799 control set as the basis for their SAS70 control set.

Conclusion:  As with any tool, SAS70 can be misused, intentionally or through a lack of understanding of the purpose and benefit of the standard.  Most of the complaints above derive from a lack of understanding of the SAS70 and how to truly execute a successful SAS70 audit that benefits both the audited company and the companies that use it’s services.