What value does an automated asset inventory system have for the risk identification process?

Asset and Data Inventory

Having an asset and data inventory is a basic part of any security program, but in many cases, it looks easier than it is. Assets usually are tracked at some level by other functions, but often, these inventories don't include the information that you will need. At a minimum, you will want to capture this basic data in your inventory:

System Type and Version

Software (including Version)

Physical and Logical Location

Logical Network Addressing

Owner

Resource Administrator

Data Sensitivity

For added efficiency, combining your inventory data with your Security Risk Profile can provide the TVM program with a single source for much of the data needed to verify applicability.

Let's imagine that a vulnerability notification for Apache Web server, version 2.0, is released. The first question you would need to ask is, “Does this apply in my environment?” If the answer is, “No,” then you have nothing else to do; it isn't productive to spend a lot of your own and the administrator's time trying to track down and qualify vulnerabilities that turn out not to be applicable in your environment. If, on the other hand, the answer is, “I don't know,” then you can't qualify the risk. For example, you may not run Apache directly on any of your Web servers, but a vendor product in your environment may use an Apache server as part of their application without you realizing it. So you can't rely solely on asset inventories that are based on records of what has been purchased, you also need to compare this to active discovery and scanning results.

There are many ways to start gathering inventory information if you don't already have a central database of assets:

Vulnerability scanning data will tell you a lot about your environment, but not necessarily about the business context for applications.

Infrastructure devices, such as DHCP, DNS, and NAC servers, can also be a good source of information.

Many organizations have a naming convention for systems that can be helpful.

Software licensing and maintenance contracts may also be helpful.

Records of technology purchases from the acquisitions or finance department are always helpful.

Methods for putting together a data inventory are similar: you can do scans of your environment, passively monitor communications, interview business owners, and so on.

Classifying Assets

In addition to developing an asset inventory so that we know specifically what we are protecting, in the sense of individual hosts, it is also vital that we know what the importance of the individual hosts is. We might choose any number of factors to rate the importance of a given host, but a few of the more likely are items such as whether the host is internet facing or not, whether it represents a single point of failure, whether it supports a critical process for the organization, and whether it stores or processes sensitive data. There will, of course, be any number of factors that may be more or less important in any given environment, and we should choose those appropriate for our needs.

We can generally assign a criticality level to the system and can base further efforts in the direction of security it on this rating. As with the asset list that we just discussed, having a formal definition of the criticality of any given system is a foundational part of developing the security program. If we cannot say that system X is more, less, or equally as important that systems Y and Z, then we have no basis for prioritizing work toward securing these systems, incident response efforts, disaster recovery, and so on.

How This Book Flows

The intent of this book to convey as much useful information about security requirements, threats, vulnerabilities, and risks in the IoT as possible, in a context familiar to those who must manage risk. It will therefore follow a format that will be immediately familiar to those who have conducted risk analyses, read threat-risk assessments, conducted them, or even have a broad-based security background that has introduced them to formal risk management.

So how does a risk assessment typically flow? Thusly:

Asset inventory: What are you assessing or protecting?

Requirements and sensitivity analysis: To how much damage are the assets susceptible, from the perspective of confidentiality, integrity, and availability? (In other words, unauthorized disclosure, change, deletion, or delay.)

Threat analysis: Who or what might want to impact sensitivity?

Vulnerability analysis: Where are the weaknesses that a threat agent might exploit?

Risk and mitigation: Taking into account the frequency or likelihood that a threat agent will try and exploit a vulnerability, what is the risk? Risk is almost always expressed in a qualitative manner (high/medium/low, for example), and we will not attempt to go beyond this convention. And finally, what can you do about the risk?

In the course of this book, we will hit all these high points and have developed chapters to fit this approach.

This chapter is an introduction to the concept of the IoT, what it might be, and what it probably is not. “Might” because this is a new area, and definitions are not hardened or complete.

Chapter 2, The Anatomy of the Internet of Things, is about the parts of the anatomy of the IoT: component parts and the different stakeholders. This is intended to identify what is in scope when discussing risk and the IoT. This is the first exercise of sensitivity analysis, as described previously.

Chapter 3, Requirements and Risk Management, is the second part of a sensitivity analysis—what are requirements for confidentiality, availability, and integrity from the perspective of business and operations?

