Importance of Defining Authoritative Sources

In a previous post, I covered The Importance of Defining Credential Types
and how you need to define what attributes you need to store in your IBoR

In this post, I want to cover Identity types and Authoritative Sources (AS). For any system, you need to ensure that you use a consistent source as accurate. What you don't want, is to use the network as a book of record.

Authoritative Sources, Identities and Credential mapping

For each identity type, there is usually one or more authoritative sources available. Each source contains different "characteristics" you may wish to store in your IBoR for identity verification. For example, HR system may be an authoritative source of employee information, but the inventory system maintains the workstation ID of the user. If you wish to use this workstation ID for identity verification, hook it in as you would any microservices API or centralized DB.

Make sure you cover all credential types. If no authoritative source exists, you need to create one. This is were intake systems and approvals become necessary.

This is usually the first step in building out identity governance and an Identity centric approach to security.

Something you know, something you have, something you are.

Most IAM people will repeat this phrase in a heartbeat. "Something you know, something you have, something you are". These are things than can be used to authenticate an identity. Put in a different way, these are things that can allow you to build the required trust to grant access.

Policy decision points use authenticate credentials based on the number of attributes available to them. A single attribute, like something you know (e.g a password secret), can give some minor level of trust. Each attribute may not have the same weighting for building trust. An 8 character secret is not as secure as a 2014-bit key, yet both may be vulnerable if poorly stored. Given the same level of trust, the number of attributes authenticated would be exponential. For example, 1 factor or attribute authenticated is 1x1=1 and 2FA is 2x2=4 times, 3FA would be 3x3 or 9 times the trust of 1FA.  

In the digital world, we often make binary decisions, if this, then that, when real life we have hundreds of attributes we take for granted and use as references for trusting someone is who they say they are. This I discussed in the post The "Identity Bottleneck. You are a sentry, and someone approaches and you challenge them " halt, who goes there", and the person responds with a password, is that enough? What if the person does not speak any of your languages, is wearing clothes of the enemy and you don't recognize them? Would you require a second proof of identity?  But in the digital world, how are these factors created, stored and used?

There is much hype around MFA, biometrics and policy decision points and the death of the password. What I wanted to highlight though was the trend towards contextual characteristics. In the real world, this would amount to identifying someone based on their relationship to something else. The first one, the one to the left, the one standing. Something marketing and advertising have lead with. Where did your connection come from, is the machine ID known, is there an existing cookie. 

Let's say you have an old application limited to 8 character passwords for authentication, could you use 1 of more contextual characteristics to improve identity trust? What is the IP, what is the machine ID, do they know the password...

Are you putting enough focus on IAM?

I wanted to create my own Identity Centric Security Framework as I  believe the industry has been slow to grasp the changes in security over the last 10+ years and security organizations are not yet focused on Identity and Access Management as they should. Thanks to the number of audit findings in the IAM space, some organizations are starting to look at IAM in a new way, but with IAM in a small box in a legacy framework, it often does not get the focus it should. The result is budgets are usually spread between "boxes" in the framework or given to the team that shouts the loudest.

This is somewhat surprising given the causes of breaches. If you have ever tried to recover a drive that book sector is corrupted beyond repair, you will realize that data has no use, unless you cannot access it. Identity is the starting point of every transaction and Access the ending point. Remember this next time you looking to secure a digital crown jewel in your organization and you will have half a project plan already. Nothing can lead to more confusion than starting in the middle with networking or some other random point, then grasping for what have we missed. In fact today I had a chat about a plan to move to identity based firewall for application layer segregation in a large financial organization and my first thought was I hope their identity system is up to scratch, else this project would have a net benefit of zero.

Even for those that don't want to embrace my logic the amount of research in the area is extensive. The identity defined security alliance recent post named "Identity-Centric Security: 10 Data Points from 10 Different Vendors". In the framework, I also pointed out proactive, real-time and reactive. Put a different way, would you rather prevent a breach or know sooner after it happened?


In no way am I suggesting you ignore the other security disciplines. What I am asking is how much of your security budget is going to IAM and is that approaches to the levels of risk it addresses? Then given the 4 pillars of IAM, does your organization have enough focus on IAM?

Mind The Gap - mystical authorities of obscurity

I blogged a satire piece about people in IAM but wanted to raise an issue in a more serious tone. Firstly, let me say, this is not unique to security or IAM, and I am sure it exists in many areas in and out of technology. Years ago, I was required to mandatory military service and served as a marine on a naval base. The base had about a dozen marines and over a thousand navy staff. As a Marine, we wore combat fatigues, carried weapons and stood apart, while the navy wore whites and most classroom weapons training only.  The average navy officer had no idea what we actually did. We shrugged off any naval policy and tradition we could and defined our own space as "mystical authorities of obscurity". Sorry navy officer, we can't because [pick and obscurity+ add some mysticism] for an excuse, then dodged as much work or responsibility as we could. Anyone read the book bullshit jobs?

Perhaps this can be attributed to a skills gap, or perhaps its leadership gap, recruiting gap or just industry hype, growth or a dozen causes. Professional certifications like ISC2 offers have done much to ensure recognition of the discipline and some level of base understanding. The problem is you can take a professional dishwasher and in a one-week executive crash course, prepare them to write their professional security designation with a significant success rate. Suddenly, with 1 week of training and a chunk of dollars, we have a "security professional", "audit professional", "risk professional", that never has looked at a log or provisioned a user, been audited or had to deal with risk other than for themselves on social media.  I have had to show "security professionals" how to book a room in outlook, and heard this same person recommending phishing training guidelines for outlook 30 minutes later. 

Perhaps is because so many companies consider IAM a regulatory or security cost vs considering the additional pillars of IAM. So, when a "security professional" is found, not demanding top dollar, they are snapped and added to the team of "defenders". Perhaps some recruiter (who has even less understanding of security than the newly minted "security professional") tries to screen candidates with questions like have you worked with "Zero Trust", "PIM", or "least privileged", discounting anyone that resume does not list these keywords in under 2 pages as lacking experience. Or have you deployed "CyberArk",  "SailPoint", "Okta" and nice to have "Venifi" in a financial organization of 100,000 or more people... in the last 6 months and have your CISSP and 5-10 years experience? If so, I have an excellent opportunity for $45,000 a year. It's a competitive market, and you get what you pay for. 

Only someone that knows little about deploying these products or has an integrity gap, would claim yes. Often the deployment "experience" turns out to be in a line of business, effected by the product deployment. Yet these jobs are soon filled and with the shortage in security, audit and compliance teams, no one seems the wiser. Next, you hear, the "security professional" was promoted to management and starts hiring their own team and finds more newly minted "security professionals" to work for them, that won't expose their limited industry knowledge. Soon the company has an entire team of "security professionals" setting policy, policing and driving corporate security strategy, with limited to no exposure to the technologies, they are attempting to protect.
 

