Dev Overflow – Part 1

By Mikhail Sudakov, Cyber Security Architect and Analyst, LEO Cyber Security.

Typical computer science graduates (our software engineers of tomorrow) may be fair logicians and problem solvers; alas, they have at best very little knowledge of software security. Unsafe computer instruction blunders are seen left and right unfortunately. Today’s machines are as powerful as they are dumb. They will execute whatever instructions given, oftentimes over and beyond of what the programmer originally intended.

Regretfully, software development is typically approached in the following steps:

  1. Build it
  2. Debug and make it work well
  3. Release it
  4. Discover (or be informed of) a vulnerability
  5. Slap security on top of the whole thing

 

The last step may be preceded by code reviews, fuzzing, static and dynamic analyses, etc. In effect, it makes software security something to be achieved, a checkbox to be marked at the end: “Yes, we did our due diligence”. It is incredibly easy to blunder this process, to forget something, and to miss a critical vulnerability. In fact, that happens all the time. I don’t believe the fault lies with our tools or QA testers. Instead, the philosophy of treating security as an end-goal is faulty.

Don’t get me wrong – I’m not advocating that we shouldn’t strive to secure our machine instructions. My take on it is that security should be a state of mind, not just the state of our software. Sure, if properly written, software should be “secure”. But, it should be securely-written at the onset and not merely fixed afterwards. Security should be interwoven into every line of our code; it should be considered constantly.

Stop thinking of software security (or security in general) as something to be achieved as there is no such thing as perfect security. Put your mind at ease and focus on software security as a thought process and not an end-goal. Weave it into every line of code, every method/function/subroutine, every class, every module, etc. Do you really need to expose that variable as global? Do you really need to run that process with elevated privileges? Make the secure decision.

And guess what – what you get in the end is attacker-resilient software that requires only minimal tweaks and fixes. You get software security that is at the very core of your instructions, not something that is an afterthought. Truly, security is a state of mind and a way of thinking – not a bunch of tests, reviews, or checkboxes.

About This Blog

As you’ve probably already guessed, this blog post is about software security. Without getting terribly technical, what I want to do over the course of several blog entries is review the newly-updated OWASP Top 10 – 2017 framework and discuss likely software blunders outlined in the list. Personally, I love what the project is doing for the software security community and have found their framework extremely helpful over the years. I think OWASP embodies my belief that software security is (or at least should be) a state of mind of the programmer and not just an end-result.

I’ll try not to be too technical in these blog entries because I want them to appeal not just to developers, but to other roles in cybersecurity as well. After all, the philosophy that security should be a state of mind is not limited to software security, but applies also in end-user training, network security, physical security, you name it.

So, keep tabs on the LEO blog to see my series of posts. The first post will detail OWASP A1 – Injection.

Comments

    Leave a Comment