Focusing on the fundamentals in the software development process.

Build secure software

Peter Hesse of 10Pearls wrote an article about the future and failure of information security. From Security Today, “Why is the Security Industry Failing?” is a wonderful recitation of the problems besetting the information security industry.

Peter describes the money-hungry vendor culture, where every problem is seen as a potential billion dollar product or service. He talks about how companies aren’t paying attention to the Top 10, 12, 15, or even 20 security control failures, from whichever creator of those lists you wish to name.

Hesse’s solution is to build security into software. Specifically, he says we need to, “focus on building security into our software applications and technology platforms.” In other words, create secure software and platforms during the development process, do not bolt security on top or add it in hindsight.

Peter, I’m sorry; you’re right…and wrong. Wait, hear me out.

You’re right. As it stands now, the typical software application is built to be sold, to send that code out the door as fast as possible so it can generate money for the company. Developers are instructed, “Deploy code quickly,” not “Deploy secure code quickly!” That one word, “secure,” makes all the difference in the world. Bolting on security ex post facto is always worse than building it in. Using sane frameworks, where input sanitization and code/data separation are part of the process? Genius! Using secure hardware with hardware security modules (HSMs), locked-down memory addressing, and very well-tested methodologies for encryption, messaging, and error handling just makes sense.

Now, Peter works for a software development company so his views fit his situation. I bet 10Pearls has fantastic code security policies and tests the heck out of its code. But are all development teams from myriad types of companies that way?

They are not, so… Peter, you’re also wrong, unless you think that all companies will use secure frameworks, will factor in code/data separation, will prioritize user security over immediate profit. To illustrate the point, how many camera companies issued firmware updates after the Mirai botnet was made public? One? Eight? None?!

In all seriousness

With the venture capital backed system we have now, coupled with stockholder priorities, it’s a rare company that thinks beyond the end of the current fiscal quarter and the magic “numbers” the company “needs to hit.” It’s difficult for most companies to develop a long-term view of the organization’s growth strategy. Yet a longer term view is absolutely necessary to prioritize security in software, systems, applications, and consumer electronics.

How do we fix the problem? We bake security into the processes, into procedures. We build structures which we slot systems and applications into. We perform that most horrible of rituals, compliance. (But it works, so that’s cool.) We use devices with Mobile Device Management systems, and lock down users’ profiles. Smart admins never log in as an admin and then surf the internet.

In other words, we focus on the fundamentals. We lock things down. We patch. We scan and test. We automate to make systems reproducible, and we segment to localize problems. We follow established standards, perform compliance audits, and prepare for $DEITY knows what, because it will happen.

Peter, until all software is written to a standard, and a standard that you and I can agree on and work with, I know you and I will keep recommending to our clients that they focus on the fundamentals. You know what? Even then, I bet we’ll still keep doing the basics. They work, after all.

Related Posts
NEMA – Electro Industry
Assessing Big Picture Risk Through the Lens of the Equifax Breach

Leave a Comment

%d bloggers like this: