This isn't new but I've wanted to post about this for a while now. With the popularity of iPods, a new threat emerges...less specifically about iPods and more about the fact that storage devices are increasing in capacity and decreasing in size to the degree that this becomes a real challenge in keeping company confidential data secure. This trend has significant implications to data theft in the enterprise.

Check out the article on "iPod Slurping"

http://news.com.com/Beware+the+pod+slurping+employee/2100-1029_3-6039926.html

Will the challenge of securing data never end?

Posted by andreyee in Odds and Ends | Permalink | Comments (1) | TrackBacks (0)

The identity theft of 26 million U.S. veterans and spouses has sparked debate and numerous investigative meetings. That significant data breach will cost us taxpayers over $100M to notify the affected parties and offer credit protection against potential abuses.

You might be thinking that this compromise of privacy information is a rare occurance or a red herring but in fact, this is merely the latest and best publicized incident in recent history. To get a better view into the number and frequency of compromises look at the record and chronology of these events at http://www.privacyrights.org/ar/ChronDataBreaches.htm

Furthermore at the time of writing, the www.privacyrights.org hadn't yet updated to include this latest faux pas.

http://www.cio-today.com/story.xhtml?story_id=111003TREALO

When will organizations get serious about security? Who knows? Unfortunately, it often requires unfortunate incidents like the Veteran's Administration debacle to spur change. I'm not usually in favor of legislating our way to security but laws like California's SB 1386 legislation need to become nationally adopted. SB 1386 holds companies legally and financially responsible for communicating to customers should information held or stored about any California resident be violated. It's created the necessary incentive for at least some organizations to take seriously the stewardship of privacy data.

Meanwhile companies need be responsible to act before they get acted upon.

Posted by andreyee in Privacy/Information Theft | Permalink | Comments (1) | TrackBacks (0)

Attacks on Web Services are often targeted at XML based content. Here are some of the more significant XML based attacks:

Recursive payload attack - the attacker takes advantage of the nesting supported within XML. One of the strengths of XML is its ability through nesting to efficiently address complex, hierarchical relationships between data elements. With the recursive payload attack, an XML document is created with very deep nesting of data elements, thousands of elements deep or where the nesting is recursive. Many of the older XML parsers would choke on this, essentially leading to a denial of service.

Jumbo Payload attack - Essentially exploiting a poorly written parser that is unable to process an exceedingly large XML document leading to a denial-of-service. This has become less of an issue as parsers, are now better able to handle larger payloads and have the correct exception handling if the document is too big.

XQuery Injection - An XML variant to the SQL injection technique. XQuery is a language designed to permit querying and format XML data. An attacker may inject XQuery as part of a SOAP message causing a SOAP destination service to manipulate an XML document incorrectly.

XML Morphing - Involves changing/manipulating XML docs into a form that XML processor cannot handle.

WSDL Enumeration - Web Services Description Language is used to describe the services and how to engage the methods for these services. By enumerating and parsing through WSDL , someone could get info about other methods that may have restricted access or a deduce how to compromise a service through a backdoor unpublished method.

Schema Poisoning – Modifying the schema referenced by an XML document in a manner that is inconsistent with the document - causing the processor to choke on the document.

These are just a sampling of XML based attacks that can be perpetrated against your web service deployment.
Here are a couple of steps to take to protect against such threats.

First, validate and version control XML Schemas. Second, encrypt XML content. Third, inspect incoming and outgoing XML through use of XML based firewall or IPS equipped to handle such inspection. It's not foolproof but it's a start toward better security for web services.

Posted by andreyee in web services security | Permalink | Comments (0) | TrackBacks (0)

Another consideration for protecting service based architectures is the issues related to transactions. The appeal of SOA is the benefit derived in enabling inter-enterprise transactions. However, this raises a number security related issues to consider. I'll just touch a couple here.

1. Inter-enterprise transactions may traverse intermediate segments that are untrusted. For instance, an insurance broker will provide best quotes by querying partner insurance companies. In this process, the requests to multiple partner companies may traverse untrusted segments, either at the partner's site or through the service providers' network.

Proposed Countermeasure: Audit the entire business process, not simply the enterprise entity. Also, use SSL for the transport layer and encrypt XML at the message layer.

2. In a multi-hop transaction, what is often neglected is the security of transient data at intermediate points. Attention is often given to secure applications, databases, etc... but not transient data found in persistent message queues or temporary cached files. These can often expose vital proprietary info or provide information that may lead to other exposures. It's the hidden, back door of web services security and we need to pay attention to it.

