meshcloud is ISO 27001 certified

We at meshcloud are very pleased to announce that our organization is now ISO 27001 certified.

Our customers use meshcloud's cloud governance solution to manage thousands of their projects in the public and private cloud: Companies like Volkswagen, EnBW and Commerzbank trust meshcloud to provide a solid and secure platform for their cloud governance needs.

It's been very important to us that we can back up this trust with an ISO 27001 certification of our Information Security Management System.

What is ISO 27001?

The international ISO 27001 standard provides requirements and describes best practices for an Information Security Management System (ISMS). It is the only standard that sets out the specifications for an ISMS and an accredited certification demonstrates that an organization has identified its risks and has eliminated them or implemented appropriate countermeasures.

meshcloud's ISO 27001 certification

For us at meshcloud, it has always been of the highest importance to live up to the trust placed in us by our customers.

The ISO Certification was the next logical step for us as a company. We partnered up with ISO experts and aligned our operation to the high standard of ISO 27001:

  • Developing internal ISMS competence
  • Conducting risk assessment
  • Implementing required controls
  • Creating thorough ISMS documentation
  • Training staff regularly

The audit of our ISMS included:

  • Inspection of documents
  • Observation and on-site inspection
  • Interviews with staff members

ISO 27001 requires re-certification checks every year.


To learn more about the meshcloud platform, please get in touch with our sales team or book a demo with one of our product experts. We're looking forward to get in touch with you.


Multi-Cloud Security and Compliance: The Comprehensive Guide 2021

This is a comprehensive guide to cloud security and compliance in 2021.

If you work as a CISO, Enterprise Architect, Cloud (Security) Architect, in DevOps or you are just interested in cloud security, this guide is for you.

In this new guide you will learn:

  • What cloud security and compliance is
  • Who the stakeholders are – inside and outside of your organization
  • What threats jeopardize your cloud environment
  • How to address security challenges on an organizational and technical level
  • How to create a security concept that combines organizational and technical security aspects
  • How to improve the interface between central IT and compliance, governance and regulatory departments

If you want to dive deeper, this guide will go into more detail on:

  • The concept of shared responsibility
  • IAM and tenant isolation
  • Shadow IT
  • Best practices on landing zone configuration
  • Security specifics of AWS, GCP and Azure
  • Certifications like ISO 27001 or CSA

 

Chapter 1: Cloud Security and Compliance Fundamentals

Let’s get started with a chapter on the basics of cloud security and compliance.

Specifically, in this chapter we are going to cover why cloud security and compliance are extremely important!

This first chapter will also show what cloud security and compliance is.

Let’s dive right in!

What is Cloud Security?

Cloud security is a strategy and concept to protect cloud computing environments, applications and data. Important elements of cloud security are organizational and technical security, as well as an overarching strategy. Although it might never be possible to prevent every variety of attack – a well-designed cloud security strategy vastly reduces the risks to data, infrastructure and applications.

The CIA and Zero Trust in Information Security

In our case CIA has nothing to do with THE CIA - it stands for the three key components of information security: Confidentiality, availability and integrity.

Cloud security is no exemption - every security strategy should aim to achieve these goals.

Arguably the most relevant goal in current security considerations is integrity.

Today's enterprise IT architectures have become so complex, that traditional perimeter security thinking won’t get you very far any more. It is very probable that your organization has no clear picture of who is doing what within their enterprise IT.

That is a great threat to the integrity of data, applications and resources.

The modern approach to information and cloud security is the zero trust approach: Assume that your firewalls have been breached, assume that the enterprise network ist just as hostile as the internet - and construct your security strategy around that.

Here are the three guiding principles to the zero trust approach:

  1. Verify explicitly
  2. Use least privileged access
  3. Assume breach

Why is cloud security so important?

You can have the best applications and the most satisfied customers.

But what if sensitive data is exposed – due to misconfiguration?

Exposing sensitive customer data greatly reduces your customers trust and may result in churn.

What if an attacker gains access to your infrastructure? Imagine an airline that loses control of the airline app backend. Resulting downtime leaves customers unable to book flights and passengers unable to check-in.

Competitors that have access to your company secrets can pose an existential threat!

Those scenarios will cost reputation and in the end a lot of money:

According to a report from IBM and the Ponemon Institute the average costs of a data breach is just short of 4 million dollars.

High profile cases of cloud security incidents include Facebook, Capital One and Docker Hub.

What are the main cloud security risks?

Most cloud security incidents can be mapped to one of these 4 categories:

  • Data is exposed or leaked due to a lack of protection
  • An unauthorized user from outside the organization has access to internal data
  • An internal, authorized user has too much access to internal data
  • A malicious attack incapacitates cloud infrastructure

Cloud security measures aim at reducing the risks posed by these threats by protecting data, managing user authentication and access, and keeping resources and services running.

Infobox: Cloud computing vs. on-premise computing

"We wish for the same security measures and capabilities on-prem as they are available in the public clouds"

We hear this a lot when talking to our customers.

Cloud security risks can seem daunting. But they overlap a lot with traditional IT security risks. Cloud computing is often more secure than on-premises computing. Most cloud providers have more resources to implement comprehensive security concepts than individual businesses do, which lets cloud providers like Amazon, Microsoft or Google keep infrastructure up to date and patch vulnerabilities as soon as possible. For example, 3,500 security experts work on keeping Microsoft's Azure Service secure. Even the CIA decided to go all-in on the Cloud with a private AWS account.

How can you improve the security of your clouds?

Achieving a higher level of security in your clouds is done by a combination of organizational and technical measures.

To get an overview on the current state of your cloud governance capabilities, have a look at our cloud governance assessment.

Let’s have a look at what that means and what you need to take into account:

  • Shared responsibility
  • Stakeholders in your organization
  • Internal regulations
  • Identity and Access Management
  • Tenant Isolation
  • Shadow IT
  • Encryption at rest and in transit
  • Credential management
  • Network architecture
  • Monitoring
  • Audit logging
  • Regional restrictions
  • Landing zones
  • Transparency
  • Certification
  • Exit Strategy

And that is likely not an exhaustive list.

Luckily this guide covers all of these aspects and a few more!

Chapter 2: Shared responsibility and stakeholders

First of all: It is important to know who is responsible for what aspect of cloud security:

The cloud provider, cloud foundation or DevOps team in your company or - most importantly - yourself? To clarify ownership throughout your organization and enable the departments and teams concerned with aspects of cloud security is a vital process for implementing a cloud security concept and strategy.

This chapter will shed light on responsibilities and relevant shareholders.

Let’s get to know the people concerned with your cloud security!

What is behind the concept of shared responsibility?

