A common theme that runs through successful books and movies
is misdirection. Are the good guys really good and the bad guys really bad?
Identity is everything. In the real world, you do not want to be the good guy
who finds out at the end that your colleague or business partner was actually
an imposter. The same holds true for companies storing their data in the cloud.
Separating reality from fantasy and security from insecurity are fast becoming
the daily fare of CISOs and their cloud security strategies.
Public cloud service providers tout cost savings and
flexibility over on-premises data centers, but there is another oft-quoted
benefit they pitch enthusiastically: security. Marketers will tell you that
cloud services can protect your data and keep you compliant far better than you
can do so yourself because it is a core competency for them. But is it?
Ultimately, the service provider is responsible for protecting its investment —
the infrastructure. In the vast majority of cases, the owner of the data is
responsible for security of that data in the cloud, according to the fine print
of the terms of service.
the fine print of the terms of service. As a result, a
company must go to great efforts to authenticate the users who access its
assets properly or risk handing over data to an imposter.
While cloud authentication is a key component of the cloud
computing narrative, it is also notoriously difficult to implement, says Paul
Simmonds, CEO of the UK-based Global Identity Foundation. He helped create the
Jericho Forum in 2004, a global thought leadership group for CISOs, before
becoming the global CISO for AstraZeneca and Imperial Chemical Industries Plc
in the UK.
The Jericho Forum, now part of The Open Group’s Security
Forum, explored how security professionals should react to the erosion of
traditional network and organizational boundaries.
One of the biggest problems that the Jericho Forum
identified was the “locus of control,” determining if the forces that impact
security were internal or external to the organization. Identity and access
management (IAM) works well when everyone in the same organization is working
on the same systems, says Simmonds.
“If you can all play in the same locus of control – in other
words, you play with my identity system in this instance – then you can make it
work,” he says. “The instant you step outside this, it all goes to hell in a
hand basket.”
That makes cloud authentication difficult because
cloud-based services live in their own domains, separate to the customer’s and
outside of their control. The customer must send the appropriate authentication
information between its own domain and to each of the cloud providers it
employs.
There are a few ways to do this, says Simmonds. One approach
is to bolt together an on-premises program of your own that manages authentication
for many cloud-based services at once.
based services at once. Steve Biswanger, director of
information security at Alberta, Canada-based oil and gas company EnCana, began
the company’s cloud authentication 15 years ago exploring applications such as
health benefits and stock options. “We had different user names and passwords
for each one. The users really disliked that,” recalls Biswanger, who is also
president of the CISO division at the CIO Association of Canada.
EnCana procured an on-premises single sign-on (SSO) product
that kept user credentials in a local database. It authenticated users for
multiple applications at once by “credential stuffing” login details into
multiple web applications’ login forms. It was a low-tech approach, he recalls.
Providing locally-hosted SSO options seems to be a first
step for many organizations. Kim Tracy, now a visiting instructor of computer
science at Illinois Wesleyan University, helped put together the cloud
authentication system at Northeastern Illinois University (NEIU) where he was
CIO until 2015. Like many of his industry colleagues, he was coping with
legacy, on-premises applications alongside newer cloud options.
“We had a mix. Some of them were cloud-based, and they were
with different providers. That’s one of the things that makes it tough,” he
says.
Another complication was the range of users that he had to
serve. He had some 12,000 students and approximately 2,000 employees, but there
were also prospective students to handle.
Illinois Wesleyan University
“We hosted most of the basic credentials in our own local
directories,” says Tracy, adding that his infrastructure supported both Active
Directory and LDAP directories to support the different providers’
authentication mechanisms. The directory systems integrated with a locally
hosted SSO tool connected to an access portal. The SSO system interacted with
each application, cloud or on-prem, using custom integrations. “That’s a real
pain to host locally, and it’s a real pain to get enough staff that really understood
this stuff. We were always behind; as we lost staff it became even harder to
maintain,” he says.
Consolidating in the cloud
Some have taken a different approach to cloud authentication
by shifting some of their credential management and authentication capabilities
into a single cloud service, enabling it to access other applications inside
that cloud service provider’s domain.
Steve Vu, who manages leadership, management and enterprise
architecture for a large, enterprise software provider, began his Azure-based
authentication project using individual subscription accounts for the service.
The company wanted to let employees experiment with the system.
“Then we got an enterprise Azure enrollment that we tied to
our Microsoft enterprise software,” he explains. In this arrangement, companies
can list various departments within an enterprise enrollment, which in turn can
contain different accounts.
“To handle authentication, we tied in Active Directory
through our Office 365 service,” Vu says. That allowed users to access Office
365 and Azure via the same account.
The company replicated its on-premises directory with the
cloud-based Azure Active Directory, enabling Azure applications to authenticate
users directly in the cloud. It also enabled him to mirror the internal roles
that his employer had created for its employees into the cloud-based system.
Like Vu’s organization, EnCana migrated much of its
functionality to Azure using the service’s own Azure AD system to authenticate
its employees with other third-party cloud providers.
management and enterprise architecture,
a large enterprise software provider
“Now I can log into a service or modern SaaS apps using
modern authentication techniques,” says Biswanger. “From the user experience
perspective it all looks the same, but it’s a lot more resilient.”
This replaces credentialstuffing with more modern
authentication protocols that enable machines to speak to each other securely
and exchange a richer set of information, and it is an important part of the
modern cloud-based authentication process, says Clive Longbottom, founder of
UK-based tech advisory firm Quocirca.
“Keep away from simple username/ password pairs: use 2FA
(two-factor authentication) tokens, biometrics, whatever,” he says. “Try to use
passwords that even the user doesn’t have to know, either through SSO systems
, or via technologies such as OAuth.”
OAuth, managed by the Internet Engineering Task Force
(IETF), is a framework for authenticating and authorizing software to make
requests for an application programming interface (API). OAuth essentially
enables cloud applications to ask each other for services, and as such can be
used for many different online interactions. OAuth works at a relatively low
layer of the cloud user-authentication technology stack, and is a platform on
which to build other technologies.
One such technology is OpenID. Created by the non-profit
OpenID Foundation, OpenID is a vendor-independent authentication system for website
owners. Users can get OpenID credentials from various providers.
In an OpenID transaction, a website supporting the standard
(the “relying party”) gives a visitor the option to present their OpenID
credentials in the form of a URL. The browser directs the user to their
identity provider’s website, where they log in.
director of cybersecurity and data privacy governance,
Cyber Simplicity
Optionally, the relying party can ask the identity provider
for extra credentials such as name, age, gender or email address. In this
scenario, the identity provider allows the user to decide which information
they provide.
Once the user has authorized themselves for the relying
party via OpenID, they can then return and log in automatically without
re-authenticating. OpenID Connect is the latest version of this protocol and is
built atop OAuth 2.0. It serves web, mobile and JavaScript-based clients.
Consumer-facing websites along with enterprises and government organizations
use the technology, which can be extended to support optional features such as
encryption and session management.
Another common protocol used in cloud authentication is the
Security Assertion Markup Language (SAML 2.0). Created by standards body OASIS,
the protocol allows two domains to exchange authentication and authorization
data with each other.
Based on XML rather than more lightweight dataexchange
mechanisms such as REST (Representational State Transfer) and JSON (JavaScript
Object Notation), SAML performs broadly the same function as OpenID, but with
some important differences.
For example, whereas OpenID refers the relying party to an
identity provider, SAML 2.0 exchanges information between domains that already
trust each other and have an existing relationship.
Offloading cloud authentication via IDaaS
Some prefer to offload management of ID issues entirely to
an external provider. Putting the entire authentication process into the cloud
will become common practice, says Raef Meeuwisse, an ISACA governance expert
and author of Cybersecurity for Beginners, whose day job is director of
cybersecurity and data privacy governance at consulting firm Cyber Simplicity
in London.
“Most organizations can’t afford the security expertise and
the scale of technologies that they need to be able to run authentication
in-house,” he says, pointing to technologies such as multifactor authentication
and geo-detection as examples of how technologies are changing.
“Cloud authentication will be the thing that is running most
enterprises,” he continues. “Most enterprises will subscribe to one of a few
cloud authentication technologies, and that will be the way to go.”
NEIU is a case in point. After his departure, former NEIU
CIO Tracy says that the university cut through the whole tangled mess and
handed authentication over to an ID-as-a-Service (IDaaS) provider. It was only
possible at that point because thirdparty services had evolved to manage
identity in the cloud, Tracy argues. He cites not only simplicity but also
resilience as a benefit.
“Sometimes our directories or network connectivity would go
down. There had to be an ability to log in with cached credentials,” he says.
“This cloudbased ID management system could manage the timing between the
provisioning of the resources and the change of the password in the directory,
so you have fewer of those timing problems where something gets ten minutes
behind and (your users) can’t log in.”
A sense of entitlement
Even when shifting some functionality into the cloud, CISOs
often find themselves with challenges, one of which involves what GIFs Simmonds
calls “entitlements.” It is one thing to authenticate access to a cloud-based
application, but it is more complex to tell the application what the user is
entitled to do with it. On well-configured software, user privileges will vary
by role.
“The challenge is can I pass enough rich information out of
my identity system such that the entitlement layer in front of the cloud
service is capable of making a rules-based decision?” Simmonds asks. That
depends not only on the maturity of the IAM system, but also on the cloud
application’s ability to segment functionality based on those user
entitlements.
This is a challenge EnCana is still facing. It might have
moved some authentication functionality to Azure, but it still uses what he
calls a “redirection shim” to authenticate with third-party services that
reside outside the Azure cloud. He deals with approximately 70 separate cloud
services.
EnCana stores the credentials and the authorization for each
third-party, cloudbased application in a shadow account in the third-party
cloud service tied to the user’s account in Azure Active Directory. However,
when a user’s status and requirements change due to a promotion, transfer,
change of job responsibilities or other event, administrators must change their
authorization entitlements manually in each cloud application that the user can
access. Would it not be more efficient to do this centrally?
“On the surface that would be ideal,” says Biswanger, but he
argues that the problem is simply too complex. “Even when we’re doing internal
provisioning and I hire somebody, thinking about what they should have access
to is a reasonably complex enough bit of work, just for my company.”
Providing a consistent experience among internal and
external applications is another common pain point. EnCana has approximately
800 applications running internally on its own premises, aside from the
cloud-based applications.
“For anything that’s in the new authentication methods —
using OAuth- or SAMLbased authentication with assertion capability — it’s a
nice experience. It works on mobile devices, home devices and my corporate
desktop,” Biswanger says. “For anything that’s still in my datacenter,
sequestered from the Internet that doesn’t support modern authentication, that
is now the crappy experience.”
Another problem is managing identities from third-party
companies that have partnered with EnCana. A contractor might work for EnCana
and for five other companies. All those organizations could use the same
cloud-based directory service. One might think all of the systems could all log
on to each other’s systems using a single ID, but it typically does not work
that way. The contractor company’s employees must maintain multiple sets of
credentials — one to access their own employer’s systems and the others to log
into each of their customer’s computers.
“We need some mechanism by which when you work for an
outsourcing company, my company trusts the outsourcing company, and we only
have to manage (one) identity there,” Biswanger says.
He is describing federated identity, which as a concept has
been around for 15 years or more. It is a difficult concept to implement, says
Simmonds, and one problem is managing transitive trust.
For one thing, Company A might trust Company B, and Company
B might trust company C. Does that mean Company A can trust Company C? Then,
what if Company D joins?
“It’s what Jericho referred to as the n factorial problem —
once you get to n>3, it doesn’t work,” says Simmonds. “You need a huge
amount of independent oversight to make it possible.”
These cross-domain challenges are among the many reasons to
err on the side of caution when providing access to cloud applications, the
experts warn.
“Make sure that privileged access is provided to as few
people as possible and even where it is provided, try to ensure that those
users still do not have read/write activity to data that they should not see,”
says Longbottom. “Ensure that the means of access are not shared. It has to be
a case that any action can be drilled right down to a specific individual.”
Jeff Spivey, past board director of ISACA and CEO of
Charlotte-based security consulting firm Security Risk Management Inc.,
highlights governance as a key talking point when creating cloud-based
authentication products.
“From day one, audit must be involved in the whole process
to ensure that whatever is being constructed in the cloud is acceptable to the
auditors and executive management and the board of directors that own all of this,”
he says. Companies must decide the level of authentication necessary based on
the sensitivity of the cloud-based data that a user is accessing.
How can companies factor that level of governance and
risk-based policy into their cloud authentication strategies?
At EnCana, Biswanger is implementing a virtual identity
management layer to help with this issue. The on-premises software will
abstract the identity information from Azure and other identity data sources in
the organization, providing a more functional front-end interface that applies
locally defined policies and business logic to the authorization process.
“The dream there is that (it) allows me to log in based on
context and get different access,” he says. “I can apply those rules at
authentication time. It’s putting a lot more smarts at that identity layer.”
Cloud authentication might be difficult, but it is an
important part of the cloud computing story, and organizations should have both
the human resources and the budget to tackle it. An option is to use a
third-party service provider to manage it if the company cannot. It presents
part of the often-unacknowledged overhead associated with cloud security.
Allocate 10 percent of the savings you expect from a cloud
computing strategy and commit that to security management, advises Simmonds.
Cloud authentication will be a part of that budget. He recommends that
companies do the same for service management. Suddenly, those return on investment
figures might look less promising, but they will also be a lot more realistic.
0 Commentaires