Addressing Your CxO's Top Five Cloud Security Concerns

 Overview and the Kill Chain

Customers frequently ask us how they can defend their Office365 tenancy. While the motivations and capabilities of attackers vary widely, most attacks still follow a common process. The security industry refers to it as the attacker kill chain; a concept borrowed from military doctrine and adapted for this realm. The basic idea here is that an attack has to follow a basic pattern and proceed from one step to the next in order to achieve the desired outcomes. This step-wise process can be defended against by focusing defense measures on choke points in the chain. Of course, any step can be bypassed through exploit technologies, so the best strategies apply defenses at every step along the chain.

Office 365 Security has described the top five threat scenarios below based on the broader threat landscape, but you can apply the same principals in your own planning. Each scenario is laid out below, with ways to protect, detect, and respond to (some of) the threats associated with each attack type.

Note that all of the detection scenarios below will require access to activity data from the service. You can use the process described here: https://blogs.technet.microsoft.com/office365security/using-office-365-activity-data-to-improve-your-cybersecurity-stance-and-capability/ to enable your detection and investigation capability. Also note that all of the activity data used to drive detection and remediation scenarios is described here: https://msdn.microsoft.com/EN-US/library/office/mt607130.aspx.

Scenario 1: Account

Scenario. In this scenario, an account in your tenancy is breached such that it can be used by an attacker to interact with either resources in Office 365, or with your on-premises infrastructure. There are a variety of ways that this can happen including spearphishing for credentials with harvesting websites, spearphishing with malware to install rootkits and keyloggers, or other sorts of attacks . Another, less common, model is to use password cracking techniques to guess the user's password by trying many variations with a computer. Since most companies with substantial numbers of users, or complex application ecosystems end up running a hybrid or federated domain model, an on-prem account and an Office 365 account will have the same credentials, and will represent a single   around the services accessible by the affected user. Once the attacker has the username and password for the user, they will generally be able to find a way to authenticate and interface with Office 365 as if they were actually the end user.

Preventing the Scenario. The best way to prevent an account from being breached in the first place is to use high quality authentication mechanisms such as Multi-Factor Authentication. Your users will have to perform an additional step to logon to services, but the need to have a second, usually physical token to authenticate makes it much harder for an attacker to steal an identity without the actual account owner knowing about it. You can protect against password cracking attempts by enabling directory controls against multiple failed logon attempts. You can either disable the account or

Detecting the Scenario. A breached account is among the more difficult things to detect quickly. Since the account is used to contextualize all interactions with the service, there is rarely just a single event that you can use to detect illicit activity (an atomic detection). Instead, you will likely have to employ more sophisticated techniques like anomaly detection. The key to an effective account breach detection is understanding what a normal pattern of activity looks like for your users. There are several features that exist in the activity data that you can use to find illicit or anomalous activity. For example, the data includes the following: IP addresses (which can be correlated to geographies), date and time, the specific action performed, and user agent. If you know that your users rarely connect to the service after hours, or rarely use a new client, or never connect from new geographies, you can use that insight to create rules to detect account usage patterns that violate those rules.

Remediating the Scenario. Every change or data access will then need to be addressed. You will also need to think through the motivations of the attacker to go after an account in your tenancy so you can determine which protection and detection capabilities you should employ going forward. For example, enabling multi-factor authentication is a common, and powerful remediation to keep the account safe after it has been breached. You should also monitor the account for a period of time to ensure it hasn’t been re-breached.

Scenario 2: Elevation of Privilege and Lateral Movement

