3.6 Given a scenario, apply cybersecurity solutions to the cloud

  • Cloud Security Models
    • High Availability Across Zones
    • Resource Policies
    • Secrets Management
    • Integration and Auditing
    • Storage
      • Permissions
      • Encryption
      • Replication
      • High Availability
    • Network
      • Virtual Networks
      • Public and Private Subnets
      • Segmentation
      • API Inspection and Integration
    • Compute
      • Security Groups
      • Dynamic Resource Allocation
      • Instance Awareness
      • Virtual Private Cloud (VPC) Endpoint
      • Container Security
  • Solutions
    • CASB
    • Application Security
    • Next-Generation Secure Web Gateway (SWG)
    • Firewall Considerations in a Cloud Environment
      • Cost
      • Need for Segmentation
      • Open Systems Interconnection (OSI) Layers
  • Cloud Native Controls vs Third-Party Solutions


Cloud Security Models

Now we must look at cloud security.  Since most data is in the cloud, how do we keep it secure?

  • High Availability Across Zones.  Recall that a cloud service provider will have data centers in multiple locations.  Below is a map of AWS data centers in North America.  Each location is known as a region.  For example, the regions are Northern Virginia, Ohio, Oregon, Northern California. 

  • When we create an application, we want to host it in the region that is closest to the users.  This reduces latency (the amount of time that it takes data to reach them).  If we have users in multiple geographic locations, then we might create multiple instances of our application and host one in each availability zone.  This ensures that each user can have access to a nearby data center.

    Within each region are multiple availability zones.  The Oregon region has four availability zones.  An availability zone is a separate data center.

    If we are concerned about an outage at one data center, we might create a copy of our application at a second data center (a second availability zone).  The two instances might share the traffic, or we might configure one instance as active and the other to be on standby.

    AWS availability is improving, so by the time that you read this, it might be better, but let’s look at what we can do right now

    • There are encrypted, dedicated fiber links between the various availability zones in each AWS region

    • That means we can have synchronous replication between availability zones.  If we have a database in one availability zone, and a copy in another availability zone, both databases can maintain the same content.

    • Availability zones are approximately 80 km apart.  They are far enough apart that a natural disaster won’t affect more than one, but close enough that the latency between them will be low.

    • AWS Local Zones are an extension of the regions.  AWS has smaller data centers in cities with large populations, such as Los Angeles, New York, Boston, Chicago, Dallas, Denver, Houston, Las Vegas, and Portland. 

      We can place applications that are more sensitive to latency at the local zones so that the data is closer to users.  For example, Netflix places servers at each local zone so that the video content does not have to travel far to reach users in big cities.  This reduces the cost of transporting the video and improves performance.

    • AWS Wavelength has application servers in 5G networks.  This allows us to install a latency-sensitive application inside a 5G network and reach users quickly.

  • Resource Policies.  A resource policy limits which users have access to each cloud device.  The policy might limit the type and/or quantity of devices that users can create or modify.

  • Secrets Management.  Since there are many devices and applications, we need a reliable way to store all of the credentials.  These include

    • Credentials to access the cloud account.  This may be linked to a user’s organizational account through Single Sign On.

    • Credentials to access each cloud server such as a web server or database server.  If we deploy Active Directory or RADIUS in the cloud, then we can authenticate each user via their organizational account.  However, each local username and password must be maintained somewhere.

      The cloud service provide might have the ability to store these credentials.  Otherwise, we must set up a credential server that stores all the credentials.  The credentials server provides passwords to users as required.

  • Integration and Auditing.  We must run regular audits to ensure that our security policies are working as intended.  We must also run random audits to check for abnormal activity (such as users accessing devices that are not in their scope of work).

  • Storage

    • Permissions.  Data should always be subject to the most secure permissions.  Only the people who need access to the data should have it.  By default, many cloud storage applications set data permissions to allow the public access.  That means that anybody on the internet can view your data.

    • Encryption.  We must encrypt all data at rest.  The encryption key should not be held by the cloud service provider.  You should encrypt all the data before you upload it.

    • Replication.  We want to ensure that a back up of our data is made.

    • High Availability.  As discussed, we want to ensure that our data is synchronized across multiple availability zones in the event of an outage.

  • Network

    • Virtual Networks.  We can create different VLANs, firewalls, routers, and switches in the cloud just like we can in the real world.  We should implement the same security on these virtual devices as we would on a physical network.  The cost of deploying a virtual firewall is minimal compared to the cost of the deploying a physical firewall.

    • Public and Private Subnets.  The cloud will limit the number of available public IP addresses.  We should only expose to the internet as few resources as necessary to serve the purpose of our application.

      For example,

      • We have a web server with an application

      • The web server talks to a database server

      • The web server must be exposed to the internet so that users can access the application.  They do so through the public subnet.

      • The database server should not be exposed to the internet.  It is only connected to the private subnet.

    • Segmentation.  If we have a large cloud-based network, we can segment it further so that applications only share necessary data.  This reduces the amount of harm that a malicious user or application could do.

    • API Inspection and Integration.  If we are using an API to connect to our network, we should monitor all calls sent to the API and ensure that they are legitimate.

  • Compute

    • Security Groups.  A security group is a set of rules for what a member can access and cannot access.  In general, when we create a resource (such as a server), we add it to one or more security groups. 

      A security group’s rules list the IP addresses and ports on the public internet and on the private subnets that a device is permitted to access (or not permitted to access).  It also lists incoming connections and ports that are blocked (or permitted). 

      When there are many security groups with conflicting rules, the firewall chooses the one that is most restrictive.

      You should give each group a meaningful name.  Each group should have an implicit deny (deny all traffic that is not explicitly permitted by a rule in the group).

      When you have many devices, you should carefully design and validate your network topology before deploying anything.

    • Dynamic Resource Allocation.  As discussed earlier, Dynamic Resource Allocation allows us to scale our cloud devices up or down as required. 

      For example,

      • We are hosting a web application

      • Each server can handle 100 users

      • We have 500 users at the moment

      • Thus, we have five servers, connected via a load balancer

      • If the traffic increases to 1000 users, then our application can automatically detect the increased demand and provision five more servers

      • If the traffic drops to 700 users, our application can shut down three servers

    • Virtual Private Cloud (VPC) Endpoint.  Remember that we might have a Virtual Private Cloud (a bunch of cloud devices on our virtual cloud network, none of which are exposed to the internet).

      Now what if we want to connect our private on-premise corporate network to our virtual private cloud?  Or what if we want to connect our private cloud to the private cloud of another organization in order to exchange data?  We can use a VPC Endpoint to create a secure tunnel between the two networks.

    • Container Security.  If we deploy an application through serverless architecture, we must ensure that it is secure.  That means we must verify that the source code we upload is the same as the source code that we actually wrote.  We should scan the container regularly to verify that the application has not changed.  We should also limit access to each container.

