This tip is a special bonus element of SearchSecurity.com's Compliance School lesson, Must-have compliance technologies. Visit our Must-have compliance technologies lesson page for additional learning resources.
When I hear the phrase "compliance workflow," I always think back to my days as a product-quality consultant. In many ways, the objectives of each are identical in both scope and objective.
However, these terms also make most people cringe, as they evoke images of pain and ardor for the staff. This is usually based on experience with poorly managed quality- or compliance-process implementations. There are, in fact, thousands of examples of where quality done right has saved entire industries. By most accounts, American automakers are undergoing a resurgence due in large part to their quality-improvement programs. So why not view compliance workflow in the same manner?
I view compliance mandates simply as leverage to ensure that enterprises implement the security controls that should be in place anyway. For example, the Federal Financial Institutions Examination Council (FFIEC) standard requires two-factor authentication for financial institutions. This mandate protects customers and minimizes risk to organizations. Despite the effort that many enterprises had to undergo in order to become compliant, the end result benefited everyone.
So compliance workflow then simply ensures that all customers, new and old, receive a baseline level of protection against identity theft, data exposure, etc. Let us begin our review of this workflow process with two classic examples: COBIT and the Deming PDCA Cycle.
The workflow
The COBIT model began in 1996 as the brainchild of the ISACA organization. Its stated purpose is to provide a framework for IT governance. This framework is comprised of four control objectives, which draw comparisons with the product-quality world. The objectives are:
- Plan and organize -- Determine the strategy of how the security organization will meet business and compliance objectives;
- Acquire and implement -- Identify and implement compliance (and security) technologies, processes and procedures based upon your strategy;
- Deliver and support -- Enable the organization to actively use the compliance controls implemented;
- Monitor and evaluate -- Make use of the feedback mechanism driven by the auditing process.
Now notice how similar these objectives are to the classic quality model pioneered by Deming:
- Plan -- Plan for quality;
- Do -- Implement the controls;
- Check -- Audit the process;
- Act -- Act on the audit results found and repeat the process.
Both models offer feedback mechanisms to ensure compliance with existing controls and continuous improvement in design and operation. Thus both provide models for compliance workflow.
The compliance auditors
Now that we have established the similarities, we need to know how a compliance workflow process functions in an everyday operational environment. This is where auditors become valuable assets. If we know what auditors are looking for, we can improve our controls accordingly.
Compliance auditors like to see well-documented processes and procedures being used within an organization. (The rule of thumb for processes usually is if it's not documented, it doesn't exist.) They look for good management practices such as planning, monitoring and reporting. They look for continuous operational monitoring and supervisory review of key reports and audit results. A consistent adherence to policies by all levels of the organization -- and senior management action when policies are not being followed -- is a key component of an auditor's review. Lastly, auditors look for a balanced focus on both long- and short-term objectives and results.
The specifics of audits
While the details vary between audit types, compliance workflow programs generally include three broad areas within the organization:
- Management (or organizational) controls
- Operational controls
- Technical controls
Within each of these sections, various subsections are reviewed based upon the controls above. For example, we might consider the "change and configuration management" subsection of the program. Management controls look at whether an organization has well-documented policies and procedures for these areas, and if they are being updated regularly. Operational controls review the change control process for the policies and procedures. The actual monitoring process for change and configuration management is reviewed to ensure an accurate accounting of changes made. Lastly, technical controls being audited include items such as any automation made to ensure consistency in how changes are made to systems. This, in particular, is a fast-growing segment of the security industry. These tools assist organizations in doing things in a consistent fashion.
Other areas under an auditor's review include access controls, logging/reporting, documentation, system maintenance and incident response. All are reviewed according to management, operational and technical controls.
These areas then make up the compliance workflow framework. These are the areas to review and revise continuously. It is, in fact, a product-quality cycle with a regulatory viewpoint. But this workflow also provides real benefit to the organization by ensuring a continuous improvement system is applied across the landscape.
Conclusions
Compliance workflow is a little different from the product-quality process. It serves as the feedback cycle for an enterprise's normal compliance operations. While compliance is generally viewed strictly as a cost to the enterprise, it should not be so. It is the process by which companies ensure that they are actually providing the security services they should have been doing all along. When used correctly, the compliance workflow process provides a highly valuable service to the organization. One has only to look to the quality world to view the positive impact the "continuous improvement" movement has on the quality of goods and services today. Compliance workflow programs should be no different.
About the author:
Tom Bowers, managing director of security think tank and industry analyst firm Security Constructs, holds the CISSP, PMP and Certified Ethical Hacker certifications, and is a well-known expert on the topics of data leakage prevention, global enterprise information security architecture and ethical hacking. His areas of expertise include aligning business needs with security architecture, risk assessment and project management on a global scale. Bowers serves as the president of the 600-member Philadelphia chapter of Infragard, is a technical editor of Information Security magazine, and speaks regularly at events like Information Security Decisions.
