Managing access to sensitive data and resources is a crucial component of an organization’s cybersecurity strategy. With advanced persistent threats [APTs] and the rise of organized cybercrime, an organization cannot guarantee that they will be able to restrict an attacker from gaining access to their internal network and systems.
Protecting sensitive data and resources requires implementing a zero-trust security strategy, where users and devices have restricted access to the organization’s digital resources. By limiting the access of user accounts and devices to what is essential for performing core business duties, it is possible to protect the organization against an attacker who has compromised a user’s account or against an insider threat.
One means of implementing this level of access monitoring and control is through the use of an access control list [ACL]. ACLs come in a variety of different types, and have their advantages and disadvantages compared to other means of access control. Understanding the capabilities and limitations of ACLs is essential to implementing a usable but secure zero trust architecture.
Types of ACLs
In general, an access control list is exactly what its name suggests: a list that governs access to a particular resource. ACLs can be used in a number of different contexts, but two of the most common are governing permissions on file systems and at the network level.
In a filesystem, an ACL is designed to help the operating system determine the levels of access that a particular user has with regard to a certain file or directory. Commonly, these permissions state whether or not a user has the ability to read, write, and/or execute a particular file.
In Linux, ACLs are available as an supplement to traditional permission management, where file permissions must be set on a per-file or per-folder basis. With an ACL, an administrator can assign certain permissions or sets of permissions to a given user very easily. This enables a certain user or group to be given certain permissions for a file by the file owner even if that owner does not have the power to manage the given group.
ACLs can also be applied at the network level, where they can be used in a variety of ways. Network ACLs can provide performance improvements by implementing restrictions on certain types of traffic or for a particular region of the network. They also provide security benefits since they can restrict communications between different systems or over certain protocols as needed.
At the network level, two main types of ACLs exist. A standard ACL applies restrictions based solely upon the source IP address of traffic. For example, a protection against data exfiltration may be blocking any traffic coming from the main database server from crossing the organization’s network perimeter. Since the database server should not be communicating with external systems directly, this could help to detect and block potentially malicious traffic. However, this standard ACL could not differentiate different types of traffic and make decisions accordingly.
An extended ACL uses the source and destination addresses and ports in its analysis. This enables a network administrator to define much more granular rules regarding the types of traffic that are permitted to pass through and the types that should be blocked. This is helpful if, for example, an administrator wishes to decrease the attack surface of a web server by limiting traffic to and from it to only traffic flowing on legitimate HTTP[S] ports [80 and 443].
Pros and Cons of ACLs
Access control lists can be used to implement a wide range of security controls. However, they have their advantages and disadvantages. In many cases, an ACL, while effective, may not be the right choice.
The main advantage of ACLs is their simplicity. An ACL clearly lays out the levels of access and permissions that each user, group, or device has on a particular system. This makes it easy to define and interpret an ACL. Since these lists can easily be made human readable, an administrator can easily determine the current permissions and access controls placed on a system, make edits, and revoke permissions as necessary.
On the other hand, ACLs have a number of disadvantages as well. These include a lack of efficiency, scalability, and visibility.
ACLs lack efficiency since they only support explicitly declared access controls. If, for example, a user has unique access or permissions because they are both in the IT department and a manager, this level of access must be explicitly stated rather than inferred based upon membership in both groups. This requirement for explicit declaration of access controls also impacts scalability. As the number of users, groups, and resources grows, so does the length of the ACL and the time required to determine the level of access granted to a particular user.
Finally, ACLs lack visibility since a user’s permissions and levels of access can be scattered across multiple, standalone lists. Auditing, changing, or revoking access requires a review of every ACL in the organization’s environment to apply the new permissions.
Choosing the Right Access Control Mechanism
ACLs are one of several options for implementing access control mechanisms in a system. In some contexts, their simplicity makes them the ideal solution, while, in others, their limitations drive a need for a different solution. Ensuring system usability and security requires selecting the right access control mechanism for each particular use case.
An access control list [ACL] contains rules that grant or deny access to certain digital environments. There are two types of ACLs:
- Filesystem ACLs━filter access to files and/or directories. Filesystem ACLs tell operating systems which users can access the system, and what privileges the users are allowed.
- Networking ACLs━filter access to the network. Networking ACLs tell routers and switches which type of traffic can access the network, and which activity is allowed.
Originally, ACLs were the only way to achieve firewall protection. Today, there are many types of firewalls and alternatives to ACLs. However, organizations continue to use ACLs in conjunction with technologies like virtual private networks [VPNs] that specify which traffic should be encrypted and transferred through a VPN tunnel.
Reasons to use an ACL:
- Traffic flow control
- Restricted network traffic for better network performance
- A level of security for network access specifying which areas of the server/network/service can be accessed by a user and which cannot
- Granular monitoring of the traffic exiting and entering the system
How ACL Works
A filesystem ACL is a table that informs a computer operating system of the access privileges a user has to a system object, including a single file or a file directory. Each object has a security property that connects it to its access control list. The list has an entry for every user with access rights to the system.
Typical privileges include the right to read a single file [or all the files] in a directory, to execute the file, or to write to the file or files. Operating systems that use an ACL include, for example, Microsoft Windows NT/2000, Novell’s Netware, Digital’s OpenVMS, and UNIX-based systems.
When a user requests an object in an ACL-based security model, the operating system studies the ACL for a relevant entry and sees whether the requested operation is permissible.
Networking ACLs are installed in routers or switches, where they act as traffic filters. Each networking ACL contains predefined rules that control which packets or routing updates are allowed or denied access to a network.
Routers and switches with ACLs work like packet filters that transfer or deny packets based on filtering criteria. As a Layer 3 device, a packet-filtering router uses rules to see if traffic should be permitted or denied access. It decides this based on source and destination IP addresses, destination port and source port, and the official procedure of the packet.
Types of Access Control Lists
Access control lists can be approached in relation to two main categories:
Standard ACL
An access-list that is developed solely using the source IP address. These access control lists allow or block the entire protocol suite. They don’t differentiate between IP traffic such as UDP, TCP, and HTTPS. They use numbers 1-99 or 1300-1999 so the router can recognize the address as the source IP address.
Extended ACL
An access-list that is widely used as it can differentiate IP traffic. It uses both source and destination IP addresses and port numbers to make sense of IP traffic. You can also specify which IP traffic should be allowed or denied. They use the numbers 100-199 and 2000-2699.
Linux ACL vs. Windows ACL
Linux provides the flexibility to make kernel modifications, which cannot be done with Windows. However, because you can make kernel modifications to Linux, you may need specialized expertise to maintain the production environment.
Windows offers the advantage of a stable platform, but it is not as flexible as Linux. In relation to application integration, Windows is easier than Linux.
A user can set access control mechanisms in a Windows box without adding software.
In terms of patching, Microsoft is the only source to issue Windows patches. With Linux, you can choose to wait until a commercial Linux provider releases a patch or you can go with an open-source entity for patches.
ACL Best Practices
When configuring ACLs, you should adhere to a few best practices to ensure that security is tight and suspicious traffic is blocked:
1. ACLs everywhere
ACLs are enforced on each interface, in nearly all security or routing gear. This is fitting as you can’t have the same rules for outward-facing interfaces and interfaces that form your campus network. However, interfaces are similar and you don’t want some protected by ACLs and some exposed.
The practice of an ACL on all interfaces is essential for inbound ACLs, specifically the rules that decide which address can transfer data into your network. Those are the rules that make a considerable difference.
2. ACL in order
In almost all cases, the engine enforcing the ACL begins at the top and moves down the list. This has implications for working out what an ACL will do with a specific data stream.
One reason organizations adopt ACLs is that they have a lower computational overhead than stateful firewalls and that they work at high speeds. This is essential when you try to implement security for fast network interfaces. However, the longer a packet remains in the system, while it is examined against the rules in the ACL, the slower the performance.
The trick is to put the rules that you expect will be triggered at the top of the ACL. Work from the general to specific, while ensuring the rules are logically grouped. You should know that each packet will be acted on by the initial rule that it triggers, you could end up passing a packet via one rule when you intend to block it via another. Consider how you want the chain of events to happen, in particular when adding new rules.
3. Document your work
When you add ACL rules, document why you are adding them, what they are intended to do, and when you added them.
You don’t need to have one comment per rule. You can make one comment for a block of rules, an intricate explanation for a single rule, or a combination of both approaches.
Developers should ensure that the current rules are documented, so nobody needs to guess why a rule is there.
RBAC vs ACL
Developers can use role-based access list [RBAC] systems to control security at a granular level. Rather than emphasizing the identity of the user and determining whether they should be permitted to see something in the application, RBAC governs security based on the role of the user within an organization.
For example, rather than giving permission to John Smith, an architect in New York, RBAC would give permission to a role for U.S. architects. John Smith may be one of many users with that role. Thus, RBAC guarantees regulatory persons that only specific users have access to sensitive information, as it gives all approvals based on roles.
RBAC is generally considered to be a preferred method for business applications. RBAC is more effective than ACL in relation to administrative overheads and security. ACL is best used for applying security at the individual user level. You can use RBAC to serve a company-wide security system, which an administrator monitors. An ACL can, for example, provide write access to a certain file, but it cannot define how a user can modify the file.
Example of a role-based access control [RBAC] system
Role-Based Access Control with Imperva
Imperva allows for control of user privileges using flexible role-based access controls. Users are provided with view-only, edit, or restricted access to management functions and objects. Organizations can also hierarchically group and manage IT assets into categories for fine-grained access control, even in Managed Security Service Provider [MSSP] deployments and large-scale enterprise.