Scenario. In this scenario, an attacker has managed to compromise one or more accounts in your tenancy, and is now working to increase their power. The target is usually global administrator privileges, but specific service privileges are also desirable if the targeted data is in that product. There are a few variations of the attack pattern here that can bridge cloud service interfaces and on-prem infrastructure. For example, if the initially breached account is a regular user, the attacker can either try to get that account promoted to global admin, or they can use it to steal other accounts that have, or can have, admin privileges. If your company allows multiple users to logon to the same machine, it then becomes fairly easy for the attacker to figure out how to logon to the shared machine and run a credential harvesting tool like Those creds can then be used to move laterally in the environment, further owning additional accounts until they eventually get to an account that has admin privileges. Another common pivot at this point is to simply create a new account and promote that new account to global admin, thereby giving the attacker the ability to 'hide in plain sight', by having an account that no one else is using, and which likely won't be noticed unless other admins are regularly reviewing the global admin account population.

Preventing the Scenario. Since the account is still at the center of the attack pattern, the same set of protection controls are at play as with a breached account. You should be using multi-factor authentication, especially with administrator accounts or ones with access to sensitive content. Additionally, you can and should review and implement as many of the lateral movement protections described in this document: . Most of these apply to infrastructure protections for your on-prem clients, but they are key in preventing a single breached account from spilling over into multiple breached accounts. Probably the biggest and best protection you can employ is to make your global administrator community small. We typically recommend a minimum of two and a maximum of five for any size of tenant. This keeps the target area small, and makes it harder for an attacker to hide. You should also setup and operate a set of processes to regularly review the community of global admins and their activity.

Detecting the Scenario. Determining whether or not a specific account has been breached will likely rely on anomalous activity that deviates from a well-understood baseline. The good news is that there is a choke-point in this pattern. Any attacker that is trying to get global admin privileges will have to steal an existing global admin account, promote an existing account to global admin, or create a new account and promote it to global admin. Either way, the global admin role is the prize here, and you can focus your detection strategy on  , and by monitoring global admin activities  .

Remediating the Scenario. The stakes for the remediation for a successful elevation of privilege attack are substantially higher than they are for a single breached account. It is also much more difficult since global admin privileges grant the attacker so much power. The basics are the same, however. You need to carefully determine everything that the attacker has done both to your data, and what they have done to further entrench themselves in your tenancy. Look for new accounts, accounts that have had recent changes (such as promotion to tenant admin!), global configuration changes, and every interaction with data from the affected accounts. In most cases, once you have successfully regained control of the breached accounts, you can reverse the changes made, and then determine what, if any, communication steps you need to take if data was exfiltrated or deleted. Pay careful attention to document access control lists (ACLs), mailbox delegate permissions, mailbox forwarding rules, and mail transport rules. Enabling MFA on the affected accounts is an excellent remediation. You will also need to re-secure your infrastructure such as mobile devices and client machines. A breach involving an administrative account is very difficult to fully remediate, since and other artifacts that would indicate their interactions. You should always assume that you missed something, and that you will need to remain vigilant over the long term to rebuild confidence in the effectiveness of your remediation.

Scenario 3: Data Exfiltration

Scenario. In this scenario, an attacker has found a way to move data out of your tenancy. The data can be stolen in any number of ways, including through a breach of an account with access to the data, or through system and infrastructure attacks that give them local or system admin privileges to computers that store the data outside of Office 365. There are a variety of potential motivations here, including the theft of intellectual property, the desire to blackmail you, the intention to sell your data on the black market, or to use the data to further entrench themselves in your systems.. The data can also come in a variety of forms, which further complicates your protection strategy. Email, documents, instant messaging conversations, yammer threads, even enumerating your directory information can be useful to an attacker.

Preventing the Scenario. Strategies you can pursue to keep your data from being illicitly exfiltrated will have to be varied, and will need to focus not only on the data itself, but also on the things needed to access the data, such as accounts. Protecting your service from account breaches and elevation of privilege will be your first step in protecting your data. Next, you should pursue several methods inherent in the data itself:

