CHAPTER 5 Asset Identification and Characterization

Overview

We have seen that information security is associated with identified assets. All activities related to information security – security controls, disaster recovery and business continuity programs, and risk assessments, should revolve around protecting the confidentiality, integrity, and availability of the assets of the organization. Unsatisfactory asset identification can leave valuable assets unprotected while the organization spends time on protecting low value resources. Identifying and classifying assets is therefore the foundation of an information security program.

This chapter will describe the important assets in organizations. We will then examine how these assets can be identified and classified. Later chapters will discuss how these assets can be protected. At the end of the chapter you will:

• Be familiar with some of the issues involved in maintaining IT assets
• Have a basic understanding of the mission of the organization
• Know how to classify assets based on their alignment to the organization's mission
• Be aware of asset management issues including life cycle and ownership

Assets overview

The goal of asset identification and classification is to proactively gather all necessary information about an organization's assets that can be useful in responding to a threat affecting that asset. Asset identification should lead to the deployment of required monitoring mechanisms so that the organization can become aware of attacks and take necessary actions. In the absence of effective asset identification and classification, an organization may not even become aware of a threat. In fact, the 2012 Verizon data breach investigations report stated that 92% of all information security incidents were identified by third parties, often weeks or months after the damage had been done.¹ It is useful to identify assets yourself, before your adversaries identify them for you.

In Chapter 4, we defined assets as resources or information to be protected. But how do you know what needs to be protected? What is worthy of protection in one organization may not be considered important in another organization. For example, your music collection might be one of your most treasured assets, but your employer may not care so much for it. Asset identification and classification is therefore fairly unique to each organization.

While no simple checklist can be developed to identify assets, procedures to do so may be developed. Over the years, industry experts have published their collective experiences on securing information assets as various information security industry standards. ISO 27002 (formerly known as ISO 17799) is the information security standard published by the International Organization for Standardization (ISO). It outlines procedures for maintaining security, including recommendations for identifying and classifying assets. Control Objectives for Information and Related Technology (COBIT) is a similar framework commonly used by auditors which also addresses classification of IT assets. In this chapter, we will develop a procedure for identifying and classifying assets by synthesizing from these guidelines.

At a high level, asset identification and classification involves listing all IT assets in the organization, and characterizing the importance of each asset to the organization's information security, paying attention to the IT systems within which each asset operates.

Broadly speaking, all assets may be classified into two kinds – general and idiosyncratic. General assets are assets that are found in most organizations. An example of a general asset is email. Virtually every organization uses email as its primary form of communication and virtually every such organization will consider its emails as an asset worth protecting. You may be able to develop checklists for such general assets without any special knowledge about an organization, based on prior experience, discussions with colleagues or Internet searches.

On the other hand, an example of an idiosyncratic asset is student transcripts. Universities and other educational institutions consider these as vital assets because alumni are entitled to ask for transcripts anytime in their lives. Alumni may potentially sue if they miss out on a job opportunity as a result of the failure of their alma mater to produce a transcript on demand. However, companies are not likely to place such a premium on employee transcripts. Except for some regulated industries (e.g., medicine, accounting), once a person has put in a few years on the job, his career depends upon present performance rather than a college transcript. Therefore, once an employee is hired, employers may not care to save their transcripts. Student transcripts are therefore an idiosyncratic asset. Idiosyncratic assets are assets that are distinct to an organization. It can take considerable effort and attention to detail to identify idiosyncratic assets in an organization correctly.

As an employee or analyst, determining idiosyncratic assets requires a determination of the processes, procedures, and activities, which ensure that the organization works to its optimal ability. Such determination starts with one fundamental question: what exactly does this organization do? The answer to this question can appear simple enough, such as “this company sells cars” or “this business cuts hair.” However, to identify all the assets relevant to the business, the security analyst needs to dig deeper and determine what is important to the owners, customers, and employees of the organization.

Determining assets that are important to the organization

Two common approaches to identify the idiosyncratic assets important to the organization are the bottom-up approach and the top-down approach.

Bottom-up approach: talking to coworkers

The bottom-up approach is normally what happens when someone is hired. It is also often referred to as the “learning curve,” the period of time a new employee has to get acclimated to the work habits and needs of the organization. The employee is either handed a lot of documentation to read and understand, or is paired with an experienced peer to teach her the ropes. This time is the perfect opportunity for the new employee to determine the importance of specific processes to the company. It is also the opportunity to start determining the dependence of lesser-known items to the achievement of the company's goal. While the employee is likely to know what makes the organization relevant to customers, now is the opportunity to find out what is important to the company's operations and tie the needs of the organization and the needs of the customers together.

No one knows the inner work of a workplace as well as the folks that deal with issues on a day-to-day basis. For example, current employees can bring to the new recruit's attention the fact that a simple DNS server failure may bring down a $2 million-dollar application that is critical to the operation of the company.

Top-down approach: understanding the goals of the organization

In addition to looking at the organization from the bottom-up, through conversations with operational staff, understanding the goals of the organization from the point of view of executive leaders is also very important. This can be done even without direct access to the top executives of the organization. Annual Reports and the “About Us” sections of an organization's website are important sources of information about the organization. Top management uses these places to communicate their personal priorities to the world. Other sources of top-down information gathering are Vision Statements and Mission Statements. These are statements used by the organization's leaders to clearly convey the values and priorities of the organization under their leadership.

