Defining adequate security controls |
 |
By Dennis C. Brewer
04 Apr 2006 | SearchSecurity.com |
|
|
Since the U.S. government's adoption of the Sarbanes-Oxley Act, security practitioners have been asking themselves what it means to "establish and maintain adequate internal controls over financial reporting.*" The confusion lies in the IT interpretation of the word "adequate" and the resultant phase "adequate IT security controls." We have seen plenty of examples in the press of companies whose security controls have been no where near adequate. No one would argue that the loss of Social Security numbers, credit card numbers and other personal information indicates inadequate security controls. But what constitutes adequate?
Congressional lawyers and SEC regulators choose their words carefully. They chose 'adequate' over and above all other words, knowing the implications for the IT shops charged with implementing sufficient authentication and access controls that support effective internal control over financial reporting. Needless to say, what is possible to do with today's product suites will change tomorrow. Defining a particular technology as sufficient would have been unwise. This leads us to see the obvious value of the regulators' use of the term adequate controls or -- stated another way -- a requirement to provide controls that are equal to (or up to the challenge of) maintaining the internal access control policy for allowing end-user access, while at the same time preventing the internal or external hackers from finding their way in to IT resources.
So what are adequate security controls? Adequate controls place full responsibility to an individual end-user for any entry to or change in a single data field impacting a financial statement or report at any level in the organization, from the store room to the board room. Having controls only sufficient to assign responsibility to "someone … I don't know who … in the accounting department" is not in any way adequate control. Adequate controls provide access only to specific, appropriate end-users and give the IT staff the ability to audit for wrongdoing, collusion and errors. If your controls are unable to do either of these, then they are not adequate and your organization is not SOX compliant.
Another reason for the regulators' use of a changeless term over ever-changing technology is that it allows for automatically raising the compliance requirements when advances in technology solutions become available. One thing that can be counted on -- even in the absence of technological advances -- is the proliferation of hacking tools, and the increase in the threat and capabilities of determined hackers over time. Yes, that is right, auditable compliance with externally imposed control requirements will become a moving target for every company. The same could be said for HIPAA or state-imposed criteria for privacy protection. Compliancy efforts need to be revisited often. The word maintain in the phase "establish and maintain*" is not a suggestion.
The only way to successfully meet the compliance criteria is to set the bar for authentication and access controls as high as the technologies and products available today allow. Once you have a control structure implemented, then have in place a scheme for constant vigilance for anything that will change the compliance landscape and to constantly test the success of your control structure long before any of the compliance auditors visit.
* terms and phrases taken from SEC regulatory documentation on sec.gov.
About the author
Dennis C. Brewer is the author of Security Controls for Sarbanes-Oxley Section 404 IT Compliance: Authorization, Authentication and Access published by Wiley, released Oct. 10, 2005, and available from Amazon.com, BarnesandNoble.com or your local book store. His resume includes a BSBA degree from Michigan Technological University, Novell Network Engineer Certification, and over a dozen years as an information technology specialist with the State of Michigan. He retired from his position as an IT security solutions specialist in January of 2006 from the State of Michigan, Department of Information Technology, Office of Enterprise Security and is now operating his own IT consulting practice in Laurium, Michigan.
|
|
|
|