1. Access Control Lists. Establish standards for who should have access to specific kinds of data, and then create processes to monitor and maintain those access controls. For example, if you have sensitive financials data in a SharePoint site, ensure that the site and document libraries are restricted to only named individuals, for only the minimum privileges they need (read only, for example), and that you regularly review the access control list.
2. External Sharing Policies. Prevent data leakage to external endpoints by configuring your tenancy to restrict certain types of sharing. You can, for example, configure your tenancy to not allow documents to be shared with external people at all. These can be restrictive, so look to strike a balance between your risk and your productivity.
3. Least Privilege. Help frustrated users that are trying to collaborate on content. They will often grant over-broad permissions to documents and document libraries. If you have a security group that has all employees, for example, you might be tempted to grant that group permissions to your team sites just to keep it simple. Resist this urge, and take the time to only grant the required minimum privilege to the smallest group of users that you can. The end user's frustrations will be much higher if their data gets stolen or deleted.
4. Data Classification Schemes. Another key strategy you can employ is to setup and use data classification metadata, particularly with document and SharePoint-hosted data. This requires you to determine a set of risk tiers (High business impact, medium business impact, low business impact, for example), and then require sites and documents to tag data in your systems with the appropriate classification. This allows you to more easily monitor very sensitive data, as well as leverage specific technologies to further protect high business impact data.
5. Data Loss Prevention. The data classification scheme above is most effective when used in combination with the DLP feature in Office 365. This technology allows you to configure rules about how to handle data moving in and out of your tenancy. It can help you prevent sensitive document content from being emailed to external parties, or prevent your users from sending social security numbers in email. See the above linked feature overview for details about how it works and how to implement it.

Detecting the Scenario. Detecting data exfiltration is also a substantial challenge because it is difficult to distinguish normal usage from abnormal usage patterns, especially since the data will most likely be accessed with an account that has the needed privileges. In addition to helping prevent exfiltration, DLP is also a great way to detect leakage.,You can also extend your account breach and elevation of privilege detection scenarios to include baselines around what kinds of data the users normally access. With those detections in place, you can employ two basic detection patterns for exfiltration:

1. First, you can focus your detections on operationalized exfiltration mechanisms like mail forwarding rules or document sharing policies. You should baseline what normal looks like, then implement detections when new forwarding or transport rules are created to move mail to external senders, or if ACL's are modified on a site to grant external parties access.
2. Second, you can look for anomalous interactions with data, especially for large downloads. Attackers often like to 'smash and grab' large amounts of data at a time. You can build detection rules that look for multiple, or mass downloads from repositories.

Remediating the Scenario. Responding to an exfiltrated data breach is the hardest attack scenario to actually fix because in many ways the cat is already out of the bag. Once your data leaves the boundaries of your control, it is very difficult to actually regain control. Your strategy should boil down to two sets of capabilities. You need to be able to clearly identify how the exfiltration happened so that you can stop it, and you have to have a clear, well-exercised plan of how to deal with the impacts of losing control of the data. The former relies on the robust acquisition of activity data so you can determine what changes were made and when, so you can go and reverse those changes. The latter relies on your organization undertaking a process to decide how you measure the impact of data loss, and what the right steps are to manage that impact. This can be a fairly simple strategy of deciding who needs to be notified and involved in handling a data breach, and identifying what kinds of data your organization really cares about.

Scenario 4: Data Deletion

Scenario. In this scenario, an attacker actually deletes your data, usually in a way that makes recovery difficult if not impossible. Some variants of this include ransomware that encrypts your data, and then demands a payment to get the key to decrypt the data. This should amount to data deletion since a successful extraction of payment usually leads to even more targeting by the attacker. Attacker motivations for data deletion include covering the tracks of an attack, attempting to do irreparable harm to your business, or simply trying to spite you or your employees.

Preventing the Scenario. Other than the account breach, elevation of privilege, and other data protection mechanisms you should employ, the core prevention strategy should be to ensure that you have sufficient redundancies built into your data management processes to minimize the impact of the deletion. Data in Office 365 will be backed up and made redundant for maximum availability. However, it is possible for an attacker to delete data from SharePoint sites, then delete it from recycle bins, making it almost impossible to recover. Ensure that you have a process for backing up mission critical data to offline stores, and that you know (and practice!) restoring it.

