Sharing structured data

XML Magazine

Subscribe to XML Magazine: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get XML Magazine: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Technical Information Security Policy

The first step to delivering the right control and visibility architecture for SaaS is to formalize the enterprise’s goal in a Technical Security Policy. The security policy lifecycle begins with policy creation and development. The Security architect must collaborate with policy authors, management, development and operations to define specific technical policies that will enforce the security architecture decisions. These policies may govern issues such as:

  • Define allowable & non-allowable usage
  • Security token types & issuers
  • Integrity requirements
  • Logging & monitoring requirements
  • Access control protocols
  • Message and Channel Encryption

These are a subset of some of the concerns that the Technical Security Policy must address to govern access and visibility to SaaS applications. Every organization has some type of Information Security Policy, these are typically hundreds of pages long, but are written at a high level and do not contain specific technical guidance such as the above list. The Technical Security Policy closes out this gap. Some standards such as WS-SecurityPolicy have emerged in this space and are worth studying to understand the level of granularity that can be expressed.

As a rule of thumb, the Technical Security Policy should include allowable and no-allowable usage for the application’s Attack Surface. For many SaaS applications, the Web Services Attack Surface is comprised of the application’s Data (such as XML), Methods (such as SOAP, and URI), and Communication channel (such as HTTP). In other systems such as Mobile applications the Attack surface could also include SMS, Geolocation, and other smartphone services.

The Technical Security Policy is likely to be highly contextualized based on each deployment type, and to cover a wide array of different deployment integration patterns – from network security to app security to identity management. This approach is good from a design standpoint because it allows the Security Architect to be precise and specific with guidance. It’s also problematic because the audit, review, execution and lifecycle management can be challenging.

Closing Out Technical Gaps with a Security Gateway

The Security Gateway pattern fills this gap by providing an execution environment to enforce the Security policies. Sure, each endpoint can be wired up to validate SAML assertions and enforce message integrity, but for a system with numerous endpoints, manageability and assurance quickly becomes a limiting factor to this approach. The Security Gatewaypattern mediates communication to and from SaaS application providers and gives the Security Architect the ability to ensure that technical security policy is being enforced. Further, the Security Architect now has a location to manage and deploy any changes to the Security Policies. Say that a SaaS provider is initially only supporting weak username/password combination for access, but that the SaaS provider is working on an upgrade to support SAML. Instead of re-wiring all endpoints, the Security Architect can wire on SAML on the Security Gateway once the SaaS provider is operational with SAML.

The SaaS provider is home to some of the enterprise’s most important data and functionality such as customer data. The Security architect will often seek to record any CRUD access to the critical SaaS functionality and data, and to accomplish the Gateway chokepoint for inbound and outbound access is essential. Simply monitoring open and close network connection won’t cut it, when message semantics are needed to determine who did what where in the SaaS application.

The Gateway formalizes the security architecture’s roles and responsibilities with the SaaS Cloud provider. The Gateway serves to enforce the policy, making runtime access control decisions, provide a place for auditors to review the controls for compliance purposes, and for the administrators to manage the system over its lifecycle. This division of roles and responsibilities gives the enterprise the ability to retain a modicum of control while still leveraging Cloud applications for their benefits.

Gunnar Peterson is a Managing Principal at Arctec Group. He is focused on distributed systems security for large mission critical financial, financial exchanges, healthcare, manufacturer, and federal/Gov systems, as well as emerging start ups. Mr. Peterson is an internationally recognized software security expert, frequently published, an Associate Editor for IEEE Security & Privacy Journal on Building Security In, an Associate Editor for Information Security Bulletin, a contributor to the SEI and DHS Build Security In portal on software security, and an in-demand speaker at security conferences. He blogs at

Read the original blog entry...

More Stories By Application Security

This blog references our expert posts on application and web services security.