Thursday, March 17, 2005

IT segregation of duties

It's no secret that auditing standards are in flux. Simply defining segregation of duties is a great example of an area where different top auditing firms embrace different approaches. While it's generally agreed by all that developer access to migrate changes to production is a bad idea, beyond that, it's all a crapshoot. Here's some areas of contention between auditing firms:
  • Can developers migrate changes to production if they are acting only in the capacity of production support -- if they don't have access to the physical code (such as a third party application)?
  • Should DBA's be able to develop or promote applications using the databases they administer?
  • Can DBA's have access to migrate their database changes to production?
  • What about system testers -- should they have access to development environments?
Clearly we should follow minimalist principles, and all users should be given no more privilege than is necessary to do their job. However, when you try to apply theory to real IT environments, compromises in terms of mitigating controls may need to be made.

It's always pleasant at such times to lean back and fantasize about a formal release management process. For some companies, SOX can be the catalyst, but this is not a trivial exercise. It requires dedicated resources, expanded application and packaging expertise, as well as a huge shift in roles and responsibilities, which may not be feasible in many organizations.

Monday, March 14, 2005

DHTML problem solving

On another front, contributed to this article on new solutions to old DHTML problems. As Ana Marie Cox just said at her SXSW keynote, "Sell out often and early."

Saturday, March 12, 2005

Data confidentiality issues

Last week I met with Jim Weise of Tablus, who I had met at last month's RSA conference. Tablus focuses on enforcing data confidentiality rules. The concept is, you would set up a database or file system, and apply a confidentiality rule against all the contents of that set. If a confidentiality rule is broken -- if a document is emailed outside the company, for example -- an alarm is issued for administrator review. They also have a sexy desktop app, which addresses the issue of someone cutting and pasting content from a confidential document into an email.

So there are some larger issues here, such as the fact that we'd all prefer preventive over detective controls, but this could be a good solution until better preventive controls come into place. Data classification is just such a horrendously annoying problem. In Secrets and Lies, Bruce Schneier discusses the Bell-LaPadula model of multilevel security, which offers a preventive concept. Basically, if I am working on a Secret computer or session, I have no access to write unclassified work, only Secret work, eliminating my ability to email a classified document, or reduce its security level. (Of course, this naturally supposes that our brains are purged of the information we read in a secure session, once we open an insecure session.) The problem is that everything -- user experience, expediency, etc -- is sacrificed for the sake of confidentiality. Great for the military, lousy for the real world.

Should we even be attacking this problem at all? Who has read access to data is not a key control for SOX, and the FDA hasn't focused attention here either. Much worse than dealing with data confidentiality in an ad hoc basis is coming up with controls which will fail under audit or inspection. In other words, if we take the time to classify all our data, develop rules, publish them, train users and put in detective controls, are we confident we can get to 100% compliance? Independent auditors are much more interested in how we comply with our own policies than whether these policies cover data confidentiality at all. I just fear that for the moment, this is a technically unsolved problem, much like controls around spreadsheets, our favorite elephant in the SOX living room.

But I digress. So Jim and I talked about the things which are easy to miss in an implementation of a detective control like Tablus. For example, I have a file system which I assign to a certain confidentiality level. What other instances of this file systems exist? Is this included in a regular backup, or in disaster recovery exercises? How is the data in these separate locations secured?

Which leads me to a concern about SOX. A company needs to compile a great deal of documentation for auditor review -- access control lists and rules, authorization schemes, network diagrams, processes for ensuring data integrity and nonrepudiation -- great stuff, and lots of it. Material that, should it fall into the wrong hands, could cause severe damage. While it's tempting to assemble all that material in one place for reference purposes, companies need to reflect on the potential threat models, and secure the data accordingly. Ideally, data should continue to reside in the organizations responsible for it -- root password rules with the sysadmins, for example -- so that the data can follow appropriate security rules. So yes, this will be more inconvenient for audit staff, but we can't compromise security for the sake of expediency.

Wednesday, March 09, 2005

aww

Kinda melts the heart, don't it?

whither SOX?

It's a strange time to be in the Sarbanes-Oxley compliance world. At the same time that trials and scandals are unfolding, governmental agencies are making off-the-record calls to dismantle the legislation.

While it's clear that SOX would assuredly not have prevented WorldCom or Enron, the most direct benefit of Sarbanes compliance is that it minimizes the shameful practice of chief executives dodging accountability.

But more important than mere schadenfreude, SOX presents a great opportunity for corporations to get their internal house in order. It's notoriously difficult to prove the ROI on IT infrastructure projects, and frankly, logical security is just not sexy. A company who takes an opportunistic look at internal controls will realize that the COBIT Framework and other best practices can use the compliance crowbar to significantly increase efficiency and security within their organization. Such a holistic approach, when brought against solid measurement criteria, can make huge strides in customer responsiveness and increased maturity.

One concern, which I haven't seen addressed so far, is the security risk inherent in assembling documentation to provide evidence for auditors, but I'll leave that for a future post.