As a contractor, I usually take time to interview for potential new contracts. You usually can spot these people 5-10 min into an interview, if not by their questions, by their vision or aspirations. "I am committed to fixing an audit finding in 5 months, that’s been open for 5 years"... and yet from experience I know that would take 2 years and significant resources to close. These are usually not the contracts you want.

Alternatively there "old security" personnel. These are people that spent many years in security and have nothing more to learn. Doing it like its 1999. They ignore emerging technologies as "security principals remain constant". They spend money on Active Directory tools, legacy firewalls and SIEMS while their organizations deploy SaaS, federated access, BI, AI and cloud-based services. Easy to find, since you notice controls in legacy environments are the focus, while the business continues to move ahead "unhindered".

IT and other technology teams soon realize that the mystical authorities of obscurity have little or no idea about their business and are seen only as roadblocks. "Security professionals" defend their standards, policies and controls as regulatory, or best practice by throwing more mysticism and obscurity around. There is usually a huge amount of hype words and jargon (often misused) that emerges. $45,000 a year solution, starts costs the company millions in other resources time and efforts, with little to show for it and all confidence, is lost.

One does not move all ones players to the defensive line, unless you lost already and just focused on trying not to bleed to death. So why put so much emphasis on second and 3rd lines of defense, at the expense of the first line. Information security needs people focused on securing systems proactively and if most of the security staff are simply reporting on the the state of security or writing a new policy (that those managing the systems will probably ignore).  We need forwards if we want to stand a chance of creating a winning team, but forwards are loved by their supporters and hated by the opposition and it can be dangerous to be noted. 

Sooner or later and executive has everyone telling them IAM folks don’t get it, and this starts looking bad on them. Management picks a project and gets IAM leadership to promise it in record time or "face the consequences". Left with little choice but quit, the project is soon kicked off often just buying time.  A vendor "partner chosen" as the scapegoat, the objectives are set. Limited timelines and resources, coupled with previous short cuts and lack of experience results in the project getting descoped repeatedly and more corners are cut. The result is usually foundational work is descoped for visible goals, like building data stores, stopping the bleeding, training, building to a point in time or ignoring life-cycles been dropped in favour of risk acceptance or bias checkbox assessment. If the deliverables can be spun as met, the security team may buy some temporary goodwill, at least until descoped issues come to the fore.

Now the IAM team cant raise additional funding to finish what they already claimed to have done, without admitting failure. In the meantime, IT and other technology teams are rolling their eyes and saying, "What did you expect" and life goes on, with the next project building on the missing foundations of the previous. Sinking more good money into new projects, that will be wasted when it all collapses.

Then they get a new CISO, spend a year doing a current state assessment with gaps and making a plan and then - start again – at the beginning. Usually resetting the company security maturity level in the process.

There are good IAM security professionals and organizations. Usually so busy plugging away that they are often overlooked. Medical specialists first need a medical base, engineers need basic engineering skills before specialization. Why then does the industry think you can have a security professional that has no experience with the technology they protecting? Security professionals need to be technology professionals first. In fact, they should be subject matter experts in a platform, area or system before specializing.

Perhaps we need a cultural change or need more collaboration and openness and less mysticism and obscurity. Perhaps if we dropped the jargon and hype words and focused on understanding and learning. Or perhaps we need rotation programs were security staff does IT work and IT staff does security work for a period. As an IAM professional though, I cannot encourage others enough to do a non-security course in technology areas your organization is adopting.

Data Stores - Entitlement Book of Record (EBoR)

Technologies and vendors come and go, and for this reason, I would like to keep this blog as vendor natural as possible. For example, SailPoint might call it your Identity cube and identify warehouse, I used the term keychain and IBoR.

For anyone that has designed any SOA based applications or database tables, this post may be obvious. For those that have not, though, there is an important intersection of IBoR and Entitlement Catalogue, I will use the term EBoR to describe. While and IBoR contains identities and credentials and the Entitlement Catalogue what is available for access (your identity service catalogue), your EBoR is who has access to what.

It's essentially a point in time report, connecting a user's identity to all their entitlements they have or an entitlement to all the users that have access to it. Who had access to this field 2 weeks ago, or what did bob have access to 2 weeks ago. Although its a point in time, the query needs to be able to run as needed, and not batched.

Depending on your decision on zero trust and network as the book of record, this should be a query from your identity management system as authoritative and not the endpoints. The reason datastores are so important for building trust.

This should also be what is certified as a 3rd lifecycle as part of the user's access lifecycle by their manager. If you pull from the endpoints, how do you know the access was gained legitimately? Rather your Moves Adds and Changes managed in your identity management system, will keep track of what access you should have and any discrepancies dealt with on the network side.

Your access request systems should be greatly simplified, for the identity of  Bay Li requesting role 123, with the workflow defined for the entitlement. The business description, technical description, need for a sperate credential, approval flow, through provisioning all defined already.  Role 123 could be a business role, IT role or application role.

So if you want to know who are your privileged users, today, how would you know? If a critical system has a known unpatched vulnerability, who has access?

Data Stores: Entitlement Catalogue / Product Catalogue

Going back to the early 2000's and the telco's wanting to upsell their customer's services, once the telco's had created IBoR and keychains, they realized that they could now see a given identity had a credential in different service directories, and could even look-up the what groups the customers credentials were a member of. What they did not really know was what those groups gave as entitlements to the customer.  As an example, if customer Bay Li had wireless services since they existed in the wireless customer directory and were members of group 400min and vmail, how much did we really know about what Bay Li had as a service? The group 400min sounds like they had a 400 min rate plan, but was that prepaid, postpaid, did it include caller line ID, call waiting etc. What's more, the rate plan changed giving the members of the group and additional 100 min "free" so it actually is no longer 400min but now 500min, although changing the group name never happened. This kicked off projects to create and maintain a centralized product catalogue.

Almost every IAM engagement, it includes a statement to implement "roles-based access". A goal, without a plan, is just a wish... and in most cases, the team is not even in sync on what they consider roles-based access or what they mean by the term. This is because the RBAC model is layered. A single application role, been something entirely different from a business role. Ironically, if you ask for clarification, you usually get this look like "#$#@ and this is the consultant?"

 

In most cases what they unknowingly referring to is business roles. The utopian world of least privilege, least effort and full compliance, and so often trying to get there without datastores or building the foundation. So I will start... yes on the opposite end. 

For example, let's use a Database as the "in application" side (Single Entitlement). In a single database role, you may grant members the ability to update and read one table named [updateme], but only read table [readme]. This is a 2 entitlement application role. Neither considered privileged by the owner of such data in such tables. (please note, write access does not mean privileged access necessarily, else my ability to write an email or add my name to the team potluck is also privileged). 

