Model-driven cloud security-automating cloud security with cloud application security policies

Security is an essential element of using cloud technology, and lack of security often hinders the adoption of cloud technology. However, as security policy and compliance complexity, it complexity, and it agility increase, the task of translating security policies into security implementations becomes more time-consuming, repetitive, expensive, and error-prone, and can easily increase the security workload of end-user organizations. Automation helps end user organizations (He Yun providers) reduce this workload and improve policy implementation accuracy. This article focuses on a particularly interesting, challenging and often forgotten topic: the application layer's security policy automation.

Cloud Application Security Automation

Application Security Policy automation is primarily an automated process that translates human-understandable security requirements, such as enterprise security policies, compliance regulations, and best practices, into the corresponding technical security policy rules and configurations implemented at the application layer. At the end of the cycle, it also includes audit automation, for example, to collect application-level alerts and map them to human-understandable security and compliance requirements in order to continually assess security posture.

Analysis of cloud Application security policy

Application security policies are often particularly complex for interconnected, dynamically changing application patterns, such as service-oriented architecture (SOA), Cloud application mashups, and other "Plug and Play" application environments. Customers adopt such an application environment for a variety of business reasons, as well as security requirements that support these reasons with minimal overall maintenance effort. So automation is critical.

Security automation is particularly important for cloud computing, as cloud users require cloud providers to support compliance policy management while measuring their strengths in terms of roughly the same metrics as cloud computing, based on how much they reduce upfront capital expenditures and their internal manual maintenance efforts.

Overall, application-layer security is far broader than the policy automation described in this article, including vulnerability scans, application layer firewalls, configuration management, alert monitoring and analysis, and source code analysis. One task that is closely related to the application-layer security policy is identity and access management. Although identity and access management is often viewed as having a greater relationship with user identity management rather than application security, they are actually highly relevant to application layer security. This is because when a user accesses an application and authenticates, an authorization policy needs to be enforced, largely depending on the particular application being accessed.

At this point, the problem arises: where does this authorization policy come from? Who writes and maintains this policy? How do I implement this policy? How do I audit this policy? These issues also apply when you use Application Security policy automation and identity and access management to make policy management more time-saving, repeatable, expensive, and error-prone.

Today's cloud application security policy automates deployment

Overall, security policy automation, especially for cloud technology, is still at a relatively early stage. It focuses primarily on providing identity/authentication as a service (for example, a Facebook connection). There are also cloud-based security services (anti-virus, e-mail scanning, intrusion detection systems (IDS), log management), some of which are indirectly related to applications.

This article focuses on automating the application security policy as a service provider. There are only a few deployments for early adopters: first, objectsecurity integrates its OPENPMF model-driven security policy automation product with a private platform, a service (PaaS) cloud (Intalio Cloud with Intalio BPMS), for Cloud mashups Provides seamless policy automation. Another early deployment involving OPENPMF applies to the U.S. Navy, in a gray area between private clouds and SOA. It involves strategy as a service, and virtualization IT services in a highly secure environment. All two cases will be discussed in a later Case study section.

There are also a number of other model-driven automated deployments of security policies, but not for the cloud, and most of them do not involve policy or service.

The challenge of automating application security policies

Unfortunately, in most cases, security policy automation is easier said than done. This section outlines the reasons why application Security policy automation is difficult to implement.

Policies become more difficult to implement and automate because they are more meaningful to people and organizations

Many of today's security tools provide a degree of automation (without maintenance), but cannot compromise dependencies, correctness, and automation: In some cases, the building of automation tools presupposes that the vendor knows what the end user organization wants to implement as a default security policy. In other cases, the purpose of building a product is to learn strategies in a heuristic manner over time. The disadvantage of both approaches is that they may implement unplanned, unrelated, or incomplete policies, even if the security mechanism itself can play its part.

Such traditional security automation is often more applicable to more general security tools, these tools do not require organization-specific policies and are oriented to the underlying level of the technology system (for example, the network or operating system layer), such as anti-virus, antimalware, preconfigured network intrusion detection systems, and common application vulnerability scans.

Security automation becomes more difficult to implement when you must consider the organization, user, and application behavior within to implement and audit security policies. For example, an organization that handles credit card payments would want to implement such policies as "unencrypted credit card information must not be taken out of the organization", and "it is necessary to delete credit card information that is no longer in use." Another example is that a medical organization would like to implement a strategy that includes "doctors and nurses can access their current patient's health files only if they have a legal purpose, without creating an alert audit log." Such complex, context-sensitive policies depend on the security policies, business processes, applications, and application interactions of specific organizations. This complex, context-sensitive policy is typically implemented because the end user organization must meet industry-specific Specifications (PCI Data security standards or PCI DSS and health Insurance Portability and Accountability Act or HIPAA).

Policies become more difficult to implement and automate because they become more, more complex, more versatile, more granular, and context-sensitive

Traditional "Authorization Management" is now categorized as part of identity and access management, it illustrates these challenges: as systems and participants become more and more dynamic, when interconnected applications evolve ("agility"), policies become less manageable when policies become rich, fine-grained, and context-related. There are too many, too complex technical security rules that need to be managed, so authorization policies can become ambiguous or not manageable, and confidence in the policies implemented may be compromised. As mentioned earlier, the question to answer is: Where does this authorization policy come from? Who writes and maintains this policy? How do I implement this policy? How do I audit this policy?

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/Servers/cloud-computing/