All posts by brianjohnson

Managing multi-cloud: Navigating your multi-cloud tagging strategy

Many companies are embracing multi-cloud strategies, and it’s easy to understand why. The cloud enables greater flexibility, accessibility and overall resilience. The bigger the organization, the more likely these assets are spread across public and private clouds. But managing these resources can quickly become a challenge.

The key to simplifying this issue lies in global tagging strategies. Organizations need to be very purposeful in creating global tagging strategies that will work across all clouds. All cloud providers are not created equal when it comes to tagging and have different limitations. Therefore, it is important that a global tagging policy does not violate any of the limitations of any of the cloud providers that are currently in use or your organization will potentially use in the future.

Whether you’re starting your tagging strategy from scratch or “retrofitting” your current cloud infrastructure, here’s how your organization can tackle the challenge: Design your tagging strategy using the lowest common denominator approach. In other words, design it to accommodate the various and distinct limitations of each major cloud provider. This lowest common denominator approach will ensure that you don’t end up with a fragmented tagging strategy. Fragmentation of your strategy is a sure-fire way to reduce its usefulness and longevity.

DivvyCloud recommends the following tagging strategy design to accommodate all major cloud providers:

  • Maximum Key Length (driven by GCP): 63 Characters

  • Maximum Value Length (driven by GCP): 63 Characters

  • Maximum # of Tags Per Resource (driven by Azure): 15 Tags

  • Case Sensitive

  • Keys and values can only contain lowercase letters, numeric characters, underscores, and dashes. International characters are allowed.

  • Label keys must start with a lowercase letter and international characters are allowed.

  • Label keys cannot be empty

  • Tag names can’t contain these characters: <, >, %, &, \, ?, /

  • AWS-generated tag names and values are automatically assigned the AWS: prefix, which you cannot assign. User-defined tag names have the prefix user: in the Cost Allocation Report.

  • Use each key only once for each resource. If you attempt to use the same key twice on the same resource, your request will be rejected.

  • You cannot tag a resource at the same time you create it. Tagging requires a separate action after the resource is created.

  • You cannot backdate the application of a tag. This means that tags only start appearing on your cost allocation report after you apply them, and do not appear on earlier reports.

  • Tags applied to the resource group are not inherited by the resources in that resource group.

  • Tags can’t be applied to classic resources such as Cloud Services.

Keep in mind, all of the providers are regularly expanding their tagging support, but it is best to plan for today and expand later when able to.

Now, on to a few different strategies based on where your firm is today in your global tagging strategy journey.

How to create and deploy an effective tag strategy

Starting from scratch: When launching your tagging strategy as part of the provisioning process, ensure that your tags represent all the needs of your organization. This will take planning and collaboration across several departments – from finance to operations to each of the business units that use the cloud as part of their workflow – and it’s best to put in a lot of effort before deployment. If your organization doesn’t address all the tags needed at launch, it means a lot of work will be needed after deployment. In general, more tags are better than fewer tags, just as long as the tags are standardized and well-documented to eliminate input mistakes and redundancy. Once your strategy is fully fleshed out, it’s best to implement it with as much automation as possible to eliminate human error and potential gaps.

Retrofitting your existing cloud infrastructure: When dealing with a messier implementation scenario, such as adding tags to an existing cloud infrastructure, there is no easy button.  Take a phased approach. Establish your policy and begin to implement it first within the IT departments. Once you have full compliance here then move on to developers and engineers in business units or who sit outside of central IT.  Start in all cases on applying this policy to all net new resources and build this muscle memory. Establish the value of tagging with all the parties involved. Demonstrate the benefits to everyone in the organization – up and down the company hierarchy.  Once you have buy-in then begin to move through legacy environments and update tags. Do so on some type of incremental basis that limits the period and frequency of disruption to the people who will have to inform or execute this effort.

Developing and implementing a strong tagging strategy works best when your organization is starting with a clean slate. That way, tags can be implemented, standardized, and enforced as part of the provisioning process. Starting from scratch also lets administrators fine-tune the tagging process moving forward: New and updated tags can be added cleanly and seamlessly as new code bases are deployed.

Unfortunately, few organizations have the luxury of starting their efforts with a blank canvas. Instead, most tagging strategies are implemented as a “uh oh, we need to address this” measure — a necessary reaction to an increasingly complex and diverse cloud infrastructure. Perhaps the company has grown quickly or moved more critical resources to the cloud over the years. Maybe the cloud provider has made additional resources available for tagging. In other scenarios, organizations may have implemented effective tagging strategies already, but a merger or acquisition requires getting an inherited infrastructure up to speed.

