• Home
  • Monitoring in Windows Active Directory Part I

Monitoring in Windows Active Directory Part I

  • 12 Feb 2013 12:26 PM | Paul Braxton (Administrator)
    Overview of the entire process

    1. Information gathering
    2. Scoped risk assessment 
    3. Event identification
    4. Event profiling
    5. Data enrichment
    6. Alert selection
    7. Operationalization
    8. Performance metrics
    9. Probability analysis

    This article will cover the Information gathering and scoped risk assessment.

    Information gathering

    It's common for authentication monitoring to be driven by  SIEM solution default rules. This is understandable because a lot of money is spent on these solutions and part of the value is the built in ability to parse, normalize, correlate and alert on common log sources such as Active Directory (AD). Depending on the SIEM system it may already be doing a great job for you but I think it is important to step back and start outside the SIEM tool so you may understand any gaps that might exist. The first things to consider is how your organization uses AD. AD is commonly used to authentication users to their desktops, Exchange, intranet web sites and shared network drives. Also seek out what parts of the business it covers. How many domains exist and do any have a special purpose? For example some organizations may separate domains by business line, others may only have a company wide domain. There may also be special purpose domains for sensitive applications. These are things your SIEM can't know out of the box and can be used to provide valuable context around your monitoring procedures.

    Learn the technical specifics of your AD deployment. The version of the software dictates what log messages are created and the format of those messages. How many Domain Controllers (DC) are there and where do they live? This will impact your collection infrastructure, where collectors are placed and let you discover possible hurdles such as firewalls separating your collectors from remote DCs. What is the current auditing policy? The auditing policy usually configured in Global Policy dictates what types of events get logged, often administrators turn off auditing because of lack of disk space or a perceived performance hit. There will always be a balance to strike because if logging is too verbose your SIEM will be overwhelmed with useless data. Too little auditing will leave out important security messages. Later in this article I will discuss how to strike that balance. How verbose can AD auditing be? Once we turned on all auditing for a single DC and sent all events to the SIEM. Overnight the single DC filled the 140GB disk of the SIEM system taking the system down! Another caution is prior to Windows 2003 SIEM products relied on collection methods that could impact performance on the Domain Controllers. These issues have been resolved with better indexing but it would be best to coordinate testing especially with AD administrators that remember the SIEM knocking over their DC 10 years ago. Your SIEM should supply several ways to get logs from AD and one of the options should work well in your environment.

    Scoped risk assessment

    The first thing to think about when developing a monitoring program around authentication logs is what risks are associated with authentication and authorization. While risk assessment can be a long arduous process when scoped to the entire organization the goal here is to scope risk assessment related to authentication and authorization. Don't get buried in the weeds trying to apply a formal risk assessment process for this purpose. Think of this a scoped risk assessment brainstorm. All organizations have common risks. There is risk that employee accounts are compromised by key logging trojans or that a former employee's accounts remain active and get misused by malicious insiders. Beyond common risks look at your specific organizational context when developing your monitoring program. For example, if your business has call center representatives plan on implementing monitoring specifically around risks associated with that population of users. It's easy to get overwhelmed with the possibilities so just start with the common risks and the highest risk users and continue to refine SIEM use cases on a regular basis. Another source of risk is regulatory compliance. Know what regulations apply to your organization and how monitoring can help you stay compliant. There may be an existing risk assessment process so leverage documentation from those processes.

    Here are some risks related to authentication and to a lesser extent authorization to consider:

    Account compromise
    • Key-logging trojan
    • Social engineering
    • Shoulder surfing
    • Account sharing
    • Uncorrelated account usage

    Privileged user (administrator) abuse
    • Unauthorized administration
    • Activity hiding
    • Service account use

    Malicious insider
    • Application browsing
    • Service browsing

    Failed administrative procedures
    • Termed user accounts active
    • Excessive access after role changes
    • Dormant users

    User availability
    • Persistent lock-out

    Specific organizational risks example: Contract developers working on a new online retail application

    Often new business initiatives equate to new applications. Consider a scenario where your company is developing a completely new retailing web site. Contractors working off-site may be used to augment staff in order to meet project deadlines. These users may be given remote network access to development resources. Consider the risk associated with these users. For example, administrators may be tempted to give the contractors access to resources beyond their needs. These users may also need to have access to service or database accounts to do their work however this access could be abused by connecting to databases outside the scope of their project.
    • Abuse of service accounts
    • Use of data or other resources out of project scope

    AD logs will prove to be a significant data source for your SIEM. A careful approach will ensure good security monitoring tailored to the risk profile of your organization. The first steps is to gather information about your organization's AD infrastructure and how it's used. The next step is to do a scoped risk assessment brainstorm on what risks are associated with authentication and authorization. Once you have risks identified and listed you will be ready for the event identification step in the process.

    In Part II  Event Identification and Profiling I will discuss how to identify the events related to the identified risks and how to profile events so that you ensure successful monitoring while striking a balance between event volume and risk mitigation.

Association of Security Data Scientist

Powered by Wild Apricot. Try our all-in-one platform for easy membership management