Focusing on success or failure?
This is the second part in the discussion of the difference between IT and Information Security. Click here for Part 1.
You probably think I’m going to say focus on success, don’t you? Well read on, it’s not nearly that simple.
When a system administrator or application developer is working to create a new system, the process usually starts first by identifying what the system is supposed to do. The process will include purchasing hardware, writing code, tweaking settings, and a rollout, all with the intention of meeting a particular objective. The system’s creator is focused intently on making a system that meets all of the requirements.
All of this makes perfect sense right? It’s the way innovative problem solvers work. See a problem, create a solution. This traditional process is completely oriented on success, and how to achieve it.
Information security works differently. Rather than focusing on how to build a system that can meet a requirement, a security-minded individual will focus on how to build a system that cannot do anything but meet a requirement. The difference is subtle, but critically important.
A success based focus is a strength for those who are innovating new ways to solve problems. It is essential for creating a new product, to differentiate a company in the marketplace, and for adding new features that customers love.
A failure based focus is a strength for those who are responsible for ensuring that goals around security, reliability, consistency and quality are met.
A failure based focus is a strength for those who are responsible for ensuring that goals around security, reliability, consistency and quality are met. This is essential for finding those hidden glitches that can turn into a gigantic PR problem and turn away customers in droves.
In information security we have the responsibility to temporarily put on a black hat and get into the mind of attackers. We must figure out how a malicious user could take processes that were created to accomplish a specific task and abuse them to accomplish a different task; one that was never intended by the system’s creator.
These two types of focus, either on success or failure, are not mutually exclusive. But it’s a rare thing to find a person whose mind can easily go either way. Most people are drawn to either creating new systems with amazing bells and whistles, or in evaluating those systems and finding ways to break them apart. A good tester is a great example of someone who should be focusing tightly in on how a system can fail. It’s in trying unexpected actions, and trying to break the system’s logic, that the most crucial and best-hidden bugs are found.
Some specific examples of ways a success focused mindset can leave security holes:
- Cross site scripting or SQL injection vulnerabilities. In both of these cases the system will meet the functional requirements just fine. Without the abusive user being considered one would never see the need to perform input validation to prevent these attacks.
- Excessive services open on a server or network. Yes, your traffic is working just fine, but what else is working as well? By not considering malicious behavior too many doors may be left open into a system, allowing unauthorized access.
- Default or insufficient passwords. In a world without malicious actors, why bother changing that firewall’s default password, or worry if a password’s complexity is sufficient to stand up to an attack?
This post should not be seen as an indictment of the success-oriented mindset in system creation. The greatest innovations were created in just this way. See a problem, create the solution. But companies should realize that those innovators are not the same ones that should be tasked with ensuring security objectives are met. It takes both kinds, and good processes will include both sides throughout the system’s lifecycle.
But since information security is still often dropped into the laps of the traditional IT departments, we commonly see success-focused technical people being asked to continue with their normal just but “just make sure it’s secure.” A better understanding of the differences between these roles can go a long way to putting the right people in charge of the right tasks.
Connect with Robb on Google+