A Mission Statement is a short (preferably one or two sentences long) expression of an organization's services, its target market, and its competitive advantages. The Mission Statement serves to inform stakeholders (e.g., employees, customers, suppliers) about the priorities of the organization and remind the leadership team on how success will be measured in the organization. Vision Statements articulate the organization's aspirations. Vision Statements also define the organization's purpose. However, Vision Statements speak only to employees and communicate the values and beliefs of the organization. Vision statements establish expectations of performance and behavior by employees in the organization. Vision Statements can communicate to customers the work philosophy of the organization, describing what to expect when dealing with the organization.

Since Mission Statements, annual reports, and other such documents make a conscious effort to distinguish the organization from its competition, a scrutiny of these documents can reveal what is important to the organization. While these statements are often dismissed as lofty and generic, efforts should be made to get an insight on what organization leaders believe is uniquely important to the organization. A few examples of recent information security incidents and the mission statements of the associated organizations follow.

These statements suggest that cyber intelligence, security, and electronic systems are the company's core businesses. Data in these areas is likely to be idiosyncratic to the company. Indeed, in 2007, BAE was a victim⁴ of an Advanced Persistent Threat (APT). APTs are highly sophisticated penetrations that remain hidden in an organization network, leaking information to outside hackers. APTs are usually deployed by government agencies to spy in other countries’ technological developments. The APT was used to steal design documents related to the F-35 Strike Fighter aircraft, for which BAE was a contractor. BAE's leaked data allegedly helped the Chinese government to develop the J-20 Fighter depicted in Figure 5.1.

Again, while these statements appear generic, they suggest that the company's idiosyncratic features will include knowledge of the user preferences of a significant share of the online population in the world, making it an attractive target for attackers trying to harvest user credentials. In July 2012, a simple security misstep in the design of one of its services, Yahoo Voice, led to the leakage of nearly 400,000 online credentials⁶ from Yahoo! servers.

Again, these statements appear relatively generic for a university. However, they suggest that the most idiosyncratic information in possession of the university is course material and student information. Loss of this information may be damaging to the university. In May 2012, a breach in UNL's Student Information System⁸ lead to the potential leakage of 654,000 students’ Personal Identifiable Information including Social Security Numbers. The number (654,000) vastly exceeds the student enrolment at the university because the university maintains records of all alumni. In addition, many universities maintain at least some information regarding all applicants to the university. Further, most universities also attract large numbers of students through non-degree programs such as summer enrichment programs.

As these examples show, organizations are likely to be targets for the most idiosyncratic information in their possession. While not an exact science, an examination of the organization's guiding principles can help to identify such information.

Asset types

As you work on identifying assets in your organization, it helps to know what to look for. What are the different types of assets in an organization? While some organizations may have very unique assets, the most important assets you are likely to encounter in information security are the following. These assets are present in all organizations in one form or another, and we will look at each of these:

• Information assets
• Personnel assets
• Hardware assets
• Software assets
• Legal assets

Information assets

An information asset is a digitally stored content owned by an individual or organization. This is usually the most important asset in an organization from the information security point of view. All deliberate information security attacks on organizations involve attempts to steal data. The most painful accidents with information security implications (crashed hard drives for example) involve loss of data. Therefore, an important component of asset identification involves searching for data and information important to the organization.

Informational assets include individual files such as images, photos, videos, and text files. They also include other digital content such as data in a database. These assets are stored either on a device owned by the organization (“locally”) or on devices accessed in the cloud, often as part of a service offered by a third party and governed by a contact with the organization.

Examples of general information assets include payroll data, cash flow data, customer contacts, credit card information, accounts payable, accounts receivable, tax returns, and email. In addition to such raw information, general information assets also include process information such as system documentation, user training manuals, operational documents that ensure regulatory compliance, and business continuity information.

Idiosyncratic information assets include intellectual property such as product designs and product test results. Intellectual property (IP) refers to creations of the mind (inventions, literary and artistic works, and symbols, names, images, and designs) that can be used for profit.⁹ In the context of a university, examples of idiosyncratic information include student grades, student test scores, and student transcripts.

While data is pervasive, executive leaders are often only aware of the security implications of information that has attracted recent negative media attention or that is included in matters of legal compliance. For example, most executives are aware of the security implications of credit card data. This is because there have been many incidents of credit card theft in the recent past and as a result the issue is discussed at all industry events. This is a classic example of a well-known cognitive bias, the recency bias, where the mind pays unusual attention to recent observations.

The challenge for security professionals is to identify information assets before the loss of such information hurts the organization. Consider the BYOD example below.

Personnel assets

Programmers, developers, and, yes, even managers are important organizational assets. It takes a long time to find an employee with the right set of skills who is willing to work at the salary your organization can afford. After the employee is hired, the organization invests a considerable amount on training the employee. Even if such training is not formal, only involving methods such as following another employee for a few days to learn the ropes, or spending days in the office reading user documentation, it creates costs for the organization. Later, as the employee develops professionally, learns the lay of the land, builds his social network within the company, he may find himself being the expert on a particular area. For instance, the employee may evolve to become the person who best understands something that may be a key operation to your department, such as string manipulation in Perl, or MySQL tuning for high-performance operation, or optimization of firewall rules. As an information security analyst, one of your responsibilities is to identify such individuals and manage the risks associated with their uniqueness. One way is to make management aware of the importance of these individuals, so that management can make extra efforts to keep them on-board. Another mechanism is to cross-train other individuals in the organization to take on some of these critical responsibilities.

