An authorization policy is a high-level document that defines how an organization will assign and enforce access control rights. It is important to write a formal authorization policy rather than simply implement random access controls. A written policy defines a high-level strategy for access control security and identifies the organization’s security goals and compliance obligations.

An authorization policy should also take into account the fact that access controls do not exist in a vacuum. Access controls for systems are dependent on physical access controls, and application security is interrelated with systems and data security. An authorization policy defines these relationships and ensures that steps taken to secure one element of an organization’s infrastructure will promote the security of all of the other elements as well.

Securing the data center or other facility that stores sensitive resources is a vitally important part of an access control plan. You can encrypt and protect a database server that holds customer records with a multistage authentication system, but what happens if someone physically steals it? The data is unavailable to those with legitimate access.

An authorization policy for facilities should dictate the following points:

• Appropriate entry system access controls: An authorization policy should specify which areas should be locked at all times and may dictate whether a one-, two-, or three-stage locking mechanism is appropriate given the resources in that area. For example, a data facility housing an organization’s database servers may justify a two- or three-stage locking mechanism that incorporates both a token and a biometric authentication mechanism. You would elaborate on the specific implementation details of what type of biometric system to use in a separate, lower-level document.
• Secondary locks on equipment and storage cabinets within the facility: To further secure specific pieces of equipment, such as a database server that stores mission-critical data, the policy may call for secondary locks on that equipment. This section of the policy should also dictate which employees should be given keys to that equipment.
• Prevention of social engineering: The authorization policy should specify goals for the prevention of social engineering. These goals should focus primarily on training employees and on their acceptance of their role in preventing social engineering attacks.

Once you dictate how to secure the data center or other facility, you should secure the systems within that data center as well. This is doubly important for systems that are not stored in a dedicated facility with strong physical security.

A good authorization policy includes goals for securing systems. Some points to include are:

• Limit access to those employees who have a legitimate need for resources. Which employees need access to specific resources varies by organization. In general, if an employee does not need access to a system in order to perform his or her duties, you should not grant access regardless of the employee’s position.
• Describe a strong password policy that includes password length requirements, use of several types of characters (uppercase and lowercase, numeric, and special characters), and change frequency. In this section, you should be careful to balance the employees’ need for passwords that are easy to remember and the ideals of robust passwords. If the policy dictates that users should change their passwords weekly, for example, employees might begin reusing old passwords, use the same password with a minor change, or simply write them down. These practices make it easier for employees to remember their frequently changing passwords. They also make those passwords less secure, defeating the purpose of the policy.

Applications are one of the most common sources of vulnerability in any system. They are often designed with functionality in mind, not security. This can lead to security testing as an afterthought. Because you cannot control the practices of various software vendors, your access control policy should include as many precautions as possible on the systems end to safeguard the environment for which you are responsible.

Key elements to include in the policy are:

• Standard testing procedures for any third-party application installed in the environment: The authorization policy should dictate that all access controls within applications be examined and tested for security. You should replace applications that do not handle access controls securely—for example, by storing application user data in an unprotected flat file or unencrypted database table—with more secure alternatives, update to a newer version, or secure on the systems end.

• Limiting application access: Many organizations seek to avoid operational issues by running applications under an administrative account. While this may be expedient, it can also cause serious problems if the application is compromised by granting an attacker administrative access to the underlying operating system. Organizations implementing applications should follow the principle of least privilege and install software with an account that has only the specific permissions necessary to run the application.

Data access is the core of any authorization policy. Access control for facilities, systems, and applications exists to protect the data stored in those facilities and systems, and the applications used to access and process those data. An authorization policy for data should include these points:

• Specify which data should be encrypted—Passwords are an obvious example, but other data may also justify encryption, depending on the organization’s regulatory compliance needs and other factors. The authorization policy should not dictate specific data elements to be encrypted but rather should provide criteria for encrypted data. For example, a policy might specify that you must encrypt any data defined as protected health information under HIPAA. This allows systems engineers and database administrators to decide whether a specific data element qualifies for encryption, even if that data did not exist when you wrote the policy.
• Enforce the principle of lowest possible access—This states that if read access is sufficient for an employee to perform a necessary task, the employee should not be granted read-write access.

