Monday, March 24, 2014

The Walled Garden Has No Walls

If the contest is between walled garden and border-less security, I fall firmly in the latter camp.  Every year I'm reminded of this contest at the RSA Conference, where it seems that 90% of the attention falls in the walled garden camp.  The companies in this space have the big booths in the middle with all of the best schwag.  These are the peddlers of what Gunnar Peterson (@oneraindrop) calls magic pizza box.  The mentality is akin to defense manufacturing where bigger and more exotic (and expensive) tools get all of the attention and funding (and boy do they dream of the industry maturing to the level of the military industrial complex).  If the firewall is not enough, we need to escalate the complexity and sophistication of this toolset.  The firewall needs to be layer 7 and malware aware (great).  If the threat arrives over ports 80 and 443, beyond packets, whole conversations and packages must be inspected for their sanity.  We must have a TSA Checkpoint for anything allowed on these ports.  Strip-search those protocols with gloves!  We need virtual warriors pulling people aside and forcing them to give up their malicious intent.  We need intel akin to NSA and CIA to play with the bad guys on their own turf.

That's all very fun and intriguing to think about... and I believe the mindset is here to stay.  However, I say we need to build our software and systems as if they're exposed to the chaos the internet.  We need to stop pretending that something else will protect the business and IT from themselves.  The evolution toward cloud business services has already put many on this path.  Whether or not your software is aimed toward the cloud (sooner or later you'll likely have to face this anyway), it must be built in the same manner as cloud applications.  When the defenses turn out to fall short-- and they will, we need to be ready with secure code no matter where it is intended to live.

Anyone who has worked in security architecture for any length of time is familiar with the conversation.  In response to your assertion of an appropriately secure design, the response is, "you do realize that these are behind the firewall, right?"  A quick bite of the tongue gets me through this as I remind myself that the person who asked is in the majority for even technical experts in IT.  To be honest, if my phone had a dope slap button, I'd use that.

Example applications are COTS (consumer-off-the-shelf), customized COTS, or home-grown applications that are intended to support internal business functions only.  I'll refer to COTS, but any of these examples apply.

My approach to designing for security with any application or service is a simple recipe where I focus first on Authentication, Authorization, Audit Logging, and Encryption (AAA + encryption).  Of course there's more to security architecture than this, but these are the foundational ingredients for integration. For some business cases, you might add transactional integrity, but where I work that's a small percent of engagements.

COTS applications have been permitted to play by different rules when behind the firewall.  Perhaps on some level, this has allowed us to put off the investment that would be required to make them safe to use.  We have permitted these applications to have limited options for integration.  Many of these applications will simply assume that they'll be wired to LDAP or Microsoft Active Directory.  Add a user to the COTS_App_Users group and they can simply authenticate the way they do elsewhere and start using the tool.  Some might use propriety integrations, like CA's Siteminder or Oracle's OAM.  This checks off the authentication and coarse-grained authorization (either they are a permitted app use or not).

Depending on the platform, the audit logging might be standard Windows events or whatever the application decided to produce.  The standard audit log expectations should be authentication attempts (pass or fail) and CRUDE (create, read, update, delete, execute).  Typically an application will make authorization decisions in context for a transaction.  For example, an application might have to implement logic that ensures that the authenticated identity and the data ultimately go together.

(An ideal solution would have the application playing only the role of Policy Enforcement Point, deferring the authorization decision to a Policy Decision Point.  The simple reason is that this means that what is ultimately highly specialized business logic is handled by security practitioners-- by those who accept their role in the defense of the business's assets.  This concept is often called Externalized Authorization Management (EAM) and a great example of the architecture is codified in XACML.)

Finally, encryption can address the impact of a failure to protect data by other means.  In-transit, it assures that data cannot be extracted from hosts on the same network.  At-rest, it can address a failure to decommission hardware safely (the most common implementation for checklist security as far as I can tell).  This usually means encrypting a cluster, a drive, a partition, a database or a table.  It can also mean encrypting individual fields in a dataset, which is common for Identity Provider (IdP) implementations.  It might also include things like credit card numbers, social security numbers, and anything else that's considered an especially sensitive part of a record.

Usually encryption gets the most resistance from the walled garden camp because it complicates architecture and management (an apt concern from an operations standpoint). However, I have found that when the subject is integration in a cloud setting, as with a B2B SaaS, I get little resistance to granular encryption.  Everyone seems to agree that the data could fall into the wrong hands; that either the Cloud Service Provider (CSP) or another tenant might find their way to the data unexpectedly and that there should be some measure to address this.

Unfortunately, when the service is to be deployed behind the walled garden any perception of an especially high bar on all of these subjects tends to be discarded as we negotiate with ourselves on the way to releasing a service.

Not only is it less safe to bet the farm on what few likely understand and what will fail over time, it's short-sighted from a security perspective but, most importantly, from a business perspective.

The vendor who sells to big enterprise customers who own and run their own datacenters is failing to prepare themselves for the future when fewer and fewer people own their own datacenters (as cloud becomes a list of commodity IT services).  And for those who will hold on to their datacenters, they are likely to sell excess capacity as a CSP eventually.  This will mean that they too will want everything in their virtual stack and beyond to have protections that assume that they are or could be exposed to all of the threats implied by being directly on the internet.

The business that builds software for in-house use or to be sold to others to install is failing to accept that the perimeters and boundaries are already dissolving with the rise of BYOD.  How will its employees connect untrusted mobile devices to its industry-specialized time tracking software, for example? Beyond BYOD, how can that custom IT service management tool, for example, be extended for use by consumer tenants?  How will the authentication of your system handle identities from multiple organizations and not just the one reflected in your primary identity store?  How will your approach to authorization ensure that data can be protected in new contexts?  How can what wants to use your data be aware of and honor the policies for that data?  What if your software succeeds in ways that you never imagined in the beginning?

It is in the best interest for all to assume that the walled garden does not exist.  From there we need to make the investments in design, process, people, and infrastructure to support addressing increased exposure of systems.  I agree with Chris Hoff (@beaker), when he asserts that this is not a matter of working without perimeters but working with many more small, fine-grained perimeters.  Moving to the EAM approach and getting serious about encryption (and other crypto, like X.509) to whatever level is justified can be the foundation for these smaller perimeters. Supporting multiple user claims: system and on-behalf-of users rather than simple system-to-system service credentials is also essential, even on the backend. 

No comments: