5 ways to explain IT security non-technically

Archive for July, 2004

5 ways to explain IT security non-technically

Posted by Wolf Goerlich

Looking to explain defense-in-depth and layered security to a non-technical audience? Here are five comparisons that drive the idea home.

 

1) Medieval castles

Castles are a well-used trope for explaining security. Castles have large grounds for seeing the enemy at a distance. They have moats, walls, and various battlements. Once inside, a court yard serves as a spot to aggregate the enemy and surround them from above. These layers can be explained with comparisons to their modern digital counterparts (for example, court yards compared to firewalled screened subnets).

 

2) Automobile safety

Cars and trucks are a good touch point. Modern vehicles have a number of security systems that we can compare with. The tires need the proper pressure and proper tread. Brakes need to be in good condition, too. Automated systems for tires and brakes, traction control and ABS, can be compared to automated IT security systems. Then there are crumple zones, airbags, seatbelts, and so on.

 

3) Stacked pyramid

A pyramid chart is ideal for showing the relationship between various security layers. Visually, it makes an easy to follow presentation. The typical layers, top to bottom, would include the firm’s data, data protection, end-point protection, network security, Internet/Intranet/Extranet security, compliance, policies and procedures, and finally the firm itself. The security at each layer can then be pulled out and investigated further.

 

4) Concentric circles

Circles within circles are another easy visual for showing the relationship between security layers. Like the stacked pyramid, this makes for an easy to follow presentation. For example, starting with the outside world (both physical and Internet) and working the way in thru perimeter security, network, host security, and all the to the firm’s data.

 

5) Onions and ogres

If you think about circle upon circle, layer upon layer, what is the first thing that comes to mind? Onions. An onion model is much like a concentric circle model. The added benefit is that some humor can be derived by tying the talk to Shrek.

Shrek: For your information, there’s a lot more to ogres than people think.
Donkey: Example?
Shrek: Example… uh… ogres are like onions!
Donkey: They stink?
Shrek: Yes… No!
Donkey: Oh, they make you cry?
Shrek: No!
Donkey: Oh, you leave ’em out in the sun, they get all brown, start sproutin’ little white hairs…
Shrek: No! Layers. Onions have layers. Ogres have layers. Onions have layers. You get it? We both have layers.

Defining Business Continuity and Disaster Recovery

Posted by Wolf Goerlich

The definitions that people have for Business Continuity and Disaster Recovery are all over the map. The confusion makes consulting on BC/DR interesting, to say the least. These terms do have standard definitions.

 

Definitions

Business Continuity is the actions a business takes to maintain key business processes in the face of a large scale outage. Business Continuity is holistic. It covers people, processes, and technology. Ideally, it is a managed as an ongoing concern. Such a Business Continuity Program will regularly review potential events (disasters or emergencies), assess the impact of such events, develop recovery strategies to meet these event, and perform regular testing.

Disaster Recovery is the actions that select business units perform to maintain IT systems and services in the face of an outage. While Business Continuity is holistic, Disaster Recovery is very specific. As a subset of the BC, DR concerns the IT applications, servers and equipment. BC identifies the critical business processes. DR identifies the enabling systems.

 

Misconceptions

I have heard a few misconceptions about the relationship between Business Continuity and Disaster Recovery. Here is some of what I have heard, and the correct interpretation.

“Our Disaster Recovery is that piece of equipment right there.” DR is not a backup library, a server, or rack space at a facility. These may be resources in a recovery strategy used for a specific critical business process.

“Business Continuity is just really fast, really good Disaster Recovery.” It is one thing to recover, another to continue. Right? However, DR is a portion of a BC program.

“We have Business Continuity for the business systems (ERP or back office systems) and Disaster Recovery for our IT systems.” The rationale goes that IT that directly supports the business gets Business Continuity and IT that does not gets Disaster Recovery. The reality is that the business has two different recovery strategies: a faster strategy for ERP, a slower less expensive strategy for general IT.

“We used to have Disaster Recovery and then we bought XYZ and now we upgraded to Business Continuity.” There is a vendor whose sales people are making these claims. The reality is that the upgrade improves your recovery metrics by reducing your recovery time. But you still have a DR product.

In summary, Business Continuity is the overall program that encompasses all aspects of maintaining a business in the face of disasters. Disaster Recovery is the part of Business Continuity that deals specifically with restoring IT systems and services.