One of the best ways to determine what threats exist is to analyze past incidents. These incidents include those at the organization, at similar organizations, and in the local area:

• Organization—A review of past incidents will reveal threats that have resulted in losses.
• Similar organizations—Incidents with other organizations in the same business will reveal possible threats to the organization.
• Local area—Natural and weather events are likely to occur again in the same area.

This data can be gathered by compiling records and conducting interviews. Data can be compiled from any existing records, including security records; insurance claims; and troubleshooting records, to determine outages and their causes. Interviews can be conducted with management and other employees. Management knows the particular threats that have resulted in significant losses, and employees often know exactly what the problems are and where the threats exist.

An Organization’s Historical Data. An organization’s historical data can be reviewed to identify past incidents from threats. Past incidents can take many forms, such as those resulting from users accidentally or maliciously causing problems or those coming from external attackers or natural events.

Following are examples of past incidents from threats:

• Internal users—Users were granted access to data they didn’t need, or they stumbled upon it and shared it with coworkers, which resulted in unauthorized disclosure of confidential data.
• Disgruntled employee—An employee was terminated for cause on Monday, and his account was not disabled or deleted. The employee accessed his account on Wednesday, and he deleted a significant amount of data. Some of the deleted data had not been backed up and was lost permanently.
• Equipment failure—A server crashed after a power spike and remained down for several hours until the power supply was replaced.
• Software failure—An ordering database application crashed on a database server, and the server had to be rebuilt from scratch. Administrators reinstalled the operating system and then reinstalled the database application. They then restored the data from backups. This process took over 10 hours, and customers could not place online orders during this time.
• Data loss—All users are required to store their data on a central file server, and the data is backed up once a week on Sunday. The file server crashed on Wednesday, and many users lost over two days of work.
• Attacks—An email server became infected with a virus, which spread to all the email users’ mailboxes. Cleaning the system and returning email services to users took approximately two days to complete.

Each of these examples shows only the threat, but various controls could have been implemented to have prevented the threat. For example, if users had access to data they didn’t need, the principles of least privilege and need to know could have been implemented. However, the goal at this stage is only to identify the threats.

Similar Organizations’ Historical Data. Many threats are common to similar organizations. By identifying the threats against similar organizations, possible threats against a specific organization can be identified. For example, attackers like to attack law enforcement websites. Years ago, many instances occurred of such websites being defaced. However, most law enforcement agencies recognize the threat today, and they take additional steps to protect their websites.

Any organization with public-facing servers faces similar threats. Apache is a popular web server product that can be run on UNIX, Linux, and Microsoft platforms. It serves webpages over the Internet. Any company that hosts Apache faces the same threats as companies with public-facing servers.

Local Area Data. Primary considerations for the local area are weather conditions and natural disasters. If a location is on the coast and the coast has had hurricanes in the past, it will likely have hurricanes in the future. If a location is in a flood zone, it will likely flood in the future.

Anyone who has lived in the area knows what the natural threats are. Someone new to the area can interview employees or other locals and should get more than one perspective because one person’s disaster may be another person’s minor inconvenience. Steps should not be taken to resolve problems based on anecdotal evidence alone.

For example, local employees may live in a flood zone. They may relay horrific stories of how flood waters flowed into their homes and destroyed everything on the first floor. While this event was horrific for them, its happening previously doesn’t mean your organization will flood in the future. This information should be balanced against other sources, such as flood zone maps, which show exactly the areas that are likely to flood. If the organization is on high ground and not in a flood zone, steps do not need to be taken to protect it from a flood.

Threat modeling is more complex than just researching historical data for threats. It is a process used to assess and document an application’s or a system’s security risks.

Ideally, threat modeling is performed before an application is written or a system is deployed. It is done when security is considered throughout the full life cycle of a product or service. In other words, if security is considered only at the end of the project, it frequently falls short.

When threat modeling is used, the assets to be evaluated first need to be identified. Asset management helps in identifying the assets that are important to an organization, including their value. Steps can then be taken to identify the threats against the valuable assets.

A key part of threat modeling is to think like an adversary, instead of a manager or an administrator. In this context, the adversary can be an external attacker or an internal user. The internal user doesn’t have to be malicious to be a threat. However, if the internal user has the potential to accidentally cause harm, the result is the same.

An excellent starting point when performing threat modeling is to use the seven domains of a typical IT infrastructure. The seven domains are presented later in this section with best practices.

When performing threat modeling, here are some of the key questions that should be asked:

• What system needs to be protected?
• Is the system susceptible to attacks?
• Who are the potential adversaries?
• How might a potential adversary attack?
• Is the system susceptible to hardware or software failure?
• Who are the users?
• How might an internal user misuse the system?

Threat modeling for complex systems can become quite extensive. Depending on the system being evaluated, specific objectives may need to be defined to limit the scope of the evaluation.

When performing threat assessments, understanding the system or application being evaluated is important. This understanding includes what systems are involved and how data flows into and out of the systems. Without a full understanding of a system, shifting the perspective to being an attacker is difficult. Understanding a system often requires interviewing the experts and reviewing the documentation on the system.

Law enforcement personnel, including local law enforcement, FBI, CIA, and Secret Service, commonly use threat assessments. For example, every time the local police answer calls to crime scenes, they quickly evaluate the situation. For example, a wife calls to complain that her husband is abusing her. The police know that this can be a violent and explosive scene because the husband could have a weapon or the wife could turn on the police when she realizes her husband is being arrested.

Similarly, every time the president of the United States travels somewhere, Secret Service teams go there first and perform threat assessments. The teams evaluate every path the president will take and look for potential threats. They visit the ultimate destinations and evaluate them. They consider the possibility of snipers and bombs, evaluate employees with a focus on new employees, and investigate any tips.