If you are old school, if you once owned a real desktop computer, then the cloud likely looks like a server being racked on the Internet and given a marketing name, the “Cloud.” Much better than giving it a name like the “Warehouse.” As an engineer, we are fortunate that marketing didn’t call it that, for if we thought of the cloud as nothing more than a remote server, we would be changing nothing. The truth is that the cloud is not a server in a warehouse. The cloud has a distinct architecture and differs significantly from running server images of virtual systems.
Clouds teach a quick lesson:
They have a different cost model.
You cannot just port your server. This is the most inefficient and costly solution.
There are new layers of security.
Cost
I have heard a number of times that the cloud is expensive. Organizations that port their servers to the cloud are seeing an increase in total cost ownership, an opposite to the savings they had expected. Not seeing and using what makes the cloud different is like towing a truck around with horses instead of driving it. And it's just as cost-effective as that too. If we ignore what the cloud is different and make it act like the horse-drawn cart we are used to using, we are spending more money and being less productive.
Just moving an image to the cloud creates what some call fat containers. All the computation and disk are placed in a single structure. The design pays for everything to always be active. Since you are paying for time, it is imperative to separate what needs to always be active from what is needed when an event occurs.
"What do I need at this moment?" is a critical element to how to be efficient in the cloud. This is the main reason putting Elastic or Splunk in the cloud makes no sense. This type of software was designed by someone targeting a server, where the components are already paid and always active. Keeping the same design mentality will make the program magnitudes more expensive to run in the cloud than it would on an on-premise server.
Learning to Migrate
When Fluency first began migrating services to the cloud, we saw it as the Warehouse. Like most companies that migrate from on-premise solutions to the cloud, we just ported our servers and gave them the configuration that worked on-premise. We gave the device images the same storage, the same drive, the same drive speed. We created base images and were able to spur them off at will inside docker containers. What we did was learn how to scale the spending of money. Ouch.
What are these differences that make the cloud better? They are:
• processing on demand
• storage on demand
• storage types
And these parts come with a steep learning curve of how to set up the network properly. A significant amount of time was in understanding the bandwidths, speeds, and costs of different solutions and designs. There is the security of the AWS and the Virtual Private Cloud (VPC). And finally, there is learning how to automate the management of the cloud. Just like having a good human manager who can save money (and frustration), good AWS management does the same.
Mentally, moving to the cloud is not a task, but an opportunity. Hidden in the word opportunity is effort. It takes effort to properly migrate to the cloud. It takes vision and learning to understand how its difference changes the architecture, processes, and architecture.
After a year-long migration or rewriting code to be on-demand and dynamic, we are finally at the starting line. We needed to remove code that did not take advantage of clustering. We had to spur processes only when needed. We needed to change disk types depending on the need of the user or processes. The result was a system completely different than the server-based approach we had at the start. It has speed, high-availability, and scalability that cannot be matched by a server or server image.
Securing the Cloud
There are four basic elements to audit a network, and we can map them to their cloud counterparts.
• User: Appears in SaaS & IaaS
• Services: SaaS like Microsoft365 and Zoom
• Assets: Are called containers, which send data to CloudTrail
• Infrastructure: AWS services Like CloudWatch & CloudTrail, to include VPC flows, produce the management access and network view into the IaaS.
Three years ago, we enhanced Fluency to absorb cloud data, such as SaaS, PaaS, and IaaS. The lesson we learned is that while there are different technologies to learn and different ways to do things, there is a common pattern in the cloud that is familiar to those that secure a network.
To change the view from model to sources, we can see clearly what we need to collect.
SaaS logs. These collected with API calls or webhooks to services like Microsoft365, Zoom, or Salesforce
Platform Audit. These are the logs from processes that operate in a system-like manner (fat container).
Containers Audit. This is AWS CloudTrail and Azure Eventhub audit. It is divided into two parts, the moving of the data out of the container and the centralization of the data.
Cloud Control Plane. This is by far the most forgotten and critical aspect of cloud security. This is the audit of the cloud assets and sits outside the container. It includes also the container flow data (VPC Flows) and administrative logs of the cloud.
Fluency collects this data and relates it so that it can be understood more clearly in a traditional operations view. This allows operators clarity on what asset or user needs to be addressed. This relationship technique is called user-entity based analytics (UEBA). The style of looking at audit using UEBA is similar to the difference of standard structure coding to object-oriented coding. UEBA produces a more natural way of looking, analyzing, and responding to audit.
For example, when a container awakens on the cloud it will appear in the VPC flow as an IP address. If there is an issue with the flow, there is no data to let you know what container is creating the problem. Fluency resolves this problem by dynamically binding audit data in realtime. In this example, when a container tells CloudTrail it is on a particular IP address, Fluency adds the container name to the flow audit logs. This is critical, for in a cloud infrastructure administration needs the container name in order to address the issue.
Fluency also reviews all audit against best security practices and issues detection in real-time. Fluency does this by defining the events with UEBA rules. Rules can detect action events, such as service interruption, multiple-location logins, and abnormal privilege user access.
Fluency comes with a number of prebuilt UEBA rules to watch for cloud security issues. The UEBA is real-time, as it searches the data stream coming in for these issues, not requiring searching. With Fluency, analysts can extend their robust process from the traditional network into the cloud.
Summary
Are we happy we went through all this effort? Yes. While a horse-drawn carriage is nostalgic, business is about efficiency. The benefits of the cloud will continue to be more obvious, but we have learned that many of the tools we once used are outdated and need to be addressed differently for a cloud.