These two application entitlements are usually used by data entry staff for the application [Database1]. This application role is mapped to a directory group that we name [Database1_dataentry], along with 10 other application roles for the same database, similarly for 20 other databases and 100 other apps. If I look in the directory, I can see the name of the group and the credentials that are members of this group, but other than the name, do I know what this group grants access to? Not unless you go to the database side and look at what the role contains. 

So if Betty now asks for access to the group [Database1_dataentry] , how do you know if this is least privilege and appropriate? How does Betty know what group to ask for? On the other hand, if Betty asks for write access to table [updateme] and read access to [readme], how do I know how to provision Betty in group [Database1_dataentry]? If an incident requires you to know who has write access to table [updateme], how will you establish this? Perhaps Betty's manager is asked to certify Betty's access to [Database1_dataentry], how do they know what that group grants access to? To automate the provisioning of access, what workflow do you use?

There is no technical limit to how many levels between a single entitlement and business role, but many companies limit their entitlement catalogue to 3-5 levels. We could go lower than the table to the field or some other flag level, like PII. We could also add levels between IT roles and business roles or include levels above business roles when you bring in persona's and wish to know for a given credential if the identity is both employee and customer. 

In our example above, let's say 5 different teams have a need to be members of [Database1_dataentry] and all data entry staff also need access to a different system where they collect data to enter. This system to collect data to enter access is granted through the [Dataentry] group in the same directory. I could nest [Dataentry] and [Database1_dataentry] into a 3rd group, create a multipurpose group or do it in the catalogue by creating an "IT role" The flexibility in scheme, workflow and fact that an entitlement catalogue can span many directories is one reason why nesting is not ideal. All 5 teams may now be members of this IT role. 

One team is contractors and other permanent employees, and the contractors need access to a time system while employees need access to a benefits system.  Both teams have the "IT role" of [Data Entry]. We can now create a business role including the other access needed for each team which is the "IT role"+ say time system access and call it [Contractors Data Entry]. This is now a business role. 

Usually, role mining works either top-down, bottom-up or hybrid. Top down mean you look at the persons job function, then determine what entitlements they need access to. Bottom up, is the approach above, where you first create the entitlement level, then the application role level, then the IT role etc. Note, top down does not mean you only build business roles and ignore the other layers, which is a common misunderstanding, that results in "business roles" being nothing but a consolidation of unknown entitlements and rather than a clearer understanding of access level, a hidden one. 

A note: Your entitlement catalogue is where technical and business description exists, along with ownership and accountability, workflows etc. You will need to establish and entitlement lifecycle management, onboarding, retirement, transfer etc process. You will also want flags for things like PII, Privileged etc that you may wish to query on. So how do you now know who has privileged access?

Data Stores : Identity Book of Record (IBoR)

Most of the blog so far has been focussed on Identity and broad structure, and I have used the term IBoR many times. In my attempts at an Identity Centric Security Framework, I have a large band titled "Data Stores and Books of Record". This section includes things like inventory systems, change management systems, application book of records and 3 core IAM systems I want to cover over the next 3 posts. The first post is about your corporate IBoR.

Back in the early 2000's the telecommunications companies wanted to focus on cross-selling services. For example, you may have used telco 1 for home phone, cable 1 for internet, and telco 3 for mobile. The first problem was a realization that each service offering for a given telco was on a different directory since the services had been created and launched at different times. So how does telco 1 know if you have more than 1 service with them already? For example, bli@homephone and bli@internet and bli@mobile needed to be linked. Massif projects were initialized to create IBoR's, linking each service directory to a master directory and keychaining credentials for different services to a single identity. Jump 20 years later, how many companies have a similar issue across directories, environments and cloud-based services? Do you know every credential for each person in your org? How about each shared or NPID?

There is a difference between an Authoritative Source and an IBoR.  An authoritative source provides input to the IBoR for certain identity types and attributes. While and authoritative source is authoritative (and therefore a BoR) for certain aspects of one or more identity types, it is not the source of record for all attributes and identity types and should not be used by downstream systems directly. For example, Bay Li is an employee and his manager, job code, cost center, status, and hire date attributes may all come from the authoritative source of the company HR system. The company also has partners and vendors with credentials, that are managed by procurement in a procurement system separate from the HR system. The procurement system would then be a different authoritative source for partners and vendors' identities and attributes. 

Perhaps that covers off humans, but what then is your authoritative source for shared and NonPeople based identities? It's not really a BoR if it's not complete (or accurate) See The Importance of Defining Credential Types. For each identity type defined, you need to define an authoritative source. This is usually a request or intake process unless you are using the network as the book of record. The intake process ensuring the collection of attributes you need to manage the identity. Another challenge is the impermanence of the cloud.

Secret management and SSO using keychains is another huge benefit for an IBoR. Rather than Bay LI changing the password for bay.li@companyabc.com on every identity store, a master secret for Bay Li can be changed and replicated to the credentials that can share a secret. For example, bay.li@dev.abc.com should probably be forced to use a different secret than their production credential and therefor linked to Bay Li as an identity by not for sharing a secret.

An IBoR is not built to be static, but dynamic. Now if Bay Li's manager changes in the authoritative source, it should change in the IBoR.  More on lifecycles and lifecycle management later. Changes to attributes stored in the IBoR could trigger an event in your identity management system, like requiring the new manager to certify the team's Bay Li's access. Now, what if the manager and cost center both changed? This could trigger a different workflow, as it would tend to imply a job change.  What if Bay Li changed from Employee to terminated?

Your IBoR is therefor a foundational component of any Identity Centric or Zero Trust security strategy and your organizational authoritative source or BoR for what to trust. It's the system you verify against for trust relating to identity. Where else would your incident response, UEBA, PAM, Insider threat, Business Roles Based Access, secrets management, key management etc program source identity truth from?

As a final note, we speaking IBoR and hence we not referring to access levels. For this reason, I have avoided the use of the term "privileged ID" as privileged refers to the entitlement level granted to the identity. 

What is a "Closed-Loop"

Well after my post "What's your Book of Record?", someone asked what I meant by a "closed-loop". Since this a knowledge sharing blog, intended for all levels, I thought it a good idea to go over the concept for any that are not that familiar with it.

Management is the noun for the verb, to manage or managing. Put differently, what differentiates a good vs bad IAM anything, is how well you manage identity and access. I once was present when a CISO explained what a control really means to a CIO relating to a need to clean up. It struck me in its simplicity as they explained "a control is something we put in place ensure we control or manage something correctly. We are then audited to show the effectiveness of that control and if we fail to clean up, it shows a lack of control and therefore a gap in our controls". This is not a career for sitting and writing a document (or a blog), standard or risk assessment and go home. It's about systems, integration, accuracy and showing control.

