Cloud Security Monitoring. Part 2
So, I will continue the article on monitoring the security of cloud providers. In the first part, I talked about the experience of Cisco in working with external cloud services, as well as the Cisco observations that we encountered when building or auditing SOCs of our customers. Taking in the first part, as an example, the three most popular solutions from Amazon, Microsoft and Google, which are IaaS / PaaS platforms, today it's time to talk about monitoring SaaS platforms - Dropbox, Salesforce.com, Slack and Apple Business Manager, and also about which SIEMs are best suited for monitoring cloud platforms today.
If on the basis of AWS, Azure or GCP you can create an almost complete analog of your corporate infrastructure, only in the cloud, that is, cloud services that perform one specific task, for example, file storage, as Dropbox does. This service has long gone beyond the usual user storage, providing its corporate users with a whole set of security mechanisms:
Dropbox Business (which is not possible in either the Basic or Pro version) logs record the following types of security events:
You can analyze security events in Dropbox either through the Dropbox Business administrative console (but do not expect big revelations in it), or using the external monitoring solution that operates with the Dropbox Business API. Access to logs is not available in any Dropbox Business tariff, but only starting with an Advanced license (remember Office365, which also starts access to logs not with a basic business license). As with AWS, it’s worth asking if your SIEM supports Dropbox? For example, Splunk has a separate module for working with Dropbox, which, thanks to the REST API, allows you to monitor the following security events:
Other SIEMs do not have Dropbox built-in support - you will have to write your own connector.
We understand that today there is a huge number of cloud platforms that can be used by businesses to solve their problems and which we would like to monitor from the point of view of their security. We won’t dive into each of these platforms (and I didn’t set such a task, just wanting to pay attention to the specifics of the monitoring tasks of cloud platform information security), but we’ll try to complete the consideration of specific platforms with two more common business solutions - Slack and Salesforce.com .
Slack integrates with 50+ security tools (from content protection and privacy to certificate monitoring and access control), but from the point of view of monitoring a wide range of security events, Slack has few ready-made integrations - on the site this list is limited to the little-known Symantec CloudSOC, Cisco CloudLock (more on that below) and Chronicle. That’s probably all. But having certification of ISO 27001, SOC2 / 3, Fed-RAMP and a number of others, Slack could not help but implement the advanced functionality for monitoring its infrastructure, some of which is available to customers. In particular, using the Audit Logs API (available only to Slack Enterprise Grid users and not available in Free, Standard, Plus plans), you can “pull” a wide range of data from your Slack infrastructure and load it into your SIEM related to user activity, but not with content monitoring (for these tasks it is necessary to use specialized DLP or eDiscovery solutions). At the same time, Slack does not have a mechanism similar to AWS GuardDuty - it sends events “as is” and does not tell you whether they are good or bad, you can only determine it yourself by writing your own correlation rules in your SIEM or using external solutions that have a set of predefined patterns of unauthorized activity in Slack (as, for example, in Cisco CloudLock).
Each event in the Slack logbook has 4 key elements - an action, the user who generated it (actor), the entity associated with the event (workspace, application, user, channel, file), and location (context) within which this action occurred (a separate workspace or the entire organization). In total, Slack captures about 70 different actions. For example, this is how the user registration event in Slack looks like:
With Salesforce, the situation is similar - using the API, you can access all user activity in this cloud-based CRM, and in particular the following events:
In addition, you can monitor the security of your Salesforce instance and work with event logs in the Salesforce admin console. You have 4 options:
Recently, Salesforce has developed a specialized security monitoring solution for its platform - Salesforce Shield. It includes three components - managing the encryption of all stored information, monitoring security and data usage, and managing security policies. In the case of information security monitoring, this feature in Salesforce Shield is akin to the Azure Monitor extensions, which not only show you events, but also due to their processing and visualization tell you what to look for. For example, can you find out from which devices and platforms users most often access SFDC? Or when, most often, and from where do users enter their copy of Salesforce (can this help identify atypical entry points)? Who views confidential information? Who most often downloads reports to his computer? Answers to these questions can be obtained using 16 pre-installed panels, the input of which is analyzed by the separately licensed Einstein Event Monitoring Analytics subsystem (nice name, isn't it). With it, you can also simulate your dashboards, upload data to external BI systems, etc.
Oops ... And where does the iPhone and cloud monitoring, you ask. Everything is simple here. For example, none of the SIEMs at the time of writing this article had a connector to the Apple Business Manager platform (or the Apple School Manager, which is better known in US universities), which allows you to manage Apple corporate devices - iPhone, iPad, Mac. For this task, you can use any of the MDM solutions, or you can use the Apple Business Manager (if you participate in the Apple Device Enrolment Program or Volume Purchase Program, which are not valid in Russia). MDM solutions can be installed locally and integrating them with your SIEM is not difficult in principle, just like cloud MDMs (for example, Cisco Meraki), but the story with Apple Business Manager has a pronounced cloud color and it’s interesting in the context of this article see how one of the largest IT manufacturers solves the problem of providing the ability to monitor the security of their solutions.
In general, it is from this point of view that Apple’s solutions are not very well known in Russia (although in the West we encounter them in SOC projects). Hence the prevailing opinion that Apple is a purely consumer company that has not turned to corporate customers in terms of integration into their SOCs. This is not so at the same time. The fact is that having a fairly powerful system of protection for iOS and MacOS, Apple continues to be a closed co-company and does not very actively allow outside parties to information about the safety of its products. Although the picture is gradually changing. For example, Apple Business Manager allows you to see information about activity on corporate Apple devices, which is combined into three blocks of information - the event, status and start date of the event (with the end date, alas, problems). Controlled events (Apple School Manager has a little more, but they are related to the classes of students / pupils) include:
To be honest, there is not much information. You can work with it either in the Apple Business Manager control panel or by uploading it as a .csv file to your computer for further analysis. I must admit that the main orientation of this feature in Apple is still focused on finding problems in the IT plane, rather than addressing security issues - Apple does not have any log collection or analysis. You can get much more information if you integrate Apple Business Manager with any MDM solution - then you can get information about active users, user IDs and devices, including the Wi-Fi address, data on installed applications and their versions, presence of uninstalled updates, telecom operator, personal access point, enabled “Find iPhone” function, data encryption, jailbreak, installed certificates, personal ITU settings and settings, PIN-when settings, remote control phenomena, etc. This is enough for IS monitoring tasks, but it will require certain gestures to integrate your corporate Apple devices into your SOC.
It should be noted that Amazon, like many other public clouds, paying very much attention to its security, nevertheless focuses mainly on mechanisms for detecting and preventing quite simple threats in its infrastructure, as well as providing access to events that can be analyzed using external decisions. Microsoft came closest to creating a system for monitoring and analyzing security events in the cloud, but using its solution will require additional financial investments. If you use only the clouds of this company, then perhaps you can limit yourself to Azure Security Center with extensions. But if you have a multi-cloud environment, then it is worth considering the use of independent solutions - SIEM, which, perhaps, you are already using to monitor the information security of your internal infrastructure. And here you need to understand how selected or chosen by you SIEM supports the cloud you use (and its various services) as a data source. For example, Splunk, QRadar, ArcSight, ELK support AWS and this is directly stated in the documentation for these monitoring systems, but the same RuSIEM or PT SIEM does not support.
It should be borne in mind that different SIEMs can take data from different cloud services in different ways. Take for example ELK and Amazon. Many cloud services and applications can forward their events to the S3 bucket, and Logstash can then pick them up on request. The AWS CloudWatch previously mentioned can also send data to S3, and can stream it to AWS Lambda (and Logstash takes them for analysis) or hosted in the ElasticSearch cloud. Well, of course, there are applications that can directly send data to ELK, bypassing S3, Lambda or CloudWatch. IBM QRadar collects the data of the same AWS GuardDuty through AWS CloudWatch, the Amazon VPC Flow Logs logs by publishing them in the S3 basket followed by captures in QRadar, and data from AWS CloudTrail either through the S3 basket or through AWS CloudWatch. Depending on what data you need for monitoring, this knowledge may help you not to make a fatal mistake by choosing SIEM, which after implementation will not be able to work with the cloud applications and services you need.
Despite the popularity of AWS or Azure, a number of SIEMs do not have built-in connectors for working with Amazon and Microsoft clouds, but it is possible to create your own - either independently or with the help of a manufacturer, as, for example, in the case of PT SIEM with Custom Connector. It is worth noting that AWS is not the right example to get an idea of how SIEM works with the clouds. AWS is the most popular cloud business platform in the world and therefore many manufacturers try to integrate their products with it, including in the field of information security. But even in this case, we must nevertheless admit that in general, SIEM today does not so often allow you to monitor cloud platforms. For example, IBM QRadar works only with the following cloud services (not including cloud information security services such as Cisco Umbrella, Cisco Meraki, Cisco Threat Grid, etc.):
The list is not very long. The same Splunk base of modules for working with clouds is much wider. In addition to the aforementioned for IBM Qradar, Splunk's solution also supports:
Please note that no one supports GCP yet.
Using the Splunk App for AWS extension (the idea will be similar for ArcSight or QRadar), you can implement, for example, the following use case monitoring scenarios that will allow you to answer questions important from the point of view of information security:
Some SIEMs specifically designed for the corporate network may have architectural problems with the clouds. At a minimum, you will need to open a series of rules for all your cloud systems that send logs to your SIEM on the perimeter ITU. Another problem, and more serious, is the fact that having connectors for working with the clouds does not mean that SIEM is ready for use in this role. If we pay attention to the components of the monitoring system mentioned at the beginning of 6, it turns out that the connector to SIEM helps you to solve two necessary, but clearly insufficient tasks - collecting and processing information security events. Storage is provided by SIEM itself, but with the analysis we still have a big question. If a typical corporate SIEM has a ratio of really useful and working “out of the box” correlation rules to their total number, it is 20 to 80, while for monitoring cloud information security this ratio will be somewhere around 5 to 95, or even less. Therefore, do not forget that having SIEM working with clouds is not all that is needed to monitor their real security. You will need much more efforts (not to mention qualified personnel) to write event correlation rules for your cloud, for your clouds, as well as for clouds and the corporate environment (because you will probably want to correlate the location data of the user connected to the cloud platform with corporate security features).
If the situation with IaaS / PaaS monitoring is more or less good - the number of sources, the volume of created logs and event types are sufficient for their analysis, then for many SaaS this still causes difficulties. Therefore, I want to pay attention to the following activities / events that are available for most serious SaaS players and which need to be analyzed in your SIEM when monitoring SaaS:
At a minimum, analysis of these events, which, for example, Salesforce.com, Box or Dropbox will give you, will allow to detect a large number of incidents with your cloud data and users.
How to explain such a gap in the ability to monitor corporate and cloud environments using SIEM? Low cloud prevalence? We understand that this is not so. Rather, the question is the maturity of customers who are already ready for the clouds, but not ready to monitor their security, as I wrote at the very beginning of the article. And without this, the required number of business cases is not recruited and SIEM developers are not in a hurry on their own initiative to implement cloud support in their products; especially in the context of regular changes in the mechanisms of work and the return of security events from cloud providers (remember the AzLog story with Azure).
But what if your cloud provider has logs, but does not have its own tools for analyzing and monitoring them, your SIEM does not support the cloud you have chosen and there is no way to write a connector to it? There is an option that allows you to use specialized intermediaries who, using the existing cloud API (it should be), access your cloud provider and then pull logs from it, apply various analytical tools to them, identifying various incidents and other irregularities, the data of which can then be given to your SIEM.
Examples of such intermediaries are either Cloud Access Security Broker, CASB solutions (for example, Cisco CloudLock), or some Multi-Factor Authentication, MFA solutions with advanced access control capabilities (for example, Cisco Duo). True, CASB or MFA, solving one problem, add another - getting another management console, which must be integrated into your SOC. But solving this problem is usually simpler. SIEM, often without a connection to the cloud, can work with information security tools, including CASB and MFA (after all, this is their main task). In this case, APIs in the CASB and MFA help, which allow you to send collected and analyzed security events to corporate SIEMs and embed them in your SOCs. It turns out a three-tier system in which SIEM, which does not have to integrate directly with the cloud, uses CASB / MFA for this (in the above case with Cisco Stealthwatch Cloud the same story).
True, CASB is not a panacea either. Not all cloud providers have APIs in their platforms that allow data to be sent to corporate SOC and SIEM. Usually it is this attribute that distinguishes corporate decisions. Sometimes even popular cloud solutions do not have such APIs, as you could see at the very beginning, when I mentioned Bitrix, “My Office” or SKB Kontur solutions.
Cisco CloudLock is an API-based solution that integrates with a wide range of existing popular cloud SaaS platforms, such as G Suite, Salesforce, Office 365, Dropbox, Box, ServiceNow, Slack, Okta, etc., as well as IaaS / PaaS -platforms such as Salesforce and AWS. Unlike proxy CASB, the API-based solution allows you to work with data that is already loaded into the cloud, analyze inter-cloud traffic, and control access from mobile and unmanaged corporate and personal devices. At the same time, Cisco CloudLock, which gradually becomes an integral part of Cisco Umbrella , does not interfere with the user’s work and connects to controlled clouds due to the API they have, which allows you to monitor violations such as:
Access to these incidents is possible both from the Cisco CloudLock service itself, and through SIEM, to which CloudLock provides the necessary information through the existing API. Currently, Cisco CloudLock can integrate with Splunk, QRadar, and Arcsight.
So, we got some idea of how information security monitoring works in popular cloud environments in Russia. Now you understand what data and how you can upload to your SIEM. But does this mean that you can talk about a built-in cloud information security monitoring system? Of course not. It’s enough to recall that according to the popular, but not quite right concept, SOC is a combination of people, processes and technologies. We talked above only about technology. The time has come to talk a little about other components.
To begin with, the cloud world today does not have a clear favorite and leader. Companies use different clouds for different tasks. I gave the example of Cisco above, which in its activity uses about 700 cloud providers around the world. And they are all different, with different approaches to ensuring information security and its monitoring.In order to integrate all of them into our IS monitoring center, it is necessary to look beyond the ways of loading data into SIEM and build a full-fledged multi-cloud monitoring strategy, which necessarily includes the following steps:
It should be borne in mind that some of these components will overlap with other monitoring tasks that your organization may face - SLA monitoring, availability monitoring, application performance monitoring, usage monitoring for subsequent billing, etc. Therefore, building a security monitoring system for your cloud, first specify what has already been done and what is planned to be done by your colleagues from other departments - you may be able to use the achievements or tools already made or to share a number of tasks with others.
It seems like I did not write anything special and new. If your SOC is designed correctly from the very beginning, then adding any new controlled entity (whether it be a cloud, ICS or mobile devices) should not lead to a strong alteration of previously developed documents and processes. When we design or audit SOCs, we try to initially take into account all these aspects in our work.
Summing up, it’s worth repeating again that monitoring of information security in cloud environments is a relatively new topic even for the “oldies” of the cloud market. Therefore, changes are constantly taking place in this segment, and something that was not possible until recently appears in the portfolio of the cloud provider. The same applies to the functions for monitoring information security. Regardless of which provider we are talking about, they can provide you with one of several monitoring options:
All of these five options differ in the complexity of working with them, the price and speed of monitoring and response. I can’t say which one to choose, since it very much depends not only on which cloud you are working with, but also what your monitoring strategy is. IB. I can only help with a list of questions to ask yourself and your cloud provider, with whom you decide to “connect your life”:
Here is a short list of questions, the answers to which will allow you to start building the process of monitoring the information security of cloud environments that you or your business decided to use. The sooner you take an interest in answering these questions, the cheaper it will cost you to build a monitoring system and the less incidents will occur with your resources given to external cloud providers. As Cisco’s experience in building or auditing SOCs shows, even the most successful IS monitoring centers that effectively manage incidents within the corporate network do not always advance cloud monitoring capabilities in their architecture, which necessitates its restructuring. I hope the observations and recommendations described in these two parts will help in ensuring cybersecurity.
Example: IS monitoring in Dropbox-based SaaS
If on the basis of AWS, Azure or GCP you can create an almost complete analog of your corporate infrastructure, only in the cloud, that is, cloud services that perform one specific task, for example, file storage, as Dropbox does. This service has long gone beyond the usual user storage, providing its corporate users with a whole set of security mechanisms:
- user identification and authentication
- file access control
- remote data deletion
- trusted device management
- integration with external information security solutions (DLP, SSO, DRM, eDiscovery, SIEM, etc.)
- security event logging.
Dropbox Business (which is not possible in either the Basic or Pro version) logs record the following types of security events:
- password protection settings
- successful and unsuccessful attempts to enter the file storage
- control privileged access and administrator actions
- file actions (add, edit, delete, transfer, load, etc.)
- connection to the file storage of third-party applications
- devices that access Dropbox
- add / remove members to access groups
- creating folders / files accessible externally
You can analyze security events in Dropbox either through the Dropbox Business administrative console (but do not expect big revelations in it), or using the external monitoring solution that operates with the Dropbox Business API. Access to logs is not available in any Dropbox Business tariff, but only starting with an Advanced license (remember Office365, which also starts access to logs not with a basic business license). As with AWS, it’s worth asking if your SIEM supports Dropbox? For example, Splunk has a separate module for working with Dropbox, which, thanks to the REST API, allows you to monitor the following security events:
- logging in
- activity on adding / removing / user requests
- activity of devices connecting to Dropbox
- file sharing activity within the company and beyond
- application activity
- etc.
Other SIEMs do not have Dropbox built-in support - you will have to write your own connector.
Example, IS monitoring in SaaS based on Slack and Salesforce.com
We understand that today there is a huge number of cloud platforms that can be used by businesses to solve their problems and which we would like to monitor from the point of view of their security. We won’t dive into each of these platforms (and I didn’t set such a task, just wanting to pay attention to the specifics of the monitoring tasks of cloud platform information security), but we’ll try to complete the consideration of specific platforms with two more common business solutions - Slack and Salesforce.com .
Slack integrates with 50+ security tools (from content protection and privacy to certificate monitoring and access control), but from the point of view of monitoring a wide range of security events, Slack has few ready-made integrations - on the site this list is limited to the little-known Symantec CloudSOC, Cisco CloudLock (more on that below) and Chronicle. That’s probably all. But having certification of ISO 27001, SOC2 / 3, Fed-RAMP and a number of others, Slack could not help but implement the advanced functionality for monitoring its infrastructure, some of which is available to customers. In particular, using the Audit Logs API (available only to Slack Enterprise Grid users and not available in Free, Standard, Plus plans), you can “pull” a wide range of data from your Slack infrastructure and load it into your SIEM related to user activity, but not with content monitoring (for these tasks it is necessary to use specialized DLP or eDiscovery solutions). At the same time, Slack does not have a mechanism similar to AWS GuardDuty - it sends events “as is” and does not tell you whether they are good or bad, you can only determine it yourself by writing your own correlation rules in your SIEM or using external solutions that have a set of predefined patterns of unauthorized activity in Slack (as, for example, in Cisco CloudLock).
Each event in the Slack logbook has 4 key elements - an action, the user who generated it (actor), the entity associated with the event (workspace, application, user, channel, file), and location (context) within which this action occurred (a separate workspace or the entire organization). In total, Slack captures about 70 different actions. For example, this is how the user registration event in Slack looks like:
{ "entries":[ { "id":"0123a45b-6c7d-8900-e12f-3456789gh0i1", "date_create":1521214343, "action":"user_login", "actor":{ "type":"user", "user":{ "id":"W123AB456", "name":"Charlie Parker", "email":"bird@slack.com" } }, "entity":{ "type":"user", "user":{ "id":"W123AB456", "name":"Charlie Parker", "email":"bird@slack.com" } }, "context":{ "location":{ "type":"enterprise", "id":"E1701NCCA", "name":"Birdland", "domain":"birdland" }, "ua":"Mozilla\/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.186 Safari\/537.36", "ip_address":"1.23.45.678" } } ] }
With Salesforce, the situation is similar - using the API, you can access all user activity in this cloud-based CRM, and in particular the following events:
- logging in
- Sign Out
- report upload
- API calls
- URI (web clicks in Salesforce Classic)
- Lightning (web clicks in the Lightning Experience and Salesforce mobile app)
- Visualforce Page Downloads
- execution of apex
- And etc.
In addition, you can monitor the security of your Salesforce instance and work with event logs in the Salesforce admin console. You have 4 options:
- Monitoring all access attempts to the SFDC portal. The Login History page shows 20,000 entries about entering the portal over the past 6 months (indicating the HTTP login method - GET, POST or others). If you need a longer story, then the corresponding log can be downloaded in .csv or .gzip format.
- Monitoring field work in CRM. Through the admin console, you can track the history of working with standard and custom cloud CRM fields over the past 18 months, and through the API, access a two-year history of field changes. You can also archive this story for up to 10 years and, if necessary, access it.
- Monitoring administrative changes. Using the Setup Audit Trail function, you can monitor more than 100 actions of all your administrators (especially if there are several) over the past 180 days.
- Transaction monitoring. Using the Transaction Security service, you can capture Salesforce events in real time and apply notifications and alarms to them with the appropriate processing logic.
Recently, Salesforce has developed a specialized security monitoring solution for its platform - Salesforce Shield. It includes three components - managing the encryption of all stored information, monitoring security and data usage, and managing security policies. In the case of information security monitoring, this feature in Salesforce Shield is akin to the Azure Monitor extensions, which not only show you events, but also due to their processing and visualization tell you what to look for. For example, can you find out from which devices and platforms users most often access SFDC? Or when, most often, and from where do users enter their copy of Salesforce (can this help identify atypical entry points)? Who views confidential information? Who most often downloads reports to his computer? Answers to these questions can be obtained using 16 pre-installed panels, the input of which is analyzed by the separately licensed Einstein Event Monitoring Analytics subsystem (nice name, isn't it). With it, you can also simulate your dashboards, upload data to external BI systems, etc.
Example: monitoring information security on iPhone and iPad
Oops ... And where does the iPhone and cloud monitoring, you ask. Everything is simple here. For example, none of the SIEMs at the time of writing this article had a connector to the Apple Business Manager platform (or the Apple School Manager, which is better known in US universities), which allows you to manage Apple corporate devices - iPhone, iPad, Mac. For this task, you can use any of the MDM solutions, or you can use the Apple Business Manager (if you participate in the Apple Device Enrolment Program or Volume Purchase Program, which are not valid in Russia). MDM solutions can be installed locally and integrating them with your SIEM is not difficult in principle, just like cloud MDMs (for example, Cisco Meraki), but the story with Apple Business Manager has a pronounced cloud color and it’s interesting in the context of this article see how one of the largest IT manufacturers solves the problem of providing the ability to monitor the security of their solutions.
In general, it is from this point of view that Apple’s solutions are not very well known in Russia (although in the West we encounter them in SOC projects). Hence the prevailing opinion that Apple is a purely consumer company that has not turned to corporate customers in terms of integration into their SOCs. This is not so at the same time. The fact is that having a fairly powerful system of protection for iOS and MacOS, Apple continues to be a closed co-company and does not very actively allow outside parties to information about the safety of its products. Although the picture is gradually changing. For example, Apple Business Manager allows you to see information about activity on corporate Apple devices, which is combined into three blocks of information - the event, status and start date of the event (with the end date, alas, problems). Controlled events (Apple School Manager has a little more, but they are related to the classes of students / pupils) include:
- Email new sign-ins
- Create new sign-ins
- Email new verification codes
- Assign roles
- Delete accounts
- Deactivate accounts
- Reactive accounts
- Assign devices
- Unassign devices
- Release devices
- Unassign and delete server
- Reassign and delete server.
To be honest, there is not much information. You can work with it either in the Apple Business Manager control panel or by uploading it as a .csv file to your computer for further analysis. I must admit that the main orientation of this feature in Apple is still focused on finding problems in the IT plane, rather than addressing security issues - Apple does not have any log collection or analysis. You can get much more information if you integrate Apple Business Manager with any MDM solution - then you can get information about active users, user IDs and devices, including the Wi-Fi address, data on installed applications and their versions, presence of uninstalled updates, telecom operator, personal access point, enabled “Find iPhone” function, data encryption, jailbreak, installed certificates, personal ITU settings and settings, PIN-when settings, remote control phenomena, etc. This is enough for IS monitoring tasks, but it will require certain gestures to integrate your corporate Apple devices into your SOC.
SIEM for cloud monitoring
It should be noted that Amazon, like many other public clouds, paying very much attention to its security, nevertheless focuses mainly on mechanisms for detecting and preventing quite simple threats in its infrastructure, as well as providing access to events that can be analyzed using external decisions. Microsoft came closest to creating a system for monitoring and analyzing security events in the cloud, but using its solution will require additional financial investments. If you use only the clouds of this company, then perhaps you can limit yourself to Azure Security Center with extensions. But if you have a multi-cloud environment, then it is worth considering the use of independent solutions - SIEM, which, perhaps, you are already using to monitor the information security of your internal infrastructure. And here you need to understand how selected or chosen by you SIEM supports the cloud you use (and its various services) as a data source. For example, Splunk, QRadar, ArcSight, ELK support AWS and this is directly stated in the documentation for these monitoring systems, but the same RuSIEM or PT SIEM does not support.
It should be borne in mind that different SIEMs can take data from different cloud services in different ways. Take for example ELK and Amazon. Many cloud services and applications can forward their events to the S3 bucket, and Logstash can then pick them up on request. The AWS CloudWatch previously mentioned can also send data to S3, and can stream it to AWS Lambda (and Logstash takes them for analysis) or hosted in the ElasticSearch cloud. Well, of course, there are applications that can directly send data to ELK, bypassing S3, Lambda or CloudWatch. IBM QRadar collects the data of the same AWS GuardDuty through AWS CloudWatch, the Amazon VPC Flow Logs logs by publishing them in the S3 basket followed by captures in QRadar, and data from AWS CloudTrail either through the S3 basket or through AWS CloudWatch. Depending on what data you need for monitoring, this knowledge may help you not to make a fatal mistake by choosing SIEM, which after implementation will not be able to work with the cloud applications and services you need.
Despite the popularity of AWS or Azure, a number of SIEMs do not have built-in connectors for working with Amazon and Microsoft clouds, but it is possible to create your own - either independently or with the help of a manufacturer, as, for example, in the case of PT SIEM with Custom Connector. It is worth noting that AWS is not the right example to get an idea of how SIEM works with the clouds. AWS is the most popular cloud business platform in the world and therefore many manufacturers try to integrate their products with it, including in the field of information security. But even in this case, we must nevertheless admit that in general, SIEM today does not so often allow you to monitor cloud platforms. For example, IBM QRadar works only with the following cloud services (not including cloud information security services such as Cisco Umbrella, Cisco Meraki, Cisco Threat Grid, etc.):
- AWS GuardDuty and AWS CloudTrail (other AWS services not yet supported)
- Box
- Cloudera
- Ms azure
- Salesforce
The list is not very long. The same Splunk base of modules for working with clouds is much wider. In addition to the aforementioned for IBM Qradar, Splunk's solution also supports:
- Office365
- ServiceNow
- Amazon kinesis
- Slack
- Jira
- Google drive
- Google cloud
- Nagios
- G Suite App
- Docker
- Kubernetes
- and etc.
Please note that no one supports GCP yet.
Using the Splunk App for AWS extension (the idea will be similar for ArcSight or QRadar), you can implement, for example, the following use case monitoring scenarios that will allow you to answer questions important from the point of view of information security:
- Who added the rule to the security group that protects our application servers?
- Where does blocked traffic come to VPC?
- What was the activity of a particular user before and after the incident?
- Notify me when a security group allows access from all ports
- What security groups are defined but are not associated with any resource?
- Notify me when the console will be accessed from an external IP address
- Notify me when a user agent typical of web attacks is committed
- When are instance resources exceeded by X%?
Some SIEMs specifically designed for the corporate network may have architectural problems with the clouds. At a minimum, you will need to open a series of rules for all your cloud systems that send logs to your SIEM on the perimeter ITU. Another problem, and more serious, is the fact that having connectors for working with the clouds does not mean that SIEM is ready for use in this role. If we pay attention to the components of the monitoring system mentioned at the beginning of 6, it turns out that the connector to SIEM helps you to solve two necessary, but clearly insufficient tasks - collecting and processing information security events. Storage is provided by SIEM itself, but with the analysis we still have a big question. If a typical corporate SIEM has a ratio of really useful and working “out of the box” correlation rules to their total number, it is 20 to 80, while for monitoring cloud information security this ratio will be somewhere around 5 to 95, or even less. Therefore, do not forget that having SIEM working with clouds is not all that is needed to monitor their real security. You will need much more efforts (not to mention qualified personnel) to write event correlation rules for your cloud, for your clouds, as well as for clouds and the corporate environment (because you will probably want to correlate the location data of the user connected to the cloud platform with corporate security features).
If the situation with IaaS / PaaS monitoring is more or less good - the number of sources, the volume of created logs and event types are sufficient for their analysis, then for many SaaS this still causes difficulties. Therefore, I want to pay attention to the following activities / events that are available for most serious SaaS players and which need to be analyzed in your SIEM when monitoring SaaS:
- User and Administrator Access
- Successful and unsuccessful login attempts
- Time and place of entry
- Input device type and attributes
- Unsuccessful login attempts followed by a successful
- SSO activity
- AD activity
- User behavior
- User file activity (downloading, deleting, copying, printing, transferring, sending)
- “Sharing” files with external and internal users
- Creating open / shared links
- Activity from unauthorized / untrusted mobile devices
- Network activity
- Third Party API Access
- API privilege changes
- OAuth Certificate Related Activity
- Activity associated with the OAuth token.
At a minimum, analysis of these events, which, for example, Salesforce.com, Box or Dropbox will give you, will allow to detect a large number of incidents with your cloud data and users.
How to explain such a gap in the ability to monitor corporate and cloud environments using SIEM? Low cloud prevalence? We understand that this is not so. Rather, the question is the maturity of customers who are already ready for the clouds, but not ready to monitor their security, as I wrote at the very beginning of the article. And without this, the required number of business cases is not recruited and SIEM developers are not in a hurry on their own initiative to implement cloud support in their products; especially in the context of regular changes in the mechanisms of work and the return of security events from cloud providers (remember the AzLog story with Azure).
What to do when your provider does not have monitoring tools
But what if your cloud provider has logs, but does not have its own tools for analyzing and monitoring them, your SIEM does not support the cloud you have chosen and there is no way to write a connector to it? There is an option that allows you to use specialized intermediaries who, using the existing cloud API (it should be), access your cloud provider and then pull logs from it, apply various analytical tools to them, identifying various incidents and other irregularities, the data of which can then be given to your SIEM.
Examples of such intermediaries are either Cloud Access Security Broker, CASB solutions (for example, Cisco CloudLock), or some Multi-Factor Authentication, MFA solutions with advanced access control capabilities (for example, Cisco Duo). True, CASB or MFA, solving one problem, add another - getting another management console, which must be integrated into your SOC. But solving this problem is usually simpler. SIEM, often without a connection to the cloud, can work with information security tools, including CASB and MFA (after all, this is their main task). In this case, APIs in the CASB and MFA help, which allow you to send collected and analyzed security events to corporate SIEMs and embed them in your SOCs. It turns out a three-tier system in which SIEM, which does not have to integrate directly with the cloud, uses CASB / MFA for this (in the above case with Cisco Stealthwatch Cloud the same story).
True, CASB is not a panacea either. Not all cloud providers have APIs in their platforms that allow data to be sent to corporate SOC and SIEM. Usually it is this attribute that distinguishes corporate decisions. Sometimes even popular cloud solutions do not have such APIs, as you could see at the very beginning, when I mentioned Bitrix, “My Office” or SKB Kontur solutions.
Example: Monitoring Security with Cisco CloudLock
Cisco CloudLock is an API-based solution that integrates with a wide range of existing popular cloud SaaS platforms, such as G Suite, Salesforce, Office 365, Dropbox, Box, ServiceNow, Slack, Okta, etc., as well as IaaS / PaaS -platforms such as Salesforce and AWS. Unlike proxy CASB, the API-based solution allows you to work with data that is already loaded into the cloud, analyze inter-cloud traffic, and control access from mobile and unmanaged corporate and personal devices. At the same time, Cisco CloudLock, which gradually becomes an integral part of Cisco Umbrella , does not interfere with the user’s work and connects to controlled clouds due to the API they have, which allows you to monitor violations such as:
- password guessing
- login from an atypical location (account theft)
- violation of the rules for working with confidential information (storage in the cloud of information that should not be there)
- malware in the cloud
- data leak
- violation of regulatory requirements
- Access from prohibited or expired applications.
Access to these incidents is possible both from the Cisco CloudLock service itself, and through SIEM, to which CloudLock provides the necessary information through the existing API. Currently, Cisco CloudLock can integrate with Splunk, QRadar, and Arcsight.
SOC
So, we got some idea of how information security monitoring works in popular cloud environments in Russia. Now you understand what data and how you can upload to your SIEM. But does this mean that you can talk about a built-in cloud information security monitoring system? Of course not. It’s enough to recall that according to the popular, but not quite right concept, SOC is a combination of people, processes and technologies. We talked above only about technology. The time has come to talk a little about other components.
To begin with, the cloud world today does not have a clear favorite and leader. Companies use different clouds for different tasks. I gave the example of Cisco above, which in its activity uses about 700 cloud providers around the world. And they are all different, with different approaches to ensuring information security and its monitoring.In order to integrate all of them into our IS monitoring center, it is necessary to look beyond the ways of loading data into SIEM and build a full-fledged multi-cloud monitoring strategy, which necessarily includes the following steps:
- , ( use case). use case Splunk. , . , , - “”. , ? use case . — , .
- playbook' runbook', .
- , use case, . , , . Amazon — ( , , ..), ( , , Amazon EC2 VPC) (, , ). , , .
- , , , , .
- , . , , Threat Intelligence, , , ( Cisco Stealthwatch Cloud), (, Amazon Web Services ), , - . .
- , .
- , , , - . , - osquery.
- , (, WORM — Write Once, Read Many), (, AWS Key Management System) (, Amazon S3 Glacier).
- , , Threat Intelligence, (, GCP Azure), . , . , , .
- (SIEM), CASB NTA (, Cisco Stealthwatch Cloud).
- Threat Hunting, , . , , — . .
- .
It should be borne in mind that some of these components will overlap with other monitoring tasks that your organization may face - SLA monitoring, availability monitoring, application performance monitoring, usage monitoring for subsequent billing, etc. Therefore, building a security monitoring system for your cloud, first specify what has already been done and what is planned to be done by your colleagues from other departments - you may be able to use the achievements or tools already made or to share a number of tasks with others.
It seems like I did not write anything special and new. If your SOC is designed correctly from the very beginning, then adding any new controlled entity (whether it be a cloud, ICS or mobile devices) should not lead to a strong alteration of previously developed documents and processes. When we design or audit SOCs, we try to initially take into account all these aspects in our work.
Conclusion
Summing up, it’s worth repeating again that monitoring of information security in cloud environments is a relatively new topic even for the “oldies” of the cloud market. Therefore, changes are constantly taking place in this segment, and something that was not possible until recently appears in the portfolio of the cloud provider. The same applies to the functions for monitoring information security. Regardless of which provider we are talking about, they can provide you with one of several monitoring options:
- — .
- SIEM . , “” /.
- API, “” . .
- .
- Access through intermediaries who collect the data of the cloud of interest to you, enrich them with additional information and apply various analytical tools and algorithms, after which they transfer the result of the analysis to your SIEM or information security event analysis system.
All of these five options differ in the complexity of working with them, the price and speed of monitoring and response. I can’t say which one to choose, since it very much depends not only on which cloud you are working with, but also what your monitoring strategy is. IB. I can only help with a list of questions to ask yourself and your cloud provider, with whom you decide to “connect your life”:
- Do you work / plan to work with one cloud or with several?
- What protection mechanisms does your cloud provider offer? It depends on what you can monitor and what not.
- ISO 27001, Fed-RAMP, SOC2/3? , - - .
- ? .
- ? ( )?
- / ? , , .
- ? ? ? threat hunting? - Threat Intelligence?
- ? / ?
- API ?
- SIEM ? /API ( )?
- “” SIEM? use case ?
- SIEM ? — SIEM?
- SIEM CASB?
- SIEM TI- ?
Here is a short list of questions, the answers to which will allow you to start building the process of monitoring the information security of cloud environments that you or your business decided to use. The sooner you take an interest in answering these questions, the cheaper it will cost you to build a monitoring system and the less incidents will occur with your resources given to external cloud providers. As Cisco’s experience in building or auditing SOCs shows, even the most successful IS monitoring centers that effectively manage incidents within the corporate network do not always advance cloud monitoring capabilities in their architecture, which necessitates its restructuring. I hope the observations and recommendations described in these two parts will help in ensuring cybersecurity.
All Articles