Chapter 4, Business and Organizational Requirements, is about threats to the IoT: the “who” and “why” associated with the risks as we understand them now. In Chapter 4, Business and Organizational Requirements, as in Chapter 3, Requirements and Risk Management, we will try and remain at the business and operational level for discussion.

Chapter 5, Operational and Process Requirements, is about vulnerabilities in the IoT at the business and operational process levels, sometimes touching on technical issues. Vulnerabilities, in contrast to threats, are about the “how” of risk. How will a threat agent or entities inflict damage?

Chapter 6, Safety Requirements in the Internet of Things, is about safety risk requirements in the IoT and how they are related to security requirements.

Chapter 7, Confidentiality and Integrity and Privacy Requirements in the IoT, is about privacy, confidentiality, and integrity requirements in the IoT.

Chapter 8, Availability and Reliability Requirements in the IoT, is about availability and reliability requirements in the IoT and the associated risks and vulnerabilities.

Chapter 9, Identity and Access Control Requirements in the IoT, concerns identity and access control risks and vulnerabilities in the IoT.

Chapter 10, Usage Context and Environmental Requirements in the IoT, is about usage context and operating environment requirements in the IoT.

Chapter 11, Interoperability, Flexibility, and Industrial Design Requirements in the IoT, is about flexibility and interoperability requirements in the IoT.

Chapter 12, Threats and Impacts to the IoT, is a broad discussion of threats in the IoT, including a strategy for threat assessment and ranking.

Finally, Chapter 13, RIoT Control, is about treating the new risks in the IoT. It describes some of the potential new management techniques and operational controls and safeguards that might evolve in the coming years.

We have tried to make this book approachable for a variety of readers, not merely risk management and security nerds, so expect to see chapters that might drift into discussions tangential to pure risk management, but helpful to provide context. The IoT is a rapidly developing domain and any aids to memory or comprehension are generally helpful.

Some technology considerations

Some of the key integrations and capabilities to consider in selecting technologies for Asset Management and Financial Optimization are

asset inventory (integration);

asset license/usage (integration);

asset contract management (integration);

financial or business-related analytics (integration);

service catalog for indicating service costs and articulating asset values (integration);

vendor management data (integration);

support for desktops and mobile devices from a life cycle perspective;

modeling to support document/contract affiliations, locations, owners and organizations, license-related Ts and Cs, and vendor/supplier SLAs and other cost-related data—as attributes for critical CIs;

automation in support of asset-related compliance audits;

integrations and analytics to support IT-to-enterprise planning and financial optimization.

Capabilities for change and configuration management as described in the first use case are also relevant considerations for life cycle asset management and optimization.

However, once again, please realize that eating the Asset Management and Financial Optimization elephant is best done one bite at a time. Do plan to build toward a more robust cross domain functionality with a longer-term vision but target phase 1 objectives based on realistic requirements. For instance, life cycle asset optimization for endpoints (desktops, mobile devices, etc.) represents a meaningful piece of the elephant in itself—and is more than enough to justify a useful set of phase 1 objectives.

IT Asset Inventories

One of the activities that should be started early during the data collection phase is the compilation of IT asset inventories and IT asset owners. This activity can be initiated at the early stages of the project and be run in parallel with the executive interviews. In fact, having a good knowledge of the IT assets would help you in the executive interviews especially when talking about systems that support the processes being discussed during the interview.

An IT asset inventory, as the name implies, is a list of IT assets that belong to the organization and support a business process or processes. The goal of this activity is to identify as many systems as possible and then, in the scoping phase, narrow the list down to the most important systems. An IT asset inventory basically gives you the building blocks to start your risk assessments for the individual systems.

This process sounds simple enough; however, time after time we have seen this activity be a source of confusion, especially during early implementations of the risk assessment and management process. This is particularly true in organizations that have never done a risk assessment and have a relatively immature control environment especially in the area of asset management.

The first step in this process is to identify sources where you can obtain or collect information for the IT asset inventory. There is rarely a “good” place to obtain this information and it may vary from organization to organization. In fact, depending on the type of organization you are working in there may be no listing or inventory at all. We have compiled a listing of groups that are typically involved with maintaining a rationalized listing of applications. Approaching these groups may give you the best chances of obtaining a good listing:

Asset Management Group.

Enterprise Architecture.

IT Application Support Group.

IT Operations Group.

Network Group.

Head of Individual Departments.

Finance—Procurement/Purchasing.

