Oct

12

Security - The Pieces that are Missing - Risk Analysis & Audits

This is the final in my series in what is generally in need of attention when building a robust security program. The two areas I have yet to address, risk analysis and audit, are in essence bookends when it comes to developing a sound security program. The risk analysis is critical in determining what threats and vulnerabilities lie in wait for the unwary and the audit process closely ties to risk management; how effectively an organization actually addressed any significant risks discovered during a sound risk analysis; and if the organization actually follows established security policies, procedures and practices.

Many organizations do not regularly conduct a risk analysis. A risk analysis should be conducted at least annually and whenever any major system or business changes occur. Changes within an organization and externally change frequently which means that identified threats and vulnerabilities will also change. What may not be a threat today may be one tomorrow and can create significant regulatory, financial and legal risks to an organization.

The risk analysis often forms the foundation of any sound security program. It involves taking stock of your assets (e.g., data, hardware, people, networks, etc.), prioritizing those assets (which is an important part of drafting a sound disaster recovery and business continuity plan), determining what threats and vulnerabilities exist, what security controls have been established to address identified threats and vulnerabilities and finally determine where action is necessary to prevent serious damage to the organization (regulatory, liability, financial and reputation).

As I indicated, risks change with time. Combating those risks do not solely lie in what technology you have on hand or how up to date your signature files, how good your patch management program is, etc. Most security breaches occur from within an organization. Your greatest risk is people. This means one of the outcomes of a sound risk analysis is the determination if current policies, procedures and practices are sufficient to reduce the risk to a more acceptable level (provide adequate security controls). There is no such thing as risk free security but your security program needs to be robust enough to demonstrate due diligence and limit any potential damage to your business. If you don’t look, you’ll never know what lies in wait.

There are generally three different types of risk analysis – quantitative (most empirical), qualitative (more subjective but, if completed by the right staff, effective) and ranking (listing in order discovered risks). In the health care space, many organizations who do conduct regular risk analyses use a combined qualitative and ranking approach. This amounts to using sound professional judgment to determine how frequently a vulnerability or threat will be exploited and what the cost is to the organization if that occurs and assigning a number to both to develop a risk score.

Qualitative risk analyses are more often followed given the fact that they are generally easier to complete and do not require a fair amount of calculations. Also, this type of assessment still proves effective in identifying risks that need attending to.

For those interested in learning more about conducting a risk analysis check out the NIST web site (800 Series; http://www.nist.gov). There are a number of sound resources available to assist you which range from books to on-line resources to external third parties who can assist you in establishing your own approach to conducting a risk analysis.

The point to remember here is the risk analysis is just the first step. Identified risks, if significant, do need to be addressed to protect the organization and, in many cases, demonstrate due diligence as it pertains to regulatory requirements and liability. After identifying risks, the organization moves into the risk management phase where such risks are addressed, policies updated, training conducted, etc. It is not enough to just conduct a risk analysis and it is not enough to conduct a risk analysis on a whim.

The next area, which is in some respects, represents part of both a sound risk management program and validates risk mitigation, is the audit program. There are generally two types of audits – periodic audits and a general compliance audit. Both are needed and regulatorily required for a number of organizations.

The periodic audit generally amounts to tracking audit logs at the network level, the application level, the data level and as it plays out in day-to-day business operations. Audit logs, if generated, need to be regularly reviewed to determine if anomalies exist, if data integrity issues exist and if inappropriate access is occurring to the data, the application and the network (internally and externally).

This is a simplification but there is a significant amount of literature out there regarding this type of audit. Once again NIST is a good resource as is SANS (http://www.sans.org) and other like organizations. The bottom line is you need to determine what audit logs are available, what you consider needs to be tracked based on the risk analysis and the functions of your business and what an appropriate approach to audit log analysis is. This is somewhat problematic with legacy systems where often audit logging is non-existent. Legacy systems may require more manual auditing (like looking over someone’s shoulder every so often) or other creative solutions.

A word to the wise – it is important to generate and review audit logs but you create a significant liability for your organization if you turn an audit log on but never look at the output. Remember that it’s available if you find yourself in court and the logs are requested for production during the discovery phase. If you haven’t reviewed the log or haven’t documented the process you follow to review the log, it is not all that difficult for the other party to claim negligence on your part.

The compliance or general audit is a complete review of your security program (under the HIPAA Security Rule it is called evaluation). You need to review your security infrastructure annually or whenever any major system or business change occurs. This means reviewing security policies, procedures and practices to determine if they are being adhered to and/or if they need to be updated. This means reviewing the results of the risk analysis and determining if the appropriate mitigation occurred. It means determining if the appropriate staff training is occurring, and so on. One way to look at it is you conduct a risk analysis to determine what needs to be mitigated, what may damage your organization. You conduct an audit to determine if not only you’ve done something about those significant risks, but how well your security program is being managed at all levels.

A good process to follow is to conduct your risk analysis, follow appropriate risk management practices (which includes the periodic audits referenced above) and end the year with a look back to determine how successful you’ve been in maintaining a robust security program and mitigating risks that crop up along the way through your compliance audit (this includes policy and procedure review). After you complete your compliance audit and note your findings, it’s time to start all over again with another risk analysis.

It is important to develop both sound risk analysis processes and audit processes. This means developing the steps to follow, the criteria to be examined, etc. up front and then move forward with a sound risk analysis process and audit program. Both need to be organized, documented with the findings acted on by the organization. This doesn’t mean if an insignificant risk is discovered, the organization needs to invest a lot of time and effort addressing the risk. It does mean, though, that the organization needs to document that the risk will not be addressed and why.

It is also important to examine your risk analysis process and your audit criteria regularly to reasonably ensure they continue to effectively assist in managing risk. As with risks themselves, the process of completing a risk analysis and conducting a sound audit need to be flexible with any changes documented.

The bottom line with all of the areas I’ve discussed in my three blog series where many organizations demonstrate deficiencies in their security programs is they need attention now and on an on-going basis. Also, they need to be documented. When I audit an organization (and most definitely when the government audits an organization), the first thing I will ask for is documentation. The better the documentation, the higher the chance the auditor’s visit will be shorter. As lawyers like to say, if it’s not written down, it didn’t happen. You can follow all of the appropriate practices but if you haven’t documented what you are doing, you run the risk of employees not following those practices, likely increase your level of security risk and will greatly irritate auditors if they show up on your doorstep (not to mention increasing the amount of time they will spend looking under the proverbial rug).