A very basic concern in cloud security is preventing unauthorized physical access to the servers. Does that mean you have to lock server room doors at Amazon, Microsoft or Google? Of course not: The responsibility for all the different aspects of security is shared. You don’t have to worry about locked doors or even patching the underlying software of the clouds you use.

Example: Pooled Audit

However, there is another side of the coin. A lot of companies, especially in regulated environments, e.g. the financial services industry are required to ensure unrestricted audit rights, when they outsource material IT workloads. This means that they would have to provide access to the service provider’s premises, when conducting an audit. This had been a showstopper for a lot of organizations within the European Union. In 2017, pioneering companies like the “Deutsche Börse” initiated a new concept, called the “Collaborative Cloud Audit Group” that enables financial institutions to group together to perform such audits in order to reduce the effort on both sides, the cloud providers and the financial institutions.

In turn, that means that there are other areas, for which the cloud providers don’t take responsibility. For example:

 

  • How you set up your organizational structure, e.g. IAM processes
  • How you configure and secure your infrastructure, e.g. network setup, firewalls, load balancers
  • How you secure your applications  

A general rule is that the cloud provider is responsible for the security of the cloud, while you as their customer are responsible for the security in the cloud. However there are other aspects that affect the shared responsibility model, e.g. the service model you are using (Iaas/PaaS/SaaS).

Here is an example: If you use a SaaS service like Google Docs, you don't have to take care of the VM images or databases this application is running on. If you deploy your own MySQL cluster to AWS EC2 instances however, you are responsible to encrypt the connection via SSL or TLS.

Who are the stakeholders in the cloud security business?

Put simply, the providers are responsible for the security “of” the cloud- whereas you and your organization - as their customer - are responsible for the security “in” the cloud.

Let’s have a look at what that means in a little more detail as you’ll have to figure out how to distribute responsibilities within your organization as well.:

Provider: The provider usually makes sure that your infrastructure built within its platform is secure and reliable. This responsibility includes physical security of hosts, network and datacenter as well as the software security of storage, databases and networking.

CISO: The CISO cares about the information and data security of a whole organization. That includes - but is not limited to - the cloud. The CISO takes executive responsibility for security operations, data loss and fraud prevention, identity and access management and the overall security architecture.

SOCs: A SOC (Security Operations Center) is a central organizational unit that is responsible to protect IT infrastructure across the organization. Monitoring IT systems, identifying security risks and responding to security incidents when they occur are part of the team’s core responsibilities.

DevOps : DevOps teams are responsible for secure engineering, secure deployment and operations, availability management, backups, separation of duties and security evaluations.

Cloud Foundation: Most large organizations aim to transform their IT environment towards cloud-native technologies to achieve more agility in their software delivery. They often set up a dedicated team to manage cloud infrastructure and provide secure cloud environments to DevOps teams across the organization. These teams are often called "Cloud Center of Excellence" or "Cloud Foundation" as they lay the foundation for the use of cloud infrastructure. This foundation may cover security and compliance aspects and relieves DevOps teams from security or compliance requirements that are independent of the application, e.g. the geographic restriction of cloud data centers.

Chapter 3: Cloud Compliance

This guide has been talking about cloud security a lot without touching on the important topic of cloud compliance so far. The second your organization decides to move data and applications to the cloud compliance becomes a huge issue!

Time to take a look at what you need to know about compliance and regulations when it comes to the cloud.

What is cloud compliance?

The term cloud compliance refers to the need that cloud-delivered systems must be inline with internal and external regulations. A common example is the European General Data Protection Regulation (GDPR), which concerns virtually every organization. But there are also very specific regulations for example in the financial or healthcare sector that companies need to comply with. This compliance must be transparent and auditable for regulators.

Which rules are there for cloud compliance?

The first step towards achieving cloud compliance is to be aware of the standards and regulations that apply within your industry and specifically within your organization. Standards and regulations may apply to certain

  • Industries
  • Geographies

Depending on the relevance of your industry there may be different regulations in place. Here are some examples, however this list is not exhaustive.

  • KRITIS for critical infrastructure (national)
  • BAIT and VAIT (Supervisory Requirements for IT in Financial Institutions/Insurance Undertakings)  (national by the BaFin)
  • ISO/IEEC 2700x (international by the International Organization for Standardization and the International Electrotechnical Commission)

What happens if you fail to be compliant?

Organizations are made responsible to meet a large variety of regulations. Failing to meet these can result in fines and a negative impact on your trustworthiness and reputation.

A widely discussed example is the GDPR, which focuses on data protection and privacy. 

Even if your organization is based outside the EU – as long as you have business in the EU, GDPR compliance is required. The possible fines are enormous. According to enforcementtracker.com the highest fines were due to insufficient technical and organizational measures to ensure information security. Marriott International was fined more than 110 million euros and British Airways almost twice that amount because of information security violations.

Cloud security and cloud compliance is a shared responsibility between cloud providers and organizations. In the past years, cloud providers have invested a lot in providing better transparency and better tools to be an eligible infrastructure provider, even for very sensitive industries or governments.

How do you stay compliant when working with the cloud?

A great challenge to staying compliant is the ever changing environment and requirements of internal and external regulations. That brings us to our list of 4 aspects you need to take into account:

  1. Be aware of regulations and guidelines
  2. Control access
  3. Classify the data and document, where it's at
  4. Encrypt the data you are entrusted with

But there is a lot more to ensuring continuous compliance - especially across multiple environments and vendors: With a declarative approach you can fully utilize the advantages the cloud offers by automating the efforts of enforcing your compliance policies across your multi-cloud environments.

Chapter 4: Organizational Security in Cloud Computing

Let's talk about organizational security.

This chapter will tell you what organizational security is. It will also show why it is an important part of any cloud security strategy. And if you want to learn about what aspects you should definitely consider for your organization - you came to the right place!

Let's go!

What is organizational security?

Organizational security is everything you do on an organizational (as opposed to technical) level to improve the security of your cloud.

How can you improve the organizational security level?

In this case you don't have to evaluate whose responsibility the measures for organizational security are depending on the cloud operating model: Organizational security is for everyone!

(Sidenote: Clear responsibilities are important! In that way an organization stays responsive during a security incident.)

  • Implementing principle of least privilege
  • Isolating tenants in a multi-tenant environment
  • Practicing the 4-eye-principle
  • Fighting shadow IT
  • Preventing accidental misconfiguration
  • Classification of data

What is the principle of least privilege

The principle of least privilege (PoLP) is the concept of granting access to only the resources that are absolutely necessary to do the assigned tasks. It is pretty similar to what you might know from movies about secret agents: They only know what is necessary to accomplish the mission: In that way they can't endanger the whole operation in case of failure.