Personnel assets are also documented from the perspective of disaster response. When an asset comes under threat, you should know how to contact the individuals who can respond to the threat. This documentation takes the form of collecting phone numbers, home addresses, email addresses, and any other applicable forms of contact information.

Hardware assets

Hardware assets include the physical pieces of machinery and associated systems directly or indirectly involved in the support of the mission of the business. It is usually “stuff” purchased with revenue, student fees, grant money, etc. Often, hardware is the medium in which the data exists and, therefore, without hardware there can be no data to secure, and hence no need for information security. Such hardware is as critical to the department as the data it contains.

In addition to the above well-understood role of hardware as a general-purpose asset, hardware may also be idiosyncratic to the firm in the form of a prototype of a new device, or a new patent. Prototypes are usually a form of Intellectual Property. Prototypes are often the foundation of new business opportunities pursued by the firm and so companies guard prototypes very carefully. To protect the commercial opportunities associated with the prototype, release of any information related to the prototype is protected by contracts called Non-Disclosure Agreements (NDA).

Tracking attributes

What should the organization be recording for hardware assets? This exercise is the foundation to many other security-related activities, from disaster recovery planning to risk assessments. Ideally you would like the information to be as complete as possible so that if a particular device is lost, you'd be able to replace it with little effort. Table 5.1 is an example of attribute tracking for a PC/laptop.

You should notice at this point that the table actually includes more than just the physical description of the machine.

• Purchase cost and EOL estimate – The purchase cost will give you a benchmark to use when you are looking into insurance and replacement cost in case of loss. You would need about $1,000 to replace this piece of equipment. The EOL estimate will help you in terms of budget. You should plan on replacing this laptop in about 3 years. At that time, you will need about $1,000.
• Asset delivery and production date – These dates will give you a glimpse of how efficient IT was preparing the machine for use. It includes the installation of OS and applications, configuration, and final delivery to the end user. The time span between these dates may increase at the end of the fiscal year, when traditionally departments are making their discretionary purchases. An abnormal increase may indicate additional complexities in the process or the need for more personnel dedicated to preparation of the computers.

You may have noticed that this “machine bio” would actually be useful to multiple departments within IT, and different folks should be able to contribute information. The networking folks, for instance, should be able to tell you which jack number that box is plugged into. They should also confirm the physical location. Desktop support should be able to update the last date of service, and compliance folks can use that date to come up with a list of when the computer was last checked by IT personnel.

Asset discovery

Managing an asset through its life cycle is the gold standard. But realistically the majority of organizations, especially small and medium-sized organizations, do not have formal procedure to follow their hardware assets through the life cycle. Servers get replaced when they break down or when they are too old to operate and their lack of performance starts affecting the business bottom line. In universities, desktops get passed on from faculty members to administrative assistants. Equipment gets purchased by grant money and magically “appears” on the network one day. In most departments, no one really knows (1) what hardware assets the department has or even (2) where these assets are located.

Network scans can be used to come up with a list of such devices. Unfortunately, scanning is not reliable because portable devices may not be connected to the network during the time of the scan. Even multiple scans, performed at different times, may not pick up all devices. To deal with this issue, many organizations institute policies requiring a periodic review of all equipment taken by off-site employees.

Software assets

Software assets are the software tools needed to manipulate the organization's information to accomplish the organization's mission. Software assets need to be protected in order to ensure that the data within the organization is readily usable so that the organization can maintain high levels of productivity. These assets have many of the same properties of hardware assets. General software assets include user applications such as Microsoft Office, enterprise applications such as PeopleSoft (used for maintaining personnel data), development tools, software version tracking systems, and security related software. Protection of software assets entails activities such as ensuring that the most current versions of the software is available and that the versions of software available are compatible with the versions of hardware deployed in the organization. General software assets are typically purchased.

Idiosyncratic software assets are typically software developed in-house, either to support local operations or to sell as an output of the organization.

Legal assets

IT-related legal assets are the contractual arrangements that guide the use of hardware and software assets within the organization. Examples of such assets include technical support agreements, software licenses, revenue sources, and funding streams. In the flow of day-to-day operations, these assets can be forgotten until they lead to disruption.

One well-known incident that demonstrates the importance of legal IT assets relates to Comair, a subsidiary of Delta airlines.¹⁰ In 2004, the airline was using a crew scheduling system acquired in 1986. Airline safety regulations specify strict guidelines on crew hours to ensure their alertness and the crew scheduling system ensured compliance with these guidelines. Forgotten was the fact that the airline had acquired licenses for a maximum of 32,000 changes in any given month. An unusually extreme winter in December 2004 caused the airline to reach that limit for the first time on Christmas Eve. Without the software, the airline could not operate, though all its aircraft were fully functional. The incident led to over 200,000 stranded customers on Christmas 2004, a loss of $20 million (compared to a profit of $25 million in the previous quarter) and the departure of the airline's CEO. All it would have taken to avoid the incident was an awareness of the licensing constraint and a purchase of the required number of additional licenses. The incident also served as the subject of a very readable book on IT risk management.¹¹

Asset identification – an example from a typical university