Good management systems work in a closed-loop. The management system manages the system or network endpoints and in return reconciles the system or network endpoints with the management system. This loop is closed when any differences are addressed in order to ensure that the systems remain in sync. Should something, for example, change on the system or network endpoints that the management system did not manage, the incident should be investigated. For example, a user is added directly to a database and not via the management system. Since the management systems were not aware of this user been added, you now have two systems giving you a different view of users on the database. Reconciliation should be a change to the system that is not the book of record (BoR).

With our security hats on, if a user is suddenly added to the database without going through the management system, it was likely not requested/approved/provisioned legitimately. This would indicate a high likelihood of malicious intent. (Note: this is given your management system is not so poorly designed, that the business chooses to ignore it, or the accuracy of the data in the management system been too poor to trust.)

Given the attack surface of a management system vs endpoint, and the purpose of these management systems, in IAM it should usually be the BoR (Book of Record). As the book of record (BoR) on finding a difference, of the user with access to the database in the example above, the user should be removed from the database and not added to the management system during reconciliation. If this process is in place, you have "closed the loop"

This is different than say a SIEM, where you usually use the system or network endpoint as the book of record, as you not managing the endpoint, but alerting to changes on it.  This difference is why I wrote the post "What's your Book of Record?"

The Importance of Defining Credential Types

How many of you have read your access control standard, your compliance standards and then tried to map a set of controls and standards that apply to each account type mentioned? How many have had an incident, and not being sure what type of account is the account in question is, and therefore if the behaviour is actually unusual? Do you have a requirement or policy for shared credentials that do not apply to non-people or visa versa, yet your standard only mentions service accounts?

The first step as an organization, if often to define standards and compliance requirements. Usually, during an engagement, I start by reading these standards. Usually, by the end of the standard, I am horribly confused, and pitty any non-security person trying to make head or tails from such a standard to adhere to the policy. Many times, the same name or term used for multiple account types. Other policies apply to different layers. Like all non-people vs batch. 

Start by looking at your upstream needs, which are usually your compliance requirements. These are the bare minimum. Make sure your frameworks support all your regulatory requirements and that each requirement for each account type is clearly listed against the account type in your framework at the right level. 

Then consider your internal or downstream needs. What attributes does your organization need to track and maintain for each identity type and is creating a grouping by this identity attribute make sense? Is there a standard perhaps you wish your organization to have, to ensure these attributes are available for use? Let's take an example. If you planning on using analytics and UEBA, you probably want to define account types based on algorithms you wish to apply. For example, periodic batch credentials have a very different usage pattern to shared people's credentials. If you were to apply an algorithm or policy in your UEBA software specific to monitor batch credentials for misuse, you will need to know the credential is a batch credential. If you don't have the means to identify batch credentials and use the network to "discover them" how do you know if the account is complaint or not already compromised?

If you find you get too many, create a 3rd layer to the right. For example people, primary, contractors, when a higher layer grouping meets shares a common set of requirements. 

Retroactively collecting attributes is the hardest challenge. Many vendors offer solutions to use the network as the book of record to collect attributes. This uses the network as the book of record and although it will then identify changes to attributes, it assumes that up until that date, the was full trust and no compromise. With a clear control standard, have the business define the account type they need before it is created, and by doing so, define the controls that apply.

Note: I * privileged credentials, since its not the credential, but the access that would be privileged. That said, your control standard probably has some requirement for credentials with privileged access and hence they need to be represented in your framework.

An Identity Centric Security Framework

Well, I had mentioned, I rarely see frameworks that put identity at the core of security and really support identity defined security. The same applies to platforms being mixed with disciplines, like saying cloud security is different from IAM. See Getting down to the root cause of breaches and The Hype of "Zero Trust" and Getting Identity Right

Although I see the need to call out all the separate areas to ensure organizational structure,  the squeaky wheel gets the oil. By not recognizing Identity for what it is, the organizational focus often shifts to the manager that wins mindshare. Historically, security has also been focused on reacting to incidents, vs proactively design and defence and many senior security executives come with this background and approach. For this reason, I tried to arrange the framework with pre-planning on the left and reaction on the right.

Security Framework 

Things like endpoint protection, currently fall under reactive, vulnerability management and training and awareness under policy and standards. Risk, under-reporting and compliance.  

So, comments, changes or omissions? What's your take?

IAM Debt and Deficit

Technical debt has become a common term within the software industry. Made popular by Ward Cunningham, who developed the first wiki and was a co-author of the Manifesto for Agile Software. Technical debt was a metaphor for the long-term obligation (deferred costs) developers and software teams incur when taking shortcuts. 

"Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise."— Ward Cunningham, 1992

In "Another" 4 Pillars of IAM I covered why we need IAM. Depending on the

your organization, it could be viewed as a competitive advantage or forced cost to do business. Data without any ability to access it by humans or non-human identities, to access it would have no purpose. Companies without an IAM vision or strategy, tend to see IAM as an area to take shortcuts, many not even realizing the debt that they are accruing while thinking they saving time and effort. How many times have you being asked to grant a role with additional privileges "for now", not finalize access roles, "temporarily" use and existing "service account", "give root in development, create a local identity or credential store... etc? More concerning is when companies have strategic projects, which they want to expedite and ask IAM or security as a whole to not "disrupt them" till they get it going? This is especially true of shadow IT, mobile apps, customer apps, cloud and DevOps, and emerging technologies.

The next thing, they in production, with 100's of users and find their subject to regulatory requirements and emerge battered from their first audit. Leadership then asks the IAM team to "fix it",  thinking this is like switching on a feature, doing a simple configuration change or collect the logs centrally. Since identity and access are foundational and due to interest costs, it turns into a huge project of nearly the same costs and timelines as the original. Audit, leadership and the app team are unhappy as this derails the whole fast path strategy and goes right back into looking to go into more IAM debt by cutting costs to now bring the system into the corporate architecture and controls. The alternate is admitting failure and the waste of those resources used to "fast path" the special project, and that could cost people jobs.

