11 April,19 at 11:50 AM
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 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.
Section |
What it means |
Centrify Products/Features |
Centrify Implements |
Section 302.2 – Establish safeguards to prevent data tampering. |
Controls are implemented to prevent, correct or detect data breaches |
DirectControl, DirectAuthorize, DirectAudit / Privileged user management, logging, auditing |
Centrify implements a RBAC mechanism that allows to control: a) Who can access a system b) How they can access the system (console, SSH, RDP, etc) c) What can they do in that system (DirectAutorize) This approach protects systems end-to-end and it’s not password-centric. It’s called Least Access/Least Privilege Principle Resource: What is DirectAuthorize? |
Section 302.4.B – Establish verifiable controls to track data access. |
Controls are implemented to attest who has access |
DirectControl, DirectAuthorize, DirectAudit / Reporting, Auditing |
All access and privilege elevation events are logged to UNIX/Linux syslog and the Windows Event log (if Kerberos events are being audited) |
Section 302.4.C – Ensure that safeguards are operational |
Self-described |
DirectControl, DirectAuthorize, DirectAudit / site awareness, watchdog, caching, offline audit |
Centrify implements the following high-availability mechanisms: a) AD Site/Services awareness – this means that it will failover upon domain controller failure b) Offline Cache: in case of no DC availability it can provide login with cached credentials c) Telemetry calculations: the client proactively will probe to see if it’s talking to the most optimal DC. d) Watchdog processes: Implements a watchdog daemon that will spawn new processes if needed. Resource: Youtube Playlist - HA Mechanisms. |
Section 302.4.D – Periodically report the effectiveness of safeguards. |
Attest that controls are working as expected |
DirectControl, DirectAuthorize, DirectAudit /enhanced logging, alerts. |
Centrify Implements a) Console-based reporting b) Script-based reporting (UNIX, Windows PowerShell) c) SQL-Server Based Reporting (CSS 2016, now in Beta) |
Section 302.5.A&B – Detect Security Breaches |
Self-described |
DirectControl, DirectAudit / logging, capture and replay |
Centrify Provides: a) Event log and syslog logging b) Session Transcripton (EE) c) Session Capture and Replay (DVR-like) (EE) d) Event consolidation (EE) e) Event reporting (EE) |
Section 404.A.1.1 – Disclose security safeguards to independent auditors. Section 404.A.2 – Disclose security breaches to independent auditors. Section 404.B – Disclose failures of security safeguards to independent auditors. |
Demonstrate the existence of a security framework, for example: • Procedures to eliminate terminated (or changed) employees • Password Policy • Separation of Duties • Attestation |
DirectControl, DirectAuthorize, DirectAudit / zone provisioning agent, policy enforcement, zone delegation, role-based access, reporting, logging, auditing |
Centrify allows for a) Collapsing the termination of users directly in active directory b) The password policy from Active Directory is reused in UNIX, Linux, Mac and Apps c) Provides mechanisms to implement delegation and separation of duties. |
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:
How does the authentication process work?
At a very simple level:
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:
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:
Resources:
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:
In addition, Centrify subscribes to Microsoft’s documented APIs (ADSI), therefore there’s no need to add software in domain controllers.
Resources for Identity:
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".