Cloud security monitoring

Moving data and applications to the clouds is a new challenge for enterprise SOCs, which are not always prepared to monitor other people's infrastructure. According to Netoskope, the average enterprise (apparently still in the US) uses 1246 different cloud services, which is 22% more than a year ago. 1246 cloud services!!! Of these, 175 are in HR services, 170 are in marketing, 110 are in communications, and 76 are in finance and CRM. Cisco uses “only” 700 external cloud services. So I'm a little confused by these numbers. But in any case, the problem is not in them, but in the fact that clouds are quite actively being used by an increasing number of companies that would like to have the same capabilities for monitoring cloud infrastructure as in their own network. And this trend is growing American Accounting Office data by 2023, 1200 data centers are going to close in the USA (6250 have already closed). But moving to the cloud isn't just about "let's move our servers to an external provider." New IT architecture, new software, new processes, new restrictions... All this makes significant changes in the work of not only IT, but also information security. And if providers have learned how to deal with the security of the cloud itself (fortunately, there are a lot of recommendations), then there are significant difficulties with cloud-based information security monitoring, especially on SaaS platforms, which we will talk about.

Let's say your company has moved part of its infrastructure to the cloud... Stop. Not this way. If the infrastructure is transferred, and you are only now thinking about how you will monitor it, then you have already lost. Unless it's Amazon, Google, or Microsoft (with some caveats), then you probably won't have much control over your data and applications. Well, if you are given the opportunity to work with the logs. Sometimes security event data will be available, but you won't have access to it. For example, Office 365. If you have the cheapest E1 license, then security events are not available to you at all. If you have an E3 license, your data is stored for only 90 days, and only if you have E5, the duration of the logs is available for a year (however, there are also some nuances associated with the need to separately request a number of functions for working with logs from Microsoft support). By the way, the E3 license is much weaker in terms of monitoring functions than the corporate Exchange. To achieve the same level, you need an E5 license or an additional Advanced Compliance license, which may require additional money that was not included in your cloud infrastructure transition financial model. And this is just one example of the underestimation of issues related to cloud information security monitoring. In this article, without claiming to be complete, I want to draw attention to some of the nuances that you should consider when choosing a cloud provider in terms of security. And at the end of the article, a checklist will be given that you should complete before considering that the issue of monitoring cloud information security has been resolved for you.

There are several typical problems that lead to incidents in cloud environments, to which information security services do not have time to respond or do not see them at all:

• Security logs do not exist. This is a fairly common situation, especially among novice players in the cloud solutions market. But it’s not worth putting an end to them right away. Small players, especially domestic ones, are more responsive to customer requirements and can quickly implement some of the requested functions by changing the approved roadmap for their products. Yes, it will not be an analog of GuardDuty from Amazon or a “Proactive Defense” module from Bitrix, but at least something.
• IB does not know where the logs are stored or there is no access to them. Here it is necessary to enter into negotiations with the cloud service provider - perhaps he will provide such information if he considers the client significant for himself. But in general, it is not very good when access to the logs is granted “by special decision”.
• It also happens that the cloud provider has logs, but they provide limited monitoring and event logging, which are insufficient to detect all incidents. For example, you can only be given change logs on the site or logs of user authentication attempts, but other events, for example, about network traffic, will not be given, which will hide from you a whole layer of events that characterize attempts to hack your cloud infrastructure.
• There are logs, but access to them is difficult to automate, which makes them monitor not continuously, but on a schedule. And if it is still impossible to download the logs in automatic mode, then uploading the logs, for example, in Excel format (as with a number of domestic cloud solution providers), may even lead to an unwillingness to bother with them on the part of the corporate information security service.
• No log monitoring. This is perhaps the most misunderstood reason for the occurrence of information security incidents in cloud environments. It seems that there are logs, and it is possible to automate access to them, but no one does this. Why?

Shared cloud security concept

Going to the clouds is always a balancing act between wanting to keep control of the infrastructure and putting it in the more professional hands of a cloud provider that specializes in maintaining it. And in the field of cloud security, this balance also needs to be sought. Moreover, depending on the cloud service model used (IaaS, PaaS, SaaS), this balance will be different all the time. In any case, it must be remembered that all cloud providers today follow the so-called shared responsibility and shared information security model. The cloud is responsible for something, the client is responsible for something, having placed his data, his applications, his virtual machines and other resources in the cloud. It would be reckless to expect that by going to the cloud, we will shift all responsibility to the provider. But building all the security on your own when moving to the cloud is also unreasonable. A balance is needed, which will depend on many factors: - risk management strategies, threat models, protective mechanisms available to the cloud provider, legislation, etc.

