Search
Nick Manson

SE Radio 547: Nicholas Manson on Identity Management for Cloud Applications

Nicholas Manson, a SaaS Architect with more than 2 decades of experience building cloud applications, speaks with host Kanchan Shringi about identity and access management requirements for cloud applications. They begin by examining what a digital identity is and then consider the technologies and tools that support identity management in cloud applications. The discussion then focuses on new developments in identity management and Identity-as-a-Service. The show ends with a review of processes that DevOps teams building and supporting cloud applications must incorporate to manage digital identities securely.


Show Notes

Other References

Transcript

Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.

Kanchan Shringi 00:00:17 Hi all, this is your host Kanchan Shringi. Welcome to this episode of Software Engineering Radio. We’re going to be talking with Nick Manson on identity management systems. Nick is an SaaS architect with over two decades of experience in building sales, service, and marketing applications. His projects have included big data and analytics, data science, mobile, customer relationship management, enterprise resource planning, commerce, call center, and content integration. Nicholas loves working with teams and staying on top of industry trends to build valuable services. This episode is from the perspective of Nick’s study and experience with identity management systems to architect several of Oracle’s cloud and mobile products. Nick, welcome to the show. Great to have you here. Is there anything else you’d like to add to your bio?

Nicholas Manson 00:01:09 No, you did an absolutely excellent job of that, Kanchan. Thanks a lot, and thanks for inviting me to Software Engineering Radio.

Kanchan Shringi 00:01:16 You’re welcome. Before we start, I’d like to mention a few related episodes we’ve done in the past. Episode 492, Sam Scott on Building a Consistent and Global Authorization Service; Episode 376, Justin Richer on API Security with OAuth2; and Episode 383, Neil Madden on Securing your API. So Nick, we work together over a decade ago on Siebel CRM On Demand, and I still remember your statement from then that the design of the system started with the user. So, I’d like to first jump into basic definitions. What is a digital identity, and what is identity management? And then I’ll have a follow up about how we actually use these technologies every day with what identities.

Nicholas Manson 00:02:09 Sure. A digital identity is an entity within a computer system that represents an external agent for the system. So that’s a two-part definition. For the entity, just think of a record and a data store. Most typical example, the digital identity will be a user record. So, we often just refer to digital identities within our systems as the users. For the external agent, think of a caller for your services. That might be a REST client or web browser that’s operated directly by the end user. When the external agent is manually operated, we often just skip it when we talk about it and just think of the user as being the agent. So digital identity, typical case a user has a digital identity that is a user record as mediated by a web browser agent. If we go on to identity management, identity management system, it’s just the part of your computer system that deals with establishing and managing digital identities. So, any application that knows something about individual users has some form of identity management in it, and some applications they’ll build that directly in without thinking about it, some are going to use embedded services, and many cloud applications will integrate an independent identity as a service provider.

Kanchan Shringi 00:03:43 So what are the different types of identities that we probably assume every day and use identity management technologies? Maybe starting with that will help with some of the follow-up questions.

Nicholas Manson 00:03:58 Sure. So most common case is cloud users. We encounter identity management, digital identity, whenever we establish an account for an online service. So, in that case the identity management system, it’s collecting that basic information about who we are. It’s allowing us to securely set a password, and it’s handling the login page. Those are the parts that we see. If you are looking at it from a developer perspective, just to flip the coin, we’ll encounter identity management when we wrap our webpages in a filter and have it redirect to a login page in order to get force to sign on before they can see what the server that’s providing. We’ll also run into it when we’re checking for authentication before running a service. So that might be checking a bearer token on a REST request or it might be looking at a session identifier on a webpage request.

Nicholas Manson 00:05:00 And then the last place we might run into it, once you’ve got authentication, once you have that identity off the bear token or the session, you might make a call out to an identity service to get further information about the user that you’re dealing with. So that’s the most common case. Now there’s a few others simpler but less common, organizations or business flows. They can have digital identities. So that case there’s normally a public-private key pair associated with some named, it’s often a business flow, but we’ll call it a partner organization. And the identity management system handles managing the public key to go with the private key so that when the organization’s agent sends a REST call to us, we can use that credential to check that the source is from the organization that we think it is. Another case, you can use identity management to track applications and devices.

