Recertification Health Check – 6 Steps

/in , , /by

The regulatory push toward formal recertification of entitlements and privileges finds many enterprises in new compliance territory. PathMaker Group Chief Architect Jerry Castille shares six critical best practices to ensure strong governance.

1) Identify Target Applications: Collecting an inventory of applications that fall within the scope of a certification campaign’s requirements is the first step in a successful certification process. This inventory will detail application information relevant to the execution of your campaign.

2) Gather Accounts & Grants: For each application identified, I work with your team to determine the optimal approach for the extraction of accounts and group/role memberships from each target. If necessary, we will work with your team to develop a process for the normalization of this data into machine consumable output.

3) Entitlement Definition Workshop: Using our guided workshop format, we will work with your team of application and business process owners to define the set of entitlements within each application that will need to be certified. At the end of these workshops, your team will be enabled to define and maintain an inventory of items within each application that require access certification.

4) Gather Authoritative User Data: At this step of the process, PathMaker works with your organization to identify the individuals that will be included in the certification process. This includes individuals whose access is being certified, individuals approving access, as well as system owners that will be approving accounts that can not be directly associated with a human user (orphan and service accounts.)

5) Import Campaign Data: All of the work up to this point has been to develop a reusable set of processes that can be re-used to facilitate the adoption of a robust enterprise governance product. During this step,  import the data gathered during previous exercises into the PMG Certification Toolkit for analysis. Upon completion, execute your certification campaign.

6) Execute Campaign: Using the parameters defined during our workshop, a good toolkit will produce actionalble analytics for approvers and system owners within your organization. Participants will then “Certify”, “Revoke”, or “Modify” each entitlement that requires their approval. Once an approver completes their certification tasks, the data is imported back into the toolkit.

7) Measure Results: After importing analytics into the toolkit, a report is generated with any entitlements that will need to be revoked or modified. This report can be used by your organization to drive administrative activities required to remove any unnecessary entailments from your user population.

Meeting IAM Gaps and Challenges with New Product Offerings

/in , , , , , , , , , , , , , , , , , , , , , /by

PathMaker Group has been working in the Identity and Access Management space since 2003.  We take pride in delivering quality IAM solutions with the best vendor products available.  As the vendor landscape changed with mergers and acquisitions, we specialized in the products and vendors that led the market with key capabilities, enterprise scale, reliable customer support and strong partner programs.  As the market evolves to address new business problems, regulatory requirements, and emerging technologies, PathMaker Group has continued to expand our vendor relationships to meet these changes.  For many customers, the requirements for traditional on premise IAM hasn’t changed.  We will continue supporting these needs with products from IBM and Oracle.  To meet many of the new challenges, we have added new vendor solutions we believe lead the IAM space in meeting specific requirements.  Here are some highlights:

IoT/Consumer Scalability

UnboundID offers a next-generation IAM platform that can be used across multiple large-scale identity scenarios such as retail, Internet of Things or public sector.  The UnboundID Data Store delivers unprecedented web scale data storage capabilities to handle billions of identities along with the security, application and device data associated with each profile.  The UnboundID Data Broker is designed to manage real-time policy-based decisions according to profile data. The UnboundID Data Sync uses high throughput and low latency to provide real-time data synchronization across organizations, disparate data systems or even on-premise and cloud components.  Finally, the UnboundID Analytics Engine gives you the information you need to optimize performance, improve services and meet auditing and SLA requirements.

Identity and Data Governance

SailPoint provides industry leading IAM governance capabilities for both on-premise and cloud-based scenarios.  IdentityIQ is Sailpoint’s on-premise governance-based identity and access management solution that delivers a unified approach to compliance, password management and provisioning activities. IdentityNow is a full-featured cloud-based IAM solution that delivers single sign-on, password management, provisioning, and access certification services for cloud, mobile, and on-premises applications.  SecurityIQ is Sailpoint’s newest offering that can provide governance for unstructured data as well as assisting with data discovery and classification, permission management and real-time policy monitoring and notifications.