For example, the classification of data hosted in the cloud is always the responsibility of the customer. A cloud provider or an external service provider can only help him with tools that will help label data in the cloud, detect violations, remove data that violates the law, or mask it using one method or another. On the other hand, physical security is always the responsibility of the cloud provider, which he cannot share with customers. But everything that is between the data and the physical infrastructure is precisely the subject of discussion of this article. For example, the availability of the cloud is the responsibility of the provider, while setting up ITU rules or enabling encryption is the responsibility of the client. In this article, we will try to see what information security monitoring mechanisms are provided by various popular cloud providers in Russia today, what are the features of their use, and when it is worth looking towards external overlay solutions (for example, Cisco E-mail Security), which expand the capabilities of your cloud in terms of cyber security. In some cases, especially if you follow a multi-cloud strategy, you will have no choice but to use external information security monitoring solutions in several cloud environments at once (for example, Cisco CloudLock or Cisco Stealthwatch Cloud). Well, in some cases, you will realize that the cloud provider you have chosen (or imposed on you) does not offer any information security monitoring capabilities at all. This is unpleasant, but also a lot, as it allows you to adequately assess the level of risk associated with working with this cloud.

Cloud security monitoring life cycle

To monitor the security of the clouds you use, you have only three options:

• rely on the tools provided by your cloud provider,
• use third-party solutions that will monitor the IaaS, PaaS or SaaS platforms you use,
• build your own infrastructure for monitoring cloud environments (only for IaaS / PaaS platforms).

Let's see what features each of these options has. But first, we need to understand the general scheme that will be used when monitoring cloud platforms. I would single out 6 main components of the information security monitoring process in the cloud:

• Infrastructure preparation. Determination of the necessary applications and infrastructure for collecting events important for information security in the repository.
• Collection. At this stage, security events are aggregated from various sources for their subsequent transmission for processing, storage and analysis.
• Treatment. At this stage, the data is transformed and enriched to facilitate their subsequent analysis.
• Storage. This component is responsible for short-term and long-term storage of the collected processed and raw data.
• Analysis. At this stage, you have the opportunity to detect incidents and respond to them automatically or manually.
• Reporting. This stage helps to form key indicators for stakeholders (management, auditors, cloud provider, customers, etc.) that help us make certain decisions, for example, changing a provider or strengthening information security.

Understanding these components will allow you to quickly decide in the future what you can take from your provider, and what you will have to do yourself or with the involvement of external consultants.

Built-in cloud services

I already wrote above that many cloud services today do not provide any possibility for monitoring information security. In general, they do not pay much attention to the topic of information security. For example, one of the popular Russian services for sending reports to government agencies via the Internet (I will not specifically mention his name). The entire section about the security of this service revolves around the use of certified cryptographic information protection tools. The section on information security of another domestic cloud service for electronic document management is not an example anymore. It talks about public key certificates, certified cryptography, elimination of web vulnerabilities, protection against DDoS attacks, the use of ITU, backups, and even regular information security audits. But not a word about monitoring, as well as about the possibility of gaining access to information security events that may be of interest to customers of this service provider.

In general, by the way a cloud provider describes information security issues on its website and in its documentation, you can understand how seriously it generally takes this issue. For example, if you read the manuals for the My Office products, then there is not a word about security at all, and the documentation for the separate product My Office. KS3, designed to protect against unauthorized access, there is the usual enumeration of the points of the 17th order of the FSTEC, which performs My Office.KS3, but it is not described how it performs and, most importantly, how to integrate these mechanisms with corporate information security. Perhaps there is such documentation, but I did not find it in the public domain, on the My Office website. Although maybe I just do not have access to this secret information? ..

For the same Bitrix, the situation is much better. The documentation describes the formats of the event logs and, interestingly, the intrusion log, which contains events related to potential threats to the cloud platform. From there you can pull IP, user or guest name, event source, time, User Agent, event type, etc. True, you can work with these events either from the control panel of the cloud itself, or upload data in MS Excel format. It is difficult to automate the work with Bitrix logs now and you will have to do some of the work manually (uploading the report and uploading it to your SIEM). But if we remember that until relatively recently there was no such possibility, then this is a great progress. At the same time, I want to note that many foreign cloud providers offer similar functionality “for beginners” - either see the logs with your eyes through the control panel, or upload data to yourself (although most upload data in .csv format, not Excel).

