Despite the presence of sophisticated security solutions, often organisations struggle to answer the most basic security questions – who, what, where and when (the 4 W’s). This is particularly pertinent when it comes to the most critical IT systems such as Active Directory, SQL Server, Exchange Server, and SharePoint. Trying to answer these 4 questions using native audit logs alone can be challenging.
The importance of the 4 W’s
If you know the who, what, when, and where of all the changes in your IT infrastructure, it is very unlikely that critical data will be misused without you knowing about it. That is why companies conduct regular audits of Active Directory, SQL Server, Exchange Server, and SharePoint. Regular auditing also helps to meet regulatory compliances like FISMA, GLBA, HIPAA, PCI, SAS, and SOX.
Is Native Auditing Enough?
Microsoft has already incorporated some advanced auditing features into Active Directory (in Windows Server), SQL Server, Exchange Server and SharePoint. They come free as part of the product and help administrators meet their auditing requirements without the use of third-party solutions. However, there are number of issues with this approach – excessive log noise, duplicate logs and the reactive nature.
1. Active Directory Auditing
The auditing features of Windows Server requires AD administrators to enable auditing and configure the SACL of objects that are to be audited. Auditing events created in the Windows security logs can be accessed through the event viewer. It involves three steps:
- Enabling auditing for the domain
- Configuring the object level settings
- Finding the event in the Windows security logs
2. Exchange Server Auditing
Exchange Server auditing ensures that no critical information in emails falls into unwanted hands without you knowing about it. This is how it is done:
- Configure administrator audit logging/mailbox audit logging
- Access audit reports in web-based Exchange control panel (ECP) or Exchange Admin center (EAC)
Exchange auditing involves auditing the activities performed by Exchange administrators (exports, copying, changes to policies, security configuration and access controls) and users (non-owner mailbox accessing and email deletions). The audit logs for administrators are stored in the audit mailbox and the logs for other users are stored in their mailboxes. These logs are accessible through ECP or EAC.
3. SQL Server Auditing
The auditing capabilities of MS SQL Server help businesses protect their MS SQL Server information. They can be utilised by enabling the inbuilt auditing feature by following these steps (executed using SQL Management Studio or Transact-SQL):
- Create a server audit
- Create and enable server audit specification/database audit specification
- Enable the audit and view audit logs using Windows Event Viewer/Log File Viewer/fn_get_audit_file function
This feature helps administrators track users, objects and user actions. Within which you can also track security operations, database operations, maintenance of objects and use of important Transact SQL table commands. However, it is difficult to manage and interpret the complex SQL audit information from the reports submitted through native auditing.
4. SharePoint Auditing
Given the value of data to the modern business, auditing a platform like SharePoint is essential. There are some inbuilt auditing features on the platform but they are limited. To set it up follow these steps:
- Enable Audit logging
- Configure audit settings for the site collection
- View audit log reports
The auditing feature helps you keep track of:
One of its main limitations is that auditing can be performed at site collection level only, not at farm level. You will not get the user/object names using native processes (only ID codes and GUID are available). The reports are stored in the SharePoint document library as Excel files.
Major drawbacks of native auditing
In a complex IT environment there are certain limitations to auditing natively. The auditor needs to be particularly adept at using the features of Windows Server, SQL Server, Exchange, and SharePoint to get all the required information. All these components have different features, interfaces and audit log storage mechanisms.
One of the problems with native auditing is that all the different reports are stored in different locations. Even if you consolidate them into a single place you may find it difficult to correlate the events and establish connections between them. Essentially it becomes a bit of a jig-saw puzzle. The major challenge is that it is reactive, you can’t create advanced alerts, it’s hard to get detailed reports and requires time and patience to achieve any meaningful results.
Is there a better way?
You can probably get what you need from native auditing with time and patience, which is often not something that IT have in abundance. The main issues you have are that it is reactive, noisy, inefficient, prone to error and it doesn’t enable you to answer the most critical questions quickly.
There are a number of third-party solutions, such as Data Security Platform, that are easy to install and provide a single click means of getting alerts and reports on the 4 W’s of changes made to any part of your IT environment – all without the headache.
Native tools vs Lepide Data Security Platform
|IT Systems||Native Auditing (Different features for different components)||Lepide Data Security Platform (Single solution for all the components)|