A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory - Part 5

Background
This is the fifth and final article in the series titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" in the previous post we discussed how to integrate your Linux and Windows systems to Centrify zones in AWS Active Directory for the purposes of authentication and privilege management.

In this article we'll discuss how to use Centrify Privilege Service to provide shared account password management, privilege session management and recording and strong access controls.  Here are the detailed goals:

• To provide a redundant secure point of access for AWS-hosted systems
• To provide password lifecycle services:  request-approve-check-out-check-in-rotate-auto/rotate
• To provide temporary access (sessions and password checkouts)
• To provide application to application password management capabilities
• To provide advanced jumpbox access to SSH and RDP systems in AWS
• To be able to proctor in real time
• To be able to review session transcription and provide session replay
• To provide advanced access controls like strong authentication, time-fencing, geo-fencing and more
• To continue to leverage Active Directory or use other identity schemes(LDAP, Google Directory, Social Identity, Centrify Cloud Directory or even a SAML IdP as the identity source)
• Minimize exposure by eliminating the need for elastic IPs (publicly facing)

Centrify Privilege Service Architecture
I've written about CPS in the community before, for some features and demos review this article:  http://centrifying.blogspot.com/2015/08/in-depth-centrify-privilege-service.html

In summary, it is a SaaS-based Password Manager and Jump Box (in Gartner speak, provides SAPM, PSM and AAPM), however it uses the assets of identity service:  Federation, Workflow, AD-Bridge, Multifactor Authentication and more.  CPS has a connector-based architecture like this:


This means that there are several ways to use Privilege Service in IaaS scenarios.  However, I will focus on this type of design:

The benefit oft his design is that it allows flexibility. Here are some highlights:

• The single source of identity continues to be the on-premises Active Directory.  AD Principals (like groups) can be used to control entitlements like who can access the management portal, check out passwords, modify resources, etc.
• Allows for connected or disconnected AWS connectivity.  Cloud Connectors in AWS act as jumpboxes, regardless of the EC2 scheme (domain-joined or not) the connectivity is centralized.
• Advanced Controls like
  • Step-up authentication:  Centrify MFA, OATH OTP, Phone factor, SMS, Email, PKI/Smartcard
  • Allow access only from corporate network: Users must be on-premises to access AWS assets
  • Geo-fencing:  access can be limited to only corporate locations.
  • Workflow:  Resource and password check-outs can use an access request system (Centrify or ServiceNOW)
  • Temporary access control.
• Time-to-Market:  Password and session access can be deployed in minutes by launching an instance and deploying a cloud connector.  The same goes for internal datacenters.

We'll discuss some planning and provide some implementation/verification videos:

Planning
Stakeholders:   Infrastructure Lead, Directory Services Lead, Security lead, AWS SME, UNIX/Linux or Windows image lead, Database (SQL Server) SME etc.

Discussion topics:

• What are the systems that need to be accessed?
  The answer to this question has implications for AWS security groups.  For example, the security group where Cloud Connectors will be residing must be able to establish connections over port 22 (SSH) and 3389 (RDP).
• What are the user populations that need access to AWS systems?
  This determines the identity stores.  User populations can be full-time employees, contractors, vendors, etc.  Depending on the existing strategy, maybe not all users have AD accounts, this is where identity flexibility of CPS becomes handy.  Some examples:
  - Temporary contractors may be provisioned in the Centrify Cloud Directory instead of AD.
  - Perhaps ADFS has been implemented or partners need access, in that case CPS can be the service provider in a federation relationship.
• What are the groups that should manage the system?  what are their entitlements?
  The answer to this question has directory service and functional implications.
• What are the security controls to be put in place?  (strong auth, geo-fencing, time-based controls, workflow/approvals)
  The data classification of the systems determines the controls that should be in place.  The most basic could be that all AWS access must be generated from the corporate IP range, and access to the portal requires strong authentication.
• Password Management lifecycle questions:
  Should approvals be required for password checkouts?  Should multiple password check-outs allowed? should passwords be rotated in a specific interval?  Should password health be monitored? should password be allowed from mobile devices? Should passwords for temporary systems be managed?  Should active directory account passwords be managed?
• Password Storage
  Should the Centrify Secure Storage be used or is a physical or hardware HSM (Safenet SecureKey) available?
• Will AAPM or self-registration be needed?
  The answer to this question has implications for AWS images or DevOps.  Centrify provides a Linux package (CLI toolkit); this allows for automation and automatic system registration.