Now that we have enumerated the important asset classes, we can move on to identifying these assets in any given organization. General assets are easier to identify since general-purpose checklists can be drawn up to itemize them. Idiosyncratic assets are more elusive since the identification of these assets requires deep knowledge of the firm and its industry. To deal with this issue, most guidelines recommend a combination of bottom-up and top-down approaches to identifying assets. Identifying what is important to the organization can help locate assets idiosyncratic to the organization. Table 5.2 is an example of some representative assets you may find at a university.

Asset characterization

Now that all the assets have been identified, with the system profiled so that we know its dependencies, we are ready to start characterizing those assets. The two parameters used to characterize assets are sensitivity and criticality. Asset characterization helps us dedicate resources appropriately toward protecting assets. Ineffective characterization can result in large investments protecting insignificant assets, while leaving the organization vulnerable to common problems.

Asset sensitivity

Sensitivity describes how much damage a breach of confidentiality or violation of integrity of an asset would cause to the organization. We can examine sensitivity based on the following example.

Hopefully you picked option 1. Not because he is a faculty member. If an unauthorized person gained access to Dr. Jameson's research, not only would the US Armed Forces personnel would be potentially put in danger, the university could face serious consequences in terms of grants. And Dr. Jameson himself could go to jail. In fact something similar happened with Prof. John Reece Roth. In July 2009, Roth received a 4-year prison sentence for illegally exporting military technology, in large part due to his work with graduate students from Iran and China.¹²

There are different guidelines on classifying the sensitivity of assets. Some organizations use a scale from 0 to 5. Others go from low to high. For the purposes of this book, we will use a simple binary scheme and classify assets in one of two categories: restricted or unrestricted.

Restricted asset

A restricted asset is an asset in which disclosure or alteration would have adverse consequences for the organization. It is up to the organization to make the determination on the threshold itself. Some consequences may be acceptable when compared to the cost required to secure the asset. This determination is called risk acceptance and will be discussed again in later chapters.

Take your grades, for instance. Your grades are a highly restricted asset to your university. Not even your parents are allowed to see them without your consent, even if they are paying your tuition in full. That does not happen necessarily because the university is one of the good guys. Universities are required to protect your grades and other data in order to be complaint to the Family Educational Rights and Privacy Act of 1974 (“FERPA”). FERPA is what is known as a “Spending Clause” statute: “No funds shall be made available under any applicable program…” unless statutory requirements are met.¹³ Unless the university complies with it, no federal funds would be allocated to the university (including student financial aid).

Quite a few of the assets you will find that are considered “restricted” are due to some sort of compliance. Some examples are Payment Card Industry (PCI) compliance, guidelines issued by banks to protect credit card information, the Health Insurance Portability and Accountability Act (HIPPA), and the Sarbanes–Oxley Act (SOX), which sets new or enhanced accounting standards for all US public company boards, management, and public accounting firms.

There are also other assets that may be considered restricted as a matter of choice by the organization. System Characterization reports, for instance, specify exactly what systems the organization consider critical for operations. They also may show vulnerabilities a person could exploit to gain access to the system (remember the unsecured channels on email?). So, System Characterization should be considered restricted. Other examples could include personnel salary, budget spreadsheets, internal audit reports, and others.

Unrestricted asset

Unrestricted assets are assets not classified as restricted. It is the data that, if leaked or viewed by someone, would not cause problems for the organization.

We saw that your grades are considered restricted information. In contrast, your university also has something called Directory Information, which is information about you that could be posted publicly. Normally, the following information is considered Directory Information and, therefore, unrestricted data: Student Name, Local Address and Telephone, Permanent Address and Telephone, Email Address, Place of Birth, Major Field of Study, Dates of Attendance, Full or Part Time Enrolment Status, Year in School (Class), Degree(S) Received, Scholastic Honors and Awards Received, Other Educational Institutions Attended, Visual Image, Weight and Height of Athletic Team Members.

If you are surprised and are wondering what your university considers Directory Information, look it up. Universities are also required to provide mechanisms to turn your unrestricted data into restricted data. There is usually a privacy form you can fill out with the Registrar's Office that allows you to keep the university from being able to release, for instance, your address.

Information posted on public websites is usually unrestricted information. Marketing information assets, a university's class catalog, and nutrition facts on a food or beverage are also examples.

Asset criticality

Asset criticality is a measure of the importance of an asset to the immediate survival of an organization. The level of criticality of an asset is usually tied with the availability of an asset within the CIA principles of security. Criticality asks the question: how long can my organization survive without this resource? The more critical an asset is, the bigger measures an organization has to take in order to make sure it is redundant, backed up, and protected for failure.

When trying to determine the level of criticality of an asset, you will find that it is largely in the eye of the beholder. It will vary from department to department within your organization, especially when an asset is only perceived to have benefits to their own organization. Some assets are clearly serving the entire enterprise and are often referred as Enterprise Business Systems (EBS). For example, the systems handling HR and payroll functions are usually considered EBS systems. In the university environment, the system handling student grades is considered an EBS. However, an email system handling only the College of Medicine would not be considered EBS, as it only works with that college. It is, however, critical to the College of Medicine operations. EBS systems are generally considered critical, while non-EBS systems are not.

Various classes of criticality are defined in the industry. A basic classification system categorizes assets as essential, required, and deferred.

Essential asset

An asset should be considered essential if the loss of availability would cause immediate severe repercussions for the organization. This implies that the organization needs to determine its definition of severe. As far as the duration, an essential asset would be missed even if its absence lasts only a brief period of time.

