Category list

Risk Assessments

< Day Day Up >

Risk Assessments

Risk assessment is a business issue, not a technical one. This is the second step in bringing your critical incident plan to fruition. Risk assessment is the process by which the organization's management understands the impacts associated with potential threats and calculates maximum downtime before the organization ceases to be profitable. Risk assessment requires widespread interaction with relevant business units and sometimes places team leaders in the middle of having to soothe tempers and calm bruised egos. Like planning, there are many different approaches to successful risk assessment. Some are very complicated and require an incredible degree of abstract understanding, while others are simple and effective.

Experience Note

Occam's razor : "All things being equal, the simplest solution is usually the best."

Risk assessment comes to a conclusion when an organization's executives make formal decisions relative to their fault tolerance. Fault tolerance is the level of functionality required by an organization to continue profitably.

< Day Day Up >

A Little Organization, Please

It is preferable to assemble a small team to collect and evaluate information used to create the risk analysis. The size of the business will dictate the size of your team. It is important not to have a risk analysis team of excessive size . Large teams seem to be more difficult to manage and they are generally less functional than smaller ones.

Experience Note

An elephant is a horse designed by a large committee.

The risk team's responsibilities are:

Gather and organize necessary data
Perform critical asset, threat, risk, and cost/benefit analyses
Formulate protection strategies
Report results

Gathering and organizing information might consist of documenting the results of e-mail and personal interviews where persons within the organization are interviewed, as well as collecting already existing documentation. This does not mean contacting employees in management positions only, it means talking to employees having operations knowledge. The most time-consuming interviewing method is the personal interview. There are circumstances that dictate a boardroom-to-boiler-room scale of questioning, which depends on the size and structure of the organization as well as the experience of the risk team. Personal interviews allow clarification and free exchange of ideas; however, if the team is faced with a large-scale organization, it is strongly suggested that you use a combination of sending questionnaires via e-mail first, then review them and conduct personal interviews of more-critical positions.

Respondents usually provide valuable information in the way of their opinions about critical assets and perceived threats. Take the necessary time to review each returned questionnaire. Frequently overlooked is the organization's internal documentation. If the organization has had a recent security audit or other type of operational assessment, ask to see the final report. A related and useful document is the organization's last audit report. Search for the organization's response to the audit. It will likely contain the findings of the audit and the corrective actions taken.

Ask for data flowcharts, organization charts , and lines of authority, human resource directories, equipment inventories, policy and procedure manuals, and software inventories. All these documents will help identify critical assets.

Experience Note

Remember these documents are very sensitive and deal with the very core of an organization, so approach the subject diplomatically. Provide appropriate security to these documents. They should be reviewed on a need-to-know basis.

Performing a threat analysis is a multi- faceted task. The first step is the identification of critical assets required to continue profitable operations over a given period of time after the critical incident happens. Critical asset prioritization is an essential part of the threat analysis process. Threats must be considered, as they impact specific assets. Threats must be considered in light of their frequency and whether they will affect critical assets in part or as a whole.

Keep threat assessments within reason. It is unreasonable to consider the chance of hurricanes impacting the Rocky Mountains or snowfalls in Brazil. Frequently, risk assessments measure the impact of threats such as fires, floods, hackers, and viruses, and ignore the employee who is sending off- color jokes through the organization's network. The risk team must consider the probability of malicious or unethical employee behavior negatively affecting assets.

Likely the most-valuable source of employee behavior policy information may be found in the employees' handbook or the organization's Human Resources Department. If the business has weak or nonexistent employee behavior policies, this should be brought to the attention of the executive sponsor. Immediate action is required to address this matter.

Formulating protection strategies starts with evaluating asset safeguards already in place, the effectiveness and cost of those safeguards as they relate to protected assets, and future safeguard needs. An important idea supporting protection strategies uses the "what-if" idea. This process takes place in imaginary scenarios:

What if an employee e-mailed an offensive joke from his workstation to other employees in the company?
What if an intruder compromised a mental health patient's records?
What if an employee steals the organization's trade secrets or intellectual property?

This method has the effect of adding safeguards to the protection strategy testing to determine the difference each safeguard makes in relation to its cost and effectiveness. A good question to be posed by the risk team: What is the level of fault tolerance in each of these "what-if" scenarios? In considering "what-if" scenarios, the risk analysis team must have a good knowledge of the business organization, its processes, and excellent communications skills. During the process of completing the project, if the team discovers it does not have sufficient knowledge of a subject, then the team must decide to augment their knowledge and seek outside resources.

Reporting results is the most important task performed by the team.

Experience Note

"If it is not written, it does not exist."

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

So it is with the report that will be developed by the team, at a minimum it must be in a logically organized written form. Oral presentations can be made to augment the report, but for legal and audit purposes, a formal written document must be created. Reports should be written as stand-alone documents, meaning readers having little knowledge of the organization's function can understand the report and gain a reasonable grasp of the process, analysis, and recommendations. The language of these reports should be plain, digestible, and jargon-free.

Experience Note

A government worker was asked to explain a document with this language: "The PIC was TDY to NCA to correct anomalies in the ALCCS."

Nothing glares in a reader's face more than having to constantly refer to glossaries or to look up hundreds of technological abbreviations.

< Day Day Up >