SUMMARY

"We're moving to the cloud!". This is a phrase that is becoming more and more common in the business world. Companies are pursuing cloud solutions for all their business needs. It won't be long before on-premise data centers and bare metal servers are a thing of the past. These are exciting times and the possibilities associated with cloud technology are endless. However, this transition presents a new, unknown territory for digital forensic investigators and incident responders. DFIR professionals must prepare to work in a vastly different environment while performing the roles that they filled in a traditional IT setting. For this reason we need to begin analyzing our current incident response and forensic procedures and determine how we can apply them to a cloud environment.

Let's start by introducing one of the cloud business suites on the market right now, G Suite. G Suite is a subscription based service by Google that provides a cloud platform for email, storage, document editing, telecommunication, and much more. The reason I decided to dive into G Suite specifically is due to encountering an incident where an account at a company that used G Suite as its business platform was compromised and proceeded to be used maliciously. I had heard of G Suite and, like many of my peers, had used all the associated products (Gmail, Google Docs, etc), but I had never had to think about incident handling for a company that ran on G Suite. I was entering an environment that had no Exchange servers, no domain controllers, and none of the other sources associated with a traditional enterprise infrastructure. With a 3 million business customer base that is continuously growing, there is a good chance that many other DFIR professionals will encounter this same situation.

Through my experience with the aforementioned account compromise and additional research into digital forensics and incident response in the cloud, I've decided to write a 3-part article on DFIR in G Suite. Part 1 will discuss applying the NIST Incident Response Framework to a IR situation in an environment running on G Suite. Part 2 will focus more on the forensic aspect of an investigation, specifically finding artifacts and keeping your investigation forensically sound. Lastly, Part 3 will provide a case study of DFIR in G Suite to see how part 1 and 2 might be utilized in a real-life situation.

INCIDENT RESPONSE IN G SUITE

In this first part of the series we will first do a very brief review of the NIST Incident Response Framework and then discuss how to apply the framework when responding in a G Suite environment.

The NIST Incident Response Framework

One of the most commonly followed frameworks for incident response procedure is presented by the National Institute of Standards and Technology (NIST) in NIST Special Publication 800-61, also known as the Computer Security Incident Handling Guide. The steps involved are as diagrammed below in the NIST Incident Response Lifecycle diagram.

NIST Incident Response Lifecycle

The specific details pertaining to the NIST IR framework are out of the scope of this article. The following is a short description of each of the steps:

1. Preparation - This step focuses on 1) preventing as many incident as possible by securing your network and 2) preparing to respond to incidents (training, writing procedures, etc.).
2. Detection and Analysis - This stage involves detecting and validating incidents. Detection can come from a variety of sources, such as a network sensor alert, end user reports, or anti-virus detections. Once you've detected a potential incident you need to verify whether it is actual a security incident or just an abnormal event. Identifying an incident from a random event takes a skilled analyst.
3. Containment, Eradication, and Recovery - After an incident is detected and scope is determined, the threat must be isolated to prevent spreading. The already impacted machines must be cleaned and purged of any infection. And any negative impact against the business must be recovered from.
4. Post-Incident Activity - This stage involves reviewing the incident as a whole and determining areas for improvement. It also involves writing up an incident report to provide to stakeholders and executives.

For more detailed and thorough information, check out the source of the framework, the Computer Security Incident Handling Guide .

Applying the Framework to a G Suite Incident

The above section should provide enough detail for us to move on to how the NIST IR Framework can be applied specifically to a G Suite incident. We are going to break it down by each part of the framework and provide some examples.

Preparation
The best preparation that can be done ahead of time specific to G Suite is to get familiar with the admin console (where an incident responder will spend most of their time) and where to find different items of interest. Essentially, ask yourself what logs or information you would pull during an incident in a traditional enterprise environment and try to find that same information in G Suite. As discussed above, preparation also involves preventing incidents. G Suite has built in security features that can assist with reducing the number of potential incidents. For example, you can enable Two Factor Authentication (2FA) or turn on the Gmail-related anti-phishing features. If G Suite's built-in options are not enough for you, you can expand on the platform itself with methods such as deploying an email security appliance in front of your organization’s Gmail traffic flow.

Detection and Analysis
During this phase incident responders receive an alert about a potential incident and analyze the situation for potential next steps needed. There are two main methods of detection in a G Suite environment outside of a dedicated email security appliance. The first is the alerting feature mentioned in the previous subsection. Any email alerts the incident response team receives from G Suite should be vetted and either marked as false positive or escalated for further investigation. It is also possible that a user may report abnormal activity that the alerts did not detect. Any reports of strange activity from users should be followed up with. Details should be gathered and associated logs should be reviewed. Though these two methods are the main methods for detection, auto-generated alerts aren’t a catch-all solution and analysts should be monitoring the logs and environment for anomalous activity not detected by the pre-written rules.

The next step in this phase is analysis. At this point we’ve received an alert about an event and escalated it to an incident. We should have some observables associated with the incident such as an IP, email sender, or user. This will be our pivot point for analyzing the incident further. The G Suite admin console provides a reporting platform to find activity among the different applications or pull logs for certain event types. Two specific logs from the admin panel that are rich in information typically useful in a incident investigation are the Login Audit Logs and the Email Logs.

The Login Audit Logs are useful in determining abnormal logon behavior. For example, if a user logs in from the U.S. and then 15 minutes later the account logs on from China, there is probably something fishy going on. From the email logs you can search on a specific criteria and see the details of all matches. These details include information about the path the email took, how many recipients there were, if there were attachments, and more. Identifying the recipients of the email and accounts with abnormal logon activity can assist in determining scope, which will assist in the next step.

Containment, Eradication, and Recovery
Containment, eradication, and recovery steps will vary depending on the scope of the incident. Below are some steps that might be performed depending on the specific incident you are responding to:

• Immediately disable any known or potentially compromised accounts until the incident response is complete. Reset account passwords for those users before re-enabling accounts.
• Review all users, groups, and aliases in the system to ensure no accounts were created for persistence.
• Review sharing settings of all files stored on Google Drive to ensure none were changed to remain accessible to the attacker.
• Review outbound emails from compromised accounts to determine whether the account was used to send emails.
• Review third party applications for any suspicious connected apps.

As stated, these steps may vary based on the specific incident you are working. However, this is a good starting checklist for almost any G Suite compromise.

Post-Incident Activity
In terms of final report writing, the same method of writing a report for an incident in any other environment will apply. The main difference with G Suite post-incident activity is the steps taken to prevent future incidents. Like the previous stage, this may vary depending on the scope of the incident that has occurred. Below are some of the many resources available related to securing your G Suite instance and will assist in preventing future incident. These steps are closely related to preparation but can be more focused on fixing the root cause of your incident.

• 8 swift steps G Suite admins can take to secure business data
• Set custom alerts on audit events for Google Apps admins

Conclusion
The existing NIST IR framework can be applied in G Suite just as it is in any environment. Though there may be different features in the platform or methods of securing it, the overall process is the same. Anyone who has handled incident response in a traditional environment should easily be able to adapt to a customer operating a G Suite account.

In part two of this blog series we will investigate digital forensics in G Suite. We will look at both the similarities and differences that exist as compared to a traditional enterprise environment.