Improve cloud security with cloud application Security Policy automation

This article describes the challenges of automating effective application security policies, illustrates the benefits of model-driven security methods for security policy automation, and then shows how to automate 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 the later Case study section.

There are also a number of other model-driven automated deployments of security policies, but not for the cloud, most of which do not involve a 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?

Policy automation becomes more difficult to implement because IT patterns become more agile and interconnected (especially for cloud mashups)

To support the adoption of principles behind agile application environments such as cloud and SOA, authorization management itself needs to be at least as agile and automated, manageable, fine-grained, and context-sensitive. Unfortunately, creating and maintaining consistent and correct technology security policies is a major challenge in the face of frequent and dynamic system changes. This is because dynamic changes (for example, dynamic changes to cloud mashups) make the technical policies implemented ineffective, and security policies are particularly complex for interconnected, dynamically changing application patterns, such as SOA, Cloud application mashups, and other "Plug and Play" application environments. Without these drawbacks, authorization management forms a key technology building block that can implement and audit application authorization policies for all protected resources. It is an important part of cloud application security, especially for cloud mashups, since different roles (users or cloud applications) should be authorized under certain circumstances to invoke each other's services according to security policy. An important authorization management standard is OASIS extensible Access Control Markup Language (XACML).

Compliance is a policy-related requirement and therefore requires as much automation support as possible

Enterprise Cloud users will inevitably require simple, low maintenance (automated) compliance support for their cloud hosting applications and services. This is because many cloud applications deal with regulatory information (privacy, health information, payment information), which is often across organizational boundaries and needs to be audited. Compliance audits cannot be a unique responsibility for cloud users, as users have limited visibility into the cloud (especially for PaaS and software as well as infrastructure as services). Therefore, compliance (like security policy Management and incident monitoring) needs to be partially built into the cloud platform.

Users need to adopt a white list based strategy because the blacklist is no longer good enough

In this reminder, the blacklist refers to any person who is not on the blacklist to provide access. Whitelist means that you only provide access to people on the whitelist.

Model-driven security components

To automate, some algorithms need to be able to understand security policy requirements and policy-related things (users, applications, application interconnections, and application workflows) and automatically generate matching technical security policy implementations. Model-driven security methods use the reasoning behind the model-driven software development approach to security and compliance policy management, thus advancing the level of security policy automation that is required.