Here’s how to hacker-proof your app in 5 steps

As reports of companies suffering data breaches continue to roll in with alarming frequency, concern about data security has moved beyond the realm of IT pros and into the mainstream.

Security breaches at a wide range of companies, from brick-and-mortar institutions like Target, which allowed hackers to access data on as many as 100 million customers in December, to web-based platforms like Kickstarter, whose site was breached in February, have shown that no organization is beyond reach the reach of persistent attackers.

While each company faces different security challenges, there are several specific measures that web-based application providers should take in order to keep customer data safe.

Enterprises that provide web-based applications should take a broad approach to securing sensitive company information, ensuring that the data is protected from all possible attack angles. This means defending the network using strong and standard encryption — in transit and at rest — hardened devices and servers, next generation firewalls, IPS/IDS, monitoring/logging, antivirus, and writing secure code for the web-based application itself.

Here, I would like to focus on one area: developing and deploying secure web-based applications. To handle this task, it’s helpful to break down the process into five different areas.

Developer training

In addition to offering security awareness training for all new employees — and an annual refresher — the engineering team should receive regular training on how to code securely, what to watch out for, and how to use tools to help them test for vulnerabilities.

Numerous organizations that review security and breaches have created lists of top web application vulnerabilities, along with classifications of those vulnerabilities. These include exposure to cross site scripting (XSS), cross-site request forgery (CSRF or XSRF), injection (SQL and otherwise), clickjacking, failure to restrict access to resources, bad use of cryptography, and bad session management.

A great starting point for developer training includes the following four web sites:

• OWASP (Open Web Application Security Project) Top 10
• CWE (Common Weakness Enumeration)/SANS (SysAdmin, Audit, Networking, and Security) Top 25 Most Dangerous Software Errors
• WASC TC (Web Application Security Consortium Threat Classification)
• Cloud Security Alliance

The training should include descriptions of the issues, real world examples — in some cases from the web application itself (all fixed, of course) — and ways to address these issues.

Code review

In addition to the regular code reviews done by the development team, the person responsible for security (or the full security team, for companies lucky enough to afford one) should review and test code in several specific areas to validate that vulnerabilities have not crept into the code base.

These areas include the parts of the application related to authentication and authorization along with other vulnerable areas, including database access, input and output, and use of cryptography.

(Pro tip: always use standard implementations of strong cryptographic algorithms; you’re not smart enough to write your own.)

The engineering team can also use a number of tools to help uncover issues.  Depending upon the company’s budget, this may include commercial tools such as Veracode and Burp. There are also a number helpful open source tools such as Findbugs, OWASP Zap, and a free version of Burp.

Internal testing

QA teams should perform a set of security tests on each release (automating as much as possible) to validate that vulnerabilities do not find their way into the application.

To keep track of potential vulnerabilities, organizations can set up a ticketing system to keep track of all security-related issues. This keeps the company aware of all vulnerabilities and helps ensure that security problems are resolved as quickly as possible.

External testing by security vendors

Internal testing alone won’t stand up to today’s threats, which is why organizations need outside validation of their security. External audits, ISO certification, and third-party penetration and web application vulnerability tests are crucial to confirming that sensitive data remains protected.

These third-party tests should be done on a regular basis — or done continually if possible. At a minimum, these tests should be performed whenever there is a significant change to the code base.

There are many vendors that can test the security of an application. Vendors that I have used include Cenzic, WhiteHat Security, and Veracode.

Cenzic and WhiteHat Security do vulnerability testing via the front door (manual and automated). Veracode scans the application layer to look for vulnerabilities. These two types of testing complement each other.  The front door tools can quickly try out known vulnerabilities and record how your application reacts. The code scans look at how all input data is processed and how this data drives the output.

These tools are particularly good at finding places in the code where output is not being properly escaped (potentially allowing XSS) or being built up incorrectly (for example, HTTP header splitting). They also help find issues related to the incorrect use of cryptography (for example, using bad random number generators). Code scanning tools can find a wider range of possible issues, though there is also the expense of also having to review the false positives that they may generate. Other vendors, mainly consulting firms, can be employed to do manual vulnerability and penetration testing on a regular or ad hoc basis.

Staying up to date

Security personnel and other top IT staff should stay abreast of new security issues by monitoring security sites, blogs, social media, and email lists. Hardware and software vendors, security providers, governments, independent experts, the security press, and hackers all have important insights to offer.  A few places that I like to review are:

• United States Computer Emergency Readiness Team
• Schneier on Security
• Krebs on Security
• A Few Thoughts on Cryptographic Engineering
• Internet Storm Center Diary
• Dark Reading
• The Hacker News
• OWASP

Attending local security meetups (for example, many cities have a B-Sides group) is a great way to stay up to date. I personally like to attend DEFCON, but that’s not for everybody.

Security is a never-ending process. Enterprises must remain vigilant as new threats continue to emerge. Make improvements to the security infrastructure early and often to best protect customer data.

Rick Spickelmier is the CTO of Birst, the leader in Cloud BI.