If you do not consider the option of no logs, then cloud providers usually offer you three options for monitoring security events - dashboards, uploading data, and accessing them via API. The first seems to solve many problems for you, but this is not entirely true - if you have several magazines, you have to switch between screens that display them, losing the big picture. In addition, a cloud provider is unlikely to provide you with the ability to correlate security events and generally analyze them from a security point of view (usually you are dealing with raw data that you have to understand yourself). There are exceptions and we will talk about them further. Finally, it is worth asking what events are recorded by your cloud provider, in what format, and how do they correspond to your information security monitoring process? For example, identification and authentication of users and guests. The same Bitrix allows you to fix the date and time of this event, the name of the user or guest (if the “Web Analytics” module is available), the object accessed and other elements typical of the website based on these events. But corporate information security services may need information about whether a user entered the cloud from a trusted device (for example, Cisco ISE implements this task in a corporate network). And such a simple task as the geo-IP function, which will help determine if a cloud service user account has been stolen? And even if the cloud provider provides it to you, then this is not enough. The same Cisco CloudLock does not just analyze geolocation, but uses machine learning for this and analyzes historical data for each user and tracks various anomalies in identification and authentication attempts. Only MS Azure has similar functionality (if you have the appropriate subscription).

There is another difficulty - since for many cloud providers information security monitoring is a new topic that they are just starting to deal with, they are constantly changing something in their solutions. Today they have one version of the API, tomorrow another, the day after tomorrow the third. You also need to be prepared for this. The same is true with functionality that can change, which must be taken into account in your information security monitoring system. For example, Amazon initially had separate event monitoring services in the cloud, AWS CloudTrail and AWS CloudWatch. Then a separate event monitoring service appeared specifically for information security - AWS GuardDuty. Some time later, Amazon launched a new Amazon Security Hub management system, which includes analysis of data received from GuardDuty, Amazon Inspector, Amazon Macie and several others. Another example is the tool for integrating Azure logs with SIEM - AzLog. It was actively used by many SIEM vendors, until in 2018 Microsoft announced the termination of its development and support, which put many customers who used this tool in front of a problem (we will talk about how it was resolved later).

Therefore, carefully monitor all the monitoring functions that your cloud provider offers you. Or trust external solution providers to act as intermediaries between your SOC and the cloud you want to monitor. Yes, it will be more expensive (although not always), but then you will shift all the responsibility onto other people's shoulders. Or not all?.. Let's remember the concept of shared security and understand that we can't shift anything - we'll have to figure out how different cloud providers monitor the information security of your data, applications, virtual machines and other resources hosted in the cloud. And we'll start with what Amazon offers in this part.

Example: Monitoring information security in IaaS based on AWS

Yes, yes, I understand that Amazon is not the best example due to the fact that this is an American service and it can be blocked as part of the fight against extremism and the spread of information prohibited in Russia. But in this publication, I would just like to show how different cloud platforms differ in terms of information security monitoring capabilities and what you should pay attention to when transferring your key processes to the clouds in terms of security. Well, if some of the Russian developers of cloud solutions pick up something useful for themselves, then this will generally be excellent.

First, I must say that Amazon is not an impenetrable fortress. Various incidents regularly happen to his clients. For example, the names, addresses, dates of birth, phone numbers of 198 million voters were stolen from Deep Root Analytics. Israeli company Nice Systems was robbed of 14 million Verizon subscriber records. However, built-in AWS capabilities allow you to detect a wide range of incidents. For example:

• infrastructure impact (DDoS)
• host compromise (command injection)
• account compromise and unauthorized access
• misconfiguration and vulnerabilities
• insecure interfaces and APIs.

This discrepancy is due to the fact that, as we found out above, the customer is responsible for the security of customer data. And if he did not worry about the inclusion of protective mechanisms and did not include monitoring tools, then he will learn about the incident only from the media or from his clients.

A wide range of different monitoring services developed by Amazon can be used to identify incidents (although these are often supplemented by external tools such as osquery). For example, AWS tracks all user actions, whether through the management console, command line, SDK, or other AWS services. All activity records for each AWS account (including username, activity, service, activity parameters, and activity result) and API usage are available through the AWS CloudTrail service. You can view these events (such as logging in to the AWS IAM console) from the CloudTrail console, analyze them with Amazon Athena, or “give” them to external solutions like Splunk, AlienVault, and so on. The AWS CloudTrail logs themselves are placed in your AWS S3 bucket.

The other two AWS services provide a number of other important monitoring capabilities. First, Amazon CloudWatch is an AWS resource and application monitoring service that, among other things, allows you to identify various anomalies in your cloud. All AWS built-in services such as Amazon Elastic Compute Cloud (servers), Amazon Relational Database Service (databases), Amazon Elastic MapReduce (data analysis) and 30 other Amazon services use Amazon CloudWatch to store their logs. Developers can use Amazon CloudWatch's open API to add log monitoring functionality to custom applications and services, which allows them to expand the range of events analyzed in the context of information security.

