9.5 Security and Privacy Administration

9.5 Security and Privacy Administration

The preparation and ongoing administration of security and privacy in the network are important to the overall success of the security architecture. As with the requirements and flow analyses, understanding what your threats are and how you are going to protect against them is an important first step in developing security for your network. In this section, we will discuss two important components in preparing for security: threat analysis and policies and procedures.

9.5.1 Threat Analysis

A threat analysis is a process used to determine which components of the system need to be protected and the types of security risks (threats) they should be protected from (Figure 9.1). This information can be used to determine strategic locations in the network architecture and design where security can reasonably and effectively be implemented.

Figure 9.1: Potential assets and threats to be analyzed.

A threat analysis typically consists of identifying the assets to be protected and identifying and evaluating possible threats. Assets may include but are not restricted to the following:

• User hardware (workstations/PCs)

• Servers

• Specialized devices

• Network devices (hubs, switches, routers, and operations, administration, maintenance, and provisioning [OAM&P])

• Software (operating system, utilities, and client programs)

• Services (applications, IP services)

• Data (local/remote, stored, archived, databases, and data in transit)

And threats may include but are not restricted to the following:

• Unauthorized access to data, services, software, and/or hardware

• Unauthorized disclosure of information

• Denial of service

• Theft of data, services, software, and/or hardware

• Corruption of data, services, software, and/or hardware

• Viruses, worms, Trojan horses

• Physical damage

A method to gather data about security and privacy for your environment is to put a list of threats and assets together in a worksheet. This threat analysis worksheet can then be distributed to users, administration, and management, even as part of the requirements analysis process, to gather information about potential security problems.

An example of such a worksheet is presented in Figure 9.2. The results shown in this worksheet were determined during the requirements analysis process and are specific to a particular organization. Depending on the organization, the results of a threat analysis can be quite different than those shown in Figure 9.2. For example, a threat analysis can consist of the information and assets that need to be protected, in terms of confidentiality, integrity, and availability. This analysis can be combined with lists of threats that are currently out there, as well as potential vulnerabilities.

Effect/Likelihood	User Hardware	Servers	Network Devices	Software	Services	Data
Unauthorized Access	B/A	B/B	C/B	A/B	B/C	A/B
Unauthorized Disclosure	B/C	B/B	C/C	A/B	B/C	A/B
Denial of Service	B/B	B/B	B/B	B/B	B/B	D/D
Theft	A/D	B/D	B/D	A/B	C/C	A/B
Corruption	A/C	B/C	C/C	A/B	D/D	A/B
Viruses/Worms	B/B	B/B	B/B	B/B	B/C	D/D
Physical Damage	A/D	B/C	C/C	D/D	D/D	D/D
	Effect:			Likelihood:
	A: Destructive	C: Disruptive		A: Certain	C: Unlikely
	B: Disabling	D: No Impact		B: Likely	D: Impossible

Figure 9.2: Example of threat analysis worksheet for a specific organization.

Threat analyses are by their nature subjective. One way to minimize the degree of subjectivity is to involve representatives from various groups of the organization to participate in the analysis process. This will provide many perspectives in the analysis. It is also recommended that you perform a threat analysis periodically, say, annually, to identify changes in your environment. As an organization grows and changes, and as the outside world changes, the degrees and types of threats to that organization will also change. A periodic threat analysis will ensure that new threats are included and can show where new security mechanisms may be applied to the network. Along with this, a periodic review of security policies and procedures is also recommended. Subsequent reviews may highlight previously overlooked areas in the network, system, and environment.

9.5.2 Policies and Procedures

There are many trade-offs in security and privacy (as with all other architectural components), and it can be a double-edged sword. Sometimes security is confused with control over users and their actions. This confusion occurs when rules, regulations, and security guardians are placed above the goals and work that the organization is trying to accomplish. The road toward implementing security starts with an awareness and understanding of the possible security weaknesses in the network, and then leads to the removal of these weaknesses. Weaknesses are sometimes in the areas of system and application software, the ways that security mechanisms are implemented, and how users do their work. This last area is where educating users can be most beneficial.

Security policies and procedures are formal statements on rules for system, network, and information access and use to minimize exposure to security threats. They define and document how the system can be used with minimal security risk. Importantly, they can also clarify to users what the security threats are, what can be done to reduce such risks, and the consequences of not helping to reduce them.

At a high level, security policies and procedures can present an organization's overall security philosophy. Examples of common high-level security philosophies are to deny specifics and accept everything else or to accept specifics and deny everything else, as in Figure 9.3.

Figure 9.3: Example security philosophies.

In Figure 9.3, the term specific refers to well-defined rules about to whom, what, and where security is applied. For example, it may be a list of specific routes that can be accepted into this network or users who are permitted access to certain resources.

"Deny specifics and accept all else" is an open network philosophy, requiring a thorough understanding of potential security threats, as these should be the specifics to be denied. It can be difficult to verify the security implementation for this philosophy as it is hard to define "all else."

On the other hand, "accept specifics and deny all else" is a closed network philosophy, requiring a thorough understanding of user, application, device, and network requirements, as these will become the specifics to be accepted. It is easier to validate this security implementation as there is a finite (relatively small) set of "accepted" uses. Of the two philosophies, "accept specifics and deny all else" is the common philosophy.

When you develop security policies and procedures, keep in mind that, to be useful, they should be straightforward to implement for your environment (keeping in mind who will be supporting them) and enforceable. They should also have clearly defined areas of responsibility.

Policies and procedures should include:

• Privacy statements (monitoring, logging, and access)

• Accountability statements (responsibilities and auditing)

• Authentication statements (password policies and remote access)

• Reporting violations (contact information and procedures)

Examples of security policies and procedures are acceptable use statements, security incident-handling procedures, configuration-modification policies, and network access control lists (ACLs). Each of these has a place in the security and privacy plan. These policies and procedures should describe not only how network resources can be accessed, used, and modified but also why to help users understand the policies that they are being asked to accept and work with. Incident-handling procedures can be particularly helpful in making users aware of what to do when a security problem arises, making them part of the security process and not just victims of it. The list of areas for policies and procedures shown here can be used as a starting point to apply to the security architecture:

User access to the system

• Authorization to use

• Authentication of identity and use of passwords

• Training and acceptance of responsibility for compliance

• Notices that corporate equipment is not private property

• Expectations of the right to privacy

Administrator skills and requirements for certification

• Superusers and administrators

System configuration and management

• Maintenance

• Virus/ Trojan protection

• Patching operating systems and applications

• Monitoring CERT advisories for notices of hacks

• Who can and cannot connect devices to the network

• Notice screens during log-in or startup

• What data get backed up

• What data get saved off-site

• Contingency computing plans

What to do when the system is attacked