This is the continuation of the series on leveraging Centrify to implement SANS Critical Security controls -
Section 12: "Controlled use of Administrative Privileges".
| CSC 12-3 | Configure all administrative
passwords to be complex and contain letters, numbers, and special
characters intermixed, and with no dictionary words present in the
password. Pass phrases containing multiple dictionary words, along with
special characters, are acceptable if they are of a reasonable length. |
| CSC 12-5 | Ensure that all service accounts
have long and difficult-to-guess passwords that are changed on a
periodic basis, as is done for traditional user and administrative
passwords. |
| CSC 12-8 | Through policy and user awareness, require that administrators establish unique, different passwords for their administrative and non-administrative accounts. Each person requiring administrative access should be given his/her own separate account. Users should only use the Windows "administrator" or UNIX "root" accounts in emergency situations. Domain administration accounts should be used when required for system administration instead of local administrative accounts. |
| CSC 12-9 | Configure operating systems so that passwords cannot be re-used within a timeframe of six months. |
Why should you do this?
Because the password policy for admin accounts should be a step-up from regular users given that they hold the keys to the kingdom.
What is the typical approach?
On Unix: cracklib PAM module.
On Windows: group policy.
What is the real challenge for organizations?
Human nature - sysadmins love their root or administrator accounts given their inherent mistrust in software, and unfortunately vendors promote fragmentation.
Centrify's enhancers:
It's the solution that can accomplish this with true RBAC (allowing the administrative accounts to be put away) plus the tight AD integration with Group Policies (and support for
fine-grained password policies). In addition, Centrify's resiliency truly makes sure that the root or administrator account are only needed in emergency situations.
In UNIX - privilege elevation using Centrify-enhanced sudo (no sudoers) - DirectAuthorize (DZ)
In Windows - privilege elevation with the Centrify agent for Windows (DZ Win)
| CSC 12-4 | Before deploying any new devices
in a networked environment, change all default passwords for
applications, operating systems, routers, firewalls, wireless access
points, and other systems to have values consistent with
administration-level accounts. |
Why should you do this?
Anyone that has had a Linksys router knows the answer to this. In UNIX/Linux, there's too much reliance on the root account or the switch user command. Local administrator in Windows is treasured by Windows admins.
What is the typical approach?
Unfortunately, in a lot of environments there's too much sharing of these accounts. TACACs, RADIUS and password vaults help with network appliances.
What is the real challenge for organizations?
Human nature. A Unified approach for these accounts like a password vault is typically the right solution.
Centrify's enhancers:
Due to the true RBAC and privilege elevation methods employed by Centrify, organizations can decrease their costs in password vault user licensing costs, by just leveraging it for non-human admin accounts, while the rest of the population uses RBAC. The end-to-end nature and
resilience mechanisms, makes it more efficient to align with regulatory requirements without a single point of failure. In UNIX, single-user-mode or Windows safe mode without network will be the only instances in which these accounts are needed.
No need to check-out the keys to the kingdom each time the root, or administrator accounts are needed.
- Tied to your identity infrastructure (Active Directory)
- True Role-based access
- Minimal process impact
- Increased accountability using the native tools (syslog/event viewer)
- Extensible to session capture and replay
Tried and true AAA.
| CSC 12-6 | Passwords should be hashed or
encrypted in storage. Passwords that are hashed should be salted and
follow guidance provided in NIST SP 800-132 or similar guidance. Files
containing these encrypted or hashed passwords required for systems to
authenticate users should be readable only with super-user privileges. |
Why should you do this?
There was a time in the security discipline in which encryption was thought to be the solution; time and different attack vectors have proven this to be wrong; however, encryption in transit and encryption at rest are a must. There's an arms race going on because although algorithms are strong, Moore's law, virtualization and well-funded and motivated agents are lurking.
What is the typical approach?
Rely on the OS, Directory or the appliance. Fortunately Microsoft has this
very-well documented.
What is the real challenge for organizations?
Human nature, again It doesn't matter how hard your encryption is if credentials are shared or clear-text passwords are used in scripts or other facilities.
Centrify's enhancers:
However, the bullets above are just marketing speak if we don't back-it up with examples:
- Kerberized tools: install.sh adjoin, adleave, adkeytab, adcert, dzdo + more are all Kerberized, which means no need to actually store passwords. The Hadoop and MongoDB examples illustrate practical use.
- Microsoft CA PKI client: Use Certificates in your Unix, Linux, Mac systems.
- Extend it to your HTTP, Java, SAP or DB2 needs.
Why even have the problem when you can completely avoid it?
