Background on the Sarbanes-Oxley Act

You need to understand what a security analyst or auditor is asking of you, let's start with the basics:

• What is SOx?
  The Sarbanes-Oxley act of 2002 or “Public Company Accounting Reform and Investor Protection Act”
• Who needs to comply with it?
  All publicly-traded companies.
• How can you prove due-diligence with SOx?
  They need to provide the assurance that systems that impact financial statements have implemented the proper security controls.
• What is the point of SOX?
  The main intention of SOX is to establish verifiable security controls to protect against disclosure of confidential data, and tracking of personnel to detect data tampering that may be fraud related. The central purpose of the act is to reduce fraud, build public confidence and trust, and protect data that may affect companies and shareholders.
• What is the cost of non-conformance?
  Very steep penalties and/or prison time for executives.
• What systems are bound by SOx rules?
  Any system that supports applications that impact the business bottomline.  Your organization should have written guidelines to categorize the data that travels or is stored in those systems.
• What are the guidelines to determine if a system may be bound by SOx?
  This should be defined by a risk assessment exercise, however, a simple model is to use the CIA rating (Confidentiality-Integrity-Availability).  This triad can be used to do a simple test.  Ask yourself these 3 questions.
  If the data on these systems....
  a) is made public (confidentiality breach)
  b) is tampered-with or not reliable
  c) is not available (system down)
  ... is there an impact to the organization's bottomline (financial, reputation, major productivity loss)?
  The answer to these questions should give you a pretty good idea.  As a matter of fact, any system that falls into that category (infrastructure like Routers, Switches, DNS, PKI, etc.) has impact to operations.

What are the common misconceptions of the SOx Act?

That you should only produce reports (e.g. lists of users in the context of IAM).  The whole point of the concept of "verifiable security controls" is to prove the effectiveness of the controls;  the reason why organizations have to produce reports is due to legacy issues.

For example, if you are using /etc/passwd for 20 users, you have to potentially attest for 20 different user/attestation reports.

Now let's discuss how Centrify can help.

Centrify-Sarbanes Oxley Reference Guide

This table, should be a good starting point; however we ask that you reconcile this information with your organization's security policies, guidelines and procedures.

The bottomline is this:

Organizations that have multiple identity silos (like /etc/passwd or /etc/group) have a very hard time (or have a lot of complexity or an army of people) just to manage simple tasks like the user/group life-cycle (add/moves/changes).  With Centrify and Active Directory these tasks become centralized, making the security controls more effective.  Organizations effectively piggy-back on existing processes, so when you get the question "how can you prove that you're performing on-time user add/moves or changes?" you can simply say:  "This is all tied to our Active Directory processes and procedures"

Here's a good sequence (for user adds/moves and policy)

1. Log on to a UNIX, Linux or Mac with an AD user.
2. Show the system log (messages log, syslog or event log)
3. Logoff and Disable the user in AD
4. Attempt login (you should fail).  Show the log again.
5. Re-enable the user and log in.
6. Try to change the password to something misaligned with policy (like 1235).
7. Show the failure in password updates.

Note: You have to be auditing logon success and failure events in Active Directory Domain Controllers to see this.  You can set this up by enabling success and failure of the Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy > Audit Account Logon Events GPO.

Samples:
In this sequence, the user Diana (dwirth) logs in to a CentOS system via SSH.

Event on UNIX/Linux:

Jul 27 17:17:55 engcen5 adclient[3313]: INFO  AUDIT_TRAIL|Centrify Suite|PAM|1.0|200|
PAM set credentials granted|5|user=dwirth(type:ad,dwirth@CENTRIFYIMAGE.VMS) 
pid=25913 utc=1438035475776 centrifyEventID=24200 status=GRANTED service=sshd tty=ssh 
client=member.centrifyimage.vms

Event on Windows:

Centrify Architecture and Credential Consolidation

You often have to explain how our solution is architected.  The bottomline is that for all intends and purposes, the system acts like a Windows system.  However, you may need to materialize diagrams like this:

Make sure you explain that Centrify uses UNIX frameworks, standard protocols and Microsoft Active Directory specifications.  Here are some of the key ones:

• Name Service Switch (NSS) –provides a facility to the OS for sources of identity information like users and groups
• Pluggable Authentication Modules (PAM) – provides a facility to the OS applications to abstract authentication providers.
• Kerberos:  Centrify communicates with AD for authentication using Kerberos.  Kerberos is an authentication protocol that relies on a Key Distribution Center and Authentication servers.  The whole principle behind Kerberos is the use of mutual authentication, tickets, encryption and mechanisms to detect replay attacks.  Centrify provides MIT-Kerberos based tools and libraries that have been optimized to work with Microsoft’s Active Directory Kerberos implementation.
• High-availability is provided by AD Site Awareness, offline credential cache, telemetry calculations and the watchdog process.

