Are XML Gateways Really the Answer?

Posted in SOA, Security by AST on Thursday, June 1st, 2006

Based on some discussion about Web services security on the service-orientated-architecture yahoo group, I decided to dig a little deeper into what XML gateways would actually be good for in a large-scale environment. We don’t use them in Reach because we have implemented some of the same functionality as part of our message delivery framework. In theory, we could use something like an XML gateway instead, but I’m not really convinced. For a lot of readers, some of the introductory material may be a bit remedial, however this detail is relevant to the rest of the discussion and I want to make sure everyone is starting from the same place.

XML gateways do have some desirable qualities, however, if you apply them in the the right way. This article attempts to look at some of the considerations for using an XML gateway in an SOA based on a very brief top to bottom view of how they might be deployed in real life. And, no, this article isn’t talking about any particular project, living or dead that I have worked on. Any resemblance to an actual project is purely coincidental.

The Theory

The theory of the XML gateway is that since firewalls allow arbitrary XML documents through without question on port X (probably 80), wouldn’t it be really great if there was something that could sit in the way and do the same sort of thing for XML documents that a firewall does for TCP/IP packets. I’m not going to go into the gory details of XML firewall vs. XML gateway as I’m sure you can use Google at least as well as I can. I’m going to focus on XML gateways for the rest of this discussion.

According to several of the XML gateway vendors, the typical deployment diagram looks something like Figure 1.

Figure 1: Typical XML Gateway Deployment View

A Dash of Reality

The view in Figure 1 is great for marketing slides and to explain the general concept, but it hides a lot of important aspects of how it would be deployed in a more complete environment. A more typical, non-trivial enterprise deployment of an XML gateway might look a lot like Figure 2.

Figure 2: Augmented XML Gateway Deployment View

While the diagram in Figure 2 is still far from complete, it serves to highlight some of the issues to consider when attempting to apply an XML gateway in your environment. I’m going to discuss some of the key aspects in Figure 2.

1. Secure the Transport Layer

   Any Web service serious about security will require some sort of secure communications channel. Normally, this is accomplished using HTTPS. Depending on the strength of your security model, the requester may also need to present a client certificate to authenticate themselves to the server in addition to the client’s validation of the server’s certificate. While this can authenticate the requester, at this level, it is used to validate the identities of both ends of the communications channel.

   Figure 2 illustrates this secure channel from the requester through the external firewall and into the Content Services Switch (CSS). Many environments have a security policy which prohibits encrypted traffic originating outside the front-end firewalls from being transmitted within the infrastructure. This is normally required so that things like network intrusion detection devices (NIDS) can scan all of the packets transmitted within the rest of the network. Obviously, if the channel is encrypted, it will be impossible for the NIDS to check for anything useful.

   Once the CSS has terminated the SSL/TLS channel, it performs load balancing and forwards the request to a selected front-end web server. The CSS is also responsible for detecting fail-over requirements in the event that one of the web servers is unavailable.

2. Authenticate the Requester

   In the likely event that the site is hosting both Web services for humans and for machines, a common deployment pattern is to have some sort of plug-in agent on the front-end web servers which intercepts all of the incoming URLs to see if the requester is authorized to access them. If the requester doesn’t have an authentication context, these plug-ins typically redirect to a credential service so that the entity on the other end of the channel can authenticate themselves. If there is a human on the other end of the channel, they may be required to present some sort of personal credentials like a username and password for authentication to a web application or portal even if the channel they’re using has been established using 2-way SSL. If there is a machine on the other end of the channel, it may be required to authenticate using its client certificate, or it may simply use HTTP basic authentication, depending on the service’s security requirements.

   Once the credential service has authenticated the requester, they are redirected back to the original target URL and the authorization check is performed again. If the requester is authorized, they can access the resource; if not, they are redirected to either the credential service or a “no access” page.

