ITS 3250 - Securing Systems

Security Strategies in Windows...
Chapters 3 and 4

This lesson presents an introduction to Windows access controls and encryption. Objectives important to this lesson:

  1. Principle of least privilege
  2. Access models
  3. Objects and access control
  4. Calculating permissions, auditing, and management tools

  5. Encryption methods
  6. BitLocker
  7. File-, Folder-, and Volume-Encryption
  8. Communication encryption
  9. Encryption protocols
  10. Security Certificates and PKI
Chapter 3

The chapter opens with a recommendation to use a five step method with your controls that is a lot like the software development life cycle.

  • think
  • plan
  • design
  • implement
  • evaluate

It is a cycle because you should always review permissions, after they have been used, after a job change, after a significant amount of time, and during any problem with them.

The principle of least privilege is the golden rule for granting access to assets. Not every asset in your organization is sensitive, classified, secret, or otherwise private in some way. If they all were, you'd have nothing to put on your public facing web site. Enough assets are meant to be private from most users, even your own network users, that the principle of least privilege says grant enough access so an employee can do his/her job, but don't grant more access than is needed. "Just enough" is the general idea. As the text states, it is easier to give all users full access to everything. Easier, but not better. Least privilege assures that we have done the first thing we should do to "limit the damage that can result from accident, error, or unauthorized use." (See page 109 in this text.)

Although there is no actual object that is called this, the text tells us that we can create user accounts with this principle in mind. If we do, we are creating least privilege user accounts. It recommends that we should manage access rights by assigning them to user groups that represent job roles, then adding and removing user accounts from these groups as necessary. On page 43, we see six groups that are created by default in Windows Server 2008 and 2012. These are not the only ones you will ever need, but they illustrate the concept.

On page 43, the text discusses granting permissions to an object in Windows, which means adding user names or group names to the Access Control List of that object. The text mentions that ACLs in Windows are discretionary access controls, so they are also called DACLs (see notes for Chapter 2). This also means that users who are granted this kind of access may be able to grant that access to other users.

On page 44, the text begins a discussion about logging in to a system. You are probably familiar with the first two steps. (The text lists them as one.)

  1. Windows asks the user to identify with a user ID.
  2. Windows asks the user to authenticate with a current password.

That's all most users know about the situation. The next steps are not visible to the user:

  1. The provided ID and password are examined encrypted (the text skips this part), and passed to an OS utility that compares them to trusted data. If there is a match, the authentication is successful.
  2. The OS creates a Security Access Token (SAT) for the user. It includes the user's security identifier (SID, which is a numeric string assigned to the user name), and the SID for each group the user is assigned to. This SAT is used to verify authorization for all processes the user attempts to run.

Page 46 introduces some features in Windows Server 2012 under a product label called Dynamic Access Control.

  • Identify and classify data - data can be tagged either automatically or manually to tell Windows which security method to use for it
  • Control file access - access policies can be set for an organization to control access by data type
  • Audit file access - audit trails can be initiated by central policies
  • Apply encryption to sensitive documents - Rights Management Services (RMS) can apply encryption to files tagged as having sensitive data

UAC credential promptUser account control (UAC) is a feature explained on pages 46 and 47. It is illustrated on page 47 as being when Windows asks the user for elevated credentials when a requested action requires more permissions than the current account has.

The text tells us that this feature can make use of the special SATs that are created for members of the Administrators group. They have normal user rights and permissions until they confirm that the action they are performing is to be performed with more rights. This feature, in fact, appears to all users on a system equipped with it, when users request an action requiring more than standard permissions.

The text continues its UAC discussion, telling us that we can choose one of four comfort levels, each of which is a bit different from the others. In actual practice, you can leave it turned on, or turn it off. The settings in between don't offer much protection, and neither does turning it off, so the default choice is to let it run normally so it can warn you when a program that has no business making changes is about to do so. The catch is that the user has to recognize that event, and choose not to allow it to happen.

