Security is necessary for cloud adoption, and lack of security is often a cloud adoption show-stopper. However, with increasing security policy and compliance complexity, IT complexity, and IT agility, the task of translating security policies into security implementation gets more time-consuming, repetitive, expensive, and error-prone and can easily amount to the bulk of security effort for end-user organizations. Automation can help end-user organizations (and cloud providers) reduce that effort and improve policy implementation accuracy. This article focuses on one particularly interesting, challenging, and often forgotten topic: security policy automation for the application layer.
Cloud application security automation
Application security policy automation is about automating the process of turning human-understandable security requirements, such as enterprise security policies, compliance regulations, and best practices, into the matching technical security policy rules and configurations enforced at the application layer. To close the loop, it also includes automation of auditing; for example, collecting application layer alerts and mapping those back to the human-understandable security and compliance requirements in order to assess the security posture on an ongoing basis.
Anatomy of cloud application security policies
Application security policies are often particularly complex for interconnected, dynamically changing application landscapes, such as service-oriented architectures (SOAs), cloud application mashups, and other "plug and play" application environments. Such application environments are adopted for various business reasons, and security needs to support those reasons with the lowest overall maintenance effort possible. Automation is therefore key.
Security automation is especially important for cloud computing because cloud users demand support for regulatory compliance policy management from cloud providers, but at the same time judge the benefits by the same measures as they do for cloud computing in general (by how much it cuts their up-front capital expenditure and their in-house manual maintenance effort).
In general, "application layer security" is a lot broader than the policy automation aspects covered in this article, and also includes tasks such as vulnerability scanning, application layer firewalls, configuration management, alert monitoring and analysis, and source code analysis. A task that is particularly closely related to application layer security policy is identity and access management. While frequently viewed as having more to do with user identity management than with application security, identity and access management is actually often highly related to application layer security. This is because when users access applications and authenticate, an authorization policy needs to be enforced, which often depends heavily on the particular accessed application.
At that point, the hard questions arise: Where does this authorization policy come from? Who writes and maintains that policy? How is it enforced? How is it audited? These issues make the case for also using application security policy automation alongside identity and access management to make policy management less time-consuming, repetitive, expensive, and error-prone.
Cloud application security policy automation deployments today
Security policy automation in general, and specifically for cloud, is still in a relatively early stage. It mostly focuses around identity/authentication as a service (for example, Facebook connect). There are also some cloud-based security services (antivirus, e-mail scanning, intrusion detection system (IDS), log management), some of which are indirectly related to applications.
This article focuses on application security policy automation as a service, and there are only a few early-adopter deployments today: First, ObjectSecurity integrated its OpenPMF model-driven security policy automation product with a private platform as a service (PaaS) cloud (Intalio Cloud with Intalio BPMS), which offers seamless policy automation for cloud mashups. Another early-stage deployment involving OpenPMF is for the US Navy, and is somewhere in the grey area between private cloud and SOA. It involves policy-as-a-service for virtualized IT services in a high-assurance environment. Both case studies are covered later in the case studies section.
There are also a number of other deployments of model-driven security policy automation, but not for cloud, and mostly not involving policy-as-a-service.
The challenges to application security policy automation
Unfortunately, in most cases, security policy automation is easier said than done. This section outlines the reasons for these difficulties to achieving application security policy automation.
Policies become harder to implement and automate as policies get more meaningful to people and organizations
Many security tools today offer some degree of automation (maintenance-free) at the price of trading off relevance, correctness and automation: In some cases, automated tools are built with the assumption that the vendor knows what default security policies the end-user organization wants to implement. In other cases, products are built so they can heuristically learn policies over time. The shortcoming of both approaches is that there is a probability that they implement unintended, irrelevant, or incomplete policies even if the security mechanisms themselves work.
Such conventional security automation tends to work better for more generic security tools that do not require organization-specific policies and target the lower layers of the technology stack (for example, the network or operating system layer), such as antivirus, anti-malware, pre-configured network intrusion detection systems, and generic application vulnerability scanning.
Security automation becomes harder when organizational, user, and application behavior must be taken into account to enforce and audit security policies. For example, an organization that processes credit card payments will want to implement policies such as "no credit card information must leave the organization unencrypted," and "credit card information must be deleted when it is not used anymore." Another example would be a healthcare organization that will want to implement policies such as "doctors and nurses should only be able to access their current patients' health records, and only if they need access for a valid purpose, without an alarm audit log being created." Such complex and contextual policies depend on the particular organization's security policies, business processes, applications, and application interactions. Often the reason for implementing such complex and contextual policies is because end-user organizations must meet industry-specific regulations (PCI Data Security Standard-PCI DSS and Health Insurance Portability and Accountability Act-HIPAA).
Policies are becoming harder to implement and automate as they become more numerous, complex, feature-rich, fine-grained, and contextual
Conventional "authorization management," which is nowadays often categorized as part of identity and access management, illustrates these challenges: Policies become unmanageable when systems and participants are numerous, when interconnected applications evolve dynamically ("agility"), and when policies become feature-rich, fine-grained, and contextual. There are simply too many, too complex technical security rules to manage, so that authorization policies can become unspecifiable or unmanageable, and the confidence in the enforced policy can be undermined. As mentioned above, questions that need to be answered are: Where does this authorization policy come from? Who writes and maintains that policy? How is it enforced? How is it audited?
Policy automation becomes harder as IT landscapes get more agile and interconnected (especially for cloud mashups)
To support the adoption rationale behind agile application environments such as cloud and SOA, authorization management itself needs to be at least equally agile, and also automated, manageable, fine-grained, and contextual. Unfortunately, creating and maintaining consistent and correct technical security policies in the face of frequent dynamic system changes is a major challenge. This is because dynamic changes (for example, of cloud mashups) can render the implemented technical policies ineffective, and because application security policies are often particularly complex for interconnected, dynamically changing application landscapes, such as SOAs, cloud application mashups, and other "plug and play" application environments. Irrespective of those shortcomings, authorization management forms a critical technical building block to enforce and audit application authorization policies for all protected resources. It plays a critical part of cloud application security, and even more so for cloud mashups, because different actors (users or cloud applications) should only be able to invoke each others' services if they are authorized to do so in a specific situation based on security policies. An important authorization management standard is OASIS eXtensible Access Control Markup Language (XACML).
Regulatory compliance is a requirement that is related to policy, and therefore also needs to be supported by as much automation as possible
It is inevitable that enterprise cloud users will demand easy, low-maintenance (automated) compliance support for their cloud-hosted applications and services. This is because many cloud applications will deal with regulated information (privacy, health information, payment information) that will often cross organizational boundaries and needs to be audited. Compliance auditing cannot be the sole responsibility of the cloud user, because user visibility into the cloud stack is limited (especially for PaaS and software as a service, but also for Infrastructure as a Service). Regulatory compliance (just like security policy management and incident monitoring) will therefore have to be partly baked into the cloud platform.
Policy based on whitelisting is required, as blacklisting is not good enough anymore
As a reminder, blacklisting means you offer access to anyone not on a black list. Whitelisting means you only offer access to those on your white list.
The model-driven security component
To achieve automation, some "algorithm" needs to be able to understand the security policy requirements and everything the policy relates to (users, applications, application interconnections, and application workflows), and automatically generate the matching technical security policy implementation. Model-driven security facilitates this required level of security policy automation by applying the reasoning behind model-driven software development approaches to security and compliance policy management.
In essence, model-driven security can automatically generate technical authorization (and other) rules by analyzing the application with all its interactions, and applying generic security requirements to it. Model-driven security is a tool-supported process that involves modeling security requirements at a high level of abstraction, and using other information sources available about the system, especially the applications' functional models (produced by other stakeholders), to automatically generate fine-grained, contextual technical authorization (and other) rules. The inputs into model-driven security are expressed in Domain Specific Languages (DSL), using generic modeling languages (such as, Unified Modeling Language-UML) or Enterprise Architecture Frameworks (EA Frameworks) (for example, Department of Defense Architecture Framework-DODAF, Ministry of Defense Architecture Framework-MODAF, and NATO Architecture Framework-NAF).
Capturing security requirements does not have to be done using a graphical editor; it can also be done using a textual model editor (for example, in a modeling tool such as Eclipse). These are then automatically transformed into enforceable security rules (access control and monitoring rules) by analyzing information about the applications with all their interactions.
The model-driven security runtime supports the runtime enforcement of the security policy across all protected IT applications, automatic policy updates, and the integrated monitoring of policy violations. In the first step of model-driven security, regulations and governance standards are modeled (or selected from pre-built templates) as a high-level security policy in a model-driven security tool. This security policy model is then applied to the functional models of constituent systems by mapping security policy model actors to system actors and constraining the behavior of those system actors in accordance with the security policy model.
From a technical perspective, these (security and functional) models are automatically translated into low-level, fine-grained, contextual security policies and enforced across the entire cloud orchestration, cloud mashup, or SOA environment (for example, through local enforcement points integrated into the middleware or at a domain boundary). The local enforcement points also deal with the monitoring of security compliance relevant events. And whenever the SOA application (or its interaction configuration) changes, model-driven security can automatically update security enforcement and monitoring.
In summary, the model-driven security process can be broken down in the following steps: policy modeling, automatic policy generation, policy enforcement, policy auditing, and automatic update. Let's examine how each of those steps work in the context of cloud applications.
Model-driven security architecture
The diagram in Figure 1 illustrates the basic architecture: The top left shows the cloud-based development and mashup environment (Business Process Management System (BPMS)-orchestrated web services). It also shows that model-driven security components need to be installed (by the cloud provider) into the development/mashup toolchain to automate the policy generation.
The top right shows the cloud security service that provides PaaS the model-driven security add-on to the development tools with regular policy updates in a generic form; it also shows the runtime management (monitoring/analysis/reporting) functionality offered by the cloud security service.
The bottom shows some cloud services deployed on application servers (and the rest of the cloud runtime stack) with Policy Enforcement (PEP) + Monitoring points that need to be installed (by the cloud provider) with the runtime stack.
When an application is developed and integrated, model-driven security automatically analyzes the application and the policy models and generates technical rules that are automatically pushed into the relevant PEP/Monitoring points. Whenever a message passes between any of the protected services, model-driven security automatically evaluates and enforces the technical policy, and — if needed — pushes an incident alert to the runtime security policy management feature of the cloud security service.
Figure 1. Architecture overview: Model-driven security policy automation using PaaS for cloud
When employed effectively (see Case studies), model-driven security has a number of benefits:
- It reduces manual administration overheads and saves cost/time through automation (policy generation, enforcement, monitoring, update) — especially for agile software applications.
- It also reduces security risks and increases assurance by minimizing human-error potential, and by ensuring that the security implementation is always in line with business requirements and with the functional behavior of the system, thus improving both security and safety of the system.
- Furthermore, it unites policy consistently across security silos (for example, different application runtime platforms).
- Finally, it forms part of a more automated model-driven approach to agile accreditation.
Model-driven security adoption sometimes still gets challenged for a several reasons:
- Dependence on application specifications and a reasonably well-defined Software Development Life Cycle-SDLC; however, modeling aspects of the interconnected system (especially cloud mashup interactions) is an important part of state-of-the-art cloud PaaS and mashups and is also part of robust systems design.
- Effort of modeling systems and security policies. However, modeling systems at the right granularity (for example, cloud mashup models) does not actually add to the total cost of policy management. This is because if security administrators have to manually specify detailed technical security rules because their tools do not support model-driven security, they are effectively specifying the security related aspects of the application specification within their policy administration tool. In practice, this is impossible for non-trivial systems, especially over the whole system lifecycle. Model-driven security simply reuses this information (which often makes up the greater part of security policy rules) from models specified by specialists (and/or tools) who understand applications and workflows better anyway (application developers/integrators and process modelers).
From practical experiences, even after only a short while in operation, model-driven security can greatly reduce costs of effort of protecting the system and improve security and safety compared to traditional, manual policy definition and management.
Achieving cloud application security policy automation
With the emergence of cloud PaaS, it is logical to move all or parts of the described model-driven security architecture into the cloud to protect and audit cloud applications and mashups with maximum automation. In particular, security policy models are provided as a cloud service to application development and deployment tools (policy-as-a-service) and policy automation is embedded into cloud application deployment and runtime platforms (automated policy generation/update, enforcement, monitoring).
Different cloud deployment scenarios are possible; for example, the security features in the development tools and application platform are all hosted in the same cloud service as part of a PaaS provisioning, or where some security features are hosted separately (especially policy configuration and monitoring). This differs from local non-cloud deployments, where model-driven security is conventionally installed within or alongside a locally installed development tool (such as Eclipse) to protect applications on a number of local runtime application platforms (for example, web application servers) and to support local monitoring and reporting.
As previously described, the general model-driven security process can be broken down in the following steps: Policy modeling, automatic policy generation, policy enforcement, policy auditing, and automatic update. Let's examine how each of those steps work in the context of cloud applications. In the context of cloud, the five steps of model-driven security are described below.
Policy configuration in the cloud (policy-as-a-service)
In the cloud version of model-driven security, policy configurations can be provided as subscription-based cloud service to application development tools. Offering specification, maintenance, and update of policy models as a cloud service to application developers and security experts has significant benefits: Most importantly, instead of having to specify (or buy and install) and maintain the policy models used for model-driven security on an on-going basis, application developers and security specialists can now simply subscribe to the kinds of policy feeds they require without the need to know the details of the models.
The policy-as-a-service provider (typically different from the cloud provider) takes care of policy modeling, maintenance, and update. Other benefits are that the user organization does not need to be a security and compliance expert because the up-to-date policy models will be provided as a feed to them on an on-going basis, that the upfront cost hurdle is minimized thanks to the subscription model, and that there is no need by the end user organization to continually monitor regulations and best practices for changes.
For more complex policies, some simple setup and some potential tagging of security-relevant information may be necessary: For example, for a PCI DSS policy model subscription, payment information-related interfaces may need to be tagged alongside the application mashup models. The more pre-packaged cloud modules are integrated in the cloud, the less tagging by the end-user organization is required because cloud modules can already be pre-tagged by the cloud provider (for example, PCI relevant tags for payment processing modules).
In general, the described outsourcing model is not new. It has been successfully used for years for other aspects of security, such as antivirus and antispyware. Users simply subscribe to a policy feed from the antivirus provider and let the antivirus software client automatically enforce that policy (but in contrast to antivirus, this article illustrates the outsourcing model applied to cloud application security).
While it is only natural to challenge the trustworthiness and reliability of a cloud-based authorization policy management service (especially for mission-critical environments), the implications of such a deployment scenario need to be seen in relation to the inherent level of trustworthiness and reliability of the protected cloud applications. If the protected cloud services themselves are accessible over the Internet, then many attacks on the policy management service (for example, denial of service) could also directed at the protected services themselves — in this case, the cloud-based policy manager does not add to the risk. If more trustworthiness and reliability are required, say for a private cloud with Quality of Service (QoS) enabled, then hardened infrastructure would be required for both the policy manager and the protected services. In summary, cloud-based security policy management will be the right choice for many services provisioned for many organizations, but not for all.
Automatic technical policy generation in the cloud
The automatic policy generation feature of model-driven security is integrated into the development, deployment, and mashup tools (to get access to functional application information). It consumes the policy feed described in the previous section. PaaS sometimes includes both cloud-hosted development and mashup tools and a cloud-hosted runtime application platform. In this case, automatic technical policy generation using model-driven security can also be moved into the cloud, so that technical security policies can be automatically generated for the applications during the cloud-hosted development, deployment and/or mashup process. This is in particular the case for mashup tools, because those tools are more likely to be cloud-hosted, are often graphical and/or model-driven, and are concerned with interactions and information flows between cloud services. If the development tools are not hosted on the PaaS cloud, then the model-driven security technical policy auto-generation feature needs to be integrated into the local development tools.
Automatic security policy enforcement in the cloud
Policy enforcement should naturally be integrated into the PaaS application platform so that the generated technical policies are automatically enforced whenever cloud services are accessed. As described in the previous section, policies are either generated within the cloud using hosted model-driven security and PaaS development tools or are uploaded from local model-driven security and development tools.
How policy enforcement points are built into the PaaS application platform depends on whether the PaaS application platform: Allows the installation of a policy enforcement point (for example, various open-source PaaS platforms; see Case studies); supports a standards-based policy enforcement point (for example, OASIS XACML); or supports a proprietary policy enforcement point.
Automatic policy monitoring into the cloud
Policy enforcement points typically raise security-related runtime alerts, especially about incidents related to invocations that have been blocked. The collection, analysis, and visual representation of those alerts can also be moved into the cloud. This has numerous benefits: Incidents can be centrally analyzed for multiple cloud services together with other information (such as network intrusion detection); also, an integrated visual representation of the security posture across multiple cloud services can be provided; integrated incident information can be stored for auditing purposes; and compliance-related decision support tools can be offered as a cloud service.
The described model-driven approach enables automatic updates of technical security policy enforcement and auditing whenever applications, and especially their interactions, change. The same automation is possible when security policy requirements change.
How end-user organizations and cloud providers can use security policy automation
The described policy-as-a-service approach removes much of the burden from end-user organizations, and also from cloud providers:
- Security professionals in end-user organizations simply need to subscribe to the policy-as-a-service security option with their cloud subscription, potentially adopt some simple security tagging features (or educate their developers), and check the compliance reports regularly. But before that can happen, an important job for security professionals is to demand policy automation from their cloud providers (especially for private clouds).
- Application developers/integrators in end-user organizations simply need to use the policy-as-a-service enhanced mashup/development tools provided by the cloud provider and potentially adopt some simple security tagging features.
- PaaS cloud providers will enable all this simplicity for the end-user organization by going through the following steps to implement policy automation: First, they will set up a subscription and service-level agreement with the policy-as-a-service provider. Next, they will need to get the model-driven security automation software and the enforcement/monitoring software from the policy-as-a-service provider and install it into their PaaS mashup/development tools and runtime platform, respectively. They will also need to provide end-user organizations with the relevant security subscription options, manuals, and access to the compliance reports created by the policy-as-a-service provider. In the near term, private cloud providers will be more likely to offer such services (see case study below) than public cloud providers, because private clouds are used for more mission-critical uses.
New concept or used before?
Some security tools are available as cloud services (security-as-a-service), for example, for web application testing. However, model-driven security for authorization management as a cloud service (policy-as-a-service) has not (to the knowledge of this author) been implemented before, mainly due to the slow adoption of standards, especially for PEPs. The author avoided this problem for the OpenPMF reference implementation (see Case studies) by directly collaborating with the cloud provider. This way, suitable integration points could be developed into their infrastructure.
Now let's look at some cases.
Application security policy automation for a private cloud
ObjectSecurity's OpenPMF implements application security policy automation for a number of different technologies. In the conventional installation, OpenPMF is used as a local development, orchestration, and compliance monitoring/reporting tool add-on that resides within or alongside a locally installed development tool (for example, Eclipse, Intalio BPMS), to protect applications on a number of platforms (various web application servers, Java EE, Data Distribution Service-DDS, CORBA/CORBA Component Model-CCM). With the emergence of PaaS, it was only logical to also make OpenPMF itself available on demand as a cloud service.
For example, for application security policy automation for a private cloud, the described move from local policy automation to cloud-based policy automation has been integrated into an Intalio cloud. The Intalio cloud is a full-stack, open-source cloud offering that includes the necessary prerequisites for policy automation, including application development and integration using business process modeling (see figures following), and a web service-based runtime platform. The current technical integration of OpenPMF is done for development (Intalio BPMS/Eclipse), runtime (Apache Axis2), and authentication/encryption (Secure Sockets Layer-SSL/Transport Layer Security-TLS). Figure 3 shows the policy automation features embedded into the BPM web service orchestration tool (menu OpenPMF > Generate Security Policy). When clicked, the detailed technical security rules for the specific application are automatically generated (Figure 4).
Figure 2. Installation (for cloud platform providers)
Figure 3. Automatic policy generation (for PaaS users)
Figure 4. Technical policy deployment (for PaaS users, or full hidden)
Figure 5. Runtime monitoring (users and Policy as-a-Service provider)
Model-driven security deployment for cloud and SOA
Model-driven security policy automation is currently being implemented in a real-world operational deployment for the US Navy by ObjectSecurity, an application security policy automation vendor, and prime contractor Promia, a provider of secure technologies to government and industry. The deployment is much more comprehensive than what is described in this article in that it deals with all layers of the cloud and SOA stack, especially applications, middleware, virtual machines, operating system, and network. The project provides an effective means to efficiently manage information assurance for dynamically changing interconnected SOA and cloud applications, and in particular a facility to expedite agile change, rapid certification and accreditation, and flexible policy management.
The technologies used (see Figure 6) include: ObjectSecurity OpenPMF model-driven security, application security monitoring, and policy management; Promia Raven intrusion detection, monitoring, auditing and XML information exchange capabilities; security-enhanced cloud and SOA development and deployment tools that enforce a secure development lifecycle; scalable Authorization Based Access Control (ZBAC) to distribute authorizations; a hardened, trusted runtime platform with full-stack protection that hosts SOA/cloud applications and protection; and a management system with global, full-stack policy management and automation, reporting, accreditation automation and decision support, configuration, versioning, scanning, and testing.
Figure 6. Implementation of model-driven security policy automation
In conclusion, this article illustrates that security and compliance policy management for agile distributed application landscapes such as cloud mashups needs to be model-driven and automated in order to be agile, manageable, reliable, and scalable. This involves two core concepts: First, policy configuration is provided as a subscription-based cloud service to application development tools (policy-as-a-service); and second, technical policy generation, enforcement, auditing, and update are embedded into cloud application development and runtime platforms. By moving security and compliance policy automation for cloud applications and mashups into the cloud, cloud applications and mashups are protected more seamlessly within the overall rationale behind cloud adoption. This also improves and simplifies the secure software development lifecycle for cloud applications.
Here are several concrete recommendations for next steps to get you started with model-driven security automation:
- Try it out
Cloud providers should try embedding security policy automation into their platform (for example, get a free trial of ObjectSecurity for Eclipse to get started). For cloud users, try out model-driven security policy automation if you are building cloud applications in IaaS or PaaS clouds that support model-driven mashups and policy automation or at least authorization management (for example, get a free trial of ObjectSecurity's tool for Intalio Cloud).
- Plan for it and sell the vision
If you are in the planning stages of cloud adoption, you should plan your architecture to support policy automation even if you are not implementing it right from the beginning. Model-driven mashup tools are particularly effective in supporting policy automation, and you can use the "sum is bigger than its parts" argument when selling both policy automation and mashup tools to your management.
- Demand policy automation from your cloud providers if possible
Show your cloud provider that technologies and approaches are available and how they can help you deal with cloud security more cost effectively. By default, cloud providers seem to provide "take it or leave it" cloud offerings that do not assist security professionals in doing their jobs best. Unfortunately, some cloud providers (especially PaaS) do not open up their infrastructure, so integrating your own policy automation product can be a challenge. Security professionals need to ask the right questions to move cloud providers in the right direction or choose a more open cloud provider.
- Integrate third-party policy-as-a-service when appropriate
If you deploy private clouds for a larger organization, consider the use of third-party cloud application security policy automation products based on standards; this way, you can subscribe to the policy-as-a-service from a third-party security specialist, while the application layer enforcement is done by the standards-based features of the cloud provider (for example, eXtensible Access Control Markup Language (XACML)).
- Integrate third-party incident monitoring and analysis services when appropriate
The same applies to monitoring — if your cloud provider does not provide what you need, make sure that alerts can be exported in a standard format (for example, syslog) for further processing by third-party products.
- ObjectSecurity's OpenPMF helps develop, operate, and maintain secure applications by easing management of application security policies for access control and auditing.
- An exemplary reference to model-driven security can be found in Access Policies for Middleware.
- In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
- Find technical articles, tutorials, communities, wikis, and business resources that should be interesting to you if you work in a specific industry domain on IBM developerWorks Industry zone.
Get products and technologies
- See the product images available on the IBM Smart Business Development and Test on the IBM Cloud.
- Join a cloud computing group on My developerWorks.
- Read all the great cloud blogs on My developerWorks.
- Read and discuss the latest news related to Model Driven Security, Model Driven Architecture Security, and secure MDA on the Model Driven Security blog community forum.
- Join the My developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.