To touch on the foundational nature of IAM, for those less familiar, let use a simple example. When you install an appliance, operating system or literally any software, you always need to create the first credential (often the privileged "service account" like root, admin, dba etc. If you have a PAM program, you need adaptors (tested in and deployed), privileged definitions, onboard privileged credentials, create safes, establish owners, access groups etc. If you have an identity management platform you need adapters, IBoR integration and credential management, build the roles in your role catalogue, role catalogue integration,  request management, active directory groups, service accounts,  integrate into automation, KPI, UEBA etc. I have personally never had great success retrofitting IAM to an application, as the users have what they need already - access and see anything further as unnecessary admin. Only when wanting and waiting for access are users quick to respond and this is where you can capture the required information to manage onboard the application.

IAM deficit is much like deficit programming. A very common mistake is building IAM controls for a point in time. For example, we pulled a list of users in a group last week, reviewed it and ignored changes during that week. A PAM or identity management program is a program, not a project and not built to a point in time, but as a set of controls and infrastructure that becomes core to your digital strategy. Usually, companies have a continual rotation of applications, as applications are end of life and new applications brought into the organization. Various organizations have a different level of formality and controls around introducing new applications. Each new application needs to be onboarded onto your IAM infrastructure. If your onboarding team is onboarding 3 applications a quarter, while your organization is introducing 5 applications a quarter, your IAM deficit is 2 applications or -40%. Does your IAM KPI only show how many new apps were onboarded for a period of time or does your KPI compare that to the new apps added?

When your IAM team is spending the majority of the time working on IAM debt (paying interest) and running an IAM deficit, you are losing ground. 

Whats your Book of Record?

Some years back I was working on a telecommunications network inventory system and remembered have many interesting discussions around if the inventory system should be authoritative or the network and systems themselves. To phrase that a different way, if I look in the inventory system and it says there is 1 available widget in rack 1-3 location A and yet when you physically go to rack 1-3 location A, you find no widget available. Which then do you take as accurate? In no way am I suggesting you should not build a closed-loop and compare your book of record to the network and build processes around reconciling them, but which one do you take as authoritative and which one do you adjust? 

At first glance, this may seem like a simple decision, but it's actually foundational and needs to be agreed an understood by the organization and used consistently in systems in order to maintain the system integrity. With the impermanence of microservices, this decision is even more important. To expand on the problem, if I get to rack 1-3 location A to use widget to connect a new service, and it is not there, do I assume the system is wrong, grab a widget from stock and install it. How then do I keep track of stock expenses and track this difference? What if that widget was stolen or out for repair only temporarily? What happens if I get there and there 2 widgets, not one, could one be malicious and you ignore it since you assume inventory was wrong? In other words, how do you deal with the incidents consistently, if you don't have a policy on what is the book of record? How will the accuracy of your system ever improve if you fix accuracy issues outside of the system?

Years ago, when SOX controls became mandatory, many financial institutions suddenly found that they had a regulatory requirement for periodic review and certification. So they installed identity management systems, not to manage identity, but to report on access and facilitate reviews. Rather than making the identity management system authoritative, they made the system/network. The logic was probably in part to security professionals being familiar with the logging and monitoring approach of pulling from the system/network. In part some large system vendors not willing to be managed by another party and in part that you should review and attest to what you have, not what should have. I was not working in the financial sector at the time, but I still, hear these arguments today. Whatever the deciding reason was, the result was that the identity management system was deployed as reporting systems, without a closed-loop at huge expense. This early adopter approach rapidly took hold in other industries, and today the approach can found implemented in many organizations.

Using an application, not in the way intended, requires customization, adding costs and complexity. Since the system was not managing, it relied on “feeds” to be formatted, imported and processed as a source of information required to be certified. These “feds” often had completeness and accuracy issues and assumed that if a credential was reported to have access, it was assumed to have been obtained legitimately. The constant problems and complexity often resulted in the certifier just blindly attesting to everything.

Another difference between IAM security systems is the exposure and visibility of the business. Once the lack of value became obvious, the entire system became a costly compliance checkbox. Changing and installed an identity management system from being downstream to the network to being upstream and authoritative while maintaining it in production is extremely difficult and not as simple as just closing the loop. The result was the need to now look for a new identity management system.

For this reason, I like to use the term “Book of Record” (e.g ABoR for application, IBoR for identity and EBoR for entitlements etc) when discussing IAM data stores. So does your organization have a policy on if the system/network is the book of record?

The Hype of "Zero Trust" and Getting Identity Right

You can hardly go to a security event or read an article without the term "Zero Trust" being used today. Much is attributed to Forrester as early as 2013, which was targeted at network security. For this reason, it is often seen as a network security and perimeter framework. In fact the original model, all but states "Identity is the new perimeter", a term quite common back as early as 2012, and perhaps was behind the approach. The Forrester original zero-trust framework stated:

1. "Ensure all resources are accessed securely regardless of location
2. Adopt a least privilege strategy and strictly enforce access control
3. Inspect and log all traffic. "

They go on to say "Zero Trust does not explicitly define RBAC as the preferred access control methodology. Other technologies and methodologies will evolve over time. What is important is the concept of minimal privileges and strict access control."

If you ask 10 security professionals what is Zero trust, you probably hear them all shout out like barracks soldiers “never trust; always verify.”, which was supposed to replace the age-old saying "trust; but verify" which in turn possibly comes from a Russian proverb. Either way, Trust is gained through verification. Trusting the identity of someone would require that you confirm their unique attributes against a known accurate source. A real-life example would be checking your passport, at the border

So where is your organization's known and accurate source for digital identity (IBoR) and does it have sufficient and relevant attributes in it, that can be used to verify trust? How confident are you, that your organization is verifying to an accurate source or is your "zero trust" project just "Fake News".

Almost every IAM engagement starts with hunting down identity and credential stores used as authoritative for different systems and applications in scope. I said IAM, though it should probably be every security project.

I usually start by asking, and nearly always get an answer of "HR systems for identity and AD for credentials". Some companies have even linked the two systems, to populate a few attributes in common either as a point in time or periodically updated. How then are shared and NPID identity and credentials handled? How are contractors, partners, vendors and other humans not in the HR system handled? More mature organizations will have an IBoR where human, shared and NPID identities are mapped to credentials and used as the book of record to verify against. The next step is to check for completeness and accuracy. Can each credential be mapped to identity and is the identity of each credential known. When and IBoR is not consolidated, in place, complete and accurate and the organization has no source that can truly verify and confirm the identity behind the credential and "zero trust" is impossible.  

Once an organization has an IBoR in place to verify trust against, we need to ensure it is the book of record. So we need to find all other identity and credential stores and check them against the trusted source or IBoR. Look at the first windows server, and if you find a number of local credentials verify them to your IBoR. Then a LINUX server, database, application, SaaS service, cloud service, the network device and so on. Checking each in turn for completeness and accuracy. In most cases, you will soon discover that dozens of identity and credentials stores, with some percentage of accuracy other than Zero. This is usually because these systems are not linked to the IBoR and or maintained and updated.

Now once you find your "orphans" (unmapped credentials, hence credentials that identity is not known) as your executive sponsor how they want to handle them, and they will probably say "turn them off!", but this will usually be tempered with much more cautious approach after the first few incidents caused by revoking unknowns. In order to get to zero trust, you need that assurance and that means to clean up. These can be huge projects, which are hard to "sell" as they can be costly and are caused by previous "short cuts" many will not want to be called out.  First, you need to stop the bleeding and make it sustainable, then "clean up" by getting to some level of assurance on each orphan.

Ironically network equipment vendors often push for their own credential and identity stores e.g. ISE, which seldom gets linked into the IAM IBoR. In more than one case, I have had someone in networking security claim "Its part of our zero trust project!". This is usually since getting money to install a new something for "zero trust" is usually easier than getting money to clean up what should never have been left to get out of hand. Others have accepted that Zero trust is a mindset, not an architecture, perhaps understanding the size of the program required to get there. Whatever your company's approach, getting digital identity right is the foundation for all digital services.

"Another" 4 Pillars of IAM

The table legs, the supports, the purpose.... yes like many before. Feel free to make it 5 or more! After the 11 Types of IAM Professionals (Satire), I thought I would set a slightly more serious tone.

1. Regulatory, Risk and Compliance

This covers all law, regulation or compliance aspects from Privacy to PCI that your particular business is subject to. This is the threshold or minimum standard any organization should adhere to. Not a target, not an endpoint, a threshold. If you don't want audit and regulatory bodies driving your strategy, then get above this layer.

2. Security

This is doing it right, protecting the brand, customers, partners, employees, intellectual property, fraud, disaster recovery, etc. That area over and above compliance that differentiates your business from another complaint one. Years ago I heard a CISO at an event say “ I don’t need to be secure, I only need to be more secure than they are” pointing to the CISO of the major competitor. There is some truth in that as a percentage of cybercrime, like any, is opportunistic. How many companies though can truly say they are more secure than their competitors? I believe that collaboration in cybersecurity will return far more than the competition.

3. Optimization

Recently I had an EVP of a very successful organization say the problem with CyberSecurity is the lack of actionable strategy. The just documents, checklist, and then"acceptance" view. In this, IAM is different, and perhaps why it usually has the most audit findings.
How many organizations can take weeks to set up a new employee or contractor's access? How many people hours does your organization spend doing access certifications? How long does it take for your business to get a certificate installed or a new application role created? How much are password changes, MFA, etc costing you in lost revenue? How many people hours is spent collecting evidence for an audit? I wish these metrics were more frequently used KPI for IAM maturity.
A discussion recently with a company wanting a "cheap and dirty" provisioning system. The issue, however, was far bigger, in that they had regulatory issues for failing to remove in a timely manner and laughed at the list of audit findings they were wading through saying they only had a few weeks to get it working due to other commitments. So let's say your business has 200 contractors/new employees onboard on an average a year. If the average salary is $60,000, and it takes 1 week to get them setup, your revenue loss as an organization could be (200x$60000)/52= $230,769 of lost revenue a year. Now add time spent doing certifications, and perhaps some other access requests and off-boarding and you have a business case for doing it right. Of course, this won't cover a $1m a year project if that comes out to be your costs (unless money is no issue)

4. Strategic

You can hardly look at a digital device or traditional printed article without seeing something about the importance of digital strategy. Just read Nicholas Rossolillo article on Motley fool "How businesses and you should invest in the digital transformation movement." The numbers in data collection and storage and digital growth are exponential and few companies do not now consider digital strategy as imperative for their future success.
Billions are being spent on collecting data, marketing, building brand, building trust, providing faster turnaround on digital services, mobile apps, supply chains and connecting digitally directly with your customers. The foundation for the success of this is built on identity and managing access. The business case is a bit different, depending on your industry, perhaps survival.

Has your security team spoken with your strategic team?

What is in a name?

This summary is not available. Please click here to view the post.

11 Types of IAM Professionals (Satire)

Ok for a little Sunday Satire fun, I thought I would write a bit about the different personas in Identity and Access Management professionals. Like any persona, people can have more than one. Now with my tongue placed firmly in both cheeks.

1. Pious Privacy (compliance & risk)

With the ever-increasing list of best practices, standards bodies, professional accreditations, regulatory bodies, privacy regulations, events, workshops, labs, risk methodologies and research centers (and I am sure I could go on) comes an ever-increasing list of compliance requirements. Some of these are mandatory (SOX, PCI, GDPR), other guidelines and everything in between. Sorting through these to find differences and responding to their needs is a full-time job - ok let's make that plural - many full-time jobs... A checkbox in approach with a limited view, PP's can have a limited view like "we determine what data should be classified as private and adhere to the privacy policy, we don't deal with how it's done". "who is this Pam anyway?"
Where to find them - Very visible, this species is often seen staring over others' shoulders or frequently performing the bewildering dance of interpreting compliance requirements (2a/b function) or dictating what data is private into languages they often never learned to speak themselves. Each point taken out of context and mapped in binary or to some scale, with little to no understanding of impact. Hours can be spent discussing the length and material of a piece of string.
Identification - Advisory only, except for checking others' work. Loves terms like "best practice, PII, least privilege, gaps assessment, certification, PAM and RBAC". They talk "risk registry, privacy by design, awareness, and risk planning and risk acceptance". Views IAM as a different practice to compliance and a pure cost and social responsibility. Tools of choice include spreadsheets, self-assessments, and risk registries and large documents never read again. They view IAM as compliance.

2. Oblivious Operator

Someone has to do the work, I mean who would PP do otherwise? But its probably boring and repetitive and basic automation or AI will probably put all OO's out of a job at some point. In the meantime, we are getting great exposure to a rapidly developing industry and being paid slightly better than the average operator due to skills shortages in the industry. 3 months as a PAM admin and I can ask for a raise or jump ship to a senior position elsewhere.
Where to find them - Heads down in the trenches on call. Will usually have a shovel in hand and wearing a toolbelt. Except when they filling out reports on what they have done for the PP's
Identification - They talk about tickets, events, incidents, and changes, usually in large numbers like "I did 40 tickets today already", or that batch had 200. Closely monitored on delivery and time usage you can usually just ask where they are. They likely on half the companies speed dial to get access issues resolved promptly. They talk process and procedure, not compliance, risk, and security. Views IAM as a never end ticket queue

3. Magnetic Marketer

These people are driving the business and so seen to "bring in the money" and their identity plan is called a strategic business strategy. Identity centric, their world revolves around the brand, trust, attributes, social media, communications, and direct relationships. Usually focused on Customer IAM or Partners, they seldom care about security or standards and usually view compliance as an obstacle.
Where to find them - Trendy coffee shops, patios board rooms, events and working on building " relationships of trust". Always looking for the next hype cycle. Usually using something like Salesforce as the IAM tool of choice.
Identification - They talk about subscriber experience, stickiness, market development, break out services and market share, cost of acquisition and market intelligence. They refer to groups as target audience, buyer personas, demographics. They talk trust, never security and usually want more access for everyone. They view IAM as a relationship building.

4. Ecclesiastic Executive

This must be one of the highest stress jobs right now period. As the saying goes, “There are only two types of companies: Those that have been hacked and those that will be hacked.” – Robert S. Mueller, III. Gerry gave a superb talk on "The Anatomy of a Successful PAM Strategy" from a user acceptance, but it perhaps applies even more to an executive in IAM earning $200k a year when a breach could cost the company $100's of millions
Where to find them - Dealing with other executives that simply have no clue, dealing with regulators/audit, struggling to find skills and budget or reading the riot act to some wayward group or support staff. At night they can be found chewing on their nails in restless beds, trying to ensure their strategy covers as much as it can as fast as it can.
Identification - Better dressed than most, they tend to have a haggard visage and if you look closely fear in their eyes while expounding the virtues of IAM loudly to any and all that will listen. Often returning from some other meeting with seemingly bizarre new requirements. Their team rally cry can is frequent and loud as they apply stick and carrot to all. Views IAM as a political quagmire. They view IAM as a career step

5. Vapourous Vendor

Nothing else can stick closer or vanish faster. They focus on features and usually have little to no understanding of process or procedure. Usually, a because you can, vs because you need approach. For this reason, they often seen with executives and engineers. Have an uncanny ability to change opinions with their business card.
Where to find them - Events, restaurants, executive offices, hotels, airports, workshops, meeting rooms.
Identification - These are usually the best dressed of all, with expensive accessories. They say things like "...Do I have a product for you...", "unlike our competitor...", "...is scheduled for the next release", "of course our system can...", "we support the open standard of..." or "all you need is a widget here" and "we did this for hundreds of customers". They view IAM as a meal ticket.

6. Einsteinian Engineer

It works, I don't care how you operate it... Architects and engineers love standards, interfaces and many many VV's. It's not if it is needed so much as if it's cool. I mean who wants to do something that's been done before, I have a better idea. The focus is usually about making it work, not solving a problem.
Where to find them -These folks usually know little about either security, security operations or compliance but a boatload on product features and standards. If they not attending a VV pitch, they can usually be found in the lab paying with "next-generation" stuff.
Identification - Usually, the one saying, "...well if the vendor only followed the standard properly it would work or I don't care how you enter the required data, the system starts from here" or "You never gave us the requirement that you would want to log in, if you need access you will need to do that yourself".They view IAM as a hugely complex yet simple set of widgets.

7. Pedantic Program Manager

These are the people credited most often with delivery and finance. Hugely skilled with spreadsheets and projects, they usually able to spin anything in a number of different ways. Financial savings and delivery focused, even if the deliverable is meanless.
Where to find them - If they not revising the project plan, they either plan, following up or reporting on status. Excellent specimens can occasionally be seen shoving large chain pizza boxes under the door for the starving project team late in the evening.
Identification - usually the one speaking of "scope", "resources" or "budget". If left unsupervised can descope all security aspects out of the project in favor of delivery. They view IAM as just another project to deliver.

8. Adherent Auditor

Filling a very important 3a/b function, auditors should never be left out of the IAM role, yet also tend to focus on security and controls and IAM functions in these areas than business capabilities and subscriber management. Like lawyers, AA's will approve a system of great inefficiencies e.g. emails been printed and delivered by hand, so long as it is done securely and does not contravene a control standard, yet will argue for hours on the wording of any such control.
Where to find them - Peridic flocks of audits or seen all year in little to no apparent pattern or season usually. They usually spotted with PP's and OO's asking for terabytes of evidence that they usually already have access to.
Identification - Serious in nature and usually concerned about their reception, AA's need love, and a finding. So give them a hug and gently point and explain a gap in your controls and most will respond well. They view IAM as an opportunity to give an audit finding when no-one else claims it.

9.Baffled Business

Often forgotten in the laser-like focus of the others, the business just wants to get things done. Of course, the other parties can make things very painful, and they usually somewhat aware of the need for security and compliance. But why can someone apply and be given a mortgage for $3m in 3 hours and yet it takes a week to get access to a system I need for work. It costs a fortune having people wait for access.
Where to find them - Usually avoiding all the others on this list as much as they dare, unless it's urgent or reading the incredibly complex instructions about access requests - I think I should just ask for root for everyone then we don't have to do this again. "What is root anyway, and why am I attesting to my staff needing it, don't they know?"
Identification - Frustrated and included to say things like "all I am trying to do is get bob access to this data (which he needs for his job" why is this such a big thing? It's worked like this for years and now you change it to something incomprehensible" They view IAM as a necessary evil.

10. Dower Defender

Security first, always first. Most notably this breed is that they tend to chase the most unlikely scenarios. Like if the sun shines at a 35% angle at midnight in an equatorial rain forest, a tropical fish walking on Bay street could intercept signals. The dark web is like a vintage fleamarket to them, bowsed on weekends. Kali is their goddess.
Where to find them - Designing 500 field request forms, pushing for 50 character passwords (changed Dailey), wanting photo ID to change your password or calculating how to shut down all signals on Bay street. Others can be found testing their neighbor's wifi security or yours. There are usually some on trial or jail.
Identification - They talk of colored teams, red/blue/purple/pink. They tend to refer to people as hats (black, white, grey). Usually pictured with their hoody up and face in the darkness scanning "Matrix like" terminal sessions.

11. Indefatigable IAMer

Very rare, these are the people that have passion, and with that passion and true desire to learn, develop and grow. Collect them, trade them and educate them. I mean we cant always promote inside our teams and these deserve to be fast-tracked.

Where to find them - as the rarest of breeds, they can be difficult to spot, but its usually in the quality of their work and the fact that they often seen first thing in the morning and/or late at night. Often volunteering for projects or eating lunch will reading a manual, white paper or blog.
Identification -If there is one clear sign that sets this breed apart it's that they have a sense of urgency and a desire for continuous improvement. They love to learn but focus on practical experience over academic discourse. They view IAM as a secure way to improve digital services.

Well, I hope everyone had as much fun reading this as I had writing it. I was once tasked with finding over 40 IAM team members in 6 months into a new organization averaging 5-10 interviews a week while orientating and onboarding the new hires. The skills gap in the industry and lack of diversity is a huge concern. More of a concern was the responses and different viewpoints on IAM I got during these interviews.

Getting down to the root cause of breaches

How many times have you heard "identity is the new perimeter" and nodded sagely?

It's not hard to read something about a breach in the press every day anymore. Although there appears to be many more of these than in the past, I am never too sure if this is a product of digital growth and increased security awareness or if there truly is an increase in the number of breaches, all things otherwise been the same. Regardless, digitization is only growing and with it the need for security. 

What is confusing is understanding were things failed or the root cause. No two organizations have the same organizational structure and responsibility matrix. Nor do two authors writing about the same breach have the same background or areas of expertise, and hence approach the root cause from the viewpoints of their experience. In fact. I have yet to see a security framework that I feel truly positions IAM correctly as it spans from HR to Sales (I will probably try to build one here at some point). When IAM functions are being performed by a different team, like network, cloud or application security, does that make it any less of an IAM issue? My number one concern for cloud security is that management thinks it changes the identity paradigm, and spin-off dedicated cloud teams. These folks usually have a great understanding of cloud features and DevOps and pipeline, and nearly always want to avoid legacy IAM “issues”, so avoid things like using the same IBoR, entitlement catalogue, PAM program, etc. The result is like the legacy space, IAM functionality is not built into the environment from day one and gets bolted on haphazardly as some necessary evil later on as a separate identity and access management silo.

The difference between a security breach and a security incident is in the case of a breach, data was accessed by someone (an identity) that should not have had access to the data. This can be accidental or deliberate, insider, outsider, etc. It could also be achieved through at least 1 (usually more) levels of the OSI and or application stack. An incident, on the other hand, includes disaster recovery, backup, denial of service and a host of other potential issues.

I have yet to work for a company that does not have more security audit finding related to Identity and Access Management (IAM) than any other area or security discipline and generally the statistics (regardless of source or authors' background) put PAM and IAM failures as the largest root-cause for breeches. This idea is not new with Gartner on record saying 95% of issues are IAM but has had some resistance to accept. Not wanting to put up my hand for more accountability than responsibility, I still feel the need to call it out. All breaches involve some failure in Identity and/or access management failure, regardless of if it is the IAM team or some other performing the function.

The breakdown is usually due to frameworks and organization structures that contain non-mutually exclusive disciplines. Let's take some examples here.

You have probably have heard about Network ACL’s. What does ACL stand for – you right, Access Control List. So when a role in a Web Application Firewall for AWS is “misconfigured”, is that a networking security issue or an IAM issue? Either way, it is a "Capital" offense. The responsibility for the beach should be attributed to the team that misconfigured the role. Who manages roles and access on a WAF and why is this any different than any other application? S3 bucket issue anybody?

Worried about Cross-Sight Scripting (or SQL injections etc). Per OWASP - “XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end-user.” In other words, its spoofing of the identity of the application.

UEBA (User and Entity Behaviour Analytics). How many organizations have logging and monitoring and incident response driving this strategy and how familiar or these teams with IAM roadmap and strategy?

Now it's important to note, I do not think traditional IAM role and mentality, can suddenly be made responsible for all areas of security. The real point of this post is Does ALL your security and infrastructure teams have enough IAM security knowledge and training? Is it easier to train your IAM staff in emerging technologies, or your emerging technology staff in IAM? Is "greenfield" an opportunity to do everything differently or learn from your past and capitalize on your existing infrastructure and processes honed and audited over the years?

What is promising is that today we have new movements like "The Identity Defined Security Alliance (IDSA)". Organizations that recognize it's not cloud security or configuration security or network security or application security, logging, and monitoring or incident response or IAM, but rather IAM in these areas that is the real challenge.

Periodic Rotation of Secrets

It may be a surprise to some that after years and years of being told to rotate secrets on a periodic basis (change your password every 60 days), NIST suddenly admitted they were wrong and changed the recommendation in June 2017 in NIST Special Publication 800-63. Few companies implemented these changes and I am not sure if reluctance is from lack of awareness or confusion. It is hard to argue against the logic that brought about the change, however.

There is little consistency in calculating the strength and determining policy. Throwing fuel on the burning problem is a number of vendors and IAM professionals hooked on rotation solutions and simply not willing to accept the changes to their market until forced. To add fuel to the fire of confusion, there is no consistency in how strong is a secret. NIST Special Publication 800-57 talks of “cryptoperiods” and was written by different people originally a year earlier. Today its seems both an indicator of the change to come and somewhat in conflict. Then there other standard organizations in other countries and even in the USA, with their own standards often in conflict with NIST, making it a daunting task to determine your organizational strategy and how you can be compliant. Take Thycotic, and howsecureismypassword return very different results for the same password. What kind of computer is this based on anyhow?

Arguably it is an audit that usually pushes companies to adopt best practices when they fail to change themselves. Ironic, since almost every company will tell you that an audit does not drive its security strategy. I personally expected auditors to give it about 12-18 months then start writing up companies that have failed to update their secret policies to the new guidelines. Why? Because I could not agree more with NIST that the risk of a secret being compromised is highest during the task of rotation. Did your parents not tell you not to open the oven to check on the Soufflé? Why if the password will take 600 years to crack, are we rotating it every 90 days unless we worried that it was revealed or compromised and if so, where was that likly to happen?

 

There are some clear guidelines on where to put effort to secure secrets, instead of setting up complex time based periodic rotation.

1) Start with an original secret. https://haveibeenpwned.com/ offers a means to check if the password was previously compromised and there a lot of credential stuffing files around. Any time a password is chosen, check it against as large a list as possible. Include passwords unique to your company that should never be used, like the CEO name, the office or the company name. Tough when you rotate them constantly. I have found companies with thousands of identical hashes in their active directory because the same password was issued by some team creating credentials. These accounts are then not used or never rotated. 

2) Pick a strong one. Base the strength on the risk and importance of what it is protecting and ensure that it is capable of surviving longer than the service. Use a cert or key if you can as the length and strength of these are usually far superior to passwords. This is especially true for API's and NPID's. Let's not make this about length, but strength and err on the side of super strong.

