Internal Security: Rules and Risks
By Paul Sholtz
On February 4, 2001, antiglobalization activists mailed a CD-ROM to a Swiss newspaper that listed the names of 27,000 attendees of the 2001 World Economic Forum in Davos, Switzerland. It also held 1400 credit card numbers, as well as spreadsheets detailing travel schedules, hotel accommodations, session payments, and Web passwords for 3200 participants. Among those mentioned were Bill Gates, former Yahoo CEO Tim Koogle, Madeleine Albright, and Israeli foreign minister Shimon Peres. In all, over 161MB of personally identifying information was burned onto the CD-ROM--all of it stolen from the Forum's Web site and intranet.
While your company may not need to protect the personal information of the most powerful people on the planet, you should be no less concerned about keeping sensitive information private. Your intranet holds employee records, customer and partner data, financial information, and proprietary engineering documents; and it's your responsibility to protect it all. Even having a basic security policy combined with the right set of tools and technologies can substantially reduce the risk of a serious security incident occurring on your watch.
Risk Management for the Intranet
Intranet security involves an ongoing process of assessing and managing the risks that face your information systems. To be effective, your security strategy should incorporate the needs of employees and partners, and define the policy and technology you'll use. While your intranet can never be completely secure against all threats, there are several steps you can take to substantially reduce the risks.
Your intranet security strategy should start with a comprehensive risk assessment. A solid risk assessment plan includes the following:
- identifying the threats that face your organization;
- estimating the likelihood of each threat occurring;
- ranking the values of at-risk business operations;
- estimating the potential losses arising from threats;
- identifying cost-effective measures to mitigate the risk.
Once you've quantified all of the risks that face your intranet, the next step is to define your security policy.
This policy should clearly define the rights and responsibilities of system users and outline sanctions for policy violation. It can also guide purchasing decisions at your organization because it defines standard classes of protection for various pieces of computer hardware and software.
An important, and often overlooked, step in defining security policy is to create an incident response action plan. A good policy defines preventive measures to reduce threats, but it's also important to have an incident response plan outlining how to react to threats as or after they occur. When there's a security breach, your company needs to be able to respond in real time. Do your employees know that they shouldn't open an email attachment with a .vbs or .exe file extension? How do you plan to respond to a denial of service (DoS) attack when one occurs?
Other important phases of the risk management cycle include implementing your security policy, promoting awareness among your employees, and measuring the policy's effectiveness, as illustrated in
Access Control and Permissions
After completing a risk assessment and crafting a security policy, it's time to put your plans into action. First you must ensure the appropriate people have access to the information and resources they're authorized to use, and nothing more. This means identifying and authenticating intranet users, and having the right tools to manage access control.
User authentication is the first step in controlling access to sensitive information. Only after a computer system identifies you can it decide what you are allowed to do, and what you aren't allowed to do. To prove your identity to a computer system, you must supply it with a set of credentials. There are three broad types of credentials you can employ to verify a user's identity to a computer system:
- something only the user knows (for example, a password),
- something only the user should have (for example, a smart card or some other physical token),
- something only the user could have (for example, DNA).
A strong system of authentication, like that used in ATM cash machines, attempts to verify credentials from at least two of these categories; highly secure systems, like those used in the military, authenticate users based on all three. The more types of credentials a system requires, the more trust you can place in its authentication abilities.
The amount of control the user has over the credentials also makes a difference in overall system security. If a system is designed so that credentials can be supplied at the user's discretion, it's said to employ discretionary access control (DAC). One example is the standard username and password system commonly used to authenticate HTTP sessions. Apache ships with a module called
mod_auththat lets you configure DAC by defining the location of a credentials database, as well as offering instructions on how to use this information (see "Configuringmod_authin Apache"). The credentials database is specified in theAuthUserFiledirective and points to a .htpasswd file in the directory to which you may wish to restrict access. Apache's Require directive sets up a simple access control list (ACL), telling the server which users have access rights to which directories.
One weakness of DAC is that any valid username and password combination will give you access to protected areas of the system. If you enter a correct combination that doesn't belong to you, there's no way the system can tell you apart from the legitimate owner. Mandatory access control (MAC) creates a higher level of system security by requiring credentials over which the user has no direct control. For instance, a MAC system may attempt to verify some biometric, like a fingerprint. Thus, MAC systems are sometimes called nondiscretionary systems (see the glossary for similar terms.)
Simpler credentials, such as IP addresses, may be used for intranet applications as long as they're difficult for the end user to control directly. Apache includes a module called mod_access for limiting access to Web pages by IP address or Internet domain (see "Configuring
mod_accessin Apache"). This is useful if you want to let only hosts located inside your trusted network perimeter access information. For example, you could use this to limit access to those accessing through your company's network or chosen remote access provider. Whenever possible, you should configure mod_access to use IP addresses instead of domain names, because it keeps Apache from getting bogged down with slow DNS lookups.
Apache handles error conditions resulting from failed DAC and MAC attempts in different ways. When DAC authentication fails, Apache generates an "HTTP 401 Unauthorized" error, and gives the user another chance to re-enter his or her credentials. When MAC authentication fails, Apache generates an "HTTP 403 Forbidden" error. Unless an administrator updates the MAC access control policy (ACL), the user will remain locked out no matter how many times afterward he or she correctly enters the proper (discretionary) credentials.
If you use usernames and passwords to restrict access to your intranet, it's important to understand the difference between the two main forms of HTTP authentication: basic and digest. Basic authentication transmits unencrypted usernames and passwords and provides no real security. This is probably all right if the passwords aren't traveling outside of your trusted network, but in most other cases you'll want digest authentication. Digest authentication uses a sophisticated hashing algorithm called MD5 to obfuscate user credentials before they're sent from client to server. You can configure Apache to use either authentication method by using the AuthType directive in the http.conf file.
Connecting to Other Networks
If you're connecting your intranet to other networks or the public Internet, an effective firewall is an important part of access control. Firewalls act as border security devices that let you locate all of your external security services on optimized and dedicated hardware. Without border security, every computing device attached to your intranet would have to perform firewall services individually, needlessly wasting resources and complicating the process of data transfer across the LAN.
The simplest function performed by a firewall is packet filtering. Packet filters decide whether to forward individual TCP/IP packets based on information contained in the packet header and on filtering rules set by the network administrator. Most packet filters can be configured to screen information based on the following data fields: protocol type, IP address, TCP/UDP port, and source routing information.
Modern firewalls further improve packet filters by adding a feature called stateful packet inspection. Stateful packet filters can record session-specific information about the network connection, including which ports are in use at the client and server. This is important because, although most Internet services run on well-known ports, Internet clients may be using any port above 1024. A stateless packet filter must let Web servers respond to browsers at one of these high port numbers, but it can't tell which one, so it leaves them all open. Stateful packet filters, on the other hand, make intelligent decisions about which ports to open for return communications and which to keep shut. Stateful packet inspection also enhances security by allowing the filter to distinguish on which side of the firewall a connection was initiated.
Another powerful security feature offered by most firewalls is network address translation. NAT lets you hide the IP addresses of your intranet's hosts from the external world, making it a powerful technique for masking the structure of your intranet from prying eyes. It does this by converting the private IP addresses on your intranet into unique IP addresses for use on the Internet. To perform NAT, a firewall maintains a list of internal sockets and matching external sockets. When an intranet client attempts to establish a connection with an external host, the firewall mates the internal socket with one of its external sockets. The same process, working in reverse, lets external hosts send data back to intranet hosts without knowing the actual IP address of the internal host.
NAT is also a useful technique for conserving IP addresses. Many small businesses get only 8 or 16 IP addresses from their ISP, the number of hosts on the intranet can rapidly exceed that number. Using NAT, only the border devices at the perimeter of your network need to expose legal IP addresses. Internal hosts can be assigned nonroutable IP addresses to conserve the number of legal ones.
Firewalls are important for securing the border of your trusted network, but don't let your firewall lull you into a false sense of security. Many firewalls are preconfigured to accept all traffic from ports above 1024. For maximum security, configure your firewall to deny all ports by default. Open only those ports that are mandated by your business requirements: port 80 for Web serving, port 21 for file transfer, and so on. Also make sure that the host operating system is secured. Many firewalls can be administered remotely by telnet. You don't want to leave any holes open in your system that would let a cracker telnet into your firewall and reconfigure it.
Security Beyond the Firewall
As you expand your enterprise, it may become necessary to link your intranet across multiple geographic locations. You may need to provide site-to-site intranet connectivity for corporate offices located in different parts of the country, or you might want to open up remote access for telecommuters. In any case, as soon as you begin transmitting sensitive corporate data outside the perimeter of your trusted network, encryption becomes an important factor. Using encryption and virtual private networks (VPNs) you can expand your intranet safely and securely to remote hosts and networks.
Encryption is a delicate issue. On the one hand, it can be used to provide data confidentiality, with integrity and authenticity. However, firewalls, antivirus software, or any other type of border security device can't scan encrypted traffic. Therefore, many enterprise sys admins are reluctant to let encrypted data reach users' desktops. A virus hidden inside an encrypted message could easily become a serious problem. Nevertheless, businesses need a way to encrypt data sent out across the public Internet.
One solution is to stop encryption at the firewall. Most major firewall vendors now include VPN support in their products to make this easier. VPNs use cryptography to create a virtual tunnel over public networks that can link private enterprise networks together securely. The functionality provided by VPNs includes:
- IP Encapsulation. Occurs when one IP packet contains another IP packet as its payload. VPNs use IP encapsulation to address hosts in remote networks when a routed connection between two networks doesn't exist.
- Cryptographic Authentication. This is a process by which the VPN authenticates users and devices to decide at which level they may be allowed to participate in the encrypted tunnel.
- Data Payload Encryption. This obfuscates the contents of each IP packet to prevent eavesdropping.
If you're ready to buy VPN equipment, look for vendors who offer IP Security Protocol (IPSec)-compliant solutions. IPSec is a relatively new protocol designed to build much of the security infrastructure required by VPNs directly in the network layer of TCP/IP. IPSec is part of the new Internet Protocol version 6 (IPv6), but many current IPv4 devices support it as well. Be sure to ask about potential incompatibilities between IPSec and NAT, because this may be an issue for some vendors. However, most of the problems with IPSec are being addressed quickly.
Rounding Out the Risk Management Cycle
Information security has evolved from a simple technical issue into an overall business concern. I have covered some basic technologies you should consider to reduce the chance of a security breach occurring on your intranet. Remember, however, that security is an all-encompassing process. Being able to detect and respond to threats is just as important as the measures you take to prevent attacks. Without increasing employee awareness about security and measuring the effectiveness of the controls you install, the job of securing your intranet will only be half done.
Paul is the cofounder and CTO of PrivacyRight, a San Mateo, CA developer of enterprise privacy products. Contact him at [email protected].