3. Web Server Redirect

   Since the web servers have the request, they may be responsible for determining, based on the URL, if the request is for a human facing or a machine facing service. One option is to route all of the machine facing service requests through the XML gateways (using some sort of load balancing scheme) and route the human facing service requests directly to the portal servers (most likely relying on application-server-specific plug-ins “stacked” in the web server to provide fail-over at the application server layer.

4. XML Gateway Processing

   It is assumed that the XML gateway will perform the following tasks on the requests it gets at the very least:

   • Virus checking of all Base64 encoded string literals within the message
   • Checking the document for well-formedness
   • Perform some sort of load balancing between the Web service servers

   The rest of the capabilities of the XML gateway may or may not fit into the overall architecture of the solution. Reasons this may be true will be discussed in subsequent sections.

5. Establish Appserver Security Context

   Regardless if the requester is accessing the portal or a machine is accessing a Web service, the container providing the service needs to establish some sort of security context for them. This may be desirable for simple things such as portal personalization, but, more critically for security, it may be necessary for implementing role-based access controls (RBAC) to control the services available to the requester and to limit what data they may access. This discussion is going to avoid considering mandatory access control (MAC) models used in high security environments because the majority of non-governmental or military systems will be using a RBAC security model.

Things that Make You go Hmmmm…

There are a few things about the above scenario that seem pretty logical at first glance, but, if you think about them for a moment, you’ll notice that some important things are missing. Namely:

1. How does the client certificate get used to authenticate automated clients?
2. What kind of identity management system is being used to perform the authentication?
3. What kind of access control/policy mechanisms are in place and where are they located?
4. Are all of the Web service requests using SOAP?
5. What is the basis of establishing the security context for the application servers?
6. Should all traffic be going through the XML gateway?
7. Where does the CSS get the client certificate information?

What Are We Trying to Do, Really?

Like most things, in order to figure out the best application of security policies and procedures, and in particular, the XML gateway device which is what prompted this article, you first need to understand your environment and what you’re trying to do. This means identification of the security requirements. For this discussion, I think the following are fairly realistic security requirements:

• No encrypted traffic is allowed in the internal network if it originates from “the unwashed horde”
• All traffic on the internal network must be subject to in-flight intrusion detection and traffic analysis
• Sensitive customer data (like credit card numbers) must not be stored unencrypted (even in audits or application logs)
• Any changes to a message must be securely audited
• Each message received must be securely audited
• Each message sent must be securely audited
• Any malformed messages received must be reported
• Any meaningful service access requires authentication and appropriate authorization
• Automated trading partners must establish a secure communications channel using bi-directional, certificate-based authentication
• Messages may be relayed by external intermediaries, therefore cannot assume the “last hop” is the message originator
• Identity management must be centralized
• Security policy management must be centralized
• User communities between automated and human users must be segregated
• Internal server credentials must not be shared between service types
• User profile information must be stored in LDAP (including any security certificates and keys)
• No direct access to internal LDAP or database servers will be allowed to originate outside the secure zone

Just to make the problem a little more interesting (and life-like), the overall environment must be reasonably resilient to change in the services which are available. The business has a policy (somewhat like Amazon), that potential value-added services will be piloted, but there is no guarantee that they may eventually enter full production mode. This means that both the interfaces and the services available to both the human and automated users are subject to potentially frequent changes. However, there will be some business-critical services available to both human and automated users that are essential to the functioning of the enterprise (examples might be supply-chain management services, customer order tracking and other “boring” stuff like that).

Decisions, Decisions, Decisions

Regardless of your architectural philosophies for Web service design, there are a few things that whomever is putting together the final solution needs to take into consideration based on everything we’ve been discussing up to this point. I know that my own personal bias is different to what many people think is the “right way” to build Web services infrastructures, so I’ll try and keep my opinions out of this as much as possible and focus on the decision points.

First, a re-cap on the general capabilities offered by XML gateways. Essentially, the functionality is divided between content inspection and access control, but most XML gateway vendors also offer some sort of management functionality as well.

Some of the things that fall under the content inspection category are (courtesy of Vordel):

• HTTP header inspection
• XML denial of service detection
• XML external entity attack prevention
• SQL injection prevention
• Buffer overflow prevention
• Service scanning prevention
• Message size analysis
• SOAP attachment analysis
• XML well-formedness validation
• XML schema validation
• XPath processing
• Auto-generation of XML Schema (XSD) from WSDL
• Auto-generation of XML Schema (XSD) from sample XML messages

To me, the ones I’ve marked in bold are core functions related to XML handling while the others are either “helpful” (auto-generation of XSD) or they overlap with areas covered by other products. There’s a couple of these items worth discussing briefly, however.

SQL Injection Prevention

SQL injection is certainly a valid concern–if you’re doing direct SQL access with badly designed or non-existent data access layers. Let’s face it, if you’re using any kind of persistence framework (including things like Jaxor, Hibernate, TopLink, EJB and others) or you’re using prepared statements, you’re really going to not suffer too much from this type of problem. Normally, this is an issue when you have database code dynamically generating SQL using string concatenation like:

  String query = "select * from table1 where col1 = \"" + inputParam + "\"";
  ...
  rs = connection.execute(query);

But, of course, you wouldn’t do stuff like that, and a lot of SQL client libraries barf if you try and combine multiple statements using the semicolon anyway. If you want more, highly-accessible information about writing secure code, check out my friend Sverre’s book, Innocent Code.

That all being said, if you’re fronting services that you don’t know the security constraints of (and you’re insisting on exposing them to the world anyway), this type of thing may be useful. I’m sure things are better than the were in 2003-2004, but some of the reviews discovered that the pattern matching for injection techniques were pretty straightforward. Most probably wouldn’t take into account escaped Unicode characters or other potentially nasty ways around the obvious select, update, and delete SQL keywords. Also, following the rule of least privilege, you wouldn’t have your front-end code running with any more permissions than were necessary to actually perform the given task now would you?

Buffer Overflow Prevention

Buffer overflow is another often misunderstood security issue. Again, I’m not saying that it isn’t there and it isn’t a problem, but it helps to understand what a buffer overflow does. Briefly, it relies on the attacker knowing something about the platform and software running on the target environment. If either of those things are different than expected, the attack won’t work. Why? Well, the attacker encodes detailed assembly/machine code which is dependent on things like the processor architecture, stack size and the instructions being executed by the software with the vulnerability. If successful, the attacker corrupts the stack frame and causes the malicious code to execute.

Interpreted languages like Java, C#, Ruby, Python, Perl are not normally susceptible to this type of attack because it is very difficult to get down to the hardware (unless there’s a bug in the runtime interpreter). If you are writing your web services in C, C++ or any other language with direct memory allocation, or you’re passing parameters directly from an interpreted language to a library written in one of these languages, you may have a problem.

With this in mind, how does an XML gateway actually prevent you from buffer overflow attacks? Not being someone who implemented one of these things, I’m only guessing here, but one way is to do it based on signatures. This puts it in the same camp as virus checking and NIDS, which, as has been pointed out before (remember the Viking story?), there’s an inherent latency between when a new attack is identified and when the signatures are deployed on any existing devices. Maybe it’s more sophisticated than that, but I’m not really sure how else you’d do it, because there’s no way the gateway can know anything about your implementation language and software. This means something very important to anyone developing their own software: if you have buffer overflow problems in code you write, there’s no way for the gateway to know about it.

Of course, if an attacker tries a known sequence of bytes to get a shell prompt, that might be detectable and stopped, but maybe not. Ask your vendors if you’re serious about trying to address this problem, but you should really pay more attention to how your developers are writing code. Another book which goes into this particular problem a great deal is Viega and McGraw’s Building Secure Software.

Service Scanning Prevention

Depending on your background, there’s a few different interpretations to this one. Historically, a “service” was any program listening on a port, so if you wanted to see what attack possibilities you had, you could use a port scanner to detect open ports. As depicted in Figure 2, between the front-line firewalls and the CSSs, a port scan isn’t going to show you very much of interest. What must be interpreted from the context of an XML gateway is that it somehow protects you from discovery of the Web services you are offering, with the general idea being to limit your exposure window.

The effectiveness of this approach depends very much on the way you design your services. If you are using REST services (or WOA, to use the shiny new acronym), each service is just a URL, so, if you knew what you were expecting to see as an output, spidering a site may be a valid way to do “service discovery”. If you are deploying SOAP-based services in the MEST style, you are pretty-much in the same boat. Each URL will only support one operation, so your primary exposure is discovery of the URL. Finally, if you’re using “standard” WSDL-based SOAP services with multiple operations, the XML gateway may be able to do something for you. In any event, an external service requester doesn’t know anything about mappings which may be introduced at any of steps (2), (3) or (4) in Figure 2, so they only know that you’re exposing a service with a discoverable operation instead of discovering any interesting information about your network.

Stepping back a bit from the details, there’s another issue worth considering. Part of the whole 3-part puzzle of the original Web services architecture was: requester, provider and discovery. If you’re already publishing your WSDL on a UDDI or ebXML Registry/Repository somewhere that supports anonymous access, trying to use an XML gateway to “hide” your service endpoint information isn’t going to make a lot of sense. Also, if you require authenticated access (especially 2-way, certificate-based authentication), Joe-random-hacker isn’t going to be able to access your endpoint URLs anyway because they won’t get that far into your network.

XML Denial of Service Prevention

In this category are things like external entity resolution based DoS, recursive XML elements and large documents. Again, the susceptibility of your own particular services to these types of attacks is very much dependent on your service design. For example, if you are using a profiled version of XML, much like rig0002, things like external entities aren’t allowed, so anything based on that attack wouldn’t be allowed into the system anyway.

The other two are primarily based on the assumption that you will be using DOM or tree-based processing of your XML. Unfortunately, most of the automagic data-mapping libraries are based on DOM (XMLBeans I know does this for sure, and using something like JDOM is going to have the same type of issue), meaning that if you are relying on these tools, you may be vulnerable to these attacks.

On the other hand, if you are using a stream-based XML processing mechanism like SAX or StAX, you can process XML documents as a stream of events, meaning that the overall size doesn’t matter to the consuming application. However, it may make a huge difference to things between the requester and the ultimate provider. Any intermediary device which is going to try and buffer requests or do store-and-forward messaging may have upper size limits on the messages they can handle. If it is a hardware device, it’s likely to be significantly less than what your JMS, MSMQ or MQSeries provider software can handle, so it is important to know these kinds of details about your end-to-end environment.

The XML gateway can attempt to detect these sorts of things like deeply nested messages and messages exceeding a certain size, but, like any security threat, you need to understand your real vulnerability to it and determine if it is something that’s going to be a cost-effective issue to control.

XML Schema Validation

The topic of XML schema validation also is an important consideration for your overall architecture. Schema validation isn’t generally that expensive in terms of possible operations to be performed over your documents, but, naturally enough, it requires the validator to have access to the XML schema. There are two main approaches to this problem.

The first approach is the most flexible, but also the poorest performer: let the validator load the remote schemas. This will work if your schemas are local and located in your secure zone (and you have the appropriate traffic rules in place), but, in most cases, your validation server will probably not be allowed to make arbitrary connections to the outside world. I’ve seen a few systems fail after deployments into production environments where these sorts of rules were in place–oops.

The main issue with this approach is less about access and more about performance. In the worst-case scenario, you’ll need to download each schema from a remote location every time you need it. The various XML validation tools have a variety of caching mechanisms to minimize this issue, but you’re still depending on the availability of a resource you don’t control, and if it’s a cached external resource and it is updated (versioning is a whole different problem), you may not know about it anyway.

The second approach is to have your XML validator either store the schemas locally, or access them from resources within your own environment. This sounds straightforward enough, but it needs to be considered in the context of the functional requirements listed above. If you have a highly dynamic set of XML schemas, you’ll need to provide a centralized access point for them within your environment, otherwise you’re going to have a potentially complex provisioning problem in getting the schemas to all of the locations that need them. Of course, by centralizing them, you’re potentially introducing a central point of failure, so you’ll need to address this issue as part of your overall architectural design.

If you want to catch non-validating documents as early as possible in the request chain, then the XML gateway may help you here. However, depending on how loosely coupled your architecture is from a processing point of view, the document may need to be validated downstream anyway. Additionally, if you are using Schematron or NVDL to do more complex, business-level validations of your XML messages, I don’t see how offloading validation to the XML gateway really is a net gain.

I’m not going to go into much about the rest of the content inspection topics. Even though it’s sponsored by Forum Systems, one of their whitepapers, Attacking and Defending Web Services (PDF) provides a pretty good description of the types of XML-specific attacks the XML gateway is trying to defend against.

Access Control Operations

The access control aspects of XML gateway functionality are arguably the best reason for considering adding one to the infrastructure. Why? Because these are generally the most process-intensive operations that can easily benefit from hardware acceleration. Of course, you could add dedicated crypto PCI cards to your servers and integrate these functions into your service implementations–the question is do you really want to?

Again, borrowing the list from Vordel, the access control functionality often provided is:

• XML Encryption
• XML Signature
• WS-Security Username Profile authentication
• WS-Security X.509 Certificate Profile authentication
• WS-Trust
• SAML
• LDAP integration
• Active Directory integration
• XKMS
• SSL (server and bi-directional)
• HTTP authentication
• IP address filtering

Besides having just won Buzzword Bingo, there are several of these functions which are important to your security architecture, in addition to influencing design decisions for the overall solution architecture. Again, I’ve placed the XML-centric functions in bold. I’ll group these together based on authentication and authorization functionality, signature and encryption functionality and PKI functionality relating to key management.

PKI Functionality

I’m going to start here because a number of the other aspects of the rest of the functionality rely or can rely on some parts of PKI. One of the biggest challenges with PKI is providing a comprehensive view of trust (see the U.S. Government’s Federal Bridge Certification Authority for some of the challenges in trying to do this sensibly), and the other relates to management of the digital certificates themselves. These two issues arguably are what have impeded the widespread adoption of PKI infrastructures even though the theory is 100% sound. Therefore, any participant in tasks relying on PKI technologies or artifacts is required to deal with these issues to some degree.

If you are considering going the route of the “private CA”, there are a number of things to keep in mind. Yes, you have total control over your certificates, but maintaining a “real” CA takes some serious investment in hardware and security measures. Most organizations simply can’t justify the costs. A simpler alternative that only works for providers with centralized control (an 800-pound gorilla) and small scale is to dedicate a machine that isn’t connected to any network to issue the necessary certificates. This solution also has some problems when it comes to managing revocation lists (CRLs), and it can’t support any type of dynamic certificate validation protocol to ensure revoked certificates cannot be used until the appropriate CRLs are updated.

Any device using certificates needs to have access to the certificates as well as be able to determine the validity of those certificates. This is where choices on your overall architecture may make provisioning of keys more difficult than necessary. An alternative is to have the XML gateway directly access the LDAP server and store them there. If we do that in this example, we are violating one of our security requirements about direct access to directory servers from hosts in the DMZ. An alternative might be to load the certificates on the device itself, but that can be problematic as well. For example, the Cisco 6500 series CSS can only hold 256 certificates, so if you have a number of trading partners (or regularly expire certificates to detect unauthorized users), this could pose a problem. Unfortunately, in the case of the Cisco CSS, there’s no other way to point it to an external certificate repository.

These types of considerations must also be part of the overall identity management strategy for the architecture. If you are going to be doing multiple things with the certificates (e.g. encryption, signatures and authentication), they may need to be distributed to multiple locations in your environment. This may be one reason that an XML gateway would be attractive because it could do all of these things in one device, but it still may not be a good fit with your overall identity management plans.

XML Signature & Encryption

There is no question that XML signature and encryption are expensive operations. There have been hardware solutions to provide dedicated processing of this sort of activity for many years. However, part of the question relevant to XML gateway usage is related to performance and part of the question is relating to what you are trying to do.

One of the first things you need to do is figure out what you are really doing by signing an XML message. Is it to detect unwanted changes to the message? Is it to provide non-repudiation with trading partners? If so, do they trust you, or do you need to have this done by an independent 3rd-party?

If you are attempting to detect unwanted changes in the message, it is important to identify the scope in which those unwanted changes can occur. It is possible in an SOA environment with extreme loose coupling that you may want to have each processing step sign the message, both for tamper detection as well as verification of what someone actually saw at a given point in a business process workflow. In an environment mostly concerned with tampering between the sender and the receiver organizations, it may be sufficient to sign the message at the XML gateway on the way out of the network. However, if you are only sending the message over a synchronous connection which is secured via 2-way SSL, signing the message may not be necessary. If you are placing the message on a publicly-accessible FTP server for collection asynchronously, it may make more sense.

Encryption of the message contents can either be done for the entire message or for individual elements within the message. As Doug Kaye discusses, different elements of the message may be intended for different recipients, meaning they should be encrypted using different public keys. When considering using encryption for data, you also need to consider the temporal aspects of the message, e.g. how long will you want to access the encrypted data, and if you are going to encrypt it using more than one key.

Anyone who has ever seriously used a personal encryption program such as PGP or GnuPGP for their email has probably made the initial mistake of not encrypting the email they send with their own key and then discovered they couldn’t read messages in their Sent mailbox. The same issue applies when using encryption in a business context, though the consequences of lost data may be a lot more than the annoyance over an unreadable personal correspondence.

Naturally, the more keys you use, the more CPU intensive the encryption operation will be and the longer the process is likely to take. Also, in relation to the temporal loose coupling of your messages, if you intend to regularly expire your “normal” encryption keys, you will eventually make historically encrypted information completely inaccessible–unless you also encrypt the data using some sort of “master” key which does not have an expiration time-out. Use of such a “master” key would want to be pretty tightly controlled, so you need to figure this in to your overall security architecture as well. If you aren’t going to have accessible data after time T, then this also affects your backup and data retention strategies because there’s no point keeping data around that you can’t read. However, even if you can’t read the data, you may want to keep a record of having had that data for statistics, accounting or other purposes.

The main point here is that you need to really decide from a business point of view why you’re encrypting the data. Is it so you can comply with the credit card processing guidelines? Is it so that you are minimizing your risk of exposing your customers to identity theft should your systems suffer a security breach?

If either of the above or something similar is the motivation, and for this example, protecting credit card data is one of our original business requirements, you may not have any choice but to encrypt part of the information when you are inserting it into the message. The bottom line is: if the information is worth encrypting, it doesn’t make sense to risk having copies of it lying around in log files, console messages and audit tables in clear text.

If you don’t care enough to encrypt it internally, maybe it isn’t worth encrypting it externally–again, especially if you’re transmitting it over a secure channel to a service that is going to immediately decrypt it and shove it in a spreadsheet or database under minimal security controls on the other side. It is absolutely critical that you understand the processes that are manipulating the data you exchange with your customers and your business partners.

In the above scenarios, while you could benefit from the performance gains of a dedicated XML gateway appliance, it doesn’t really seem wise to leave encryption and decryption separated from the point at which the data will be used. In the worst case, if you have a machine that is compromised in the DMZ and the XML gateway decrypts the message payload before sending it into the secure zone, an attacker able to put a network interface on the compromised machine into promiscuous mode would be able to capture the clear-text information at will. In most cases, it will be much easier to compromise a machine in the DMZ than it will be to break the encryption on the messages.

Finally, with both signing and encryption, the process performing the task needs secure access to the key store. Without this, a bogus key could potentially be supplied by a compromised system that would enable an external party to later decrypt the messages. This process also is directly related to the issues discussed in the PKI Functionality section, because, depending on the choices you make, you still have the key provisioning problem.

Authentication and Authorization Functionality

Authentication and authorization (AA) share an overlapping set of problems with the PKI functionality in terms of provisioning of the identity and policy information to be used. In this example, one of the business requirements was that centralized policy management must be part of the architecture. This means any device or process performing authentication and authorization must leverage this consistent set of policies. Once more, we have the distributed vs. centralized (and potential single point of failure) issue.

For the sake of argument, the directed arrows marked as (6) and (7) in Figure 2 are some sort of remote call to a policy store which is persisting information in the LDAP servers. This policy store provides complex rules that can be tested at any appropriate policy enforcement point (PEP). Arrow (6) represents the PEP required by the AA functionality of the web server plug-in. Arrow (7) represents a possible PEP required by the XML gateways if “standard” SOAP services with multiple operations are deployed at the same URL.

From an authentication point of view, the only context available to the XML gateways comes from the message itself. It may be possible for the XML gateway to leverage the “split” X.509 certificate information conveyed as HTTP request headers to provide additional context in making the authentication decision, but none of the products I saw discussed such a feature. In the case of multi-operation SOAP services, the XML gateway is probably the best PEP to make the authorization decision to determine if a given requester can invoke a particular service.

However, unless the identity and authentication credentials are present in the message, it is possible that the authentication information present in the request may not be available to the XML gateway. There are a number of ways around this problem which do not involve putting the XML gateway “in front of” the web servers or the CSSs, but once more, you need to be wary of the provisioning complexity potential of the business requirement for a fairly dynamic service environment. It may be possible to minimize this effect so you can use a consistent URL pattern matching expression at either the switches or the web servers, but this decision must be part of the overall architectural design of the system.

Closing Thoughts

Things are rarely as simple as they seem, and this is especially true regarding security. Every decision made at an architectural level will have security consequences just as every security decision will have architectural consequences. This is an unavoidable characteristic of system design. The bigger the system, the more decisions that need to be made, and the harder it is to achieve consistency across them. This reason more than any other should make the necessity of having a well defined, enterprise security policy in place before you have designed, built and implemented your system architecture quite clear. One of the best quotes I’ve seen about designing systems is from Barry Boehm:

“The most important software engineering skills we must learn are the skill involved in dealing with a plurality of goals which may be at odds with each other, and the skill of coordinating the application of a plurality of means, each of which provides a varying degree of help or hindrance in achieving a given goal, depending on the situation.”

Part of what prompted me to write this was there is a widespread school of thought that goes something like, “all I need is product or device X, and my security problems will be solved.” Any security professional will tell you this is patently false. Security is achieved through a combination of people, process and technology being applied in a consistent manner based on a security policy created to support the business goals of the enterprise. There’s no way that one product, or even a set of products can completely solve the security problem.

A lot of people (and I’m not talking about Anne here) think things like XML gateways are “pixie dust” for security in the same way that people thought XML was some sort of magic solution to all business data representation and exchange problems. The answer to the question posed in the title of this article, as illustrated by Bohem’s quote, is: it depends. Hopefully, if you’ve made it this far, you learned a few things, and you’ll be better prepared to participate in the overall security effort and answer the XML gateway question for yourself–regardless of your role within your organization.

References

• A Conversation with Werner Vogels, ACM Queue, May 2006.
• Boehm, B.W., Software Engineering Economics, Prentice-Hall, New Jersey. 1981.
• Configuring SSL services for Cisco 6500 series switches, Cisco, Accessed 31-May-2006.
• Forum Systems Website, Accessed 30-May-2006.
• Heffner, R., Commentary: Keeping developers out of security, Forrester Research via CNet, March 2004.
• Kaye, D., Loosely Coupled: The Missing Pieces of Web Services. RDS Associates, Marin County. 2003.
• Kuznetsov, E., XML services call for security checks, EE Times, Aug 2003.
• Kuznetsov, E., XML Web services security best practices, ZDNet, Sept 2004.
• MacVittie, L. and J. Forristal, Enemy At the Gateway, Network Computing, Oct 2003.
• Nance, B., XML Infrastructure Front-end Processors, Business Communications Review, December 2005.
• Reactivity XML Security Gateways, Reactivity, Accessed 30-May-2006.
• Vordel Website, Accessed 30-May-2006.

Permalink 4 Comments

Doug & Wendy vs. Your Credit Card Data

Posted in Rants, Security by AST on Tuesday, May 16th, 2006

How many people ever saw the SNL skits featuring Doug & Wendy Whiner? If you never did, then the title won’t make much sense to you. Essentially, the Whiners are a couple that whine about nearly everything. Unfortunately, it’s remarkable how much reality was in those skits.

Having just come back from giving presentations about effective data protection and understanding the fundamental premise of legitimacy or fairness expected implicitly by customers from organizations who store our data, this CNET article scared me to death: “Credit card security rules to get update.”

The article discusses proposed changes to the security requirements for businesses that accept credit card information. Currently, the PCI standard (PDF) developed by both MasterCard and VISA requires the following (from the VISA CISP information page):

1. Install and maintain a firewall
2. Do not use vendor-supplied default passwords or other security features
3. Protect stored data
4. Encrypt transmission of cardholder data and sensitive information across public networks
5. Use and regularly update anti-virus software
6. Develop and maintain secure systems and applications
7. Restrict access to data by business need-to-know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data
10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes
12. Maintain a policy that addresses information security

To anyone who has ever built or implemented a security policy, the above should seem to be pretty standard stuff, and it’s pretty fair to the customer in attempting to protect access to their data. However, these quotes from the article indicate that some legacy systems can’t cope with the requirements, so they need to be “relaxed”:

“Today, the requirement is to make all information unreadable wherever it is stored,” Maxwell [director of e-Business and Emerging Technologies at MasterCard] said. But this encryption requirement is causing so much trouble for merchants that credit card companies are having trouble dealing with requests for alternative measures, he said.

and

The challenge with encryption is that older payment systems were not built to support the scrambling technology, said Qualys CEO Philippe Courtot. “Encryption is the ultimate measure of security, but the current applications have not been designed with encryption in mind,” Courtot said.

These systems and their delinquent owners are holding your, yes, that’s right, they’re holding your credit card data unencrypted because of flaws in the application. That’s equivalent to the police saying that it was too hard to catch the guy breaking into your car, so you should just keep it in the garage instead where it’s safe.

The Whiners who own the defective applications are whining to Visa and MasterCard–and they’re listening! This is incredible. To be fair to Qualys’ CEO, I’m going to assume that he’s stating that there were complaints rather than his own opinion here.

So, how are these delinquent systems going to keep your data (and your identity) safe from the bad guys? You’ll love this:

Changes to PCI will let companies replace encryption with other types of security technology, such as additional firewalls and access controls, Maxwell said. “There will be more-acceptable compensating and mitigating controls,” he said.

Right, so let me get this straight: no encryption; more firewalls. Because, as Marcus Ranum says firewalls just don’t work, and, well, nobody reads any of these articles anyway:

• Black Market in Stolen Credit Card Data Thrives on Internet, The New York Times, 2005-06-21
• Consumers, retailers grapple with data theft, CNET, 2005-06-22
• Credit card leaks continue at furious pace, MSNBC, 2004-09-24
• Lax Security Cited in Massive Credit Card Data Theft, Netcraft, 2005-06-18
• Credit card companies can keep data ID theft secret, The Register, 2005-09-24
• Backup tapes a backdoor for identity thieves, SecurityFocus, 2005-04-28
• Backup-Tape Security: Enter the “Brown Bag”, Enterprise Systems, 2006-04-11
• Iron Mountain looses more backup tapes, TechWorld, 2006-05-02

Granted, this article from ZDNet, “Lose your backup tapes? It could be worse” makes two good points: a) it would take some pretty serious knowledge to get the data off the tapes, and b) the fact that the tapes are missing is going to be pretty obvious. However, what he also points out is that there are even easier ways to get at the data–all you need to do is get to the machine. Since the data isn’t going to need to be encrypted on the machine anymore, once you have access to the machine, you have access to the credit card data. It’s as simple as that.

