Risky Behavior: Making Risk Assessment Fun

The Naval Safety Center's Picture of the Week often provides a great visual aid when discussing risks - I find that audiences get a kick out of them, and they can help break the ice when starting a risk assessment. This one? I'm pretty sure that's an integrity risk (for his bones), and an availability risk (to his services). Impact? High! Probability? Well...that depends.

Visualizing a Risk Vocabulary

Worlde.net's word visualization tool can be a great way to map out words and concepts. The Wikipedia text for Risk Assessment became part of a presentation I am building for a presentation that I was asked to provide as a guest speaker in an MBA class. Here's what is looks like:


The map for computer virus is also interesting:

I suspect that these will be useful visual aids in my presentations - a new way to present security concepts is often helpful, particularly when dealing with a non-IT staff audience.

The Intersection of Can and Shouldn't

Every IT staffer knows that there are times when technology supports capabilities that can make a solution work, but which shouldn't be implemented. A co-worker phrased that nicely recently - "that's the intersection of can and shouldn't".

What intersections of can and shouldn't have you run into? My best example recently? Overly helpful helpdesks.

Often, help desk staff have access to a lot of data, allowing them to assist with various cases and events. Unfortunately, this leads to the inclination to be helpful outside of the scope of IT technical support, and can lead to additional risk exposure for an organization. In this case, training has to overcome the highly ingrained inclination to be helpful - something that help desks are designed to do.

Oh, and just because you can fix NAT issues by using your inline IPS or other packet filter to change them to the correct IP doesn't mean that you should...

Upcoming webcast: Risk Assessment and Risk Transfer in a Digital Age

Core Security and Chubb (an insurance company that offers "CyberSecurity" insurance) are hosting a webcast titled "Risk Assessment and Risk Transfer in a Digital Age" on Tuesday, March 25th at 2 PM EST. If you're using a risk based security model, or you're interested in insurance as a risk transfer strategy, this might be an interesting webcast to listen in on. Their topic list includes why attacks are made, how to improve security, a comparison of assurance and false confidence, and how to transfer risks. That last topic is of particular interest, as Chubb's involvement should mean a good discussion of what options insurance can offer you when transferring risk.

I've started to see more organizations looking into cyber insurance, and the market appears to be maturing - in fact, the first webcast I've seen hosted by an insurance company. With cyber-theft insurance and other similar coverage has become a more frequently discussed topic in the past year, and I'll be interested to see how Chubb positions themselves in the market.

Risk Management: Denial, the strategy that isn't a strategy

One of the short courses I enjoy teaching is a basic back of the napkin risk assessment process. It gives people a bit of leverage as well as a better understanding of the risks involved in their projects, designs, and systems. One part of that training is to talk about risk management once risks have been identified.

Most security professionals will tell you that there are four basic methods of risk management:

• Acceptance or retention - accepting the loss when it occurs. Self insurance is often used as the standard example of risk acceptance.
  

• Avoidance - not performing the activity that creates the risk. If exposing your services to the outside world creates a risk, you can avoid it by not exposing them. This is often possible for some, but not all risks.
  

• Transferral - insurance is an excellent example of risk transferral. A lower payment insures that losses can be recouped, thus transferring the bulk of the risk to another organization.
  

• Mitigation or reduction - taking action to reduce the risk. This is often paired with avoidance by avoiding as many risks as possible, then mitigating the remaining necessary risks.
  

There's a super secret fifth option that isn't really an option - but which is quite common. Every time I teach someone asks about it, because it shows up in almost every organization at some level when assessing risk.

Denial.

While it isn't a valid strategy, often management and staff will not want to face a problem, or admit that a risk exists. I've seen this happen with the most senior management in organizations and at every level down to entry level staff, and once it starts, it often becomes an organizational assumption. It usually isn't due to ignorance, but rather due to a simple blind spot - the risk just doesn't seem real or possible.

There is a possible win in instances of denial though - if you can crack through that carefully built armor and get someone to admit that there is a risk, the entire organization's attitude can quickly change. In one case, the most senior person on a team I worked with paused halfway through a risk assessment in which we had identified a risk that senior staffers were highly trusted with no internal checks.

The light had turned on.

She noted that if she herself decided to cause problems that the organization could face a significant risk. Once she admitted that she herself could be a risk, the rest of the team quickly chimed in with the risks and vulnerabilities that their positions faced. Denial had shifted to awareness, and that let us address their risks through valid risk management techniques - with the full support of management.

Denial. It isn't a valid risk management strategy, but it is real - develop a strategy to deal with it as part of your risk assessment process, and you'll reap the benefits.

Creative Commons licensed photo credit Flickr user shawnzlea

DHS: CFATS - have you accounted for your chemicals?

Many higher education institutions will be preparing their lists of "chemicals of interest" for the Department of Homeland Security early next year. The rule stipulates that listings be delivered 60 days after the release of the final rule meaning lists will have to be provided by January 19th unless you request and receive a 60 day extension. Chemicals range from chlorine to aluminum chloride to propane, meaning that many departments on campus will likely have to report their totals.

If you haven't thought about what the chemicals on your campus could be used for, take a look. Each chemical lists what it would be potentially useful for, providing a convenient overview of what risks your campus might face.

The Chemical Facility Anti-Terrorism Standards require a variety of things, ranging from risk assessments to reporting of chemical amounts on hand . These apply to many higher education institutions, and responsibility for detailing may have fallen to risk management or facilities staff. If you're an information security staffer, you may want to check with the appropriate department at your school to see how that data is being stored and secured.

Where did all of this come from? It is part of the Department of Homeland Security Appropriations Act of 2007, which President Bush signed in October, 2006. Section 550 of the Act gave DHS the authority to enact the rules above. The Act defines the covered entities as "chemical facilities that, in the discretion of the Secretary, present high levels of security risk." More details can be found in the final rule here.

Risk Assessment: EULAs and contracts

One of the often neglected parts of a security program is the contracts that your organization enters into with vendors. Often organizations accept the standard boilerplate rather than negotiating a more favorable position, or accept a EULA that contains conditions that the organization may regret. This is a great place to apply some of the tools and tactics that you apply to other security projects - checklists, risk assessment, and standards.

One tactic I like to recommend is to work with your legal representation to create a checklist to review EULAs and other agreements - being able to filter out those with issues that are easily found up front can save significant amounts of time - your lawyer's time is often expensive, and doing a first round check can save you money and pain in the event the contract becomes an issue. The EFF provides a good user level guide to dangerous EULA terms which can be a good starting point. Once you have a checklist, you can pull risky or questionable clauses out.

When you develop the checklist, make sure to separate your categories - terms that are completely unacceptable should be noted, and terms that are questionable, or that you prefer alternate language for should be marked as such. If a clause that your company requires isn't present, that should be accounted for as well.

While a checklist isn't a substitute for proper legal review, it can help weed out some of the worst EULAs and contracts.

Along those lines, check out the OWASP Secure Software Contract Annex. Organizations that hire third party developers should have a well understood contract, and projects like this help smaller organizations with something they might not have the resources or in house expertise to handle.