But we're not the CIA or MI5 so let's see what the principle of least privilege means in terms of cloud security!

4 Tips to implement the principle of least privilege

From developer onboarding to long-term management of user and permission lifecycles, managing access to cloud infrastructure is complex and security-critical. Authorizations should be granted as sparingly as possible (principle of least privilege) in order to reduce security risks. At the same time, the productivity of developers should not be restricted by lacking access rights or tedious approval processes. A simple and transparent process for assigning access rights is therefore essential.

  1. Avoid excessive use of broad primitive roles
  2. Assign roles to groups, not individuals
  3. Reduce risk and control access to your project by using networking features
  4. Consider using managed platforms and services

Quarantine your applications and environments

A relatively easy but very important step in securing your cloud workloads is tenant isolation.

By that we mean 2 things:

  1. Every application needs to run in its own tenant.
  2. Different development environments, e.g. development, staging and production environments of each of your applications should run within their own tenant.

A common setup with our customers are three cloud tenants for every application you move to the cloud: Development, staging and production. The number of stages ranges from 2 up to 6, depending on the use case.

Let's have a look at a company that did not follow this principle – Tesla:

In 2018 security experts discovered that hackers gained access to Tesla's cloud resources. Not to steal company secrets but use them to mine crypto currencies. All of that happened on a tenant that was used for several applications and environments. That made it relatively easy for the attackers to hide their malware in the general activity on this tenant. It’s much harder to identify deviations of regular activity within a shared environment. One team responsible for a single app would probably have identified high expenses or unknown resources much earlier.

The dark truth about Shadow IT

According to a survey by the Cloud Security Alliance, only 8% of the CIOs believe they know about the secret digital infrastructure in their company. This shadow IT, or Stealth IT as it is more aptly referred to, hides from the radar of IT managers. Eco, the Association for the Internet Economy, asked 580 experts from German medium-sized companies for its IT security report - the result is clear and worrying: three quarters of those surveyed assume that a shadow IT exists in their company. Nearly 25% fear a "considerable extent".

Even without an actual security breach, shadow IT costs your organization money, right now. It is uncontrolled and may contain unnecessary workload, organization-wide discounts by the cloud providers, e.g. for reserved instances are not taken into account. There are examples of cloud costs being billed as travel expenses on company credit cards, making the controlling of cloud costs hardly possible.

Chapter 5: Technical Security in Cloud Computing

Now that we have covered the ins and outs of organizational security, let's turn to its even more powerful brother: Technical security!

This chapter will cover what technical security is when it comes to keeping your cloud secure.

You will learn about important aspects of technical security, like encryption at rest, credential management and audit logging.

What is technical security?

In the realm of IT – or in our case more specifically – cloud security, the term technical security refers to technical actions that can be taken to implement and enforce security measures.

How can you improve your technical security level?

Here's a list of aspects and concepts you definitely have to take into account when thinking about technical cloud security:

Once again, make sure you understand who is responsible for each aspect. The cloud service provider? If not, who in your organization is it?

  • Encryption
  • Credential management
  • Network architecture
  • Monitoring
  • Audit logging
  • Regional restrictions

Even if you make use of cloud-native service offers, you have to evaluate whether the service is compliant to your internal and external regulations. To give you an example: With AWS Key Management Service (KMS), AWS offers a managed service to generate encryption keys. Some organizations however, have the requirement to have exclusive control on their HSM (hardware security module, the device that manages digital keys and performs encryption and decryption functions), which isn’t fulfilled by the KMS service. To address this need AWS launched additional services for this specific use case.

Encryption at rest: Protecting data, even if it has been stolen

Simply put, data encryption is the process of translating one form of data into another form of data that unauthorized users can’t decrypt. For example, you saved a copy of a paid invoice on your server with a customer’s credit card information. You definitely don’t want that to fall into the wrong hands. By encrypting data at rest, you’re essentially converting your customer’s sensitive data into another form of data. This usually happens through an algorithm that makes it practically impossible for somebody without the encryption key to decode it. Only authorized personnel will have access to these files, thus ensuring that your data stays secure.

Encryption in transit: Get the armored vehicle for your data

Data that is being moved from one place to the other is vulnerable to attackers. Unencrypted data transfer puts this data at risk. To protect it against eavesdropping or a Man-in-the-Middle you need to enforce your defined encryption requirements. It’s also a good idea to authenticate the network communications using Transport Layer Security (TLS) or IPSec.

Credential management

Credential management is key to securing any kind of system: From the traffic on our roads, to the traffic in our data centers. The management of drivers licences and IT credentials have a lot in common. They both are:

  1. Generated,
  2. stored,
  3. backuped,
  4. used,
  5. audited,
  6. changed,
  7. and eventually revoked and deleted.

Those 7 aspects need to be taken in account when managing credentials. That’s about how far our little metaphor will get us here. Let’s dive into multi-cloud credential management:

When we say credentials, we mean passwords, tokens or keys that grant access to your workload. Manage credentials and authentication mechanisms in a way that reduces the risk of accidental or malicious use.

Here are a few tipps, tricks and best practices:

  • Define IAM configurations to meet your organizational, legal, and compliance requirements.
  • Integrate with the centralized federation provider of your organization to reduce complexity. In that way, all users are authenticated in a centralized place.
  • Enforce password requirements to protect against password attacks like rainbow tables or brute force.
  • Enforce multi-factor authentication (MFA) to provide an additional layer of access control.
  • Lock physical credentials away That includes hardware MFA tokens.
  • Rotate credentials regularly to avoid unauthorized use of old credentials.
  • Audit credentials from time to time.

Network architecture

Most organizations have a hybrid infrastructure, with parts in the cloud and parts on-premises. Sensitive data is often kept on-prem, for security reasons, but also because large amounts of data in the cloud lead to an immense lock-in effect, as it is very easy to get the data in there, but costly to take it out again. That's why a lot of applications running in the cloud need access to on-prem infrastructure.

All 3 public cloud providers offer Virtual Private Clouds (VPCs) that enable you to build virtual network topologies that you can fully control.

Here are some VPC Best-Practices to improve network security:

  • Use multiple availability zones for high availability
  • Use public subnets for external-facing resources and
  • Private subnets for internal resources
  • Use ACLs —> Access Control Lists to limit the traffic between components to the minimum

It can make sense to hand out new cloud tenants with standard network components already deployed (via Landing Zones) to relieve DevOps teams and avoid insecure configurations.

4 Tips for monitoring cloud security

Cloud Monitoring is another critical aspect of keeping your workloads secure. Correct monitoring will tell you if your cloud infrastructure functions as intended while minimizing the risk of data breaches.