• Monitoring and Reporting
  What events should be sent to log aggregation (SIEM) platforms?  What reports should be generated and who are the consumers of these reports?
• Attestation
  What is the process of validating that certain privileged users should have (or continue to have) access to certain resources?
• Session Recording
  What is the data retention policy for audited sessions?  How many concurrent sessions (SSH/RDP) can be expected?
  These topics are covered in depth in Chapter 2 of the DirectAudit Administrator's guide. 

Implementation
In this example, I will use an AWS environment with Active Directory to:

• Add a cloud connector for privilege service session management
• Manually register some EC2 Linux and Windows systems for jumpbox accesss
• Manually manage the password of a local Linux, Windows and Active Directory domain account.
• Use two AD groups:  AWS-CPS-Full Access and AWS-CPS-Read-only access. Members of the 2nd group must request access for password checkouts or proxied sessions.
• Enforce Strong Authentication.
• Using the CLI toolkit for CLI password checkouts and manual and automatic.

Moderation note:  Due to the blog's 20K character limitation, videos will be used.

Requirements for this Lab

• An AWS instance with Active Directory (managed by you or hosted by Amazon)
  • Two AD groups:  AWS-CPS-FullControl & AWS-CPS-Limited
  • A Domain Administrator to authorize the cloud connector
  • Outbound Internet connectivity via single-attached Elastic IP or Internet gateway (preferred)
• From Centrify you'll need:
  • A Centrify Privilege Service evaluation or production tenant with sysadmin-like credentials.
  • The Installation bits for Centrify DirectAudit
• A domain-joined system for:
  a) Centrify Cloud Connector (although not recommended, this can be the DC if running a simple lab).  Cloud connectors require outbound HTTPS connectivity and to act as jumpboxes for Linux and Windows systems, they should have connectivity over TCP ports 22 and 3389  (or your custom ports if changed).
  b) DirectAudit components:  this will be the not recommended all-in one scenario (Database/Collector/Agent). 
• Test Linux and Windows EC2 instances.
• Optional:  An Android/iOS mobile device for Touch/OTP MFA or a Yubikey 4 or NEO for OATH OTP

Requirements Verification

Installing a Cloud Connector

Installing DirectAudit

Configuring Roles for CPS Access


Configuring Workflow and Approvals

Using the CLI Tookit (AAPM)


Managing Active Directory Domain Account Passwords

Session Management, Proctoring, Capture and Replay

Dashboards and Reports

Advanced Controls (Policies, Authentication Profiles, Strong Authentication)


Adjustments
Some of the adjustments that can be made include:

1. Password storage:  HSM or Secure Centrify Storage
2. Different directory sources for different user populations
3. Smart Card Authentication
4. Bulk import of systems
5. CLI tookit baked into master AWS EC2 Linux instance.
6. Use of PowerShell to automatically register Windows accounts
7. Limited visibility of resources using the Privilege Portal login right.

End of Series - Conclusion
This ends the series on AWS and hopefully you've seen how the Centrify product lines:  Server Suite, Privilege Service and Identity Service work together to secure your AWS environments while balancing operational efficiency and productivity.   

A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory - Part 4

Background
This is the fourth article in the series titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" in the previous post we discussed how to secure Amazon Identity and Access Management (IAM)  by leveraging Centrify Identity Service and your on-premises Active Directory.
In this article we'll discuss how to use Centrify Server Suite to secure your AWS Server instances by leveraging Active Directory (in AWS, on-premises or a mixed environment).  The drivers behind this are:

• To continue to leverage Active Directory as the source of identity and privileges
• To eliminate the reliance on SSH keys or fragmented identities
• To provide a tried and true privileged elevation mechanism (sudo) without the inconveniences of sudoers files
• To be able to deploy additional controls such as time-fencing and multi-factor authentication for linux
• To be able to quickly attest who can access systems, their roles, privileges and how the privileges were granted
• To enforce the principle of separation of duties

Active Directory and AWS
The prescriptions outlined on this article depend on how your Active Directory AWS strategy is designed.  It's even possible that there's no AD in your AWS deployment today, in that case you'd benefit from looking at the next entry in the series (that focuses on session brokering and password management).  Assuming you are using AD in AWS, here are some of the models we've seen with our customers:


The Connected Model
This model implements some degree of permanent connectivity between AWS and your on-premises infrastructure (e.g. Amazon DirectConnnect, Firewall ACLs, VPNs/Tunneling, etc); the end result in the Active Directory layer is that the following models can be implemented:

• Account-resource model:  With accounts living on-premises and a resource domain existing in AWS (for example, with a one-way trust).
• Extended model:  Domain controllers extend to AWS (writable or read-only).

The connected model allows for organizations to extend their AD and Centrify deployments and treat AWS as another site.  As far as Centrify goes, it's like adding another branch or site.

The implications of this model are permanent connectivity (and costs), plus the need to implement the network and security components prior to the AWS deployment.  Once it is in place, the administration is simplified.

 
The Disconnected Model
This model uses the opposite approach.  It treats AWS as a disconnected entity.  Users connect to AWS through the Internet.  Directory services are separated.

In this scenario, independent AD forests exist on premise and in AWS.  The benefits of this model are:

• Faster-to-production because there's no need to wait for dedicated connectivity to be set up.
• No need to architect a security model around AD.

The obvious drawback of this model is dual administration.

Commonalities and Customer Inquiries
When communicating with prospects and customers on the field, these are the commonalities that I have observed:

• They want to extend the Centrify Server Suite benefits to these environments
• They have questions about their AD architecture (the two models below hint at how things would be designed and managed)
• They have questions about the instance lifecycle:
  • How can I automate Centrify client deployment?
  • How can I automate AD joins when systems are launched?
  • How can I automate AD leaves when systems are terminated?
• They have questions about management frameworks  (e.g. Scripts, DevOps, Amazon OpsWorks)
• They want to automate privileged operation leveraging PowerShell
• They want to deploy additional controls (like multifactor authentication or time-bounding)
• They have miscellaneous questions about pre-validation and the use of DirectAudit (session capture and replay)

Fortunately the building-blocks for all the questions asked above are scattered in the Tech Blogs and the Centrify Knowledgebase.  Instead of using the Plan-Do-Check-Adjust model in this article (because of the combination of scenarios), I will speak about each bullet-point individually.

Extending Centrify Server Suite to Amazon Web Services
This one is straightforward.  CSS requires Active Directory and there are several avenues that you can use.  This all depends on the access and privilege model to be implemented. 

• If status-quo will be maintained and the same user population retains the same rights to AWS
  • You may only need to create a child zone or a computer role in your existing zone structure.
  • Active Directory design principles are maintained: 
    - AD Sites and Services (subnets/sites) need to be created and maintained. 
    - Global Catalog location needs to be accounted for, especially if Universal or nested groups are used.
  • If RODCs are in use, adjust your instance provisioning model based on the prescriptions of the Server Suite planning guide (pg. 205).
• If there's a different access model being implemented
  • If there will be a completely new governance model within the same forest, then a parallel zone may need to be created and delegated to the proper group.
  • If a brand-new forest with a 1-way trust is created, then a zone in the resource domain will have to be created and principals from the trusted domain have to be added to provisioning and role-granting groups.

EC2 Instance Lifecycle
The EC2 lifecycle (Launch, Stop, Terminate) has implications depending on the use cases.  In permanent environments, systems are expected to be there for a long time;  in elastic environments systems may be alive for a few weeks while an app is tested, or may be scaled-up or down depending on load or business seasonality.
Aspect that require planning include naming conventions, properly deprovisioning systems and using the analyze wizard to make sure things are tidy.  Some resources:

• Server Suite Documentation: Deployment and Planning Guide
• Technet: Naming conventions in Active Directory for computers, domains, sites, and OUs
• Utilities - The Analyze Wizard tool

Deploying the Centrify Software and Joining (or leaving) AD automatically
Deployment depends on the approach.  I've seen customers that bake the software into their private AMIs (this allows for them to test and validate any corporate software) or I've seen the use of repositories and configuration management software.  The guidance here is consistent:  If you want the system to participate in your AD, you must align your hostname with your naming convention,  specify the domain name, and automate the AD join (using a krb5.conf file and a service account keytab).
Baking the software and utilities to an image makes things more predictable; however using a DevOps framework is the way of the future (given the testing orientation). 


This article shows how to create these building blocks: [HOWTO] Use Centrify Tools for Public/Private Cloud Automation Activities
The Termination sequence is relatively the same:  retrieve utility files, run kinit and instead of adjoin, run "adleave --remove" this will remove the computer from AD and Centrify, freeing-up the license.

DevOps Frameworks
Amazon AWS provides a great set of tools based on Chef (OpsWorks).  If you choose to use this framework, you need to have your recipes and underlying infrastructure in place (e.g. an APT/YUM repo, or Chef infrastructure) to host the dependencies.  If you are looking at the DirectControl, DirectAudit or CLI toolkit as an app, you have to sequence the triggering of the script based on your design (e.g. user-data, setup/configure/deploy/undeploy/shutdown). 