The silly thing is that encryption isn’t rocket science, and it isn’t hard to design systems to take advantage of encryption techniques to store the information. In the absolute worst case scenario, you just have to pay your database vendor to solve the problem for you, and you don’t even need to change a single line of application source code. I don’t recommend this as the right way to solve the problem, but it is an alternative if all else fails. The latest versions of Oracle actually have some pretty sophisticated mechanisms for compartmentalizing data in the database.

The good news is that it’s only currently a proposal, but the bad news is that, due to the Whiners of the world, the proposal is likely to be accepted by MasterCard and Visa. If MasterCard and Visa accept it, they’re really going to loose a lot of points with people, because it proves that they really aren’t as serious about security as they should be, and that with enough pressure, they’ll revisit security controls which some find “inconvenient” or “difficult to implement”. Given the number of people in IT and especially management who actually understand security is quite low, this is a slippery slope to start down.

Permalink 1 Comment

InfoSeCon 2006 Wrap-up

Posted in Security by AST on Friday, May 12th, 2006

I originally had grand plans to do a day-by-day summary of the conference, but then I decided that I really didn’t want to touch my computer any more than I had to while I was at the conference (well, that and the fact that the wireless in the hotel didn’t cover my room). As a result, I’m going to lump it all together and just focus on overall impressions and highlights.

