Asset management is a core feature in information technology, maintaining important data about assets for an organization, like personal computers, network equipment, or vending machines. When new assets are provisioned or introduced in a company, ideally the asset management system is updated for each new asset. This could include items like who initiated a request, who is responsible for the asset, is legally reportable information stored, or which business systems the asset supports.
Accuracy is important to manage costs. Automating the process to provision assets and record asset management data saves money. Overtime changes in business requirements can impact automation in subtle ways. Company reorganization and outsourcing can shuffle the people using a process, without requiring a change to the processes directly. How can you know if the automation is working or used as originally intended?
Here is how a few simple data points can identify systemic issues and raise important questions.
As assets are provisioned, a business’s asset management system should include a minimum set of information about each asset. Comparing when an asset is created along with specific attributes required for each asset can expose process or data problems not easily noticed on a day-to-day basis.
Presumably, if a minimum set of information is not provided, the provisioning process should generate a ticket for the asset or provisioning system. When resolving a ticket, the asset must be both usable and correctly defined in the asset management system, otherwise the asset is disposed, and provisioning must be restarted. Problem management updates the process to improve the system. All is well.
Or is it?
Neither resolving a ticket nor the existence of an asset is proof a process or required information is accurate or complete. For example, intermittent or infrequent errors in manual or automated steps may go unnoticed or unresolved. This can lead to costly remedies or greater risks to the business.
One revealing analysis method is to review a select data point over time. If an asset’s required attribute is missing, there may be a process problem.
By charting all assets of a specific type, provisioning date, and a single asset management value, the frequency or change of a missing or incorrect value may a pattern of failure difficult to notice at any single point in time.
In this fictitious sample, @DryCyber looked at the assets of the bogus company Saltwort International. Each quarter, Saltwort provisions roughly the same number of assets. Each asset should specify a “Has PII” attribute within the asset management system. For Saltwort, this indicates if Personally Identifiable Information (PII) is stored on the asset elevating the need for additional monitoring and protection.
In the time series sample shown here, it becomes apparent in the fourth quarter the Has_PII value is no longer set consistently. September shows all assets having the value set, and all other months show a few assets missing the value.
While further analysis is needed, this simple chart helps identify possible systemic problems, and where to look.
It reveals nearly every month a few assets missing the Has_PII indicator. This raises several questions. Are missing values corrected manually after provisioning, while some are occasionally not addressed? Was the sudden increase in December the result of a skipped manual process, for example, someone was on vacation or tickets misrouted? Was Problem Management aware the Has_PII information was not provided as expected in all cases? Was there an issue or change in December with the provisioning or automation process? Was there a recent change in vendors or support contracts?
Extending the asset list with additional information like support groups, ownership, ticketing, requestors, or provisioning teams can help identify where problems are originating. Do errors originate from a particular requestor or when provisioned in a specific environment? Are tickets being created? Where are process improvements needed?
Identifying assets with PII is very important to Saltwort International. Any data breach and potential exfiltration of PII is costly, affecting stock price, company trust, and future or existing contracts. Properly identifying assets is vital to Information Security to prioritize remediation. Identifying and addressing the root cause and data accuracy will reduce risk and better protect the company and employees.
In the example, root cause analysis revealed the Asset Management system’s API did not reject poorly formatted asset data as sent by a new cloud provider. Some asset data was corrected after provisioning by assigned system administrators, however, a staffing change in December led to unresolved misconfigured assets. Problem management was unaware of the issue because corrective tickets were not generated. Fortunately, the number of affected assets was small, thus, updates were quick to manually implement in the asset management system. Problem Management worked the API and data quality issues to prevent further misconfigurations.
While the graph and sample data are simplistic, it illustrates how to measure and evaluate a provisioning process and its related asset management information. Adding further details such as asset ownership or the provisioning environment can aid root-cause analysis to both correct the data and resolve the underlying problems.
Rebellious Oak and @DryCyber are a nom de plume to express thoughts, stories, and opinions on cybersecurity and business independent of any specific company, person, or governing body. Rebellious Oak uses the fictitious company Saltwort International to illustrate examples derived from real experiences and observations. Any reference to existing businesses, people, events, or case studies are coincidental.