With an effective tagging strategy, any organization can achieve a greater sense of clarity and structure within a multi-cloud infrastructure. Your tagging strategy can start simply and seamlessly and over time, it can mature and grow in complexity as your business evolves and scales. All you need is a solid tagging foundation, an understanding of best practices, and an inspired first step.

https://www.cybersecuritycloudexpo.com/wp-content/uploads/2018/09/cyber-security-world-series-1.pngInterested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.

How the Cloud Security Alliance Cloud Controls Matrix benefits financial institutions

The self-service and dynamic nature of cloud infrastructure creates challenges for risk and compliance professionals. Tools that worked well in the traditional data centre do not translate to the public cloud.  

Due to these concerns over regulatory compliance and security, as well as the complexity involved in replacing legacy systems, financial institutions are taking a more tentative approach to change – especially when it comes to implementing new technologies that could put compliance at risk.

So how can today’s financial service organisations embrace the many benefits of the cloud without opening up a Pandora’s box of risk relative to compliance and security?

Cloud native frameworks

One way that innovative financial service organisations are addressing this issue is by introducing cloud native frameworks to govern the cloud. The major cloud providers have been hard at work to ensure that there is a fundamental infrastructure for compliance in place, and new tools are available to ensure that the parameters are being followed and that financial institutions are in compliance.

Let’s explore one of these common frameworks and how it maps to the cloud.

Cloud Security Alliance Cloud Controls Matrix (CSA CCM)

The Cloud Security Alliance Cloud Controls Matrix (CSA CCM) framework provides fundamental security principles to guide cloud vendors and assist prospective cloud customers in determining the overall security risk of a cloud provider. The CSA CCM provides a controls framework with a detailed explanation of security concepts and principles that are aligned to the Cloud Security Alliance guidance in 13 domains.

As a framework, the CSA CCM provides organisations with the needed structure, detail, and clarity relating to information security tailored to the cloud industry.  It has also become the generally agreed upon standard of US-based financial services companies on how they will govern their use of the cloud.   Many financial institutions use the CSA CCM because it encompasses multiple security frameworks across multiple organisations and allows them to look at their legacy frameworks and determine which portions are covered.

The CSA CCM strengthens existing information security control environments in a number of ways:

  • It emphasises business information security control requirements;
  • It reduces and identifies consistent security threats and vulnerabilities in the cloud;
  • It provides standardised security and operational risk management; and
  • It seeks to normalise security expectations, cloud taxonomy and terminology, and security measures implemented in the cloud.

One reason it is such a powerful resource is that if you are compliant in one area, it can provide validation that you are compliant with numerous related frameworks. 

For example, the control ID – DIS-03 under the CCM Domain – data security and lifecycle management for eCommerce transactions, requires data related to e-commerce that traverses public networks to be appropriately classified and protected from fraudulent activity, unauthorised disclosure, or modification in such a manner to prevent contract dispute and compromise of data.  If an organisation is in compliance with DIS-03 there is a direct correlation with NIST 800-53 which addresses these same security requirements with controls including:

  • AC-14: Permitting actions without identification or authentication
  • AC-21: Information sharing
  • AC-22: Public Accessible content
  • IA-8: Identification and Authentication (Non-organisational users)
  • AU-10: Non-Repudiation
  • SC-4: Information in shared resources
  • SC-8: Transmission confidentiality and integrity
  • SC-9: Transmission confidentiality

Many financial institutions use the CSA CCM because it encompasses multiple security frameworks across multiple organisations and allows them to look at their legacy frameworks and determine which portions are covered.

CSA CCM and cloud management platforms

CSA CCM has directives AIS-04, BCR-07, BCR-10, BCR-11, IAM-01, IAM-12, IVS-01, and IVS-03.  All of these require that you have Global API Accounting Configured so that it records API calls for your account and delivers log files to you. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by the specific cloud service. Global API Accounting provides a history of API calls for each account, including API calls made via the management console, SDKs, command line tools, and other cloud services.  Without this, you are in violation of CSA CCM. With a cloud management platform, users can build an automation to remediate. For example, in AWS, this would mean the cloud management platform would use the API to write credentials to turn on AWS CloudTrail for the resource in question.

Embracing cloud automation

The ability to automate the enforcement of best practices and standards will be a game changer for the financial services industry. Cloud automation tools provide organisations with continuous compliance and the ability to take the burden off of the IT department by automatically monitoring applications and identifying and fixing issues on the fly. They continuously scan the virtual infrastructure, identify non-compliant resources and remediate common cloud problems related to security, cost and compliance.

As financial institutions look to reinvent their IT organisations, they must ensure that security, governance and compliance is at the foundation of all decisions.  Regulatory compliance and managing cyber risk do not need to be the enemy of innovation. For such a regulated industry, automated cloud services and frameworks can help financial service organisations advance IT innovation