Security through simplicity - live it
Over the past semester, I have had the opportunity to assist a co-worker who was taking an “Introduction to C++” class.
I was a C++ tutor in my undergraduate program, and I helped a lot of my fellows in the Master’s Degree program I was in at JMU. Though I’m no expert, and haven’t done any C++ since graduation, I have probably written close to 25,000 lines of C++, and was excited to get involved.
My coworker was taking the class in the context of an IT Management class that has a focus on security and disaster recovery.
After she submitted her last project, she sent me an email talking about how tough the class was for her.
Below was my reply. I felt it worth capturing in a blog post…
…
Also, don’t worry if you didn’t leave this class as the world’s best developer.I think the real take-away is that coding is hard. It’s really, really hard.
It’s easy to make mistakes, very easy.
And it’s easy to hack something together, just enough to get the project done. It happens ALL the time. With the simple tools at our disposal, even novice developers can develop huge, web enabled, and EXTREMELY BUGGY software.
And from a security perspective, you must remember that fact ALL the time. That is the big learning lesson!
Not only will the software you buy have bugs.
But so will your firewalls, your anti-virus, you name it.Coding is hard. It is F’ING hard.
And even worse, you can take two completely secure pieces of code, and put them together. And you know what, the result may have security bugs!!!
Remember your experiences in this class. Use that experience to govern your thinking in future security related projects.
The experiences you have had are why my number one motto is: “Security through simplicity.”
It’s my opinion that every piece of hardware or software increases risk through it’s very nature.
Even a security countermeasure has some implicit security risk that must be assumed.
On the business side, when implementing software, or installing a new piece of hardware you make a business case. Does the hardware or software save money, or allow sufficient increase in revenue to justify the cost.
From the security perspective, particularly with security countermeasures, that equation is a little different. The “cost” is measured in risk.
So the consideration must be: Does the amount of risk offset by the countermeasure, adjusted for the inherent risk associated with the countermeasure itself, reduce the overall risk sufficiently to justify the use of the countermeasure.
It’s a tough equation, given that it can be tough to calculate the risk inherent in a security countermeasure. Why? Because we want to think that security systems are secure. But we know the truth. We know how deep the rabbit hole goes.
For example, what’s the risk profile of a firewall?
Well, there’s a lot. Among them:
- Potential for flaws in firewall hardware and software that could allow unacceptable traffic through.
- Potential for human error in configuring rule sets.
- Potential for the firewall to fail in an unsafe mode.
And there are plenty of associated costs.
- Cost of the system.
- Cost of maintenance.
- Cost of developing security processes and procedures to manage the firewall.
- Cost of developing and maintaining trained staff to manage the firewall.
- Cost to accurately monitor the system.
The logic is cyclical. The more risk you offset, the more you assume.
Hence my motto:
Security through simplicity.
Bill