With more than $32 billion in reported cyber-security losses in the U.S. alone last year (and with unreported losses likely to be equally huge), there should be no doubt that cyber crime is a serious problem. It’s no wonder; more than 70 percent of all websites contain critical security flaws, making them easy targets for professional and even amateur hackers.
As a security professional, I have come to believe that Americans accept the inevitability of breached IT environments and compromised computer systems. And they do it unnecessarily.
This article explores a major cause of the security nightmare – a surprising lack of contractual security obligations between companies and web developers – and looks at an often overlooked approach to software development that businesses should consider to avoid being at the mercy of hackers.
Questions that Never get Asked
One of my favorite security axioms is:
Corporate websites are open to security breaches because security was considered as a basic requirement of the development effort.
Or, said differently:
You have a security-flawed website because you never asked for a secure one.
I will back up my truism with twin facts. First, in my many years of software development, only one client has ever asked about security. To repeat: only one client has ever asked how we were going to secure his web application against hackers. I’m not sure what the others expected. Second, industry studies suggest the percentage of new web applications built in the last year that are security-flawed continues to hover around 70% – ironically, the same percentage as websites that were built when security was not part of the security media circus we see today.
If companies never think about security when building new web applications and the percentage of newly created insecure websites continues to hold steady, then the second half of this failure must come from the software development teams that are tasked with their creation.
Protecting One’s Own Interests
Organizations hiring web development firms must realize that unless a security-focused contractual relationship exists between themselves and their web application development team, the probability of ending up with a secure web application is almost zero. It is in the best interests of any company to put a high priority on security from the outset of any project. Even if liability might fall on the web application development firm in the event of a security breach, that breach could still cost the client company lost time and money during recovery.
A solid contract focused on security will keep both parties’ interests protected and ensure a good working relationship from development to launch and beyond.
The Corporate Side Contract
In my experience, there is a soft line between the contractual relationship surrounding a software development agreement (sometimes called a Master Services Agreement, MSA) and the requirements of a specific software development project (sometimes called a Statement of Work, SOW). Rather than feign legal expertise, I will leave the placement and wording of the security needs below to the legal experts.
The security needs that should always be considered in any web application development contract are:
• Best Practice Security Standards – All developed software must adhere to security best practices in accordance with policies set by worldwide organizations such as the Open Web Application Security Project, OWASP. These standards are, for the most part, concise definitions of good software development practices that experienced developers should already have incorporated into their daily routines. This expectation should not introduce any additional cost or time into the development effort.
• Third Party Review – The final, delivered software product must pass a comprehensive third-party security review, including an industry-recognized automated web vulnerability scan. The detailed results of this review and scan must be included as one of the specified deliverables. All critical security flaws must be fixed before delivery, and all medium severity security flaws should be triaged to determine which, if any, must be repaired before final delivery.
This requirement is triggered by another of my favorite axioms: Untested software is security-flawed software. Software hackers are well funded, motivated by the huge potential profits, and as technically clever as even the most accomplished software developers. Without automated vulnerability scans, manual security checks and code reviews, it is almost impossible to determine which of the literally thousands of attack methods might breach any given web application. The cost and time associated with this requirement should be considered just the cost of doing business in the world of web application security.
• Encryption – All web application databases must encrypt sensitive data using current secure and industry accepted encryption algorithms. Even with the best of safeguards, hackers will often find a way to compromise an IT system and steal the underlying databases. The best secondary defense is the encryption of all sensitive data such that even if it’s stolen, the hackers cannot read the data.
A recent example to reinforce this concern: A business maintains a login-protected database where customer passwords are not encrypted. When asked about this potential security problem, the customer indicated the current development company did not see a need for password encryption because the website did not contain any sensitive information. True, but what the client and development company both missed was that more than 50% of all Internet users reuse the same password for all their Internet accounts. Thus, a stolen login credential pair (email address and password) will be used on all major financial and ecommerce website accounts (PayPal, eBay, Schwab) with a high probability of access to at least a few of those accounts. My client was unwittingly putting his entire customer base in jeopardy. Beyond the legal issues surrounding this situation, the public relations fallout if this became a known issue would be dire.
Encryption should not introduce any significant cost or time into the development effort.
• User Protection – Web application development specification should include at least the following:
o Robust and strong password requirements (length and complexity) that include protection against brute-force password hacking attacks.
o Multi-layer user permission systems that prevent low-level employees from accessing sensitive information or modifying the web application.
o SSL protection on all web pages that exchange sensitive data with the application’s server.
Websites are often layered such that the initial public-facing pages contain few, if any, attack surfaces. Web pages that are beneath customer and administrator logins are often less secure (with more attack surfaces) because of an implied trust factor; if the user has a login, he or she must not be a threat.
In addition, websites, particularly promotional websites, often intentionally give administrative users the ability to modify the web application or database itself.
My position on user access security is this: Give out administrator rights on a strict need-to-view/update basis, and for robust login access, make sure an absolute need exists.
An example to stress this: I worked on a large credit union brochure website a few years ago. I use the term brochure site here because the site was purely promotional – happy families, great rates, etc. The site contained just a few attack surfaces, such as search boxes and a blog comment feature, that were easily secured.
As with most financial institution brochure sites, this one had bold buttons and links to the credit union’s customer account portal. Therein, of course, lies the problem. Any hacker with access to the credit union’s website source code could easily redirect the customer account portal link to an identical-looking website that would be under the control of the hacker. Even allowing a low-level staff member full access to CMS (Content Management System) functionality might give a hacker just the opportunity he or she needs to redirect the customer. Then, once customers entered their banking credentials, they would be presented with a screen indicating the “site” is down and to come back in a few hours. Meanwhile, the customer’s stolen banking credentials would be used to transfer monies to the hacker’s off-shore accounts.
The point of this example is to show that this seemingly low-risk website was anything but low risk. This is where web design companies get caught all the time – they spend endless hours on the aesthetics of a promotional site and miss that a potentially devastating redirect of the account portal might be possible. Robust login requirements are now standard practice and should be included as such. Not surprisingly, multi-layer access permission systems are sometimes complex and expensive, so this is one requirement I would leave as a negotiation point between the client and development company. Smart and effective use of SSL protection just requires common sense and should always be implemented.
Cyber Security is Within Reach
Web application security is not magic. It requires serious effort, but it is no less attainable than any other component of a custom web application. No application, however, can be truly safe if security is an afterthought of development. Security might seem basic and mundane, but as with all aspects of an application, you will not get it built into your website if you do not request it. Without a contractual relationship that includes security clauses, security will almost never be achieved.
Generally, standard software development contracts have been in place for many years and are easily obtained through corporations, software development companies, or their respective legal representatives. However, such contracts taking a security-aware approach are so rare that I can honestly say I have never seen one (outside of my own) and never, ever had a corporation or attorney speak to me about one.
As IT security becomes a major focus in our world, it is essential that corporations and development companies alike demand web application security at the contractual level. While hackers are happy to let us continue with our ‘plausible deniability’ approach to life, financial and reputational penalties continue to grow and make a proactive approach to web application security a must.
Disclaimer
I do not have a legal background and apologize in advance for legal terms or concepts I may have inadvertently mangled. My hope was to provide a conversational starting point for software development contracts that adequately address security. I leave the construction of these actual contracts to legal professionals.
