Business Intelligence (BI), data analytics and security reports
In today’s highly networked market where even the smallest business can have global reach, it is increasingly important to manage, monitor and analyze who is accessing and is using your computer resources. Active Directory is more than a directory service. It is the tool that allows you to manage and define security policies for who can assess your computer resources.
Active Directory holds information on your users, computer resources, and security policies. Deployments can vary from a small business that has a handful of users and computers to large multinational enterprises with thousands of users spread across several global locations. As such, the Active Directory’s database records can be on a single computer or spread across several server farms.
The data that is contained in Active Directory is an essential part of your security data analytics. Active Directory provides tools for administrators to view the directory’s database, to analyze the impact of applying security policies and to log all of the events. However, it is not a data analysis and reporting tool. Most companies therefore implement an analysis and reporting tool to complement their Active Directory deployment. These tools can range from free add-ons that help you filter and generate SQL queries to highly complex tools that can run what if analysis and generate hundreds of different reports. This article is focused on helping you decide which reports are essential to you.
The golden rules of report generation
Before defining the essential reports, it is worth spending a few moments to define what constitutes a good security report. Regardless of the size of your Active Directory deployment there are three golden rules for creating good security reports. Reports should contain information that is comprehensible and accurate. Reports should tell you if the system is working as your business needs it to work. Reports should provide insights into what is happening such that you can decide on a course of action.
By focusing on reports that are accurate, relevant and actionable, you will be able to sort through the hundreds of Active Directory security reports available to find the ones you need to manage your business.
Is your documentation up to date?
Active Directory allows you to set up Group Policies to manage user access and computer resources. Security settings are defined in Group Policies, These security settings define how users are authenticated on the network and which computer resources they are permitted to use. You can view almost all of your security settings through the Group Policy Management Console (GPMC).
Securing your computer resources requires you not only to apply effective Group Policies, but it also requires you to make sure that employees and other users of the network understand the security policies and the importance of complying with these policies. It is therefore essential that Group Policies are documented and shared with users. Therefore the first report that you should generate is a list of all your Group Policies.
Active Directory allows you to generate a Hypertext Markup Language (HTML) report that shows all of the Group Policy Object (GPO) settings. To create this report in Windows Server 2008 you should go to the Group Policy Management console, select the Domain and the Group Policy Object you are interested in. The report is generated when you select the Settings tab. Figure 1 below provides an example of this report. To print this report simply right click in the view window and select print.
Now that you have a list of your Global Policies it is time to apply the golden rules. Ask yourself the questions, are these the right Global Policies for my business and what do I need to change? If you need to modify or add new GPOs this can be a complex and somewhat daunting process as it can be difficult to determine which users and computers will or will not be impacted by a specific GPO. Active Directory includes a Group Policy Modeling capability that you can use to run what-if analysis.
Have you reviewed your administrator accounts?
It is important to periodically review your administrator accounts. As the name suggests, these are the accounts used by administrator to updates to Active Directory. You need to know who has access to change things on Active Directory. The delegation of tasks that each administrator can do is core to your organizational security. Failure to give the appropriate access to administrators is a more significant security risk than any other potential Active Directory vulnerability.
You need a report that shows the administrative accounts and what privileges they have. In other words who can do what? Figure 2 shows the permissions for the default Administrators account. You can access this information by selecting the Active Directory Users and Computers, selecting advanced features in the view menu, and then right clicking properties and the security tab. Although a preferred approach would be to use a reporting tool to generate a report that allows you to compare and contrast permissions allocated to different administrators.
When applying the golden rules a great question to ask is are you conforming to best practices in setting up Administrative Accounts? If no, what changes can you make to come closer to these best practices? For example, a best practice for these accounts is to set a Password Policy that require a longer and more complex password to make it more difficult for a hacker to break this password.
Are changes conforming to your design?
Prior to implementing Active Directory, a best practice is to create a design document that defines the rules for how you will be implementing Active Directory. These rules should include a naming standard for users and computers, a user password policy, and a list of who can create, delete, and manage groups. In addition to guidelines for how domain local, global, and universal groups should be used. Failure to create a design document or to adhere to the design guidelines can make it impossible to implement new policies as the organization evolves and the business needs change.
It is important to ensure that this design document is still being followed. For example you may wish to check whether the naming standards are being followed and review newly formed groups to ensure they conform to the written guidelines. These types of reports tend to be quite complex. For example let’s say you choose a user naming standard last name, followed by a period and then the first name. To identify user names that do not conform to your naming standard you could search for names missing the period. This is not an easy report script to write.
Ideally your reporting tool should enable you to easily run these investigative reports.
Are you watching who is accessing your network?
Authenticating a user’s access to the network and computer resources is at the heart of any Active Directory system. Ideally you should be looking at who is assessing your network resources on a daily basis. Looking at statistics on legitimate user behaviors and potential hackers is an important part of protecting your system.
There are two main account security policies, Password Policy and Account Lockout Policy. Once these policies are set they are not typically changed unless your business needs or security risk assessment changes. Figure 3 shows a typical user password policy.
Having made decisions about your Password and Account Lockout Policies, you can now detect abnormal behavior that could indicate that your users are experiencing problems with your security policies or that your network is under attack. Ideally you should have a reporting tool that allows you to rapidly identify data anomalies in your Active Directory system. Examples of data anomalies are a high number of authentication attempts on a specific user accounts or a high number of changed password messages.
What are your logs telling you?
Security logs provide a history of events. You can configure your security logs to capture Global Policy related events by defining the Audit Policy. Events can include system events such as computer shut downs, policy changes, log-on and account management changes.
When you first deploy Active Directory, auditing is turned off. Setting the Audit Policy requires you to select the events that you wish to track. This can be a most challenging decision. If you keep too much data, it will result in significant server overhead and it can make it more difficult for you to quickly see what is happening. If you keep too little data you may not be able to achieve your security goals and meet your regulatory compliance requirements.
Figure 4 provides an example of setting an Audit Policy. In this example, the IT staff wanted to be able to detect if the system suffered a dictionary attack, so they set the audit policy to record the number of failed log on attempts but they are not recording the successful log on attempts.
Remember that security logs are essential for troubleshooting, but they are also invaluable for analyzing changes to your system over time and investigating security breaches. You also need to decide how long you plan to keep the security logs. You should configure the size of your security logs based on the expected number of logged events over the period you plan to keep the log.
Are you ready to define your security reporting needs?
Creating reports is an essential part of managing and securing Active Directory. There are several things that do not show up during your day-to-day monitoring activities. Generating accurate, meaningful and actionable reports enables you to keep your documentation up to date, to analyze and see data in a different way over a longer period of time, and to identify patterns.
Arm yourself with good security reports and you can be the unspoken hero that takes action before problems actually manifest!