Like many others, your organization is moving applications and resources to the cloud as part of a broader digital transformation. But it’s not enough to move to the cloud; you need to secure the cloud as well.
But how do you do this when your company subscribes to dozens of cloud applications like Office 365, G Suite, Salesforce, and Box? How do you ensure that these apps all fall in line with your org’s security and compliance requirements?
This may all sound overwhelming, but you can address these concerns in 3 simple steps:
Your first step is to review the gaps within your current IAM (Identity and Access Management) environment and use that information to define your future requirements. Take inventory of your current policies and infrastructure so you can better understand the costs and benefits of a new IAM solution.
Ask yourself the following questions:
What apps are your users utilizing today? Which users and groups need to authenticate with which resources?
When considering your users, be sure to look beyond just your employees, and include your extended enterprise. Who that is depends on the nature of your business. For instance, if you’re a manufacturer, it might include suppliers and distributors. Or, if you’re a retailer, it might include temporary seasonal staff.
What “Shadow IT” apps have been implemented outside of IT’s control? Who is using them?
What is your current process for managing employee entitlements and provisioning new user access?
What is your current process for off-boarding former users? How confident do you feel that you are offboarding all users from all apps?
What are the current support and administrative costs related to managing user identities and access?
Once you’ve answered the questions from step one, you’ll have most of what you need to start researching solutions. Here are some key factors to consider:
Perhaps your enterprise relies on Active Directory and LDAP directory running on-premise. You may even have an on-premises legacy IAM solution. Administration of your users’ access to cloud applications through these is possible but probably very difficult.
So your cloud IAM solution needs to have strong integration with on-prem Active Directory and LDAP. It needs to operate smoothly with AD and LDAP, providing real-time, bi-directional synchronization of users, their attributes, and their groups from your on-prem directories to your cloud IAM directory. And it needs to smoothly merge multiple directories into a single, unified cloud directory.
Identity management is a critical part of your IT infrastructure, and plays an even more important role as these services move to the cloud. The idea of outsourcing this foundational element of your application strategy requires some diligence in understanding your cloud provider’s commitment to protecting your data and embracing practices to mitigate those risks associated with an outsourced service.
Establishing trust with your vendor selection is critical. You can separate trust into a few areas: compliance, accountability, and redundancy. Here’s how to evaluate each.
To measure compliance, here is a checklist of items to look for in a cloud IAM vendor:
- Has the vendor been audited by third parties as part of a SOC 1, SOC 2, or other compliance framework?
- Do they adhere to globally recognized standards such as ISO 27001, 27017, and 27018?
- Do they take steps to safeguard personal information by participating in Safe Harbor, TRUSTe, and GDPR?
- Do they regularly run penetration tests, network scans, and bug bounty programs?
- Can they speak to their compliance with other initiatives such HIPAA, FFIEC / GLBA, NIST Cybersecurity Framework, FERPA, and the UK’s G-Cloud?
Accountability is a key part of establishing trust. To that end, ask your vendor the following:
- Do they contractually commit to an SLA both for overall service availability, and for support responsiveness? Are these SLAs acceptable to you given your business needs? Remember: an SLA of 99.9% uptime might sound great, but lets a vendor get away with over eight of hours of downtime a year. What happens if those eight hours happen to fall on your busiest day of the year?
- Do they display their overall uptime and provide historical tracking of not just full-service outages, but also performance degradation, feature disruptions, and planned downtime? This demonstrates that they are committed to transparency in their SLA reporting.
- Do they report on the root cause analysis of their outages? This shows that their operations team has a culture of accountability and continuous improvement.
Redundancy is key for a cloud identity vendor. If your cloud IAM vendor is down, you can’t access their single sign-on portal, and thus you’re shut out of your applications. So, ask the following to determine if your vendor has a culture of redundancy:
- Do they run their service in multiple, geographically separate regions? Running in multiple geographies means that if there’s a natural disaster in one area, the service should continue running smoothly in other geographic regions.
- Do they have a single, monolithic codebase, or do they split their code into smaller chunks, typically called microservices? Microservices are considered more reliable; if one microservice crashes, they typically don’t bring down other microservices. And they can be restarted much more quickly if necessary.
- Do they use multiple DNS providers? This is crucial, since distributed denial of service attacks (DDoS) on DNS providers are the Achilles’ heel of Internet infrastructure and have brought down large portions of the web.
- Do they support redundant instances of connectors to on-prem directories? This ensures that your cloud directory is always syncing with your on-prem directories.
You should expect both your IAM and cloud application providers to support these open standards. They provide you with greater vendor choice when moving to cloud IAM, and greater flexibility to move to a different IAM vendor if you’re not happy with your initial decision. A quick overview of each of these standards and why they matter to an IAM buyer:
- SAML and OpenID Connect are application authentication standards that can be used to securely log into an application from a single sign-on portal.
- SCIM is an application user provisioning standard. It provides an easy way for IAM providers to create new user accounts in an application based on identities in your directory.
- OAuth allows you to use social sign-in, to log into a single sign-on portal using credentials from a social network such as Facebook, Twitter, Google, or LinkedIn.
- TOTP is a standard for multifactor authentication (MFA) that lets you use a range of MFA applications as an additional authentication factor to access a single sign-on portal.
While custom connectors may be required to connect “must have” apps to your cloud IAM, these should ideally be the exception to the rule.
Subscription-based pricing associated with SaaS models like Cloud IAM differ from traditional perpetual licensing and maintenance models. Many organizations view subscription models as an advantage because it moves the cost from capital to the operations budgets, and includes the ongoing maintenance of the system.
It’s reasonable to assume that many support and IT costs (in terms of both time and money) will decrease after the adoption of an IAM solution. With a federated view across your cloud app environment, an IAM solution creates many ancillary savings. For example, because IAM solutions can report on how many users are actively running specific apps at any one time, organizations can recognize when they’ve over-provisioned an app, and can adjust app permissions accordingly.
Your IAM provider should also be willing to provide an ROI calculator, explaining how their solution can provide measurable, quantified value to your organization.
The key to a successful implementation includes engaging the right stakeholders early, driving toward achievable milestones supporting early successes, and then expanding the reach and scope of your solution. Stakeholders might include representatives from your line of business, security, network, compliance, and human resource teams.
All IT projects are better off for having cooperation and buy-in from other parts of the company. This is especially true for IAM, as it affects nearly everyone. Approach it step-by-step, carefully ensuring that things are working correctly, and others will see the value to them.
Consider these strategies for charting the path of your rollout:
You must plan on the pre-requisite exercise of mapping your legacy directory groups and attributes into your new cloud directory and defining new roles and application entitlements. Engage your stakeholders in resolving what data is important. For example, do you plan to include employee’s mobile number field to take advantage of any SMS forgotten password features?
SSO (Single Sign-On)
The greatest and most obvious benefit of a good IAM implementation to both users and IT is enterprise single sign-on. Implement this feature to gain immediate productivity gains. Make sure users understand the SSO experience and the benefits it provides. This can be achieved through an internal communication plan that highlights the benefits of this new deployment to employees.
You may also want to consider taking the above steps with just one part of the organization initially, perhaps a single Active Directory Organizational Unit, before moving on. You can pay extra attention to that test project and move other groups over when you have the system running smoothly.
MFA (multi-factor authentication)
As SSO gains acceptance and the federation of cloud apps begins, the need to better secure the authentication process emerges. IAM greatly eases the work involved in implementing multi-factor authentication, yet it increases demands on the end user to implement additional authentication factors. You may need to implement some of this at the same time you implement enterprise SSO, but a good second step would be to expand the use of multi-factor authentication after the SSO capabilities are rolled out successfully.
It’s important to note that not all MFA options are created equal. For instance, SMS is no longer considered an ideal MFA option, since hackers have been able to socially engineer mobile carriers into porting phone numbers — and their SMS messages — to mobile devices that they control. Additionally, SMS codes can be stolen by compromised telco employees, using a form of man-in-the-middle attack. You want to choose an MFA solution that provides end-to-end encryption from your IAM to the MFA app, making it impossible to perform a re-routing or man-in-the-middle attack.
Provisioning Streamlining employee onboarding represents a growing focus within enterprises. Provisioning applications from the IAM system is the most common means of achieving this. However, consider the need to support HR-driven identity workflow integrations as part of the company processes for introducing new hires to company resources. These can include integrations with popular Human Capital Management (HCM) software such as Workday, Ultipro, and Namely. Other departments, such as Human Resources, should probably be involved in this step. You may be able to integrate user provisioning/de-provisioning from HCM systems through the IAM system for onboarding/offboarding. By using your HCM system as the primary source of truth, you’ll save time for your IT admins, while ensuring reliable on- and off-boarding.
Corporate laptops hold a large amount of corporate data, but unfortunately aren’t always subject to the same strict password policies that govern corporate apps. This is a problem when laptops are stolen, which happens about once a minute on average. Consider when you want to allow users to log into Windows and Mac laptops using the same credentials as their SSO portal. You’ll extend strong password policies to your laptops, and your users will love having one less password to remember.
IAM vendors focus on security at the time of login, while CASBs focus on security after the login. Why does this matter? Consider a user whose account has been hijacked by a hacker. The hacker starts downloading excessive amounts of confidential company data. A CASB can detect this and have an IAM solution deactivate the compromised account. CASBs can detect other types of security issues as well. So, determine when to integrate your cloud IAM with CASBs such as CloudLock or SkyHigh.
When a security breach happens, an infosec team often uses their SIEM to scour terabytes of data to determine the cause and extent of the breach. SIEM’s pull in log data from a broad range of security software and cloud resources, and make them instantly searchable; think “Google for machine data.” To enable your security team to connect the dots, it is essential for IAM data to be part of this data set. For these reasons, consider when to integrate your IAM vendor with your SIEM, such as Splunk, Elastic, or Sumo Logic.
Extending your IAM practices to support the growing cloud application environment within your organization does not need to be a large rip-and-replace exercise. The adage, evolution over revolution, can be applied. We hope this simple framework will serve you in advancing your cloud identity services in a thoughtful manner.
Please contact us with questions around any of these steps.