To do that there are a few guidelines to follow:

  • Your monitoring tools need to be scalable to your growing cloud infrastructure and data volumes
  • Aim for constant and instant monitoring of new or modified components
  • Don't rely on what you get from you cloud service provider alone - you need transparency in every layer of your cloud infrastructure
  • Make sure you get enough context with your monitoring alerts to help you understand what is going on

You can and should monitor on different layers (e.g. network, application performance) and there are different tools for doing this. SIEM (Security Information and Event Management) tools collect data from various sources. They process this data to identify and report on security-related incidents and send out alerts whenever a potential risk has been identified.

Audit Logging

With audit logging you document changes applied to your cloud tenants: Has a new user been added to your AWS account? Were access rights granted in your Azure subscription? Or who logged in when and for how long into your Google Cloud Project?

Audit logs are an absolute necessity when it comes to cloud security and compliance! And there are three main reasons why:

  1. Compliance auditing: Audit logs are official records that can be used to prove compliance to an auditor.
  2. Security analysis: Audit logs let you trace malicious behaviour and potential attacks.
  3. Operational troubleshooting: Audit logs help you find what is wrong with your tenants.

Closing remarks to this topic: Disk space is cheap, there is absolutely no reason to not keep audit logs.

Infobox: The most common audit logging services

At AWS user activity and API usage can be tracked with AWS CloudTrail. CloudTrail stores event logs in the CloudTrail console, Amazon S3 buckets and (optionally) in Amazon CloudWatch logs.

Azure provides a whole barrage of logging, auditing and monitoring tools. Audit logs can be retrieved from the Azure Active Directory portal.

Google Cloud Platform offers Cloud Audit Logs, that maintain three audit logs for each project, folder and organization.

Regional Restrictions

Regional restrictions in the context of this guide are mainly a compliance concern that can be addressed technically. Many european companies want to, or need to, make sure that their data is stored on servers within EU jurisdiction. Same with managed services: They often need to be delivered from a certain geography. 

With AWS for example you can disable entire regions (that’s not possible with all of them) and set up IAM policies that restrict access to certain geographies.

Chapter 6: The combined approach to cloud security

Achieving security in all aspects of cloud computing is a multilayered quest for every organization. Single measures of organizational and technical security are important but not enough.

This chapter will discuss the overarching organizational and technical security measures you need to know about and implement within your organization.

Learn about metadata for applications, the danger of configuration drift and how landing zones greatly improve the security and compliance of your tenants.

Metadata

Maintaining organizational metadata - or context information - for applications, such as Application IDs, cost centers or security contacts is a way to establish a connection between the organization and the actual implementation of the application and integrate cloud infrastructure to the surrounding IT landscape, including CMDBs (Configuration Management Databases), SIEMs or Accounting systems like SAP.

Let’s have a look at two examples:

  • Providing a cost center when creating a new cloud tenant enables cloud foundation teams or management systems like meshcloud to map the occuring cost of an application to the corresponding department.
  • SOCs scan infrastructure for vulnerabilities. If a vulnerability is detected, it is essential to know within which application the affected infrastructure is used and who is responsible for its security and therefore fixing the breach.

Declarative model vs. Workflow-centric approaches

We’ve almost reached the end. And by now it’s pretty clear that cloud security and compliance are a complex endeavour with many different technical and organizational aspects to take into account. The complexity increases, if you consider that all these aspects do not only have to be set up and implemented once, but for a heterogeneous application landscape throughout the application lifecycle. Looking at a longer term perspective this leads to a risk for a phenomenon called configuration drift.

What is configuration drift?

Configuration drift describes a deviation of configurations from their initial setup due to frequent changes in hardware and software.
Within a complex cloud landscape you’ll have to think about how to treat configuration drift, from detecting it, to managing and correcting it. 

Declarative model vs. Workflow-centric approach

A common way to speed up slow manual processes is to automate the workflow. So for example, instead of having an Azure Admin manually create and configure a subscription for a DevOps team, there will be a script automating the workflow to reduce the time needed. 

But what happens if the DevOps team lead goes ahead and changes the configuration to better suit the application’s needs? Right, configuration drift, and no one will be aware of it.

A superior approach is to define a desired state. To stick with the Azure example, this could be an Azure subscription with access permissions for a DevOps team lead and one of his team members. This desired state definition can be continuously compared to the actual state. If no subscription or permissions exist yet, they will be initially set up. If the DevOps team lead changes the configuration, this will be detected. If it is intended the desired state can be updated, if not the action can be undone to get back to the desired configuration.

Infobox: How vs. What

Workflow-centric approaches focus on “how” to achieve a desired outcome, while declarative approaches provide a clear definition of “what” is to be achieved. A declarative approach has the benefit that it enables a continuous validation of the actual state against the defined desired state (re-certification) and provides a single source of truth to avoid configuration drift.

Landing Zones

Configuring a new tenant to be secure and compliant can be quite the hassle – especially if you have to do a basic set of tasks over and over again. This is where landing zones come in. Landing zones allow to quickly set up a multi-tenant environment with a baseline of identity and access management, data security, governance and logging already in place.

The basic purpose of a landing zone is to build and secure the airport before an application lands in the cloud.

But landing zones are not "fire and forget": A proper landing zone lifecycle management is an important part to keep your environments secure and compliant.

The big cloud service providers have the concept of landing zones implemented in some way.

Exit Strategy

Moving your workloads to the cloud brings many advantages – like on demand infrastructure and elastically scalable services. While most cloud users love the feel of innovation and progress to it, many don't think too much about how to get out again – why would they? But having a solid exit strategy in place is essential! In some industries, like banking, it is a regulatory requirement, as stated in the EBA Guidelines on outsourcing arrangements. The goal of an exit strategy is to ensure business continuity under changing circumstances. What if the service provider terminates the contract? What if the services do not meet the defined quality standards? Being able to handle these scenarios without interrupting critical business functionality is part of a comprehensive cloud transformation strategy. 

So here are 4 aspects you will have to have an eye on when building your cloud exit strategy:

  1. Most importantly: Take inventory! Knowing your assets is essential. Exit strategies often apply to critical business functions only. So it’s important to know what you have running in which cloud – an up to date cloud inventory is of great help.
  2. Open-source infrastructure is key. Open-source infrastructure components like Kubernetes clusters or open-source databases can make a move between clouds much easier. The more proprietary services you use, the harder it will be to adapt your application to running in a new cloud environment.
  3. Go multi-cloud from the beginning. Contract negotiations between enterprises and cloud providers can take a while. It’s too late to start the process, when it’s actually time to move
  4. Watch out for organizational lock-in. Even if from a technical perspective your application can easily be moved to a different cloud provider, there’s more to it. If you are running cloud applications at scale, setting up the corresponding cloud environments transferring permissions and configurations comes with massive complexity. Use a centralized governance system like mehscloud to keep your organizational structures independent from specific providers.

