Because of Active Directory's role as the basis for pretty much all of your on-prem, cloud-based, and Office 365 security, it's critical to maintain a high level of Active Directory security. Should its security become compromised, the impact of that breach no longer ends on-premises; every cloud application – as well as all of Office 365 – becomes susceptible to further compromise.
In Conversational Hybrid AD Security, the "parent" book to this mini-edition book, I pointed out that your hybrid-AD environment is in a constant state of flux – with changes being made on a daily basis.
Should those changes turn out to be inappropriate and cause harm to the business or, at a minimum, decrease your organization's security stance, it's necessary to have a sense of what was changed, and how those changes impact the business.
In larger organizations, there are a lot of hands in the AD soup. Many changes made aren't documented. But they should be. Auditing is a solid foundation for establishing security.
Take the real-world example of an organization where suddenly one of their on-prem Exchange servers stopped functioning properly.
Once aware of the malfunction, IT did the normal things – check the services, hardware, connectivity, error logs, etc. Everything looked good. Literally zero indicators on the box why it wasn't providing services. No changes to the Exchange environment existed in the audit logs that would cause a problem.
So, they expanded their search, and asked if anyone made any changes at all to anything in the last 10 minutes since the problem started. It turned out an AD admin was modifying the subnets within an AD site and reconfigured the subnet just so; the result was that the Exchange server was logically isolated on its own subnet, and had no DC to communicate with.
While this is an example that lies outside of the security focus, it does demonstrate the need to be able to identify changes across multiple systems, platforms, and environments.
And, while auditing your hybrid AD is important to help you understand what's changed in the environment, what's also needed is an ability to understand the "why" behind those changes.
A single change that turns up in the audit logs may only be the tip of the iceberg. Let's say a user with permissions to manage the membership of a group that has access to intellectual property abnormally begins to add multiple users to the group within a short period of time. With Directory Service auditing enabled, you can surely see these membership changes. But, what's more critical is understanding what else was done with those permissions.
Suppose it was an external attacker who compromised the account managing the group, and they added multiple users they created within AD (as a means of establishing persistent access to the intellectual property). You'd need to understand:
You see, maintaining AD security is as much about what's done with the security, as it is maintaining the security itself. What's required is an ability to do two things:
In many ways, IT is like the police – you're part detective, part clean-up crew. You need to understand what's happened, and then take action to restore the peace. Thus, the need to both investigate and recover.
Let's take a look at how both are necessary as part of your hybrid AD security strategy.
The term investigation automatically brings up thoughts of detectives trying to solve a crime. There are some solid parallels here to investigating the details behind changes in AD. The goal of investigation is 2-fold.
First, you use investigation to determine the root cause of an issue. Work my external attack scenario backwards and assume the indicator of a problem was that an unknown user accessed intellectual property. You'd need to work that backwards to "how did they get access?", and then "who added them to the group?" and even "who created the account?" – all culminating in a root cause – the misuse of an account with privileges.
Next, investigation helps to establish context around the action in question. An action on its own – such as just the adding of a user to the intellectual property group, or the accessing of one of the files containing intellectual property – doesn't give the full picture. It's only in looking at the activity before, during and after the action in question that you get context.
Despite the focus of this book being on securing your hybrid AD, to meet both investigation goals, you need visibility into much more detail than just AD changes (otherwise, this book would simply be the Detection & Alerting book I mentioned previously).
So, what sources of data does investigation require?
This being a book on AD security, you obviously start with AD activity. But you should consider including activity data from as many other systems, endpoints, services, and applications as possible – in addition to AD. This should include (when applicable) both change and access data. For example, if you were to include activity from a file server, you'd want to have visibility into when someone, say, opens (accesses) a file, as well as changes the files content or permissions.
When actions are performed, the next logical question often is "How are they being granted permissions to do that?" So, many investigations require understanding how the environment is configured. This can include the current state of security, or the configuration of a system, application, or service, or even AD itself.
In many instances, it's necessary to look at previous versions of both security and configuration settings to understand what the state either did or should look like. This provides context around whether the current state is sanctioned.
All this data may be used in just about any order – depending on how the unsanctioned action is found out, you may find yourself starting with the current state, followed by historical, and finally activity. There is no right or wrong path to take; the order will follow the investigator's own logic.
While this book is focused on the detail provided by your hybrid AD, it's important to highlight the value of data (whether historical, state-based, or activity-related) outside of AD/AzureAD. Threatening actions can take place within Office 365 (e.g., the sending of a malicious email via a compromised account), OneDrive (e.g., the placement of a malicious file to be used as part of a phishing scam), SharePoint, and even within Azure itself – the creation of a VM to perform unsanctioned cryptocurrency mining, for example – can all provide context around what threat actions have transpired.
Once you understand the scope of what's transpired, there may be the need to put things back the way they were.
In many cases, detailed investigations can uncover changes in AD that require recovery. This can involve anything from a single object all the way up to an entire forest.
While my example above is one founded in malicious intent, changes can be unknowingly made, and can even be made by 3rd party ADintegrated applications and systems.
The concept of recovery in the context of an investigation may seem rather simple – just recover whatever was changed. But it's not that simple. Recovery can cause even more problems if not properly planned.
So, what kinds of recovery are needed, and what kind of planning does each require?
Changes to AD sometime only impact AD. But in the case of a hybrid AD environment, changes made on-prem or in the cloud can have a ripple effect of actions and access that extends throughout the entire environment, including onprem AD, Azure AD, Office 365, and other applications and services that rely on AD.
Internal IT organizations need visibility into those potentially affected systems and applications, to investigate and truly understand what actions are taken across the environment, in order to determine how to put AD – and the extended environment – back into a place of security.
You only can have a true understanding of whether changes to AD and other systems and applications are improper, and come with negative repercussions, if you have visibility across all of AD, and the systems and applications it touches.
Quest offers solutions to empower IT organizations to perform investigations, and any level of recovery deemed necessary to restore AD to a place of security.
Investigations rely on having all three data types mentioned in this book.
Activity Data is made available via Quest InTrust and Quest Change Auditor. These solutions consolidate and make available privileged user and machine changes across your Windows environment and alert in real-time allowing for speedy investigation and insight.
State-Based Data is accessible via Quest Enterprise Reporter, which provides access to the current state of critical IT assets such as user, computer and group information, direct and nested group memberships, OU and file/folder permissions, ownership and more to empower IT teams to comprehensively understand their state of security.
Historical Data is provided using Quest Recovery Manager for AD which lets you view historical configurations of your respective backups for review and comparison.
Rather than digging into data from a number of different systems and devices, Quest has IT Security Search – a powerful interactive search engine that pulls together the data found in each solution above, making investigations a fast and simple task.
Once the scope of recovery is determined, Quest Recovery Manager – Forest Edition (which includes Active Directory virtual lab) can be used to simulate and recover everything from a single attribute up to the entire forest with the same level of ease. For hybrid environments, you can integrate Recovery Manager with On Demand Recovery. This solution provides fast, secure and scalable backup and recovery of Azure AD and Office 365 users, attributes, groups and group membership.