Take the wheels in a car, for instance. If you are driving your car down the highway, wheels are essential. A blowout could spell major disaster for you and your passengers. Other examples may include a purchasing system for a web-based vendor, electrical power for a hospital, and lifeboats for the Titanic.

One common flaw in information security is that essential assets are sometimes not protected properly and their availability is often taken for granted. We will review this issue further in when we discuss Disaster Recovery in Chapter 11.

Required asset

An asset is considered required when it is important to the organization but the organization would be able to continue to operate for a period of time even if the asset is not available.

Let's think of our car analogy again. This will also illustrate the time-dependency of the criticality level. The wheels are clearly considered essential if you are driving down the road. But what if you get home and later in the evening find that you have a flat? At that point in time, assuming you don't have anywhere to go, the wheels could be considered an essential asset: they are important but not critical. They may again be critical the next day when you have to leave for work, but until then you would have a chance to rectify the problem. One of the ways to rectify things is to activate your Disaster Recovery plan: get the jack, install the spare tire, and take the bad one to be fixed. Downtime: about 20 minutes.

Deferrable asset

A deferrable asset is an asset that is needed for optimal operation of the organization but whose loss of availability would not cause major issues to the organization in the near term. If an asset is described in terms similar to “well, eventually we would like to have it back but we could do without it for now,” you know that the asset is a deferrable asset.

These assets are items that would maybe make the organization run smoother, more efficiently, but could be rebuilt it needed. Take something simple, like the pen you are using in class. If you lose the pen you may have difficulty taking notes in this class, but you could simply find a pencil in your backpack and it would work just as well.

Here's another. Imagine you have a 10-item list of to do chores around the house. One of them is to vacuum your room. But in order to do that you have to use the vacuum, but your sister is currently vacuuming her room. Of course you always have the option of going and doing a hostile takeover of the asset if you consider it required at this time. Or you could do the other tasks first and defer the need for this asset at this time in the hopes that she will be done by the time you are done.

Deferrable assets are also those information assets that can be re-created without major impact. Your professor writes your grades on a sheet of paper before entering them on your university's Student Information System. If the computer he is using suddenly crashes and he loses the data he was entering, no worries. He still has that sheet of paper and can reenter the missing data.

The elements of asset characterization are shown in Figure 5.2.

Table 5.3 builds up on the example assets by characterizing them. Some definitions are clear-cut. Others require a bit more thinking and perhaps even negotiations within the organization. Take the MS Office Suite, for instance. The software itself, the DVD with the application, can be considered an unrestricted asset because to get the application to run, you need a Product Key. As long as the Product Key is restricted, the MS Office Suite can be considered Unrestricted.

This completes the essentials of asset identification and characterization. However, in practice, an exercise in asset identification and classification requires the analyst to be aware of the environment within which the assets operate. The environment may be characterized along four dimensions – life-cycle stage, system dependencies, ownership, and responsibilities. The prototype case is when a department is considering the purchase of an IT asset with its own budget. The people deciding on the purchase are likely to be business people, with limited awareness of the impacts of the purchase on other IT systems. As an information security analyst with an awareness of the asset life cycle, system dependencies, ownership, and responsibilities, you can be better positioned to guide the introduction of the asset into the organization. We cover these issues in the remaining part of this chapter.

IT asset life cycle and asset identification

Assets have long lives. During their usable lifetimes, assets pass through many stages. While most discussion of information security revolves around assets in operational use, asset identification requires a scrutiny of assets in all stages of the life cycle in order to minimize the likelihood of security issues arising from the use of the asset. This section introduces the asset life cycle and provides examples of potential hazards arising from oversights at each stage of the asset life cycle.

Figure 5.3 shows a generic IT asset life cycle. In the industry, the management of IT assets over their life cycles is called IT Asset Life Cycle Management (ITALM).

The IT asset life cycle in Figure 5.3 shows the high-level stages of an asset. It includes the following stages: planning, acquisition, deployment, management, and retirement.

Planning stage

Assets don't just “show up” in a business. They are usually acquired for a particular purpose, answering a requirement, a project, or an initiative. For instance, when a new employee is hired, one would imagine that the first step would be a change in the work environment in some form, either increased load on existing personnel performing a task, or the need to track and maintain compliance with a new law, or the unveiling of a new product. The cost of the asset will also be considered at this stage.

The planning stage is also the best time to evaluate the organization's processes to try to leverage the new asset to help with multiple initiatives. For example, a planning exercise may be initiated to acquire software that will encrypt data within a database. The driving force to acquire the asset may be the need for compliance at the state level, with laws requiring Social Security Numbers to be encrypted whenever stored within a Student Information System. However, with appropriate planning, the same software license could also cover credit card numbers stored by the local computer store, or copies of tax returns stored by Financial Aid.

Perhaps the best known example of an oversight at the planning stage relates to the lack of security features built into the Internet. In the planning stages, no one had anticipated the extent to which the technology would be used for commercial transactions worldwide. The planners were mainly concerned with reliable data delivery. This omission is responsible at least in part to the security issues we face today on the Internet.

Another interesting example of an oversight at the planning stage relates to the lack of security features in Windows 95. The technology was developed to help users communicate over small networks in controlled environments, e.g., within homes and small offices. The focus was on user convenience. No one anticipated the wide adoption of the Internet and the use of Windows 95 to access the Internet. Without protections, these PCs became ready targets for attackers. In fact, at least some security experts believe that the information security industry owes its existence to the widespread deployment of insecure Windows 95 computers on an equally insecure Internet.¹⁴

