A few months ago, we read with astonishment that a group of French students had discovered thousands of publicly accessible, open MongoDB databases—not because of a vulnerability in the database engine, but because of poor practices by the people who had deployed them. It’s terrifying when you stop to think about it. It may seem like an isolated curiosity, but the point is that the information in those databases could put people, institutions, and even countries at risk. Without exaggerating, that case is probably just a drop in the ocean.
Let’s admit it: when developing projects, we almost always end up delivering under time pressure, leaving a long trail of TODOs and things that could be improved. What’s more, few clients—especially those who don’t know much about technology because their business or field is something else—know how to evaluate the quality of what they’re given. As long as it works and they like what they see, there won’t be a problem: everyone’s happy, we’ve delivered a project, the company has been paid, and on to the next thing.
When we talk about software, we’re talking about a means that enables other activities: a company’s document management, a freelancer’s blog, a washing machine’s firmware, or a SCADA system that manages a thermal power plant.
But is there really any interest in addressing security in every kind of software project? I’m not talking about software for aircraft, nuclear plants, and so on, but applications of any kind, built by any company for ordinary clients (who, for their part, try to pay as little as possible).
Here’s what I mean: information security is barely a relevant concern for most software developers. That’s not because we lack the technical knowledge to address these issues, but because, in general, there’s no technology culture that is especially concerned with demanding software built to all security standards. Cybersecurity is still more of a science-fiction movie term than a genuine, widespread concern across our industry.
Whether it’s a simple project where a breach could have little or no impact, or one of the many projects where any security incident could be a serious problem, the consequences can range from lost working hours and enormous frustration for those affected to risks to people’s physical safety and facilities. I’m not exaggerating at all: for example, one of the products sold by the company I work for could literally leave thousands of electricity customers without power. What if one of them depended on life-support equipment? This is a very serious issue and shouldn’t be taken lightly.
Security is important—extremely important—especially at a time when our entire economy is not only addicted to oil but also depends on technology to keep functioning. For many platforms, an hour of downtime can mean a lot of money (as well as an unprofessional image). But even for a small family business’s website, an outage can mean many hours spent resolving the problem.
I’d say that to handle security better in our work, we also need to develop a bit of a hacker mindset and act as pentesters.
We don’t need to think about security the way it’s portrayed in shows like Mr. Robot. It’s not all about super-hackers with socialization problems and a geek subculture. Software security is part of our everyday work, whatever kind of software we build and whatever platforms we use: it should be part of the roadmap for every development project we work on.
But how? It’s true that project managers themselves may trivialize these issues and see them more as a cost than as a distinguishing mark of quality. Yet every professional activity needs to minimize risks. That means including security assurance tasks in development, at the design level, in the configuration of the platform we rely on, and at deployment time. And, naturally, the client should see that work as a positive contribution to the project (and therefore agree to it and pay for it).
Could this be a good time to stand out professionally as a developer who specializes in security? The subject certainly offers plenty to explore.
Leaving grand statements aside, here are a few simple examples that can be addressed with relatively little effort:
- If you use any data store containing sensitive information, that information should be stored encrypted.
- Passwords used to access middleware or external services should be strong, like the security keys used to access cloud services on Amazon or Azure.
- If you use a file containing access passwords of any kind, make sure it isn’t accessible after the project is deployed (obviously), and why not consider encrypting the file itself, too?
- If you have a web client, validate data on both the client and the server.
- Review any IT software infrastructure in use (web servers, protocols, operating systems, databases) in production, and make sure it is configured correctly.
- And a very long list of other things…
Some clients, on the other hand, will be delighted to see a security appendix in a project proposal. In my opinion, a company that provides software and places special emphasis on the security of its work is not only doing something necessary; it should also be seen as a higher-quality provider. That can set it apart from its competitors.
Software security has many facets; it’s an enormous subject. As a small sample, for any web application:
- Could it withstand a DDoS (distributed denial-of-service) attack?
- Does it include XSS (cross-site scripting) filters and prevent SQL injection?
- Does the web server, whatever it may be, account for HTTP request/parameter pollution vulnerabilities?
- Is the web server configured properly to hide the
X-Powered-Byheader, or has it implemented HPKP (HTTP Public Key Pinning)? - Does it implement the frameguard strategy?
- Do the forms include a CSRF (cross-site request forgery) token?
- And another very long list of other things…
Huh, what? I’m certainly no security expert, but it’s a subject I’m becoming increasingly interested in. If you develop web applications and the concepts above (randomly picked from many others) sound like complete gibberish, ask the Three Wise Men for training in 2016 or a good stack of books to help you improve in this area.
It’s true that being absolutely exhaustive about everything that needs securing would be a huge undertaking. At the very least, though, we could include a checklist in every project to ensure that the essential security requirements are met.
By the way, speaking of security, why do hackers—or at least some high-profile hackers—always seem to have a scruffy look, caps, T-shirts, and several days’ worth of beard? Curious… :-)