Poor implementation planning and a lack of real understanding of compliance requirements doom many companies to compliance project lifecycles of unrealistic expectations, expensive implementations and disappointment in the results.
Take for instance a common requirement of log data retention. There exists a widespread misconception that large amounts of audit data must be generated and stored for long periods of time for successful compliance.
The HIPAA standard is a perfect case in point. The oft repeated chestnut is that HIPAA requires all raw data from all transactions to be retained for seven years in order to support auditor and customer requirements.
However, take a look at this excerpt: “Information system activity review (Required). Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.”
(HIPAA 45 CFR 164.308 (a) (1) (ii) (D)
Read it carefully - you are required to maintain a review of audit data and not necessarily records of raw audit log data itself. Often this misunderstanding is exacerbated by a "if we don't know if we have to save it, we might as well err on the side of caution and save it all" syndrome. As a result, the storage requirements of a good sized HIPAA compliance effort single handedly props up the stock price of EMC for the foreseeable future.
The FUD cycle
A lack of understanding of the standard, coupled with the usual internal structures and tensions inherent in many large organizations, gives rise to what is know as the “fear, uncertainty and doubt” (FUD) cycle of compliance.
A typical cycle: The board passes a resolution stating that the company will resolve to identify, prevent and deter instances of non-compliance with such and such regulation; or a high profile data breach motivates the CEO to take steps to ensure that it doesn't happen to them. The word is passed down to the CFO and CIO to make it happen and a project is created
This is the first mistake. It is essential to realize that corporate adherence to compliance guidelines requires deep internal changes, much like permanent weight loss requires lifestyle alterations and not fad dieting.
The CFO and CIO put in place a “tiger team” made up of personnel from their respective departments to plan and implement the compliance project. This team is empowered to take decisions and is allocated a timeframe and budget to complete the project.
After boning up on standards, data auditing requirements are typically understood to mean that system-wide auditing needs to be implemented with a solution that will provide reports, analyses and trigger alerts when exceptions are detected.
When this requirement is presented to the IT staff , they respond with inflated requirements of their own – “We'll need much more CPU, memory, disk space; a dedicated team of persons to generate and maintain the reports, resources to tune the correlation engine to respond to new threat patterns, a faster network with new gear etc etc. This will drive budget projections which get presented to the CFO as “cost of doing business.”
This is the next mistake – a proper understanding of requirements will not cause excessive requirements to be levied. Further, proper implementation will extract corollary benefits in the server health monitoring and security areas.
After balking at the “excessive” budget demands, the CFO calls for a meeting with the CIO to hash out a middle ground for implementation that will allow them to go back up the chain to report success. This implementation plan is not based on requirements, but based on budget considerations. The permanent staff required to maintain the implementation, of course, never materializes.
Once the project is complete, the tiger team is disbanded. This again is a mistake, as a system owner must be defined who hereafter will own the compliance problem. The board or CEO is informed that the project is complete and requirements are satisfied.
In a short time, without an ongoing process owner responsible for refinement and monitoring, the implementation begins to break down and is eventually discarded as broken.
The cycle starts all over again. What went wrong?
In the example above, there are several mistakes:
As always, a dose of common sense liberally splashed throughout the project cycle can wash away a lot of problems. Here are some guidelines:
Compliance efforts are not projects and must be continually performed – assign budget and staff accordingly.
Not all systems need to be audited and even then, not all resources need to be audited to the same depth. Limit audit generation to generate the smallest possible set of data.
For example, limit generation only to the core financial systems, and within these, only to the critical files or folders or data. This will make IT staff scale back their system demands to more reasonable levels.
Another way of looking at this is that the retention of the logs are themselves security risks – much like keeping credit card data. Raw logs are useful for a little while for forensic purposes but after once they are no longer useful, delete them.
Recognize that most compliance standards require that log records be reviewed and it may be acceptable to retain only these reviews or summaries after a certain time. Don't assume that you must have all logs of every kind stored forever and a massive engine to search through the complete set for any arbitrary answer at any time.
Before enabling auditing on production systems, have persons in place to regularly review and sign off on generated reports.
Designate a system owner who will maintain the system and refine the processes, as needed.
Recognize and evaluate the corollary benefits that can accrue when a system is in place. Ensure that these benefits flow back to the organization.
Right size the requirements, right size the solution
Many log management projects borne out of compliance data auditing requirements are stillborn because the initial analysis leads to a conclusion that it is a massive project requiring an enormous amount of investment/time. In other words, the return on investment is poor. Recognizing and ordering the level and depth of audit data to be generated will permit you to design and implement an effective log management solution.
Understand the log data retention requirements that are truly necessary. It may very well be that reviews (electronic sign-off) and summaries are sufficient after data has aged beyond a certain time. If so, a more modest investment may suffice to meet the requirements.
As all compliance standards are cut from the same cloth of best practices, recognize that any implementation must yield corollary benefits in the areas of operations and security to maximize return on investments and lower the cost of compliance.
- A.N. Ananth is the co-founder and CEO of Prism Microsystems, Inc.
Take for instance a common requirement of log data retention. There exists a widespread misconception that large amounts of audit data must be generated and stored for long periods of time for successful compliance.
The HIPAA standard is a perfect case in point. The oft repeated chestnut is that HIPAA requires all raw data from all transactions to be retained for seven years in order to support auditor and customer requirements.
However, take a look at this excerpt: “Information system activity review (Required). Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.”
(HIPAA 45 CFR 164.308 (a) (1) (ii) (D)
Read it carefully - you are required to maintain a review of audit data and not necessarily records of raw audit log data itself. Often this misunderstanding is exacerbated by a "if we don't know if we have to save it, we might as well err on the side of caution and save it all" syndrome. As a result, the storage requirements of a good sized HIPAA compliance effort single handedly props up the stock price of EMC for the foreseeable future.
The FUD cycle
A lack of understanding of the standard, coupled with the usual internal structures and tensions inherent in many large organizations, gives rise to what is know as the “fear, uncertainty and doubt” (FUD) cycle of compliance.
A typical cycle: The board passes a resolution stating that the company will resolve to identify, prevent and deter instances of non-compliance with such and such regulation; or a high profile data breach motivates the CEO to take steps to ensure that it doesn't happen to them. The word is passed down to the CFO and CIO to make it happen and a project is created
This is the first mistake. It is essential to realize that corporate adherence to compliance guidelines requires deep internal changes, much like permanent weight loss requires lifestyle alterations and not fad dieting.
The CFO and CIO put in place a “tiger team” made up of personnel from their respective departments to plan and implement the compliance project. This team is empowered to take decisions and is allocated a timeframe and budget to complete the project.
After boning up on standards, data auditing requirements are typically understood to mean that system-wide auditing needs to be implemented with a solution that will provide reports, analyses and trigger alerts when exceptions are detected.
When this requirement is presented to the IT staff , they respond with inflated requirements of their own – “We'll need much more CPU, memory, disk space; a dedicated team of persons to generate and maintain the reports, resources to tune the correlation engine to respond to new threat patterns, a faster network with new gear etc etc. This will drive budget projections which get presented to the CFO as “cost of doing business.”
This is the next mistake – a proper understanding of requirements will not cause excessive requirements to be levied. Further, proper implementation will extract corollary benefits in the server health monitoring and security areas.
After balking at the “excessive” budget demands, the CFO calls for a meeting with the CIO to hash out a middle ground for implementation that will allow them to go back up the chain to report success. This implementation plan is not based on requirements, but based on budget considerations. The permanent staff required to maintain the implementation, of course, never materializes.
Once the project is complete, the tiger team is disbanded. This again is a mistake, as a system owner must be defined who hereafter will own the compliance problem. The board or CEO is informed that the project is complete and requirements are satisfied.
In a short time, without an ongoing process owner responsible for refinement and monitoring, the implementation begins to break down and is eventually discarded as broken.
The cycle starts all over again. What went wrong?
In the example above, there are several mistakes:
- Treating the compliance effort as a project rather than an ongoing process requiring enterprise-wide internal changes and collaboration;
- Incorrect understanding of the reason and rationale behind compliance standards leading to excessive requirements;
- Failure to understand and extract corollary benefits from the implementation effort; Compliance mandates are often best practices turned into legislation;
- Ending the project without assigning a compliance system owner and a process to continual refinement and improvement.
As always, a dose of common sense liberally splashed throughout the project cycle can wash away a lot of problems. Here are some guidelines:
Compliance efforts are not projects and must be continually performed – assign budget and staff accordingly.
Not all systems need to be audited and even then, not all resources need to be audited to the same depth. Limit audit generation to generate the smallest possible set of data.
For example, limit generation only to the core financial systems, and within these, only to the critical files or folders or data. This will make IT staff scale back their system demands to more reasonable levels.
Another way of looking at this is that the retention of the logs are themselves security risks – much like keeping credit card data. Raw logs are useful for a little while for forensic purposes but after once they are no longer useful, delete them.
Recognize that most compliance standards require that log records be reviewed and it may be acceptable to retain only these reviews or summaries after a certain time. Don't assume that you must have all logs of every kind stored forever and a massive engine to search through the complete set for any arbitrary answer at any time.
Before enabling auditing on production systems, have persons in place to regularly review and sign off on generated reports.
Designate a system owner who will maintain the system and refine the processes, as needed.
Recognize and evaluate the corollary benefits that can accrue when a system is in place. Ensure that these benefits flow back to the organization.
Right size the requirements, right size the solution
Many log management projects borne out of compliance data auditing requirements are stillborn because the initial analysis leads to a conclusion that it is a massive project requiring an enormous amount of investment/time. In other words, the return on investment is poor. Recognizing and ordering the level and depth of audit data to be generated will permit you to design and implement an effective log management solution.
Understand the log data retention requirements that are truly necessary. It may very well be that reviews (electronic sign-off) and summaries are sufficient after data has aged beyond a certain time. If so, a more modest investment may suffice to meet the requirements.
As all compliance standards are cut from the same cloth of best practices, recognize that any implementation must yield corollary benefits in the areas of operations and security to maximize return on investments and lower the cost of compliance.
- A.N. Ananth is the co-founder and CEO of Prism Microsystems, Inc.