Secondly, the VPC Flow Logs service allows you to analyze the network traffic sent or received by your AWS servers (from outside or inside), as well as between microservices. When any of your AWS VPC resources interact with the network, the VPC Flow Logs service records information about the network traffic, including the source and destination network interface, as well as the IP addresses, ports, protocol, bytes, and packets you have seen. Those who have experience with local network security will recognize this as analogous to threads. NetFlow, which can be created by switches, routers, and enterprise firewalls. These logs are important for information security monitoring purposes because, unlike user and application activity events, they also allow you to not miss network interactions in the AWS Virtual Private Cloud.

In summary, these three AWS services - AWS CloudTrail, Amazon CloudWatch, and VPC Flow Logs - together provide a fairly effective view of your account usage, user behavior, infrastructure management, application and service activity, and network activity. For example, they can be used to detect the following anomalies:

• Attempts to scan the site, search for backdoors, search for vulnerabilities through bursts of “404 errors”.
• Injection attacks (for example, SQL injection) through bursts of “500 errors”.
• Known attack tools sqlmap, nikto, w3af, nmap, etc. through the analysis of the User Agent field.

Amazon Web Services has also developed other services for cybersecurity purposes that allow you to solve many other problems. For example, AWS has a built-in service for auditing policies and configurations - AWS Config. This service provides a continuous audit of your AWS resources and their configurations. Let's take a simple example: Let's say you want to make sure that user passwords are disabled on all your servers and access is only possible based on certificates. AWS Config makes it easy to test this for all your servers. There are other policies that can be applied to your cloud servers: "No server can use port 22", "Only administrators can change firewall rules", or "Only user Ivashko can create new user accounts, and he can do It's only on Tuesdays. In the summer of 2016, AWS Config was extended to automate the detection of policy violations. AWS Config Rules are essentially continuous configuration requests for the Amazon services you use that fire events when the relevant policies are violated. For example, instead of periodically running AWS Config queries to verify that all drives in a virtual server are encrypted, you can use AWS Config Rules to continually check server drives for this condition. And, most importantly, in the context of this publication, any violations generate events that can be analyzed by your information security service.

AWS also has its equivalents to traditional corporate information security solutions, which also generate security events that you can and should analyze:

• intrusion detection - AWS GuardDuty
• Information Leak Control - AWS Macie
• EDR (although it talks a little weird about endpoints in the cloud) - AWS Cloudwatch + open source osquery or GRR solutions
• Netflow analysis - AWS Cloudwatch + AWS VPC Flow
• DNS Analysis - AWS Cloudwatch + AWS Route53
• AD - AWS Directory Service
• Account Management - AWS IAM
• SSO - AWS SSO
• security analysis - AWS Inspector
• configuration management - AWS Config
• WAF - AWS WAF.

I will not describe in detail all the Amazon services that can be useful in the context of information security. The main thing to understand is that all of them can generate events that we can and should analyze in the context of information security, using both the built-in capabilities of Amazon itself and external solutions, such as SIEM, that can collect security events to your monitoring center. and analyze them there along with events from other cloud services or from internal infrastructure, perimeter or mobile devices.

In any case, it all starts with data sources that provide you with information security events. These sources include, among others:

• CloudTrail - API Usage and User Actions
• Trusted Advisor - Checking security for best practices
• Config - inventory and configuration of accounts and service settings
• VPC Flow Logs - Virtual Interface Connections
• IAM - Identification and Authentication Service
• ELB Access Logs - load balancer
• Inspector - Application Vulnerabilities
• S3 - file storage
• CloudWatch - Application Activity
• SNS is a notification service.

Amazon, offering such a range of event sources and tools for generating them, is very limited in its ability to analyze the collected data in the context of information security. You will have to independently study the available logs, looking for the appropriate indicators of compromise in them. AWS Security Hub, recently launched by Amazon, aims to solve this problem by becoming a kind of cloud SIEM for AWS. But for now, it is only at the beginning of its journey and is limited both by the number of sources it works with and other limitations set by the architecture and subscriptions of Amazon itself.

Example: Monitoring information security in IaaS based on Azure

I don’t want to enter into a long debate about which of the three cloud providers (Amazon, Microsoft or Google) is better (especially since each of them still has its own specifics and is suitable for solving its problems); Let's focus on the information security monitoring capabilities that these players provide. It must be admitted that Amazon AWS was one of the first in this segment and therefore advanced farthest in terms of its information security functions (although many admit that they are difficult to use). But this does not mean that we will ignore the opportunities provided by Microsoft and Google.