Personally, I had a great time at this year’s InfoSeCon conference in Dubrovnik. Last year, I had the opportunity to meet some really well-respected security professionals like David Bianco, Vince Gallo, Richard Neely, Jorge Sebastiao and John Sherwood who were all back for this year’s conference. It was great to see them all again and see what they’ve been up to since last year.

This year, I also had the opportunity to meet and have some really good chats with Ron Collette, Steven Cox, Mike Gentile, Marcus Ranum and Radovan Semancik. The nice thing about InfoSeCon is that because it is a smaller conference, you really have the opportunity to interact and get to know people. I think this is a really valuable experience for both the speakers and the delegates.

Some of the things that really stand out in my memory of this year’s conference are:

Vince Gallo’s presentations on Steganalysis and Intel’s new LaGrande technology

The steg presentation was very interesting because it showed that there really are trends that you can identify from seemingly random image information that can be used to detect messages embedded in binary formats. I’m not giving anything away here because the research and implementations that Vince and his team at Inforenz are doing are based on published work that is freely available.

The LaGrande technology is something that I hadn’t heard about yet, but it is intended to allow you to provide, in Vince’s words, a secure “VPN-like channel” for the execution of code within an untrusted environment [software and hardware] that has important applications for trusted computing.

While the technical content of both presentations was very interesting, some of the stories Vince was telling at dinner really reinforced that we really do need to cultivate more people like Vince in the current technology workforce. He’s been in the business of writing security code and building secure hardware devices for more than 20 years.