If you are lucky enough to be in an organization that has its own asset management group, there is a good chance that you will be able to get a decent listing; however, before you get your hopes up, some asset management groups focus primarily on tracking hardware rather than software and so they may not be able to provide much assistance. The organization’s application support group, as well as the enterprise architecture group are also typically great sources of information when trying to compile an IT asset listing.

Ok, so now you know the groups you should approach; however, how do you narrow down the individuals that you should be approaching? The best people to approach would be the operational or line managers for each group, as they are the most involved with actual operations. Going to executives to obtain this information may be of little value since the knowledge of day-to-day operational details tends to decrease the higher you move up the organizational hierarchy. Operational and line managers are more likely to know the key applications and supporting databases that are supporting their operations.

Ultimately, you need to keep in mind that your goal is to gather as much information as possible to allow you to build the closest approximation of all the systems supporting the organization. The information to be collected includes but is not limited to:

Listings of Enterprise Applications.

Listings of Databases.

Software Inventory.

Hardware Inventory.

System Diagrams.

Technical Design Documents.

The goal here is to combine all of the information collected into the form of a single list (e.g. a spreadsheet). Though you shouldn’t be picky when obtaining information from various sources in the organization there are certain important data elements that you should try to capture. These are:

Asset Name.

System Name.

Description of the System.

Hostnames or IP Address.

Vendor if any.

System Owner.

Technical Support Contact.

Department that uses the Asset.

Description of Data.

Classification of Data.

No of Records.

If an application:

Operating System.

Database.

If a database:

Operating System.

Applications Supported.

There are a variety of different sources for the above information, so it is important to rationalize and normalize the list. One common problem occurs when various groups use different modules of a single enterprise application and refer to the system by the module they use instead of the applications name. As trivial as this may sound, when it happens this can lead to having 10–15 entries on your listing, all of which are for the same system. Another question you will face is whether you should consider a database that supports an application as a separate asset. This is actually a tough question to answer. Let’s say that you have identified a database that supports multiple applications. Should you consider the database as a separate asset or would you only identify the application assets and leave the database server off the list? Ultimately, this depends on the application and database architecture. For a database that supports multiple applications such as a database cluster, there is an argument that it should be considered as an asset for purposes of creating your listing. In an instance where the database supports one application and is self-contained, you may just consider the application stack as one asset.

In many cases, the collection and correlation of the data needed to build your listing does not go as well as planned. There are usually large gaps between what information you would like to obtain and what you actually have. The goal here is to gather as much information as you can. At the very least, you should aim to obtain the system name and system owner as this information will allow you to follow-up and gather more detailed information through interviews.

A sample asset inventory is provided in the companion website of this book.

Detecting Operating Systems

A really nice feature of Nmap is the ability to remotely detect OS versions. This is particularly useful for network asset inventory and OS patch management. For example, you may use Nmap OS detection to identify outdated or unauthorized systems on your networks. Nmap performs OS detection by probing the target host and analyzing the responses. Probes include TCP and UDP packets that examine OS specifics such as initial sequence numbers (ISN), TCP options, IP identifier (ID) numbers, timestamps, explicit congestion notification (ECN), and window sizes. Each OS has distinctive responses to the probes, which identify the OS and result in an OS fingerprint. The probes and response matches are located in the nmap-os-db file. Nmap will attempt to identify the following parameters:

Vendor Name The vendor of the OS such as Microsoft or Sun.

Operating System The underlying OS such as Windows, Mac OS X, Solaris.

OS Generation The version of the OS such as Vista, XP, 2003, 10.5, or 10.

Device Type The type of device such as general purpose, print server, media, router, WAP, or power device.

In addition to these parameters, OS detection also provides useful information on system uptime and TCP Sequence Predictability Classification, which is the measure of the difficulty to forge a TCP connection against the remote host. To enable OS detection with your port scan use the -O command-line option. For example:

# nmap -O 192.168.100.2