Here are some avenues:
User Data field:


OpsWorks:

These articles show the same sequence using Chef or Puppet:

• Basics - Using a Chef recipe to deploy Centrify and join Active Directory
• Basics - Using Puppet standalone to deploy Centrify and join Active Directory

Automating Access and Privilege Operations with PowerShell
Amazon AWS provides a powerful toolset that has been implemented in PowerShell.  This is very aligned with Centrify's efforts (both Centrify Suite Standard and Enterprise edition provide PowerShell management tools). 

The subject of PowerShell is very broad, here are a few resources:

• Access Control and Privilege Management Scripting Guide
• Auditing and Analysis Scripting Guide
• Use the Centrify PowerShell Module to Automate Access and Privilege Operations

Securing Windows Servers in AWS
Some of you are also using Windows servers in AWS and ask us how we can help.  The windows security model has been challenged by modern threats like PtH and the dependency on high-privileged accounts (like Administrator) and groups (like Administrators and Domain Administrators).  Centrify DirectAuthorize provides a powerful mechanism to control access and privilege elevation.
In Suite 2016, Centrify added the ability to join zones automatically with the dzjoin command.  This can be combined with the EC2Config tasks for your Windows based AWS systems.  The User's Guide for Windows describes dzjoin in detail.

Advanced Controls and Reporting
Depending on the data classification or risk profile of the systems hosted in AWS, organizations may want to deploy additional controls to provide the assurance that only authorized users are accessing these systems, in addition, these systems may be subject to attestation requirements just like on-premise systems.  We will explore other controls in part 5, however Centrify Standard Edition provides multi-factor authentication for access and privilege elevation as well as several mechanisms to obtain access data.

Related Videos

Business Problems: What does 'Secure' mean to you? Your answer may impact your ability to launch your BigData Project

We've had an opportunity to man the Centrify booth at the Strata+Hadoop show in New York this past week and we were constantly surprised by the focus on the core capability, but when we engaged passers by, the were unaware of the following facts:

• A large majority of Big Data projects never make it into production
• The most visible examples of Big Data projects that add value to organizations involve data that may contain Personal Identifiable Information (PII) or financial information.

It does not take a security expert to realize that these projects would be subject to the biggest security requirements.

When challenged, we heard answers like "but [management tool] can be integrated to Active Directory" (on the more informed side of the spectrum) or simply, people were focusing on areas like table-level security.

It became clear to me, that "to secure" a capability has a different meaning depending on who you ask (e.g. Big Data Scientist vs. Linux administrator vs. Security Analyst);  this is why at Centrify we always encourage the main stakeholder to bring in their infrastructure and security peers.

The key takeaway is that regardless of who you ask, there are reasons like

• people: being able to find capable data scientists
• data: availability of the data
• cost
• dynamics: integration with business processes
• need: is it just a fad (business want to jump into the BigData bandwagon without real requirements)

But security will always come up, that's a common denominator across all Big Data.  We know this first hand because that's what we do.  Upwards of 60 of our customers are using Centrify to align their Big Data deployments with security requirements.

If you're tasked to launch a Big Data project, you have all the opportunity to get a leg-up on this problem and attack security early.

At a basic level you have to look at this in terms of layers.

To simplify, there's two of them:  The Identity/Infrastructure layer and the Big Data layer.  The concerns and focus are completely different.

OS Layer
I also like to call it the Identity/Infrastructure layer because it plays directly into what Identity and Access Management is set out to do:

a) Use a common directory to identify and authenticate users
b) Enforce the least access principle
c) Enforce the least privilege principle
d) Eliminate the human problem of shared accounts
e) Implement strong controls (e.g. end-to-end session auditing or multi-factor authentication) when needed
f) Be able to attest who has access to a system
g) Provide reporting and tools for attestation

Big Data Layer
I can't even pretend to advise on the Big Data layer, but all I know is this:
If you can't identify - you can't authenticate - if you can't authenticate, you can't authorize;  and if you can't authorize, you can't enforce strong access controls.  Regardless of Knox, Sentry and any other security initiatives at the Big Data layer, you need robust OS services to optimize those.

A promising future
We were also excited by the bright spots:  Cloudera, Hortonworks and MapR are taking security very seriously because they realized that this affects their ability to bring nodes into production.

Centrify is here to help!!!   Learn what we mean by "secure" - it's all about the OS Layer (Identity and Access Control)