Nicholas Manson 00:06:07 So bring your own device registration, it’s identity to management for devices. That’s one way to think of it. There are other things involved there, but it has a digital identity. It works a lot like the organization. Additionally, there can be a lot more complexity in the flow. Workforce identity management allows one of the registered people, one of the identities that you pick up, to serve as the manager for a group of employees and control the registration of the rest of the digital identities in their group. Banking systems use a digital identity in the banking system. There’s often a point where it says, well you’ve gone this far but you can’t go further until you come into the bank and show a teller your driver’s license, maybe a passport or your last hydro bill. So, there’s an actual know-your-customer component to that with a human workflow attached to the identity management in that onboarding process. And it’s very common for the identity management flow to be set up in complicated arrangements so that they’re federated, especially with enterprise computing, and in an enterprise computing situation, the enterprise will have an identity management system, you’ll have an identity management system, and your system will trust their system for identifying particular users.

Kanchan Shringi 00:07:45 So what do you mean by the enterprise and then you, what is ‘you’ in this case?

Nicholas Manson 00:07:51 Okay, so being that this is for engineers, when I say you, I’m typically thinking of you, the developer, and your service on the cloud. So, remembering again that most cloud applications have some idea who their users are.

Kanchan Shringi 00:08:10 So in this case, Nick, you’re actually alluding to two systems and that’s why you said there was federation. Can you clarify?

Nicholas Manson 00:08:18 Yeah, sure. So, cloud services often have some concept of their users; they’ll have some form of user management going on, and that’s really, it’s a very small identity management system. What happens in enterprise identity management — really usually in coordination with workforce identity management — is the identity management system will establish some rules under which it will accept users authenticated by a federated, separate identity management system that’s under control of someone else, entirely. So, in that case, the customer’s identity management system “big company” will have a list of employees and will be set up to assert those identities for your service’s identity management service. And your service will say I can receive identities from this system over here using this public key, and the identities I receive and allow must have the following characteristics. So, federation across two systems.

Kanchan Shringi 00:09:36 Okay, that makes sense. Thank you. So besides this, what are the goals of an identity management system? Where does access management fit in?

Nicholas Manson 00:09:46 Yeah, breaking that into two, this is where it begins to get a little bit more fun and a little bit less dry. So, fundamentally an identity management system, its purpose is to provide a basis for trust. If you think back in the beginning, it used to be that the person who ran an application was the person who created the data for the application and the person who produced the code — all together as one. And that’s been broken up, especially with cloud services. Three entirely separate people, multiple people working on the same data. We need a way to establish trust, and that’s what the identity management system does. It gives us confidence that the caller of our service — speaking from the point of view of a developer of a cloud service — is the user that we think they are, and we have an identifier for them that we can associate with the parts of our application, build rules around.

Nicholas Manson 00:10:50 So at the core it’s a very abstract goal. More concretely, its goal is to authenticate the user. So that’s the process where the caller has a secret and they use that secret to prove that they are who they claim to be. So that in the case of a regular login, the secret is a password. In the case of public-private key, they encrypt some token with the private key, send it up, public key decrypts and therefore knows that the sender had the private key in the first place without ever having to transmit. So, either way, the identity management system here at its core is a system for authenticating by handling that cryptography and providing a trustworthy digital identity at the end of it to the rest of the application. Now, if we layer on what’s normally you’ll see the acronym I-A-M, “identity and access management,” that layers on further services for authorization. So, authorizations the process where having an identity, we check if that identity the user can access particular parts of the system, particular functions, particular pieces of data. You’ll see this in the identity management service. They’ll often call that a scope or a privilege. The user has a privilege operating within a scope. I can read all financial records, there’s my privilege; the scope is financial records in this application.

Kanchan Shringi 00:12:40 Makes sense. We’ll touch upon some technologies for this little bit later in the episode, but I wanted to talk about a related topic with our anti management systems, which is trade-offs between the user experience and the actual goals of the identity management system, which as you said was making sure that we establish the trust and ensure that there’s authorization. Can you touch upon that?

Nicholas Manson 00:13:09 Yeah, there’s two things going on there. One thing, thinking of the identity management, the banking account situation, that’s certainly not convenient. The identity management eventually probably has you showing up at a bank teller and showing them documentation. That’s there because it’s really important to identify the person, and that’s going to work against the ease of use, which means there’s a bit of a ramp there. The rule is: use the identity management that’s appropriate to the data and process that you have, the thing that you’re securing. The more you have to know, the more you should do. If you’re really only looking to know that this is the same user that viewed this page last time, your identity management system might just be cookie tracking and nothing else. You might have no special code around it, aside from set cookie, get cookie, check the number, accept that as the person now on the far side you might all have all the way through workflow on the banking in the middle, people do things like they do caps to verify that the person creating account is a person that’ll work until the computers learn how to interpret the graphics, uh, too late.

