January 26, 2004
(Computerworld)
Most information security professionals are probably familiar with at least one of the many recent regulations that have an information security element to them. For my company, the legislation of concern is the Sarbanes-Oxley Act, which has presented new financial accounting and reporting requirements.
I recently reviewed the law to see what the IT security group needed to do to ensure compliance. It was without a doubt the most boring document I've read in months.
Besides getting bored, I also came away confused because it offered no guidance on the related information security issues. After further reading, I decided that the most important part for my group is Section 404, titled "Management Assessment of Internal Controls." This section mandates that management attest to the effectiveness of our company's "internal control" structure and procedures for financial reporting. Internal control is an extremely broad term, but I translated this section to mean that the CEO will expect my group to have sufficient controls in place to ensure the confidentiality, integrity and availability of financial and other critical information. So I came up with an initial plan to ensure compliance.
Over the past few years, I've put together a series of information security policies, standards, procedures and guidelines. Some of these documents are published, others are available to those who ask, and others are just sitting in a shared folder on our network.
I think we have enough infrastructure in place to satisfy most expectations of our executive staff and any auditor. But to make everyone's lives easier, I decided to standardize on a methodology for policies and standards called ISO 17799 -- something many of my peers are also doing. The ISO information security code of practice consists of a framework that provides guidance in creating strong information security.
The ISO framework consists of 10 main sections, with several subsections within each. First I created a table of contents, making sure that the expected ISO 17799-compliant headings were in place and that there was a place for every policy, standard and guideline that we have created over the past few years. Most of our documentation exists as either Microsoft Word or Adobe Acrobat files. Eventually I'd like to convert all of the documents to HTML and create a hyperlinked set of documents where users can quickly navigate from a policy to the corresponding standard, guideline and procedures.
Even a well-organized set of documents doesn't ensure compliance with those corporate standards, however. Sarbanes-Oxley mandates that audit reports contain a description of internal controls testing and that we document our system of internal control. That presents a problem.
The Auditor Issue
We used to have an audit person in the information security department, but after he resigned, we never replaced him. At the time we couldn't find a qualified candidate. Then, eventually we lost the requisition for that position, and the work he had been doing fell by the wayside. We do have a separate audit department, but it mainly focuses on financial matters, not IT security.
From my perspective, the important aspect of compliance is ensuring that the policies and standards we have created are followed and that we have a program to ensure that all departments are complying with the appropriate standards. This means that we have to take the time to revisit the standards we created to make sure they're up to date.
We started this work by scheduling meetings with each department in order to review documentation and ensure that it is current and being followed. We also looked at some of the work the previous IT security auditor had completed. Along the way we found an Access database that lets us enter audit items and track compliance and areas of concern.
Fortunately, there has been an extension to the Sarbanes-Oxley compliance date, and that should give us the time we need to satisfy these audit requirements.
Goals for 2004
While the Sarbanes-Oxley effort will consume much of my team's time for the next few months, I have a few other high-level initiatives in store for my group this year.
The first will be an identity management system that includes public-key infrastructure technology. The challenge will be identifying all of the applications that the identity management system will touch and ensuring that we make the right decision on which vendor's PKI system to use. Along the way we'll have to decide whether to install a certificate authority in-house or outsource that function.
Finally, there is still a lack of compatibility between PKI vendor offerings and other products. It's imperative that the system we pick be compatible with all of our applications and operating systems.
After that's completed, we will be looking for a new event-correlation tool. Our current product just isn't performing as well as we'd like, so we will look at several other contenders. In addition, we will be looking to install a remote scanning system to continually scan our infrastructure for vulnerabilities. Finally, we will begin installing a configuration and patch management tool to address inconsistencies within our environment.
We want to ensure that both our critical servers and individual desktops have consistent configurations and are up to date on patches for each environment. Those projects should keep us busy well into the new year.
What Do You Think?
This week's journal is written by a real security manager, Mathias Thurman, whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com, or join the discussion in our forum: QuickLink a1590
To find a complete archive of our Security Manager's Journals, go online to computerworld.com/secjournal.