Overcoming the Hadoop Security Challenges at the IAM layer with Centrify

Centrify's Value Proposition - Part 3: Privileged User/Identity Management with Least Priviliege

In the third part of this series, we'll discuss how Centrify provides solutions for privileged user/identity management and maintains these principles:

a) Eliminates identity silos

b) Implements strong access controls without interfering with the user experience

c) Use what you have: infrastructure, processes, knowledge (less IT fragmentation)

d) Promotes operational efficiency

e) Provides strategic value, rather than tactical solutions

Organizations come to Centrify for privileged identity management or privileged user management because of combinations of the following challenges or circumstances:

•  Overall: They want to increase accountability and implement strong privileged user identity and access controls based on a common identity repository.
• They have Active Directory and multiple platforms, but primarily for UNIX, Linux and Windows
• They have a traditional (on-premise only) or hybrid (public/private cloud) enterprise
• They want to eliminate the use of shared credentials or persistent administrative accounts (root, administrator, “-a”, etc)
• Their existing solution does not provide flexibility on grouping systems based on a security governance model
• They might have chosen to implement a password-centric approach as their unique strategy and they’ve come to realize that their users are less productive (or supportive), that they’ve duplicated identity silos and that ultimately, their systems (the main goal) aren’t protected by it.
• On UNIX: They understand that using sudo/sudoers, although it’s mature may not be enough for high-risk, highly-regulated enterprises; they are tired of the complexities of managing a sudoers file and want more granularity and flexibility
• They want a higher-degree of control on how their users access systems (beyond just granting/denying access) cross platform.
• On Windows, they want to eliminate the problem of the Local Administrator, are conscious of the “pass the x” attacks and want to eliminate the “camping” issue with “-a” accounts.
• They need to provide separation of duties (operational rights vs governance rights)
• They need timely reporting of who has access to what system(s), what are their privileges, and what granted them access to do this.
• They don’t want to deviate from existing processes or realized that by implementing point solutions or “best of breed” they ended-up fragmenting their IT in the context of processes.
• They have regulatory requirements that they need to meet or exceed.  These may be SOx, PCI DSS, HIPAA, NERC, FERC, etc.
• They want to solve the Shared Account Password issue, but they want a solution that reflects the state of modern trends (they hybrid datacenter, IaaS, mobile-first, etc)
• They have high-security requirements like FIPS, solutions common-criteria certified, perhaps they rely heavily on Smart Cards.
• They want log aggregation that is simple to their native tools (ARCSight, LogLogic, Splunk, etc)
• They may need to go beyond the traditional security operations and provide session capture and replay from anywhere (remote or via console) because today they don't have that capability, are required to have it or simply, they might have gone the "jumpbox" route to realize that they are missing crucial sessions.
• They hate having to invest in multiple solutions to enforce the same basic security principles.  Each time they do, this may mean:
  - Evaluate a product
  - Invest or procure new hardware or software
  - Add additional infrastructure
  - Train or hire specialist
  - Maintain the solution down the road
  - Manage the vendor relationship

Here's a technical demonstration on how Centrify delivers this value:

The key differentiation areas are:

• AD Orientation - implemented in more of 90% of enterprises, users use a unique identity.
• Centrify Zones - unique patented way to create groups of systems in Active Directory
• Granularity of Access Controls - control HOW users log in to systems
• Granularity of Privileges - no need to know the privileged account password.
• Simple privilege elevation:  sudo-like tool in UNIX/Linux, shell and command line on Windows.
• No proprietary magic on how events are stored: no need to have a central system just to know who did what and when - need to rely on a central system to correlate who had a privileged account.
• Quick attestation and robust reporting - the data is in AD.
• Separates the operational tasks versus the governance tasks - to enforce SoD
• Works in multiple core platforms:  UNIX, Linux and Windows
• Protects your systems: Provides end-to-end enforcement of the rules as well as session capture and replay.

Finally, the end user experience is not affected, no identity silos are created  and your AD infrastructure, processes and technology are reused.  We propose that the "least access/least privilege" approach to Privileged Identity/Super User Privilege Management should be used at least in 80% of the use cases.

In the next post we're going to talk about the next 20%, this includes Shared Account Password Management, Proxied/Brokered/JumpBox initiated sessions (what gartner calls Privilege Session Management).

Centrify's Value Proposition - Part 2: The hybrid and heterogeneous enterprise

Organizations with traditional (on-premise) and  hybrid (private/public cloud) with Active Directory, come to Centrify because:

• They have diverse platforms (UNIX, Linux, Macs) in their enterprise (on-premise and in the cloud).
•  They are looking to Centralize the administration (or implement effective controls) for user access in those different platforms.  Their reasons may be due to security, regulation, operational efficiency or simply because they are reacting to an audit or other event.
•  They are also looking to leverage the secure authentication methods provided by Active Directory. 
•  They are looking to find a way to effectively manage UNIX identities by using Active Directory, but preferably, they don’t want any schema extensions to AD or software loaded in Domain Controllers.
• Some other organizations (and this is quite common on the Mac side) are looking for a more robust way to support AD integration and are also looking to use a common management framework (like Active Directory Group Policies) to enforce security policy or configuration management policies.
• Other organizations are looking to focus on their core competencies because perhaps they invested a lot of engineering cycles using open source software (like Samba/Winbind, RedHat’s SSSD, OpenLDAP with MIT Kerberos) and realized that the speed of requirements and diversity of platforms does not align with their goals.  (E.g. a Financial organization spending hundreds of man hours on “manual” identity and access controls rather than portfolio analysis).  These types of organizations are ready for a solution that “just works”
• Organizations want solutions that are friendly to private/public cloud scenarios; this means a toolset that promotes automation.
• The organization may have high-security requirements like smartcard authentication, FIPS encryption or common-criteria certified solutions
•  Finally, some organizations tried to wait as long as they can keeping the status quo; and a compelling event has made them change like:

• Change of leadership

•  A merger or an acquisition

•  A new technology (like BigData)

•  Acknowledgement that advanced persistent threats can’t be ignored

•  Another solution isn’t providing timely updates, proper support or their future is uncertain

• An audit or data-breach

•  Perhaps there’s an old infrastructure (e.g. NIS, LDAP) that found fresh blood that isn’t afraid of “touching the server, who knows what will break”  <= yes, this sadly happens.

Everything I outlined above is core of what some analysts call “Active Directory Bridging” but when you look at it is much more; it is the basis for implementing critical access controls and a management framework that is based on reuse of existing infrastructure and processes rather than point solutions.  It’s also the foundation of making sure users can do their work, without interrupting their flow.

Here’s a technical demonstration on how Centrify provides value:


 A very unique capability that is exclusive to Centrify is the zones technology.  Nobody else can do what Centrify does to group systems in a hierarchical way while consolidating UNIX identities for Users, Groups and NIS Maps.

Note that also, a large number of "born-in-the-cloud" organizations are coming to Centrify for Web Application SSO and Enterprise Mobility.  We will cover that in other entry.

In the next post, we'll focus on how Centrify builds on their AD bridging capabilities to provide Privileged User Management on UNIX, Linux and Windows and how it uses it's Identity Platform for secure access and shared account password management.

Opinion: On Centrify's Value Proposition - Part I

My take on Centrify's value proposition

Non-IT people often ask me:  “What is it that Centrify does…?” the answer to that question is becoming increasingly broad, because the product portfolio is growing; what I typically like to say  is this:  “we provide Active Directory-centric Access Controls(*)”; however, in the past 3 years we have released capabilities that expand beyond the basic premise of a heterogeneous data center.  The overwhelming response to some of the briefings we have with prospects or customers is this:  "Wow, I didn't know you did that much?"

I've expanded the definition to:  “We help you with your existing access control challenges in the data center, in the cloud and with mobile devices” this is regardless of directory bias especially in the context of Cloud (IaaS, SaaS) we are dealing with extended borders where Active Directory may not exist. However, ultimately common sense dictates that organizations should be aiming to reduce identity stores, not increase them.  However, when I look at our customer successes, and I'm a bit more bullyish.  Perhaps the answer should be: "We allow you to implement strong access controls in your systems and apps, regardless of location while promoting usability and operational efficiency" 

In this long entry, I'm going to present Centrify’s value proposition in 3 major areas:

• The diverse data center (using Active Directory to conquer AAA challenges with non-Windows platforms:  UNIX, Linux and Macs)
• Privileged Identity Management (using Centrify software and Services and Active Directory) to conquer the Super User Privilege Management (SUPM), Shared Account Password Management (SAPM), and Privileged Session Management (PSM) for Windows, UNIX, Linux, Macs and Network Devices.
• Web application and Software as a Service (SaaS) access controls, single sign-on (SSO), mobile access and mobility management

