I believe that by 2018, we have all heard how security is a shared responsibility, and how companies and their leaders must be informed and be ultimately responsible for the cybersecurity of their organizations. But what is rarely heard are success stories where these principles are applied and where C-level executives accept this responsibility transparently, without looking for ways to shirk the issue just because it is “something technical.”

If the theory applied, organizations and their executives would understand the crucial role they play in all technical aspects of their organization. We must remember that the self-regulation of technology organizations (Vice Presidencies or Departments) has not been very successful, in part because there are many options, and a clear example is the topic of the cloud. The answer to difficult questions like, “What cloud provider should we use? Amazon? Google? Microsoft?” quickly becomes a religious crusade, where no side advances and everyone believes they are right.

The impact of the lack of leadership from the executive level in technology organizations is devastating and usually puts them on the path to failure.

When the scenario is ideal and there is clear direction from the executive level, then the technical exercise becomes much clearer, using criteria such as:

  1. Opex vs. Capex
  2. Local presence of the cloud provider
  3. Support levels
  4. Deployment speed
  5. Security

Taking into account that Microsoft’s cloud services have a tangible advantage, at least in Panama.

  1. Local offices
  2. Local and remote support
  3. Quite decent response times
  4. Multiple licensing options (sometimes this is a disadvantage)
  5. Availability of cloud architects who can help, among other topics, with ensuring cloud deployment

Taking into account that my experience is more with Azure, this article focuses on the capabilities of this option. I still need to explore Amazon and Google.

Without redundancy from the previous article, it is necessary to note that a migration to the cloud, regardless of the selected provider, basically involves transferring existing on-prem processes and procedures to the cloud, making the necessary adjustments to adapt them to that environment. This requires that such processes and procedures exist before attempting a migration of services to the cloud. Otherwise, it will be very difficult to manage the costs of that deployment and makes it practically impossible to secure it.

What are the real threats?

As they say, a picture is worth a thousand words. A nice way to understand the problem can be by looking at it in the following graph: http://informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/

In this visualization, I filtered for only two types of attacks: hacked (red) and insider attacks (purple).

If we add to this the number of new vulnerabilities, their severity, and the fact that complete malware platforms can now be rented as a service to attack specific organizations, then we can conclude that the threat landscape is real, that we are not selling fear to executives, and that such threats must be expressed in common language that allows technicians to obtain the resources needed to secure the workloads that have been migrated to the cloud.