Cloud/SaaS SSO, Privileged Access and EMM

Finally, Centrify provides advanced privileged access management, enterprise mobility management, cloud-based access control for customers across industries and around the world.  The Centrify Identity Service provides a Software as a Service (SaaS) product that includes single sign-on, multi-factor authentication, enterprise mobility management as well as seamless application integration.  The Centrify Privilege Service provides simple cloud-based control of all of your privileged accounts while providing extremely detailed session monitoring, logging and reporting capabilities.  The Centrify Server Suite provides the ability to leverage Active Directory as the source of privilege and access management across your Unix, Linux and Windows server infrastructure.

With the addition of these three vendors, PMG can help address key gaps in a customer’s IAM capability.   To better understand the eight levers of IAM Maturity and where you may have gaps, take a look this blog by our CEO, Keith Squires about the IAM MAP.  Please reach out to see how PathMaker Group, using industry-leading products and our tried and true delivery methodology, can help get your company started on the journey to IAM maturity.

Initial Credential Issuance: An Often Overlooked Area of a Secure Identity Posture

/in , , , , , /by

Architecting mature and functional IAM strategies for our clients requires us to frequently reflect on the approaches that we have seen organizations take to solve common (and sometimes mundane) problems. One such such problem is that of initial credential distribution for internal user constituents (employees, contractors, temp workers, etc). How an organization creates and communicates a new user’s credential is really one of the first steps in a chain of maintaining a good security posture in the space of identity provisioning.

non-rep

At the core of this problem is the issue of non-repudiation. Basically, the ability to say that a given account owner was the only person who could utilize their credentials to access any given information system. More information on non-repudiation can be found here.

 

Over the years working in the IAM field, I’ve seen customers approach the problem of getting credentials to newly created users in different ways. Some (surprisingly many) choose to have their IT departments create new user accounts using a known password or formula (such as: <user_lastname><month><day>) in the newly created system. The issue with this approach is that there is no real guarantee that the account will not be used by a third party prior to or after distribution before the intended user begins to use them. This presents an obvious security issue that can be slightly mitigated by requiring a user to change their password after the 1st use. But, even forcing a user to change their password doesn’t completely solve this issue.

 

A more mature approach is to have a random password generated that complies with corporate password policies that is then communicated to the user through the IT department or the user’s manager. This still leaves the issue of non-repudiation, since whoever generates and communicates the credential to the user or manager also has knowledge of the credential. However, this approach limits the knowledge of this credential to only those in the chain of custody of the credential, instead of everyone who has been exposed to the ‘standard known password’ or password formula.

 

The most mature and effective way to address this issue usually involves implementing some sort of ‘account claiming’ mechanism. In this approach, a provisioning system or process generates a random system generated password that is never known to any person. Additionally, a system generated ‘claim token’  is generated that is then submitted to the user that can only be utilized once and within a specific time frame of issuance. The intended user is then directed to visit an internal account claiming site where they are asked for some personally identifying information (PII) along with their ‘claim token’. Once this information is verified, the user is directed to change their password, which is then communicated to the provisioning system and all downstream information systems. Identity provisioning platforms such as those from Oracle, IBM, and Sailpoint all make available the tools required to develop/configure this solution with minimal effort. This approach more effectively protects the integrity of the credential and greatly increases an organization’s IAM security posture with very little overall implementation effort.

 

This article is part 1 of a multi-part series that dives into specific concepts covered during our IAM MAP activities. More information about the Pathmaker Group IAM map can be found here.

 

With today’s increasing Mobile Enterprise Security Threats, do you have a strategy to mitigate the risk on your Corporate Network?

/in , , , , , , , , , , , , , , , , , , , , , , , /by

