This blog is co-authored by Dominik Witte:
Dominik Witte is a security consultant and professional trainer for SecurIntegration
After the mainframe and the client-server-area, Service Oriented Architecture (SOA) appear to be a promising approach for meeting the challenge of constant change of today’s businesses. The business must not be interrupted, that is a fast composition and adaptation of applications must be possible. A flexible "applistructure" is needed in order to drive the business (and not to be driven). When we talk about Enterprise SOA, we think about services on the enterprise level: there are reusable business service modules with standardized Web-service specifications. The applications are composed and implemented while being in the middle of the process – when you need it and how you need it. So far, nothing much new. As security experts, however, we started to think about security in the Enterprise SOA context. What paradigms will work as we knew them? What has to be extended or even reinvented? In this article, we discuss how we see a transition from known approaches to an enterprise service context. After a short introduction, we present 10 security challenges that we have identified and discussed with enterprise users (e.g. at the International Security Conference 2006 in Krems, Austria or at the latest DSAG meeting in Walldorf). Furthermore, we dig deeper into the first of the challenges ("how to get authorizations done in a distributed service environment?") and also show some answers. Each of the subsequent articles will explore another Enterprise SOA security challenge. Of course, we will also have a look at your feedback.
Misleading Assumptions – Some Examples
There are many false beliefs that lead to a false sense of security. A typical misbelieve is that infrastructure security mechanisms such as firewalls and IDS, will guarantee security. This is not necessarily wrong. But it is usually not sufficient. An Enterprise Service talks a high level protocol and uses specific interfaces. If the firewall or IDS don’t know about them, they cannot protect enterprise assets. As a consequence, the service itself must be robust against malicious usage itself. Another misleading thought is that the vendor protects all your assets as the products are shipped with a variety of security features (e.g. I&A, access controls and encryption). While modern business process platforms are equipped with every state-of-the-art security feature, it’s still up to the customer to use them appropriately. This is challenging, if the typical enterprise borders begin to vanish in a service environment. Developers want to deliver high quality software. Software has to be fast, usable, accessible, maintainable, etc. There are many qualities that have to addressed and the time-to-market pressure allows only very limited time for addressing them all appropriately. As security is a very, very complex topic, we assume that the average developer is not a security expert. Thus, we conclude that it is very likely that certain security issues will be missed. Some people also confuse safety and security. No doubt, safety is one of the most critical system properties. However, safety features do not necessarily lead to security features. On the other hand, security features are a prerequisite for safety. Rethinking Security: 10 Challenges for Secure Enterprise SOA
Why do we have to rethink security? There are many security guidelines for Web-based applications out there. However, they do not fit for large business systems. Sometimes they are not applicable or not relevant. In any case, they are not ‘Enterprise Scale’ (see Enterprise Application Security (EAS) Project). Therefore, we have identified the following 10 challenges - Authorizations
- End-to-End Security
- Interoperability
- Secure Configuration
- Quality of Service
- Secure Development
- Assurance
- Regulatory Compliance
- Auditing
- Migration of Legacy Applications: new context, new security!
Challenge 1: Authorizations
Authorizations are a function that is most severely affected in an Enterprise SOA world. Traditionally, authorizations are used to protect business functionality (i.e. processes) of an application server such as SAP R/3. Authorization checks are hard-coded in the respective applications and modules and are enforced by the application server. In the SAP field, we have for instance the "AUTHORITY-CHECK" statements in ABAP and PFCG roles for authorization decisions. In an Enterprise SOA scenario, however, there is no central application server anymore that can enforce authorization restrictions. Instead, business processes spread across a variety of servers, each one providing selected elements of the process – the enterprise services. This implies the definition and implementation of multiple authorization concepts, possibly for completely different systems. These additionally need to form a consistent overall concept for the business process to be protected: If for one single system authorizations are not set properly, the complete business process might be unusable. The same is true for the user management: Users that shall be able to use a business process need to have a user account in all systems and be granted adequate permissions. This can create tremendous administrative maintenance efforts. In order to ensure maintainability, user and authorization management should be centralised where possible. This implies organizational measures (e.g. the setup of a central authorization team in your company) as well as technical measures. For the latter, SAP provides several building blocks that can help you in centralising common administrative tasks: A central user management is possible via SAP’s central user administration (CUA) and the LDAP interfaces provided in NetWeaver Application Server ABAP and Java. This way, you can create new user accounts in one designated system, grant all relevant authorizations and have the information propagated to all other systems participating in an SOA. Especially in heterogeneous scenarios where non SAP systems need to be considered, too, LDAP should be the preferred way. Being an industry standard, it is widely supported by enterprise applications and also allows for an integration in a company-wide identity management solution. For more complex authorization assignments, especially when approval processes are involved, Access Enforcer (part of the SAP GRC Access Controls) comes into play. It allows a central provisioning of authorizations for SAP and non SAP systems including complex and customizable workflows. Wrapping it up, before implementing an Enterprise SOA landscape, carefully inspect your current user and authorization management. A cleaning-up and integration of existing identity management applications and processes might be required and will certainly ease management of the new Enterprise SOA processes after go-live.
Now the next Challenge ...
Read more about the 2nd Challenge: End-to-End Security