Detecting the Scenario. If you have a very clearly defined set of data that is absolutely mission critical that you cannot lose under any circumstances, you should build an automated detection to alert you if it is deleted. Most organizations won't have such clear criteria, so a fall back detection of alerting when large amounts of data are being deleted is a viable alternative. Most of the time, impactful data deletions are detected by end users within hours of its removal. Ensure your users know how and to whom to report those incidents.

Remediating the Scenario. Since the data deletion scenario is usually at the end of the kill chain, your first remediation is to ensure you can determine the scope of the breach for all the things needed to actually affect the deletion, such as the user account used, infrastructure leveraged, etc., and that you can remediate those pathways. Restoring your data will be the key step here, and it will rely on the processes established in your protection capability. Bear in mind that in many cases, users will have offline copies of documents that you can leverage to restore service. Also bear in mind that some data, such as OneNote notebooks, are usually stored in the cloud exclusively, aren't often synced to offline sources, and are crucial to team collaboration and communication. Make sure your strategy incorporates coverage for all data types in use.

Scenario 5: Malicious Insider

Scenario. In this scenario, one of your approved users is performing illicit activities in your tenancy. These sorts of attacks can be the most damaging because the user usually knows a lot about your company already and understands very clearly how to maximize the negative impact to you and your data. Motivations for a malicious insider are as varied as can be, but typical ones include disgruntled employees looking for ways to make extra money, to make a splash on their way out of the company, or to simply spite you. The range of illicit activities that can be performed fall all along the kill chain scenarios as well. The insider might take steps to ensure long term access by building in backdoor accounts or go straight to exfiltration or deleting sensitive data. In the kill chain diagram above the malicious insider scenario spans all the other steps because the attacker can essentially shortcut their attack to any downstream step using their normal access to your tenancy. Users with administrative rights are the most dangerous.

Preventing the Scenario. As with the other scenarios in the kill chain, you will need to ensure your accounts are secure, your privileges are well managed, and that your data is well protected. Of course, the attacker in this case has usually already achieved all the required prerequisites to execute any attack, so the focus on prevention should turn to ensuring you have processes that allow you to discern motive. Make sure you have ways to identify disgruntled or unhappy employees, and ways to protect yourself from short-term vendor and contingent staff. If you think there are specific roles (such as administrators) that are susceptible to working conditions that can lead to disgruntlement, take steps to protect yourself and your data. Awareness, in these cases, is really half the battle. One quality bar you can establish is that sensitive data should require collusion by more than one employee in order for the data to be breached.

Detecting the Scenario. Your detections for this scenario are really no different than what you would put in place for the other scenarios. The core difference here is that you must assume breach, and ensure that you aren't blind to the possibility that an attacker might be one of your own users. Basically, you don't need a detection mechanism for a malicious insider, you need to make sure your breached account, elevation of privilege, data exfiltration, data deletion detections include malicious insider considerations.

Remediating the Scenario. Recovering from a malicious insider attack is among the more difficult exercises you will have to perform. The insider will have lots of normal activity alongside the malicious actions. Scoping the real extent of the breach is the hardest part of the remediation effort. Once you have all the illicit activity identified, the remediation actions themselves are exactly what you would do in the other threat scenarios.

Conclusion

Adopting cloud service technologies like Office 365 is an effective way to increase your company’s productivity, and reduce costs. When you are trying to decide if you should make the jump to the cloud, or if you are already there and are trying to address concerns about your risk, the above threat scenarios cover the majority of threat categories you will have to address. Attackers tend to follow the path of least resistance, so adopting a robust protect, detect, and recover strategy across each of these scenarios in the kill-chain will give you reasonably good answers about how much risk you are mitigating.