Corporations are increasingly utilizing mobile enterprise systems to meet their business objectives, allowing mobile devices such as smart phones and tablets to access critical applications on their corporate network.  These devices provide advanced technologies over traditional desktop clients, such as: information sharing, access from anywhere at any time, data sensors, location, etc. But what makes these mobile devices desirable, by their very nature, also poses a new set of security challenges.  Reports by research agencies in recent years show an alarming trend in mobile security threats listing as top concerns: Android malware attacks, and for the IOS platform issues with enterprise provisioning abuse and older OS versions.

These trends highlight the need for corporations to start taking seriously a mobile security strategy at the same level to which cyber criminals are planning future attacks. A mobile security strategy might involve adopting certain Mobile Security Guidelines as published by standards organizations (NIST) and Mobile OWASP project. See the references at the end of this document:

The following guidelines are a subset of Mobile Security Guidelines I pulled from various published sources with most coming from NIST. It is by no means a comprehensive list, however they can be considered as a starting point or additional considerations for an existing mobile security strategy.

1 – Understand the Mobile Enterprise Architecture

You should start with understanding and diagramming the flow from mobile application to business applications running on the back-end application server. This is a great starting point and should be done at the beginning stages, as most of the security guidelines will depend on what is known about the architecture.

  1. Is the mobile application a native application or mobile web application? Is it a cross-platform mobile application?
  2. Does the mobile application use middleware to get to the back-end API, or does it connect directly to a back-end Restful based Web Service?
  3. Does the mobile application connect to an API gateway?

2 – Diagram the network topology of how the mobile devices connect

Is the mobile device connecting to the business application servers over the cellular network or internally through a private WiFi network, or both? Does it go through a proxy or firewall? This type of information will aid in developing security requirements; help with establishing a QA security test bed and monitoring capability.

3 – Develop Mobile Application Security Requirements

At a high level, a security function must protect against unauthorized access and in many cases protect privacy and sensitive data. In most cases, building security into mobile applications is not at the top of the mind-set in the software development process. As such, these requirements should be gathered as soon as possible in the Software Development Life Cycle (SDLC). It has been my personal experience in many cases that you have to work with application software developers in adopting best security practices. So the sooner you can get that dialogue going the better. Security objectives to consider are:  Confidentiality, integrity, and availability. Can the mobile OS platform provide the security services required? How sensitive is the data you are trying to protect. Should the data be encrypted in transit, and in storage? Do you need to consider data-in-motion protection technologies?  Should an Identity and Access Management (IDAM) solution be architected as part of the mobile enterprise system? Should it include a Single Sign On functionality (SSO)? Should there be multi-factor authentication, role based or fine-grained access control? Is Federation required? Should the code be obfuscated to prevent reverse engineering?

4 – Incorporate a Mobile Device Security Policy

What types of mobile devices should be allowed to access the organization’s critical assets. Should you allow personal mobile devices, Bring Your Own Devices (BYOD’s) or consider only organization-issued or certified mobile devices to access certain resources? Should you enforce tiers of access? Centralized mobile device management technologies are a growing solution for controlling the use of both organization-issued and BYOD’s by enterprise users. These technologies can remotely wipe the data or lock the password from a mobile device that has been lost or stolen. Should Enterprises consider anti malware software and OS upgrades to become certified mobiles on the network? To reduce high risk mobile devices, consider technologies that can detect and ban mobile devices that are jail broken or rooted, as these can pose the greatest risk of being compromised by hackers.

5 – Application Security Testing

According to a study performed by The Ponemon Institute, nearly 40% of 400 companies surveyed were not scanning their applications for security vulnerabilities, leaving the door wide open for cyber-attacks. This highlights the urgency for security teams to put together some sort of security vetting process to identify security vulnerabilities and validate security requirements as part of an ongoing QA security testing function. Scanning application technologies typically conduct two types of scanning methods: Static Application Security Testing (SAST) which analyzes the source code and Dynamic Application Security Testing (DAST), which sends modified HTTP requests to a running web application to exploit the application vulnerabilities. As the QA scanning process develops, it can be automated and injected into the software build process to detect security issues in the early phases of the SDLC.

6 – System Threat Model, Risk Management Process