What this really means is he’s seen a number of the 6-8 year iterations of ideas and technology come and go, and understands the strengths and weaknesses of technologies and techniques at a level that a lot of “senior and experienced” security professionals and developers just don’t have. It isn’t that there aren’t people like or better than Vince in the world, but they’re few and far between because of the way the industry works–you’re not supposed to have 20 years of experience and still be writing code every day. I mean, come on, what’s wrong with you?

However, if you ever have an opportunity to sit down and talk with these guys, you’ll be doing yourself a great disservice if you don’t take advantage of it. Think about this the next time a vendor or consultant tries to sell you a new security solution. Experience really does matter.

Marcus Ranum’s presentations on general security and firewalls

Of all the things you could say about Marcus, saying he was not someone with strong opinions wouldn’t be one of them. His presentation, “Dude, where’d my firewall go?” was very interesting and highlighted a few things that most people don’t think about:

• Why today’s firewalls are so fast

  Marcus contrasted the early firewalls that he developed against the firewalls of today. There’s a couple of key differences: first, the 1st generation of firewalls enforced protocol correctness based on the limited number of commands that were actually used by deployed software vs. the number of commands that were actually available.

  With the original firewalls, it didn’t matter too much about the vulnerabilities in the software because the firewall wouldn’t let unexpected application protocol traffic (often referred to as layer 7 traffic) past them. The device actually understood what was going on on the connection and would drop it if strange things started happening.

  Today’s firewalls don’t understand applications, so they don’t do anything other than relay traffic to a specific back-end application–with all of its vulnerabilities laid bare to the world for exploitation.

  The second reason that today’s firewalls are so fast is they generally don’t do anything useful out of the box. That’s right, the $60K piece of hardware is actually going to do nothing to protect your network until you enable the controls. What’s that about default to no access or something crazy like that? Oh, and when you do start turning on those controls, it will slow down the traffic going through your network. Wow. What a surprise, but, according to Marcus, people don’t find that acceptable so they turn off the protections. Excellent stuff.