To learn more about the meshcloud platform, please get in touch with our sales team or book a demo with one of our product experts. We're looking forward to getting in touch with you.


Multi-Cloud Monitoring: A Cloud Security Essential

This is an introduction to cloud monitoring: If you work as a cloud operator or developer or you want to learn about cloud monitoring - this blog post is for you!

In this post you will learn:

  • What cloud monitoring is
  • How it helps you secure business success
  • How monitoring and alerting connect
  • About different types of monitoring
  • How Prometheus and cAdvisor work

Let's get started with the basics!

Cloud Monitoring: Definition and Challenges

Monitoring helps you understand the behavior of your cloud environments and applications.
Technically speaking, in IT, monitoring refers to observing and checking the state of hardware or software systems. Essentially to ensure the system is functioning as intended on a specific level of performance.

Monitoring in cloud environments can be a challenging task. Since there is no control over all layers of the infrastructure, monitoring becomes limited to upper layers depending on the cloud service model. Besides, cloud consumers frequently use containerized applications. Containers are intended to have short lives, even if they did last for long, we don’t rely on them e.g. for storing data. Since their nature is dynamic monitoring them is challenging. Tools such as Prometheus with cAdvisor take care of this challenge. More on that in the two bonus sections at the end of this blog post.

Five reasons why cloud monitoring helps business success

Here are five reasons why good monitoring helps you secure business success:

  1. Increase system availability: Don't let users take the place of proper monitoring and alerting. When an issue occurs on a system that is not being monitored, it will most certainly be reported by the users of that system. Detect problems early to mitigate them, before a user is disrupted by them.
  2. Boost performance: Monitoring systems leads to a more detailed understanding. Flaws become visible and Developers can gain detailed access and fix problems for better performance.
  3. Make better decisions: Detailed insight into the current state of a system allows more accurate decision-making based on actual data analysis.
  4. Predict the future: Predicting what might happen in the future by analyzing historical data is very powerful. An example is so-called pre-emptive maintenance; performing maintenance on parts of the system that have a high probability of failing soon, given the historical data provided.
  5. Automate, automate, automate: Monitoring highly reduces manual work. There is no need to manually check system components when there is a monitoring system doing the checks instead.

Monitoring and Alerting

Monitoring is usually linked to alerting. While monitoring introduces automation by pulling data from running processes, alerting adds even more automation by alerting developers when a problem occurs.

For example: Alerting if a critical process stops running.

Another important reason to monitor is conforming to Service Level Agreements (SLA). Violating the SLA could lead to damage to the business and monitoring helps to keep track of the agreements set in the SLA.

The Different Types of Monitoring

To classify types of monitoring we can ask two questions:

What is being monitored?

and

How is it being monitored?

To the first question there are many answers:

  • Uptime monitoring: As its name suggests, this is important to monitor service uptime.
  • Infrastructure monitoring: In the cloud world, infrastructure varies from traditional infrastructure in that resources are software-based; i.e. virtual machines and containers. And it is important to monitor these resources since they are the base of running processes and services.
  • Security monitoring: Security monitoring is concerned with SSL certificate expiry, intrusion detection, or penetration testing.
  • Disaster recovery monitoring: Also, taking backups for stored data is always an important and necessary practice. Monitoring the backup process is important to ensure it was done properly at its intended timeframe.

Now to the second question: How it is being monitored?

This lets us differentiate between Whitebox and Blackbox monitoring:
Illustration of whitebox and blackbox monitoring. Credits to https://medium.com/@ATavgen for the illustration idea.

Whitebox monitoring: This type refers to monitoring the internals of a system. When monitoring applications, the running process also exposes information about itself which makes it visible to the outside world. Exposed information can be in a form of metrics, logs, or traces.

Blackbox monitoring: This type refers to monitoring the behavior of an object or a system usually by performing a probe (i.e. sending an HTTP request) and checking the result such as ping to check the latency of a request to a server. This type does not check any internals of the application.

The concept of white box and black box is used in software testing with semantically similar meaning as in monitoring. It is also concerned with testing the internals and externals of a software system. The difference being, that software testing usually occurs during development while monitoring is applied when the software is already running.

4 Tips for monitoring cloud security

Correct monitoring will tell you if your cloud infrastructure functions as intended while minimizing the risk of data breaches.

To do that there are a few guidelines to follow:

  • Your monitoring tools need to be scalable to your growing cloud infrastructure and data volumes
  • Aim for constant and instant monitoring of new or modified components
  • Don't rely on what you get from your cloud service provider alone - you need transparency in every layer of your cloud infrastructure
  • Make sure you get enough context with your monitoring alerts to help you understand what is going on

You can and should monitor on different layers (e.g. network, application performance) and there are different tools for doing this. SIEM (Security Information and Event Management) tools collect data from various sources. They process this data to identify and report on security-related incidents and send out alerts whenever a potential risk has been identified.

Bonus 1: Prometheus Architecture

As promised a short excursion to Prometheus:

Prometheus is a metric-based, open-source monitoring tool written in Go. It is the second graduating project after Kubernetes was adopted by the CNCF and will remain fully open-source. Prometheus has its own query language called PromQL which is powerful for performing operations in the metric space. Prometheus also uses its own time-series database (TSDB) for storage.

Prometheus architecture illustration

Prometheus uses service discovery to discover targets or can use statically defined targets as well. It scrapes those targets which are either applications that directly expose Prometheus metrics through Prometheus client libraries or with the help of exporters that translate data from third-party applications into metrics that can be scraped by Prometheus.
While Prometheus has its own time-series storage in which the scraped metrics are stored, it can also use these stored time-series data to evaluate alert rules. Once a condition is met, alerts are sent to Alertmanager which in turn sends a notification to a configured destination (Email, PagerDuty, etc.)

Prometheus time-series data can also be visualized by third-party visualization tools such as Grafana. These tools leverage Prometheus query language to pull time-series data from Prometheus
storage.

Bonus 2: Container Monitoring using cAdvisor and Prometheus

cAdvisor (Container Advisor) is a tool to tackle the challenge of monitoring containers. Its core functionality is making the resource usage and performance characteristics of containers transparent to their users. cAdvisor exposes Prometheus metrics out of the box. It is a running daemon that collects, aggregates, processes, and exports information about running containers. cAdvisor supports Docker and pretty much every other container type out there.

To get started you'll need to configure Prometheus to scrape metrics from cAdvisor:

scrape_configs:
- job_name: cadvisor
  scrape_interval: 5s
  static_configs:
  - targets:
    - cadvisor:8080

Create your containers - Docker for example - that run Prometheus, cAdvisor, and an application to see metrics produced by your containers, collected by cAdvisor, and scraped by Prometheus.

Authors: Mohammad Alhussan and Wulf Schiemann


To learn more about the meshcloud platform, please get in touch with our sales team or book a demo with one of our product experts. We're looking forward to get in touch with you.


Rules to comply with traffic light depicting compliance and regulation.

Ensuring Continuous Compliance in the Cloud

Ensuring continuous compliance in dynamic multi-cloud architectures is quite the task. The challenge: Achieving and maintaining the required level of compliance across all environments. To many this seems more complex than traditional data center operations. But cloud computing opens up possibilities to stay compliant that by far outweigh the challenges it may add.

In this post you will learn

  • what we mean by continuous compliance,
  • about the typical challenges of implementing continuous compliance,
  • why a declarative approach is superior
  • and as a bonus: What tools and services Azure, AWS and GCP offer you to stay compliant.

Let's get started!

What is continuous compliance?

For compliance efforts to make any sense they have to be ongoing. That means they have to stretch way beyond the initial setup and migration. Continuous compliance ensures a compliant state of all cloud environments at any point - especially in day-to-day operations.

A failure to be compliant to - e.g. the European GDPR - can result in substantial fines and loss of reputation.

Continuous compliance is a matter of culture and strategy in your organization. It's a matter of using the right tools and services to actually live up to the set standards in practice.

Continuous compliance frees IT departments from only reacting to regulators or threats to data security: Well-implemented continuous compliance practices prepare the organization for future security threats and audit requirements.

The 3 hurdles to get over when implementing continuous compliance

There are 3 major hurdles any organization needs to clear when it comes to continuous compliance and moving to the cloud:

  1. Evaluation,
  2. building,
  3. scaling.

The evaluation of general and industry-specific regulation is the first - easier - step. It's followed by the assessment of possible cloud platforms and the definition of enterprise-specific compliance requirements.

With building we mean the challenge of implementing the continuous compliance strategy organization-wide. Spanning all teams, environments, and applications.

The last hurdle is making the continuous compliance strategy and implementation fit for scale. New cloud platforms, new projects, and the dynamic change of existing environments must all be incorporated in continuous compliance efforts.

Continuous Compliance in Cloud Computing

Moving workload to the cloud is a complex operation. Especially multi-cloud architectures with multiple cloud service providers like AWS, Azure, and GCP. Achieving and maintaining compliance across clouds and applications seems more difficult than the traditional datacenter operations.

Cloud migration timeline showing compliance milestones
On this timeline, you can see major compliance milestones in the cloud migration process and during operations: From evaluation to building and scaling.


The added complexity is outweighed by the added transparency the cloud offers: Cloud technology allows you to audit, query, alert and resolve issues on a grand scale across all environments.

There is no denying it - initial definition is complex: A service provided by central IT - let's say a jump host - may take weeks or even months to get security and compliance clearance. But services provided by the cloud, like logging and anomaly detection, paradigms like CI/CD, and automation are great tools to overcome complexity and build on a large scale.

The extent to which companies can utilize the new options and what it will cost them depends on the approach they opt for:

We discern between the workflow-centric and the declarative approach.

Challenges of the workflow-centric approach

A common way to speed up slow manual processes is to automate the workflow.

So for example, instead of having an Azure Admin manually create and configure a subscription for a DevOps team, there will be a script automating the workflow to reduce the time needed.

But what happens if the DevOps team lead goes ahead and changes the set up to better suit the application's needs? Right, configuration drift and no one will be aware of environments becoming non-compliant.

To detect non-compliant environments a compliance monitoring can be introduced subsequently: It issues an alarm if compliance policies are violated. A workflow must then be triggered again to resolve the discrepancies.

The declarative approach: Taking continuous compliance a step further

A superior approach is to define the desired state. That is what we mean by the declarative approach. It is the final and most mature stage in our multi-cloud management maturity model. It offers a lot of potential to take the hurdles of building and scaling we talked about earlier.

The declarative approach focuses on the what as opposed to the how of the workflow-centric approach: The declarative approach has the benefit that it enables a continuous validation of the actual state against the defined desired state (re-certification) and provides a single source of truth to avoid configuration drift.

To stick with the Azure example, this could be an Azure subscription with access permissions for a DevOps team lead and one of his team members. This desired state definition can be continuously compared to the actual state. If no subscription or permissions exist yet, they will be initially set up. If the DevOps team lead changes the configuration, this will be detected. If it is intended the desired state can be updated, if not the action can be undone to get back to the desired configuration.

The declarative approach covers both technical and organizational compliance measures: Tools like Azure Resource Manager templates help you describe the desired state to ensure continuous technical compliance.

The same is possible for continuous organizational compliance: As part of the government-funded MultiSecure project, meshcloud enables enterprises to describe organizational structures in a declarative format.

Let's have a quick look at an example: Productive cloud environments do not only have to follow specific configurations - provided by landing zones - but organizations have to make sure that only authorized staff creates and accesses these environments.

The idea of MultiSecure is to describe organizational elements and their relationships as code in an open and reusable format - a declarative manifest that represents the desired target state of the organization. MultiSecure allows centralizing this information in an open format, instead of squeezing the organization into the envisaged organizational models of the cloud providers and therefore maintaining multiple proprietary organizational models in parallel and distributed. It builds a projection of the organization that can be consumed by different systems.

A practical look at using meshcloud

Let's have a look at how you can prevent unauthorized and unintended permission changes in your cloud environments using meshcloud:

The creation of new cloud environments often comes with a certain permission set. A DevOps team lead creates a project and receives permissions to access and edit the corresponding cloud environments and so do the other DevOps team members who work on the application deployment.

If DevOps teams receive cloud-native access to the clouds, such permissions are prone to unintended or unauthorized change.

To prevent this configuration drift, the permissions must be monitored. With meshcloud - following the declarative approach - the desired state of configurations is continuously checked against the actual state of the subscription. In case of deviations, the configurations will be automatically restored to maintain a compliant state of all environments.

Bonus: A quick look at Azure, AWS and GCP compliance services

The big public cloud platforms offer a range of resources, tools, and services to help their customers implementing their continuous compliance strategies.

Let's have a look!

Microsoft Azure:

Microsoft puts its Azure Trust Center forward to explain what Azure offers in terms of compliance: From audit reports and compliance offerings (including regulation and certification like GDPR or ISO 27001) to their understanding of shared responsibility.

With Azure Security Center Microsoft offers an infrastructure security management system to protect cloud and data center workloads.

