Four Steps to Getting Your Linux Cloud Audit-Ready
By: Sara Fein
TL;DR: Compliance can be a huge point of stress for cloud-first companies. In this co-written article with Audit Liaison, we’re sharing a handful of core actions to get your cloud audit-ready.
Back in the “good” old days, audits involved much less data and way more paper. Today, a compliance audit can encompass massive amounts of data, servers, multiple clouds, production Linux environments, hundreds of users, and more. With the advent of cloud environments and the explosion of unique service providers processing a variety of user data, companies are also subject to many more regulations.
Depending on a given company’s industry, customers, and focus, some of the regulations driving audit needs are:
Regardless of which regulations your organization is beholden to, preparing for audits can be overwhelming without a plan in place. In this post, we’ll discuss four ways that organizations of all kinds can get audit-ready.
1. Assess Your Risk
Audits exist to ensure that organizations are operating in secure and legal ways. While they can be annoying, they do represent a crucial business need to assess risk and build appropriate controls.
Organizations that mishandle data, experience breaches, or suffer other security issues can get in big trouble, and not just from a regulatory perspective. They can lose customer trust and diminish their reputations.
“Risk assessments can be crippled with complexity, or end up far too simple to act upon… ironically there is a risk in not performing a risk assessment correctly”
The first step to being “audit ready” is to have a firm sense of your individual organization’s risk factors and risk profile.
Of course, no two cloud environments are the same, and so no two companies have the same risk profile. The best way to get audit-ready is to actually understand your unique risks.
Some good questions to ask internally include:
How many corporate devices do you have? What kind?
How well are these devices monitored and secured?
Where is your client data?
Who has access to that data?
Where do your logs live?
Who is reviewing these logs?
A risk assessment may sound like a massive lift, but even a simple assessment can reveal areas for quick improvement. Take, for example, this worksheet, which includes a checklist based on SANS guidelines. The COSO framework, which is used widely as a benchmark for organizations of every size, also has a useful framework for risk assessment. For another comprehensive baseline, the ISO 27001 can also provide a valuable place to start.
2. Establish Roles and Responsibilities
Long before an audit takes place, organizations need to determine who is responsible for which aspects of preparation:
Who is the point person?
Do they understand the respective audit requirements?
Who knows where the logs are?
Who is managing ongoing monitoring?
When companies are large, it’s easier to separate developers from individuals who manage security and control access to production environments. While this is the ideal—a separation of church and state, if you will—it’s not possible for all organizations. Smaller companies with lean development teams often lack the headcount and resources necessary to separate duties. Their lead developers are also often in charge of security and access control; done correctly this can result in a positive shift, known as DevSecOps, but it’s often much easier to say than to implement. Either way, it’s a lot of power in one person’s hands, and it can introduce risk for unmonitored changes.
If you’re a smaller company that cannot separate duties, there are several ways to address the conflict:
Closely log and monitor access:Software like Cmd can provide this level of granular insight into who is doing what, when, and where—so even if the same people are granting permissions and taking action, there is a clear trail to demonstrate what is happening for any upcoming audits.
Implement just-in-time permissions: This means not leaving permissions wide-open, but rather granting them in time-limited instances. This ensures sensitive production environments are not perpetually open, and that, again, there is a record of who is accessing information or systems and who gave them the OK to do so.
Regardless of your organization’s individual dynamics, someone needs to be specifically in charge of compliance… someone who can be a trusted control owner, who may (or may not) be an expert in the backend intricacies of your infrastructure, but is well versed in your audit requirements and what they mean. They’ll need full access to the relevant logs, insights, and more.
3. Establish Controls
Once you have the right people in place, it’s time to set up controls. This can mean different things depending on the regulations you must adhere to, but ultimately, controls are all about ensuring a level of standardization and safety around data.
“Storing logs is not a control. It’s akin to having Encyclopedia Britannica on your shelf… a wealth of information sure, but just because you have it doesn’t mean you can quickly tell me the last three Secretaries of State…”
There are five main areas where you should establish controls:
Shared standards and clear internal policies (e.g. a security handbook)
Documented procedures (e.g. a Wiki for handling various potential situations)
Training (e.g. security awareness training, process training, and more)
Monitoring (e.g. logging and alerting)
Internal audit (i.e. preparing for the “big one”)
Since we’re focused at Cmd on Production Linux, logging is a common topic that comes up around compliance. Remember, just having logs is not a control in and of itself. Without the ability to understand who is in the environment, what information they have access to, when they access that information, and what they do with it, audit logs are not useful… like books in a library with no Dewey Decimal System. You need controls set up around your logs.
The exact controls for your business, again, will vary, but the five areas above are a good place to start getting more organized ahead of an audit.
4. Get Talking, Start Training
In organizations that do have a separation of responsibilities between compliance and technical functions (e.g. engineering, IT, etc.), the people tasked with compliance and audits are often non-technical employees—or at least, they’re not developers themselves, even if they have some technical experience. In this case, the name of the game is getting information as fast as possible.
The biggest challenge for these business-side employees is translating technical information into insights that fit the parameters of an audit. Good communication between developers and the compliance leader and/or team will go a long way in making an organization audit-ready. The more each team understands each others’ needs, the better.
For example, make sure that logs are stored and set up in ways that non-technical people can access quickly and easily. You can craft queries for frequently requested information and just provide simple instructions to copy and paste them to retrieve the information needed.
In addition to access to information, organizations should also invest in training for compliance employees. Once an external audit starts, they will be expected to know exactly what to do and where the information resides, so give them a head start with training. The best preparation is a “dry-run” audit, driven internally to learn the audit process without the downside of opinion risk.
Think Beyond the Audit
Organizations that understand their unique risks, designate point people, get the right controls in place, and provide good training will be much more prepared to effectively manage an audit. Being audit-ready can take significant preparation, and compliance needs will naturally change over time—so it’s far from a “one and done” process.
Moreover, most organizations need to recognize that passing an audit does not mean you are fully secure. It’s key to embrace evolution and continuous improvement when it comes to both audit requirements and a strong security posture.