In an effort to boost sales and generate revenue, one U.S. multinational energy company recently embraced the Internet to bolster external communication and internal collaboration.
In addition to creating a corporate web site, the firm deployed hundreds of intranet applications for procurement, expense reporting and other processes. Numerous departments and branch offices worldwide also set up specialized web sites for partners, customers and even project management.
Though the company has achieved its strategic goals for the web, by leveraging valuable communication and management tools that lower costs and streamline processes, it has, unwittingly, set itself up for malicious intrusion. The decentralized and ad hoc intranet application deployment has created a fragmented, multi-platform mosaic that raises important security questions (see boxout below).
Clearly for internal or external web applications, security is the biggest concern today. The dramatic number of attacks is expected by CERT to double again this year to almost 100,000. It is estimated by Gartner Group that as many as 70 to 80 percent of these attacks are coming in through ports 80 and 443, commonly used by web applications. Such attacks can be costly and detrimental to corporate credibility. Privileged customer, financial and operational information or valuable intellectual property can be damaged or stolen during the average hacker intrusion of 15 minutes or less. The average loss is more than $2 million among those willing to quantify losses, according to an FBI/CSI survey. Downtime alone can potentially cost tens of thousands of dollars per minute. "There is much more illegal and unauthorized activity going on in cyberspace than corporations admit to their clients, stockholders and business partners or report to law enforcement. Incidents are widespread, costly and commonplace," the survey concluded.
Danger From Within
Although the media focuses on external attacks, it's estimated that 'insiders' (employees, partners or contractors) perpetrate 50 percent of all hacks. Insider attacks can be purely malicious. Verizon was a recent victim of malicious hacking, via an employee who eventually pleaded guilty to intentionally sabotaging computers at a network support center. Damage can also result when sensitive information such as salaries, intellectual property or financial data is accessed inappropriately.
Such breaches often come as a surprise because most managers believe that their internal systems are safe from hacks. After all, systems reside behind a corporate moat consisting of firewalls, IDSes, access control solutions and other safeguards. In reality, however, intranets represent a cyber Trojan horse. Outside threats can use intranets as a potential back door into corporate systems and can also provide employees or "insiders" with an easy path to unauthorized data.
Intranet security gaps are most commonly a result of a combination of firewall and IDS limitations, poor application development and deployment practices, and widespread accessibility. Network devices such as firewalls and IDSes offer little or no protection at the application layer. They are unable to verify requests made through ports 80 or 443, which are kept open for HTML and HTTP communications.
More critical, however, is the lack of management oversight and safeguards. In many cases, intranet applications are developed by outsourced contractors (or even employees). While they may know HTML well, they are likely to have minimal knowledge of corporate security practices. This lack of knowledge is compounded by a lack of information about web security imperatives. As a result, developers will often trust users interacting with the application, fail to religiously validate input streams, encrypt passwords, enforce user access rights or control database access and retrieval.
Unfortunately, most enterprises do not realize just how easy it is to hack intranets that lack appropriate security. Hackers can crash servers using a multitude of methods, including buffer overloads or other techniques, to gain insights into database and application structures. Cookies that encapsulate application states can be manipulated for unauthorized access. Even the viewable HTML source code offers insights about hidden fields or file structures.
The biggest vulnerabilities probably result from widely available third-party CGI scripts that enable web servers to access databases or transactional systems. By manipulating a CGI script, internal or external hackers can instruct servers to send password files or configuration information, reply with inadvertently revealing error messages, or even establish telnet sessions for data downloads.
Widespread deployment and accessibility compound the inherent security weaknesses of many intranets. Not long ago, only a trusted few had keys to the corporate data center. Now, intranet usage is as much a part of corporate routines as sending email. Employees and others who are allowed behind the firewall can use intranets to check benefits, inventory levels, order status and other activities. In an unsecured intranet, anyone with privileges to access a 401(k) holding can also potentially dip into R&D files with a technique as simple as URL manipulation. A hacker outside the firewall can also leverage poorly secured intranet servers to execute cross-site scripting attacks on other network servers.
A Three-Pronged Strategy
Securing intranets requires a three-pronged approach that treats intranet security as rigorously as Internet security. The first step is to gain control over widely deployed web sites through comprehensive security policies. These policies must not only dictate who can produce and update web sites, but also address who can access information. Effective policies must also cover programming. Usage of non-validated CGI scripts should be banned, and database access limited through proxies or similar techniques. Such policies should be reinforced with education.
Next, all aspects of security, from firewalls to data access, must be audited. Effective audits include both the logical and physical networks, and should address IT practices, policies and procedures.
Finally, complement existing security measures with a web application firewall. Located on the data path, this will analyze upstream and downstream HTTP and HTML packets. By analyzing this traffic in real-time, the firewall can block malicious or inappropriate traffic from reaching web, database and application servers.
A web application firewall adds intelligence to security. Instead of just looking at packets, it creates an application analysis by parsing the HTML, recompiling application logic, and analyzing the form data and code. Information is stored for comparison when the request returns from the user. The data store in the application analysis is used to analyze web traffic legitimacy.
The multiple benefits from a web application firewall are substantial. Most important, it ensures robust protection. Harmful - or even questionable - activities using web protocols are blocked before any resources are affected. This eliminates the potential harm from data or logic content attacks, and other attacks that focus on files or hosts. For example, a web application firewall could have easily stopped the Nimda and Code Red viruses, which propagated through abnormal server requests, without any prior knowledge of the attack pattern.
Web application firewalls extend protection to applications inside and outside the firewall. These include e-commerce and corporate web sites; intranet deployments, including HR, project management and intellectual property; and supply chain and partner extranets. A web application firewall even shields vulnerabilities in Microsoft's IIS, embeddable 'shopping-cart' applications and other third-party software.
Web application firewalls also allow network and security managers to proactively address current and potential threats. Today, IT managers are caught in cycles of patch installation and signature/pattern updates, which themselves are prone to error. But a web application firewall can detect and block attacks before patches are even available, allowing the IT staff to proactively patch in an orderly and controlled manner.
A Unified Security Model
Currently, network and security managers are waging war with complexity. Heterogeneous networks and even security devices offer cracks that determined hackers can slither through. Employee change, network reconfiguration and user indifference make it difficult to enforce security policies.
The IETF has begun work on the standards that will form the backbone of a unified security architecture; however, results are years away. In the meantime, companies need to follow in the footsteps of enterprises that understand the vulnerabilities from uncataloged intranets. They should establish policies that reduce security risks, and put in place web application firewalls that keep external bad guys at bay - and internal good guys honest.
Abishek Chauhan is CTO and co-founder of Stratum8 Networks (www.stratum8.com).
Ten Key Questions for Intranet Web Security Managers
1. Can you accurately count the number of intranet applications and
web servers in your organization? Do you have an accurate
inventory of what is being published on these sites?
2. What security protections were incorporated during the web
application development process? Are CGI scripts and other
programming shortcuts validated for security protection? Are
there any consequences for non-compliance?
3. What databases do these applications access? Has any of the
code linking to back-end databases been outsourced to a third-
party web developer or employed downloaded code?
4. Have your internal web development staff been updated with the
latest knowledge in web application security? Would they know
what buffer overflows, cross-site scripting attacks or cookie
tampering are, and how to prevent them?
5. Have security audits addressed intranets as well as extranets?
6. How much time do IT managers spend on administering security
issues like patches and updates?
7. Have employees signed agreements concerning access,
intellectual property and security issues?
8. Is your security architecture layered? Do you have multiple
stages of protection against internal and external attacks?
9. Is all your hardware and web server software configured
properly, and not just on default settings?
10. Can you accurately audit your system and report on the last
100 hacking attempts (yes, there have been - guaranteed!)?