Risk Analysis

One of the first and most essential things to do is to conduct an analysis of the security landscape and think about the security universe at it pertains to your organization. For each application you have to determine how it can be exploited, what would happen if something were to happen, and how to mitigate such occurrences. The term “application” in the previous sentence is meant to apply to all facets of applications—not only the user interface but also the servers and databases. This is often referred to as risk analysis, and it must be done. It can be very tedious, but it’s a necessary and valuable exercise.

In a simplified view of risk analysis, the first step is to determine the assets being protected and their associated value. The value can be determined either qualitatively or quantitatively. Referring back to the car example, your car has both a quantitative value and a qualitative value. Its quantitative value can be defined by a monetary amount. Its qualitative value may be in its reliability and possibly any nostalgic memories associated with places the car has taken you. Companies, company assets such as computer servers, and even data have similar values. Sometimes a concrete value can be determined quantitatively. For example, the company lost $6,000 due to the theft of a computer server. Qualitative values can be more difficult to calculate. For example, if the stolen server contained a database, there would also be a loss associated with the data that was stored within that database. A security breach that was made public could damage a company’s reputation.

The next step is to consider all possible threats to the assets. These threats aren’t just external or from outsiders, they also include insiders who may be privileged and authorized to access parts of or all of the application. Threats also include nonhuman or natural causes such as fire, floods, earthquakes, power loss, tornadoes, and so on.

The last step it to predict a rate of occurrence, or the overall likelihood that the threats will happen. Because there can be an infinite number of threats, it’s important to focus on the threats that have higher probability of happening. Power loss has a higher rate of occurrence than does a tornado or earthquake, so ensuring your site has backup power may be a higher priority than building a tornado- or earthquake-proof structure.

Returning to the car example, assume your car cost $10,000. If you live, work, and drive in a safe part of town, you may conclude that the likelihood of car theft is very small. Buying and installing an alarm system that costs $30,000 may be unreasonable. However, if the rate of occurrence of auto theft is sufficiently high, then the extra expense and inconvenience of the alarm system is well worth it.

For your IT assets, the threats also can be external and internal. Firewalls may be used to address the external threat, but the internal threat will still exist.

The risk analysis process has to evolve over time. You have to remain vigilant about your security. Your security posture should always reflect the new insights and perspectives you have about your data, applications, users, operating systems, and policies.

Risk analysis is important and valuable. The lists of assets, their value, and the threats associated with those assets helps to guide and influence prudent security decisions.

Document Your Risk Analysis

The results of the risk analysis should be documented. The documentation should explain the decisions that were made and why they were made and list all the identified threats and vulnerabilities.

The benefits to documentation are many. First, the results of the analysis can be used as a reference or checklist for audits. The documentation can also serve as a template for other, future systems. The risk analysis results may also be useful in proving due diligence in the event that something bad happens. It’s not unreasonable to assume a civil suit may occur as the result of what appears to be negligence on your organization’s behalf. The documented analysis should help to prove that security was taken seriously and that the occurrence was an anomaly and not the result of gross negligence.

Expect the Unexpected

Many successful system attacks are executed by unconventional means. Make sure to consider the unexpected when you are gathering information for your risk analysis. What you expect to happen to your system may not actually be what’s going to happen to your system. For example, for better home security, you might install a new steel-reinforced front door with an industrial-strength dead bolt. It is unwise to assume a burglar can only gain entry to your house through the front door just because that’s the way people normally enter and leave the house. An unlocked ground floor window can provide an easy alternative and unsecured entry path for a burglar. Similarly, you should assume that hackers and attackers can get to your data in ways other than through the normal access paths that you use. Consider the following two examples.

You may believe the only way to access your database data is via an application since that’s the way your users access the database. A great amount of effort may then be focused on securing the application; however, the assumption that all access to the data is by way of application is wrong. There are many ways to connect to the database, and your application only represents one of them. There may be nothing preventing a user from bypassing the application and all the application’s security by connecting directly to the database. Applying security in the database, like locking the ground floor windows, is a good solution for this.

Assume you have now secured your database and your application(s). There is still a risk. The unexpected attack now shifts to the possible theft of the database’s backup tapes. Theft of the backup tapes can be easy if the tapes are left on someone’s desk in an unprotected area, or worse, left in a box in the mail room.

This last threat leads to another point. There are a lot of known technology-based attacks: network eavesdropping, IP spoofing, password cracking, and so on. However, there are many more unconventional methods that are just as effective, if not more so. For example, a social engineering technique would be to impersonate someone from the help desk. The attacker simply asks for a user’s password to fix a problem or asks the user to set their password to “admin” to allow them in. Proper education for your user community is helpful in thwarting these attacks. But note that many methods are not technological in nature, so using technology as a solution may prove ineffective.

Expecting the unexpected means that you anticipate the use of unconventional tactics. You must assume that there is no single way to do anything. People are creative, ingenious, and curious, and they’ll prove this to you by testing your designs and implementations.

Contingency Planning and Incident Response

With all the risks properly identified, the next step is to decide how to properly respond when incidents occur. This is called contingency planning and incident response, and I can’t stress enough how important this is. For example, you know what to do in the event of a fire: get out of the building as fast and safely as you can. Leave your valuables in the building to burn. This has probably been drilled into you since elementary school, if not before that. But what do you do about your databases in the case of a fire? Yes, you leave those to burn too, but once the fire is out, then what?

Contingency planning outlines what you will do in the event that fire destroys the computer room. It also states what to do if you are under cyber attack. These guidelines are essential because they may be the only pillar of stability in a time of crisis. For example, in case of a data center outage, you need to direct your applications to a failover site, which may simply require an update to the internal domain name servers (DNS). In the case of cyber attack, you need to disconnect the servers from the network, alert the response team, and make sure you do not reboot the servers. Rebooting can delete potential evidence or clues about how the attack occurred and whether anything was compromised.

For the same reasons you conduct fire drills, it’s important to rehearse your incident responses, too. People tend to not think clearly when overwhelmed by anxiety. Having a plan gives you a sane reference point in the midst of insanity. Don’t forget to keep the plans in a safe place so that they are also not destroyed in the fire!