What will typically come out of the application scanning process will be a list of security vulnerabilities found as either noise, suspect or definitive.  It will then be up to the security engineers knowing the system architecture and network topology working with the application developer to determine whether the vulnerability results in a valid threat and what risk level based on the impact of a possible security breach. Once the risk for each application is determined, it can be managed through an enterprise risk management system where vulnerabilities are tracked, fixed and the risk brought down to a more tolerable level.

7 – Consider implementing a Centralized Mobile Device Management System

Depending on the Mobile Security Policy that is in place, you may want to consider implementing a Centralized Mobile Device Management System especially when Bring Your Own Device (BYOD) mobiles are in the mix that can:

  • For mobile devices, manage certificates, security setting, profiles, etc through a directory service or administration portal.
  • Policy based management system to enforce security settings, restrictions for organization-issued, BYOD mobile devices.
  • Manage credentials for each mobile device through a Directory Service.
  • Self service automation for BYOD and Reducing overall administrative costs.
  • Control which applications are installed on organization-issued applications and check for suspect applications on BYOD mobile devices.
  • A system that can remotely wipe or lock a stolen or loss phone.
  • A system that can detect Jail-broken or rooted mobile devices.

8 – Security Information and Event Management (SIEM)

Monitor mobile device traffic to back-end business applications. Track mobile devices and critical business applications and correlate with events and log information looking for malicious activity based on threat intelligence. On some platforms it may be possible to integrate with a centralized risk management system to specifically be on alert for suspicious mobile events correlated with applications at higher risk.

References:

Your journey toward IAM maturity requires the right MAP

/in , , , , , , , , , , , , , , /by
Read more

Developing an Entitlements Management Approach

/in , , , , , , , , , , , , , , , , /by

We were sitting down with a client during some initial prioritization discussions in an Identity and Access Management (IAM) Roadmap effort, when the talk turned to entitlements and how they were currently being handled.  Like many companies, they did not have a unified approach on how they wanted to manage entitlements in their new world of unified IAM (a.k.a. the end of the 3 year roadmap we were helping to develop).  Their definition of entitlements also varied from person to person, much less how they wanted to define and enforce them.  We decided to take a step back and really dig into entitlements, entitlement enforcement, and some of the other factors that come into play, so we could put together a realistic enterprise entitlement management approach.  We ended up having a really great discussion that touched on many areas within their enterprise.  I wanted to briefly discuss a few of the topics that really seemed to resonate with the audience of stakeholders sitting in that meeting room.

(For the purpose of this discussion, entitlements refer to the privileges, permissions or access rights that a user is given within a particular application or group of applications. These rights are enforced by a set of tools that operate based on the defined policies put in place by the organization.  Got it?)

  • Which Data is the Most Valuable?- There were a lot of dissenting opinions on which pieces of data were the most business critical, which should be most readily available, and which data needed to be protected.   As a company’s data is moved, replicated, aggregated, virtualized and monetized, a good Data Management program is critical to making sure that an organization has handle on the critical data questions:
    • What is my data worth?
    • How much should I spend to protect that data?
    • Who should be able to read/write/update this data?
    • Can I trust the integrity of the data?
  • The Deny Question – For a long time, Least Privilege was the primary model that people used to provide access. It means that an entitlement is specifically granted for access and all other access is denied, thus providing users with exact privilege needed to do their job and nothing more.  All other access is implicitly denied.  New thinking is out there that says that you should minimize complexity and administration by moving to an explicit deny model that says that everyone can see everything unless it is explicitly forbidden.  Granted, this model is mostly being tossed around at Gartner Conferences, but I do think you will see more companies that are willing to loosen their grip on the information that doesn’t need protection, and focus their efforts on those pieces of data that are truly important to their company.
  • Age Old Questions – Fine-Grained vs. Coarse-Grained. Roles vs. Rules. Pirates vs. Ninjas. These are questions that every organization has discussed as they are building their entitlements model.
    • Should the entitlements be internal to the application or externalized for unified administration?
    • Should roles be used to grant access, should we base those decisions on attributes about the users, or should we use some combination?
    • Did he really throw Pirates vs. Ninjas in there to see if we were still paying attention? (Yes.  Yes, I did).

