Enterprise Security: Built on Sound Policies

The creation of an information security policy can be a complex task. Decisions need to be made concerning the degree and type of security that is right for your company, while considering economic factors. Where do you begin?

• 12/01/1999

The real issue for most organizations is not whether security is necessary, but if it is recognized as an urgent need. We live in an era characterized by more complex computer environments, multiple computer platforms, and vast conglomerates of integrated computer networks.

Decisions about key security issues are far from trivial and often perplexing. How much security is necessary? What kind of security most effectively satisfies your individual requirements? Where do you begin? How can you obtain an economical level of security for your information systems? This article helps answer these difficult questions by guiding you through the process of creating an information security policy.

An information security policy is a senior management statement written to ensure that information is handled securely. This policy statement provides a mandate for the implementation of security throughout an organization. The policy document points to specific standards that indicate the security requirements that must be implemented, while guidelines describe the requirements that should be implemented.

A policy establishes who is authorized to access different types of information, and points to standards and guidelines regarding how much and what kinds of security measures are necessary. Procedures provide the method for implementing those standards and guidelines. Almost every organization has an information security policy in place, though some are not explicitly written.

An information security policy should not be written in a vacuum; it should relate directly to the business needs of your organization. For example, the concerns addressed in a policy for a defense contractor performing top secret work are different than those required by a video store. Whereas the contractor is probably more concerned with protecting classified data, the store wants to be certain that its inventory and accounting records are accurate. With differing needs, there is not a general security policy perfect for every organization.

An organization-wide security policy should be fairly short; probably three to five pages. It should be written in generic, non-platform-specific terms, and worded in a way that makes it resistant to changes in structure and technology. It should have a lifetime of three or more years.

The key to writing a document that requires little change after completion is to have the policy point to associated documents that contain the standards, guidelines and procedures, as well as any user contracts. These associated documents contain security-specific information and future changes are then made to these underlying documents. The policy provides a charter for getting security implemented, and the associated documents provide the implementation method. Additionally, there may be site- or system-level policies detailing specific guidelines and procedures.

The security policy is a charter that embodies fundamental business practices, and should be signed at the highest level possible, preferably by the CEO. If a lower-level executive signs the policy, the user community can resist and the policy becomes just a suggestion of guidelines for voluntary compliance, not a mandate for information security.

A small task force, consisting of at least one high-level executive, system security administrators, EDP auditors, MIS directors, attorneys and consultants, is best suited to drafting such a security policy.

Policy statements cover the three basic goals of security:

• Confidentiality – ensuring that sensitive data is read only by authorized persons.

• Integrity – protecting data or software from improper modification.

• Availability – ensuring that systems, networks, applications and data are online and accessible when needed.

For different types of applications, the required levels of confidentiality, integrity and availability change. For example, a nuclear weapons research system requires a high level of confidentiality, but may be able to withstand lengthy outages. A system reporting public stock trading values has a low requirement for confidentiality, but a high-integrity requirement.

In order to assure that the above goals are being met, include policy statements to cover:

• Accountability – ability to tell who did what, so there is a means for verifying compliance with security goals.

• Resource Control – protecting computer equipment from accidental, natural and deliberate harm and restricting equipment access to only authorized individuals.

Separation of duties is a fundamental concept to information security providing checks and balances, as the following suggests:

• Origination from approval – separate the person who signs checks from the person that writes them.

• Creation from maintenance – separate the person creating new vendor accounts from the person who enters debits and credits.

• Procedures from data – separate programmers writing accounting programs from the persons entering data.

In large organizations, classifying data is sometimes worthwhile. This way you can have policy statements that refer to certain types of data. This means that individuals must be cleared to access data with a particular classification.

In defining a policy, you need to know the threats and risks to your information systems. Threats are the sources of potential security problems, while risks refer to the likelihood and cost of a particular event occurring. Threats can be natural adversaries (fire, water, power outages, etc.) or human damage, either deliberate or accidental. Some human threats come from society, such as terrorism and war. Others come from inside users or outside hackers. Recent surveys confirm that inside users are viewed as a greater threat than outsiders due to their greater access.

Risk management is the process of balancing the cost of protecting against risk versus the cost of exposure. When the cost of protecting and the cost of exposure are at almost the same point, your security measures are properly balanced and prudent. Otherwise, you may be spending more on security than it is worth, or, even more likely, you are spending too little and exposing your business to risk.

There are three basic choices that you can take with regard to each risk:

• Accept – Robert Courtney, a leading security consultant, says, "Never spend more avoiding a risk than tolerating what it will cost you." If the exposure is small and the protection cost is high, your policy may be to accept the risk.

• Assign – In some cases it costs less to assign the risk to someone else than to directly protect against it. For example, most companies purchase fire insurance rather than build fireproof buildings.

• Avoid – This involves putting in place the necessary measures so that the security event will not occur at all, or so that the security event becomes much less likely or costly.