With this in mind, I next propose a list of steps for secure cloud, based on my brief experience (3 years) with these technologies:

  1. Stay Informed

    This may sound like a broken record, but the truth is there is no alternative. Now it is not only about staying informed about threats, but also about defense techniques, best practices, and so on.

    As always, NIST provides a lot of information, and the cloud topic is no exception. At this link https://www.nist.gov/publications/nist-cloud-computing-reference-architecture, you can find NIST’s cloud computing reference model (publication 500-292). This model serves to put things in context and standardize the terms to use when talking about cloud.

    On the specific topic of security, NIST also has another publication “Cybersecurity Framework” (https://www.nist.gov/programs-projects/cybersecurity-framework).

    And already getting into the topic of security in Azure, Microsoft has quite a bit of information. However, the required reading to start the conversation on the topic is the shared responsibility document in the cloud, published at the following link https://gallery.technet.microsoft.com/Shared-Responsibilities-81d0ff91.

  2. Azure Cloud Networking, Encryption, and Data Storage

    I think the concept of cloud could not exist without data encryption, which gives us the possibility to use VPNs, HTTPS everywhere, and data encryption at rest.

    But this is not enough. Data encryption at rest and in transit must be part of your cloud solution (https://docs.microsoft.com/en-us/azure/security/azure-security-data-encryption-best-practices).

    In Azure, this is reality out-of-the-box. However, it must be noted that this level of encryption may be insufficient since Microsoft controls the private keys. To ensure that Microsoft employees do not have access to customer data, you should implement the BYOK (Bring Your Own Key) scheme through Azure Key Vault implementation (https://blogs.technet.microsoft.com/kv/2015/01/08/azure-key-vault-making-the-cloud-safer/).

    On encryption, there will always be debate about the access the cloud provider has to customers’ encrypted data. In civil matters, Azure Key Vault scheme is sufficient to ensure that any demand Microsoft receives is redirected to the customer who owns the information, since the provider would not have access to the information encrypted with the customer’s private key. However, in criminal matters, there is a whole range of legal options that may or may not be contrary to the best interests of cloud service users.

    In this last scenario, it is concerning to see how the U.S. government has made trans-border access to information easier, setting aside the usual channel of MLATs (Mutual Legal Agreements). This law, known as the CLOUD ACT (https://en.wikipedia.org/wiki/CLOUD_Act), was passed without extensive consultation within the federal government budget. This topic is quite recent, so I believe its disclosure has not been very widespread.

    Regardless of legal limitations, the number one tip when consuming cloud services is to encrypt everything: data at rest, in transit, virtual machines, use VPNs and/or encrypted web services (HTTPS). This applies to everything done in the cloud, whether internal development, virtual machine deployment (IaaS), service consumption (PaaS), and so on. This topic is especially delicate when it comes to development, as programmers may not have experience with encryption and security technologies, as they are accustomed to applications existing within a perimeter under the control of the organization. In the cloud, the perimeter does not exist, and the identity of users and their information are the priority.

  3. Identity Management and Multiple Factor Authentication

    In everything related to user identity, we tend to think about the minimum necessary. Usually a password is sufficient, and the minimum password complexity rules are not even considered. How many times do we not hear users complaining when minimum password complexity rules are implemented? This is especially true when we are talking about users in technology departments.

    Now, imagine the process of implementing things like:

    • Single Sign-On
    • Multiple Factor Authentication (MFA)
    • Device registration
    • Administrative credential management (Privileged Identity Management)
    • Conditional access control
    • Hybrid identity systems
    • Role-based access control (RBAC)

    I think the idea is understood. The selection and implementation of access controls is complex. However, its result should be an integrated identity management solution that is easy to use for both administrators and end users.

    This requires robustness in the IT processes that support this function (security and helpdesk).

    The good thing about making cloud deployments is that it gives us many tools to choose from. Specifically, in Azure, we can find that RBAC and MFA are included without much fuss. The rest of the options might have a cost, but the other advantage is that if the model works for the cloud, it should work for on-prem resources. In other words, the model is extensible.

    This is a good place to start reading about identity management in Azure: https://docs.microsoft.com/en-us/azure/security/azure-security-identity-management-best-practices.

    Here is another interesting link: https://docs.microsoft.com/en-us/azure/active-directory/identity-fundamentals

  4. Azure Security Center

    Usually the security teams are always against cloud deployments. I imagine this is because of the feeling of loss of control over the perimeter (as if it still mattered), loss of visibility into logs, and other myths and legends we have learned through the years. These are usually related to security by obscurity practices or the famous FUD (Fear, Uncertainty, and Doubt), which has traditionally served us to get our budgets.

    Having to admit that these dark practices of the past are not actually effective causes resistance to cloud adoption, which cannot accommodate these concepts. The reason is that when a provider offers the cloud service, it must be based on widely proven and well-known processes and procedures (ITIL, Cobit, ISO, NIST, etc.). This always provokes the question at executive levels: “And why were we not doing this before?” And the typical answer from technology departments: “Because that is how we have always done it.”

    This is the main obstacle to cloud adoption. However, security departments cannot afford that luxury. Simply, we have not existed long enough, nor have we operated in only one way long enough, to say that we have always done it one way or another. The reason is that the threat landscape changes constantly, actors change, motivations change, and if your security office is not changing constantly, simply, you are not doing your job.

    Now, returning to Azure, the best way to address all these changes in the fastest, simplest, and most economical way possible is by implementing Azure Security Center (https://docs.microsoft.com/en-us/azure/security-center/security-center-intro).

    It is simply the place where we will find all types of information related to our technology plant. And before you ask, the monitoring agents can also be installed on your on-prem servers so that you have a single control and monitoring console for the security state of everything in the cloud and, if your budget allows, everything that is on-prem.

    From my perspective, it is not possible to perform a cloud deployment without a tool like this. Everything else is simply irresponsible, as you cannot perform a cloud migration and simply hope nothing bad happens.

    Remember that in the cloud, data responsibility is always the customer’s and never the provider’s job.

I am sure that many more topics got away from me, but the good news is that that can provoke an interesting conversation.