In the case of a network that uses Active Directory (and what networks don't?), SID information has to be passed across the network in order to create SATs for users. When this is done, one of two security protocols will be used. The default protocol in networks running Windows 2000 or later is Kerberos. In older networks, it may be Network Translation LAN Manager (NTLM) also called Windows Challenge/Response. NTLM is no longer recommended.

The text further discusses DACLs, telling us that they must exist for Windows to control access to objects, and the access control rules in them are called Access Control Entries (ACEs). On page 53, we see a chart defining the six basic permission levels that can be granted to a user or group in an ACE. This article from Microsoft offers some other insights.

  • full control - all rights, no limitations
  • modify - all user to modify files and folders, but the user cannot delete, change permissions, or change ownership of those objects
  • read & execute - user can read the file system tree, execute files, read folder contents, read data
  • read - list contents of folders, read files
  • write - create files and folders, write data, includes read
  • special permissions - this is a flag that means some settings have been made on the object's advanced permissions screen; note that a setting on the advanced screen allows you to block inheritance of ACEs from the parent of the object in question.

The text has used the SID term quite a bit. It reminds us that they can have a local scope: if an object is created simply in the OS of a given computer, that object and the associated SID are local, they are unique only on that machine. If the object is created as a domain object, it and its associated SID are unique in that domain.

Extending the concept to the next level, Microsoft has created the globally unique identifier (GUID). This is a system whose intent is that all objects can be given identifiers that are unique regardless of who creates the numbers for them. That sounds awfully like promises we have seen fall apart before (e.g. IPv4 addresses), but they start out meaning well. A GUID is 32 hexadecimal characters, broken into groups of 8, 4, 4, 4, and 12. That's a lot of complexity. The text tells us that Windows uses GUIDs in its registry, in which they are called Class Identifiers, whose acronym is horrible: CLSID. Looks like a bad word in biology class. To illustrate the concept, the text gives us a toy on page 56. It asks us to click the Start button in Windows, choose Run, then enter one of the CLSIDs it offers to start a specific process. For instance, the string ::{20d04fe0-3aea-1069-a2d8-08002b30309d} is supposed to open My Computer. I tried it in Windows 10, it opened Windows Explorer, and put the focus on This PC, which is the equivalent object in Windows 10. This proves the claim on page 57 that the CLSID of an object can be used even if its name changes, as I just told you it did. We can take comfort in the fact that we still need proper permissions to execute a process or view an object, that calling it by its CLSID is not a back door that ignores rights and permissions.

The text discusses an issue that may have occurred to you: what happens if there are multiple DACLs and ACEs that contain conflicting allow and deny rules for the same object? We are given three rules to resolve such problems:

  1. If no DACL or ACE applies to a requested access, the access is allowed.
  2. If only one ACE exists that applies to the requested access, it is applied, whether it is to allow or deny access.
  3. If there are multiple ACEs that apply to the requested access, and any of them is a denial, the request is denied.

Auditing is discussed on page 58. We are told that there can be a need to review requested access, allowed access, and denied access. The illustration on page 59 shows us one computer's local audit policy. Note that there are nine categories of events in that policy. Only two are enabled:

  • Audit login events - the policy is configured to log Failure events of this type
  • Audit object access - the policy is configured to log Success and Failure events of this type

Each category of event can be set to audit Success, Failure, both, or not to audit at all. There is a tip on page 60 about starting the Event (log) Viewer. Note that in Windows 10, you look for Start, Windows Administrative Tools, Event Viewer. On the same page, we are shown two more elaborate auditing policies that apply to Windows Server 2012. In each case, a specific kind of user will be logged when attempting an access that they have no business need for.

The chapter ends with a discussion of three access management tools, each of which works from a command line:

  • Cacls.exe - used to list or modify DACLS for one or more files or folders
  • Icacls.exe - used to list, update, and make a backup of ACLs for files or folders
  • Robocopy.exe - short for robust copy, this one can copy files and folders, along with their ACLs
Chapter 4

This chapter begins with the horrifying realization that everything we learned in chapter 3 is pointless if an attacker does not have to use Windows to access the files and data we are trying to protect. For instance, the attacker may boot a device from a memory stick that loads a small version of Linux, making all the Windows defense irrelevant. In an aside, the text notes that the attacker's OS needs to be able to read the file structure of the hard drive in question, but that is quite possible.

This leads us to an example of defense in depth. Assume we have set access permissions, but we are afraid that our sensitive data will be exploited by a Linux expert. The text reminds us that the memory stick/CD/DVD attack usually requires physical access to a targeted computer. So, put a lock on the door to the server room (or your office) and use it. Assuming that measure may be defeated as well, the text starts discussing encryption.

The text glosses over a distinction we need to make. Different encryption methods are used depending on the state of the data. Two states are important:

  • data at rest - this is data that is stored on a hard drive, a memory stick, a solid state drive, or any other kind of long term storage
  • data in transit - this is data that is either passing from one device to another across a public medium like the Internet, or data that is passing from one device to another on private network

The text discusses several methods that can be used in each of those states. Note that none of the methods discussed cannot be used in both states.

Methods for data at rest:

  • Encrypting File System (EFS) - This is a feature included with Windowws since Windows 2000. It requires that the NT File System (NTFS) be used. It allows a user to turn on encryption for individual files and folders. The key used to encrypt data (the FEK) is based on the password of the user who turns on encryption.

    Since it can be turned on by a user, the text tells us that doing it that way makes the selected data available only to that user. The image on the right is from an article on EFS on Wikipedia. That article has a lot more detail than the discussion in the text, including more problems with it, such as the fact that if the user who encrypted files copies them to a medium that is not using NTFS, the copies of those files will no longer be encrypted.

    In the image on the right, the lower portion shows how files might be shared with others by sending them an encrypted copy of the FEK, encrypted by the user with a public key system, which would allow a recipient to decrypt the FEK, then use it to decrypt the data file itself.

  • It may be useful to know that I have never had this method proposed to me for use in my day job.
  • BitLocker - I have used and continue to use BitLocker on a daily basis. The idea behind BitLocker is that you encrypt an entire hard drive (a volume) with it. Computers typically have one drive from which the computer boots. That is the drive that would be encrypted. When the computer with the encrypted drive is booted, a password for BitLocker is requested. On my computer, I have one minute to enter it correctly. If the correct password is not entered, the machine will not boot into Windows.

    This feature is most useful for devices like laptops that have a risk of being stolen. Its biggest attraction is that there is no way to read the data on that drive unless you know the BitLocker password. If you forget it, you can get help from staff with administrative rights to unlock access to the hard drive, once you prove you have a right to ask for that. If the laptop is lost or stolen, the thief is very unlikely to gain anything from the information stored on that system. Recently, my daytime employer has extended the BitLocker policy to cover all Windows computers, laptops and tower units alike. We also use a policy that requires BitLocker encryption to be used on any USB storage device that is attached to one of our computers, unless we are only going to read from that device. Attempting to copy to or write to an unencrypted USB device will result in an error message.
  • BitLocker To Go - This is a "portable" version of BitLocker that applies to removable media. For instance, if I encrypt a memory stick with BitLocker, that memory stick can only be read by on computer (or another Windows computer) if the person trying to read it knows the BitLocker password for that memory stick. Once entered, the current user has read/write access to the memory stick, if their computer is running Windows 7 or later.

    Okay, so that works for computers running Windows 7 and later. If the user is running Windows XP, the user is prompted to run BitLocker To Go Reader, which is a program that is stored in an unencrypted folder on the portable medium. The user still has to enter the BitLocker password for the memory stick, and in this case the user will only have read access to it.

On pages 78 to 82, the text discusses the method to engage each of the three services listed above. You should review the steps to do so.

On page 83, the text begins a section about encryption of data in motion. Its heading is Encryption in Communication. The difference about data in transit is that there is a transmission across a medium from one device to another, such as a transmission across a network, or across a communication medium.

  • SSL/TLS - The text tells us that Secure Sockets Layer protocol is the old name for Transport Layer Security protocol. It provides an encrypted channel between web servers and web browsers. This article on Wikipedia is a good bit longer and more detailed than the one in the text. It tells us that the two protocols are different, which is easy to believe, given the number of revisions TLS has gone through. Note that the encryption takes place with a symmetric key, meaning that each party in the data transfer uses the same key as the other. Identities may be verified with public key cryptography, but it is usually only the server that does this.
  • Virtual Private Network (VPN) - A VPN is a an encrypted channel that typically passes across a public, unencrypted network, such as the Internet. The VPN method is commonly used for remote users and travelers to connect to their usual resources on their regular organization's network. The network that the remote user wishes to connect to must support the use of a VPN, else the connection cannot be made.
    The text lists several protocols that may be used with VPN connections: Internet Protocol Security (IPSec), which is used with Layer 2 Tunneling Protocol (L2TP), and Point-to-Point Tunneling Protocol (PPTP). The text mentions that Secure Socket Tunneling Protocol (SSTP) runs over SSL/TLS connections, and it requires less firewall configuration that the other protocols to work.
  • Wireless Security - The bottom line is this: don't use old protocols. Older wireless network equipment was configured to use Wireless Equivalent Privacy protocol (WEP), which is no longer considered to be secure. It was superseded by Wi-fi Protected Access (WPA), which was superseded by WPA2, and by more refined versions after that. The text tells you not to transmit business data over public, unencrypted access points, such as you find in most restaurants. My day employer has a security policy against doing so. It is simply a bad idea because the risks are too great.

The text moves on to discuss a few basic security principles, starting on page 87. Encryption systems typically use one of two approaches:

  • symmetric - In any connection between two users, they will both use the same key to encrypt and decrypt data. This is a good system except for two problems. First, since only one key is being used, an eavesdropper who has stolen that key can read the data flowing in both directions. Second, we have to figure out a secure method to deliver that key to both users in the connected session. Symmetric systems typically run faster than asymmetric systems, so they are preferred for large transmissions. Sometimes, the symmetric key is transmitted to the users by encrypting it in an asymmetric system.
  • asymmetric - An asymmetric system typically works like the system called public key cryptography. An entity, whether a person or company, must have two keys in this system: a public key and a private key. They are created so that whatever is encrypted with one must be decrypted with the other. The owner of the keys gives the public key to anyone who wants it, but keeps the private key safe from everyone. This is how SSL encryption on a web site works. I connect to a vendor's web site. I obtain the vendor's public key by making the secure connection. My browser encrypts my credit card data with the vendor's public key and sends the ciphertext to the vendor. If the vendor's private key is secure, the vendor is the only one who can decrypt the data sent through the public key. Each entity keeps their private key locked away, private and secret.

    The text warns us that an impostor who seems to be a real, recognized entity (such as a store or a security vendor) can run a scam on users by providing the user with their own public key, allowing the user to set up a private session with the impostor. This is why a system of respected certificate authorities (CAs) has been created. If I connect to Amazon, I may not actually receive Amazon's public key directly from them. I may receive it from a trusted source like Comodo, Symantec, or Verisign, entities who are in the business of providing a user with a valid security certificate for a requested vendor. Security certificate? That's a short document that includes a copy of an entity's public key, along with a promise that it is the actual key belonging to the entity named in the certificate. It's a bit like ordering an official transcript from your school to be sent directly to a potential employer. The employer trusts that the school would not falsify the document, and would take care to make it accurate. A Certificate Authority, likewise, has an obligation to provide only a true copy of what has been requested.

    A company can run its own certificate server, and can provide its own certificates to users making a request for it. This may be a better choice for entities who have an infrequent need to provide certificates.


Assignments for these chapters will be found in Canvas. We will explore that in class.