Adoption of Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS) applications means navigating the Shared Responsibility Model. Under the Shared Responsibility Model, the cloud services provider takes care of the infrastructure’s security, but you need to secure what happens within that environment.
According to the State of Cloud Native Security Report, 50% of companies surveyed reported that maintaining comprehensive security remained a challenge. As you continue to develop your cloud security program, knowing how to use log management for Shared Responsibility Model compliance can allow you to leverage current toolsets more effectively.
What is the Shared Responsibility Model
The Shared Responsibility Model attempts to define the security obligations that a cloud services provider (CSP) and its customer have. Still, accountability to develop, manage, test, and deliver internally developed applications. Additionally, a PaaS deployment may include prebuilt tools that help DevOps teams. This infrastructure provides organizations a way to focus on software development, manage security, and facilitate collaborative DevOps.
Within a PaaS model, the CSP must secure:
- Runtime
- Middleware
- Operating system
- Virtualization
- Servers
- Storage
- Networking
Meanwhile, the organization needs to secure:
- Data
- Applications
Understanding the Overlap
Generally, the more infrastructure the CSP controls, the more responsibility it has. In a PaaS model, the CSP provides more services, thus giving it more responsibility. However, as organizations incorporate more cloud services, the two models tend to converge.
Example:
IaaS providers also sell Database-as-a-Service (DBaaS), offering storage options that traditionally fell into the PaaS bucket.
Additionally, in multi-cloud infrastructures, an organization may have an IaaS deployment in Azure but a PaaS deployment in AWS. Ultimately, the interconnected nature of these cloud environments increases confusion, which can lead to security weaknesses.
Further complicating the relationship, some cloud security controls are shared equally between the CSP and the customer.
Example
- Patch management: the CSP must patch the global infrastructure, but customers must patch operating systems and applications
- Configuration management: the CSP configures the infrastructure devices, but the customers configure the operating systems, databases, and applications.
Finally, organizations cannot merely take a “set it and forget it” approach to their CSPs security responsibilities. Companies must continuously monitor their vendors’ cloud security posture as part of their third-party risk management programs, functionally making them responsible for monitoring all cloud security risks somehow.
How does log management enable Shared Responsibility Model compliance?
Enter log management. Every action taken by a user or device within your infrastructure generates a record. When aggregated, these records can tell you about activity within your cloud, from the number of failed login attempts to endpoint security logs.
A centralized log management solution enables you to create a single source of documentation for monitoring your cloud security posture. Aggregating event data allows you to correlate information more efficiently, either as part of a proactive risk mitigation strategy or as part of forensic research.
Example
If misconfigured, serverless functions can create a security risk. AWS VPC Flow Logs can track a Lambda function’s activity. Bringing this event log data into a centralized location enables you to correlate and analyze data more efficiently.
Since your organization is responsible for any code you develop and deploy, monitoring for security risks is part of your responsibility.
4 Event Logs That Enable Shared Responsibility Model Compliance
Whether you deployed an IaaS or PaaS model, you need to secure data located within your cloud. You also need to prevent malicious actors from gaining unauthorized access to your cloud. With that in mind, the following four event logs provide essential visibility into some of the most significant cloud risks.
Identity, Access, and Authentication
As organizations move data to the cloud, traditional protections, like firewalls, become less effective. Monitoring access to your cloud resources is fundamental to Shared Responsibility Model compliance. Identity, access, and authentication logs can help you identify malicious actors using stolen credentials.
Example
“Failed login” event data can provide insight into potential credential theft. Too many failed login attempts, when combined with failed multifactor authentication attempts, indicates more than a forgotten password.
Endpoint protection
With malware attacks on the rise, organizations need to ensure that the devices connecting to their cloud instances have up-to-date antivirus protection. Since most malware attacks seek to steal credentials, endpoints become a primary threat vector. Endpoint protection logs provide visibility into malware trends, security risks, and attacks.
Example
Microsoft Endpoint Manager log EPCtrlMgr.log records details about synced information between the Endpoint Protection role server and the Configuration Manager database.
Application logs
Application logs provide important security monitoring data. When appropriately configured, they provide insight into activities indicating a security incident such as input validation failures, output validation failures, file upload virus detection, changes to privileges, key changes, creation and deletion of system-level objects, and network connections.
Example
Microsoft AppService 9.3 scans web applications to ensure that they are using the latest version of TLS encryption. If the log indicates outdated encryption, the web application may not be secure, leading to the Shared Responsibility Model noncompliance.
Server logs
Web server logs collect information about the traffic requests coming into your servers, often alerting you to potential Denial of Service (DoS) attacks. Server log anomalies that might indicate an attack include malicious requests from hosts, spikes in web access trends, changes in traffic proxies or referrers.
Example
In AWS Cloudwatch, you can configure streams of SSH log entries. The log can capture failed login attempts that might indicate a security event.
Graylog Centralized Log Management for Shared Responsibility Model Compliance
With Graylog’s centralized log management solution, your security team can gather and aggregate data for a proactive cloud security approach. Our integrated search, workflow, dashboards, and reports enable your team to dig rapidly into data for more efficient research.
Our automated reporting feature lets you monitor trends over time so that you can review and document your compliance activities. Our easy to use report builder streamlines compliance so that your team can focus on securing your cloud deployment.
