Developing an IT Security Risk Analysis

Security professionals recognize that the more secure a system is, the less functional it is likely to be. Security features often get in the way of quickly getting a task done, and strict policies can often have the opposite detrimental effect of causing users to seek ways to bypass security.

Security is an ongoing process, not an end product. Just like your immune system, your security process can never rest completely. Although you may face periods when new attacks are of little threat, you can never relax completely because you cannot predict when the next assault will occur or when a user will accidentally open up a previously closed hole.

The security process consists of the following steps:

1.	Analyze your risks. Define how vulnerable your system is to attacks by assessing the threat level and the user's security skills.
2.	Assess risk versus cost. Security is a compromise between an acceptable level of security and its associated cost. More security translates into more cost and vice versa.
3.	Establish policies. Once you have gathered the necessary information in the previous two steps, write a security policy. This will be a balancing act. The most convenient access will often be the least secure. A large part of this effort will be defining the various levels of access that you want to allow and which users should be permitted into each level. Another large part of this effort will be user education. You'll have to develop a strategy for teaching users what they can do, what they can't do, and why certain things are not permitted. (Getting higher-level management backing on these issues is generally helpful.) Also important in the balance between security and convenience is your own convenience. You need to ensure that you are not making system administration so difficult that you are loathe to undertake the necessary tasks.
4.	Implement solutions. Once policies are in place, the next step is to implement them. Set up the servers, firewalls, and user accounts. Get the users on your network using the servers.
5.	Monitor the network. Security is an ongoing process. You must monitor your network constantly to ensure that your policies are effective and that someone hasn't inadvertently (or even deliberately) breached your security.
6.	Formulate a response. You must develop a plan of action in advance for responding to a breach of security, a lack of conformance to policies and guidelines, or a change in user needs (for example, your company grows from 15 users to 200). You might have to repeat the entire cycle or make implementation changes and go back to monitoring.

The full cycle doesn't need to be completed each time you have a problem, but you should evaluate the full security picture with the full cycle in mind.

Assessing Threat Level

The first step in the problem space of the security process is to define vulnerabilities. To do so, you must assess threat level and user skills, which help determine the security needs of your organization.

The threat that has been popularized by mainstream media is that of an outside attacker accessing private information using a network connection. This is perhaps the least of the threats facing you in terms of security from the client side.

A more insidious attack is what is known as social engineering, which relies on people giving out information that they shouldn't. Someone may call a user claiming to be from the help desk in your organization and saying that they need to reset passwords on a system.

A more mundane attack is simple physical theft. In addition to the loss of equipment, you and your users face significant downtime while you replace equipment and figure out how to replace lost data. Even worse is a case where confidential data falls into the hands of your competitors.

An attacker may take advantage of multiple avenues. For instance, an attacker may use social engineering to discover a password, then steal a portable computer or security token to gain access to information.

Other forms of attack are viruses and Trojan horses. These pieces of code are the subtlest of the threats, infecting mail, hard drives, and networks. The effect of these attacks can range from inconvenient to devastating.

Perhaps the most dangerous and common threat comes from insiders who already have access to your information. Keeping this threat under control is beyond the scope of this book, but the key to lessening it is careful use of permissions.

Also when assessing threat level, try to assess how determined an attacker might be. For example, if you have a high-profile website that provides access to classified information that is sought by adversaries, it is highly likely that an attacker will try every possible way to get to the information, resulting in a high threat level.

Defining User Skills and Needs

Assess who needs to use a particular resource. What will users do to circumvent the security if it is too inconvenient? Examples of other issues to consider are that users may:

• Not use the service at all, which wastes money and time

• Not log out of the system, so password policy may be moot

• Leave passwords out in plain view

• Copy files to insecure areas

As mentioned, security is a compromise between how much risk you're willing to take and how much expense you're willing to incur. To assess risk versus cost, you must:

• Consider examples of compromise based on your experience.

• Assess user needs to help you determine how many of them you should address to maintain an appropriate level of security and the associated cost. Following are some examples:

  • Users access the network from outside the firewall using VPN.

  • Users can take their computers, which might contain sensitive information, with them wherever they go.

  • Users can share computers with other users.

• Assess organizational needs. Like user needs, an organization's computing and security needs help you determine where to draw the line between risk and cost. Following are some examples of organizational needs that affect the balance between security and cost:

  • Back up computers daily.

  • Monitor logs daily.

  • Check computers for viruses on a regular basis.

