Reporting vs Complying vs Securing
Many IT terms, concepts, and goals are applied incorrectly. Here, we’ll highlight and clarify three of the major ones.
These terms are not specific to any one operating system, platform, or environment. I will, however, give examples regarding Microsoft Active Directory (AD) since it is my area of expertise and experience. Extrapolate the concepts for any other environment, and they will apply just as well.
In the world of AD, reporting is a task that most administrators hate for two reasons. First, generating a report is boring, takes time, and does not advance their agenda. Second, a report can expose an issue (setting, misconfiguration, etc.) that makes the admin look bad. Managers and other departments typically want reports to illustrate something that is not easily seen through the interface. Reports might include:
- User accounts created in the past six months
- Disabled user accounts
- User accounts that have not logged in for six months
- Unlinked Group Policy Objects (GPOs)
- Members of the Domain Admins group
Reports can be security-related, but often they are not tied to a security issue or improving the overall security of the environment.
Meeting compliance regulations is usually all about generating reports. The reason I have distinguished reporting from complying is that they are different functions, using similar actions. Complying is the process of meeting certain requirements based on a compliance regulation and auditors’ interpretation of that regulation.
Most compliance is tied to security in some way but does not ensure that the environment will be any more secure after the compliance is met. Some compliance reports and key aspects might include:
- Users that are not required to change their password
- Password policy settings
- Members of the built-in privileged groups (Domain Admins, Enterprise Admins, etc.)
- Open ports on domain controllers
- Domains in each forest and list of forests
- List of GPOs
Most compliance is created by a non-admin, non-security, non-technical professional. Many of the requested reports are based on a misinterpretation of the core security principle that is being reviewed.
The purpose of securing is to actively configure settings and structural components to the best possible security state. Unlike compliance and reporting, securing is not looking at what others want out of security, but what is required to create a secure environment.
The list of security areas for Active Directory is shockingly extensive, as it goes well beyond what any compliance regulation or report list includes. Again, securing Active Directory requires that misconfigurations and attack paths be corrected.
Here are a few concepts to consider when thinking about securing Active Directory:
- Most AD environments were installed years ago and have never been correctly secured.
- SIEM solutions and AD monitoring tools do not indicate what is currently insecure.
- SIEM solutions and AD monitoring tools only indicate, alert, and report actions that have been done already. (By this time it is too late, the attack is complete).
- The auditing, monitoring, compliance, or security solution should not open an attack path itself! Therefore, any agent-based solution or solution requiring privileges fails this criteria.
- Deep and complex areas of the environment need to be considered (user attributes, privileged user attributes, actions that are only seen in an attack but never logged, etc.). To give you a better idea, see this list of security setting triggers: https://alsid.com/indicator-exposures-reference
Alsid is based on four key security pillars, each essential to securing any Active Directory environment:
- Fixing existing weaknesses
- Real-time detection of new weaknesses
- Detection of attacks
- Deep investigation: post attack