With the advent of mashups, innovative developers all over the enterprise are seeking new ways to leverage the value of corporate information through the use of external Web applications, APIs, or services. Although the thought of this adventure has sent many corporate security specialists running behind their firewalls, mashups are here to stay. Indeed, they have strategic value for many enterprises, so you’d better figure out how to live with them.
Here’s how to deal with the risks around mashups -- and how your enterprise can have its cake and eat it too.
Mashups seen and unseen
Although enterprise mashups (and the problems they inherently create) are new, solution patterns are already emerging. Broadly speaking, there are two types of mashups: presentation-centric and data-centric. Each has a different set of security issues.
The Google Maps variety of mashup typifies the presentation-centric type. In many instances they are dashboards, portals, or reduced-size data displays for mobile devices. The formula is simple: Take two or more different resources and create something that is more useful than the sum of its parts. It’s easy to see the value because it’s right there on the screen in front of you.
Presentation-centric mashups are already infiltrating the enterprise with or without the knowledge of IT. A typical example: customer information mashed together with Google Maps in support of a delivery schedule application that maps customer addresses, creates routes, and even examines traffic to expedite deliveries.
While clearly a valuable application, important customer information is in play. Steps can be taken to make sure the information remains behind the firewall. But in many instances, the information has to be transmitted to the Web application over the Internet, and therein lies the problem.
Data-centric mashups, on the other hand, combine two or more services to create an integration point that serves a true business process. They may operate behind the scenes and never appear on screen, at least not directly, but they are mashups nonetheless. This is actually lightweight XML integration and may involve all manner of vital information, depending on what’s exposed or available. Data-centric mashups present the greatest security challenges because they have the potential to do the most harm. Indeed, megabytes of valuable customer or financial data could be compromised in just a few seconds if a rogue data-centric mashup is created.
Transmitting private information outside the firewall without encryption or other security measures invites disaster. For instance, leveraging an Internet-based service to calculate the risk of a financial trade is certainly a valuable thing to mashup with existing trade information on the corporate mainframe. But flowing that trade information through that Internet-hosted service opens a big, fat vulnerability.
Five mashup security strategies
To get the most from an enterprise mashup, you need to strike a balance between the value of the mashup and the need for security. There are several security approaches to take: policy level, data access level, service access level, screen access level, and identity management.
Policy level security refers to design-time policies and procedures. The policy-level approach typically doesn’t deal with the underlying technology, nor security tools and technology, but addresses security threats through rules, governance, procedures, and education. There are legal issues here as well: Sarbanes-Oxley compliance, for example, or the use of published polices that could protect corporate assets and provide a means to fire employees who violate those policies.
To create a security policy for mashups, you need to run through the use cases and examine how the information and behavior of the underlying corporate systems should be protected. Most enterprises have existing guidelines for security, including policies that may state that data can’t be transmitted outside the firewall without encryption, or that all use of information within a mashup needs to be reported to IT -- or, in some instances, that mashups are not allowed at all.
Indeed, the knee-jerk reaction to mashups has been to not allow mashups before the security organization can wrap its arms around the risks – in much the same way that the Web was initially branded a liability and temporarily banned in many large corporations a dozen years ago. In hindsight, they were right. But just as the obvious value of the Web overcame worry about risks, so will the value of mashups as balanced security polices emerge.
Data-access level security controls access to underlying databases and data stores, ensuring that information leveraged by mashups won’t be compromised. While policy applies here as well, this is mostly a matter of technology to provide the protection, or layers of security between the data and the mashup.
Security at the data-access level is pretty traditional, including password protection at the database, table, and record levels. The mashup must provide credentials in order to consume the data from the data store, but what the mashup does with that information is out of the control of the data-access level security mechanism. That’s where published policies take over…we hope.
Service-access level security is similar to that of security at the data level. Services may exist as part of ERP or CRM applications, for instance, or as new services built in support of an SOA. Typically, but not always, services are accessed via Web service protocols. Services can be mashed up with either presentation- or data-centric mashups -- and therefore must be treated as services that can produce both information and/or behavior. Either way, they must be protected.
Security at the services level depends upon the system in which the services reside. SAP, for instance, employs its own security subsystem to validate access to its APIs or Web services. The mashup must provide the proper credentials in order to access the service or API, but after that, it’s still available for access within the mashup and perhaps to external Web applications as well. So as with data-access level security, a lot depends on the care of the mashup builder.
Screen-access level security provides user ID and password gatekeeping for information transmitted to a user interface. So-called “mash-at-the-glass,” presentation-centric mashups deal with information sent to one screen (the enterprise application) and can be mashed together with information from other screens (Web applications).
The issue with screen access is that any information delivered to the user interface -- a GUI application, Web application, or even an old mainframe terminal app -- can be extracted as if you’re talking directly to the database, service, or API. Those who use the screen must and should be validated through user IDs and passwords. Again, you need to trust that the information process won’t fall into the wrong hands.
Identity management recognizes that services aren’t for internal use only. Mashups that leverage services and corporate data need to be known and authorized, or you open the door to malicious or incorrect behavior. The basic idea behind identity management is to monitor all services’ producers and consumers and ensure that the services invoked are indeed the services meant to be invoked. In other words, all consumers are known, identified, authorized, and tracked -- as are all producers.
This is clearly the best way to approach mashup security since you’re dealing with many services – and the mashups themselves -- each with their own identity information. Identity-based monitoring ensures the correct services and mashups are interacting and exchanging only authorized information, and that there are no shenanigans taking place (intentional or not). Since you can track things at the component level versus the system or data levels, there is much more granularity to this security approach and thus more flexibility for mashups.
Today, most enterprise mashups don’t use services or data controlled through an identity management infrastructure. The increased popularity of SOA will drive identity-based security, but for now, it’s not an option for most enterprises, due to cost and the newness of the technology.
Rolling out a secure platform
Moving from a security strategy to a real-world plan can be tough, thanks to the early-stage nature of the mashup trend. Nonetheless, a few best practices have already emerged:
Create a mashup development and operation policy for your enterprise, clearly defining what’s allowed and what’s not allowed when creating mashups. Follow up the policy with a mashup validation and verification process that’s equally clear, well-communicated, and (hopefully) followed to the letter. Make sure that all mashup development is known to the security team, and that they work with the mashup developers on guidelines and best practices to insure security is not an afterthought. The idea is to balance the need for security with the need for innovation.
Create a technology suite approach to mashup security, selecting key existing technology and standards for data-access level, service-access level, and access to information through user interfaces. Typically, you’ll deal with enabling technology already in place, such as security subsystems already bound to databases, APIs, and user interfaces. This is not optimum, but it’s the way security exists for mashups today. Both security professionals and mashup developers need to learn how to leverage it properly and enforce well-defined policies as previously outlined.
Create an identity management strategy around both SOA and mashups, which are really extensions to SOA in the first place. This means creating an identity management model for the architecture, including patterns of use within mashups. Then select the right identity management-based security technology, and develop a path to implementation. Typically, this is a long-term project, and it takes careful planning to get it right the first time.
Given the gestation period for identity management, most organizations will be forced into the policy and existing technology approaches first. But it’s worth it: Mashups offer a valuable new platform to quickly create enterprise applications that are practical and useful. And whether IT acknowledges it or not, increasingly sophisticated Web development is happening under the radar anyway. Properly implemented, a mashup strategy can provide a framework to bring all sorts of Web development into the fold.