• Perform regular security audits to evaluate the current state of security in your organization and determine how best to improve it.

Establishing Policies

When establishing policies, your challenge is to balance convenient user access to services with organizational security needs. An absolutely secure computer is one that is turned off, unplugged, and locked in a bank vault, but it is not very convenient. A computer placed in a public library with no individual user accounts is convenient for whomever comes into the library, but it is not very secure.

Providing a service always opens a potential breach in security. Think of a computer as a blank wallevery service is an additional gate through the wall. Even if the gate is well protected, it's still not as strong as a solid section of the wall.

Depending on the level of threat that your installation faces and the sophistication of your users, you will need to create a security policy that can keep your systems safe while still allowing for sufficient access.

Remember that convenience also includes the ease of system administration tasks. If you make system administration procedures too burdensome, someone will take a shortcut at some point that will potentially compromise security.

Keep in mind the phrase "obscurity is not security." You cannot and should not rely solely on keeping the configuration of your computer systems secret. Apart from the fact that there are many techniques available to probe your systems, some of the greatest threats to security come from colleagues who must know your systems because of job function and responsibility.

Documenting Policies

One of the most important things you can do is write down your security policy. This creates clear expectations for users, system administrators, and management. The policy should be written plainly, avoiding jargon. Following are some examples of the information it should contain:

• Allowable uses

• Resource access policy and limits

• Monitoring policy

• Anticipated threats and relative risks

• Implemented defenses against anticipated threats

• Best practices

• Escalation procedures

• Checklist for follow-up audit after an exploit

In addition, you should document threats that you have examined but consider of such low probability that they are not worth defending against, threats that are too costly to defend against, or threats that are possible but require the cooperation of other agencies, such as your Internet service provider, to develop a proper defense.

Writing down this information serves two very important purposes:

• You are forced to be clear and consistent with your thinking about security.

• Your written policy is an invaluable tool when it comes to the hardest part of securityeducating your users.

Implementing Solutions: Creating a Secure System

Once you have defined policies, you move from the problem space to the solution space. This is where you implement policies through system architecture and design:

• Configure hardware: Set up hardware firewalls, servers, and computers to comply with the policies you have defined for your organization. This includes setting firmware passwords and physical security of equipment.

• Configure software: Server software, firewalls, and user accounts must be configured for security. The default configuration for Mac OS X leaves services off; an administrator must enable them. This means that at the beginning, there are no known holes in the Mac OS X security posture. Opening a hole requires an action by someone who should be knowledgeable about the operating system.

  In addition, unlike older versions of Mac OS, Mac OS X is a true UNIX-based multiuser system. This means that access privileges are always enforced and cannot be bypassed except by the root user. It also means that, unlike AppleShare IP, the access privileges are available at the file level as well as the folder level, which enables you to configure privileges to allow a finer degree of access control.

• Define processes: Users and administrators need processes to follow when using computing resources. For example, you can define a process that administrators follow to report and respond to a breach of security.

Monitoring the Network

After implementing the solutions, you need to monitor computers and network activity in your organization to detect any attempt or actual breach of security (inadvertent or deliberate).

Examples of monitoring include:

• Using Console or Terminal to monitor logs

• Using virus-detection software to check systems for viruses

• Using packet sniffers such as tcpdump and Ethereal to monitor network traffic

Formulating a Security-Breach Response

When monitoring computers and network activity, you might detect or be alerted to an actual or attempted breach of security. You need to formulate an action plan that will enable you to respond to the potential threat based on the processes that you have in place.

The work involved in the formulation of the response will vary with the nature of the alert. If the alert is minor, you may not need to adjust your policies, but rather tighten your implementation of the policies or solutions and enter the monitoring phase again. If the alert is major, your threat level may have increased enough to warrant redefining vulnerabilities and starting the security process again from the beginning. In all cases, the alert should be documented and a follow-up audit should take place as part of the monitoring process to ensure that the response succeeded in addressing the issue.

In reality, formulation can lead you back to any point in the security process, keeping the process flowing and dynamic. This is good, as security is an ongoing and ever-changing challenge. There will always be attackers pushing the security envelope. The key to keeping them at bay is keeping your security process active and flexible.