Further Azure services include

  • Azure Sentinel (cloud native SIEM and security analytics)
  • Azure Policy (implementing governance and standards for Azure resources)

Amazon AWS:

Amazon offers what they call the AWS Security Hub. It provides insights into the security state of AWS environments and helps to check against set security and compliance standards.

AWS Systems Manager provides visibility and control to manage infrastructure securely at scale. It helps to maintain compliance by detecting policy violations.

Google Cloud Platform:

In their Cloud Compliance Resource Center Google collects all important information on what tools and services GCP offer to help to stay compliant on their platform. Google provides a wide variety of compliance offerings - global and regional.

With Google Anthos there now is a service that lets you enforce security and compliance policies across all cloud environments.

GCP also supports third-party services like Forseti Security that provide monitoring, enforcing, and displaying policies.


To learn more about the meshcloud platform, please get in touch with our sales team or book a demo with one of our product experts. We're looking forward to get in touch with you.


Cloud Exit Strategy: Ensure Compliance and Prevent Vendor Lock-in

A clear cloud exit strategy is absolutely necessary when moving to the cloud. Ensuring both compliance and business continuity - and avoiding vendor lock-in - are the primary reasons.

Today, large companies can no longer do without the advantages of the cloud. The competitive pressure of digitalization requires migration to the cloud. At the same time, high regulatory demands are being placed on outsourcing - especially in critical industries. And using public cloud is outsourcing!

Placing oneself in the hands of the hyperscalers involves risks. You generally don't have to worry about security: Amazon, Microsft, and Google do a lot to keep their offers safe. Compliance and vendor lock-in is a different matter: It is important to clarify which data and solutions end up with which cloud providers. For this purpose, a clear exit strategy is required in addition to the (multi-)cloud architecture and the cloud sourcing strategy. A high-profile example is that of Dropbox leaving AWS in favor of hosting their workloads themselves.

Regulatory Requirements

In certain critical industries, a documented exit strategy is more than just a good idea, it is a regulatory requirement.

The banking sector is one of the most heavily regulated industries. The regulators also deal with the cloud use of companies. The European Banking Authority, for example, requires an exit strategy for outsourced critical or important functions in its EBA Guidelines on outsourcing arrangements under chapter 15. This includes the use of the public cloud.

The German financial supervisory authority BaFin also prescribes the development of an exit strategy in its banking supervisory requirements for IT.

4 aspects of vendor lock-in

Vendor lock-in means not being able to shift workloads from one vendor to another without too much hassle. That it brings great advantages to be able to do this shows the recent downtime at IBM.

Not being able to do so has different possible reasons:

  • Cost
  • Contracts
  • Skills
  • Technology

Cost is a major factor in prohibiting migration from one vendor to another. The vendor might charge for exporting data. In addition to that costs will pile up for training staff, consultants, and the lowered productivity. The larger the workload the larger the costs. A good example to look at is Netflix: The streaming service is all in on AWS and won't be able to change that - at least not with reasonable costs.

Contracts can play a big role in vendor lock-in. Some cloud service providers make it hard to decide for a migration to an alternative vendor by implementing a continuously upward pricing model that aims at drawing their customers deeper and deeper into a factual lock-in. At some point, a partial exit may no longer be economical and a complete and difficult withdrawal from the whole contract the only option.

Skills play a big role in migrating and operating workloads. Cloud architects, DevOps teams, and security experts are specialized and it takes time and money to shift that knowledge to newly adopted cloud platforms. That can be a major hurdle when considering leaving a vendor for another. Going multi-cloud from the start provides companies with a larger talent pool and that takes the trouble out of transitioning a little bit.

Technology causes vendor lock-in as well - at least when it comes to proprietary technology vendors use to differentiate. On the one hand, that's great and can offer a competitive edge. On the other hand, it can get companies locked in on this technology and hinder the adoption of the next big thing in cloud technologies.

The 4 key aspects to every cloud exit strategy

So here are 4 aspects you will have to have an eye on when building your cloud exit strategy:

  1. Most importantly: Take inventory! Knowing your assets is essential. Exit strategies often apply to critical business functions only. So it’s important to know what you have running in which cloud – an up-to-date cloud inventory is of great help.
  2. Open-source infrastructure is key. Open-source infrastructure components like Kubernetes or OpenShift clusters or open-source databases can make a move between clouds much easier. The more proprietary services you use, the harder it will be to adapt your application to run in a new cloud environment.
  3. Go multi-cloud from the beginning. Contract negotiations between enterprises and cloud providers can take a while. It’s too late to start the process when it’s actually time to move
  4. Watch out for organizational lock-in. Even if from a technical perspective your application can easily be moved to a different cloud provider, there’s more to it. If you are running cloud applications at scale, setting up the corresponding cloud environments transferring permissions and configurations comes with massive complexity. Use a centralized governance system like meshcloud to keep your organizational structures independent from specific providers.

To learn more about the meshcloud platform, please get in touch with our sales team or book a demo with one of our product experts. We're looking forward to getting in touch with you.


Cloud Landing Zone Lifecycle explained!

The Cloud is the backbone and foundation of digital transformation in its many forms. The - quite literal - foundation for a successful transformation to the cloud is the concept of landing zones. This post will cover the management of landing zones over their lifetime.

But let's start with a brief definition of what a landing zone is and does:

What is a Landing Zone?

A landing zone is the underlying core configuration of any cloud adoption environment. Landing zones provide a pre-configured environment - provisioned through code - to host workloads in private, hybrid, or public clouds. You don't want to hand your developers "naked" cloud tenants - completely unconfigured AWS accounts, Azure subscriptions, or GCP projects.

Here are 4 key aspects a landing zone can and should take care of in your cloud:

  1. Security & Compliance
  2. Standardized tenancy
  3. Identity and access management
  4. Networking

A landing zone is certainly the starting point of your cloud journey - but it is also a constantly evolving core component of your infrastructure.

Benefits of Landing Zones:

Landing Zones allow you to standardize cloud environments that are provisioned to DevOps teams. They offer consistency across all tenants in naming, scaling, and access control. With that comes a security baseline that preempts (accidental) non-compliant or unauthorized configurations.

So let's talk about the different phases of a landing zones lifecycle!

Design, Deploy, Operate: 3 "Days" in the life of a landing zone

In software development you often hear the terms

"Day 0/Day 1/Day 2".

Those refer to different phases in the life of a software: From specifications and design (Day 0) to development and deployment (Day 1) to operations (Day 2). For this blog post, we're going to use this terminology to describe the phases of the landing zone lifecycle.

Visualization of a cloud landing zone lifecycle.

Day 0: Designing a Landing Zone