The policy must indicate who is responsible for security. In the simplest sense, "everyone" is responsible, since users are both the primary safeguard of, and the greatest threat to, security. The policy should require all users to sign a contract, which spells out their security responsibilities and acknowledges who owns the system and data. The following should be covered in the contract:

• Organization owns the systems/data.

• User agrees not to make unauthorized copies of data or software.

• User agrees to choose passwords wisely and to keep them secret.

• User agrees to access the system and data in authorized fashion only.

• User acknowledges right of organization to monitor system use for security purposes.

The policy must be published and made available to all users. Adherence to the security policy should be a part of each employee’s performance review.

Certain individuals within the organization will be directly charged with security responsibility; the policy should refer to these people by function and title, not name. In general, duties should be separated: 1) security managers should be responsible for overseeing security; 2) system managers and IT directors should assist in implementing security, but ideally, the security manager should be a separate person reporting to corporate security – not IT; 3) the information systems auditor should periodically review the security of the information systems to provide management with the assurance that the policy is being followed.

Depending on the size and structure of the organization, security duties may vary, but the policy should clearly designate them. There should always be checks and balances with different persons overseeing, implementing and reviewing security.

The policy must indicate a procedure for ensuring compliance. This might consist of a periodic review or automatic notification of a policy violation by the system. When a violation is found, the policy should indicate the measures to take, such as the following:

• Notify proper authorities.

• Correct the problem.

• Take disciplinary action.

• Allow an exemption.

Exemptions or waivers to the policy must be granted only under extraordinary circumstances.

With the advent of enterprisewide computing, you need the ability to define security policies and to manage and enforce them across desktops, LANs, midrange and mainframe systems, without regard to the computing platform.

An integrated security solution must be able to evaluate security status across heterogeneous environments according to a single set of security policy rules.

After you have a defined security policy in place, you need to determine if it’s being enforced. Security violations must be evaluated for their ability to be repeated. An effective, meaningful way to manage security goes beyond break-in statistics.

On a continual basis, you need to measure actual security performance against pre-determined, objective, quantifiable criteria.

Information security policies can be grouped into several security categories. Each of these categories represents a group of security checks for user accounts and authorizations, network and server settings, and file systems and directories. The categories allow you to identify policy violations and indicate areas of vulnerability and potential security threats for the defined domain.

User Accounts and Authorizations. Account Integrity scans user and configuration files. Key checks include user privileges, home directories and permissions, which prevent accounts from having privileges outside of the established security policy.

Login Parameters look for failed login attempts, unused accounts and expired passwords. This capability warns of potential break-ins and lowers security risk.

Password Strength checks passwords for conformance with the security policy, including password format, length, expiration and key words. This feature enables you to avoid critical problems like easily guessed passwords.

User Files reduce the number of unauthorized accesses by ensuring file ownership and permissions. Suspicious files in user directories are also identified, including files with the same name as system commands, hidden directories, special device files and mount points in other areas.

Network and Server Settings. System Auditing monitors audit trails and system accounting to make sure they’re running as specified. You can therefore detect unauthorized access and get valuable tracking information during or after a break-in.

System Mail checks known problem areas in UNIX, OpenVMS and NetWare mail systems. This function monitors the system mail for embedded software worms, Trojan horses and other software risks.

Network Utilities examine the security of your Internet connections, Network File System (NFS) software, DECnet, NetWare supervisor access, disk space and number of connections. As a result, any vulnerable network points of entry are closed to internal and external attacks.

Object Integrity identifies changes in ownership, permission, logical name tables, rights identifiers and other software objects for device-specific files in the systems device directory or account. New devices, deleted devices and changes to devices are identified, ensuring that these objects have not been compromised in any way.

System Queues prevent break-ins by checking UNIX "cron," "batch" and "at" utilities, as well as file integrity.

Startup Files look at the UNIX "rc" scripts for changes, ownership, and proper content and files in NetWare and OpenVMS according to the information security policy files. This function protects against the security risk of improperly set up or modified files, where attacks can be facilitated by a simple addition of commands to poorly protected scripts.

File Systems and Directories. File Access examines the permissions of user-specified files and identifies the user accounts allowed to access the files in the manner specified by your security policies. The options are checked to make sure that only the policy-designated users can access or modify those files.

File Attributes indicate specifically chosen changes in selected system file attributes, including "read," "write" and "create" privileges for group and individual. Changes made outside the normal software updates performed by the system administrator may represent a security problem.

File Find checks executables and other files for anomalies like viruses, Trojan horses, the UNIX "sticky" bit set and other corruption that would allow unauthorized use of the file or your entire system. Each operating environment has a different set of unique checks. This function allows you to specify individual system checks.

Your security solution should not only provide the means to define, manage and enforce, but also give you the means to correct problems proactively from a central workstation.

Trend analysis allows you to keep a record of previous security problems and analyze problem areas over time. Thus, you can track progress objectively and make necessary adjustments in an informed manner.

About the Author: Robert A. Clyde is the Vice President and General Manager of AXENT Technologies’ Security Management Business Unit. He can be reached at rclyde@axent.com.