Virtualizing Your Forensics Lab in the Cloud Part 5: Securing Your Evidence in Microsoft Azure

Hello everyone! Jamie McQuaid here, Technical Forensics Consultant with Magnet Forensics, and lately I’ve been spending a lot of time thinking about—and implementing—innovative ways to conduct investigations in the cloud and using cloud technology. In this fifth installment of the series, I’ll go over some ways that you can secure your evidence if you’re using Microsoft Azure. There are definitely ways that you can make the cloud a safer place for your evidence, and I’m going to show you how.

Getting Started

Whether you’re collecting evidence from the cloud or storing it there for analysis, considerations and steps should be taken to ensure that data is secured and only accessible to those who need it. We, as examiners, do this for evidence whether it’s in your lab physically, somewhere else in your organization, or virtually in the cloud.

How do we secure our evidence so that it’s integrity can be evaluated and confirmed regardless of how it’s stored? There are lots of methods but the primary way to secure something is to limit access. We do this today with proper evidence handling and storage requirements and we track that access with chain of custody. A chain of custody at the most basic level tracks everyone who’s touched the evidence from the moment it is seized to the moment it gets presented in court (and then either returned to the owner or destroyed). Well, we can do these same things if our data is stored in the cloud, we limit access to it and have an audit trail of everyone who has accessed it.

Restricting Access Using Access Controls in Azure

Just like you do in your lab, you need to restrict access to your evidence in the cloud. Luckily most cloud providers have very robust security access controls at your disposal for this exact purpose. So, let’s take a look at ways we can secure that data in various states:

Evidence at Rest – Azure Blob Storage

Azure has a few different types of account storage that depend on the type of data you’re storing. Examiners are most often storing either phone or disk images such as AFF4 or E01, or case files from various tools like AXIOM so the general purpose blob storage will work just fine.

Access to Azure storage is controlled by Azure Active Directory (AAD) and anyone familiar with using or managing an on-premise AD account will be very familiar with how it functions. If not, that’s ok too,

permissions are granted to users, groups, and/or roles at both the account, the container, or the individual objects.

If you want to grant access to data in a container to a specific person for a short period of time, you can use shared access signatures (SAS) which will create a URL and a token that will allow access for a specific period of time or from specific IP addresses as well.

Virtual Machines & Disks

To process or analyze anything, you’ll likely want to move the data from object storage to something that has computing capacity. A lot of the same access controls and security measures mentioned above still apply but there are a few other considerations you might want to consider while analyzing your data.

• Restrict Access – use the same IAM roles/policies as above to restrict access to your instances as well as what the instance can access.
• Dedicated vs Shared Hosts – Azure allows you to run your instances on dedicated hardware, however that comes at a cost. The shared infrastructure is always segregated and scrubbed before it gets used by another user but if you want the extra layer of separation, dedicated hardware might be an option for you.
• Clean up & shutdown – If you need to preserve or save your case data, you can either save the case back out to blob storage or save the entire disk as a snapshot prior to terminating it (saving the disk image is great if you think you may want to use the same tools you had previously configured as well).

Encryption

Encryption is likely the first thing you think of when you want to secure your data anywhere and Azure has many options for encrypting your data at rest for both blob storage and VM disk storage. The default setting for Azure is to encrypt both storage accounts and VM disks with Azure managed keys however they have options to configure your own keys as well.

For most standard uses, the default encryption works quite well but when dealing with evidence you may want to or may be required to apply your own customer-managed keys to ensure compliance for your lab or organization. You can use the Azure Key Vault to create and manage your own keys and once they’re created and configured, they can be used across your Azure resources.

By default, Azure also sets the data in transit to be encrypted and will deny any non-HTTPS requests (this can be disabled but default is to have it on and best to leave it on). When setting up your storage accounts you also have the option to control how the data gets routed prioritizing routes within the Azure infrastructure instead of the public Internet further minimizing the risk to your data while it’s in transit.

Tracking Access with Audit Logs

Once we’ve secured our data and restricted access to it, how do we know nobody else accessed it? If we set up our access controls above correctly then only those authorized accessed it, but how do you prove it? Cloud providers have very robust logging features and functionality that goes far beyond any chain of custody form and can complement an existing custody tracking to ensure that access has been restricted.

Log Analytics in Azure

Each service has its own logs that you can review from within that resource (Activity Log) however if you want to centralize your logs across resources, you’ll want to use Log Analytics in Azure Monitor.

Log Analytics helps consolidate your logs and better manage them across resources. Once you need to start tracking activity across several resources, it becomes a necessary part of your integrity checks. Log Analytics allow you to visualize and query data for quick analysis right in the platform, but you can also export them if you wish as well. You can also set up alerts to notify you of any particular activity of concern for any of your resources so that response can be immediate.

Overall, using the cloud to improve our investigative capabilities is a major win for teams who might not have a budget for a full lab or has limited storage and computing power. Even if you have a decent lab, there is certainly many benefits to enhance your lab’s capabilities. As long as you take the time to understand how it can be used and secure your evidence just like you would secure it in your physical lab, it can be a very valuable addition to your toolkit. Securing data starts with access controls and auditing allows us to ensure the confidentiality and integrity are maintained throughout the investigative process.

About Jamie McQuaid

Jamie McQuaid is a Technical Forensics Consultant with Magnet Forensics with over a decade of experience in corporate investigations and helps advise Magnet and their customers on cloud security best practices and find innovative ways to conduct investigations in the cloud and using cloud technology.

Follow Jamie McQuaid on Twitter (@reccetech) to see what he’s up to and catch up with him!

Further Reading

• Part 1: Leveraging IaaS for Your Lab
• Part 2: Benefits of Virtualizing Your Forensics Lab
• Part 3: Let’s Get Practical
• Part 4: Securing Your Evidence in AWS

Technical Advice Disclaimer

Magnet Forensics is dedicated to engaging with the DFIR community through our blogs and whitepapers. However, properly addressing technological issues often includes numerous variables that require independent assessment and strategies designed for each specific circumstance. Since Magnet Forensics cannot have complete insight into all variables involved in a specific situation, this blog/whitepaper is for informational purposes and should not be read as professional advice recommending techniques or technologies to address your specific situation. We do not accept responsibility for any omission, error, or inaccuracy in this blog/whitepaper or any action taken in reliance thereon.