Nicholas Manson 00:14:31 So caps are, they’re challenged at very least right now as a means of providing security, or they could be multi-factor. We’ll talk about I think probably later about multi-factor is a technology, but you’ll run into that in your phone, text messages when you log in. In order to validate that at very least you also have access to this phone number. So, the more you have to do to establish your identity, the bigger a ramp there is, and that can be a bit of a barrier. So, it’s a trade-off. Folks don’t like multi-factor if they’re trying to sell things, their shopping carts get abandoned. On the other hand, you can’t really accept the payment without knowing who’s providing it. At some level, you’ve got to have credit card or something so you can charge.

Kanchan Shringi 00:15:27 So your example of somebody having to go to the bank to prove identity is really in the signup stage, right? That’s where they are verifying who they are by actually physical presence. And of course, there’s a lot of fraud-detection technologies used during signup for services on the cloud. So, what is the spectrum between showing up at the bank and what’s implemented in the signup? You said credit card is one aspect of it. What else do people do to ensure that when you sign up you are who you say you are?

Nicholas Manson 00:16:05 There are various features. It will run a gamut. Certainly the bank teller, that’s your more extreme end and those processes can take days at their worst. Actually getting your passport is probably the root of all of that depending where you live. Stepping back, there are chains of building trust can go through things like you only have access if another person who knows you provides you with that access. So very manual. You yourself never get the ability to onboard; somebody onboards you. You probably get the ability to set your password because you don’t want two people knowing the password; that sort of breaks the system. If it’s a little bit more automated, they try things like introduce another factor: Do you have access to this phone number? Do you have access to this device? Do you have a pass card or a dongle, a little chip that gives a number when pressed based on a timer so that there’s effectively two passwords, one of which is in your head, the other of which is on a chip. And then there’s multi-factor and you start getting into other input devices, biometrics. And finally, getting less and less secure, text messages, a bit less secure, straight old password, and the conditions on your password itself can ramp up anything from, nowadays they try to get make you use 15 characters, mix alpha and numeric, et cetera.

Kanchan Shringi 00:17:51 So, we’ll dive into more detailed topics, but as we are wrapping up this introduction, I’d like just to ask my last question, which is, what is identity as a service? What does that mean as opposed to any identity management system?

Nicholas Manson 00:18:08 Right. So, remembering there’s a gamut here. As I said, you can just build it in, Hey I have a very, very vague idea of who the user is. I can tell the same person’s visited this webpage before. Not much else. That’s just a cookie. That’s it. Built in. Really nothing there at all. Stepping back a little, okay, I’ve got a whole identity management subsystem. It may be based on libraries, definitely is built on crypto libraries. I’m probably not coding those myself, compiled in or maybe I’ve gone a little bit further, created my own services. That’s been great and it’s worked pretty well. It was the industry standard for years. Federation stretched it a bit further. But now we’re in the microservice world. In the microservice world, identity management has split off entirely to become identity-as-a-service and that’s an identity management service — usually, a really well built out one — that’s run by someone else. So, someone else does the running and hosting. Big advantage there. Security is constantly moving. Having somebody else manage your hosted cryptography and your factors of authentication, your techniques, what’s going on out there, it’s going to be a big advantage for you because it reduces your part of that to just, all I have to do is conform to their API so I can recognize the identity when I receive it. So, identity-as-a-service, the microservice form of identity management.

Kanchan Shringi 00:19:52 Thank you for that. So, in this section, maybe let’s look at some of the technology and tools that have enabled the space. The first I had was SAML. Is that the right place to start ? Would you describe what SAML is?

Nicholas Manson 00:20:10 You could flip a coin. There’s a lot of ways to start. Probably what I would do is I’d start first with single-sign-on because that’s why you have SAML. So single-sign-on, the idea is I sign on with one identity, one password, and then every site I visit thereafter can use that authentication to do its identity management. So that’s the federation case. In that case, each individual site has its own little bit of identity management that trusts the federated single-sign-on identity management for identity under particular conditions that it sets. SAML is the original guy in this space. So SAML, it’s a specification involving identity providers and service providers. The identity provider in this is the identity management system; service provider, those are your individual cloud applications out there in the world. And they arrange to exchange public keys and patterns of interaction such that in the most common flow you’ll go to your end cloud service. It’ll say I need to authenticate this person and redirect them to a login page.

