New platforms for hybrid cloud monitoring bring both new capabilities and new challenges. We have already discussed some differences between monitoring the different cloud models, and some of the different deployment options available. This post will dive into some technical considerations for these new hybrid platforms, highlighting potential benefits and issues for data security, privacy, scalability, security analytics, and data governance.

As cool as a ‘CloudSOC’ sounds, there are technical nuances which need to be factored into your decision and selection processes. There are also data privacy issues because some types of information fall under compliance and jurisdictional regimes. Cloud computing and service providers can provide an opportunity to control infrastructure costs more effectively, but service models costs are calculated differently that on-premise systems, so you need to understand the computing and storage characteristics of the SOC platform in detail to understand where you are spending money.

Let’s jump into some key areas where you need to focus.

Data Security

As soon as event data is moved out of one ‘cloud’ such as say Salesforce into another, you need to consider the sensitivity of the data, which forces a decision on how to handle security. Using SSL or similar technology to secure the data in motion is the easy part – what to do with the data at rest, once it reaches the CloudSOC, is far more challenging.

You can get some hints from folks who have already grappled with this question: security monitoring providers. These services either build their own private clouds to accommodate and protect client data, or leverage yet another IaaS or PaaS cloud to provide the infrastructure to store the data. Many of you will find the financial and scalability advantages of storing cloud data in a cloud services more attractive than moving all that collected data back to an on-premise system.

Regardless of whether you build your own CloudSOC or use a managed service, a key part of your security strategy will be the Service Level Agreements (SLAs) you establish with your providers. These agreements specify the security controls implemented by the provider, and if something is not specified in that agreement the provider has no obligation to provide it. An SLA is a good place to start, but be wary of unspecified areas – those are where gaps are most likely emerge.

A good place to start is a comparison of what the provider does with what you do internally today. We recommend you ask questions and get clear answers on every topic you don’t understand because once you execute the agreement you have no further leverage to negotiate. And if you are running your own make sure you carefully plan out your cloud security model to take advantage of what your IaaS provider offers. You may decide some data is too sensitive to be stored in the cloud without obfuscation (encryption) or removal (typically redaction, tokenization, or masking).

Data Privacy and Jurisdiction

Over and above basic data security for logs and event data, some countries have strict laws about how Personally Identifiable Information (PII) data may be collected and stored, and some even require that PII not leave its country of origin – even encrypted. If you do business in these countries your team likely already understands the regulations today, but for a hybrid SOC deployment you also need to understand the locations of your primary and backup cloud data centers, and their regional laws as well. This can be incredibly confusing – particularly when data protection laws conflict between countries.

Once you understand the requirements and where your cloud (including CloudSOC) providers are located, you can effectively determine which security controls you need. Once again data encryption addresses many legal requirements, and data masking and tokenization services can remove sensitive data without breaking your applications or impairing security analytics. The key is to know where the data will be stored to figure out the right mix of controls.

Automation and Scalability

If you have ever used Dropbox or Salesforce or Google Docs, you know how easy it is to store data in the cloud. When you move beyond SaaS to PaaS and IaaS, you will find it is just as easy to spin up whole clusters of new applications and servers with a few clicks. Security monitoring, deploying collectors, and setting up proxies for traffic filtering, all likewise benefit from the cloud’s ease of use and agility. You can automate the deployment of collectors, agents, or other services; or agents can be embedded in the start-up process for new instances or technology stacks. Verification and discovery of services running in your cloud can be performed with a single API call. Automation is a hallmark of the cloud so you can script pretty much anything you need.

But getting started with basic collection is a long way from getting a CloudSOC into production. As you move to a production environment you will be constructing and refining initialization and configuration scripts to launch services, and defining templates which dictate when collectors or analytics instances are spun up or shut down via the magic of autoscaling. You will be writing custom code to call cloud APIs to collect events, and writing event filters if the API does not offer suitable options. It is basically back to the future, hearkening back to the early days of SIEM when you spent as much time writing and tuning collectors as analyzing data.

Archiving is also something you ll need to define and implement. The cloud offers very granular control of which data gets moved from short-term to long-term storage, and when. In the long run cloud models offer huge benefits for automation and on-demand scalability, but there are short-term set-up and tuning costs to get a CloudSOC working the way you need. A managed CloudSOC service will do much of this for you, at additional cost.

Other Considerations

• Management Plane: The management plane for cloud services is a double-edged sword; IT admins now have the power to automate all services, using simple commands, from a single dashboard. It also means you are completely screwed if an attacker gains access to the console. The power provided by the management console and management APIs require greater attention and diligence to ensure proper authentication and authorization than on-premise systems. That means focusing far more attention on administrative rights, administrative entitlements, and monitoring from where from and by whom the console is accessed – via both web console and API calls. Finally, we recommend a heavy dose of threat modeling to ensure your policies are tuned to how an attacker could misuse cloud resources to access your cloud management environment.
• Analytics: To better detect malware and application misuse, companies are looking to leverage cloud-based big data computing environments for security analytics. This is a highly specialized field, with tools and techniques evolving rapidly. Cloud infrastructure providers offer sophisticated analytical tools and infrastructure as part of their core offerings, helping accelerate development of these capabilities for security. The issue is generally not lack of infrastructure, but more likely a personnel skills gap. Building and running security analytics require both facility with “big data” architecture and security analytics knowhow (practitioners are typically called “data scientists”) to mine through it. Regardless of how little it costs to create a data warehouse today, only a handful of companies actually employ people capable of standing up a sophisticated security analytics environment. So we see more companies engaging third party services – sometimes even in parallel with their own efforts – to perform additional analysis and triage security events across cloud and on-premise systems.
• Pricing Model: To build your own CloudSOC you need to reconsider the economic model for cloud services when you plan for how to move, store, and process data. Data travels through your data center for free. You ran the cable and installed the switches; those sunk costs enable you to use all your available bandwidth without additional costs. PaaS and IaaS providers offer different pricing tiers for different types of network connectivity. Some offer free network services for ‘local’ traffic (within an availability zone), but charge for data movement between data centers. If you leverage cloud messaging services for added reliability and event processing in your SOC, you will pay a tiny fraction of a penny per message. But even that low per message-price adds up across the millions or billions of events you capture and process every year. Different data storage tiers are available, where performance and reliability rise along with costs. The good news is that cloud providers offer much better metrics and fairly clear pricing on available services. The bad news is that you need to figure out how much of some abstract service you have never used is needed so you can model the costs of your cloud environment. Cloud economic models are fundamentally different, but your need to model costs is the same.

Our next post will detail how to get from A to B: The Migration Process to Monitoring the Hybrid Cloud. We will list the distinct phases of collecting and aggregating cloud data, compare partial against full migration to a CloudSOC, and offer specific advice on what to do and what to avoid.