• Why signature-based tools like IDS and virus scanners don’t work

  This point was illustrated with a brilliant story about castle guards and Vikings (Marcus is also a bit of a military historian). The problem is that the tools (firewalls and anti-virus) don’t know about Vikings, they know about Eric the Red.

  Castle guard: “Are you Eric the Red?”
  Canute the Viking: “Nope.”
  Castle guard: “Ok, then. In you go.”

  At which point, Canute the Viking enters the castle and begins his conquest of England, Denmark, Norway and part of Sweden. Are you starting to see the issue here?

  The issue is that the guard needs to know all of the potential attackers on a first-name and by-sight basis. While this is theoretically possible, in practice it will never work because you’re always reactive and there are a lot more potential Vikings in the world than there are of you. Military history shows us that the people who were always on the defensive generally didn’t end up winning the war.

I hadn’t gotten the opportunity to meet Marcus in the past, but I had read some of his articles. I have to say that you can’t really form an opinion about Marcus until you meet him in person. I certainly have a different impression of him than I did before the conference. There was no question that he was a smart, funny and irreverent guy who knew his stuff, but he’s also a very interesting and genuine guy who really doesn’t just disagree with things for the sake of disagreeing (despite what you may think from reading some of his work). I have a tremendous amount of respect for Marcus and what he knows–even if I don’t always agree with him (now that I know Marcus, I’m sure he’ll take this in the way that it was intended).

