Security problems within an enterprise are almost always the result of a failure within the organization's IT operational procedures. By focusing on the problems and not the underlying cause of their existence, security professionals fail to provide their customers with all the arrows in their quiver to get ahead of the curve in security.
As IT security professionals it doesn't take much to become jaded to the problems we discover on our customer's networks. I often say "I cannot believe it!" after seeing what amounts to stupid errors that leave companies at huge risk. But the tactical problems are almost always the symptom of a broader IT operational problem. People who do not run a tight ship operationally usually do not have a good security practice organizationally. It sounds obvious, but many times the people who hire us to analyze their infrastructure are not necessarily the same people who manage it, and those same people are more technically focused than organizationally focused.
IT security is a dynamic endeavor. What was secure yesterday might not be secure tomorrow. What is secure on one platform might not be fine on another. Due to security's dynamic nature, to manage it, your customers must have a comprehensive understanding of their environment, and have a formal and documented procedure to deploy it, and to mange change within it. Without knowing exactly what their network and its entire components look like, they cannot manage change on it.
A sustained secure network is the product of the following formal, written, adhered-to operational procedures:
- Change Control -- Nothing on the network is deployed or modified without change control, which enforces configuration management and manages emergency change procedures.
- Configuration Management -- A repeatable procedure to deploy only approved configurations onto the network. These configurations include the network, hardware, OS and application software.
- Patch Management -- Patch management ensures that all deployed technologies are tracked for security patches and updates. Patch management uses change control to push patches.
- Audits -- Depending on deployed technologies and business uses, a scheduled third-party audit of the deployed security controls.
- Security Policy -- A security policy is a strategic document that spells out the corporate philosophy on information security. This policy does not tell how to achieve its tactical implementation, but rather requires that formal and written HR and IT Operational procedures meet or exceed the standards spelled out in the policy.
Often times, security problems can be traced back to weaknesses in these procedures, which, if not addressed, can cause further problems down the road. If you are conducting an assessment and find problems with an organization's security, take a wide view of the IT department and look at how they conduct business. Check for formal, written procedures, enforcement of policies, and most importantly, change control. When you're hired to do an assessment, a formal review of the administrative controls is usually not in scope, so ask the tactical engineering teams if they have change control, configuration management and a security policy. They are the people who implement and manage the network, so if they have not heard of them, it really does not matter if they exist or not.
When I write a report of findings for a security assessment, a penetration test or other technical security review, I include a section called Root Cause Analysis. In my experience the majority of the time the paragraph is the same: the organization does not have or does not enforce strong IT operational procedures, which always leads to the corresponding security problems. I re-enforce this finding in the executive summary and make it an explicit part of any discussion with the customer. I also state that although I didn't formally review the procedures for completeness or accuracy, based on the findings and discussions with the engineering staff, it appears that there is a weakness. I tell them that without an examination of the root causes of the findings, they might remain in a reactive mode, rather than getting a handle on the laundry list of "To Dos" that come with a security assessment.
Root cause analysis adds little time to an assessment but lots of value your customers. They will appreciate that you are adding a dimension to your reports that give them a direction and path toward fixing the cause of their problems, not just a list if issues that are the symptom of their problems. Remember, repeat business comes to consultancies that add a tangible value to their customers, and root cause analysis does exactly that.
About the author
Adam Rice is a Manager at VeriSign'sGlobal Security Consulting. VeriSign's Global Security Consulting Services help Fortune 500 companies understand corporate security requirements, navigate the maze of diverse regulations, identify security vulnerabilities, defend against and respond to attacks, reduce risk, and meet the security compliance requirements of your business and industry.
Adam has authored several white papers and technical articles on security professional services and emerging threats to the Internet community. He has an extensive background working in security professional services product development and business delivery.
