IN THIS CHAPTER, WE FOCUS ON THE SERVERS and networks that store sensitive information, and how to use the built-in access controls provided by various operating systems to control access to files and data. In the case studies at the end of the chapter, you'll read about how access controls are built into server and network infrastructures.
A major concern for any IT department is the security and integrity of data or information. The major method of securing that information is through access controls. Let's take a look at some methods for securing information in its various forms.
Information can exist in one of two states: at rest or in motion. Data at rest is data that is in a storage system. Data in motion is data that is in transit, such as on a network. To truly protect data, you need to consider both of these states.
Data at rest (DAR) is simply stored data. The data may be in archival form on tape or optical disc, on a hard disk, or sitting in a system's buffers. Depending on where the data is resting, it can be at very high risk. Some devices such as Web servers are accessible from outside an organization's network and are open to attack. Portable devices like personal digital assistants (PDAs), flash memory devices, and laptops are at a high risk of physical theft. In many ways, data at rest is a risky state to be in. Regardless of where it resides, there are a number of techniques you can use to secure data at rest.
Access controls are a vital first step in securing DAR. Having strict access controls in place will help ensure the privacy and integrity of data even when a user has legitimate access to a system. Regardless of the form these controls take—mandatory access control (MAC), discretionary access control (DAC), or role-based access control (RBAC)—these controls are a necessary first step. If a user has legitimate access to a system without access controls in place, they could access all of the data stored on that system.
Let's look an example of file server access and DAR. A large corporation is establishing network storage for archival purposes for all of its employees. Each user's local Documents directory is mapped to a folder on a network file server. The users are told that any document that needs to be backed up should be stored in the Documents folder. For ease of management and organization, each user's folder on the file server is named with his or her logon. These folders are then organized by department, so each user folder is within his or her departmental folder.
Although documents are more easily backed up, end users raised concerns, especially users in the human resources (HR) and accounting departments. Some documents contain sensitive information that should not be accessible to all employees. This is where access controls come in. Each user is granted full rights to his or her network folder and limited rights to the departmental folder. For document-sharing purposes, users have rights to read and modify files in other user folders in their department; however, those rights are applied and revoked using MAC by the owner of the document. Users do not have any access rights to any other department's folders. Using access controls, the company was able to guarantee the privacy of sensitive data on the file share.
Access controls alone are not enough to secure DAR. Portable devices can be stolen and access controls can be circumvented. When a malicious user has access to the medium on which information is at rest, the user can circumvent standard access controls. A malicious user could mount a stolen laptop hard drive, for example, on another system on which he or she has administrative rights. The user could then take ownership of files and folders, modifying the access rights at will. This is where disk encryption becomes vital.
Disk encryption, especially whole disk encryption, is essential to securing data at rest, especially on a portable device. An encrypted disk is difficult to extract data by an unauthorized user. Although a malicious user could decrypt the disk, it would take months or even years.
You must also consider physical security when dealing with DAR. If an organization uses backup tapes or optical media for archival purposes, how and where are those tapes stored and transported? How does the organization decommission and dispose of obsolete systems? Some organizations have discovered that device disposal can lead to information leaks. Here are some examples of data leaks due to incomplete disposal policies:
At the end of the 2008 U.S. presidential campaign, the McCain campaign sold off PDAs and smartphones that were no longer needed. They neglected to clear the devices' memory before the sale and exposed the personal phone numbers of high-end donors and campaign officials.
In 2006, a U.S. defense contractor sold obsolete hard drives on eBay. Information found on these drives included Top Secret documents on a new U.S. missile defense program.
In 2005, a German police department sold a hard drive containing detailed plans on the department's alarm systems as well as sensitive police procedural documentation.
There are countless other examples. A study by British Telecom found that 34 percent of the hard drives the company bought on eBay contained sensitive information. This included personal data, financial information, and even classified documents belonging to various nations.
Data in motion (DIM) is the term used to describe data any time it travels from one place to another, for example Web page files are considered in motion while they are sent from a Web server through the Internet to a Web browser (see Figure 8-1). DIM is vulnerable to improper disclosure and theft. DIM is vulnerable as it travels over the network, whether the network is wired or wireless. During transit, standard access controls applied by the operating system are irrelevant. Data packets on a network do not carry ownership information and are not modified by access controls that protect data at rest. Therefore, anyone with access to the network could access the data. The data is vulnerable at any point in transit.
DIM can also be at less risk than DAR, which seems counterintuitive. In a modern switched network, data travels from point to point. For an attacker to gain access to the DIM, she would have to know the path the data takes while in transit. She also needs access to the physical wires or routers to insert her packet sniffing equipment inside that path. This also applies to sending data over the Internet. The data travels a distinct path and is not shared with systems that are not on that path. An attacker could use various techniques to trick the switch or router into acting like a hub, which would broadcast the packets to multiple points, including her packet sniffer. However, the attacker would still need undetected access to that device for a significant period of time. At that point an attacker would have access to an organization's network and be able to compromise routers and switches. This represents a significant security breach, meaning DAR will be at risk as well. If a switch can be compromised, any system on the network could be compromised.
Standard network security includes intrusion detection systems (IDSs), intrusion prevention systems (IPSs), and border protections like firewalls. These systems can effectively secure most DIM that doesn't leave the local area network (LAN). An organization should further secure high impact data. There are two methods for securing DIM, encrypting data and securing the communications channel.
One way to secure DIM is to encrypt data. This is especially common with e-mail. The information sender and receiver agree on an encryption technique, and then share the appropriate keys. The sender then encrypts the information and the receiver decrypts it. Anyone who intercepts the data packets in transit are left with meaningless bits of data.
Another method is to secure the communications channel. You can use protocols such as Secure Sockets Layer (SSL) to accomplish this. SSL creates encrypted two-way communications at the application layer of networking. You'll see this most commonly with Hypertext Transfer Protocol Secure (HTTPS) communications. You can also secure the path with a virtual private network (VPN). A VPN is a secure encrypted tunnel through a public network such as the Internet. All network traffic from one end of the tunnel is automatically encrypted before it is sent to the other end of the tunnel. This strategy is widely used to secure sensitive information that must be sent through unsecured channels such as the Internet.
An "object" is an item or a distinct group of information in a data storage system, usually a relational database (RDB), but it can be any grouping of information. By grouping information as an object, applying access controls can be significantly more efficient. You can set controls at the object level. This allows you to manage groups of related data instead of managing individual items. Not only does applying security at the object level help with DAR security, it can help with DIM security. If the network security device is object-aware, you can apply security rules to objects. This can be utilized to control how and where data can get transmitted. Application layer firewalls and Web content filters use object-level security to protect DIM.
When securing DAR, applying an access control policy to an organization's file system is the first step. This is done by creating an access control list (ACL) to handle both rights management of the data and to audit data access. File system access controls deal directly with accessing data stored on a system, or a group of systems sharing a common file system. You can manage ACLs in a Microsoft Windows environment using Active Directory, or in a UNIX environment using Portable Operating System Interface for UNIX (POSIX) or Network File System version 4 (NFSv4).
Note
Active Directory is the directory service for Microsoft Windows Server. POSIX is a set of interoperability standards defined by the IEEE. NFSv4 is a network file system developed by the Internet Engineering Task Force (IETF).
An ACL is a list of security policies associated with an object. An ACL is commonly comprised of a collection of access control entities (ACE). These are security objects that define access for one distinct user, group, or system. An ACE has four properties:
There are three primary types of ACEs you can apply to any security entity: access-denied, access-allowed, and system-audit. Each ACE allows, denies, or audits a specific right, such as read or modify for the SID it's attached to. Table 8-1 lists types of ACEs.
Note
You'll learn about access control lists and access control models in detail in Chapter 10.
An ACL is applied directly on the file system of one system and affects only users and data on that system. There are two types of ACLs: discretionary and system ACLs. Each list utilizes ACEs and handles a different aspect of access control.
A discretionary access control list (DACL) controls access to an object. It handles what access is allowed or denied. When an object is accessed all of the ACEs contained in the DACL are checked to see what access, if any, should be granted. Although the DACL can be directly accessed, it generally is not. The ACEs contained in it are the combined result of access controls set by an object's owner on an object, rights set by administrators on the object and its container, and by system rules.
When applying the rights from a DACL, the system begins by denying all rights and then processing the ACEs in the DACL until one granting access is reached. This means if a DACL is empty and contains no ACEs, access will not be granted to any user. This also means that it is important to create a DACL for every object that needs security. In the absence of a DACL, full rights are granted to the object.
A system access control list (SACL) is a system-created access control list that handles the information assurance aspect of access controls. Although a user can modify an SACL, this is generally not done. The SACL is a system-generated list based on the auditing rules set by the systems administrators. It contains the ACEs that handle what access needs to be audited and where to store the audit information. The SACL handles recording any access attempt, or only the successful or only the failed attempts. It is important to note that the SACL doesn't actually allow or deny access; it only records the access attempt and the success or failure of that attempt.
In addition to applying access controls to end users and objects, you can apply them to applications as well. This takes two forms—internal to the application and through the operating system.
You can assign an application its own user ID and directories. From there, you can grant the application rights only to the files and directories it needs to run and explicitly deny access to the rest of the system. This gives the application a sandbox to work in. If the application is compromised through an exploit in its code, the malicious user will only have access to the information that the application had access to. This type of access control is common on Web servers and application servers, which are highly accessible to the general public. Database servers typically operate behind a firewall and have little direct exposure to the public, but Web servers are public by design. This accessibility requires additional security measures that are not necessary on more protected servers, such as a database server.
Certain executables have their own internal access controls as well. Internal access controls are necessary where the application holds sensitive information in a format that is not accessible to the general file system. This situation is common in database management systems, where data is stored in raw form in tables or in binary large objects (BLOBs). In these cases, information must still be secured, but is inaccessible to the file system ACLs.
Let's take a look at an example of internal access controls. A homeowner's insurance company needed a way of controlling access to claims data, not only information on individual customer claims but also sensitive pricing information. The pricing information was especially critical. The price lists gave the company a competitive advantage because its estimates were more accurate than its competitors'. The accuracy was due to the extensive real-time pricing data in the price lists. The information was also legally protected. Due to recent lawsuits in the industry, the insurance company had to show that the price lists could not be modified at will.
The claims files and the pricing information were stored in a relational database management system (RDBMS) as BLOB data and inaccessible to the file system. The only way to access the data was with an estimating tool, but that didn't guarantee data privacy or integrity as most of the company had the tool. In fact it was an off-the-shelf application that other insurance companies and independent contractors had access to as well.
To secure the information, the insurance company worked with the application vendor to develop an RBAC system built into the application. This involved roles like Claim Representative who had the rights to create and modify estimates, pricing specialist who could create and modify price lists, and super user to handle administrative and support aspects of the application.
Adding the roles took care of data privacy, but not necessarily data integrity. To handle that, an auditing log and rollback functionality was added to the application. A user could see who had made changes to a file, when, and what changes were made. This included claims files and price lists. If a file was changed incorrectly, a user with super rights could revert the file back to a previous version.
All of this was done inside the application. The file system was unaware of any of the roles or protected data that resided inside the RDBMS.
In a discretionary access control environment, users have the ability to delegate access rights to the objects under their ownership. Delegated access rights are granted from something that owns an object to another user or system. Delegated rights come in two forms—explicit and implicit.
Explicitly delegated rights are access rights that are actively given to a user by an object owner. This occurs when the object owner identifies a user, group, or system and then grants a level of access to them. In most access control policies, an object owner can grant any right except the right to delegate access to the object.
Implicitly delegated rights happen automatically due to previously delegated rights from the object owner. This happens when an object owner delegates rights to a folder or other container object. Unless otherwise specified all child objects of the container will inherit the delegated rights of the parent object.
Microsoft Windows-based systems have highly granular file-based access controls. On a local level, an administrator works with users, groups, and objects. The administrator may group users together to grant rights. The administrator may control objects with both basic and advanced rights. Table 8-2 lists the basic access rights available in Windows and what they affect.
Table 8-2. Basic access rights in Windows.
NAME | DESCRIPTION | FILE OR FOLDER |
|---|---|---|
Full Control | Change permissions, take ownership, and delete subfolders and files. Perform actions permitted by all other NT File System (NTFS) file or folder permissions. | Both |
Modify | Delete a file or folder. Perform actions permitted by the Write permission and the Read & Execute permission. | Both |
Read & Execute | Navigate folders to reach other files and folders, even if the users do not have permission for those folders. Perform actions permitted by the Read permission and the List Folder Contents permission. Run the application. | Both |
List Folder Contents | View the names of files and subfolders in the folder. | Folder |
Read | See files and subfolders in the folder. View folder ownership, permissions, and attributes, such as Read-only, Hidden, Archive, and System. Read the file. View file attributes, ownership, and permissions. | Both |
Write | Create new files and subfolders within the folder. Change folder attributes. View folder ownership and permissions Overwrite the file, change file attributes, and view file ownership and permissions. | Both |
The Windows operating system can get far more granular with the utilization of advanced rights. The basic rights are just preset groupings of the more granular levels. These groupings cover most roles that an organization would want to give a user or group. The advanced rights for files are:
Full Control—The sum of all other rights
Traverse Folder/Execute File—The ability to navigate the file system and execute files
List Folder/Read Data—The ability to list the contents of a folder
Read attributes—The ability to view ownership and access control attributes on a file or folder
Read extended attributes—The ability to view all file or folder attributes
Create Files/Write Data—The ability to create new files and write to existing files
Create Folders/append Data—The ability to create new folders
Write attributes—The ability to change file and folder ownership and access control attributes
Write extended attributes—The ability to change extended attributes such as the ones in this list
Delete—The ability to delete files and folders
Read Permissions—The ability to view access control permissions on a file or folder
Change Permissions—The ability to change access control permissions on a file or folder
Take Ownership—The ability to change the ownership attribute on a file or folder
This gives you a partial picture of the level of granularity. Groups of objects or users—called organizational units (OUs)—provide advanced rights that allow thousands of different options. General administrators use basic rights for ease of management.
An organizational unit is a logical structure that allows you to organize users, computers, and other objects into separate units for administrative purposes. The main difference between an organizational unit and a group is that groups apply only to users while an OU can include any type of object.
Rights in Windows can be either explicit or inherited from parent folders. A user's rights on any given object is based on all of the inherited and explicit rights granted or denied by every OU that the user is a member of. It is important to note that Deny rights always take precedent over Allow rights. For example, Julie is a member of both the Accounting and IT OUs. She needs to access the accounts payable spreadsheet. Although the Accounting OU has been granted Read permission to this document, the IT OU is explicitly denied Read rights. Regardless of rights granted to Julie, the explicit deny will block her access.
A domain administrator in Windows is a member of the special domain administrators group. Members of this group have full control over all computers in the domain, including any file or folder that they haven't explicitly been denied access to. Members of this group have the ability to assign and modify the ACL of users, files, and folders on all systems in the domain. This group also has the ability to add or remove computers and OUs from the Windows domain. This group is added to the local administrators group to any computer added to the domain.
This is not the top-level authority in Windows. Above the domain administrators group is the enterprise administrators group. This group has administrative rights to the entire Active Directory forest in an organization. It is the only group with the ability to add or remove domains from the Active Directory forest, and is included in all domain administrator groups when they join the forest.
The Super Administrator is a built-in "secret" account in Windows Vista and Windows 7. This account is the local administrator on a standalone installation of Windows and is disabled by default. This account has full rights on the local system, and can take ownership of all objects. It is generally not needed in a standalone installation, but users with a lot of legacy applications may find a need to activate this account.
To activate the Super Administrator account, a user must first launch a command window with administrative rights using the runas command. In the command window, enter the following commands:
Net user Administrator /active:yes
To deactivate the account run the following command:
Net user Administrator /active:no
The Super Administrator account has no password by default. If it is activated, the first thing you should do is give the account a password.
By default, UNIX-based systems, which include UNIX and Linux, have a simplified ACL-based file permission systems. Unlike a standard ACL-based system, rights are not inherited in UNIX and must be applied to all files and folders explicitly. There are three rights, and three classes those rights can be assigned to.
The rights in a UNIX environment are:
Read—Grants a user or group the ability to read a file. If the right is on a directory, the requestor may read the list of files in that directory.
Write—Grants the requestor the ability to modify a file. If the right is set on a directory, the requestor may create, rename, or remove files in the directory.
execute—Grants the right to execute a file. This allows the requestor to run a binary or script file. If the right is set on a directory, the user may access files in the directory and access subdirectories but not view the list of files in the directory.
There are three classes of users as well: owner, group, and world. The group class refers to the group that the file or directory is a member of. Each one of these classes can have any, all, or none of the permissions applied to them. If no permission is set, the system denies access to the file.
There are two standard ways UNIX-based file permissions are written: symbolic notation or octal notation. Symbolic notation is simply listing the permissions by the first letter of the right. For example, the read right is listed as "r". This is done in a nine-character string with dashes in place of unassigned rights. The order the classes are listed is always the same, with user coming first, followed by group, and then world. The order in each three-character set is also standard, with read coming first, then write, and followed by execute.
Note
UNIX-based file permissions are customarily written in all lower case, while Windows permissions are usually written with an initial capital.
Octal notation is based on assigning each triplicate in symbolic notation a numerical value between 0 and 7. These values are then expressed as a three-digit number. No permissions has a value of zero, read adds 4, write adds 2, and execute adds 1. Adding the rights together gives a value for each class.
Table 8-3 lists some examples of UNIX-based rights in both notations.
Table 8-3. Examples of UNIX-based rights.
RIGHTS | SYMBOLIC NOTATION | OCTAL NOTATION |
|---|---|---|
Full rights for all classes on a file | rwxrwxrwx | 777 |
Full rights to the user, read execute for group, read for world | rwxr–xr–– | 754 |
Read write for the user, read for group, none for world | rw–r––––– | 640 |
Full rights for the user, write, execute for group, read for world | rwx–wx––x | 731 |
To calculate the octal notation for full rights to the user, read and execute for the group and world:
For the user: r+w+x or 4 + 2 + 1 = 7
For the group: r+x or 4 + 1 = 5
For the world: r+w or 4 + 1 = 5
Combine the results of the addition, and you get 755.
To change the permissions on a file or folder, use the chmod command, as shown here. Replace myfile with the name of the file or folder to be changed:
chmod 755 myfileYou can also use the letter notation or add or subtract rights from the user, group, or world. The command:
chmod g+rwx myfileadds read, write, and execute permissions for the group on the file myfile. The command:
chmod w-x myfileremoves the execute permission from the world on the file myfile.
Although this simplified ACL is useful on a standalone server or workstation, it has a lack of granular control and does not allow for multiple groups with different permissions. This causes difficulties and confusion in a network environment. In most organizations, the basic UNIX-based permissions have been extended with more full-featured ACL-based systems.
Linux Intrusion Detection System (LIDS) is a kernel patch intended to make Linux more secure by restricting the root user's abilities, adding intrusion detection functionality and improving the UNIX-based ACL.
To help with intrusion detection, LIDS adds a port scan detector to Linux. This allows administrators to watch activity on the system, alerting them of unusual activity. To further secure the system, LIDS implements two different ACL systems—a file ACL and a process ACL to restrict the capability of processes.
The file ACL implemented by LIDS extends the basic ACL in UNIX. The rights in LIDS are deny, read, write, and append, where append is a special type of write. With the append right, a user can add to a file but not otherwise modify it. The major difference in LIDS ACLs comes from its idea of subjects. A "subject" in LIDS is a user or group. Each file or folder can have these rights applied to multiple subjects. The concept of subjects allows far better control of files than standard UNIX-based permissions. LIDS also allows for rights inheritance, so rights applied to a folder can be inherited to all files and subfolders.
Root is a special class of user in a UNIX or Linux environment, also known as the superuser. It is similar to the administrator user in Windows. Root has full access to the system. It has the ability to override file system permissions and run any process. Therefore, it is not a good idea to run a system when performing ordinary tasks as root. Not only is it a security concern, a user can also accidently damage the system. UNIX assumes you know what you are doing and that you intend to run all the commands you enter. If root is logged in, it is possible to accidently delete major parts of the operating system.
Note
While in college, one of the authors of this book was a systems administrator in a university lab. The author accidently renamed the home directory while upgrading hard drives. This temporarily turned a server into a fancy paperweight. The damage was repairable, but the process was tedious.
However, some administrative tasks must be run with root access. UNIX offers a solution: the sudo command. Substitute user do (sudo) allows you to run any process as if another user was running it. This allows an administrator to be logged into the system with a standard user account and still perform tasks that require enhanced rights on the system by using sudo to run the command with root permissions.
Network Information Service (NIS) is a Sun Microsystems addition to UNIX to add client-server authentication to UNIX. NIS gives a UNIX network a central repository for configuration information like users and passwords, groups, host names, e-mail aliases, and other text-based configuration information. Although this does help with user management, it still utilizes standard UNIX ACLs and all of the drawbacks that come with that system. NIS also utilizes an older crypto methodology for securing passwords, which led to the creation of NIS +.
NIS+ was created by Sun Microsystems as a replacement for NIS, adding a level of security and granularity to UNIX access controls, as well as enhanced security in communications between the client and server.
Just like UNIX, objects in a NIS+ directory have owner, group, and other/world principles that can have rights to data. Other refers to other users in the NIS+ directory. NIS+ also adds a Nobody principle, which denotes any user that is not native to the NIS+ directory.
Objects in NIS+ have an ACL connected to them with access rights listed for each type of principle. There are four rights an NIS+ object ACL assigns:
Read—The ability to read the contents of the object
Modify—The ability to modify the contents of the object
Create—The ability to create new objects in the NIS+ directory table
Destroy—The ability to destroy objects contained in the table
NIS+ rights are displayed in a similar manner to those in UNIX. The main difference is that NIS+ groups rights in groups of four instead of three, and the first four are the Nobody user instead of owner, as follows:
RMCD RMCD RMCD RMCD nobody owner group world
As of 2002, Sun Microsystems phased out NIS+ in favor of Lightweight Directory Access Protocol (LDAP). This directory structure implements ACLs in the same manner as Microsoft's Active Directory. In Solaris 9 and 10, Sun has loaded both NIS+ and LDAP along with a tool to migrate NIS+ environments to LDAP.
A process control system (PCS) is a mechanism used to control the output of a specific process. For example, heating a room is a specific process with the desired outcome of maintaining a defined temperature over time. A PCS would receive information from a device, in this case, the thermostat, and decide to heat or not to heat based on the desired temperature. SCADA systems, which were discussed in Chapter 4, are basically large, complex PCSs.
Information systems access controls are generally not built into SCADA or PCS systems. Systems located on the perimeter of a network must rely on physical access control. The programs controlling these systems can use the access controls built into the environment. UNIX and Windows environments can control which users have rights to execute programs; those controls can be utilized to limit access to the SCADA backend to only users who need to access them. The best method would be to create a group that had access to the systems, and remove rights from all other users. Only authorized users, or members of that group, would be able to access the application.
Access controls for information systems are only as good as the policies and procedures that dictate their use. There are a few general best practices that you should follow to ensure reasonably secure access controls on information systems:
Create a baseline for access—Build a baseline for the current access levels in the environment. This will help identify holes in access and identify which users have rights beyond their needs.
Segregate users' rights by their role—Developers do not need access to production databases; sales executives do not need access to the accounts receivable system.
Automate user creation—Have prebuilt groups for the major roles in the organization so that when an employee joins or switches roles, you can modify his or her rights quickly and correctly.
Tie access controls to the environment—Some situations, such as accessing a VPN, call for two-factor authentication. In other instances, such as accessing an intranet site, you can put lighter controls in place.
Have a clear standard for decommissioning data storage devices—When decommissioning a storage device, which may include a hard drive, thumb drive, or digital camera, have a standard method to guarantee that data is removed from the device before disposal.
Every organization implements some type of access control on its information systems. In this section, you'll read about three real-world examples of how access controls are implemented on information systems. In this case study, you'll learn how an organization converted from a paper-based to a digital records system with granular access controls. In another, controlling file access locally and remotely is a key factor.
Access controls are not just important for large enterprises. Small- and medium-size businesses also benefit from the security and organization that implementing access controls can provide.
Diva Construction is a small mid-western construction company specializing in urban condos and building rehabilitations. In the late 1990s, it needed to upgrade its infrastructure. Diva's infrastructure consisted of a Windows desktop acting as file server, a few Windows workstations for the office staff, and a dozen laptops for the sales and field staff. The entire network was set up as a Windows workgroup, with the possibility of discretionary access controls, but only the accountant was implementing them.
There were a number of issues with Diva's original network environment. Its sales staff was commission-based, and there was some concern of customer poaching because a former employee had contacted customers belonging to other sales staff before he left. Diva management wanted to be able to access files from the field securely, and as the company grew management wanted to move to a computer-based HR system.
The initial plan for securing sensitive information in Diva's infrastructure was based on enforcing the current DAC system in place, with each user responsible for securing and granting access to his or her documents. This was quickly discarded as too intrusive because not all employees are computer savvy. Expecting them to handle all access control issues was not feasible. The other issue with the current environment was remote access. As it was currently set up, remote access was not possible.
Diva decided to add a Windows server to the environment and migrate from a Windows workgroup to an Active Directory domain. The company also upgraded the workstation acting as a file server to a Windows server. The new environment allowed for MAC to be set up, centralizing access controls. Groups based on user roles were created, including Accounting, HR, Support Staff, Sales, Management, and Construction. These groups were given space on the file server that only they and managers could access. Network shares were turned off on the workstations, and each user's documents directory was mapped to the file server with access limited to the owner and management. The Windows domain controller was also configured as a Remote Authentication Dial In User Service (RADIUS) server and had an ISDN modem, allowing users to connect from the field over cellular modems.
By implementing an LDAP environment using Windows Active Directory, Diva Construction was able to better secure its information, manage that information more efficiently, and enable remote access for its field employees.
Implementing information systems access controls are critical for public sector entities, large and small. Anglican Care is a small aged-care facility in New South Wales, Australia. The facility handled 80 patients utilizing paper records. To stay in compliance with health care regulations, the facility needed to convert to an electronic documentation system. Anglican Care could build the system from the ground up with information security in mind. The Australian government worked with Anglican Care to design and implement the system as a demonstration of the use of clinical IT in aged-care facilities.
Anglican Care's paper records stored personal, financial, and medical information on patients. Contact information for staff and visiting professionals, staff salaries, and other financial information were kept in paper records as well.
The electronic version of the system would replace the use of paper, and provide remote access to the health information system (HIS) stored on the server. One PC will be used by the manager, with a number of PCs available for the staff. Doctors and physical therapists can make use of mobile devices that connect to the network.
The access controls must be created for the various users of the system. The controls need to maintain at least the strictness of the current paper-based system, ideally by implementing a least-privileged scheme. To do this, it is necessary to first understand the sensitive data that is to be stored.
There are two basic kinds of data stored for each resident. The first is static data that is entered into the system when the resident is admitted. This includes personal information such as name, gender, religion, as well as medical insurance information and medical history. Emergency information is also included in this information such as allergies, blood group, primary doctor, and a contact person in case of emergencies. Currently this information is stored on a card-based system that makes the information available rapidly.
The second kind of information is used and updated in the day-to-day running of the facility. This includes the patient care plan and progress notes. Progress notes are used to update the care plan and medical records. In the current paper-based system, medical entries older than one year are archived and filed in a locked room. Recent medical entries are stored in locked filing cabinets in an accessible location controlled by the facilities manager.
To mimic the access levels in the paper system, an LDAP-based data store was created with following groups:
Manager—This group had the broadest range of access, with the ability to view most information on the system. This is also the only group with the rights to create new staff and residents, and the only group with rights to remove information. For most information, they have full control. The one exception is doctors' private notes, which they are denied access to. Any user accessing care plans is also logged, and these logs are reported to the manager group.
Health care workers—Members of the health care workers group can view care plans, add progress notes, and access all emergency information. This is achieved by giving them read rights to the care plans and append rights to the notes.
Doctors—Members of the doctors group have access to the medical information of the residents who are their patients. They can modify the medical information and care plans for their patients. Doctors have read, write, and modify privileges to their patients' medical information. Doctors can also create private notes on each of their patients. This information is not accessible to anyone but the doctor and the patient.
Patients—Patients have rights to read all of their medical records, including doctors' notes, but they cannot modify or remove the information.
Implementing these rights allows the facility to move to a paperless environment, while maintaining strict access control to sensitive HIS.
One of the major bottlenecks with any access control system is the provisioning and deprovisioning of users. This is especially daunting in large organizations. In the follow case study, you'll learn how Alabama Medicaid agency handled this issue.
User management at the agency was a manual decentralized process. The creation of a new user required manual entry into the help desk, HR, e-mail, mainframe, resource store, and data store. This was an intensive process that left a lot of room for manual error. User rights had to be audited and crosschecked on all of these various systems. Sometimes rights and roles were assigned incorrectly. De-provisioning of users was an even larger problem. With all of the different user areas sometimes usernames and rights were missed in the manual removal process. There were times when former employees still had e-mail access months or even years after leaving the agency.
User management was obviously a major problem for the agency. The process was very labor and cost intensive, and security was a major problem. Although no incidents had occurred yet from a user with incorrectly enhanced rights or a former user that had yet to be removed from the agency systems, it was only a matter of time.
To solve this issue the agency moved to centralized access controls and centralized user life cycle management. Now, user information can be entered in one location and propagated out to all of the various systems. This also simplifies the user's life, as he or she now has a single sign on. Once users log on to their workstations, they can automatically log on to any other system that they have rights to. By centralizing, rights can be modified easily and quickly. Rights audits only need to look at one location to make sure everyone has the privileges they need and no more.
Decommissioning of users is now a much quicker process. Users are disabled at a central location, and within a half hour, their accounts are suspended on all of the systems. This is a much more secure way of decommissioning users, as there is no longer a worry of missing an account on one of the multitude of systems that the agency has users logging into.
By utilizing single sign on, the agency was able to reduce workload of the IT department by removing the need to create separate user accounts on every system. This reduced the time it takes to manage users and closed major holes in access controls.
In this chapter, you read about how access controls are implemented in various operating systems, and how those security features are used to solve real-world challenges. The goal of any access control system in a server or network environment is to decide whether any given user can access data, and what they can do with it. To achieve this goal, operating systems implement a system of granular user rights. Users are bundled into groups to simplify rights management.
Access mask
Active Directory
Binary large objects (BLOBs)
Child objects
Data at rest (DAR)
Data in motion (DIM)
Delegated access rights
Discretionary access control list (DACL)
Domain administrator
Explicitly delegated rights
Forest
Implicitly delegated rights
Intrusion detection
Lightweight Directory Access Protocol (LDAP)
Linux Intrusion Detection System (LIDS)
Network Information Service (NIS)
NIS +
Organizational unit (OU)
Parent object
Port scan detector
Process control system (PCS)
Relational database (RDB)
Root
Sandbox
Super Administrator
Super user do (sudo)
System access control list (SACL)
UNIX
Data residing in a system's buffers is considered data at rest.
True
False
Data in motion is at higher risk than data at rest.
True
False
A(n) ________ is a list or collection of access control entities.
The three primary ACEs are access-denied, access-allowed, and________.
________ in a database are an example of an application with internal access controls.
Which operating system(s) implements the most granular access controls?
Linux
UNIX
Windows
A and B
In a Windows environment, what is an organizational unit?
A logical structure for organizing users, groups, and computers
A business unit
A group of related data
A logical structure for organizing firewall rules
A Windows domain administrator has full control over all the computers in the domain.
True
False
A Windows domain administrator is the top-level authority in a Windows environment.
True
False
In which operating systems is rwxr–xr–x an example of rights notation?________
What does the sudo command in UNIX allow systems administrators to do?
Log in as root.
Run any process as if they were logged in as another user.
Disable the root user.
Disable a user account.
The four rights on an NIS+ object are Read, Modify, Create, and________.
Why should an organization automate user creation? (Select two.)
To save time and effort for the IT staff
To allow individuals to manage their own user accounts
To accurately add, modify, or remove access rights
To minimize the need for a full IT staff