ActionScripting in Flash MX

5.2 Developing the security policy

One of the first documents many organizations create when tackling security is a security policy. This is basically a list of all activities you will permit on your network and the types of user or network processes allowed to perform them, together with a definition of security levels for various services and data. It is worth reflecting on the definition of security policy offered in [8]: A security policy is a formal statement of the rules by which people who are given access to an organization's technology and information assets must abide.

Given that there are known internal and external threats to your network, you must establish a clear policy for preventing and dealing with security breaches.

5.2.1 Policy components

A security policy should be designed in accordance with a risk assessment of vulnerable resources and what levels of availability or loss the organization can tolerate, with characteristics such as the following:

• It must be understandable and unambiguous. If the policy document is written in such a way as to cause misunderstanding or misinterpretation, then security may be compromised.

• It must be implementable through system administration procedures, publishing of acceptable use guidelines, or other appropriate methods.

• It must be enforceable with security tools, or sanctions where tools are not available or appropriate.

• It must clearly define the areas of responsibility for the users, administrators, and management.

• The more rigorous the security policy, the more expensive the solution, and the more impenetrable the network should be. In an ideal world you should aim to develop a policy document that includes information such as a vulnerability and risk analysis, a privacy policy, an accountability policy, and an authentication policy.

For further information on policy, the interested reader is directed to [8].

5.2.2 Risk analysis

Risk analysis produces a monetary vulnerability assessment, and these data can then be used in financial planning projects when attempting to justify expenditure on security; and it certainly helps to focus attention on critical vulnerabilities. If the annual projected losses exceed the cost of the security measures, then it should be easier to convince senior managers to allocate budgets accordingly.

5.2.3 Attack trees

One useful technique in exploring system vulnerabilities is to create an attack tree of the potential paths and choices a malicious user might take to exploit your system. Figure 5.3 illustrates a partial attack tree with some of the steps that might be considered by a malicious user in attempting to gain a copy of a sensitive client database from a corporate server.

Figure 5.3: Simplified and incomplete attack tree for getting a copy of a sensitive client database from a corporate server (progress is from top to bottom).

5.2.4 Policy implementation

When implementing policy, there are two basic approaches you can take when configuring software and devices; these form the overall guiding policy from which everything else is derived, as follows:

• Model A: Everything not specifically permitted is denied.

• Model B: Everything not specifically denied is permitted.

Anybody serious about security will choose Model A. Policies must be consistent throughout the network. All internetworking devices that relay user and service traffic must be examined to see if they can be included in the policy implementation. This may include routers, bridges, gateways, servers, firewalls, remote access devices, terminal servers, and hosts. Table 5.2 summarizes several major security implementations and demonstrates the various features that are present and absent in each. This table is a useful tool for putting things in perspective when implementing security policy.

5.2.5 Legal issues

Once your security policy has been established, the policy should be reviewed by legal counsel to ensure that it meets all legal requirements.