Microsoft products have always been distinguished by their “openness” and in Azure the situation is similar. For example, if AWS and GCP always come from the concept of “everything that is not allowed is prohibited”, then Azure has the exact opposite approach. For example, when creating a virtual network in the cloud and a virtual machine in it, all ports and protocols are open and allowed by default. Therefore, you will have to spend a little more effort on the initial setup of the Microsoft cloud access control system. And this also imposes more stringent requirements on you in terms of monitoring activity in the Azure cloud.

AWS has a feature related to the fact that when you monitor your virtual resources, then if they are in different regions, then you have difficulties in combining all events and their unified analysis, to eliminate which you need to resort to various tricks, such as create your own code for AWS Lambda that will transfer events between regions. Azure does not have this problem - its Activity Log mechanism tracks all activity within the entire organization without restrictions. The same applies to the AWS Security Hub, which was recently developed by Amazon to consolidate many security functions within a single security center, but only within its region, which, however, is irrelevant for Russia. Azure has its own Security Center, which is not bound by regional restrictions, providing access to all the security features of the cloud platform. Moreover, for various local commands, it can provide its own set of security features, including the security events they manage. AWS Security Hub is still striving to become like the Azure Security Center. But it’s worth adding a fly in the ointment - you can squeeze a lot of what was described earlier in AWS out of Azure, but this is most conveniently done only for Azure AD, Azure Monitor and Azure Security Center. All other protection mechanisms of Azure, including the analysis of security events, are not yet managed in the most convenient way. Part of the problem is solved by the API that permeates all Microsoft Azure services, but this will require additional efforts from you to integrate your cloud with your SOC and the availability of qualified specialists (in fact, as with any other SIEM that works with cloud APIs). Some SIEMs, which will be discussed later, already support Azure and can automate the task of monitoring it, but it also has its own difficulties - not all of them can take all the logs that Azure has.

Event collection and monitoring in Azure is provided using the Azure Monitor service, which is the main tool for collecting, storing and analyzing data in the Microsoft cloud and its resources - Git repositories, containers, virtual machines, applications, etc. All data collected by Azure Monitor is divided into two categories - metrics collected in real time and describing key performance indicators of the Azure cloud, and logs containing data organized into records that characterize certain aspects of the activity of Azure resources and services. In addition, using the Data Collector API, Azure Monitor can collect data from any REST source to build custom monitoring scenarios.

Here are a few sources of security events that Azure offers you that you can access through the Azure Portal, CLI, PowerShell, or REST API (and some only through the Azure Monitor / Insight API):

• Activity Logs - this log answers the classic "who", "what" and "when" questions regarding any write operation (PUT, POST, DELETE) on cloud resources. Events related to read access (GET) are not included in this log, as well as a number of others.
• Diagnostic Logs - contains data on operations with a particular resource included in your subscription.
• Azure AD reporting - contains both user activity and system activity related to managing groups and users.
• Windows Event Log and Linux Syslog - contains events from virtual machines hosted in the cloud.
• Metrics - contains telemetry about the performance and health status of your cloud services and resources. Measured every minute and stored. within 30 days.
• Network Security Group Flow Logs - contains data on network security events collected using the Network Watcher service and resource monitoring at the network level.
• Storage Logs - contains events related to storage access.

For monitoring, you can use external SIEMs or the built-in Azure Monitor and its extensions. We'll talk more about information security event management systems, but for now let's see what Azure itself offers us for data analysis in the context of security. The main screen for everything security-related in Azure Monitor is the Log Analytics Security and Audit Dashboard (the free version supports limited event storage for just one week). This panel is divided into 5 main areas that visualize summary statistics on what is happening in your cloud environment:

• Security Domains - key quantitative indicators related to information security - the number of incidents, the number of compromised nodes, unpatched nodes, network security events, etc.
• Notable Issues - displays the number and severity of active information security issues
• Detections - displays patterns of attacks used against you
• Threat Intelligence - displays geographic information on external hosts that attack you
• Common security queries are typical queries that will help you better monitor your information security.

Azure Monitor extensions include Azure Key Vault (protection of cryptographic keys in the cloud), Malware Assessment (analysis of protection against malicious code on virtual machines), Azure Application Gateway Analytics (analysis, among other things, of cloud firewall logs), etc. . These tools, enriched with certain rules for processing events, allow you to visualize various aspects of the activity of cloud services, including security, and identify certain deviations from work. But, as is often the case, any additional functionality requires a corresponding paid subscription, which will require you to appropriate financial injections, which you need to plan in advance.

Azure has a number of built-in threat monitoring capabilities that are integrated into Azure AD, Azure Monitor, and Azure Security Center. Among them, for example, detection of the interaction of virtual machines with known malicious IPs (due to integration with Threat Intelligence services from Microsoft), detection of malware in the cloud infrastructure by receiving alarms from virtual machines hosted in the cloud, password guessing attacks ” on virtual machines, vulnerabilities in the configuration of the user identification system, logging in from anonymizers or infected hosts, leaking accounts, logging in from unusual locations, etc. Azure is one of the few cloud providers today that offers you built-in Threat Intelligence capabilities to enrich collected intelligence events.