Starting Nmap 4.50 (http://insecure.org) at 2008-01-03 21:40 EST

Interesting ports on 192.168.100.2:

Not shown: 1709 closed ports

Device type: general purpose

Running: Apple Mac OS X 10.4.X

OS details: Apple Mac OS X 10.4.8 – 10.4.10 (Tiger) (Darwin 8.8.0 – 8.10.2)

Network Distance: 0 hops

OS detection performed. Please report any incorrect results at http://insecure. org/nmap/submit/.

Nmap done: 1 IP address (1 host up) scanned in 11.844 seconds

This command will use Nmap’s default SYN scan for port detection, but the OS detection option can be combined with any of the port detection techniques.

Nmap includes several command-line options to configure the OS detection engine. To limit OS detection to targets with at least one open port and one closed port, thus increasing your chances of a successful identification, you can use the --osscan-limit command-line option. If Nmap can’t make a perfect match for an OS it will guess something that is close, but not exact. To make Nmap guess more aggressively, you can use the --osscan-guess command-line option. Lastly, to make OS detection quicker you can lower the --max-os-retries command-line option. By default, Nmap will retry OS detection five times, and two times when conditions aren’t favorable. Setting the --max-os-retries to a lower value such as 1 will speed up the detection process, but detection may not be as reliable.

This section provided a basic introduction to Nmap’s OS detection usage. Table 4.4 summarizes the OS detection command-line options. Nmap’s OS detection features are covered in more detail in Chapter 6.

Table 4.4. Operating System Detection Command-Line Options

Note

For detailed information on OS detection, including usage and customization, check out http://insecure.org/nmap/osdetect.

What level of change management is most effective?

The last is one of the most critical points of ITSM: You must manage changes to configuration carefully. ITSM does not define the size, scope, or shape of a component; this task ITSM leaves up to the organization. The general rule is that you should size each component in a CMDB to the level of “independent change” or “maximum control with minimum records.”1

Finding the right components to include and pinpointing the appropriate level of detail is the ultimate challenge, but generally you can start with an asset inventory and justify your way simpler or more complicated. If you develop software internally, you will need to account for changes to these components as well. With a model, you can see the effects of architecture and process on each individual component to help you make decisions. A model can help you

Understand the relationships

Estimate the impacts of each change before making changes

Ensure that resources do not make untracked changes

HP's Change Management group defines five principles of change management. The following principles are the basis for the Global Change Management Standards and Procedures. (See Table 8.1)

Table 8.1. Change management

(Source: HP)

Process Summary

At this point, we have completed a full information security risk assessment; however, the overall process is not finished. The final part of our information security risk assessment process is to conduct a post-mortem in order to see if there are options and alternatives for improving the process. Before diving into the post-mortem review let’s look back at each of the phases of the process:

Asset Identification and Valuation

The second concept to understand involves asset identification and valuation. An important component to a risk management methodology is the identification and inventory of information assets. Without an accurate asset inventory, it will be difficult to assess risk and ensure appropriate administrative, physical, and technical safeguards are implemented to protect the organization’s assets. For example, as the HIPAA Security Rule mandates protection for electronic protected health information, the organization must understand where this type of information is stored, received, maintained, or transmitted to ensure it receives appropriate protections and the organization maintains compliance with the law. Asset valuation is another important factor in identifying the importance of assets to an organization. Value can be derived in both tangible and intangible forms and associated with risk (e.g., low, medium, high). Tangible forms involve direct (real) value of physical assets including revenue and server or facility costs. Intangible forms involve indirect value such as brand, reputation, and loss of prospective customers and intellectual property. For example, let us say a healthcare organization has an online prescription filling system that generates $5000 per hour in revenue. If the system goes offline unexpectedly for 3 hours and leaves the organization unable to take new orders or fill prescriptions, the organization would have $15,000 in tangible (direct) revenue losses. The organization might also incur intangible losses associated with media coverage of the outage impacting brand and reputation or customers filling prescriptions with a competitor. An inventory of information assets and their associated value will enable organizations to leverage a risk-based approach to protecting only those assets with the greatest need of protection. Otherwise organizations will be left wasting resources and likely failing to protect all information assets equally based on the highest set of requirements.

Developing a Security Policy

The aim of this process is to develop policies and procedures that are designed to meet the business needs of the organization. This process should provide a framework under which all security architecture design, implementation and management can be accomplished.

Security policy and procedures should be created from information collected from the organization and its staff. To determine what your security requirements are, is best achieved by a combination of:

The results of an information asset inventory

Interviews with information asset owners

Interviews with IT security staff

Interviews with organization managers.

The next stage is to develop a corporate security policy that will contain, at a minimum:

A definition of information security with a clear statement of management's intentions

An explanation of specific security requirements including:

Compliance with legislative and contractual requirements

Security education, virus prevention and detection, and business continuity planning

A definition of general and specific roles and responsibilities for the various aspects of your information security program

An explanation of the requirement and process for reporting suspected security incidents

The process, including roles and responsibilities, for maintaining the policy document