Case studies are an invaluable tool when performing a risk assessment. Rather than trying to re-invent the wheel, you can use case studies to learn how others assessed risk in similar situations to yours. In this section, you will see how risk assessments are performed in real-world situations.
No access control system is 100% secure. A determined attacker, with plenty of resources and time, can break into just about any system. The key is to deter the casual attacker and to make your organization a hard enough target to encourage even dedicated attackers to look elsewhere. This way, only an attacker with a specific interest in your organization will continue the attack.
In private industry, risk is understood in terms of profit and loss, and business continuity. How would a security breach affect the ability of the business to continue to run? What would it cost the company in lost revenue?
Let’s look at the example of Acme Pharma, a large pharmaceutical company in the United States. Acme Pharma needed to update their network security infrastructure to bring them into compliance with new federal regulations. The first step was to identify what needed updating and the risks they were intending to mitigate. The existing system consisted of a border firewall with a demilitarized zone (DMZ) for web servers. There was email antivirus and antispam software and some access controls implemented on the internal network.
The first step in the update was assessing what the risks to the environment were, and what the highest-risk systems were. Their IT department determined that some of the highest-risk systems did not need to be on the corporate Intranet and were segmented off into their own protected LAN. From there, extra layers of security were implemented in case of border network breaches. Network-based intrusion detection systems (IDSs) and intrusion prevention systems (IPSs) were implemented to detect and block suspicious network traffic.
On web-facing systems, automated patching was implemented, as well as host-based firewalls and host-based intrusion prevention systems. It was also determined that the servers themselves exposed too much information. Each website hosted on the server was given its own users, with rights limited to the directories that the website needed to have access to.
The risk assessment showed that certain websites were actively targeted for attacks. These systems were segmented away from the rest of the DMZ and further protected with pass-through proxies and application-level firewalls. It was then determined that security needed to be an ongoing priority. To achieve this goal, a new monitoring team was formed. Log shipping (automatic backup of transaction logs) was implemented and automated monitors were created. Procedures for manual monitoring were also created, and there was active human monitoring of the network done to augment the automated monitors.
Finally, they performed a full audit of user rights and file access controls. Any user with enhanced rights was closely examined to determine the need for those rights. New user groups were formed based on the different roles in the company, and document access was regulated by these groups. Users with a need for heightened rights, such as systems administrators, were not automatically granted rights to all files—they also had to be a member of the appropriate role group.
A new file team was created to handle the roles and access rights. They were tasked with reorganizing electronic document storage. To verify user right levels and create forms to request elevated rights, they established who in each department could authorize access requests and established a policy for adding and revoking rights.
Through honest and accurate risk assessment, Acme Pharma was able to secure their infrastructure and move from a border-only security system to a defense-in-depth environment. The most valuable systems were determined to be too important and removed from the Intranet, removing any possibility of outside intrusion. They also established an access control policy to handle information access inside the organization.
In the public sector, threats are sometimes literally about life and death. Consider the U.S. Department of Defense. If an unauthorized user accesses sensitive battle plans, soldiers’ lives could be at risk. Of course, the public sector encompasses far more than just the military. The U.S. Department of Energy is a very high-profile target—especially the various research labs they maintain around the country.
Consider the Pacific Northwest National Laboratory (PNNL). PNNL is a U.S. Department of Energy Office of Science National Laboratory. It works on solving problems in energy, the environment, and national security. It has over 4,000 employees conducting research that translates into practical solutions to some of the most vital challenges facing the United States. This makes PNNL a very tempting target.
According to Jerry Johnson, CIO of PNNL, 10% of their connection requests are attacks. That translates to around 3 million attacks a day. They also receive over 1 million spam messages a day—around 97% of all email sent to the laboratory.
These intrusion attempts come from a wide range of attackers, including organized crime and foreign governments, as well as skilled individuals. Motives for these attacks include economic, national security, and the challenge of breaking into a government facility. The targets of the attack include intellectual property, other proprietary data, and valuable employee information such as Social Security numbers.
To add further complexity to the problem, the lab needs the ability to share data and computer resources with authorized scientists around the world. Security is important, but collaboration is vital. The attackers are also evolving and becoming more sophisticated. Given time, they could defeat any one security mechanism put in place.
To handle this difficult situation, PNNL has implemented a seven-layer defense-in-depth strategy. Each layer is intended to stop any attacks that defeated the layer above it:
If malware gets onto a workstation through an unknown attack vector, the host-based firewall keeps it from spreading to the Intranet.
PNNL requires two-factor authentication for any remote access to the PNNL network. PNNL utilizes a token system that requires a user to know a PIN and have the token. This is a little inconvenient to the users but adds very strong protection against session attacks and keystroke loggers.
No network is 100% secure, but by using a defense-in-depth strategy, PNNL can reliably secure their sensitive infrastructure. This strategy allows them to further secure data and facilities that are at the highest risk.
In some cases, the biggest factor in a risk assessment does not directly affect profit and loss or even injury to patrons, but damage to critical infrastructure. That infrastructure can include loss of IT resources such as a network or Intranet site, or it can refer to physical infrastructure like the controllers for a hospital’s emergency power generators. In these cases, risk assessment should be focused on the loss of productivity or the ability of an organization to fulfill its core mission, rather than on loss of revenue. Let’s look at a case where a failure to assess the risks to the system led to lax access controls with unfortunate consequences.
The incident happened at a local water treatment facility in Maroochy Shire, Queensland, Australia. A large amount of sewage was released into parks, rivers, and the grounds of a hotel by a former contractor who worked for the facility, causing major environmental and economic damage. While he was eventually caught, the damage was already done.
The attacker had several advantages because he was familiar with the system and had a copy of the software needed to communicate with the controllers. However, several vulnerabilities contributed to the incident. The system used inadequately protected wireless communication, giving the attacker an easy vector to compromise the system. The administrators at the treatment facility also failed to have a proper access control policy in place. As it turned out, the contractor still had full security rights to the system even after he was terminated. A proper access control policy would incorporate procedures for quickly removing accounts that should no longer have rights, thereby preventing or complicating an attack.
The administrators of the system also never considered the threat of an inside attack. They assumed that the proprietary nature of the controlling software and complexity of systems would keep the systems secure. An access control policy that included provisions for removing access when necessary would have greatly reduced the possibility for this attack. Had the risks to this system been accurately assessed, the access control policy would have been expanded and an effective wireless security system could have been implemented.