ITS 421 - Tactical Perimeter Defense

Chapter 8, Access Control for Information Systems

Objectives:

This lesson discusses uses and application of access controls in various environments. Objectives important to this lesson:

1. How access controls protect data and file systems
2. How access controls protect executables
   
3. Implementing access controls on Windows computers
4. Implementing access controls on UNIX computers
5. Implementing access controls on SCADA and process control systems

Concepts:

Chapter 8

Protecting Data and File Systems

This chapter starts out with some general concepts about data. The classic view is that data can be in one of two states: data at rest (DAR) or data in motion (DIM). The second concept is also called data in transit (DIT).

The text explains that data stored on a hard drive, a tape, a disc, or other medium is data at rest. Data in motion means data flowing across a network, or data being copied from one location to another. This becomes confusing when you think about carrying a disk or a memory stick from one location to another. Which state describes the data then? That's tricky. We are certainly moving a copy of the data, but that copy is vulnerable to physical theft, not electronic theft, which is what the text is worried about on page 158.

In fact, we should be concerned about several things:

• Data at Rest - People, companies, and organizations often sell their older equipment when they buy upgrades or replacements. If they do not remove the data at rest on those devices, they create the problems discussed on pages 157 and 158. Once a device like a hard drive is mounted in a new system, the access controls on its data in the old system are irrelevant. The storage devices and media we use, the backup devices and media we use, the temporary copies of files on workstations are all at risk of theft unless we have a reliable encryption system that requires authentication to view the data.
  
  
• Data in Motion - The text gives us the example of web pages being sent over the Internet as packets of data in motion. Data traveling across any network, such as a file being stored or copied, is also data in motion. It is different from the concept of putting a file on a memory stick and taking the stick somewhere. The electronic transfer of data across a network is typically something that a hacker lurking on that network can capture, copy, and use just as well as the owner of that data. Any rights that a user needs to access a file must be satisfied before the packets start to fly to their destination. Once they are in motion, no rights are needed. The text comforts us with the idea that packets can take multiple paths to reach a destination, so it is less likely that a hacker with a sniffer would be able to harvest all the pieces of a file. Maybe. Or maybe the hacker only has to be on a choke point that leads to the requester. Two ideas are proposed to fight this problem:
  • The text proposes that we should always be using encryption when transferring data, such as using the SSL and TLS protocols found in HTTPS transfers.
  • Also, using VPN encrypted tunneling more often would add security to any connection.
    
    
• The text backs up a step, to offer the idea that we should also use rules to protect data as an object, which is often done with Active Directory permissions. I have been assuming that we are doing this already, so it's nice to know we are on the same page with the authors. The text points out that we can use this feature with Application Layer firewalls and Web content filters.
  

Moving ahead on page 160, the text discusses control features for data at rest in file systems. The features it discusses are available in a Windows system through Active Directory. In a UNIX file system, they can be implemented through Portable Operating System Interface for UNIX (POSIX) or through Network File System version 4 (NFSv4).

• Access Control List (ACL) - The text makes a fairly simple idea complex by introducing an unnecessary label. Every object in a file system can have an access control list, which tells us two things. First, the list contains the names of entities that have permissions to the object. Second, it contains the specific permissions each of those entities has been granted. The right to edit an object's access control list is the right to add and remove entities (typically users) to and from this list. It also includes the right to edit each entity's permissions. The discussion on Wikipedia uses different words, telling us that an ACE is an Access Control Entry, which is just a line in the List. This is also the way it is explained by Microsoft, so I think we can assume the text has had a proofreading event that we should ignore. The Microsoft discussion tells us that there can be two kinds of ACLs.
• Discretionary Access Control List (DACL) - The DACL is like a composite of the access rights granted to an entity by the a personal entry in an object's ACL, by rights set on the object or its container by an administrator, or by rules set for the system. Microsoft tells us that these rights are all set separately, but we should remember that an entity's rights are always a combination of those granted and those inherited.
• System Access Control List (SACL) - The SACL is like an auditing version of the ACL. It is generated by the file system, and does not contain entries unless auditing rules have been set for the object in question.

Page 162 takes us to access controls for executables. Executables are files, so it should not be a surprise that they can have ACLs. There can also be internal permissions granted to data and to functions within applications, but the concept of an ACL is most easily displayed by two facts. An executable may be granted rights to particular files and folders that it must manipulate. Also, users must be granted permission to execute an executable, or they cannot use it.

The text touches on another aspect of rights that are granted to entities on page 162.

