Thursday, August 4, 2022

Principle of Information Security Module 3 Information Security Management part 6

While issue-specific policies are formalized as written documents readily identifiable as policy, systems-specific security policies (SysSPs) sometimes have a different look. SysSPs often function as standards or procedures to be used when configuring or maintaining systems. For example, a SysSP might describe the configuration and operation of a network firewall. This document could include a statement of managerial intent; guidance to network engineers on the selection, configuration, and operation of firewalls; and an access control list that defines levels of access for each authorized user. SysSPs can be separated into two general groups, managerial guidance SysSPs and technical specifications SysSPs, or they can be combined into a single policy document that contains elements of both.

Managerial Guidance SysSPs

A managerial guidance SysSP document is created by management to guide the implementation and configuration of technology and to address the behavior of employees in ways that support information security. For example, while the method for configuring a firewall belongs in the technical specifications SysSP, the firewall’s configuration must follow guidelines established by management. An organization might not want its employees to access the Internet via the organization’s network, for instance; in that case, the firewall should be configured accordingly.

Firewalls are not the only technology that may require systems-specific policies. Any system that affects the confidentiality, integrity, or availability of information must be assessed to evaluate the trade-off between improved security and restrictions.

Systems-specific policies can be developed at the same time as ISSPs, or they can be prepared in advance of their related ISSPs. Before management can craft a policy informing users what they can do with certain technology and how to do it, system administrators might have to configure and operate the system. Some organizations may prefer to develop ISSPs and SysSPs in tandem so that operational procedures and user guidelines are created simultaneously.

Technical Specifications SysSPs

While a manager can work with a systems administrator to create managerial policy, as described in the preceding section, the systems administrator in turn might need to create a policy to implement the managerial policy. Each type of equipment requires its own set of policies, which are used to translate management’s intent for the technical control into an enforceable technical approach. For example, an ISSP may require that user passwords be changed quarterly; a systems administrator can implement a technical control within a specific application to enforce this policy. There are two general methods of implementing such technical controls: access control lists and configuration rules.

Access Control Lists

An access control list (ACL) consists of details about user access and use permissions and privileges for an organizational asset or resource, such as a file storage system, software component, or network communications device. ACLs focus on assets and the users who can access and use them. A capabilities table is similar to an ACL, but it focuses on users, the assets they can access, and what they can do with those assets. In some systems, capability tables are called user profiles or user policies.

These specifications frequently take the form of complex matrices rather than simple lists or tables, resulting in an access control matrix that combines the information in ACLs and capability tables.

As illustrated in Figures 3-4 and 3-5, both Microsoft Windows and Linux systems translate ACLs into sets of configurations that administrators use to control access to their systems.

Figure 3-4

Figure 3-5

The level of detail may differ from system to system, but in general, ACLs can restrict access for a specific user, computer, time, or duration—even a specific file. This specificity provides powerful control to the administrator. In general, ACLs regulate the following:

  • Who can use the system

  • What authorized users can access

  • When authorized users can access the system

  • Where authorized users can access the system

The who of ACL access may be determined by a person’s identity or membership in a group. Restricting what authorized users are permitted to access—whether by type (printers, files, communication devices, or applications), name, or location—is achieved by adjusting the resource privileges for a person or group to Read, Write, Create, Modify, Delete, Compare, or Copy. To control when access is allowed, some organizations implement time-of-day and day-of-week restrictions for certain network or system resources. To control where resources can be accessed, many network-connected assets block remote usage and have some levels of access that are restricted to locally connected users, such as restrictions by computer MAC address or network IP address. When these various ACL options are applied concurrently, the organization can govern how its resources can be used.

Configuration Rule Policies

Configuration rules (or policies) govern how a security system reacts to the data it receives. Rule-based policies are more specific to the operation of a system than ACLs, and they may or may not deal with users directly. Many security systems—for example, firewalls, intrusion detection and prevention systems (IDPSs), and proxy servers, all of which you will learn about in Modules 8 and 9—use specific configuration scripts that represent the configuration rule policy to determine how the system handles each data element they process. The examples in Figures 3-6 and 3-7 show how network security policy has been implemented by a Palo Alto firewall’s rule set and by Ionx Verisys (File Integrity Monitoring) in a host-based IDPS rule set.

Combination SysSPs

Many organizations create a single document that combines the managerial guidance SysSP and the technical specifications SysSP. While this document can be somewhat confusing to casual users, it is practical to have the guidance from managerial and technical perspectives in a single place. If this approach is used, care should be taken to clearly articulate the required actions. Some might consider this type of policy document a procedure, but it is actually a hybrid that combines policy with procedural guidance to assist implementers of the system being managed. This approach is best used by organizations that have multiple technical control systems of different types and by smaller organizations that want to document policy and procedure in a compact format.


Post a Comment