How does the authentication process work?

At a very simple level:

1. A UNIX-enabled AD user attempts to log in using a PAM-enabled(*) application (like login or SSH)
2. An application like login uses the Centrify PAM module to attempt to log in.
3. The PAM modules will perform a series of checks, e.g. (user is authorized, AD account in good standing), password is correct, etc,
4. Kerberos: The system will use a mutually authenticated encrypted connection (with the highest allowed encryption) to talk to a domain controller and get the appropriate service tickets.
5. The user will be logged in to the system via the corresponding application (e.g. login, SSH)
   (see the attachment)

Encryption Levels

You may be asked about encryption too.  Make sure you explain that in an Active Directory environment, encryption algorithms and strength are defined by the version and functional level of the environment.  For example, an AD DC that is running in 2008R2 functional level will use AES256 for encryption, previous versions would use lower encryption levels.  The Centrify agent will follow the levels defined by Active Directory. 

Passwords are stored in Active Directory domain controllers and the encryption level is defined by the msDS-SupportedEncryptionTypes attribute.  To view the encryption levels supported by your current infrastructure, consult your AD team, or look at the /etc/krb5.conf configuration of any Centrified system. 

Encryption is used for two areas:

• Kerberos transactions (encryption in traffic – self-explanatory)
• Offline cache:   Centrify just like Windows supports the use of offline logins, as a compensating high-availability mechanism in case of lack of communication with a Domain controller.  The encryption levels for the offline has are the ones available by the AD functional level.  The parameter to encrypt the hash of the offline credential is cache.encrypt (or its corresponding Group Policy Object) and you can force an encryption type by using the adclient.cache.encryption.type (or the GPO).

Due Diligence

Due to Centrify’s penetration in high-security environments, we’ve had to perform additional due diligence and have achieved the following certifications:

• Common Criteria EAL2+:  https://www.commoncriteriaportal.org/files/epfiles/centrify-v20132-cert-eng.pdf
• FIPS 140-2:  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2011.htm#1604
• For additional certifications:  http://www.centrify.com/solutions/federal/certifications/

Resources:

• Centrify Configuration and Tuning Guide:  https://www.centrify.com/downloads/products/documentation/suite2015/centrify-unix-config-guide.pdf (page 31 – adclient.cache encrypt/encryption.type)
• About functional levels:  https://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels%28v=ws.10%29.aspx
• About Active Directory encryption levels:  https://msdn.microsoft.com/en-us/library/cc223853.aspx

Identity: Why aren’t AD Schema extensions or software in Domain Controllers required?

I've seen instances in which the auditor/security analysts asks this question.  
As it relates to identity data, Centrify has several ways to use Active Directory without requiring Schema Extensions:

• Pre-Windows 2003R2 AD functional levels:  Centrify zones implement mechanisms to store UNIX identity information in classic zones.
• Windows 2003R2 and above functional levels:  Centrify can use identity stored in the RFC2307 attributes implemented natively in this schema.
• Services for UNIX (SFU) Schema:  If a customer or prospect uses UNIX information stored in the MS SFU schema, we can use it as a UNIX identity source (although it provides less flexibility than Centrify zones).

In addition, Centrify subscribes to Microsoft’s documented APIs (ADSI), therefore there’s no need to add software in domain controllers.

Resources for Identity: 

• Video – How DirectControl stores information in Active Directory:  https://www.youtube.com/watch?v=JO3_AJObkAs
  in this video, the CTO and creator of DirectControl, explains how Centrify stores data in AD.
• RFC 2307: https://www.ietf.org/rfc/rfc2307.txt
• Attached - The “Understanding the Centrify DirectControl Agent.pdf” excerpt; explains the process step by step and more detail.
  
  (*) Centrify provides functionality for IBM Loadable Authentication Modules (LAM) as well.

Application Edition

If an Application (Apache, Java, DB2, SAP) initiates an authentication request via an interface (SPNEGO, GSSAPI, SASL, SNC, etc) ultimately the agent will use Kerberos for authentication.

In addition  Centrify has a whitepaper titled "Using Microsoft Active Directory to Address Sarbanes-Oxley (SOX) Compliance in Heterogeneous Environments".