![Nobu 9.20.21 - Copy.jpg](https://files.peakd.com/file/peakd-hive/kotenoke/23ynapajdhRfenaT1H4kQ4kkaHTrd1cGGsS8UuFwjiXRyaL9fppH5e2teYrZFhy2ARk7C.jpg)

Hello Everyone,

So far I've written primarily about Splinterlands but today I've decided I'd like to start a technical How-To series as it relates to IT security and auditing. This series and guide is intended for those of you just starting out in IT operations, IT compliance, and IT audit. We will be focusing on IT General Controls which generally cover Authentication, Authorization, and Change Management.

To start this series off we are going to be talking about Windows because who isn't familiar with that.

The risks associated with Windows and AD from a compliance and audit standpoint can be tied to the areas we discussed previously, the risk of inappropriately assigned access, inappropriately configured systems, and poor change management. In a mature environment these risks are formally mapped out against identified IT controls and tested internally by management, internal audit, and external audit.

At the enterprise level, Windows is reliant on Active Directory (AD) which is a hierarchical structure, much like a database, that stores information about objects such as users on the network. The ability of AD to store this information allows Windows administrators to easily secure their environment by configuring and restricting the system and areas within the network to specific objects. 

**Privileged users and groups**
Windows environments are shipped with a built-in privileged administrator account with the security ID (SID) 500. This ID is setup under the name 'Administrator' and effectively has all of the keys to the kingdom and should be priority 1 to secure. Best practice is to rename this ID and configure it to require smart card or other physical auth token for login. In addition, Windows has some default privileged groups, noted below, which provide critical access to configurations and user maintenance. These groups and the users within should be monitored regularly to ensure appropriateness.
• Administrators
• Domain Admins
• Enterprise Admins
• Group Policy Admins
• Schema Admins
• Account Operators
• Server Operators

![Group-Policy-has-overwritten-our-Domain-Admins-group-members-600x401.png](https://files.peakd.com/file/peakd-hive/kotenoke/23xf7Tx5p1gnyjK4s2onWeTAdzpzJAGfAqv5bZe2acKpkprTskTXEgGrhUf3xUPKaWh54.png)
*image property of Microsoft Geek*

In addition to the root domain controller, enterprise networks typically are used to connect all of the servers that run company applications, databases, and tools. Each of these individual servers also contain privileged users and should be monitored and configured in the same manner as the root level. That said, there are some differences. The Enterprise Admins and Schema Admins groups will only exist at the root domain. Each child domain has a set of the remaining groups and each child server more specifically would be managed by the Administrators group. In a mature environment, these groups and users would be reviewed on a periodic basis according to corporate policy.

**Inappropriate configurations**
One of the first areas of concern after ensuring access privileges are assigned properly is ensuring that the system itself is hardened, or difficult to get into. As simple as it sounds, authentication configurations such as basic password restrictions are the cornerstone to achieve this. Within Windows this is easily accomplished by setting a Default Domain Policy via a Group Policy Object. This policy should be set at minimum to corporate policy and the following attributes should be considered:
• Minimum Password Length
• Maximum Password Age (in Days)
• Minimum Password Age (in Days)
• Enforce Password History 
• Password Complexity
• Lockout Threshold 
• Lockout Duration
• Reset Lockout Counter (in Minutes)
Although these settings 'can' be set globally, local servers can also block inheritance of the policy so these same settings should be enforced and checked locally within servers as well.


![AD-Default-Domain-Password-Policy.png](https://files.peakd.com/file/peakd-hive/kotenoke/23wXLgX4fjmVM4ZZw3wpy3Ykm39fTKMugFf9mMp3b1vZddCyB2ytuVFLnEdHaQbwf4QRX.png)
*image property of Specops Software*

Deploying multi-factor authentication using tools such as RSA, Google Auth, etc is generally the next step and vastly hardens any system.

**Change Management**

![download.png](https://files.peakd.com/file/peakd-hive/kotenoke/48Fi6mFbSMUQDg9jbS7hVC9eStJUaGvwPUF8t5Xqau7EsSS8GL245uyr7XwnsxRrfA.png)
*image owned by Microsoft*

Deploying changes is actually one of the easier versions of change control that you will find in IT Ops as it is primarily done by Windows themselves. Generally on "Patch Tuesday" Windows will deploy patches and updates to their security channel for download by their clients. These changes are Windows developed and tested which reduces the burden on in-house IT teams. Generally, when designing or auditing a change control, part of the core evidence that should be maintained is documentation showing successful testing. As Windows performs this step, all that is typically required of IT is ensuring that each patch is approved by appropriate management before being deployed. However, it is still best practice for server teams to test out new patches in a non production environment prior to production to see if the patch interferes with any custom configurations or applications running in the environment. Most importantly however, Microsoft will occasionally release critical patches which should be installed as soon as possible. These are most often to fix known, easily exploitable, vulnerabilities. As such, it is also important to develop a process for IT to push these critical patches before obtaining approval. Review after the fact is a common reasonable approach. To start compare patches currently installed to the Windows listing found [here](http://www.microsoft.com/technet/security/current.aspx).

I hope by reading this you have a general idea of what types of security controls your company has in place to address these areas or have an idea of how to take care of them if not. Its always better to fix an issue before an auditor, regulator, or worse threat actor find them. Next week I will discuss the basics of securing Linux.

Regards,

Your friendly internet IT guy