Defining the Teleworker Environment
Network Design Considerations
The basics of teleworker security apply to any type of design and center on protecting the teleworker PC first and then its communications to the central network.
Host Protections
The list of protections recommended for user systems from Chapter 13, "Edge Security Design," and Chapter 14, "Campus Security Design," all apply here; in addition, there are some security precautions that should be considered more essential than they might be in internal-only hosts. Here is the list of considerations for host PCs in teleworker environments:
- Reusable passwords Users will likely authenticate to their systems with usernames and passwords. Like any reusable passwords, mechanisms to encourage strong password selection (education, operating system [OS] options, audit) should be implemented.
- OS/application hardening Whether you use an internal software management system (larger networks) or require that users update using the built-in update mechanism in their operating systems, the first rule for teleworker systems is to keep them up-to-date. Often the level of network security controls available to them is significantly reduced, if they exist at all, making basic host hardening all the more critical.
- Host antivirus Host antivirus (AV) is an absolute requirement for all teleworker systems and should be kept up-to-date through some form of automatic update mechanism.
- Host firewall Host firewalls can optionally be deployed on teleworker systems, but keep in mind the concerns raised in Chapter 4,"Network Security Technologies," regarding their use. This should not be done as a substitution for host hardening. If properly configured, host firewalls can narrow the potential avenues of attack; just take care that you don't notify users with a pop-up message every time they are scanned (otherwise, they'll notify you with a support call).
- File system crypto Although file system crypto is still an optional component because of its relatively limited availability and the technology's relative immaturity, it should be considered required for certain classes of users. As discussed in Chapter 4, often there is really valuable data on users' portable computers in addition to an organization's servers. Users with particularly sensitive information (such as financial records, medical records, and so on) should consider this a requirement. Without file system crypto, it doesn't matter how good your password is for initial device authentication because attackers will be able to read the cleartext files off of your hard drive on stolen portable computers.
Network-Transit Protections
Under normal circumstances, the chances of an attacker gaining access to communications between two parties on the Internet is so small that it can almost be considered impossible. For example, your credit card numbers are in much more danger of attack by being stored on many different e-commerce sites than they are when sent from your PC to the server. Trying to access data in transit is like trying to photograph a running jaguar. It is much easier to wait for it to stop (though the results are less exciting).
All this changes, however, when the attacker is able to connect to the same network from which the traffic originates. This is exactly the case in airports, coffee shops, hotels, and other public broadband networks. Layer 2 (L2) attacks (discussed in Chapter 6, "General Design Considerations"), among others, create the opportunity for an attacker to gain access to the flow of data before it enters the labyrinth of connections that makes up the Internet. As a result, in addition to protecting the host connected to the network, some cryptographically secure mechanism should be used to protect the data in transit. For most organizations, this means IPsec VPNs as discussed in Chapter 10. For others, it can mean limited access through session layer crypto such as SSH or Secure Sockets Layer (SSL)/Transport Layer Security (TLS). In the designs that follow, this crypto can originate from the PC directly (in the case of the software design) or from a hardware VPN device (in the hardware design).