• Explicitly delegated rights - This occurs when rights are granted directly to a user, a system, or another entity that can receive them.
• Implicitly delegated rights - This occurs when rights are granted to a container object, such as a folder or a group object, that can be considered the parent of the objects it contains. The child objects receive rights implicitly.
  

The text moves on to discuss the file permissions found in Window systems and those found in UNIX and Linux systems.

Windows

The list of commonly available basic access rights in a Windows file system appears on page 163.

Advanced rights appear on page 164, and the text discusses applying rights on the next two pages.

All rights are authorized by default to three ID concepts on Windows systems.

• domain administrator - This is a default group in Windows domains. Members have full control to all computers, and all parts of their file systems unless the group has explicitly been denied permissions to some part.
• enterprise administrators - This group has full control over all domains in a Windows forest.
• Super Administrator - This is an account that exists but must be activated to be used. The text does not mention whether this account exists in Windows 10. The screen shot below was taken on my Windows 10 computer, showing that it does. As the text mentions, the command to activate this account must be run "as administrator".
  
  
  

UNIX and Linux

UNIX files (and directories) have three basic permissions assigned to them. That's usually all you get, and by the way there is no inheritance:

• read - you can see what is in a file
• write - you can change what is in a file
• execute - you can run a file, if it contains commands
  

UNIX also divides the world into three categories, with regard to files. First, you should know that users on a UNIX system are classified as belonging to groups. A user on the system must fall into one of three categories with respect to any particular file:

• user - person who owns the file, and probably wrote it
• group - people in the same group as the user who owns it
• other - everybody else in the universe

Think of permissions as being in three groups of three when seen on a list of files. A file's permissions might look like this:

-rwxr-xr--

The first hyphen means this is a file, not a directory (folder). Ignore that hyphen. The rest of the string is three sets of three letters (or hyphens).

• The first set is for the User (owner), and rwx means he/she can read, write and execute that file.
• The second set of three is for the Group the User belongs to. The combination r-x would means they can read it and execute it, but not write to it (the w is missing).
• The third set is for anybody else wandering across this file in the system. They have r-- in this example. That means they can read the file but not write to it or execute it (unless they know a trick to do it anyway.)

There are several ways to set or change the permissions assigned to a file. Only the owner, a system administrator, a superuser, or a semi-talented hacker can do so. I usually use the chmod command with the decimal equivalents of those nine positions turned on or off in binary. You summarize the permissions down to three digits. Each digit represents the rights you grant one category above. Use this chart to decide what number to give each kind of person:

0 - no rights (000 in binary)
1- execute only (001 in binary)
2 - write only (010 in binary)
3 - write and execute (011 in binary)
4 - read only (100 in binary)
5 - read and execute (101 in binary)
6 - read and write (110 in binary)
7 - all three: read, write and execute (111 in binary)

Issue the command like this:

chmod 751 filename

This sets the owner's permissions to full (7=111), the group's permissions to read and execute (5=101), and common people's rights to execute only (1=001). You might want to do this to protect shell scripts you write, while still allowing all people to run them.

The text mentions two special cases in UNIX and Linux. As seems to be a habit in this text, the features are discussed in the wrong order. Let's fix that:

• Root - Root is a user ID on these systems that has all permissions to all objects. It is recommended never to sign on as this ID, due to the potential damage you could potentially do to the system. The text mentions that there is another way to run a command with root permissions. Precede the command with sudo, which either stands for substitute user do, or superuser do, which means to do run the command that follows as a superuser.
• Linux Intrusion Detection System (LIDS) - This is a patch that can be applied to Linux which includes a port scanner, an extension to the file system permissions, and inheritance. LIDS adds deny and append to the file system permissions. The real purpose of LIDS is to monitor activity, particularly root activity, but the file system changes are useful.

The last concepts to cover in this chapter are Supervisory Control and Data Acquisition (SCADA) and Process Control Systems (PCS) . As usual, they define their second term first. We are told that a Process Control System is like the feedback loop between a thermostat and a furnace. In this example, it is meant to control the process of maintaining the temperature in a room. It measures the output of the system, and runs it as needed to reach and stay in the range of desired output. As you can see, this kind of control system takes a setting from an operator, but runs automatically once it is set,

A SCADA system is a large PCS. Examples are the systems that monitor and control the flow of power and water to customers. Systems that adjust traffic lights to accommodate changing traffic flow during a day are also examples. You may see that this kind of system is used to make social infrastructure work, making it a target for politically motivated hackers. The text does not explain this concept well, so take a trip to this article from TechNewsWorld. It should be clear that the access controls for these systems must be very secure, and that they must be limited to only the people meant to access them.