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?