As mentioned above, the protective functionality and, as a result, the security events generated by it, are not available to all users equally, but require a certain subscription that includes the functionality you need, which generates the appropriate events for monitoring information security. For example, some of the functions for monitoring anomalies in accounts described in the previous paragraph are available only in a P2 premium license for the Azure AD service. Without it, just like with AWS, you would have to parse collected security events manually. And, also, depending on the type of Azure AD license, not all events will be available for analysis.

On the Azure portal, you can manage both search queries to the logs you are interested in, and set up dashboards to visualize key information security indicators. In addition, there you can select Azure Monitor extensions, which allow you to extend the functionality of Azure Monitor logs and get a deeper analysis of events from a security point of view.

If you need not only the ability to work with logs, but a comprehensive security center for your Azure cloud platform, including information security policy management, then we can talk about the need to work with the Azure Security Center, most of whose useful features are available for a fee, for example, threat detection, monitoring outside of Azure, compliance assessment, etc. (in the free version, you only have access to a security assessment and recommendations for fixing identified problems). It consolidates all security issues in one place. In fact, we can talk about a higher level of information security than Azure Monitor provides you, since in this case the data collected throughout your cloud factory is enriched using many sources, such as Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) and Microsoft Security Response Center (MSRC), which are overlaid with various sophisticated machine learning and behavioral analytics algorithms, which should ultimately increase the effectiveness of threat detection and response.

Azure also has its own SIEM - it appeared at the beginning of 2019. This is Azure Sentinel, which relies on data from Azure Monitor and can also integrate with. external security solutions (for example, NGFW or WAF), the list of which is constantly updated. In addition, by integrating the Microsoft Graph Security API, you have the ability to connect your own Threat Intelligence feeds to Sentinel, which enriches the ability to analyze incidents in your Azure cloud. It can be argued that Azure Sentinel is the first "native" SIEM that appeared with cloud providers (the same Splunk or ELK that can be placed in the cloud, for example, AWS, is still not developed by traditional cloud service providers). Azure Sentinel and Security Center could be called the SOC for the Azure cloud and they could be limited (with certain reservations) if you no longer had any infrastructure and you transferred all your computing resources to the cloud and it would be the Microsoft cloud Azure.

But since the built-in capabilities of Azure (even with a subscription to Sentinel) are often not enough for the purposes of monitoring information security and integrating this process with other sources of security events (both cloud and internal), it becomes necessary to export the collected data to external systems, to which may include SIEM. This is done both using the API and using special extensions that are currently only officially available for the following SIEMs - Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight and ELK. Until recently, there were more such SIEMs, but on June 1, 2019, Microsoft stopped supporting the Azure Log Integration Tool (AzLog), which at the dawn of Azure and in the absence of normal standardization of working with logs (Azure Monitor did not even exist yet) made it easy to integrate external SIEMs with the Microsoft cloud. Now the situation has changed and Microsoft recommends the Azure Event Hub platform as the main integration tool for other SIEMs. Many have already implemented such integration, but be careful - they may not capture all Azure logs, but only some (see the documentation for your SIEM).

Concluding a brief excursion into Azure, I want to give a general recommendation for this cloud service - before you make any statements regarding the information security monitoring functions in Azure, you should configure them very carefully and test that they work as written in the documentation and as consultants told you Microsoft (and they may have different views on the health of Azure Functions). If you have financial opportunities, you can squeeze out a lot of useful things from Azure in terms of information security monitoring. If your resources are limited, then, as in the case of AWS, you will have to rely only on your own strength and the raw data that Azure Monitor provides you. And remember that many monitoring features cost money and it is better to familiarize yourself with the pricing policy in advance. For example, you can store up to 31 GB of data for free for 5 days per customer - exceeding these values ​​will require you to fork out additionally (approximately $ 2+ for storage for each additional GB from the customer and $ 0,1 for storage of 1 GB each additional month ). Working with application telemetry and metrics may also require additional financial resources, as well as working with alerts and notifications (a certain limit is available for free, which may not be enough for your needs).

Example: Information security monitoring in IaaS based on Google Cloud Platform

Google Cloud Platform looks very young compared to AWS and Azure, but this is partly good. Unlike AWS, which increased its capabilities, including protective ones, gradually, having problems with centralization; GCP, like Azure, is much better managed centrally, which reduces errors and implementation times across the enterprise. In terms of security, GCP sits, oddly enough, between AWS and Azure. It also has an organization-wide event logging, but it is incomplete. Some features are still in beta mode, but gradually this shortcoming should be eliminated and GCP will become a more mature platform in terms of information security monitoring.