Providing remote access capabilities can greatly increase employees’ productivity by allowing them to do their jobs wherever they need to be, from a hotel room to a job site. However, with increased levels of access come new access control challenges. When every person who connects to the internal network does so from a workstation on that network, you don’t have to worry about communications being hijacked. When employees gain remote access, they can use any Internet connection to access the internal network via a virtual private network (VPN). Because you have no control over those Internet access points, you should always assume the worst—that they are being actively monitored by hackers.

Including the following points in an authorization policy will provide direction for implementing specific controls to secure remote access:

• Provide remote access only to those employees who have a legitimate need to work offsite. Grant it on a temporary basis for those who travel or work offsite occasionally.
• Grant access to the VPN through a two-stage authentication process that includes both a strong password and a token device. You should document specific password creation guidance in a separate password policy document.
• Outline specific guidelines in your authorization policy on acceptable activity while connected to the VPN.

Supervisory control and data acquisition (SCADA) process control systems are at the heart of much of society’s critical infrastructure. SCADA systems monitor and control telecommunications, water and waste control, energy, and transportation, among other industries and utilities. SCADA devices use local area network (LAN), wide area network (WAN), and wireless communications infrastructures for monitoring and control purposes. These systems can be very complex. The systems are used for everything from monitoring the temperature in a room within an electrical substation to monitoring all of the activity in a waste management plant. Access controls to these devices are critical.

SCADA systems have the ability to monitor and control utility systems in real time. The monitoring provides readings from meters and sensors to a central facility through devices called remote terminal units (RTUs) to the user interface at regular intervals. The operator at the central facility is able to interact with the SCADA system to modify or override settings as necessary.

This interface, called a human machine interface (HMI), is where the operator views the data that are received and processed. The HMI is connected to a database that gathers information from the RTUs. Programmable logic controllers (PLCs) are also connected to this system. PLCs are designed to generate graphs on logistical information and trends. They also provide access to troubleshooting guides. These devices allow SCADA operators to efficiently monitor and manage the infrastructure.

SCADA systems are a point of risk for the utilities that use them. These systems were often designed with the assumption that they would not be connected to outside networks. They were also designed with misplaced faith in the practice of security through obscurity. The designers of SCADA systems also relied on logical security and did not consider physical security. This has resulted in a critical system that is inherently insecure.

The ISA Security Compliance Institute (ISCI) publishes industry standard guidelines that may be used to certify secure SCADA devices. Devices meeting the ISCI requirements may be awarded the ISASecure Certified Device designation. It is imperative that organizations understand the limitations of SCADA system security. You must physically secure devices and WANs. Strong access controls, such as the following, in both the physical and logical realm are necessary:

• Physical security on collection points
• Encrypted communications between collection points, controllers, and the central hub
• Two-way authentication between remote points and a centralized controller
• Easily managed user rights for removing or modifying users
• Segregation of SCADA systems from the rest of the network systems

Following these practices will make SCADA systems more secure and lessen the risk of a security breach.

It is imperative to conduct a threat and vulnerability assessment of critical infrastructures. Some of the more difficult to handle are those threats and vulnerabilities related to interdependencies and interoperability of the various systems. Understanding these interdependencies is essential to securing the most critical systems. Identifying single-point vulnerabilities is also essential to risk mitigation.

One of the first steps you must take when analyzing risk and developing a mitigation plan is to identify which assets are more critical. Determining which systems rely on each other is vital. If a water treatment plant is damaged, how will that affect other services? It is essential that you identify critical points that can cause multiple systems to fail.

Redundancy for these critical systems is also vital to risk mitigation. They must be completely separate systems. Two power lines running on the same path do not achieve redundancy. One event, whether it’s natural or unnatural, could take out both systems. To mitigate risk, infrastructure design must avoid single points of failure.