Nicholas Manson 00:21:36 That login page will be provided by your SAML provider, the identity provider at the SAML service. It will do the login page handling and send back a page with an assertion about the identity of the user that just logged in. Then the cloud application will take that identity, turn it into a current session, continue on. There’s also a form that works with just regular web service calls involving bearer tokens where it, basically, creates that end credential and sends it along with the service request. So that’s SAML. Going from there because I can sort of guess and because it’s so related, OAuth2 has pretty much replaced SAML with modern services. OAuth2, that’s what you’re seeing when some site says you can log in and create your account directly or you can sign in using Google, and you use your Google account.

Nicholas Manson 00:22:48 That’s OAuth2. OAuth2 has a two-legged and a three-legged form. The two-legged form, it looks a lot like SAML. There is an identity management system. It handles that login page. It’s got a trust relationship set up so that post the authentication on the login sends along a token this time JWT bearer token or usually a JWT, definitely a bearer token, on the header of your HTTP request. And the cloud application uses that in order to determine the identity of the caller. So, there’s also three legged OAuth, which it’s like it adds one more step in which the identity provider can actually, before finishing the login, can call out to that cloud provider and just check on the person, hey, I received a request for this person looks okay to me, what you think about it? You establish any state you need to do, do any checks you need to do, come back to me and then I’ll return login succeeded. So it gives the Cloud a bit more control over what’s going on potentially.

Kanchan Shringi 00:24:01 So this is definitely covered in detail and episode 376 on API security with OAuth2. However, as we’re talking about this, where does OpenID Connect fit in?

Nicholas Manson 00:24:14 So OpenID actually builds on OAuth2 and adds a few more things that you can do that is it’s main purpose in the universe. A few more things that you can do once you have the authenticated user. So extra calls to get the digital facts about the digital identity and supporting setup in the background for it. So think of it as an add-on.

Kanchan Shringi 00:24:39 Okay, so we talked about the SSO and how we started with SAML and then evolved to OAuth, and in response to some previous questions you did mention multi-factor authentication. Do you want to cover that in a little bit more detail now?

Nicholas Manson 00:24:57 It gets more exciting when you think about things that have changed. So just to take you there, multi-factor authentication. So, we’ve already talked about how you have multi-factor authentication. When your authentication provides two proofs that you are who you say you are; they’ve got to be independent from each other. It’s no use to ask a person for two passwords because heck, why not just make them give you a longer password? Same thing. Has to be two entirely different mechanisms, sources of truth. Most common one is a device in your possession and the password in your head. So multi-factor. Exciting in that there are some changes here. A standard called Fido2 is out there for what’s called password less authentication and it is in fact a form of multi-factor. So, there’s some room and change going on there, but boils down to the same thing: we have the identity of the device involved. What Fido2 does is it allows the device to register and for the device to handle login in an automated fashion and it stipulates that the device must, when it needs credentials, check with you.

Nicholas Manson 00:26:09 And because these are devices and our devices are better and better all the time, it can do things like check biometrics, your face, your fingerprint. So, we go from a secret in your head to a physical factor and a biometric, a personal factor, making the whole password experience both more seamless and really, really hard, much harder than just a simple password for someone else to figure out.

Kanchan Shringi 00:26:56 Things have certainly evolved in that area with this new technology. So, this is about authentication. These tools and technology support the authentication. In terms of access or access control, can you discover the broad spectrum of what policies are used there or what roles, what’s the difference between a policy-based system versus a role-based system?

Nicholas Manson 00:27:25 Yeah, so building up from, well all of these things sort of occurred all at once in real life. However, we really started the world most applications, once they get into access management, they start with really statements of privileges in terms of their authorization. So, I have the user, I know who he is, what can he do? Started out with this person, this digital identity, has the following permissions to do things in my system, privileges. He can read records, he can create records of this type, he can use this function. That was great, but there was a ton of privileges hanging around. Even a pretty simple application can quickly grow privileges, especially if you’ve been building for a few years. You start to get hundreds, thousands of these things. Significant functions that you might want one person to do where another person can’t.

Kanchan Shringi 00:28:27 Could you just give an example of a privilege?

Nicholas Manson 00:28:30 Can read a record of a type; that would be an example. So, to organize this all, people created roles. And roles they map that basically to your position in a business. So, a vice president could have the following permissions, vice presidents they can read financial records, frontline sales guy, maybe they can’t, maybe they can only create them, they can’t read them thereafter. So, role management, it grouped privileges into a container. It then gave that container the role to the individual. And you’ll find with identity management and identity and access management systems especially that people will split things up and they’ll often put the role in the identity and access management system and keep the privilege for their own cloud application. And that gives them the flexibility to add more privileges easily while having that role out there that people confederate and work with.