There are no cut and dry answers for these questions, as it truly will vary from application to application and organization to organization.  The important part is to come to a consensus on the approach and then provide the application teams, developers and security staff the tools to manage entitlements going forward.

  • Are We Using The Right Tools? – This discussion always warms my heart, as finding the right technical solution for customers IAM needs is what I do for a living. I have my favorites and would love to share them with you but that is for another time.  As with the other topics, there really isn’t a cookie cutter answer.  The right tool will come down to how you need to use it, what sort of architecture, your selected development platform, and what sort of system performance you require.  Make sure that you aren’t trying to make the decisions you make on the topics above based on your selected tool, but rather choose the tool based on the answers to the important questions above.

Oracle Identity and Access Management with EM12c: Red Pill or Blue Pill?

/in , , , , , , , , , , , , , , , /by

It seems all too often that when users are unable to access an end-user business function protected by a IDAM (Identity and Access Management) solution, the IDAM system gets the brunt of the blame and in a lot of cases without justification. Today’s corporate web based business functions are comprised of complex systems based on a service oriented applications.  As such, it can be difficult to diagnose particular issues in a timely manner to preclude having to restart several components. As the issue persists, security controls may be removed or bypassed all together resulting in another set of problems. In many cases the root cause does not get identified and a repeat incident occurs.

Example Use Case

Consider a system that hosts a web application providing an end-user business function to allow users to sign up for service and be able to pay their bills online. To protect the web application, an Oracle IDAM system, referred to as the SSO Stack, is implemented to provide access control and data protection for the end-users. As you can see, there are a lot of complicated flows and dependencies in the systems.

TomBlogFigure1

Suppose an issue has been reported by an end-user and technical support personnel are logged in to try and resolve the issue. To illustrate the complexity of the issue, suppose an end-user cannot access the system to pay their bill. Without having an in-depth knowledge of what is going on inside the systems, it is difficult to determine if the web application is the problem or if the problem is related to the SSO Stack. If it is the SSO Stack, which component is at fault?

Remember the movie, the matrix, “take the red pill” and find out what is really going on in the matrix. “Take the blue pill” and you live in ignorance and bliss. When troubleshooting systems, the tendency is to: collect and analyze logs on each of the system components independently, trouble-shoot at the network level, and execute manual user tests, all time consuming. How many times have you heard someone say “I can ping the server just fine” yet the problem persists.

TomBlogFigure2

“What if I told you”, testing at the application layer provides a more accurate indication of what is really going on inside the system. The business functionality is either working as intended or it is not.  Applications performing the business functions can be modeled as services and tested in real-time. Service tests can measure the end-user’s ability to access a service and if automated, allow issues to be resolved before end-user complaints start rolling in. Service tests strategically placed in each critical subsystem can be used as health checks determining which system component may be at fault if there are reported issues.

EM12c Cloud Control Service Model

With EM12c Cloud control, business functions can be modeled as services to be monitored for availability and performance.  Systems can be defined based on target components hosting the service. As a service is defined, it is associated with a system and one or more service tests. Service tests emulate the way a client would access the service and can be set up using out-of-the-box test frameworks: web testing automation, SQL timing, LDAP, SOAP, Ping tools, etc. and can be extended through Jython based scripting support.  The availability of a service can be determined by the results of service tests or the system performance metrics. The results of the system metrics can be utilized in system usage metrics and in conjunction with service level agreements (SLAs). Additionally, aggregate services can be modeled to consist of sub-services with the availability of the aggregate service dependent on the availability of each of the individual sub-services.

Example Use Case Revisited with EM12c Service Model

