Security Corner: How your Centrify Deployment Affects your Existing Security Policies, Procedures and Standards

Background

Identity and Access Management capabilities fall under the umbrella of Information Security therefore any technical implementation (such as Centrify for Servers) needs to align with IT Security principles and procedures.  In the Security corner, we discuss topics related to information security and how they relate to these capabilities.

Blog Objectives Refresher

As per our first post, this blog's mission is to:

• Provide general information, discuss use cases and provide step-by-step guides
• Minimize or eliminate IT capability fragmentation
• Promote operational efficiency and process reuse
• Discuss problems from the business and technical perspective
• Project & Capability Management (Plan-Do-Check-Adjust)
• Promote proper security practices

That is quite a lot to balance, but hopefully the topics in this section can focus on the security side of the problem.

The Security Process

In our first post we outlined that all security measures should flow from a sensible risk assessment exercise. Depending on the nature of the business, organizations may protect from (in no particular order):

• Financial loss (mainly in for-profit organizations - here's a current topic)
• Reputation hits  (this affects for-profit organizations, but less and less - e.g. was there any fallout from the TJX data-breach?  I'm sure that management blunders, cost more to non-profits)
  Note:  Some things just don't make sense, but I guess that's the world we live in.
• Risk of injury or human life (or other externalities)
• And more....

The result of an assessment, as it relates to Information Security produces what are called Policies, Guidelines and Standards.  Although we can find a better description somewhere else online, let me try and simplify:

• Policy:  What shall be done.  (Regardless of how)
• Standard:  Establishes what should be the result (What/Per platform)
• Procedure:  The template or recipe on how it should be done in a particular use case  (How)
• Guideline: The best practice to shoot for.
  

We already stated, that a properly implemented countermeasure, includes technical, procedural and administrative controls that are preventive, corrective and detective.  

For example a policy statement like:  "the organization shall limit end-user Internet misuse"  (that I just came up with) may imply controls like this:

• Standard:  The corporate browser is Mozilla Firefox, configured to use a proxy server.
• Standard:  Microsoft TMG is the official Proxy Server, implemented with HTTP and HTTPS access with a filter to block all "Liability" categories.
• Standard:  Group Policies will be deployed to limit access to the Options-Advanced-Network tab of the browser.
• Standard:  All questionable internet usage will be reported and consolidated into a SQL server back-end.
• Guideline:  When possible, make the user acknowledge the fair use statement when users go to questionable sites.

The browser and proxy server standards are the preventive controls, the TMG filter is the corrective control and the reporting is the detective control.

Notice that these standards are mostly technical controls.  For a proper implementation, things that are relevant:

• Standard (administrative):  Background checks for prospective employees
• Standard (administrative):  Security policy attestation (proper use)
• Standard (procedural):  Discuss proper use with employees as an item for performance reviews.
• Guideline (procedural): Assign some points to proper use in the Housekeeping performance category.

Now we have some additional administrative and procedural controls that can prevent the hire of candidates with history of misuse of corporate assets, we are requesting acknowledgement and attestation of the fair use guidelines, and the fair use is being discussed as part of performance reviews.

Technical controls alone can't mitigate all risks, especially when there are human beings involved.

How your Centrify Implementation Affects your Standards and Procedures

With Centrify, the UNIX/Linux administrator has more tools at their disposal, this means that principles like least access, least privileges, separation of duties and more are easier to implement.  Let's look at an example - the password policy.  (by the way, here's a great example of a password policy)

Policy:  End users shall protect passwords and implement them in a way that are not easily guessable.  

Standard: An acceptable password contains at least 8 characters, 1 numeric, one special.  The age of a password will be 45 days, cannot be reused until after 15 iterations and will be stored with non reversible encryption.

So far this is very straightforward:  but when it comes to the sub-standards and procedures, here comes the variability:

On Windows Platforms:  Since all windows computers are domain-joined, the policy shall be implemented with the "Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy" Group Policy objets.

On UNIX/Linux Platforms:  All Linux platforms should implement the standard /etc/login.defs file. On Solaris, the standard /etc/defaults/login. The PAM library pam_cracklib should be implemented.

Notes:  This is overly simplified, but it has implications on the standard build (or image), maybe the files have to be centrally hosted and checked constantly, etc.

Process Reuse: With Centrify in place, the Windows Standard can be reused for the UNIX/Linux platforms and the agent will enforce it.  The standard may be needed for local accounts, but since all human accounts will be in AD, the root account (or any other service account) can have a long password that can be secured.  The privilege management component of Centrify allows to elevate to those accounts without knowing the password.

A Standard Framework to Enforce Access Controls

The Centrify agent implements Role-Based Access Controls (RBAC) that allows for easier implementation of the least access and least privilege principles.  The best way to see it is with our example.  We have a simple model, in which only DBAs can accesses Database Systems (so far CEN1), only Web Admins  can access Web Systems (so far SUSE1) and Sysadmins can access and manage all systems.  This means that standards like the ones outlined in the PCI DSS section 7:

Requirement 7: Restrict access to cardholder data by business need to know

To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. Need to know is when access rights are granted to only the least amount of data and privileges needed to perform a job.

7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.

7.2 Establish an access control system for systems components with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

Only Doyle and Matt (Web Admins) with Jessie (sysadmin) can access SUSE1

Only Jeremy and Ramon (DBAs) with Jessie (sysadmin) can access CEN1

How is this accomplished with Centrify:

Zones will only allow Active Directory UNIX-enabled users that have a proper role to access the systems.

The privilege management module (directauthorize) with AD and authorization manager.

(And this same model can be extended to Windows too!!!)

Moderation note:  This is why Centrify Express is not discussed in this blog, because by default, it will allow every AD user from the local domain (and trusted domains) to access te UNIX/Linux systems.