Back to newsletter
Heads in the Sand
Beware of a false sense of security
by Barbara Morris, Editor, Secure Software Advisor
In a recent online survey by Zogby International, many business decision-makers revealed a shocking conviction that their companies were impregnable to security breaches, despite underlying concerns about hacker attacks. While 34 percent have no tools/procedures in place to detect identity fraud, 44 percent believe that a security breach would have minimal to no financial impact on their business.
|
Complimentary White Paper
Ten Questions You'd Better Ask to Be Sure Your Company's Assets are Secure
Today’s business infrastructures rely upon software applications to manage corporate assets, automate critical business process and store private information. And most applications today contain security vulnerabilities that can be exploited for profit or malicious use. That's why most hackers today target the software, not the network infrastructure, in their attacks.
What can you do to be certain your company's software -- and assets -- are secure? Start by asking TEN essential questions.
Download this complimentary white paper.
|
Rob Rachwald, director of product marketing at Fortify Software, likens this head-in-the-sand mentality to the attitude of the U.S. Army toward tank warfare before World War I. Back then, the Army considered tanks as ineffective and unproven battlefield weaponry, thinking a traditional horse cavalry would do just fine. It took the legendary persistence of (then) Colonel George C. Patton to push mechanized warfare. The rest is history.
Preparing for the worst
But today's worsening economy will only increase security attacks because hackers will look even harder for critical data, such as personal information they can sell. Hackers can bring down an application or take control of it, and they're not afraid to go after the big guys -- online banks, government agencies or munitions companies. But they also like the little guys who don't have the resources to put up an adequate defense.
Rachwald adds, "People have a false sense of security in the old technologies such as firewalls and antivirus software. Sure, you need the traditional methods of protection, but you also need to look at the new modes of attack, especially against applications." He notes that in the past two years, 33 percent of cyber attacks on the U.S. Air Force were at the application level. Gartner estimates that 75 percent of hacks are against applications -- while NIST puts the number at 92 percent.
Rachwald explains how developers can address three major concerns:
-
Secure "old" apps. Design is a big issue. Many applications were built a long time ago, even before HTML, and are susceptible to breaches. Be sure these apps are secure.
-
Think like a hacker. Many developers don't have the mindset that hackers have; they're not thinking about how to break an app. Developers need to think like hackers in order to understand where the vulnerabilities lay. "Abuse cases" have to be added to the usual "use cases" on the to-do list.
-
Input validation, input validation, input validation. Is there a basic tenet of application security that few follow? It's input validation. And a lot of developers just don't do that. This simple step can help stop many basic -- and common -- attacks, including SQL injection, cross-site scripting or buffer overflows.
Benchmarks in security best practices
In 2002, Microsoft Corporation's Chairman Bill Gates sent an email to his employees, setting new best practices for the company. Gates wrote, "When we face a choice between adding features and resolving security issues, we need to choose security." Microsoft has long been known as the number one vendor of software vulnerabilities, focusing more on developing new features and letting consumers deal with the security issues with cumbersome patches and antivirus software.
While Microsoft may have finally come around to making security a priority, not all software development firms heed the call. Rachwald offers an analogy with the automotive industry to clarify how the security mindset has to change. U.S. auto manufacturers are known for assuring quality at the end of the design process, while Japanese manufacturers always consider quality at the beginning of the process; thus, Japanese cars have outsold many U.S. brands by offering better products at lower prices.
Rachwald adds that current U.S. application security practices are the most vulnerable and least understood risk in companies today. However, a recent survey conducted by Fortify Software in April showed that over 81 percent of the employees of 300 IT companies know that the software they use is vulnerable to hackers.
In March 2008, European information technology analysis group QuoCirca published several key findings regarding application security:
-
Web 2.0: Exposure to Web 2.0 technologies, an insecure technology, is high, and users do not fully understand the vulnerabilities.
-
SOA: Organizations expose their applications to security threats through use of service-oriented architecture (SOA).
-
Outsourcing: Outsourcing of code development is widespread but fundamentally insecure, as organizations don't mandate security when outsourcing development.
For extra protection: automate and integrate
While the QuoCirca report found that all the above practices expose businesses to greater threats, it also found that organizations using automated tools to ensure security at an early stage in development could significantly reduce the risks of successful attacks. In addition, using automated tools to build security into software development cycles translates into lower spending on IT security in the long run.
To build security in the design and development process, Rachwald offers suggestions on how to go about the process:
-
Architect security first. At the macro level, you must architect security to reduce entry into data. If you compare two contrasting operating systems, say, Linux and NET Brute Force Detection (BFD), you'll find that in Linux there are lots of open calls to the Internet, while BFD allows only 100 call-outs.
-
Integrate security in processes. IT can build security by mandating processes that integrate security proactively throughout the development lifecycle. This could include relevant non-coding activities, such as threat modeling and the development of abuse cases. Perform static analysis in development, and perform dynamic analysis during quality assurance (QA).
-
Put countermeasures in place. Developers usually design software as a use case rather than trying to figure out abuse cases. You need a security expert who can understand what the bad guy does and who can design in countermeasures.
-
Training is important. One large bank reduced vulnerabilities by 25 percent by training its developers. Be sure to train developers in the previous processes. You'll get management's buy-in if you give them logical reasoning.
Finally, Rachwald suggests that developers read Fortify's Secure Programming with Static Analysis, which explores secure coding practices in depth.
As people bring more sophisticated business and Web-based applications to market, developers and architects need to keep security in mind from the beginning of the development process. The head-in-the-sand attitude just isn't working any more.
Barbara Morris is an InternetVIZ editor and freelance writer based in New York City.
| 
