Security doesn’t seem to be such a major issue on a corporate intranet as it is on the public Internet. After all, this network is not public. But business considerations can make security an important issue with which to deal.
If security on an intranet is centralized, it is usually controlled by a corporate organization. Many corporations currently do not have centralized security for their intranets, which is unfortunate as much of the hacking done today occurs on private rather than public networks.
If your corporation does have central control of intranet security, those in charge will have security standards that your application must meet before you can place it on the intranet. As with other corporate organizations, you will probably have to plan in advance to work with the corporate security department. Some intranets might even use centrally administered security for logon passwords and other security issues.
Most technicians find that security concerns often conflict with the technical considerations of their applications. Technical advances often outstrip the security department’s ability to accommodate them. You might devote your time to security modules that seem overly burdensome and might find that you are unable to implement some technologies on the intranet because of security requirements and concerns. But by planning ahead, you can prepare time in your design and construction schedules to accommodate these security needs.
Another concern in intranet applications is protecting confidential material. It is true that your application is operating over corporate resources, but it can pass data that should not be seen by unauthorized employees, contractors, customers, and others who have access to the intranet. Many confidentiality issues discussed in Chapter 1 for the Internet also can be applied to intranet applications. Because the intranet and Internet are both TCP/IP networks, they have the same limitations and problems when plain text is transmitted across them.
One issue that requires a balancing act is the need for confidentiality versus the availability of information for the corporate community. Security and confidentiality issues are always cost-benefit tradeoffs.
Remember also that you might have to apply local, state, and even national laws to the information in your application even though it passes over your private intranet. Personnel and financial applications are often subject to these laws. Another interesting consideration that spans political jurisdictions-states, provinces, or even countries-is that various segments of the intranet might be subject to different laws when it comes to the confidentiality of the information carried on them.
Maintaining security and confidentiality is a juggling act. On one side is the need to keep information secure and confidential, and on the other side is the need to make information available. There are no hard-and-fast rules for managing this dilemma. You could write an entire book on security and confidentiality issues. In a single chapter, I can provide only some guidelines by which you can develop your application.
You will need to examine two things to determine the level of security that your application requires. First, determine how sensitive your data is. Some data is easy. For example, if you are developing an organization chart application that will display information about your employees such as social security numbers, home addresses, and phone numbers, you are dealing with sensitive information that should be protected from unauthorized access. Other information is more subtle. Let’s say you’re working on a marketing application that will enable your managers and sales representatives to share information about current and potential customers. You might think that this information doesn’t need to be very tightly secured; after all, this is your internal network-your intranet. This brings us to the second consideration in the security versus availability dilemma.
Stop for a moment to consider the people who have access to your intranet. If you are part of a company of any size, you probably have all sorts of people in your intranet:
- Temporary help
- Consultants and vendors
Would you want all of these people to look at your data? Even subtle data can have an impact on your business. Let’s say you want to put your company newsletter online. Along with those announcements of company activities, the local bowling league scores, and the picture of the employee of the month is an article about your marketing strategy. If consultants, vendors, or customers had access to this information, it could give them (or their other customers) a competitive advantage in the future.
If your intranet has a mix of people on it, consider giving non-employees IDs that are easily identified, perhaps with special characters in certain positions. Secure all confidential or potentially damaging information with secured Web servers. Require access via ID and password. Your application can detect the special IDs and deny access to the information.
One interesting fact is that very few corporations have implemented internal firewalls on their intranets. You might consider implementing a firewall, especially if you are designing a sensitive divisional or departmental application that needs to be isolated from other divisions or departments.
How do you decide the security issues? Only you can do so. Look at the data, and then give some thought about the people who are using your intranet. If you have any doubt, secure the information. A few tips follow.
- If you have any doubt about the security if your intranet, run your application on a secure server and pass information only to users with secure browsers to ensure that your sensitive information will not travel over your network as plain text.
- Develop a central security system that can identify the various types of users by user ID and password.
- Accept connections only from known, secure IP addresses. Make sure that machines that are accessible to unauthorized personnel cannot access your application. Use filters on your router, if appropriate, or refuse to send pages from your server to unknown IP addresses.
Given a choice, most of us would select a password that was easy to remember, never change it, and use the same password everywhere. Your corporate security group probably has standards much stricter than that-for a reason. Easy passwords that never change are easy to crack, and once passwords are cracked, hackers can use them again and again.
Never send passwords via electronic mail unless the message is heavily encrypted. In fact, just to be safe, never send passwords through electronic mail, period!
If you must use passwords in your application, change them periodically. Once a month is typical, though your application might require more or less frequent changes. If you use the HTTP password capability, you will want a separate process for updating passwords. One way is to use corporate security files to obtain passwords. Another suggestion is to alter the passwords periodically yourself and distribute them to your users via a secure mechanism. Never send passwords in an electronic mail message unless the message is encrypted!