Bridging the software and infosec professional chasm

In contrast to the unseasonably cold weather Columbus, Ohio, has experienced of late, this week’s InfoSec Summit kicked off in bright purple ‘Aloha’ style with Jim Manico’s recommendations for improving web application security. Only one other attendee could match his shirt color, but none were equal to the energy with which Jim highlighted some serious software security concerns.

No, this wasn’t a dig on the software developers who face an incredibly daunting tempest of deadlines, budget constraints and requirements as part of their daily existence. This was a heartfelt plea to security professionals to provide clear and specific security requirements as part of the pre-design documentation. If we do anything less than proactive, constructive communication about security with application developers, we’ll never slow down the freight train of increasing cybersecurity threats.

The description of Manico’s session explained “we cannot ‘firewall’ or ‘patch’ our way to secure websites. In the past, security professionals thought network security practices and corporate policies were enough. Today, however, these methods are outdated and ineffective to protect application, as attacks on prominent, well-protected websites are occurring every day. No company or industry is immune. Programmers need to learn to build websites and other applications differently.”

Manico — an author, developer security educator and 17-year veteran of building software as a developer and architect — shared several examples of poor software security practices and some healthy antidotes. Here are a few, and you’ll find a link to his library of software security slides referenced at the end.

Thwart SQL Injections

Would the email address ‘;–@domain.com pass your email address validation? Hope not. It’s the perfect recipe for a SQL injection attack that sets the email address field to nothing (that’s the ‘; part of the address). And the two dashes? Well, they comment out the rest of the link.

Solution? Use query parameterization. Now, be honest. When was the last time your development team received “query parameterization” in their list of requirements? None of the software developers at this week’s InfoSec Summit had the benefit of such instruction, but were still mandated and doing their best to write secure code.

Improve poor password management

OK, now would “Password1!” meet your password policy? How many banking websites are there that still limit passwords to eight characters? Please, allow your passwords to be as long as you reasonably can.

Sprinkle a little cryptography and salt on your passwords to slow down your password verification. That’s right — slow it down. It puts a real crimp on brute force hackers and can buy you days or even weeks against an aggressive attacker without significant negative impact to your users.

Use multi-factor authentication

First, if you’re not using multi-factor authentication for your Gmail, Twitter, LinkedIn and other accounts, stop reading this. Enable multi-factor authentication now, and then come back. Seriously. No, go ahead, we’ll wait right here. If you really took the time, you’ve just spared yourself and your networks a lot of spam and hassle.

Think the impact of poor password management is trivial? Blizzard, producer of World of Warcraft, implemented multi-factor authentication when players’ accounts were brute forced hijacked to facilitate cyber money laundering and the involuntary dispersal of valuable possessions. As every business is discovering, digital assets are a currency all their own, and protections are woefully weak

Don’t reinvent the wheel

There are many excellent software security libraries available, such as the OWASP Java Encoder Project. If you are writing your own security code from scratch — stop. Chances are a mature library already exists that you can leverage and help meet those crazy deadlines and requirements even more gracefully!