Infrastructure Access and Auditability
Introduction
In this blog, we look at all the different factors organizations should consider while sharing infrastructure access with team members. This has become quite a critical question post-covid as companies are still adapting to the remote set-up. Also, a lot of recent high-profile stories like the Twitter whistleblower incident and the Uber and crypto hacks have created an urgency in organizations to really think through their infrastructure access strategies.
One of the major risks while sharing infrastructure access is the lack of transparency and auditability. So first let's take a look at the cost of unsupervised access before diving into how this can be solved through audits.
Cost of Unsupervised Access
Unsupervised access often leads to compromised credentials, which then lead to data breaches. Data breaches in organizations have been increasing at an alarming rate of 15% every year since 2015. In the US alone, the number of data breaches has gone up from just 785 in 2015 to more than 1800 cases in 2021.
And these data breaches are extremely expensive to an organization. An average data breach costs about $4.35M and 19% of these breaches are caused due to compromised credentials - Hence, unsupervised access is extremely dangerous and expensive!
Access Management Considerations
So now that we’ve established how important having an infrastructure access strategy really is, how do companies currently do this? Especially w.r.t. production environments, where the cost of a breach is way more expensive?
At the end of the day, any organization’s security implementation is a tradeoff between:
- Locking everything down and making it really hard to use which is expensive to implement and maintain, and reduces employees’ efficiency
- Moving fast with minimal restrictions, key sharing, etc. but it’s really prone to security incidents
However, there are a few more nuances to the above philosophies that are important to consider. There are 4 key dimensions to consider when evaluating an infrastructure access strategy:
- Security Posture
- Auditability
- Developer Productivity
- Ease of Set-up & Maintenance
In this blog article, we go deeper into two dimensions - Auditability and Ease of Set-up & Maintenance. We will discuss how you can use your existing logging facilities to improve Auditability. We also dive deeper into the limitations and breaking points of these audit capabilities.
Server Audit Tools
Default logging in most Linux distributions shows who accessed your servers via ssh or what commands were run with elevated privileges. Auditd takes this a step further and is easy to set up.
| Tool | Captures |
|---|---|
| journalctl | Successful/failed login attempts along with username/source ip (via sshd). Commands run with elevated privileges (via sudo) |
| auditd | File/directory changes by any user, system calls, etc |
| sshaudit | ssh server & client configuration |
Limitations of SSH audits
While the setup is easy and without cost, these tools have limitations:
Attribution
Both manual and automated access is logged, making it very hard to segregate. People often have bucket access making it even more convoluted to figure out who accessed what. This often happens when applications and team members share the same public/private key pairs to access the servers.
Scaling
This is hard to scale. One way to scale this is to add agents that stream these audit logs. Would need additional tooling such as an Ansible infrastructure to manage the agent lifecycle.
Figure 1. Additional tooling is required for log collection/analysis
Log Management
Adequate steps must be taken to ensure that logging continues uninterrupted and that the logs are archived/rotated without overwhelming the storage of your production systems. Additional tooling may be required to analyze the logs as they accumulate over time.
Database Audit Tools
By default, full audit logs are not enabled on popular database systems including PostgreSQL or MySQL. Fortunately enabling detailed logging boils down to simple configuration/extension.
| Configuration/Extension | Captures |
|---|---|
| PostgreSQL’s log_statement | User submitted queries |
| pgAudit extension | Queries executed by DB |
| MySQL’s general_log | User submitted queries |
Limitations of DB audits
Besides difficulties associated with attribution, scaling, and log management, Database Audit tools have limitations of their own:
Heterogeneity
Organizations with heterogeneous databases such as NoSQL, SQL, etc. will require a different setup for each database. And additional tooling will be required to get a unified view from all the databases.
Unencrypted Confidential Data
Extra effort is required to ensure that confidential information is not propagated unencrypted into the logs.
Conclusion
The tools discussed above are easy to set up, require little financial investment, and are a good starting point toward Auditability. However, as the organization or infrastructure grows, maintenance and scaling issues start showing, necessitating investment in third-party tools.
|
SOC2 Type II