Solutions

Some solutions for cloud security

  • CASB.  A CASB or Cloud Access Security Broker is a gateway that sits between users and the cloud.  The CASB can enforce organizational policies and apply them to the cloud.  It can also authenticate users and provide them with access to the resources that they require.

  • Application Security.  We must enforce the same security policies in the cloud as we do in the real world.

  • Next-Generation Secure Web Gateway (SWG).  Since many people are working from home, and since much data is in the cloud, we need a better way to secure our users.  Nobody really knows what it is, so SWG is a term that covers many technologies. 

    But in general, it is a firewall that sits in the cloud, but it sits between the user and the internet.  That means that your data travels to the cloud first, and then through the SWG, and then to its final destination.  There might be a VPN tunnel between the user and the SWG.

    These SWGs can do the following

    • Provide granular filtering of data

    • Protect against SaaS threats such as fake SaaS websites

    • Provide visibility into data stored by unmanaged apps

  • Firewall Considerations in a Cloud Environment
    • Cost
    • Need for Segmentation
    • Open Systems Interconnection (OSI) Layers




Cloud Native Controls vs Third-Party Solutions

Advantages of a Cloud Native Control

  • A cloud-native controller will always be more integrated than a third party since it is written by the cloud service provider.  A third-party solution will have to gather data from an API that the cloud service provider has made available.

  • A cloud-native controller will cost less than a third-party solution or may be free (it might be included with the cloud services).

  • A third-party solution increases the security risk because we are permitting a third party to access our cloud data.

Third-Party Solutions

  • A third-party might have more features than the cloud-native controller.  The third-party may have innovative tools or additional functionality that the cloud service provider is unable to provide.

  • A third-party tool might work across multiple cloud service providers.  If we are using more than one cloud service provider, then we can monitor everything from one location (a single pane of glass).  We can also monitor on premise devices from the same system.