Nicholas Manson 00:29:40 And I have two VPs and 100 salespeople. Okay, so that’s the part that they wanted external as opposed to internal. That’s great. But the problem was we often have, especially data, that has attributes that are important to the way it is used. So, “ownership” would be the simplest case. So, what we did is we invented attribute-based access control ABAC. In attribute-based access control. We still have those privileges and permissions, but they’re relative to something that’s on the data itself. So as a vice president, I can read all financial records; as a director, I can read financial records in this division, and the division goes on the record and the rule for how you get this division, that goes into your system. So divisional read access would be my privilege. And the attribute that it’s based on is the division on the financial record.

Nicholas Manson 00:30:54 That’s great because you can tell I’m kind of hardcoding that all in there just to keep access space access control simple. So, really quickly people invented policy-based access control and what policy-based access control did is it said all right, now we need another component that’s going to provide a small little language interpreter, and that’s going to take our privileges and our attributes from access-based control, maybe our roles and we’re going to mix them all together and we’re going to allow operators. So, AND OR NOT, inclusion, exclusion based on attributes of the record and the user and the role all mixed together in a language with rules that get defined separately of the actual running system. You pass those factors in, it gives you an answer ‘yes no’ for you can do this, do this thing as this person with this piece of data. So, policy-based access control, and that really is now let’s call it the state of the art, but there’s even developments there. That’s certainly the most built-up form of authorization.

Kanchan Shringi 00:32:12 Thank you. Nick. So we’ve covered some of the technology that has spurred this space or, certainly been key requirements that have evolved now into identity management systems and identity-as-a-service. I’d like to now focus a little bit on what has changed in this space recently. So, you mentioned some key progress on multi-factor authentication, but my next question is going to be around a word that I hear more and more, which is zero trust. How is that related to identity management systems?

Nicholas Manson 00:32:51 Okay, so I would say that really has been two very exciting things and that Fido, that’s exciting thing number one. Exciting thing number two — and they play together and taken together they’re exciting because of a reason, and I’ll circle back to that. So, zero trust, that’s exciting thing number two. So, under zero trust, there’s the assumption we have when we write cloud applications that our cloud application is sitting behind a firewall and the firewall’s structured and it’s going to keep everything bad out. And that’s true and good and necessary. Don’t put a cloud application out there without putting some level of network protection around it. You won’t last long. However, it’s not great. There’s been a number of very public incidents where through social engineering people managed to get programs on the internal network of a company’s system. And because it’s sitting there in that internal network and because all of the internal applications, we’re trusting that firewall to protect them, that program had free run.

Nicholas Manson 00:34:08 So there’s been attacks on food supply, attacks on gas pipelines, all using these; attacks on banks in other countries, all using these mechanisms. Australia recently had a healthcare attack. So, what’s evolved in response is zero trust network architecture and zero trust philosophy. Under zero trust, your internal services behind that firewall they don’t trust their network anymore. They assume it’s entirely possible for someone to get an application, some agent onto that network, find their service and start making calls. So, zero trust requires that your internal services have authentication, have a strong sense of user identity, have a strong centralized service for user identity, and have multi-factor authentication in that the request, the caller, the device from which the call is being made, data possibly that’s being requested, and even what they call network intelligence, security intelligence — so, settings fed in by a system administrator possibly dynamically about other things they’ve discovered: hey this module’s been compromised — can control that access decision.

Nicholas Manson 00:35:29 So, zero trust really sophisticated takes it past that firewall. Doesn’t get rid of the firewall, but it means that our internal services as cloud providers are, they’re suitable for being exposed externally. They behave as if they are exposed externally. The US federal government has gone, let’s call it all-in on this. They’re a very strong advocate. The Office of Management and Budget has in their FedRAMP program, which is their set of standards for making purchasing decisions, especially related around security and management of cloud application services. They’ve set a set of zero trust security goals and required all federal agencies to meet them by 2024. And that includes every federal agency is expected to take one of their moderate internal applications and make it zero-trust internet-exposed as part of that deadline. So, real application at the federal government level. Governments are supposed to be slower than the rest of us. So, you can tell this is cross the chasm from early adopters into now big business is going this way.

Kanchan Shringi 00:36:59 How have all these regulations impacted the space? Has it just made it more imperative to use an identity management system rather than a homegrown approach? Or is there more?

