Thinking Security: Thinking Or Not Thinking Security
This is the 29th blog in a series about security and how security is about how you think.
The major theme of this blog has been the security mindset and how we “think” security. But when do we do we “think security”? If we’re good at it, we’re always thinking security. One of my favorite sayings is, “You’re not really paranoid if they’re really out to get you.” Of course, that statement has a sarcastic edge to it, but it does bring up the point of when we have to and should consider security.
It’s really different depending on circumstance and background. Many people don’t think security until after the fact. For example, the first car designers probably didn’t think about putting in a key-based ignition system until after someone stole a car for the first time. They probably came out to where they had left their car prototype and realized that it wasn’t there. Only then, did they think about making it so only they could start the car. This is an example of reactive security (thinking security after the attack). Either they thought of it – but not much – – or they never thought that it would be a valid “attack.” It’s part of the process (because you sometimes underestimate the actual probability of risk’s happening). It is taking a risk (someone taking your car prototype) and evaluating with regard to it happening (what are the odds?)
True security is proactive – all risks are evaluated and possible. It’s thought of at design time and remediated before deployment to product. Let’s take another example – the concept of a network-connected pacemaker. The research and development process starts with getting the pacemaker to work in a restricted environment, in which no external connections are possible. In that environment, the developers can get the pacemaker working and optimal. But before deployment into a large hospital or external environment, the developers must first analyze and implement control of the pacemaker. For example, a unique identifier and control for each pacemaker is critical, so no one else can get in and change settings or turn the pacemaker off. The designers of the pacemaker thought through the design of the pacemaker, thinking of all of the security implications and prioritizing each security feature. Only when it was secure was it released to the general public.
But there is an evaluation process involved – there are many, many possible attacks to a system. Proactive security includes constantly enumerating all possible attacks and prioritizing them. But it also involves designing the system to be more resilient or even impervious to the attack. That’s the proactive security in Unisys ClearPath Forward™ systems – the system designers thought about security when they created the architecture. They thought about only being able to execute segments designated as code (thinking ahead to malware in the future) as well as checking memory bounds (so data corruption could not occur through buffer overflow). Security was built into the architecture of the system from the very first models all the way to today’s ClearPath Forward systems.
You can never get in trouble thinking security earlier rather than later. It’s a classic tradeoff. But it’s all about being proactive about security – think about it as early as possible. It’s all about how and when you think security.