Between Cloud, Mobility and the Enterprise is the API Middle Ground

Scott Morrison

Subscribe to Scott Morrison: eMailAlertsEmail Alerts
Get Scott Morrison: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

The Challenge of Web Services Security Inside the Firewall - A true story from the consulting trenches

The Challenge of Web Services Security Inside the Firewall - A true story from the consulting trenches

True story from the consulting trenches: the operations staff had left hours ago, shaking their heads and reluctantly leaving the consultants to resolve a problem with their code. It was well past midnight, in the middle of winter, in a town many time zones from home. The project was late. Altogether, this was an awkward situation that you probably know well.

The consultants - falling into that murky classification of not quite outsider, nor regular employee - worked from hobbled accounts; the security staff were pros and took their charge seriously. By 2:00 a.m., the group was stuck. They needed to change a properties file residing on a remote server, but the distributed file system wouldn't allow it, rightfully sneering at the group like the grubbiest serfs in the kingdom. But there was a Web server...

...And this server was running as root. Before you could say "exploit," our team had all of the rights and privileges of the king of the castle. They tweaked the configuration, muddied the logs, and lo and behold, the software began to run as designed. The client was thrilled the following day; the application moved into production; everybody got paid.

Is this an allegory illustrating the virtues of hacking on the job? No, as it was unethical, possibly illegal, and certainly grounds for termination. No, this is a story about a clash between security models. At the OS/file system level, the consultants were exactly where they should have been: contractors, a little weary, and not entirely trusted. It was a failure at the application level, that is, across HTTP and the Web server, where policy broke down, allowing any one of our friends to become Neo flying about the Matrix. This collapse of the identity model is a common security problem. It's becoming a particular issue with Web services deployed inside an organization's firewall.

The Internal Threat
It's the outside hackers who receive all the attention. The media is intoxicated with the idea of the teenage misfit outwitting the corporate giant, and all of this attention diverts much of a security professional's time and energy toward addressing the threat. But the threat of the insider can often be as severe, and it may have greater consequences. In its 2003 Global Security Survey, Deloitte discovered that 39% of respondents in the financial services sector had experienced some kind of system compromise in the previous year, and of these, 10% were internal breeches. This might not seem like a lot, but the cost stemming from an internal compromise can be much higher. Gartner estimates that of the security breeches that result in actual measurable loss to an enterprise (as opposed to mere annoyances), an astonishing 70% involve insiders.

Web services are simply a new avenue for the internal hacker to exploit - and it's some very fertile ground to work on. Years of emphasis on perimeter defense have left internal networks open and vulnerable, a mishmash of unpatched systems and obsolete technologies. The irony is that it's into this environment that we're deploying the majority of our Web services applications. Lacking faith in the immature state of Web services security, it just feels safer than tentatively creeping past the firewall. Yet in doing so, we may be placing our data assets at even greater risk.

Principles of Good Internal Security
Security is a game of risk management. It's impossible to eliminate risk - that's like eliminating all bugs from software. But risk can be reduced, and the real challenge is finding the balance between comfort and investment.

Good security is a process, not a technology. While technology certainly has its place, as we will see, it's a mistake to think that it alone will solve the problem. Instead, technology fits into four critical areas everyone must address when building an effective internal security model:

  1. Instill a culture of security
  2. Apply the principle of least privilege
  3. Implement a strong identity model
  4. Monitor, monitor, monitor
Instilling the Culture of Security
The social process of security is a reflection of corporate culture. Accountability and integrity begin with the executive team and filter down among the ranks. Security policy has to be clear, simple, and well known - on their first day, employees must be made aware of what the expectations are and what the consequences are for violation.

Policy, however, has to be backed up with continuous monitoring and audit. Technology helps here, but it isn't the only answer. Employees themselves are probably the best resource for uncovering security violations, but they need to know that they will be supported when they report that the person in the next cube is accessing records they shouldn't. Clearly, a strong network identity model plays a critical role here. If transactions are anonymous, monitoring is of little value and the social process will break down.

Principle of Least Privilege
After culture, a rigorous application of the principle of least privilege is the most important strategy to confront the insider threat. This can also be thought of as a need to know, where a person's access privileges are closely mapped to their business function - no more, and no less. It sounds trivial and obvious, but this is a common failing. How many companies have you worked for where several people share a general account? Conversely, how many times have you found yourself in possession of several separate accounts, each under an independent security domain, but all within a single organization? And how many accounts from your previous jobs remain active, overlooked in the ether between HR and IT?