Nicholas Manson 00:37:12 So, I mean there’s really been two things going on in that when it comes to consumer identity, the regulation has been really important for driving up the standard. It’s know you want to be really careful about how you’re dealing with your identity because if you fall behind, a government with a just a regular person’s identity, the government will stand up for them and come after you. So that’s a big deep pocket that will come in and fine you. So, it becomes a real business concern in your cloud to keep right up to date. If you’re not confident with doing that yourself, you’re probably wise to get an identity-as-a-service and an identity management system. That’s one factor. The other factor on the enterprise side — setting aside the medium ground of the government itself and FedRAMP — on the enterprise side, people have to buy insurance for their risks, and there’s been a lot of security issues lately.

Nicholas Manson 00:38:17 So what’s happened is the insurance rates for cybersecurity have doubled in the last year, approximately. Talking to people in the industry, I know of companies I have talked with people who, because of their insurance needs and their need to have operating insurance for their business while maintaining internet connection, using the internet as part of their business, not as a software provider, in a completely separate industry, the insurance has forced them to move from having an internal IT shop for everything to using a cloud provider because the Cloud provider can provide a workup of ISO to 7001. It can make the standards and certifications. It has the backing to do security incident event management. So, SIEM, S I E M, you run into that. So, the Cloud provider is basically being forced on — forced is a strong word, but strongly indicated — if you want to keep your insurance policy affordable and that’s passed, that’s already happened.

Nicholas Manson 00:39:37 Now they’re coming back and doing their renewals and the insurance provider’s saying that great, but have you turn on multi-factor authentication? And when zero trust is out there, they’re going to say that’s great, but is your provider or all of your providers zero trust. And if you can’t do those things, they’re not going to cover you. And if you have even the slightest wrapping over top of it, your service is dependent on their services and you have due diligence responsibility to ensure that they’re doing their part and then you are doing your little part on top of it. So, the whole world is pushing towards professionalization of identity management. Kind of long past for crypto. You can make up your own crypto or, but a regulator’s not going to accept it until you sit down and you prove it very rigidly. So, it just doesn’t happen anymore. They get mathematicians to do it.

Kanchan Shringi 00:40:39 So there are multiple vendors. So, this next question is from standpoint of an enterprise that is using multiple cloud applications, multiple SaaS applications, what is the experience there? Like if I have SaaS applications from multiple vendors, is there any attempt to have a common identity management system? Or is it a fact of life that you would have different identities for each of these?

Nicholas Manson 00:41:06 Well, remembering that your digital identity, it’s just a record, right? Don’t get too hung up on one identity being one record. I can be represented in many, many, many records, each saying something slightly different about me, but it would still be my one identity as long as I’ve got single sign on that brings me between those identity management systems. And that’s what’s happening in the situation where two windows, one identity; if it’s actually two windows in a browser, one identity, there’s a thing called CSRF, C S R F that they try not to allow data to pass between two windows. It can lead to certain kinds of attacks and there are countermeasures, but it is very common for one internet application to have an interface that directly or indirectly brings up services from another internet application and then uses single sign-on, uses federated identities at some level, to access both services in some orchestration or coordination of work. You’re going to run into this really commonly; as developers, we’re all really used to this now. If we’re using one of the big cloud providers, they all now have tens, some maybe over hundreds of services that all have a single point of authentication. Each one of those individual services knows something about you as a user, but there’s one identity and access management system for setting up the cloud that operates across all of them.

Kanchan Shringi 00:42:53 Let’s talk a little bit from the perspective of the developers and the teams for the next few minutes. Has that changed the structure of the teams? We structure nowadays as DevOps team where there’s a certain level of expertise expected within the team, but there can be central teams as well. Has all this evolution changed how teams are structured and what is needed from the devs and ops folks on the teams?

Nicholas Manson 00:43:21 So, way back in the day, you’ll definitely remember that I burned you guys in security a lot. I burned all my teams continuously on security a lot. And I think that’s the world we’re in. So, the term people use is DevSecOps. I have to admit, I’m not a big fan of the term DevSecOps because I’ve always believed if you’re doing development and operations, you had better be doing security from the very get-go. And that remains true. That’s one factor going on here that remains true. So serious development, serious operations, you should be building in security. So, from the DevSecOps practice means that there are a few things that you should be doing with respect to identity management. First of all, think of your cloud application, break it into its two main parts: there’s a control plane and there’s a data plane. Back up to the basics of cloud theory here, control plane, that’s the thing that can start stop services, install applications, control resources, manage network configuration, set up how the application behaves. Your data plane takes those policies, runs them against data.