Proposed Countermeasure: Audit the intermediary sources of transient data such as persistent message queues, config files, caches. Enforce encryption for the transient data if possible (it isn't always possible).

We'll get to XML based attacks next...

Posted by andreyee in web services security | Permalink | Comments (0) | TrackBacks (0)

The problem with securing web services isn't all about XML...it's also about the unique challenges brought about by distributed service based architectures. Here's just a couple of issues arising from distributed web services architecture -

1. Multiplication of open interface points - in a "simple" monolithic web app, the primary interface point into the application is through the user interface. Hence, many common attacks against those older simple web architectures would be driven through the web based interface such as SQL injection where a SQL command is appended into a web form field entry with the hope that it would be inadvertantly executed and valuable info from the database would be retrieved. In a distributed service based architecture, the problem is increased because of the multiple interfaces that can be potentially attacked. The very strength of a SOA based application becomes a challenge with regard to security. Each service component would have mutiple interfaces or published methods that may be exploited by a malicious attacker.

Proposed Countermeasures:
Comprehensive testing and code reviews from a security perspective isn't just helpful, it's essential. With an SOA, the scope of that tasks can be much larger than expected but web services application developers and security managers need to collaborate on this. Also, creating internal trust zones where critical services are grouped and locked down is a deployment best practice. Creating these zones by grouping similarly typed services and then locking down and applying appropriate defense measures from a intrusion prevention, firewalling perspective is helpful.

2. Protecting internal resources while exposing enabling cross enterprise transactions. The issue here is challenge of enabling services to legitimate external partners/users but still maintaining a measure of protection for internal service components. What often happens in many SOA deployments is that over a period of time, the number of services that are exposed to be externally facing increases and the overall security for a number of internal resources become vulnerable to attack.

Proposed Countermeasure: Create a broker/proxy service that will act as a "traffic cop" for legitimate external requests...the requests will be brokered by this service to the appropriate internal service component. This enables legitimate outside requests to be fulfilled but creates an abstract layer of protection for potential malicious outsiders. Vital resources are protected and it stops the creep of exposing more internal service components directly to the outside world.

The bottom line here is this - XML isn't the only security issue for web services architectures...you need to consider the architecture issues as well.

Posted by andreyee in web services security | Permalink | Comments (0) | TrackBacks (0)

Much of the discussion around web services or SOA security tends to revolve around enabling SOAP messaging security in the form of WS-Security and other standards. Far less has been written about the notion of protecting your web services architecture from potential threats. When you consider securing this service oriented world we are intentionally engaged in from a technical perspective, we start to realize how challenging threat protection can be.

Threat protection of a distributed web services environment is exponentially more difficult than your traditional tightly bound, monolithic web app. You have to consider protecting web services architectures at three levels:

1. Architecture
2. Transactional
3. XML Content

Much of the discussion is relegated to (3) without consideration to (1) to the detriment of security. Let's examine how architecture plays a role in changing the rules of threat protection.

Posted by andreyee in web services security | Permalink | Comments (0) | TrackBacks (0)

As web applications increased in sophistication, potential exploits evolved in complexity as well. Here is a sampling of the threats that are often perpetrated against these applications:

SQL injection - where an attacker would append SQL statements to an entry in a web based form to take advantage of a possible coding flaw whereby the SQL statement would inadvertantly be executed. The SQL statement would then yield valuable information from the web application database.

Cookie manipulation - the attacker manipulates parameters of an existing or harvested cookie to gain access and compromise a system

Cross-site scripting where the server processes a malicious script, leading to web defacement, cookie harvesting or other generally bad stuff.

Other threats that assail newer web applications include XML based attacks that target the applications ability to process malformed or non-conformant XML documents.

How does one protect against these threats from an enterprise security perspective?

Conducting regular security audits and building a "defense-in-depth" approach to your security architecture are important ingredients to any secure enterprise. It is important that security audits include code level inspection of your web application to ferret out command injection or buffer overflow vulnerabilities. However, specifically to web application security, one should supplement with XML inspection conducted either as part of an XML firewall or an IPS that has incorporates that capability.

While doing the above will allow your security administrator to sleep easier at night, it doesn't necessarily mean that you're equipped to make the transition to securing your web services architecture.

Posted by andreyee in web services security | Permalink | Comments (3) | TrackBacks (0)

To examine web services security today, let's take a little survey of the security issues related to the first generation web application model. This model was typified by thin-client/server HTTP communication with a tightly coupled server side is comprising of a web server, scrpted business logic and database. This first gen web application model is in many ways, still the most prevalent today.

Inital attacks against this model were primarily denial-of-service exploiits that exposed web server processing vulnerabilities. Other attacks included buffer overflow exploits such as the highly publicized Code Red which took advantage of a vulnerability in the Microsoft Index Server.

In those early days of web application security, installation defaults were often a source of vulnerabilities. Unsecured critical directories or elevated privileges were sometimes left exposed after installation. Diirectory traversal attacks where an attacker would look for open, available directories with execute privileges were often an effective way to compromise a system. With the attention given to security these days, it is unlikely to have installation defaults exposed in this way but it used to be far too prevalent.

As web applications became more sophisticated, the attacks likewise became more complex as well but I'll tackle that in my next post.

Posted by andreyee in web services security | Permalink | Comments (0) | TrackBacks (0)