10 Intranet Security Pitfalls and How to Avoid Them
Niku Corporation (Redwood City, Calif.), a developer of commercial exchange software uncovered security violations - another company seemed to be aware of its confidential plans. The company verified the problem and sought legal relief. The company obtained a temporary restraining order against Business Engine (San Francisco, Calif.) in August 2002. Unfortunately, this type of problem is not discussed in the media. Security is among the top concerns of information technology professionals. Security is even more pivotal when companies selling security experience security violations!
Intranets are networks made available to employees or to contractors to an organization. Most people assume that Intranets are more secure than public networks such as the Internet. Any network is vulnerable, even internal networks operated by companies who sell secure online transaction systems. The Niku-Business Engine example underscores this fact.
In the course of our work at commercial and governmental clients, we have seen many examples of excellent security systems. However, even the best security system can erode over time if security procedures are not followed and modified. Technology, people, and the policies associated with certain information change over time.
We have extracted 10 security pitfalls that we have identified from various engagements. No one organization suffers from all of these; however, even the organization with a clean bill of health from their security consultant may find this checklist useful.
The checklist makes three assumptions. First, the reader's organization has a security policy. A security policy is a statement of procedures and requirements. A typical policy decision is to state what software applications are supported; for example, the Internet Explorer browser and the specific security settings selected in Tools > Internet Options > Advanced.
Second, the organization has an Intranet that allows or denies certain users access to specific software, data, and services available on the network. A good example is a table that allows the security officer or system administrator to allow the director of personnel and finance to access salary information. All other employees are not given access to these data.
Third, the organization permits some type of Internet access and use of electronic mail. Networks that allow a user to navigate to data located outside the organization are subject to somewhat different levels of risk that users who have access only to data located on a single application on an internal network. Electronic mail is a security challenge and requires that Intranet security be in place and that other measures are taken as well; for example, setting e-mail clients so previews of messages are not displayed unless the recipient specifically activates the message display. Many common viruses which exploit unpatched systems are transmitted by the victim merely looking at the contents of an e-mail.
If your organization does not have these three foundation stones in place, the prudent reader will make completing these tasks a high priority.
One difference between the Internet and an Intranet is that work-related trust relationships exist between systems and individuals. In an Intranet, privacy and data integrity are particularly important. Intranet e-mail and data files may be more vulnerable to some type of compromise. The three goals of security are confidentiality, integrity and availability. Intranet security must deliver integrity and availability. Intranets exist to make information available to colleagues. Nevertheless, confidentiality is an issue. Each job function and person holding that job is given a level of access appropriate to his or her role. Intranets are often less secure than information technology professionals and managers realize.
The security for the Intranet often focuses on information, content control, and access security. The operating system and network devices must be given equally attention. It comes as a surprise to many managers, that an Intranet raises more issues dealing with browser-related security and access to information on certain machines or of a certain type.
Anyone probing an organization's security quickly discovers that when the Intranet connects to the Internet, additional security issues surface. These include users inadvertently allowing a virus to infect the Intranet to hackers who obtain access to data that the organization views as proprietary. Wireless access adds yet another level of complexity. System administrators must treat each wireless access point with the same care given a network server.
Regardless of security policies and the security procedures implemented at any organization, an Intranet system is only as secure as the people with access to the system. The most sophisticated security system can be compromised by the actions of a single individual. Good security, therefore, begins with the staff.
An Intranet security strategy begins with a risk assessment, including:
A security policy converts the security strategy into a set of procedures and information. These data are used to configure the system and maintain the appropriate level of security. A security policy defines the rights and responsibilities of system users. Some policies state the steps an organization will take when a security breach occurs. A security policy may also define standard classes of protection for various pieces of computer hardware and software.
Here are the ten pitfalls we have encountered. Each includes a suggested step to take if a pitfall exists in the reader's organization:
1. Encryption. Secure server / client software is now available. Have such encryption and authentication options as Secure Socket Layers, Secure HTTP, or proprietary solutions from third-party providers such as IBM been implemented? Encrypting Intranet traffic for user name and passwords is a minimum. Other traffic can be encrypted as required in the security policy. Authenticated log on to the Intranet is a first line of Intranet security. All or parts of the Intranet can be protected using encryption and authentication.
Action to take: convert all log on and authentication functions to Kerberos, NTLM, SSL, or equivalents.
2. Access control. Are the server or servers protected by both hardware and software defenses. Is access to the Intranet sites limited to internal locations? Is secured remote access made available? Are access controls tied to job function, specific employees, and specific content? This means that the manager of Department A has access via a specific mechanism to certain information specified in the access control table.
Action to take: make certain that the information in the security policy has been communicated to appropriate individuals. Verify that access controls are in place as part of the security audit, item 10 below.
3. Passwords. Are employees required to change their passwords on a cycle; for example, every 60 days or more frequently? Is this process automated and enforced? A bad password is the name fred, a pet's name, or a single character such as d. A good password is a combination of letters and keyboard symbols; for example, h@pp7bo$car.
Action to take : enforce password changes, length, and a combination of letters and keyboard symbols. (Make certain users do not tape user names and passwords to their keyboard or laptop.)
4. Content publishing and management. Who is responsible for making changes to marketing-related Web pages? Who has the responsibility-often called ownership-of deleting and posting new pages on an Intranet portal? The Intranet is intended to facilitate the exchange of information and applications among colleagues. Nevertheless, servers and Web pages should have designated "owners"-that is, people who have specific permission to add, remove, and change content. The permissions function of the operating systems is used for controlling basic rights and permissions. Other steps include requiring that certain content be digitally signed with digital signatures.
Action to take: verify and update the table that shows each job function, ownership of data and Web pages for that function, and the specific rights accorded that job function.
5. Firewall set up. Was your organization's firewall set up in a rush or on a Friday before a long weekend? The most common problem with firewalls is that those installing them are often pressured to work quickly. No firewalls should be activated until the default settings have changed and tested. Accepting the default settings for software firewalls such as Black Ice Defender or hardware firewalls from LuciGate allow probes from within the Intranet to identify points of vulnerability. Does your organization use one centralized firewall? Does each department have lower-cost firewalls?
Action to take: make certain that firewalls are properly configured. A security audit can catch most setup oversights.
6. Remote access. Does your organization allow users dial-up access behind the firewall? Does your organization support wireless access from any location? Special steps are necessary to handle remote access. Other precautions are necessary for wireless access, including the use of WEP security. Restricting them to the same access offered to the rest of the Internet in front of the firewall denies them valuable services. A virtual private network allows an authorized user to establish a secure connection to the Intranet. An employee who is careless with a user name and password can compromise the system. For a useful introduction to VPN's see www.csm.ornl.gov/~dunigan/vpn.html.
Action to take: test your organization's remote access system. Make certain that the security audit analyzes and addresses any weaknesses in the virtual private network.
7. Manage e-mail. How easy would it be for your organization to give up electronic mail? For most organizations, e-mail is a must-have service. Many professionals perceive e-mail as a variant of traditional paper-based mail. It is not. Organizations need to have an active approach to e-mail security. At the very least, employees should be told the organization's policies regarding e-mail. Anyone with access to an organization's e-mail will need some education about the vulnerability of unencrypted e-mail. Not only is clear-text e-mail easy to intercept. E-mail messages reside in multiple servers and machines in a network. For example, a copy of a message is on the sender's machine, possibly on the organization's mail server, possibly on the Internet Service Provider's mail server, the recipient's machine for a period of time, and possibly on the mail server at the addressee's organization and ISP. An increasing number of organizations are implementing procedures that encrypt e-mail. Other organizations use systems that track and monitor e-mail, writing all messages to an archive. Certain governmental entities use both encryption and tracking for secure messaging. Many companies offer secure e-mail systems. One example is Hush Mail
Action to take: verify that your Internet Service Provider Supports S / MIME (Secure Multipurpose Internet Mail Extensions). If not, ask when your ISP will. Chances are good that S / MIME is supported. If your ISP has no intention of implementing S/MIME, look for a new ISP. If you are running your own e-mail server, implement S/MIME, even if you choose to go with a third party security product.
8. Viruses and rogue code. Most organizations know to have antivirus software installed. There are different schools of thought about which antivirus system is optimal and the use of antivirus software on the user's machines. Part of the antivirus security procedure includes settings in the mail client, settings in the browser with regard to executables on Web pages, and the types of write protection implemented for various users. Rogue code--that is, Java or other executables embedded in a Web page or document opened by an application--is an unfortunate fact of life in organizations today.
Action to take: ensure that the organization's security policy addresses antivirus programs and settings for what executables are automatically launched by an application.
9.Standard software. Can a user bring a third-party program to the office and install that software? If the answer is "yes," a close look at existing policies and procedures and their enforcement is warranted. In many organizations, software from any source other than the system administrator is not permitted on any network-connected device. Many government organizations specify a standard browser and automatically configure security setting for that browsers using the permissions table mentioned elsewhere in this article. Third-party software is the primary means for unauthorized programs to be installed on a device and possibly the network. Trojan horses, backdoors, sniffers, and zombies can be traced to such unauthorized software or rogue code.
Action to take: automated sweeps of the software on each network device can identify unauthorized software and remove it. Also, software maintenance, provided by an appropriate source, should be licensed for each server and desktop to ensure that bugs and vulnerabilities are repaired.
10. Security audit. A third-party service-available from local, national and international firms-checks the security of an organization's Intranet. AT&T as well as smaller firms such as META Security Group offer a range of services. Most security audits require a combination of tests run remotely to determine if the external connections are secure. Then, a security engineer performs a series of tests at the client's location. The security audit has at least three steps. First, the audit itself. The results of the audit are reviewed with the appropriate client personnel. Second, fixes are made to the existing system. The final step is a repeat of the audit. Most organizations do not perform regular security audits of existing systems. Costs of security audit vary by the size of the organization and the stringency of the testing procedures. The sorts of things we cover in a security survey include things like trust relationships, internal compartmentalization, roles (system manager, security manager, programmer, analyst, clerical, management, etc., etc.) and responsibilities, communication lines, etc. It is vitally important that organizations do such a survey in the development of a security policy for their Intranet security. They ought to have a physical, logical and organizational (relational) network map.
Action to take: implement an annual security audit with monthly or quarterly spot checks of Intranet weak points.
One pundit said, "The only secure computer is one with no power, locked in a room, with no user." Any other system can be compromised. A review of these checkpoints provides a quick and easy way to assess the security implemented at your organization.
Stephen E. Arnold
Mr. Arnold is a consultant to organizations of all sizes and types. He and a small team of specialists provide services in online systems, information strategy and budgeting, and related activities. Information about Mr. Arnold and his team's services may be found at www.arnoldit.com/sitemap.html
[ Top ] [ AIT Home ] [ Beargrass ] [ Site Map ]