The main tool for logging events in GCP is Stackdriver Logging (similar to Azure Monitor), which allows you to collect events across your entire cloud infrastructure (as well as from AWS). From a security standpoint in GCP, each organization, project, or folder has four logs:

• Admin Activity - contains all events related to administrative access, for example, creating a virtual machine, changing access rights, etc. This log is always written, regardless of your desire, and keeps its data for 400 days.
• Data Access - contains all events related to working with data cloud users (creation, modification, reading, etc.). By default, this log is not written, as its volume swells very quickly. For this reason, its shelf life is only 30 days. In addition, not everything is written in this journal. For example, events related to resources that are publicly available to all users or that are available without logging into the GCP are not written to it.
• System Event - contains system events that are not related to users, or the actions of an administrator who changes the configuration of cloud resources. It is always written and kept for 400 days.
• Access Transparency is a unique example of a log that captures all the activities of Google employees (but not yet all GCP services) who access your infrastructure as part of their job duties. This log is stored for 400 days and is not available to every GCP client, but only if a number of conditions are met (either Gold or Platinum support, or the presence of 4 roles of a certain type within corporate support). There is also a similar function, for example, in Office 365 - Lockbox.

Log example: Access Transparency

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

Access to these logs is possible in several ways (much like the previously discussed Azure and AWS) - through the Log Viewer interface, through the API, through the Google Cloud SDK, or through the Activity page of your project for which you are interested in events. In the same way, they can also be exported to external solutions for additional analysis. The latter is done by exporting logs to the BigQuery or Cloud Pub/Sub storage.