Revisiting the issue reported in the previous use-case, it was not a trivial task in determining whether it was or was not an SSO issue and which component or components were at fault.  Now consider modeling the consumer service and running web automation end-user service tests against the web application. Consider the SSO stack as a service modeling the Identity and Access Management functionality. The SSO Stack can be defined as an aggregate service with the following subservices: SSO Service, STS Service, Directory Service and Database Service. The availability and performance of the SSO Stack can be measured based on the availability and performance of each of the subservices within the SSO Stack chain. Going back to the problem reported in fig 1, the end-user could not access the web application to pay their bill. Suppose service tests are set up to run at the various endpoints as illustrated in figure 3.  As expected, the end-user service tests are showing failures. If the service tests for the Directory Service and Database are passing, it can be concluded the problem is within the OAM server component. Looking further into the results of the SSO Service and STS Service the problematic application within the OAM server can be determined. As this illustration points out, Service tests provide a more systematic way of trouble shooting and can lead you to a speedier resolution and root cause.

TomBlogFigure3

Em12c Cloud Control Features

The following are some of the features available with the EM12 Cloud Control monitoring solution to provide the capabilities as mentioned not available from the basic Enterprise Manager Fusion Middleware Control.

  1. Service Management:
    1. Service Definition: Defining a service as it relates to a business function. Modeling services from end-to-end with aggregate services.
    2. Service tests: Web traffic, SOAP, Restful, LDAP, SQL, ping etc. to determine end-user service and system level availabilities and performance.
    3. System monitoring. Monitoring a group of targets that represent a system that is intended to provide a specific business function.
    4. Service level agreements (SLAs) with monitoring and reporting for optimization.
  1. Performance monitoring
    1. Defining thresholds for status, performance and alerts
    2. Out-of-the-box and custom available metrics
    3. Real-time and historical metric reporting with target comparison
    4. Dashboard views that can be personalized.
    5. Service level agreement monitoring
  1. Incident reporting based on availability and performance threshold crossing, escalation and tracking from open to closure. Can also be used to track SLAs.
  2. System and service topology modeling tool for viewing dependencies. Can help with performance and service level optimization and root cause analysis.
  3. Oracle database availability and performance monitoring:
    1. Throughput transaction metrics on reads, write and commits
    2. DB wait time analysis
    3. View top SQL and their CPU consumption by SQL ID.
    4. DBA task assistance:
      1. Active Data Guard and standby Management
      2. RMAN backup scheduling
  • Log and audit monitoring
  1. Multi-Domain management: Production, Test, Development with RBAC rules. All domains from one console.
  2. Automated discovery of Identity Management and fusion middleware Components
  3. Plug-ins from 3rd party and developer tools with Jython scripting support to extend service tests, metrics etc.
  4. Log pattern matching that can be used as a customizable alerting mechanism and performance tool.
  5. Track and compare configurations for diagnostics purposes.
  6. Automated patch deployment and management.
  7. Integration of the system with My Oracle Support

As a final note and why it is referred to as EM12 Cloud Control

One of the advanced uses of Oracle Enterprise Manager 12c is being able to manage multiple phases of the cloud lifecycle—such as the planning, set up, build, deployment, monitoring, metering/chargeback, and optimization of the cloud. With its comprehensive management capabilities for clouds, Oracle Enterprise Manager 12c enables rapid deployment and end-to-end monitoring of infrastructure as a service (IaaS), platform as a service (PaaS)—including database as a service (DBaaS), schema as a service (Schema-aaS), and middleware as a service (MWaaS).

What is Single Sign-On?

/in , , , , , , , , , , , , /by

As I was preparing for Gartner’s Identity and Access Management conference next week in Las Vegas, I was thinking about some of the typical topics that attendees usually ask us about.  There are always the people that want more information about the sexy, cutting edge topics like the Internet of Things, Privileged Identity Management and Adaptive Access Control.  I love talking about these subjects as they are new and involve interesting problems.  Solving interesting problems is fun and the reason many of us got into the information security field.

Another topic that frequently comes up isn’t quite as sexy or fun but really is a foundation function for a mature IAM system:  What is Single Sign-On (SSO)? It seems like SSO is viewed by many as a commoditized feature these days but a surprising number of organizations are still in the early stages of investigating SSO and what it might mean for them.