3) Store it correctly – Every time I hear of a breach that includes unencrypted passwords being stolen, I cringe. Forcing a password change, then storing it in a simple database table encrypted with reversible encryption is not secure. These breaches came from a credential store that was poorly thought out, and no amount of rotating will protect them.

4) Rotate as needed. This is not periodically, but if there is a reason for concern. If hashed by SHA1 or some other protocol no longer considered secure or if there is any concern that it has been compromised. We rotate passwords in PAM to ensure non-repudiation. The question to ask is, is is the secret safe per 1,2,3 above or are you forced to assume the risk of rotating it.

5) Secure the creation and rotation process. I cannot count how many companies have raised concern about the security of their credentials in SaaS or other cloud-based services as secrets should need higher security, then email passwords via outlook and O365 when they create an account, to a team mailbox protected by a poor strength password and archived and stored with regular email. Remember the risk is highest during the task of rotation.

Of course as much as possible, please use more than a secret alone. For example MFA, One Time Passwords (OTP), Biometrics, ABAC or some other form of policy-based access controls that leverage attributes known and stored in your IBoR. Using 1 attribute (a secret) is never as strong as using multiple for identity verification. This includes limiting the from where, at what times, and the means of use. Lastly, UEBA, when used with these identity attributes, can be extremely powerful in identifying the need to rotate a secret.