Finally, consider the average lifetime of the asset and the potential need for a replacement at End of Life (EOL) during the planning phase as well. What will happen to the asset when it reaches its EOL for a particular project? Will the organization be able to reuse it for another project? For instance, a workstation used for 3D gaming development initially dedicated to a game designer may be assigned to an administrative assistant after a year, increasing the overall lifetime of the asset for the company.

Acquiring stage

After the planning stage comes the acquisition of the asset. The prime concerns during this stage are associated with the viability of the vendor, compliance with regulations and internal organizational procedures, and operational viability of the asset and ethics. This could involve a variety of methods and potential complications. Most companies require a series of approvals to ensure that the new asset satisfies these conditions. Some procedures used in this phase of the asset life cycle include:

• Invitation to Negotiate (ITN) – The ITN is a statement issued by a company indicating a willingness to look into a product or service. An advertisement, for instance, is considered an ITN. A company has a product and is willing to sell that product at a certain price. Keep in mind that a response to an ITN is different than an actual offer and could never, on itself, lead to a contract. ITNs are often used by government agencies when the criteria for purchase are more than just low price alone.
• Request for Proposal (RFP) – The RFP is issued when the goals of an initiative or project are known, but the company doesn't really care about how they are done. There may be several methods that could be used to accomplish the task and the company will consider all available options. Detailed instructions identify the elements of information or documentation to be submitted for evaluation purposes. An RFP usually will contain a description of the company issuing the RFP, explain the current condition, project, or challenge facing the organization, layout budget and time frame, and a set of open ended questions to be answered by the vendor.
• Invitation to Bid (ITB) – An ITB is used when the requirements for the purchase of the asset or service are very well defined and specific. An invitation to bid is generally structured in such a way that a respondent provides minimal documentation to support their qualifications to provide the goods or services. Examples of documentation required may include licenses, permits, insurance, proof of agreement from product source, references, available equipment, years, and experience performing the services sought. Once the respondent has passed the minimum requirements test, the award is recommended to the respondent with the lowest bid.

Deploying stage

Deploying is the stage where the asset is made available to organizational employees. The primary concerns at this stage involve compatibility of the new asset with existing organizational assets, integration with other organization systems, avoiding data loss, and minimizing downtime. The complexity of the deployment of new assets will vary greatly from asset to asset. One of the primary differentiators is whether the asset is a new product, software, or initiative versus an update to an existing one.

A simple deployment example would involve the deployment of a new desktop computer to a staff member. While this appears simple, let's think about this situation for a bit. To simplify maintenance, most organizations have minimum requirements for new machines, whether they are published or not. The desktop will come licensed with a specific version of the operating system, say, Windows 7 Home, but the organization is licensed and supports Windows 7 Professional. So, prior to doing anything else, the computer has to be wiped and the operating system reinstalled. Next we would install applications such as Microsoft Office and Adobe Acrobat. If there is an Active Directory domain, the computer would have to join the domain. Resources such as shared drives and printers are made available to the new machine. Since this is a security class, we also have to mention that antivirus software would be one of the top priorities. Ensure that the AV software is installed and updated prior to handing it off to the end user.

To minimize user downtime due to the upgrade (remember the CIA triad, confidentiality, integrity, and availability), the final step is to transfer the data files, including images and bookmarks, to the new machine. During this time, the user will not be able to work on either computer, old or new. The switch may have to be scheduled after hours to reduce the impact, or if the user is high enough up on the food chain that disruptions are not seen in a favorable light.

Are we done yet? Not really. The deployment should not be considered complete until the end user has a chance to sit down and test the new machine. This stage is known as the User Acceptance Test or UAT. Missing applications would have to be installed. Read and write access to shared drives confirmed. Only then the deployment phase is complete.

This is an example of a simple deployment. In the light of this example, consider the deployment of a new SCADA (Supervisory Control and Data Acquisition) system for control of a hydroelectric plant. Although very complex and seemingly daunting, the tasks are very similar. If you work for the company selling the SCADA system, the engineers who will be working with the system are your users. Keeping the lights on at people's homes is your goal, installing the new system with minimum impact to the home utility users. For the sake of simplicity, we can assume that the plant has a fully redundant system that can be brought online while work is done on the production system. Finally, testing will be extremely important. Are the controls working as designed? Are the fail-safe mechanisms in place to avoid catastrophic failures? Did the operational test, the nuts and bolts of the system, proceed without failure? Did the functional tests succeed as well?

Managing stage

Managing is the stage where the asset is in use. Once the asset is deployed, it is important to ensure that the asset does not introduce new vulnerabilities into the organization. For starters, let's again start small and focus on the desktop that was just installed. The staff member was absolutely thrilled with the IT desktop service performance, shook hands, and the employee said the usual “if you have any problems, give the help desk a call and we'll come take a look at it” and moved on to the next challenge. Even though the face-to-face support may have ended for the time being, there are many things happening in the background that are often times invisible to the user.

One thing we would like to do is to make sure we track where the desktop was deployed, who is the primary user, if applicable, and the MAC address of the new device (so we can track it on the network). This helps asset tracking, discussed later in this chapter. There are many ways to do this, from a simple spreadsheet for small organizations to large, automated tracking software that is normally deployed with the machine.