When explaining SSO to someone, I used to lead off by trying to break the news that they are really never going to have 100% single sign-on but as more and more legacy desktop fat client applications become web-enabled it is much more likely that they might be able to approach a true single sign-on.  These days I just get into a quick overview of what SSO means across a variety of different use cases.

  • Web-Based Single Sign-On – The most commonly recognized type of SSO is the sharing of credentials and user sessions across a common set of internally managed web applications. These can be things like Oracle e-Business Suite applications, portals and most other non-Software-as-a-Service (SaaS) web applications.  A user will be authenticated when the system validates username and password (plus additional factors in some cases).  They are given a session token in the form of a browser cookie that is validated and updated as they travel from application to application.  Usually the same Access Management system provides some level of authorization into these applications but we’re not going to get into all that entails.
  • Federation – Federation is a standards based method of authenticating users into applications hosted by a third party, also called Cloud-based or Saas. Think of SalesForce.com or any of a variety of Oracle’s Cloud applications. There are two sides to a federated agreement: Service Provider controls the actual application, and Identity Provider controls the user IDs and passwords.  The session token is typically a SAML assertion that is consumed by both parties and includes all of the relevant user information.  These SAML assertions can typically be consumed by the Access Management system that provided SSO for the internal applications, allowing users to seamlessly move from application to application regardless of where that application is hosted. (As an aside, when you hear Identity as a Service (IaaS) tossed around, typically is refers to a federation model when you still control your account information but the IaaS is used to broker application access via federation.)
  • Windows Native Authentication – This is the bridge to true SSO by allowing the Access Management system to integrate with a Windows domain to provide a seamless experience. A user will authenticate into their domain as they perform their initial login.  Once they are validated, they will received a Kerberos ticket from the domain controller that contains user and session information much like the browser token or SAML assertion.  When they launch an application that is protected by the Access Management system, the Kerberos ticket will be consumed, validated and then used as the basis to issue its own session token.
  • Enterprise SSO – eSSO, or desktop SSO, is based on agents being installed on each work station to handle the login in process for fat client and legacy applications. We don’t see this nearly as much since more and more applications are moving to the web.

An example to tie it all together – I sit down at my workstation and log in for the morning. A Kerberos ticket is issued.  I decide that I need to check the status of a customer lead in Salesforce.com so I launch a browser and go to the site. When I land on the app, it will query its Identity Provider (our Access Management system) who I am.  The Access Management system sees that I have a valid Kerberos ticket so it will create a SAML assertion and send me back to Salesforce.  This all happens behind the scenes and is usually pretty quick.  Once I am done on SalesForce, I need to go to Oracle e-Business to check on the status of an order.  I browse to the app.  The Access Management system sees that there is an active SSO session (via the SaleForce visit) and creates a new browser cookie to manage the session.  I’d be able to go between any integrated app, onsite or in the cloud, and have SSO for the duration of that session.

Obviously, this is a super-simplified version of how SSO works but I find that it gives people who don’t have a working knowledge of IAM concepts a good understanding of the functionality that is typically grouped under the SSO umbrella.

As a note, PathMaker Group typically implements SSO early in the release roadmap as it can be a quick win that shows value and progress to stakeholders.  We can get through a typical SSO project from requirements through production deployment in 3-4 months depending on scope and complexity.  Reach out to us to see how we can help you get your SSO project underway.

 

 

 

Three Characteristics of a Mature Identity and Access Management Program

/in , , , , , , , , , , , , , /by

Identity and Access Management (“IAM”) as an industry started gaining significant recognition and momentum around 2003. During these last 12 years, we’ve seen product vendors come and go, we’ve seen industry consolidation, and we’ve seen important product innovation driven by real business need.

While all this has been going on, many companies have leveraged IAM products to achieve important and significant gains in security, efficiency and compliance enforcement. On the other hand, some companies have tried and tried to establish effective IAM programs only to fail in their attempts to affect real change.