Herein lies much of the challenge for creating secure Web services inside the firewall - that is, managing identity across domains so that the principle of least privilege has any meaning at all. Only when we associate identity with transactions can we harden our internal networks into zones of trust.

This is a particularly acute problem for internal Web services because of the nature of these applications. Web services are most often sold with the promise of driving new revenue through integration of external trading partners; but for most organizations, the reality is much less glamorous: they adopt them for that most dismal of problems, internal EAI.

With EAI comes the challenge of security domain integration, the integration and reconciliation of different security principles that have evolved independently to support a particular application. It's further complicated by a lack of identity in machine-to-machine communications (as compared to human-to-machine, where identity is simpler to establish using manually entered credentials). The most common approach to this issue is to map principals n:1 when crossing application boundaries, aggregating all users into a general access proxy account. It works, but offers only very weak accountability. Now some emerging Web services security standards can provide a much more finely grained identity model.

Identity and Web Services
The first challenge is to establish reciprocal identity between service producers and consumers. The OASIS Web Services Security (WSS) group addresses this. Their core SOAP message security specification defines the fundamental security model for Web services, specifying how to apply the existing XML encryption, signing, and canonicalization standards to SOAP messages. It defines a generic encapsulation mechanism for security tokens used to establish identity; this accommodates new or existing authentication technologies, such as basic authentication and x509 certificates. Each of these is defined separately, in detail, as a profile. The username profile, for instance, supports basic authentication, and provides mechanisms for digest schemes to enable identification without explicit transmission of passwords. It's very similar to what is already in HTTP, but it's decoupled completely from transport, so that the SOAP message remains secure using SMTP, message-oriented middleware, or even written on a piece of paper.

For many applications, this is fine; as credentials are required, the client pops up a dialog to a user requesting a password and the remote service is accessed, establishing a security context between client and server. It's worked well on the Web for years, gating entrances to subscription services, protecting personal data, etc. Behind the firewall, however, it's somewhat awkward - after all, these credentials might be the same you entered to sign on to your PC when you arrived in the morning. Why isn't this security context simply replicated to the remote server? Or for that matter, why do you have to sign on again when you switch between related applications, say the HR system and payroll?

This is where we find our first real problem, because sharing security context is complex, often very system dependent, and largely not transferable, despite the desirability of this from a convenience and consistency perspective. Fortunately, there are some further Web services standards efforts that are beginning to address this.

Security Assertions
SAML is the cornerstone of this effort. Measured against other Web services standards, it's mature - even ancient - having evolved over a few years and been officially accepted to version 1.1 by OASIS. It suffers from specification that is dense and difficult to read (it's almost completely lacking in examples), but conceptually, SAML is simple. It's an XML framework for exchanging security information about an identity and its entitlements. It does this by defining a schema to declare facts, called assertions, about subjects (a representation of identity). Assertions describe acts of authentication, authorization decisions (allow/deny), or the attributes associated with the subject. For example, an authentication assertion declares that a subject S was authenticated by means M at time T. An authorization assertion might declare that subject S is authorized to use resource R for access type A based on evidence E.

It's equally important to realize what SAML doesn't do. It does not provide yet another means for an application to perform authentication against a security server—that is, credential transfer and validation. There's no need; this is already well defined elsewhere: in WS-Security, in LDAP, in Kerberos, etc. Instead, SAML defines how applications can check that authentication has previously taken place. It's a crucial point, because it provides the mechanism to synchronize with an existing authentication context, rather than establishing a new, independent one. This is the basis of single sign-on.

SAML on its own has great value when there are multiple systems under a single unified security domain, and in many organizations that have moved toward a single source identity model, this is sufficient. Application servers publishing Web services can be configured in a trust relationship with a centralized SAML issuing authority, which can assert whether a subject has been authenticated, is authorized to use a particular resource, or is associated with specific attributes.

In keeping with its agnostic approach for encapsulating and processing security tokens, the WSS effort simply defines SAML as another profile. Assertions, or references to assertions, can be transported within WSS security headers, providing a means for service producers and consumers to exchange proof of events that established identity. Alternatively, SAML itself defines query mechanisms so that services can question an identity server about authentication events, or request an authorization decision.