As the starting point of your cloud journey and the core component of your cloud environment landing zones should be well thought out and strategized - certainly with Day 1 and 2 in mind. Let's expand on the 4 aspects a well-designed landing zone should take care of in the cloud:

  1. Security and Compliance: Centralize your security, monitoring, and logging approach. Company-wide compliance and data residency policies for example can be implemented with landing zones. This way you can ensure a base level of compliance over multiple tenants or environments.
  2. Standardized tenancy: Enforce tagging policies across multiple cloud tenants and provide standardized tenants for different security profiles (dev/staging/prod).
  3. Identity and access management: Implement the principle of least privilege by defining roles and access policies. Define your user ID configurations and password standards across tenants.
  4. Networking: Provide IaaS network configurations, firewalls, and other basic networking parameters you want to have in place.

Day 1: Deploying a Landing Zone

On Day 1 it comes to customizing and deploying a landing zone according to the design and specifications determined on Day 0. The implementation of the landing zone concept is handled differently by every public cloud service provider.

Let's have a look at the big 3 CSPs:

Microsoft Azure: Within Microsoft's public cloud platform the concept of landing zones is implemented in the Cloud Adoption Framework. A major tool is Azure blueprints: You can choose and configure migration landing zone blueprints within Azure to set up your cloud environments. As an alternative, you can use third-party services like terraform.

Amazon Web Services: The landing zone solution provided by AWS is just called AWS Landing Zone. This solution includes a security baseline pre-configuring AWS services like CloudTrail, GuardDuty, and Landing Zone Notifications. The service also automates the setup of a landing zone environment thereby speeding up cloud migrations. Depending on your use case AWS offers Cloud Formation Templates to customize and standardize service or application architectures.

Google Cloud Platform: With GCP the Google Deployment Manager is the way to go to write flexible template and configuration files. You can use a declarative format utilizing Yaml - or Python and Jinja2 templates - to configure your deployments.

Day 2: Operating a Landing Zone

Cloud environments and their usage are never static. That means ongoing effort has to go into the management and operations of the underlying landing zones.

As your use of the cloud expands, the landing zones need to be well-maintained and updated as all aspects of cloud environments evolve: Implementing new best practices from the cloud providers, reacting to new needs that arise from new applications or responding to upcoming security threats. Make sure to keep your architecture flexible enough to be able to expand and update your landing zones during operations.

The meshcloud take on Landing Zones

We at meshcloud have our own take on the landing zone concept: With meshLandingzones we support native tooling provided by the different cloud platforms and vendors. This way we ensure seamless integration of existing operational capabilities and leverage the most powerful and best-integrated tooling available for each platform. In most instances, this tooling follows an infrastructure-as-code paradigm that fits naturally with meshcloud's multi-cloud orchestration approach.

On day 0, the design of the landing zones is done by native tools of the respective providers.
On day 1 meshcloud comes into play for the deployment. For example, previously created Azure blueprints can be integrated into meshLandingzones. meshLandingzones rely on the various native tools of the providers: In the case of AWS, these are in particular OU Assignments, Lambda Invocations, and Cloud Formation Templates.

For day 2 operations meshcloud offers various mechanisms for landing zone management. With fast updates of landing zones across many projects, it is possible to react to short-term security risks. The long-term development of landing zones to comply with new regulations and requirements is made possible by versioning the landing zones. With meshcloud, you always have a cross-platform overview of which projects use which landing zone (and in which version).



To learn more about the meshcloud platform, please get in touch with our sales team or book a demo with one of our product experts. We're looking forward to getting in touch with you.


Shadow IT is a risk in multi cloud managment

Under the Radar: The Risks of Shadow IT

Shadow IT is a risk in multi cloud managment

The IT requirements of employees are clear: flexible, adaptable and tailored to the processes of the specialist departments. In many companies this requirement is met on their own initiative - past the official infrastructure this becomes an incalculable cost and security risk.

 

Anyone who discovers a tool that makes work easier is seldom in compliance with the rules and regulations of the IT department. With cloud services, an account is created quickly and colleagues are easily convinced. According to a survey by the Cloud Security Alliance, only 8% of the CIOs believe they know about the secret digital infrastructure in their company. This shadow IT, or Stealth IT as it is more aptly referred to, hides from the radar of IT managers. Eco, the Association for the Internet Economy, asked 580 experts from German medium-sized companies for its IT security report - the result is clear and worrying: three quarters of those surveyed assume that a shadow IT exists in their company. Nearly 25% fear a "considerable extent".

 

Parallel structures as the sword of Damocles

It is not by chance that shadow IT is the subject of an IT security report: The direct advantages of the services that employees establish in parallel to the official structures quickly fade when looking at the risks. Unauthorized IT is impossible to secure and endangers business data and processes. A study commissioned by Tenable Network Security has shown that 38% of German companies have already lost data due to unauthorised hardware and software. Failures and associated costs are imminent. The hidden IT structures float above the company's activities like a sword of Damocles. The great uncertainty regarding existence, extent and relevance leads to the fact that nobody can say how big and sharp this sword really is. The only way to control this risk is to reduce shadow IT. A heightened awareness of the causes is essential.

 

Shadow IT as an opportunity for transformation

The reasons why employees use unauthorized tools and cloud services lie often in the relationship to their own IT department. At the outset there is the desire for certain capabilities of the IT used - insufficient coordination, lack of know-how and rigid budgets often prevent this desire from being reflected in the official company IT. Cloud services play a special role here. For every problem, no matter how specific, there is a cloud solution somewhere. In an interview with Harmon.ie, 48% of the "knowledge workers" surveyed admitted using unauthorized cloud services. Most of the services used in this way lack management, security and compliance features. GDPR conformity is also missing. However, the development of shadow IT can certainly have a positive influence on motivation and innovation at this point. In this respect, IT managers should see it as an opportunity. Anyone who knows what the specialist departments consider important enough to implement without following the regulations will receive valuable information for the further development or even transformation of the digital infrastructure in the company.

The key to reducing shadow IT is proximity to the needs of users. Integrating shadow IT into the company's IT management and close coordination between the business and IT departments is necessary to design a transformation that combines flexibility and user-friendliness with company policies and legal requirements. 

 

At meshcloud we are strongly dedicated to help companies avoid shadow IT, by reducing the complexity of their multi-cloud environments. The meshcloud platform provides a single pane of glass to support seamless use of multiple cloud platforms without vendor lock-in or loss of efficiency. We streamline processes by providing self-service-access to developers as well as transparency and cost control to IT leaders.

Do you want to learn more? Please send us a note and we will get in touch with you

[contact-form-7 id="4173" title="Contact Form Blogpost"]