Jorge Sebastiao giving me the best intro I could have possibly wanted for a presentation on privacy (flash required)

At the end of Jorge’s presentation on Business Impact Analysis, he played the above flash video about the guy who tries to order a pizza and is refused the one he wants because the pizza order taker has access to his health records and other personal information. I don’t really remember how it fit with his presentation, but I think I’ll have to work it in to mine for the next time I give it. Why is it we’re concerned about access to our personal information again?

The tag-team presentation by Mike Gentile and Ron Collette on security program development

I ended up sitting on the plane next to Mike and his wife on the way to the conference and this was the start of a couple of new friendships with the folks from California. All week long, Mike and Ron were talking about what a rebel each of them was and how many people they deal with see what they’re saying about security as highly controversial. I was looking forward to their presentation, and couldn’t imagine what it was going to be like.

You also need to understand they both are accomplished athletes (Mike played soccer and Ron played American football), so to see them present is a very interesting study in both American culture and teamwork. It wasn’t quite one completing the other’s sentences, but it was a very effective presentation technique. Having spent a lot of time with them this week, I can attest that they’re really just like that, but I can imagine the reaction they might get at Fortune 100 companies, because they’re both really down-to-earth and practical guys focused on results.

The best part was that after their presentation, David Bianco made the comment that he really didn’t see anything controversial in their message at all–it was just sound security practices. David’s comment got resounding nods from most of the other people in the audience. However, the issue here isn’t that Mike and Ron were preaching to the choir, because there was really some good stuff in what they said; instead, the issue is that what they said could be considered controversial at all. It underlines the fact that in any aspect of security, most organizations really have a lot to learn about how to do it properly. While this is good news for security professionals, if you really think about it, it’s pretty terrifying as a customer of these organizations. Mike and Ron are going to be really successful because they know what they’re talking about, they can articulate it in a way people understand, they’re genuine and they care about what they’re doing.