We are still missing a crucial piece of the complete identity puzzle. The real challenge, to unite disparate security domain within an EAI project, remains. SAML on its own does not address this, though it could become the plumbing to enable it. For this level of security integration, we need still more standards.

Federation
Federated security is the solution we need. Federation allows different, independent security domains - each of which might use entirely different means to represent and authenticate identity - to share information about authentication events, authorization, attributes, etc. For example, the HR applications might reside in a domain organized around a central LDAP server that accepts binds with basic authentication credentials. The payroll system, in contrast, runs under control of the accounting department that uses Kerberos. It would be ideal to unite these independent security domains into a trust relationship, under which they share security information.

This is the goal of WS-Federation, another effort by the IBM/Microsoft team. WS-Federation provides the framework for brokering of identities between security domains, including mapping of identities, global sign-out, etc. At the time of this writing, it's quite new, and it relies heavily on other emerging specifications, such as WS-Trust, and on profiles of wire protocols such as SAML to serve as the glue bonding authentication domains. It will be some time before it sees formal implementation in commercial products, but it shows great promise and is a necessary component to implement a unified security model inside the firewall.

The hype behind federation builds off a vision of independent, but cooperating, businesses (air-car-hotel!); the reality will probably be somewhat more prosaic, but arguably more valuable to the organization. The real triumph of federation will be internal EAI projects, uniting those islands of information inside the corporation that so offend CIOs. And they will work precisely because they are inside a single organization. Federation requires significant stakeholder buy-in. It compels participants to concede a lot of trust to make it work, and often this can only happen under corporate mandate. So in a way, Web services security inside the firewall is as much opportunity as challenge: an opportunity to protect critical assets from insiders, but also an opportunity to perform EAI with a sophistication that has not previously been attainable.

References

  • 2003 Deloitte Touche Tohmatsu Global Security Survey: www.deloitte.com/dtt/research/ 0,2310,sid%253D3489%2526cid%253D15232,00.html
  • Web Services Security Technical Committee: www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
  • WS-Federation Specification: www-106.ibm.com/developerworks/webservices/library/ws-fed/
  • Security Services TC (SAML): www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
  • More Stories By Scott Morrison

    K. Scott Morrison is the Chief Technology Officer and Chief Architect at Layer 7 Technologies, where he is leading a team developing the next generation of security infrastructure for cloud computing and SOA. An architect and developer of highly scalable, enterprise systems for over 20 years, Scott has extensive experience across industry sectors as diverse as health, travel and transportation, and financial services. He has been a Director of Architecture and Technology at Infowave Software, a leading maker of wireless security and acceleration software for mobile devices, and was a senior architect at IBM. Before shifting to the private sector, Scott was with the world-renowned medical research program of the University of British Columbia, studying neurodegenerative disorders using medical imaging technology.

    Scott is a dynamic, entertaining and highly sought-after speaker. His quotes appear regularly in the media, from the New York Times, to the Huffington Post and the Register. Scott has published over 50 book chapters, magazine articles, and papers in medical, physics, and engineering journals. His work has been acknowledged in the New England Journal of Medicine, and he has published in journals as diverse as the IEEE Transactions on Nuclear Science, the Journal of Cerebral Blood Flow, and Neurology. He is the co-author of the graduate text Cloud Computing, Principles, Systems and Applications published by Springer, and is on the editorial board of Springer’s new Journal of Cloud Computing Advances, Systems and Applications (JoCCASA). He co-authored both Java Web Services Unleashed and Professional JMS. Scott is an editor of the WS-I Basic Security Profile (BSP), and is co-author of the original WS-Federation specification. He is a recent co-author of the Cloud Security Alliance’s Security Guidance for Critical Areas of Focus in Cloud Computing, and an author of that organization’s Top Threats to Cloud Computing research. Scott was recently a featured speaker for the Privacy Commission of Canada’s public consultation into the privacy implications of cloud computing. He has even lent his expertise to the film and television industry, consulting on a number of features including the X-Files. Scott’s current interests are in cloud computing, Web services security, enterprise architecture and secure mobile computing—and of course, his wife and two great kids.

    Layer 7 Technologies: http://www.layer7tech.com
    Scott's linkedIn profile.
    Twitter: @KScottMorrison
    Syscon blog: http://scottmorrison.sys-con.com

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.