In addition to Stackdriver Logging, the GCP platform also offers the Stackdriver Monitoring functionality, which allows you to monitor key metrics (performance, MTBF, overall health, etc.) of cloud services and applications. Specially processed and visualized data can make it easier to find problems in your cloud infrastructure, including in the context of security. But it should be noted that this functionality will not be very rich precisely in the context of information security, since today GCP does not have an analogue of the same AWS GuardDuty and cannot single out bad events among all registered events (Google developed Event Threat Detection, but so far it is in beta and it's too early to talk about its usefulness). Stackdriver Monitoring could be used as an anomaly detection system, which would then be investigated to find the reasons for their occurrence. But in the context of a shortage of personnel qualified in the field of information security GCP in the market, this task at the moment looks like a difficult one.

It is also worth listing some information security modules that can be applied within your GCP cloud, and which are similar to what AWS offers:

• Cloud Security Command Center is similar to AWS Security Hub and Azure Security Center.
• Cloud DLP - Automated discovery and editing (such as masking) of data hosted in the cloud against over 90 predefined classification policies.
• Cloud Scanner is a scanner for known vulnerabilities (XSS, Flash Injection, unpatched libraries, etc.) in App Engine, Compute Engine and Google Kubernetes.
• Cloud IAM - Manage access to all GCP resources.
• Cloud Identity - Manage user, device, and GCP application identities from a single console.
• Cloud HSM - protection of cryptographic keys.
• Cloud Key Management Service - cryptographic key management in GCP.
• VPC Service Control - Create a secure perimeter around your GCP resources to protect them from leaks.
• Titan Security Key - protection against phishing.

Many of these modules generate security events that can be sent to BigQuery storage for analysis or export to other systems, including SIEM. As mentioned above, GCP is an actively developed platform, and now Google is developing a number of new information security modules for its platform. Among them are Event Threat Detection (now available in beta), which scans Stackdriver logs for traces of unauthorized activity (similar to GuardDuty in AWS), or Policy Intelligence (available in alpha), which will allow you to develop intelligent access policies to GCP resources.

I made a small overview of the built-in monitoring capabilities in popular cloud platforms. But do you have specialists who are able to work with the “raw” logs of an IaaS provider (not everyone is ready to buy advanced features from AWS or Azure or Google)? In addition, many people know the proverb “trust, but verify”, which is truer than ever in the field of security. How much do you trust the built-in capabilities of the cloud provider that give you information security events? To what extent do they generally focus on information security?

Sometimes it's worth looking at overlay cloud infrastructure monitoring solutions that can complement the cloud's built-in security, and sometimes these solutions are the only way to get insight into the security of your data and applications hosted in the cloud. In addition, they are simply more convenient, as they take on all the tasks of analyzing the necessary logs generated by different cloud services of different cloud providers. An example of such an overlay solution is Cisco Stealthwatch Cloud, which is focused on a single task - monitoring information security anomalies in cloud environments, including not only Amazon AWS, Microsoft Azure and Google Cloud Platform, but also private clouds.

Case Study: Monitoring Information Security with Stealthwatch Cloud

AWS provides a flexible computing platform, but this flexibility makes it easier for companies to make mistakes that lead to security issues. And the shared information security model only contributes to this. Running software with unknown vulnerabilities in the cloud (for example, AWS Inspector or GCP Cloud Scanner can fight known vulnerabilities), weak passwords, incorrect configurations, insiders, etc. And all this is reflected in the behavior of cloud resources, which can be monitored by Cisco Stealthwatch Cloud, which is an information security monitoring and attack detection system. public and private clouds.

One of the key features of the Cisco Stealthwatch Cloud is the ability to model entities. With it, you can create a programming model (that is, a near-real-time simulation) of each of your cloud resources (whether it be AWS, Azure, GCP, or something else). These can include servers and users, as well as resource types specific to your cloud environment, such as security groups and auto-scale service groups (auto-scale). These models use structured data streams provided by cloud services as input. For example, for AWS, these will be VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda, and AWS IAM. Entity modeling automatically discovers the role and behavior of any of your resources (we can talk about profiling all cloud activity). These roles include an Android or Apple mobile device, a Citrix PVS server, an RDP server, a mail gateway, a VoIP client, a terminal server, a domain controller, and so on. It then continuously monitors their behavior to determine when risky or safety-threatening behavior occurs. You can identify password guessing, DDoS attacks, data leaks, illegal remote access, malicious code, vulnerability scanning and other threats. For example, this is how it looks like detecting a remote access attempt from a country atypical for your organization (South Korea) to a Kubernetes cluster via SSH:

And this is how the alleged information leak from the Postgress database to a country with which interaction has not previously been encountered looks like:

Finally, this is how too many failed SSH access attempts from China and Indonesia look like from an external remote device:

Or, suppose that the server instance in the VPC, according to policy, should never be the destination for remote login. Let's further assume that this computer experienced a remote logon due to an erroneous change in the firewall rules policy. Entity Modeling will detect and report this activity ("Unusual Remote Access") in near real time and point to a specific AWS CloudTrail, Azure Monitor, or GCP Stackdriver Logging API call (including username, date and time, among other details), which prompted a change in the ITU rule. And then this information can be given to SIEM for analysis.

Similar capabilities are implemented for any cloud environment supported by Cisco Stealthwatch Cloud:

Entity modeling is a unique form of security automation that can discover a previously unknown problem with your people, processes or technology. For example, it allows you to detect, among other things, security issues such as:

• Has anyone discovered a backdoor in the software we use?
• Is there any third party software or device in our cloud?
• Is an authorized user abusing privileges?
• Has a configuration error been made that allows remote access or other unintended use of resources?
• Is there data leakage from our servers?
• Did someone try to connect to us from an atypical geographic location?
• Is our cloud infected with malicious code?

A detected information security event can be transferred as a corresponding ticket to Slack, Cisco Spark, PagerDuty incident management system, and also sent to various SIEMs, including Splunk or ELK. Summarizing, we can say that if your company uses a multi-cloud strategy and is not limited to any one cloud provider, the information security monitoring capabilities described above, then using Cisco Stealthwatch Cloud is a good option to get a unified set of monitoring capabilities for leading cloud players - Amazon , Microsoft and Google. The most interesting thing is that if you compare prices for Stealthwatch Cloud with advanced licenses for monitoring information security in AWS, Azure or GCP, then it may turn out that the Cisco solution will be even cheaper than the built-in capabilities of Amazon, Microsoft and Google solutions. Paradoxical, but true. And the more clouds and their capabilities you use, the more obvious the advantage of a consolidated solution will be.

In addition, Stealthwatch Cloud can also monitor private clouds deployed in your organization, for example, based on Kubernetes containers or by monitoring Netflow or network traffic received through mirroring in network equipment (even domestically produced), AD data or DNS servers and so on. All of this data will be enriched with Threat Intelligence collected by Cisco Talos, the world's largest non-governmental threat intelligence group.

This allows you to implement a single monitoring system for both public and hybrid clouds that your company may use. The collected information can then be analyzed using the built-in Stealthwatch Cloud capabilities or sent to your SIEM (Splunk, ELK, SumoLogic and a number of others are supported by default).

This concludes the first part of the article, in which I reviewed the built-in and external tools for monitoring the information security of IaaS / PaaS platforms, which allow us to quickly detect and respond to incidents occurring in the cloud environments that our enterprise has chosen. In the second part, we will continue the topic and consider options for monitoring SaaS platforms using the example of Salesforce and Dropbox, and we will also try to summarize and put everything together by creating a unified information security monitoring system for different cloud providers.

Source: habr.com