Application Security Grows Up

A few years ago, The Walt Disney Company came to the realization that continuing “business as usual” in terms of application security was unacceptable.
Why? They did not consider their existing security systems flexible, efficient or cost-effective enough. For example, they were unable to produce a report that showed the access a user had across all systems, or what function that user performed across systems in a given time period. Various applications and web services were secured using a myriad of administrative tools, which ran the risk of increasingly disjointed security controls and required time-consuming administrator training for every individual system.

The Walt Disney Company faced additional challenges. Its existing security system offered no way to enforce segregation of duties across the organization and across any application. It was clear that applications that needed disconnected mode were not being secured properly or consistently, and applications in general lacked security best practices. The final straw was the realization that developers were spending too many hours re-creating the same authentication and authorization logic over and over when developing new applications.

The CIOs at every business unit and the Enterprise Architecture Board of The Walt Disney Company took these matters very seriously and were determined to address them decisively. However, an exhaustive search of the marketplace failed to produce a workable, comprehensive solution.

“We recognized a big problem in user authorization, controlling which users had access to which roles, function, and data in an application,” said Steve Davis, chief architect and VP Information Technology for the Walt Disney Studios. “We went to the marketplace, but there was a gap between our requirements and what was available.”

So Disney decided to build its own Identity Centric Architecture Engine. I was assigned to deliver the technical architecture and solution for the enterprise. During our initial analysis phases, I was amazedat how much companies were willing to pay to implement simple solutions such as authentication, provisioning, and single sign-on. I did not consider these capabilities worth hundreds of thousands of dollars, and in some cases even millions. To me, this wasn’t rocket science. While role based access control was a good baby step that seemed attractive given the available technologies, I was confident we could build a holistic system that included single sign-on, provisioning, attribute-based authorization, fine grained authorization, web services security and disconnected-mode authentication and authorization.  We also wanted to take into account the investments already made in the company’s existing security environments. So we built a solution that didn’t need to replace what had already been purchased and integrated, but rather one that augments and extends the existing identity management infrastructure to allow the enterprise to have a unified and consistent way to secure every single business application – including web services, Java-based applications, web applications, .NET and .NET compact framework solutions, AS400 systems, file systems and much more.

The Technical Dilemmas
I’m often asked the difference between Role Based Access Control (RBAC) and Fine Grained Authorization (FGA), and it’s crucial to know the answer in order to appreciate the power and flexibility of Identity-Centric Architecture.

RBAC is the basis for coarse grained authorization. I find it inadequate for the needs of large enterprises. Why? If developers hard code things such as “if the user is VP of Finance, allow closing of a fiscal period”, what happens if business requirements change and now a Director of Finance must also be allowed to perform this function? With simple RBAC, a developer would have to retrofit the source code of the application to accommodate that one simple change. This might sound simple, but it’s not. Accommodating that change requires identifying where in the source code the change must be made, making and testing the code change, compiling the application, performing regression testing to ensure that the application operates properly, and only then deploying the application. A change as simple as “also allow a Director to perform a function that a VP can do” might cost a company anywhere from $2,000 to $6,000 – and that assumes the change is made successfully the first time.

What about an audit trail revealing when the change was made, by whom, and approved by whom? When code changes, there is no simple solution to provide reporting in a consistent fashion. In addition, what does it mean to a new auditor that Joe X is now a Director of Finance? How does an auditor know that a Director of Finance is authorized to close a fiscal period? The short answer is – there is no way of knowing, not in RBAC. All a Role-Based Access Control system will tell you is a user’s role; the definitions of that role must be derived from asking people, or perhaps by researching source code. That kind of time-consuming, unreliable information gathering is not likely to happen, meaning the reports auditors look at are, in most organizations, virtually meaningless. RBAC has very clear limitations.

On the other hand, fine grained authorization never requires developers to modify the code once it has been deployed. Why? Because the formal definition of what a role means is clearly described and is externalized away from application logic. For example, the application code asks the fine grained authorization engine things like, “Does this particular user have read access to this field?” Whether or not the user is granted access depends on how the user’s role maps to the use case, and how the use case maps to the field. In fine grained authorization, more layers of abstraction not only allow user X to perform role Y, but provide a formal definition of what role X means in terms of functionality and access to resources.

Introducing Keystone
My team and I worked diligently on a new and comprehensive security solution. The result of our labor was Keystone, and its invention turned out to be a real homerun for Disney IT. Developers throughout the company embraced it because of its robustness and ease of use. And administrators finally had a unified way to secure applications with unlimited power.  This means an administrator using Keystone can easily and graphically set that the function “Issue a credit” can only be allowed to be performed from a particular IP or IP range, on certain days of the week, between certain dates – and only if it’s raining outside. As absurd as this seems, this example demonstrates the flexibility of the system. Creating rules like this no longer required modifying application code. Applications could now be deployed, and then security rules could follow and be changed post-deployment.

In addition to the flexible authorization capabilities, Keystone’s authentication abstraction layer allowed organizations to change the underlying directories, or to add multi-factor authentication without touching the application code.

Disney’s ongoing benefits include significant cost reduction in application development, as well as extensive audit trails of every authentication, unsuccessful authentication, metadata changes, and extensive reporting (e.g., what functionality a user can perform across all systems, what a user did, who gave them access to those functions, when and from which workstation, etc.)

ICA solution finds a home at BiTKOO
Once we witnessed how the Keystone solution revolutionized IT security at Disney, we knew other organizations would also benefit from this powerful authentication abstraction layer and a fine-grained authorization engine. We decided to make Keystone a commercial product, and I left Disney in 2006 to co-found BiTKOO, a company focused on delivering innovative security solutions. The Walt Disney Company licensed Keystone exclusively to BiTKOO, and Keystone is now on its third major release as commercial software. It’s a mature, battle- proven, highly available solution, and it works straight out of the box. It is the only solution that is Internet scalable and which provides features such as federated authorization (a BiTKOO exclusive), disconnected mode authentication and fine-grained authorization.

The Burton Group analyst firm called Keystone “cutting edge” and featured a presentation on Keystone at its annual Catalyst conference. Along with the developers at Disney, it realized that the implementation of Keystone has changed the way people think about securing applications of any kind.
Given all the benefits of Identity Centric Architecture, there is no question in my mind that Identity Centric Architecture is a prerequisite ingredient for the continued evolution of computing.

Interested in test driving Keystone in your environment? Contact info@bitkoo.com to request a virtual machine image. BiTKOO will provide your organization with a download URL that works the first time you run it. It integrates with your existing infrastructure, whether you run Linux, Unix, AS400, Windows or MAC OS. It will connect to your LDAP, Active Directory RSA SecurID or any other authentication source, and will provide you with unlimited flexibility in authentication and authorization. Contact Andra St. Ivanyi at BiTKOO to find out more about Keystone.

www.bitkoo.com
E: Andra@bitkoo.com
T US: 888.4.BiTKOO /888.424.8566
T Intl: 001.818.985.4700