The subsequent posts will consist of “problem statements” or “challenges” that our customers and prospects provide us, and I will deliver a series of technical briefings (or demos) to cover each problem set.  As always, the intended audience is typically architects, security professionals, systems administrators and application owners.

In summary, and in business terms Centrify’s value proposition is around these principles:

• Implementing Strong Access Controls to protect your systems regardless of location
• Eliminate or consolidate identity stores
• Use what you have:  de-duplicate processes and infrastructure 
• Promote operational efficiency
• Be strategic, rather than tactical - solve the problems of today and tomorrow.

The goal is not to go in depth in technical terminology but to look at problem sets and solution sets "a la Centrify" - If you're just a visitor, it's a great way to look at Centrify in a non-technical way, although the demos will be somewhat technical.

(*)Why not use “Identity Management”?   Centrify uses the term too.

I personally refrain from using the “Identity Management” term because years ago, the term was intimately linked with Gartner’s definition AND for too many IT professionals it is synonymous with software that was expensive, consultant-heavy and projects that showed very little results.  

I think Centrify is in the identity space, but our approach is much simpler and integrated (producing faster results), besides, prospects often have unrealistic expectations if they think a single solution can solve all their Identity-related problems.  What I’m willing to concede (and I’m BIASED) is that if an organization is committed to Active Directory as their main identity store, using Centrify will provide “pound-per-pound” the best capability return per dollar invested, however, I’m also able to recognize that not all organizations are the same; there are complexities, political battles, biases and the simple commitment to use Active Directory is a tough decision to get to.

I also don’t want to have to tell people what they don’t want to hear.  If you were to ask me “Can you synchronize between PeopleSoft and target “X” system” – my answer is basically “No. user provisioning happens upstream and we try to avoid synchronization at all costs”  - sometimes briefings become a contest of “what can you do?” vs. “what problems can you help me with?” and this is the most frustrating part of being in technical sales.

Implement strong access controls for Hadoop clusters using Centrify

This 15-minute video also features Centrify Privileged Service



Centrify can help challenges with Hadoop implementations for confidentiality and integration at the OS-level.  No need to stand-up independent MIT Kerberos infrastructure, plus the strongest Access Controls to meet or exceed any security or regulatory requirement.

Business Problems: Overcoming the Confidentiality and Integration challenges with Hadoop Clusters using Centrify

Background

Hadoop implementations present multiple challenges to enterprises at the Operating System layer(*), I like to categorize them in 2 areas:

Confidentiality

• Hadoop clusters are unsecure by default.  What that means is that there's no service-to-service authentication and that privileged users have access to world-readable information and can elevate to privileged Hadoop accounts.
• Multiple clusters are needed because of the development nature of the apps.  Typically at least a DEV/QA and PROD environments are needed, depending on the risk profile of the organization, each environment may be in different isolated environments and require different access control rules.
• Different types of users need access:  From the SysAdmin, to the Hadoop Admin, to the Data Scientist, they all have different access and privileged needs.
• The data classification of the business intelligence may require additional controls.  What if the cluster crunches Personal, Financial, Health, Energy or Card data?   SOx, PCI, HIPAA, NERC or FERC compliance is needed.

Integration

• Kerberos:  Many organizations balk at the proposition of standing-up a separate MIT Kerberos implementation; and even if AD is an option, test environments may be in a one-way trust.
• Different organizations == Different requirements, therefore the devil is in the details:
• Process
• Technology/Infrastructure
• People
• Regulations

(*) There are additional security challenges, like how to protect data at the Hadoop layer, for this, your trusted Hadoop vendor (Cloudera, Hortonworks, MapR, etc) have an ecosystem of applications.  Centrify can provide identity information to those apps.

Technical Briefing

The following videos provide technical demos on how Centrify can overcome these challenges

Putting it all together

• Centrify allows for OS level integration for Linux and UNIX systems that enables:
• Centralized Administrations of multiple Hadoop Clusters
• Regardless of how complex your AD may be 
• No schema extensions or software in domain controllers
• Using UNIX frameworks
• Kerberos just works out of the box
• Leverage AD fully:  Kerberos, Group Policy, PKI
• Centrify enables the implementation of strong access controls to enforce
• Least access
• Least privilege (RBAC- not password Centric)
• Easy attestation and reporting
• Separation of Duties
• Works on Windows to eliminate the problem of the persistent administrator
• For environments with Personal, Financial, Health or Card data
• Session transcription 
• Session replay
• Event consolidation
• Works on Windows
• Hadoop-exclusive features:
• adkeytab for advanced keytab/service account provisioning
• Kerberos infinite ticket renewal parameters and GPOs
• LDAP Proxy to assist apps like Sentry, Hue and Knox
• Partner with Cloudera, MapR and Hortonworks