What makes one company succeed and another one fail while attempting to leverage the same products and technologies? What are the characteristics of a truly mature IAM program?

Over the next few weeks, I will attempt to address these questions. I also hope to create an important dialogue among those of you who have “been at it” for the last 5-10 years and have seen and been part of great successes and colossal failures. Although I have been part of hundreds of IAM projects, and will lend my experience to the discussion, you, as the readers and contributors, may have much more to contribute to make this topic come alive. Will you help?

Let’s get started with three important characteristics of a mature IAM program. This list is not exhaustive but these capabilities are common among organizations that have made IAM a strategic part of the IT infrastructure.

#1 – User Identity Integration

Pieces and parts of a user’s identity can exist across many different systems in an enterprise. HR systems are an obvious source along with IT systems like Active Directory. Then there is the badge or physical access system, the phone system, and various business applications that become critical for a user to perform their role. Before long, keeping up with all these disparate systems and keeping user attributes current becomes unmanageable. Most organizations recognize the problem and also recognize the need for a consolidated view of a user’s identity. It seems simple enough, but it takes planning, time and good processes to move an organization down the road to centralizing processes, automating synchronization, and removing redundant identity attributes from across the enterprise.

#2 – Account Provisioning

Creating an account on an appropriate system with the correct permissions is a straightforward task when you’ve been given the right information and you have the time to get it done. When a company grows to around 3,000 employees, the enterprise reaches a tipping point where going about this using people and manual effort becomes untenable. Too many requests for new accounts, or too many changes to existing accounts, or repeated requests to remove accounts for terminated employees all begin to pile up. This creates a backlog delaying new workers from getting started, hampering productivity, or creating security exposures where accounts of terminated employees remain active far too long.   Centralizing and/or standardizing the process can help but adding technology that provides automation will speed up the process along with enforcing identity standards, access entitlements, and important policies and standards. Automatic account removal of terminated employees is also a significant gain. All accounts on key systems can also be tied back to a central, validated user account eliminating unknown, orphaned user ids from across the enterprise.

#3 – Password Management

Password management activities face a similar challenge as an organization grows and adds more and more people, systems and applications. Initial steps should be to provide tools to help desk personnel centralize and automate this activity. Ultimately an organization needs to move this function away from the help desk and enable the end user to manage his own passwords on key systems, including resetting their own Active Directory password. This is another step that seems simple on the surface but can actually take a significant amount of planning and coordination to get it right and keep it running smoothly. Organizations that make a misstep on their first attempt find it difficult to gain user adoption the second (or third) time around. Eventually, standardized help desk procedures can assist the user community in adopting the self-service approach to managing passwords.

 

Identity integration, provisioning and password management are three essential building blocks, but there are another 8 – 10 key capabilities we could discuss that should be considered when talking about IAM maturity. What other capabilities would you consider to be essential building blocks? Please contribute to the discussion.

Up next, let’s talk about the essentials for planning a long-term, mature IAM program. If you’re just getting started or have been struggling to make progress, what are some of the keys to putting plans in place that can be effectively executed?

Realizing Rapid Value from Identity Management Provisioning

/0 Comments/in , , , /by

We’ve been working with most of the leading Identity Management/Provisioning tools since 2003. Most of the products have been acquired or rolled up into a larger suite of products. This process brought maturity, stability, and added investment to the industry. This helped the products and industry establish a place in the IT infrastructure that’s here to stay.

When we first meet with a prospective client we always ask the question, “What’s driving your need for provisioning?” Most organizations will talk first about audit compliance forcing these initiatives. And although this driver has finally elevated the effort to become a budget priority, the fact is that most companies wanted to do the project years ago simply to improve the overall security of the organization. And that can still be done pretty quickly.

So what if you’re one of those organizations that still can’t seem justify the project? Let me suggest you consider a streamlined, rapid approach that will enable you to realize value quickly — I mean in a matter of weeks vs. months or years! Read more