Nicholas Manson 00:44:37 So it’s a much more static in terms of the components it runs. It uses rules to decide how many compute nodes are going to be running this process or that process. And it only accepts data from these sources, and it only serves data to these other things. You’ll want to look at your Cloud platform providing an identity management system, built in an identity management capabilities that are strong, preferably multi-factor, with a strong amount of physical ownership. So, often it has been up to now dongles, but Fido’s going to start playing in there. Things like pass cards by dongle, some physical device, a reader on your system, a USB chip you plug in, it gives you a dynamically generated password that changes over time and therefore very hard to replicate. You’ll need that in your control plane. You should not build a cloud-facing application without that level of strength.

Nicholas Manson 00:45:50 Good news: really easy to do. All the major Cloud providers are already doing that. And if your Cloud provider doesn’t provide a service that allows it, you’re going to find that there are great vendors out there that provide systems that you can install to add that level of access control on your control plate. Secondly, well first before I step off that DevOps-wise, this means that your very first thing you’re doing, you’re setting up your development environment, you’re already in identity and access management. Don’t skip on that section, pay attention to it, set it up so that you have proper security control. It’s going to be good experience for you moving forward, and your teams are going to have to know how to interact with their cloud platform’s console, which means interacting with its security. So yeah, it’s got harder, the skills have gotten different, but also cloud platforms are there, and in a way they’re making it easier again.

Nicholas Manson 00:46:51 So they are taking a lot of the professional level of identity management for the control plane and they’re putting it in the provider itself. Second thing, it’s a really good time identity management-wise to start thinking about zero trust. If you’re building applications for the federal government, you’re already looking at FedRAMP and you’re probably already looking at this. Now there are vendors out there and people are in the process of building their zero trust offerings. But it’s a good time to start looking and to start thinking about if I’m building a microservice, it used to be that I would set it up and not authenticate at all. Hey, it’s on an internal network, nothing will ever reach this thing except for my friend who’s in the cubicle beside me, who’s writing another service, who’s going to call mine. That’s just: stop thinking that way.

Nicholas Manson 00:47:47 Start thinking about your microservices need authentication. That’s got to be built into them. And that now means that the smallest component that you have in your Cloud architecture has authentication in front of it, knows who that user is and is dealing possibly with a policy management system for its authorization. So, look for those components or the capability to introduce those components. And think about the parts of your system that you’re hand building right now that you may want to refactor and replace later. Don’t overbuild; build for what you need, but definitely now’s the time to start thinking of it, except if you’re in FedRAMP: time to start doing.

Kanchan Shringi 00:48:34 So. You mentioned SIEM, or security information and event management. What else should people be thinking about in terms of monitoring and analysis and risk management?

Nicholas Manson 00:48:48 Yeah, you’re thinking exactly along the same lines as me. So, third thing you should think about doing security incident event management. So, what that is, is no matter what you do, you should start with the assumption that somebody’s going to abuse your system. And that might actually be a straight outright attack. Or it might be that your system, you’ve built something that it kind of feels like, hmm, you miss something. It almost feels like an attack when the customer goes and uses it. So, the one I’ve encountered not a lot by have encountered: put in a service, customers use it in a way and at a frequency you never anticipated. It DOSes you. Your system’s now in a recovery mode, re receiving extreme usage. Is this an attack or is it not? Security incident event management. You have to start by building in. When you build your applications, the assumption that abuse is going to occur and you’re going to have to track it back to the agent that is the source of the abuse, and preferably track it back to a person and what’s more, you’re going to need to stop that person, that agent, without stopping everyone.

Nicholas Manson 00:50:14 So build that in now. Your development team should be thinking about, hey, when the abuse comes, we check here. And then if we find abuse, we look here to see how to isolate it, and then we go here to turn that off, leave everything else running.

Kanchan Shringi 00:50:34 Makes sense. It’s a lot of ground.

Nicholas Manson 00:50:39 It’s a lot to do. It seems like a lot to do. You’ve got platform engineering coming along after you and they’ve definitely picked up the Cloud side. So, what you really need to do is think about how you’re going to fit into those pieces. There are logging tools out there that will help you with the log capture and secure management of logs for SIEM. There are consoles out there that will help you monitor usage, pick up on events that occur. So, it’s really a matter of figuring out how does your application, in its own running, surface events and logs that allow you to trace back. So, it’s really much more closely related to what you were actually doing in the first place. You’ve just got to buy the components and make your application use them.

Kanchan Shringi 00:51:31 So starting to wrap up now, Nick, if you evaluate INT management platform vendors, how do you do that? What steps do you use?

