Audit logs in the cloud: who was it?!

Itian 1: "Please, do you know why it's not working now? It was running yesterday!"

Atiyak 2: "I traced from the log that someone logged in with an admin account, but I don't know what changed."

Ijit 1: "Who changed anything in there?"

Chorus: "Not me."

Similar situations have probably happened to all of us. Personally, I hope that it is rarely the case anymore and that we all have the right set of change management process. It is also important to keep and process environmental audit logs honestly, perhaps because your internal guidelines require it, or you are even obliged to process audit logs for external regulations (e.g. CNB regulation, critical infrastructure of the state or different ISO standards). So why should we store audit logs and what tools should we use? That's what we will discuss in today's article.

Basic division of audit logs

In principle, audit logs can be divided into two basic groups. Each is equally important and we should not forget one or the other.

Let's not forget that audit logs should be always store and processregardless of the technology used or where the application is run from. Furthermore, we must not forget the topic data retention. Due to the fact that we typically keep audit logs for regulatory reasons, it is necessary to keep this data for a long period of time (sometimes several years).

• Environment audit logs: typically contain information about who has manipulated, accessed or modified the environment and how. Thus, these are typically logs that reflect administrative actions (who changed which component or resource, which data in the database or which files were accessed, and how).
• Application audit logs: these logs map and describe user activity within the application. For example, this can be information about what application functionality the user accessed, what user inputs were used to generate a menu, or what document was downloaded.

As part of our Cloud services we will be happy to help you define and set up the necessary rules.

Audit logs and the cloud

A major benefit of the cloud environment is that audit logging tools are a direct part of all major cloud platforms. In the cloud (as opposed to a typical on-premise environment), the all actions performed via API - either by calling these APIs directly or indirectly via UI interfaces or various software development kits. So if we perform all operations "over one place" (the API), it is very easy to log and process all these actions.

Environment audit logs

So what tools do individual cloud providers offer us? In the case of AWS, these are AWS CouldTrail, Azure again offers Activity & Resource Logs.

The aim of these tools is to capture any activity (operation) performed over all resources. These activities can be triggered by the user or directly by the cloud environment or another service.

Here, for example, we see activity in one of our internal Azure environments and we can clearly see that some operations were performed by the user (here specifically by me) and others are performed directly by the cloud environment (automatic backup of a virtual server).

A detailed audit trail is available for each operation, which stores all the information about the individual operations performed. Typically, therefore Who (identity or role), when (when the operation was called), Where (identification of environment and region), From(IP address, endpoint identification) and What (what operation over what specific resource) was performed within the environment.

 

Processing and visualization of audit logs

The first part is over - we have detailed logs of all operations. Both of the tools mentioned above (AWS CloudTrail and Azure Monitor) offer basic options for filtering and browsing these logs, but you'll probably want to implement some additional (either native or 3rd party) tools in your environment to visualize this data.

If you choose to use pure cloud provider tools, you'll likely reach for tools like AWS CloudWatch, AWS QuickSight or Azure Log Analytics. All of them have the aim process any volume of source data and based on your preferences and requirements is visualize and offer it to users.

The next step in optimal work with audit logs will probably be the definition of specific notification rules. For example, it would be interesting to track the rate of failed attempts (access denied) over individual accounts, which may indicate that a user is trying to do something they shouldn't.

Another example might be notification of key operations over production resources, but there are no limits to your imagination and you can certainly come up with many other interesting scenarios.

External tools for processing audit logs

Nowadays, there are a wide range of external tools that can be used to analyze audit logs. The primary difference from native cloud tools is a certain higher level of "intelligence", prebuilt repots and templates, and support for different environments, which is useful for those of you running multi-cloud environments.

For me personally, I would recommend looking at the following tools:

• CheckPoint CloudGuard
• Datadog
• Runecast

The individual tools differ from each other, especially in terms of the additional security features offered. There is certainly no perfect tool, each has its pros and cons. I definitely recommend to deploy the chosen tool in a Proof of Concept implementation and thoroughly test all the required features before the final implementation.

Application audit logs

The second area you should cover is audit logs within the application itself. Here the situation is a bit more complicated because each application is unique. In general, you should be able to identify within the audit logs every user action performed in the application itselfsuch as:

• Performing a business action
• Access to application data
• Calling a key operation
• Change of data

But how to achieve this? Here, the decision will probably be up to the application development team to decide what technology or approach to use. The functionality for collecting application audit logs can be implemented purely "in-house", i.e. within the application development itself, or you can use services offered directly by cloud providers.

Here I would like to mention especially the tools AWS X-Ray a Azure AppInisghts. Although these services are not focused on the area of application auditing (their primary use is for application monitoring), but thanks to the fact that they can "see in detail" into the application itself, it can be relatively easy to create your own "audit logic".

How to process and evaluate these audit records? This is similar to environmental audit trails - for example, you can use Azure Log Analytics and visualize the data or use standard log management tools such as Splunk or ELK Stack (Elasticsearch, Logstash and Kibana).

What do you use?

Audit logs are not magic, and they are remarkably easy to work with in the cloud because they are available to you automatically. Don't forget them, store them and process them. They will come in handy! And the next time someone asks you, "Who was that?!", you won't have to think long.

What tools do you use? Do you use only the native tools of each cloud provider, or do you use other technologies and tools? I will be glad for any comments and especially personal experience.

And what can you look forward to next? In the following article, we'll take a look at the detailed cloud monitoring options and a colleague Jakub Procházka introduces you in detail to some of the tools I've mentioned in this installment of the Cloud Encyclopedia. All previous chapters in the series you can find here.