Search Intranets
Current Issue
November/December 2013
News & Tools

About Intranets
Subscribe to
Past Issues
Sample Issue (PDF)
Ten Intranet Security Pitfalls
- Jan/Feb 2003 Issue Posted Jan 1, 2003 Print Version  
Page 1

Note: This article appeared in Intranet Professional, prior to its re-launch as Intranets (in 2004).

Niku Corporation, of 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. Niku Corporation obtained a temporary restraining order against Business Engine, of 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 and 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 that 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 find 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.

The three goals of security are confidentiality, integrity, and availability. 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 types of compromise. 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 equal 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 certain types of machine.

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 as well as 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 begins with the staff.

An intranet security strategy begins with a risk assessment that includes the following:
• understanding the security vulnerabilities in an organization
• identifying the threats that face your organization
• assessing the risk of each threat
• identifying appropriate steps to reduce risk to an acceptable level
• verifying that the system meets the security benchmark appropriate for a particular organization

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.

Ten security pitfalls are presented in the checklist below. No one organization suffers from all of these; however, even an organization with a clean bill of health from its security consultant may find this checklist useful.

The following three assumptions are made:
• 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.
• 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 give the director of personnel and finance access to salary information. All other employees are not given access to these data.
• 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 than 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 that exploit unpatched systems are transmitted by a victim merely looking at the contents of an e-mail. If an organization does not have these three foundation stones in place, the prudent reader will make completing these tasks a high priority.

The 10 Security Pitfalls

1. Encryption
Secure server/client software is now available. Have encryption and authentication options such 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 an 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 keyboards or laptops.)

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 system is used for controlling basic rights and permissions. Other steps include requiring digital signatures for certain content.

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 the 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 been changed and tested. Accepting the default settings for software firewalls such as Black Ice Defender [] or hardware firewalls from LuciGate [http://www.luci] allows probes from within the intranet to identify points of vulnerability. Does the 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 the organization allow users dial-up access behind the firewall? Does the 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 remote-access users to the same access offered to the rest of the Internet in front of the firewall denies them valuable services. A virtual private network (VPN) 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

Action to take: Test the 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 the 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, but 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 (ISP) 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 the ISP supports S/MIME (Secure Multipurpose Internet Mail Extensions). If it doesn't, ask when the ISP will. Chances are good that S/MIME is supported. If the 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 settings for that browser 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 connectionare 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 is performed and the results 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 audits vary by the size of the organization and the stringency of the testing procedures. The sorts of things covered in a security survey include trust relationships, internal compartmentalization, roles (system manager, security manager, programmer, analyst, clerical, management, 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. 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.

Print Version  
Page 1