Nicholas Manson 00:51:40 So I basically, I divided in three. The very first thing you’ve got to think about is your cloud platform. Your identity and access management for your Cloud platform, the infrastructure on which you’re running your application, that’s a requirement. Start there. If you don’t have it, then that’s disqualifying. You can’t use that platform; it’s got to change or you’ve got to switch platforms. As I’ve said, that’s actually pretty easy. The major cloud platforms, they’re well ahead of us here and they’ve already set it up such that you can, so it’s a matter of exercising. Next level down, think about your internal network architecture. This is fairly new and recent. Think about how your individual services are going to integrate into your identity management system, your logging system — although that’s somewhat separate for SIEM. Ease of use is a big concern there. You’re going to want to prototype and figure out what you’re using.

Nicholas Manson 00:52:45 If you’re building exclusively for one Cloud platform, you may have strong indicators in terms of what you’re doing there already in the family of applications that that system provides. But people have been substituting components, and one of the big drivers is ease of use. Regardless, stop picking components that are going to prevent you from doing this. Stop writing code that’s going to prevent you from eventually achieving zero trust. It’s coming. Then last — not necessarily in that order, think of all three at the same time– external authentication: how are you going to meet the users where they are? What is the level of identity management that’s appropriate for the data that you’re handling and the processing that you’re providing? Don’t undervalue your data. If you’re building an internet service, you’re building a cloud application, there’s something about it that’s valuable, right? So, think about what it would mean if that data was compromised, corrupted, if a password is lost, if somebody just circumvented the whole thing.

Nicholas Manson 00:54:02 Think about that. Think about how you provide your customers with the ability to sign in in a smooth way, and what identity management system they’re using. So, a lot of authentication, people are signing on using Google or Facebook or one of the other major Internet applications. They have an identity-as-a-service provider there. It integrates often using OAuth. You want pickup. Provide that on top of your basic authentication if you’re going to allow people to sign in without going through that system. And if you’re dealing with enterprises, you should think about, well, if they buy one of the big identity providers and they decide to federate with me, does my identity management system support that federation? Is it giving me the right amount of policy control such that I can take that enterprise and provide a cloud service to them and continue to provide cloud services to other enterprises who might decide to approach this whole thing differently?

Nicholas Manson 00:55:15 Other identity management, using your identity management, could be many things. So, look at all three, break it down that way. Do consider cycle time, ease of development. That remains very, very important. If you can’t turn out software because you can’t get the APIs to work, that’s a big concern. But try to pick your components to enable that internal network authentication, or at least have a roadmap to it to provide strong platform authentication and to meet that customer where they are in their identity management. Whether it’s they individually in a Fido2 or they as an organization with a SAML identity provider, wanting you to be a SAML service provider.

Kanchan Shringi 00:56:04 Thank you, Nick. So how should folks contact you?

Nicholas Manson 00:56:08 Easiest way to reach out to me is via my LinkedIn profile. That’s Nicholas Manson, N-I-C-H-O-L-A-S-M-A-N-S-O-N at LinkedIn.

Kanchan Shringi 00:56:17 Okay, sounds great. Will try to put that in the show notes. Is there anything you’d like to cover that we haven’t talked about today on this topic?

Nicholas Manson 00:56:27 There are a ton of things in security that we could discuss. Once you’ve picked your platform, and as part of considering the platform that you’re developing in, pick up their best practice documents, give it a good read. Remember that everything you develop and all of security gets a lot easier if you do it early. This is one of those places where debt just piles up real quick, and it can prevent you from releasing. And it can do it the very last moment and with a lot of pushback from an auditor if you’re going to try to do an ISO27001 standard certification. So, instead pick up the best practices, start implementing right away. Think of it as everything that isn’t a regular day-to-day thing that the operators do via standard operating procedure. That’s development. Pick it up then; do it then. Otherwise, have a lot of fun with this. Of course, security is of course the part we’re all anxious to write. Yeah, take it seriously, push it forward. It won’t be as bad as you think.

Kanchan Shringi 00:57:42 Sounds great. Thank you so much for being on the show today. It was great talking to you on this complex topic.

Nicholas Manson 00:57:48 Yeah, thanks a lot, Kanchan. It was great being here.

Kanchan Shringi 00:57:50 Thanks all for listening. [End of Audio]


SE Radio theme: “Broken Reality” by Kevin MacLeod (incompetech.com — Licensed under Creative Commons: By Attribution 3.0)

Join the discussion

More from this show