In reality, there were a lot more great things that happened at the conference than these, but I don’t want to end up writing War and Peace. I think that everyone I talked to really enjoyed the conference and thought it was worthwhile.

Finally, I want to thank Stanko & Biljana Cerin for all their hard work in putting the conference together. These are two of the nicest, most genuine and hard working people that I’ve met. They really believe in bringing a high level of quality security material to people in Croatia and the surrounding countries. Not only do they believe it, but they are also qualified security professionals in their own right.

I’m already looking forward to next year’s conference–better go start figuring out what I’m going to talk about…

Permalink 1 Comment

InfoSeCon 2006

Posted in Security by AST on Tuesday, March 7th, 2006

Once again, I will be speaking at the InfoSeCon security conference. Last year, I had a really great experience and met some excellent speakers as well as made a few new friends. I’m looking forward to a repeat of that experience this year.

This year, I’m going to give two presentations on privacy issues. One of them is from the business perspective, “The Man’s Got His Eye On Me”: Understanding Your Customer’s Privacy Perceptions. Here’s the presentation abstract:

You have been audited by several accredited security auditors and found to be completely in compliance with both the current EU Data Protection Directive and your local government’s implementation of that directive. Still, you are receiving a high volume of customer complaints about perceived violations of their privacy. Since you must investigate each complaint, and the volumes are so large, you’ve had to set up a special department with dedicated staff to deal with these matters. All of this affects your bottom line in two ways: overtly due to the expense of dealing with all of the complaints and covertly due to the negative reputation you are developing amongst your customers, present and future.

Does the above paragraph sound familiar to you? Do the issues raised resonate with your current thinking? If the answer to either of these questions is “Yes,” this presentation will help you understand the rationale behind the data protection directive and related privacy legislation by looking at how your customers may feel about privacy as individuals.

Several actual Data Protection complaints to the Irish Data Commissioner will be examined, along with some recent privacy related news reports and other privacy literature, in an attempt to identify and concisely articulate common themes. Exposing these themes and how they relate to the legislation will provide insight into the motivating spirit behind the law and identify core privacy concerns. Capturing the spirit of the various privacy laws will allow you to assess your current data requirements and management practices to determine if there are ways you can go beyond compliance and address your customer’s concerns proactively–to the benefit of both your business and your reputation.

The second one is more focused on people who design and build software for a living, so it’s more technical. Here’s the abstract for the second presentation, Design Considerations and Strategies for Data Protection Compliance:

If you are responsible for designing or implementing software systems and think that privacy concerns are not something you need to worry about, think again. Depending on the way a local Data Protection Controller may interpret EU and national laws, information about the way you store data and even how you’ve labeled it, may be up for public disclosure.

How can you be prepared? By thinking about privacy issues and the results of potential investigations into privacy complaints during the design of your IT systems, you can store and manage customer data in ways that are not only secure, but also sensitive to the privacy needs of your customers.

This presentation will show the impact of privacy preparation on the requirements gathering, design and implementation stages of system delivery. It will highlight specific questions to ask business owners, and show some potential pitfalls which may lead to unnecessary cost in proving system compliance, changes to the fundamental design due to questions of compliance or even embarrassing publicity for your clients or company as the result of a legitimate “right to access” request. Armed with this information, you will be able to build software systems that are not only better, but also more compliant with data protection legislation.

Hopefully, this year’s conference will be as much of a success as last year’s. If you’re in the mood for some security in the sunshine (although it did rain one of the days last year…), it’s worth the trip to Dubrovnik. Hope to see you there.

Permalink Comments