Centrify + AD + Hadoop = faster, more secure and regulation-aligned big data projects.

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (4/5)

This is part 4 of the series on leveraging Centrify to implement SANS Critical Security controls - Section 12: "Controlled use of Administrative Privileges".  (Also relates to PCI DSS 10.2)

CSC 12-11

Configure systems to issue a log entry and alert when unsuccessful login to an administrative account is attempted.

Why should you do this?
This is a detective control.  You can't control what you're not tracking.  Security operations typically leverage log aggregation technologies that tap into the native OS log facilities and centralize all this information into a centralized logging infrastructure that may or may not offer intelligence.

What is the typical approach?
On Windows:  Harvest and mine of the Windows event logs.  Surprisingly, a lot of outfits are not auditing the logon/log-off success/failure events.
On UNIX:  Harvest and mine the UNIX syslogs.

What is the real challenge for organizations?
Data vs. Noise.   How can organizations reconcile all the sources of data into meaningful information?  This is not Centrify's main capability, but it can certainly help by requiring meaningful data (e.g. change control/authorization numbers) and if all logs fail, there's always the session capture/replay capability.

Centrify's enhancers:

• Use what's native:  Uses syslog and event logs.  Unix logon/logoff success or failure are logged in the security log of the domain controller if configured by the Windows sysadmin.
• Enhance to differentiate the data from the noise:  Centrify can be configured to require reference information upon elevation, for example, change control number.
• Contextualize with DirectAudit to "clear the noise":  Enterprise Edition offers session capture and replay for both UNIX, Linux and Windows.
• Adding DirectAudit (Enterprise Edition) exceeds the requirements of PCI DSS 10.2 "reconstruct events"

Have a look:

How privileged elevation is logged (syslog) and recorded with Centrify on UNIX:

How with the Centrify dzdo validator, you can add more meaningful data to privilege elevation

How privileged elevation is logged (eventlog) and recorded with Centrify on Windows:

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (3/5)

This is part 3 of the series on leveraging Centrify to implement SANS Critical Security controls - Section 12: "Controlled use of Administrative Privileges".

CSC 12-7

Utilize access control lists to ensure that administrative accounts are used only for system administration activities, and not for reading e-mail, composing documents, or surfing the Internet. Web browsers and e-mail clients especially must be configured to never run as administrator.

Why should you do this?
To limit the exposure of administrative accounts to malware.

What is the typical approach?
On Windows:  Two sets of accounts are given to administrators,  a "dash-a" account and a normal account.  On the server side, to access the internet there's an air gap or the proxy server does not allow the servers or the "dash-a" account to go out to the internet.  The IE Enhanced Security mode is enforced.

On UNIX:  Systems are crippled from internet access or GUIs.  The email/surfing computer is different from the server systems.

What is the real challenge for organizations?
Human nature - people find ways to go around this, especially in the process of doing their actual jobs.  In the times of "knowledge on demand" having an internet browser to consult FAQs and community boards is very common.

Centrify's enhancers:
It's not all about just giving separate accounts, but being able to establish additional controls, like scope of systems, types of roles, privilege effectiveness, logon experience and flexible assignments.

CSC 12-10

Configure systems to issue a log entry and alert when an account is added to or removed from a domain administrators' group, or when a new local administrator account is added on a system.

Why should you do this?
At basic level this is a detective control, all administrative access should be traced back to an approval, otherwise this is misuse or a data-breach.

What is the typical approach?
Log aggregation.  Logs from multiple systems are sent to an enterprise security operations dashboard.

What is the real challenge for organizations?
Log aggregation lends itself for NOISE, then the log aggregation needs to be complemented by a data mining engine;  this is all to make sure that what's happening out there is authorized.

Centrify's enhancers:

• A Centrify deployment limits the local root or administrator account to break-glass situations.  They are not needed.
• Centrify (without any modification) augments log aggregation.  Therefore, the existing collection mechanisms can have richer data.
• Plus, Centrify reporting shows you what are the AD principals that grant the administrative roles, if things are tied to a Workflow or an IDM, anything that is not there by way of approvals will be identified quickly or rolled back.
• Plus Centrify DirectAudit provides the ability to view or audit who makes changes to the governance model.

Short video:

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (2/5)

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:

• More US-federal government certifications that I can even pretend to understand
• Common Criteria
• FIPS 140-2 Validated

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?