In many cases, using “software” today can be very simple. However, software engineering—the process of designing, building and deploying it—is becoming more complex with every new release. Most software engineers build software for a customer to help solve a problem. This means not only knowing the nature of the problem, but also knowing the nature of the customer. Many business scenarios require vendors to understand their customers, which also means they need to understand the context by which they need your product or service to solve a problem. To effectively accomplish this, you must think about how you are defining and managing “identities.” It can seem easy to many, but it’s one of the main tenets of heightened cybersecurity.

For your solution to solve your customer’s problems, you need to know what your solutions need to know about them (and their relationships mentioned above). And you need to have a clear understanding of how you are going to protect that information. This is done through a process known as Identity and Access Management (IAM).

If you were able to travel a few years back in time and ask your software teams what “IAM” means to them, they would probably say, “That’s user IDs and passwords, nothing more.” For a very long time those words alone would have been an adequate definition. The customer (or user) provides a user ID and a password that they’ve shared with you in the past and your solution checks to confirm those details as the proper credentials for “valid users.” Then you provide that user access to access your system, and (hopefully) your solution provides some guidelines (often called “roles”) for what users can view within your solution. That’s how most software engineers think about IAM today – “That’s handled by someone else in the Infrastructure Group.” Or, “I think they use Active Directory.” Or, “Don’t talk to me about that; I have features to get out.”

Today’s software teams can’t operate with that same lack of understanding for IAM, because in today’s environments, we build software in ways most executive business magazines would call “a digitally connected world.” Now, I have to point out that this phrase means a lot more than what we often take it to mean. Why? Because of all of the connectivity and data sharing required for a modern application to help your users solve a problem. To have an application work correctly, it is common to leverage services from another application that depends on user identification provided in a specific way. Think about all the software that enables you to buy a concert ticket. Does your ticketing app manage the payment? No, the credit card company does. (And even then, it usually outsources that process to a bank.) Does your ticketing app track all of the available seats in an arena, including the pricing tiers and stage views? No, the venue itself provides that. Does it provide you with a digital ticket that you show to the box office to get into the venue? Again, probably not on its own, and all of these applications need to trust each other and the details of the identity-related information that is shared to buy that ticket and show it to the box office or usher.

To make a well-connected, full-service application work in this digitally connected world, you have to know and share a variety of information in secure, well-established ways. This includes:

• How your users are expected to prove who they say they are
• What systems you need to connect with
• How to challenge and respond to queries to confirm identities and assets
• What data must be visible, hidden or shared to help your customers solve their problems
• Where “trust boundaries” exist and how they could be exploited by a malicious actor

All of that is done through a chain-of-trust that is “modern IAM.”

To many of us, these subsystems are visible ones. Want to connect to a website that needs a user account to remember you next time? Just use your Google ID! Need to prove it’s really you to your bank’s customer service department? Use a one-time-only passcode sent to your mobile phone! Does your computer ask if you want to store your user credentials in your private password manager or in your browser’s password “vault?” Just click OK!

But, what’s the problem here?  Simply, providing this level of IAM has implications on how you build software today and how you prepare for future changes. Making weak decisions about something as serious as IAM will expose your solution—and your customer’s identity and data—to people who could be hacking your system and harvesting your data. And you would never know it because, to you, they can look just like your normal customer/user. If bad actors can get those digital credentials, they can break that chain of trust, impersonate a valid user and begin to compromise, corrupt and collect data from your internal teams, your partners and your customers.

The process of creating and sharing your digital identity is built on technology that establishes a level of digital trust. Without it, you really can’t trust anything. Just like the old cartoon of two dogs in the office talking said: “On the internet, no one knows you’re a dog.” To address this, companies that create secure software embrace the implications of that cartoon while recognizing the complexity of the problem. They use a name for this situation that you will hear more and more about in the future: Zero Trust.

With guidance from subject matter experts at our long-standing partner Microsoft, as well as with our own internal SMEs, we are adopting that zero trust paradigm at Altera Digital Health. I can tell you that it is an entirely new and more secure way to think about not only the nuances of IAM, but also how you build a solution that respects the trusted relations we’ve established with our customers today and for the future. Stay tuned for more on this concept as we take a deep dive into zero trust and its implications for healthcare.