"Open Sesame" or Not? Use the Right Access Controls
- Use the Right Access Controls on Network Servers
- Use the Right Access Controls On Public Web Servers
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In our previous article, Stick to the Essentials,we made the point that more than 99 percent of intrusions result from the exploitation of known vulnerabilities or configuration errors, even though countermeasures and solutions are available. This excerpt from The CERT® Guide to System and Network Security Practices (Addison-Wesley, 2001, ISBN: 020173723X), and the CERT security improvement modules Securing Network Servers and Securing Public Web Servers advises administrators to configure network servers securely by applying two essential practices: Use the right access controls on general purpose servers, and use the right access controls on public Web servers. The second practice assumes that the guidelines described in the first have been followed.
Vendors sell systems configured so their customers will be eager to buy. Often, systems are general-purpose, that is, fully featured with most of the software enabled for ease of use. They are meant to satisfy everyone's needs and, perhaps, some they didn't realize they had. Such systems frequently contain
services that are unneeded and often insecurely configured
little to no protection against intruders accessing data objects such as files and directories
ease-of-use features often provided at the expense of security
vulnerabilities that intruders can use to break into systems
Given a user's or user group's role and access authority, administrators are responsible for implementing user privileges to access any data object on any network server. Access controls need to be configured to allow users to do their jobs while, at the same time, protecting the organization's critical data from breaches in confidentiality, integrity, and availability.
Use the Right Access Controls On Network Servers
Many operating systems provide the capability to specify access privileges individually for files, directories, devices, and other data or code objects. We recommend configuring the settings on files and other objects to take advantage of this capability and protect information in accordance with the organization's security policy.
The biggest challenge for administrators setting up access controls on data items in an operating system's file system is knowing what level of access is appropriate and correct. They must determine which identities need what type of access to properly use the data items in question.
Why This Is Important
Carefully setting access controls reduces the risk of both intentional and unintentional security breaches. For example, denying read access helps to protect confidentiality of information, while denying unnecessary write (modify) access can help maintain its integrity. Limiting the execution privilege of most system-related tools to authorized system administrators can prevent general users from making configuration changes that could reduce security. This restriction can also make it harder for intruders to use those tools to attack the system or other systems on the network.
How to Do It
Some operating systems provide a number of file systems, each with different access control capabilities. It is important to choose the file system that best meets requirements for file access control. This decision may affect the low-level formatting of storage devices, so it should be made early in the process of configuring the operating system.
Implement access controls during initial installation and configuration of the operating system. Carefully monitor and maintain them thereafter.
Identify the Level of Protection Needed
Restrict access to data based on groups, not individuals. For example, instead of giving read-only access to the Master Auto Parts File to the identities Manny, Moe, and Jack, the administrator first creates a group named Master_Auto_Parts_File_Read_Only, and places the identities Manny, Moe, and Jack into this group. The access control lists associated with the Master Auto Parts File are changed to grant read-only access to the group Master_Auto_Parts_File_Read_Only. If that triumvirate ever changes, only the group definition needs to change; the file need never change, even if no one is a member of the Master_Auto_Parts_File_Read_Only group. Plus, the group's name helps to document the access granted to those who are members. Use groups even if they contain only one member.
One method that can be used to identify needed protection is to construct a matrix with categories of files and objects on one axis and groups of users (defined by roles and access authority) on the other. Then, record in the matrix the kinds of access privileges allowed for that class of objects and that class of users. The privileges are based on the security requirements (such as confidentiality, integrity, and availability) of the various classes of resources.
For example, file categories may include administrative information (user names, passwords, privileges, and so on), applications, development tools, operating system files, and user data files. The latter may be further subdivided into categories such as customer accounts, inventory records, research data, and management reports. User groups may include system administrators, network service daemons, and users from various departments.
Privilege identification may result in the need to split some rows and columns. This happens, for example, upon discovering that a single group of users is really two groups because their needs to access a particular resource is not uniform.
Consider distinguishing local access privileges from network access privileges for a class of files.
Application programs may request and be granted increased access privileges for some of their operations—a change that is not obvious to the users of that application, and may not be desired. Therefore, it is important to take great care in assigning privileges to users and groups.
Configure the operating system to recognize the needed user groups and then assign individual users (including network service daemons) to the appropriate groups.
Configure Access Controls
Configure access controls for all protected files, directories, devices, and other objects using the matrix created in the first step as a guide. Every change or decision not to change each object's permission should be documented, along with the rationale.
The least privilege principle should be used when deciding how to implement access control lists. In other words, grant permissions to those user groups that need to have access and then allow those groups only the access levels they absolutely require. For example, if a group needs Read access to a folder, resist the temptation to give the group Full control, and grant only Read access.
Consider the following:
Disable write/modify access permissions for all executable and binary files.
Restrict access of operating system source files, configuration files, and their directories to authorized administrators.
For UNIX systems, there should be no world-writable files unless application programs specifically require them. For Windows systems, there should be no permissions set so that "the Everyone group has Modify permissions to files."
For UNIX systems, if possible, mount file systems as read only and nosuid to preclude unauthorized changes to files and programs.
Assign an access permission of immutable to all kernel files if assigning such a permission is supported by the operating system (such as Linux and FreeBSD).
Establish all log files as "append only" if that option is available.
Aim to preclude users from installing, removing, or editing scripts without administrative review. We realize that this restriction is difficult to enforce. Refer to the practices Consider Security Implications for Programs, Scripts, and Plug-ins and Configure the Web Server to Minimize the Functionality of Programs, Scripts, and Plug-ins in the references noted at the beginning of this article.
Pay attention to access control inheritance when defining categories of files and user groups. Ensure that the operating system is configured so that newly created files and directories inherit appropriate access controls, and so that access controls propagate down the directory hierarchies as intended when assigned.
Many of an administrator's security directives can be overridden on a per-directory basis. The convenience of being able to make local exceptions to global policy is offset by the threat of a security hole being introduced in a distant subdirectory, which could be taken over by a hostile user. Administrators should disable a subdirectory's capability to override top-level security directives unless that override is required.
Install and Configure File Encryption Capabilities for Sensitive Data
Some operating systems provide optional file encryption; there are also third-party file encryption packages available, which may be useful if the operating system's access controls are insufficient to maintain the confidentiality of file contents. This situation can occur if the operating system provides few or no access control features, or when the relationships among categories of files and categories of users are so complex that it would be difficult to administer the security policy using only access controls.
The security provided by strong access controls is further enhanced by the use of encryption. However, when using encryption, an administrator must still dispose of unencrypted versions of the data that existed prior to encryption being performed, remain after decrypting, and are used in the encryption process. Encryption adds complexity, so weigh the need for it against the cost of using it.
NOTE
Note that this recommendation pertains only to the encryption of files stored on the server itself. Encryption of information for transmission over a network is a separate issue that is not within the scope of this practice.
Policy Considerations
An organization's security policy for networked systems should specify the following:
Access privileges and controls for the information that will be stored on servers
Ways to access the files that have been encrypted with a user key. This information is very important when that user no longer works for the organization.
Access privileges and controls for administrators, such as
the authority and conditions for reading other users' e-mail
access to protected programs or files
disruption of service under specific conditions
a ban on sharing accounts
a ban on the unauthorized creation of user accounts
the authority and conditions for using vulnerability testing tools
the authority and conditions for using password cracking tools
The AusCERT Unix Checklist recommends permission settings as well as tasks for administrators to complete when adjusting access control lists (ACLs) on a Unix- or Linux-based system.