IT asset inventory vs an ISI – What’s the difference?
Many frameworks, standards, and regulations require organizations to have an IT Asset Management program in place. However, the understanding of what separates a mature Information System Inventory (ISI) from an IT Asset Inventory and the benefits realized from an ISI are generally less well understood. Naturally this may lead to a higher likelihood of deprioritizing an ISI in favor of what are viewed as more pressing security needs.
Figure 1. An Information System Inventory (ISI) is a record of Information Systems in an organization and includes information traditionally in an IT Asset Inventory.
But a properly constructed ISI should be prioritized as the foundation on which organizations implement a System Development Lifecycle (SDLC) program, facilitate Security Operations activities, make informed risk management decisions, move towards a more data centric view of security and mature their security posture as a whole. The ISI is an opportunity for an organization to have a core source of intelligence that ties security information across the organization together. Having the ability to view risk at multiple levels (network level, system level, division level, organizational level etc.) is becoming ever more important as organizations implement more complex environments and move away from a traditional network perimeter.
Policy, process & training: Ensuring reliable information
One of the best places to start maturing the ISI is to mature the categorization process. Without measures in place to ensure repeatability and consistency, information may become suspect and of little value. It is critical to implement a process that satisfies the need for stringent accuracy, but that is not so cumbersome it makes efficient use of personnel resources difficult. One of the most effective ways to balance this need for accuracy with the need for agility, is to invest significant time in process creation, documentation, and training. This includes defining and documenting the process itself, definitions for each field and each possible field answer, and the creation of tools such as interview templates and forms.
Utilizing training sessions and tabletop exercises then ensure all interviewers implement the processes in a consistent and accurate manner. As categorizations are conducted on an annual or recurring basis, it is important to continuously update the process documentation, definitions, and training to align with the implemented process.
Figure 2. A possible process for categorizing an Information System
It is also important to design the categorization process to allow for documentation of reasoning behind critical fields. Besides the obvious benefit of providing a high level of confidence that the information is accurate and easing the quality assurance process, this also has the added benefit of capturing inevitable grey areas and edge cases not considered in the original process. As the organization continues to mature their ISI and the categorization process evolves, notes on previously categorized systems are also invaluable in backfilling information for newly identified business uses. This reduces re-work required, helps ease maintenance of the ISI, and provides a more accurate picture of current risk.
Figure 3. A short list of possible categorization fields and reasoning fields for critical fields.
Shared responsibility of categorizing a system
As an Information Security professional, the interviewer’s role is to provide guidance to the Information Owner. Interviewees (Information Owners) have authority over the system and system’s risk but are often senior representatives in departments outside of IT. Information Owners rely on correct categorizations for management of risk but may not be familiar with more technical categorization questions and fields. Therefore, the responsibility for accuracy relies on both Information Security and the Information Owner; Information Security asks probing questions, educates, documents, and provides recommendations while the Information Owner provides information about the system and has authority over the categorization values.
For an Information Security department to achieve its goals, it is essential for non-Information Security departments to be cooperative and collaborative. This is especially true for organizations where the IT department has traditionally assumed all risk for all information systems. When undergoing a cyber-transformation such as a shift in risk ownership, there is often resistance from new risk owners. Information Security should use categorizations as an opportunity to build valuable working relationships with external departments, position Information Security as a business enabler, and mitigate some of the resistance expected with cybersecurity transformations.
Figure 4. Split responsibility shown between the interviewee (Information Owner) and interviewer (Information Security) in making a correct selection on the FIPS 199 Availability rating. Explaining why categorization choices are made and why it is positive is a great way to help build a working relationship.
Plan for unknown discoveries
Expect to find more systems than were planned for. This is especially true for organizations where Information Security is not separate from the IT department, organizations where less mature System Development Life Cycle (SDLC) processes are in place, and organizations where a significant number of cloud systems are utilized. According to a Frost & Sullivan Stratecast SaaS survey, “expect that upwards of 35 percent of all SaaS apps in your company are purchased and used without oversight”. Plan for even higher percentages of unknown systems in organizations that meet more than one of the criteria above. Ensure development of a plan for what to do with discovered systems that are abandoned, un-owned, or partly retired. There is a risk with these systems that must be measured and tracked, however not all business information may be available in the same manner as systems with Information Owners and Information Custodians.
A system for systems
In order to gain maximum risk-management insight out of the ISI, the information within the ISI should tie together different data sources, be easily usable, and show supported business processes. Configuration Management Database (CMDB) tools are designed to best accomplish this task. CMDB tools often include automation and orchestration features that allow linkages and relationships between assets to be automatically populated and maintained. This then allows for a near real time display of risk. Although it is theoretically possible to do this without a CMDB, in practice the manual work required to manually create and maintain thousands of relationships usually make it time/labor prohibitive.
Creating intelligence – Linkages, automation and dashboards
An ISI within a CMDB gives the ability to link the business level information identified within the categorization meeting, to the system components it is built on. Each Information System is able to then be connected to business objectives and services. The ISI allows for aggregation of data at a system and organizational level that is leveraged across information security functions in support of vulnerability management, continuity planning, incident response, disaster recovery, compliance and more.
Figure 5/6. Sample inputs for a single high-risk system (top) and display of a possible risk overview dashboard (bottom).
The value that the ISI brings to the business is realized when information is able to be aggregated and tied together in a digestible way. While some dashboards are valuable to nearly all organizations (ex: server risk, production system risk, organizational risk etc.) each organization should tailor custom dashboards to best suit their needs. The creation of custom dashboards is often what separates information collection from actionable intelligence. Because actionable intelligence is at the root of business value, an organization with ISI’s in CMDBs should invest significant time and personnel resources in the development of tailored views, custom reports, and automation/orchestration workflows.
Once dashboards and linkages are set up properly, it allows for a significant level of system exploration – the lowest levels of information systems are tied to software versions, vulnerabilities, impact levels, information owners, recovery timelines, and business impacts. There are many use cases for this intelligence depending on the information collected and may include Compliance Monitoring, Vulnerability Management Monitoring, Third Party Risk Management, Change Management, Network/System Topology, Incident Response, and Disaster Recovery.
Consider an Incident Response & Disaster Recovery use case displayed in Figure 5 below. Several benefits are realized from when an incident is first identified in an organization’s Security Information and Event Management (SIEM) to when the incident is closed out. The server is tied to the business process it supports. The CISO is automatically notified for any incident impacting a critical business process and then utilizes the ISI for near real time updates. Current and potential future business impacts are communicated to business stakeholders. Critical priority Incident Response tickets are automatically opened on the assets identified in the SIEM. High priority investigation tickets are automatically opened for the rest of the system’s assets and for systems with direct connections to the compromised system. If any disaster recovery is required, systems are prioritized based off classification values in the ISI. When the investigation is concluded and the risk has been managed to an acceptable level, the ISI displays required public or private breach disclosure actions.
Figure 7. Sample Incident Response & Disaster Recovery use case where green boxes indicate significant benefit from a mature ISI.
ISI business value realized
Categorizations in which Information Systems are defined, and business level information gathered are a key step in developing or maturing an ISI. Some resistance to cyber-transformation (ex: shared responsibility of categorizations and system risk ownership transference) may be able to be mitigated by treating categorizations as an opportunity to establish working relationships between Information Security and external departments. An organization matures their categorization process by spending sufficient time on documentation and personnel training activities. An organization should plan for discovery of previously unknown systems and using a CMDB to allow for linkage of business level and categorization level information down to information system assets. By creation of tailored dashboards and orchestration, organizations have the ability to facilitate Information Security activities across the organization.