Thinking Security: Don’t DO that

 Author(s): , Posted on January 18th, 2017

This is the 22nd blog in a series about security and how security is about how you think.

One of my favorite jokes ends with the punchline “Don’t DO that”. I won’t include the joke here, but it helps me also think about one of the most important but misunderstood areas of security – what the industry calls “Best Practices”.

We all have been raised with “life’s best practices” since we were little – “Do eat your vegetables”, “do your homework”, “Don’t talk to strangers”, “don’t talk with food in your mouth” and so on. These sayings were to make sure that we did the right things (as well as be safe and secure). As we see there are two types of these rules – the actions that we do, and the actions that we don’t.

This idea can be extended very easily into security – “don’t share personal information unless you’re sure of the identity of the other person” and “do ensure that all network traffic passes through a firewall.” There are many industry documents and security frameworks (e.g. Payment Card Industry Data Security Standard (PCI-DSS), ISO 27001) that contain page after page of these “best practices”. We look to these documents for guidance how to be secure and run secure businesses.

But it’s not completely DO and DO NOT. There are categories of “Best Practices” to understand the urgency of them in the environment around them. I divide “Best Practices” into three categories:

MUST:          These are the best practices that have to be done, no matter what. The entire security of the environment depends on them. For example, MUST and MUST NOT. (, “you must drive on the correct side of the road”, “you must make sure you identify and authenticate everyone that uses your computer system”, and “you must not play in traffic”).

SHOULD:      These are best practices that are highly recommended, but there are circumstances that may make these not needed. For example, “After buying a house, you should change all of the locks” – if you’re buying a house from your parents or someone that you trust, you may not have to do this if you trust them that they’re giving you all of the keys. “You should lock your car when you leave it” – if you’re parking it in a locked garage, then you don’t need to also lock the car if you trust the garage’s locks. On the contrary side, “You should not share your password with anyone” – but there may be circumstances in which you have to have shared passwords, but those are only very rare occurrences.

COULD:        These are best practices which are recommended for most environments, but may only apply to specific conditions. “You could require everyone to have two forms of identification to cash a check” or “You could require all computer access to use multi-factor authentication”. It comes down to the level of the security of the environment and how high a level of security you need.

All of these recommendations (from the MUST, SHOULD and COULD lists) are kept in a Security Guide for the environment (wouldn’t it be nice to have one of these for life?). There are two types of Security Guides – those that are written by the manufacturer (for example, your car or a computer system comes with one); and those that are written by the owner of the environment (for example, you can write one for the best practices in your own house). The more formal name for these Security Guides is STIGs (Security Technical Implementation Guides).

So, how does this tie into ClearPath Forward? All ClearPath Forward systems come with security guides, but they are smaller and easier to apply because of the high security environment that ClearPath provides. For example, the best practice “You MUST run an anti-virus program on every computer” – doesn’t apply to ClearPath, because viruses can’t exist on ClearPath because of the environment’s secure architecture. Other best practices are clearly defined and help clients use ClearPath Forward within the industry security frameworks (for example, ClearPath Forward has special documents just on PCI compliance).

Security does come down to how you think about these rules (“best practices”) and the environments for which they were intended – whether it is about life around us (“don’t take candy from strangers”) to computer systems (“do use ClearPath Forward systems for your business-critical data because they are the most secure computer systems in the industry”). How you think about security also determines where the best practices are put – MUST, SHOULD, or COULD as they apply to your environments and computer systems.

Tags: , , ,


About the Author

Mike Kain is a consulting engineer and security architect for the ClearPath MCP environment and has held various technical leadership positions during his 30 years of experience at Unisys. Read all Posts





«Strategic Application Agility through the Cloud: A Game-Changer for the Digital Age

Are students the biggest data security risk for universities? »






We use cookies on this site. By using this site, you agree to our use of cookies. To change or learn more, see our Privacy Notice.