From the security perspective, there is one key element that must be done periodically in order to keep the desktop and the organization's computing environment safe: patches and security updates. We will discuss these at length in later chapters but for the time being it suffices to say that operating system, applications, and antivirus signatures must be patched.

The harsh reality for many IT assets is that, even though they may have been initially planned to have a End of Life of, say, 3 years, budgetary constraints will lead to an extension of that life within the organization. More often than not, the “if it ain't broke don't fix it” principle applies to these assets and organizations find themselves managing severely outdated devices. Especially in this situation, it is important to keep up with software and hardware maintenance contracts for as long as possible. It will come a time in which maintenance costs will outweigh the cost of a new device. That is the clear point to alert management and retire the existing, old device for a new one.

Retiring stage

Retiring is the stage when an asset that is no longer contributing to the mission of the organization is removed from use. “Retirement” does not always happen because something is obsolete. A common reason for retirement is when it becomes cheaper to remove an asset than to continue using it. Another possibility is the utilization of a newer, better asset, with improved features.

The primary concerns in the retiring stage are protection of the organization's intellectual property and performance of fiduciary duties. Retired equipment will typically contain data and some of it can be restricted. It is important to ensure that such data cannot be recovered from the retired equipment. For example, the desktop deployed in a college will reach a point where it can no longer provide the minimum level of service the dean and the students consider “adequate.” This desktop will then need to be retired. Over the course of its deployment, users are likely to have recorded student data, credit card, and other sensitive data on the machine. As part of its retirement, all such data should be wiped clean.

In later chapters, we will discuss the disposal of equipment. Donation is always an option. Make sure the disk is wiped clean before donating any equipment. If your company has a contract with another company for disposal of the material, make sure there is a privacy clause on the contract and assurances that devices containing data will be appropriately destroyed, and not simply repurposed or thrown on a landfill.

Take the example discussed in Chapter 2. Sunshine University was planning to replace its existing student email system with a brand new, cloud-based system that offered stability, redundancy, and new features to the user community, while at the same time allowing Sunshine to repurpose its personnel assets into other new ways to support its mission. Later we will also be discussing the potential impact of continued use of EOL equipment within the university and analyzing the risks versus the benefits of such support.

System profiling

In the previous examples we looked at assets in isolation: a laptop, a server, and a specific data set. This was done for simplicity during the introduction to the topic. However, when evaluating criticality and sensitivity in practice, it is necessary to look at assets in the context of the systems within which they are used. An asset that may be considered “essential” in isolation may be classified as “required” in practice if the organization has invested adequately in redundancy. Similarly, an asset that may be considered “deferrable” in isolation may actually be “essential” when viewed within the context of the system (the license for the scheduling system in an airline for example). Or, a collection of individual assets that by themselves may be considered “deferrable” could come together to form a system that is “critical.” This section provides a brief introduction to system profiling.

System profiling is a bit more complex than a simple inventory of computers. Identifying all the components of a system and the dependencies between them may be as much an art as a science. System profiling is the act of putting together all the assets inventoried, grouping them by function, and understanding the dependencies between these assets. It is creating a big picture view of a particular system or process.

According to the National Institute of Standards and Technology guidelines for IT risk management, NIST SP800-30 – Risk Management Guide for IT Systems,¹⁶ while performing system profiling, organizations will provide the hardware, software, system interfaces, data, personnel, and the mission of the system. As a result, the system boundaries will be clearly defined, together with function, criticality, and sensitivity.

Think again about your university environment, and some of the IT systems the university has in place in order to run the academic and the business sides of the learning environment. One core system is the Student Information System (SIS), shown at a high level in Figure 5.4.

Student Information System

The SIS does what the name implies: it stores student information such as financial aid, grades, address, social security number, advising data, and class schedule. It is a vital part of the operations of a university. Figure 5.4 gives us a sample of what a SIS system normally looks like. Students view their information using a web browser interface. Advisors, professors, and other administrators have a deeper view of the data, often using a desktop interface.

Following SP800-30, we can characterize the system in the following manner.

Hardware

Redundant student web servers handle the student interface. Each server on its own is a deferrable asset: they can fail and all the end user would see is a performance hit, a slight delay in loading the pages. Together, however, they become required: if somehow they lose their connection with the Internet, students may not be able to access them. During registration periods, they become essential: if they all somehow lose their network connection, no one is able to register.

Similar analysis can be made on all elements of the system, even separating them into subsystems with differing levels of criticality and sensitivity.

Software

SIS is usually one of those systems too complex to be developed in-house. There are both commercial and open source systems available, such as Ellucian's Banner and OpenSIS. The application has many complex pieces and often includes a database backend where all the information is stored. The student interface is usually web based, but the faculty/staff interface could also have a dedicated client. Typically, all software and the associated licenses will be considered essential assets.

Data

What type of data will be stored in the SIS? A couple of them stand out and must be treated as restricted data: grades and social security numbers. Grades are non-directory information protected by FERPA, as seen previously in this chapter. SSNs are also protected by FERPA in addition to other State and Federal regulations, together with other Personal Identifiable Information (PII). As a whole, due to the type of data it contains, SIS systems are classified as restricted.

System interfaces

The interfaces specify how data is entered and extracted from the system. Consider the following inputs:

• Admissions: how is the student admitted to the university?
• Applicants: is there a separate interface used for applicants?
• Financial aid: is there any reporting requirement on financial aid? Tax considerations?
• Scholarships: how are scholarships awarded and reported.
• Compliance: are there requirements for reporting on the number of students, average GPA, or any other type of information to the Department of Education?
• Grades: how are grades entered? Manually? Automatically from the Leaning Management System?
• Classes: how is add/drop communicated to the LMS so that it has up-to-date information on who is enrolled and authorized to access which class?

All of these interfaces contain data that is exchanged between the SIS and another system. If the data is considered restricted, then this exchange, or at least the restricted data, should be encrypted. Credentials for accessing the system must be protected, especially those with privileged access.

In this manner, the goal of system profiling is to describe the system with all of its dependencies so that we can make decisions on what to modify (user access through unsecure means, for instance), determine single points of failure, and other concerns.

Asset ownership and operational responsibilities

Recall from the beginning of this chapter that the goal of asset identification and classification is to proactively gather all necessary information about an organization's assets that can be useful in responding to a threat affecting that asset. So far, we have gathered all the technical information necessary for this purpose – what are the assets (asset identification), and how important are these assets (asset characterization). But we have missed an important element of responding to threats facing an asset – who should respond to a specific threat facing an asset?

For this reason, as part of the characterization of an asset, it is essential to also determine individual responsibility for the asset. In your home network, this is simple – you are responsible for everything within your home and your ISP is responsible for anything happening with your connection to the ISP. In enterprise networks, however, this is more complex. There are two specific problems you are likely to encounter. The first is that different people or units are likely to be responsible for different functions related to an asset. The second is that in spite of your best attempts, you are not likely to be able to anticipate everything that can go wrong with an asset.

Operational responsibilities are the responsibility of an individual or entity for a specific function related to the use of an asset. Operational responsibilities clarify the roles of organizational members for all well-defined functions related to an asset. The owner of the asset is the individual or unit with operational responsibility for all unanticipated functions involved in securing an asset.

You may notice that the above definition of the owner of an asset makes no reference to the entity that pays for the purchase of the asset. This is because while budgetary contributions and asset ownership may sometimes be shared, they can also be separated. This may be clarified from the example below.

It should be clear from the example that while the department paid for the asset, the professor had operational responsibility for all anticipated aspects of the asset – including functions such as software installation, software updates, data backups, and user account management. It should also be clear from the example that the FBI subpoena was a completely unexpected scenario, which was eventually handled by USF IT. As a matter of fact, in this example, the university's IT department was involved in the lab for the first time only when the subpoena was received. Who would you consider to be the owner of the asset – the academic department, the professor, or university IT?

Because the operation of IT assets requires specialized skills, IT organizations are often responsible for all residual functions related to IT assets. However, since most IT assets are purchased by business units from their own budgets, IT is often not considered to be the owners of the asset. A security analyst needs to be aware of this dynamic and its consequences because the owners of the asset are those responsible for coordinating their efforts in order to ensure the security of an asset. A clear understanding of this aspect of asset characterization can be helpful in planning responses to threats on assets.

As another example, let's look at a particular type of information asset common to Universities – “institutional data.” The University of South Florida defines institutional data as:

Institutional data is defined as all data elements created, maintained, received, or transmitted as a result of business, educational, or research activities of a USF System unit and may include one or more of the following characteristics:

It is easy to see that this kind of data can be distributed across the university, with a diverse set of owners. It is important to establish clear lines of responsibilities around users handling this type of data. This is where information asset ownership and information asset operational responsibilities come into play.

While the actual data ownership is held by the university, someone must be able to make decisions regarding the use of the data. That being the case, the university delegates the authority and ultimate responsibility for the security of the institutional data to specific individuals within the organization. These individuals are knows as the information asset owners.

Users who have operational responsibilities for maintaining data security but do not own the data are called data custodians. An example of a data custodian is a student advisor in an academic department who has access to student transcripts to help students register for the most suitable courses in order to graduate on time. The advisor has the fiduciary responsibility to maintain the confidentiality of such data but is not the owner of the data.

With this background, we can update our asset characterization table to include ownership and responsibilities as given in Table 5.4.

Example case–Stuxnet

The nuclear enrichment facility at Natanz is one of Iran's most critical and sensitive assets. Approximately 5,000 centrifuges work to enrich uranium to weapons grade so the country can develop a nuclear bomb on its own. Alongside these centrifuges are computers used to monitor and control these centrifuges.

Many countries, including the United States, are concerned about Iran's program. After considering all available options, these countries identified the computers controlling the centrifuges as the best assets to leverage to slow down Iran's progress. The result was a sophisticated computer worm, widely known as “Stuxnet.” At the peak of its effectiveness, Stuxnet is reported to have taken out 1,000 of the 5,000 centrifuges operating at Natanz, setting back Iran by an estimated 18 months.

Stuxnet was designed to spread from one target machine to another automatically, do its job, and destroy itself, leaving no trace behind. However, the targeted computers were heavily guarded. For added protection, they were not physically connected to the Internet, meaning no Internet-based attack could reach the facility. From the perspective of the attackers, however, the people working at the facility were very useful assets. If one person could be persuaded to carry an infected USB thumb drive to the facility, the worm could begin doing its job. We can only presume that this is exactly what happened.

Stuxnet is now considered the world's first “weaponized” computer worm.