Novell is now a part of Micro Focus

Creating and Enforcing an Internet Acceptable Use Policy

Articles and Tips: article

Tony Merritt
Global Solutions Architect
Novell, Inc.
tmerritt@novell.com

01 Apr 2003


This AppNote is for those individuals who are responsible for implementing, maintaining, and enforcing corporate Internet usage policies. The content is also relevant to those who allocate and pay for Internet bandwidth and are responsible for its usage, especially in these times when the boundary lines are blurring between corporate and personal liability.


Topics

Internet acceptable use policies, Secure Identity Management (SIM), security, access control

Products

eDirectory, BorderManager, iChain, DirXML

Audience

network designers, administrators

Level

beginning

Prerequisite Skills

familiarity with basic network security concepts

Operating System

n/a

Tools

none

Sample Code

no

Introduction

The ubiquity of Internet access in today's business world has opened up powerful new channels of communication, both within a single organization and between separate organizations. However, it has also given rise to a host of problems related to security and legal liability for Internet misuse.

This AppNote discusses some of the key business problems regarding Internet access and presents a sound methodology for devising an Internet Acceptable Use Policy (iAUP) for any organization. It then presents a sample solution for automating and enforcing such a policy. This information will be of particular interest to those involved with the creation and maintenance of corporate Internet usage policies, including Internet content policy administrators, firewall policy administrators, human resources administrators, and corporate security administrators.

The Business Problems of Internet Access

Business requirements are the key framework within which to design a solution. Across different businesses, there tend to be major differences in policy, especially with regards to Intenet access and usage. As a result, a consistent methodology is critical to formulating an effective Internet Acceptable Use Policy. Business requirements are not typically bound by the "inside" or "outside" of a corporation. The security of corporate data is important regardless of the access location. Because of this, the technology, policies, and procedures must support internal corporate users interacting externally through the Internet, as well as users interacting from the Internet into the organization. This section discusses some of the key issues driving the importance of an iAUP.

Security of Corporate Assets

Any company today can be severely handicapped or put out of business by the disclosure of confidential or proprietary information. The release of confidential processes, the distribution of customer information and pricing, or the publication of private medical records for virus screenings are examples of situations that can lead to loss of revenue, loss of customers, and legal damages that could prove insurmountable. Here are some revealing statistics from a recent FBI/CSI Computer Crime & Security Survey:

  • Network penetration by outsiders increased for the third year in a row; 30% of those surveyed reported specific intrusions.

  • 57% of the respondents reported the Internet as a frequent point of attack.

  • Internal abuse of Internet access privileges by employees was reported by 97% of the respondents.

  • 26% of the respondents reported actual theft of proprietary and classified company information.

  • 45% reported unauthorized access by insiders.

Another indication of security risk is the rash of Internet theft of credit card numbers. The following is just a small listing of recent articles on CNN covering these types of activities:

  • "Root of massive credit card theft found" (CNN 02/20/2003) - A hacker who gained access to millions of credit card numbers apparently did it by breaking into a computer system at a company that handles transactions for catalog companies and other direct marketers.

  • "Rebuffed Internet extortionist posts stolen credit card data" (CNN 01/10/2000) - An anonymous computer hacker stole credit card numbers from an Internet music retailer and posted them on a Web site after an attempt to extort money from the company failed.

  • "Hackers access Playboy.com's credit card data" (CNN 11/20/2001) - Computer hackers broke into the Playboy Enterprises' Web site, playboy.com, gaining access to the credit card numbers of customers.

Regulatory Compliance

One has only to look through the daily news to read about companies failing due to illegal activity, personal information exposed for public view, and consumer credit information illegally distributed. As a result of such activities, many countries have enacted laws requiring companies to comply with privacy policies and be held accountable for the security and privacy of the information covered by those policies. Here are examples of a few of these regulations:

  • Sarbane-Oxley Act (2002). This U.S. legislation affects financial services, accounting, auditing, financial reporting and professional services firms. The act declares its purpose as follows: "To protect investors by improving the accuracy and reliability of corporate disclosures made pursuant to the securities laws, and for other purposes. Penalties for failure to comply include the possibility of the removal of publicly traded stocks from the market and encarceration for corporate officers responsible."

  • Gramm-Leach-Bliley Act (1999). The primary goal of this U.S. legislation is the facilitating of affiliation among banks, securities firms, and insurance companies. The section relevant to iAUP and security is "Title V - Privacy," which states: "It is the policy of the Congress that each financial institution has an affirmative and continuing obligation to respect the privacy of its customers and to protect the security and confidentiality of those customers' nonpublic personal information."

  • Health Insurance Portability and Privacy Act (1996). This U.S. act, commonly referred to as HIPPA, includes important new protections for millions of working Americans and their families who have preexisting medical conditions or might suffer discrimination in health coverage based on a factor that relates to an individual's health. The section relevant to iAUP and security is the Administrative Simplicifcation Provisions including National Standards for Transactions, Security, and Privacy.

  • UK Data Protection Act (1998). This British act makes a new provision for the regulation of the processing of information relating to individuals, including the obtaining, holding, use, or disclosure of such information. It is designed to protect personal information and establish security and privacy regarding that information.

  • Poland Data Protection Law (1997). This Polish law states: "Any person has a right to have his personal data protected. The Act shall determine the code of conduct for the processing of personal data and the rights of natural persons whose personal data is or can be processed as a part of a filing system."

  • Personal Data Protection Act (2000). This purpose of this Argentine act, also known as the Habeas Data Law, is the full protection of personal information recorded in data files, registers, banks, or other technical means of data-treatment, either public or private for purposes of providing reports, in order to guarantee the honor and intimacy of persons, as well as the access to the information that may be recorded about such persons.

  • Data Protection Directive (2002). This European directive applies whenever personal data is processed wholly or partly by automatic means and also to certain forms of manual systems. In this latter situation, the legislation will apply only where the data is held as part of a structured filing system. Although an extensive transitional period of 12 years is made available to those Member States whose legislation presently excludes manual systems, this will apply only in respect of data held in systems at the date of the Directive's adoption (24 October 1995).

Liability for Offensive Content

In the last decade, harassment in many forms has driven corporate workplace litigation, resulting in fines, settlements, and policy changes. Typically, rulings on these cases have been based not only on the incident, but also on the corporate cultures that support the specific behavior. As a direct result, corporations which do not actively control the Web-based content employees are exposed to at work are at risk for "passive approval" of such material. These actions tend to widen the litigations from personal liability to corporate liability.

As an example, federal law now requires companies in the United States with 25 or more employees to provide a work environment free of gender, ethnic, and racial harassment or discrimination. That requires taking reasonable steps to eliminate harassing materials from the workplace. Illegal or offensive content may include:

  • Pornographic images downloaded off the Web

  • Pornographic or racially offensive e-mail attachments

  • Offensive language or words

It may not matter whether the company knew employees were downloading pornographic images. The test at trial is whether well-known remedies were available to prevent abuses, whether a policy existed to apply those remedies, and whether the policy was actually enforced. Here are two examples of such situations.

United States Example. R.R. Donnelly is facing a $500 million discrimination suit involving allegedly racist e-mails. Employees claim they were discriminated against when the company arranged transfers after a 1993 plant closing. Presented as evidence were e-mail documents listing 165 racial, ethnic, and sexual jokes said to be created at the Lancaster, Pennsylvania plant.

Australia Example.  In the court case of "Thompson v Australian Capital Television," Channel 7 was found liable for relaying a Channel 9 television show that contained defamatory material. The court considered that Channel 7 had the ability to control and supervise the telecast. Even though the program was "live," the legal argument was that Channel 7 knew from experience that program carried a high risk of defamatory statements and therefore was still liable.

Loss of Productivity/"Non Work-Related" Activity

Typically, the Internet has been touted as a mechanism for improving productivity in the workplace by allowing employees to become "knowledge workers." Employees empowered by the Internet are able to research information more easily, communicate with customers and vendors more efficiently, publish product information instantly, and so on.

However, with the ubiquity of the Internet and the information published through it, there exists the temptation to view "non work-related" information. Further, depending on the particular "non work-related" information downloaded (for example, pictures with huge file sizes, bandwidth-gobbling multi-player games, and the like), such activity can impact the bandwidth available for legitimate work-related activities.

Internet Gaming Example.  A soft manufacturing outsource company headquartered in Clearwater, Florida, was having tremendous problems with the wide area network connectivity between its U.S. headquarters and a Singapore office. Operations based on exchange of data had all but halted, and the IT personnel were called in to determine the cause. The conclusion of the investigation led to the discovery that a network-enabled game called Doom had been played between several members of the headquarters staff and staff from around the world (including Singapore). Since the Singapore office already had bandwidth constraints on their wide area network connectivity, that site was the first location to be affected.

Internet Acceptable Use Policies

The cases and examples cited above tend to support the following conclusions about the iAUP in today's corporate environments:

  • Documentation regarding the iAUP is inconsistent or non-existent.

  • There is little or no enforcement of the iAUP.

  • There is little or no maintenance of the iAUP.

  • There is little or no alignment of the iAUP with compliance or regulatory requirements.

Only within the last few years has the technology become common that is required to support an enterprise implementation to address these issues.

As more and more companies adopt a "remote workforce" approach, there is a stronger need to create, implement, enforce, and maintain an enterprise-wide set of Internet acceptable use policies.

Policy Best Practices

To create an auditable and verifiable match of enterprise policies to specific business drivers, including the ones mentioned previously, a functional matrix approach is recommended. This approach allows a mapping of policies across various classifications, personnel groups, and locational dependencies.

Typical iAUP Policy Classifications.  The first step in creating the functional matrix is to identify the appropriate classification from a list such as the following:

  • Regulatory Compliance

  • Security Risk

  • Offensive Content

  • Productivity

  • General Departmental

  • General Corporate

These classifications answer the question, What is driving the policy? Ideally, only one of the items is checked in the above list of matrix categories. This allows for easier classification and management.

Typical Application of iAUP Policies.  The next step in completing the matrix is to do a similar mapping of the corporate personnel:

  • Everyone/Global (employees, customers, vendors, and so on)

  • Specific Company Relationships (customers only, partners only, and so on)

  • Employees

  • Departmental Personnel

  • Corporate Roles (CIO, CSO, vice presndents, and so on)

This step answers the question, Who is affected by the policy? Again, ideally only one of the items is checked in the above list. When two or more of the areas seem applicable, choose from the top down to ensure a wider scope of compliance.

Finally, the matrix resulting from the prior two classifications is combined with a matrix regarding locational dependencies/security exposure dependencies:

  • All Locations (both internal and external)

  • Public Shared Access Locations (shared workstations, Internet cafes, nursing stations, airport kiosks, and so on)

  • External Locations (external wireless, company laptop in hotel, company laptop at customer site, home office, and so on)

  • DMZ (De-Militarized Zone, referring to devices that are Internet facing and outside the internal company firewalls, making them particularly vulnerable to attack from the Internet)

  • Company Private LAN

  • Company Secure Location (machines protected by hardened physical security, biometric authentication devices, and so on)

  • Company Data Center

Using this matrix approach, you can readily map policy creation, management, and maintenance to technical capabilities. Population of the matrix for a particular company is typically a combination of input from the CSO (Chief Security Officer), the IT Director, the HR Director, Corporate Legal Counsel, external auditors and consultants, and so on.

Matrix Formulation Example

As an example, here is how a company might go about creating a functional matrix if they want to protect employees from "controversial material" and reduce the company's harassment liability.

First, they determine that "controversial material" falls under the classification of Offensive Content. As far as interpreting where the policy should apply, they check the "Employees" box. One of the assumptions of reducing the liability associated with "controversial material" is that the company is only responsible for material viewed within its walls. Based on that interpretation, the company then determines the following locations to apply the policy against:

  • Corporate Campus Wireless Location

  • DMZ

  • Company Private LAN

  • Company Secure Location

  • Company Data Center

The resulting iAUP matrix is as follows:

Type:   Offensive Content How:    Block All where policy appears


 
All
Public Shared Access
External
Campus Wireless
DMZ
Private LAN
Secure LAN
Data Center

Everyone/Global

 

 

 

 

 

 

 

 

Specific Company Relationships

 

 

 

 

 

 

 

 

Employees

 

 

 

x

x

x

x

x

Department Personnel

 

 

 

 

 

 

 

 

Corporate Roles

 

 

 

 

 

 

 

 

By working through the matrix from a top-down perspective, general corporate policies will consist only of policies that are not from compliance, offensive data protection, and productivity policies. By using the matrix in this fashion, when compliance or other policies are changed, they can easily be updated and matched to the technology changes that are required to maintain compliance. Also, an auditor or other non-technical person can review the enterprise policies and ensure due diligence within the company.

Note: Keep in mind that there is no specific "correct" answer; each company may have a different interpretation and desired risk exposure. The point isn't necessarily to arrive at the "correct" answer, but to come up with a consistent and auditable application of the answer the company has chosen and supporting documentation to prove due diligence.

Now that you are armed with an iAUP matrix, let's discuss how to create a technology mirror of this abstract policy that provides automated enforcement.

Architecting an Automated Policy Solution

There are many different types of approaches, as well as software, hardware, and other technology mechanisms on the market, for working towards the described goal. For our sample solution, we will configure and use the following products: Novell eDirectory 8.7, DirXML 1.1, BorderManager 3.7, Novell Modular Authentication System 2.1, and iChain 2.2. These products will be combined to create an automated and provisioned iAUP. By tying the policy management to the authentication and authorization management, the solution is able to create a policy based on a secure identity management (SIM) system.

Each company, and certainly each industry, has unique requirements for the iAUP architecture. For this example iAUP, assume that the customer is a government organization which is working on an iAUP. The example will focus on the part of the architecture based on usage and exposure of data related to the espionage (spy) personnel within the agency.

In this instance, all data access is denied unless policies allow it. As with many government organizations, the particular information and data is departmentalized. A possible interpretation of the policy might be this: the only people who should be able to access the data are currently active members of the espionage department who have authenticated with at least two forms of identification and who are located in a secured corporate campus area.

Using the methodology described in the previous section, the following information has been filled out in the matrix for the government agency:

Type:   Security Risk How:    Deny unless policy allows


 
All
Public Shared Access
External
Campus Wireless
DMZ
Private LAN
Secure LAN
Data Center

Everyone/Global

 

 

 

 

 

 

 

 

Specific Company Relationships

 

 

 

 

 

 

 

 

Employees

 

 

 

 

 

 

x

 

Department Personnel

 

 

 

 

 

 

 

 

Corporate Roles

 

 

 

 

 

 

 

 

Authentication Management (eDirectory)

In certain areas of the United States government, the separation of authentication and authorization mechanisms is mandated. This practice has gained wider application across many industries. Based on the scenario described above, it is quite likely that the organization would actually have separated the Authentication Vault (eDirectory) from the Authorization Vault (eDirectory). The Authentication Vault is a system that allows for a secure recognition and verification of the credentials used to access a system (for example, passport ID number, social security number, and so on). The Access Control Vault is a system that, after verification with the Authentication Vault, determines the access rights of the individual (for example, airplane ticket and photo ID are required to board a plane).

In this design, a "services" container is created to hold the various housekeeping items that are required to support the design, but outside the scope of authentication or authorization. The design might resemble the Authentication container shown in Figure 1.

Figure 1: Authentication Vault, containing members of the Espionage department.

The user identities in the Authentication Vault are automatically populated by the government's human resources software. As a person is hired in the human resources system, the data operator enters all the information about that individual, including which department the individual works for. This action triggers Novell DirXML to automatically create the user in the Authentication container, as depicted above, with all the appropriate properties (including the department). In this example, the system also populates the fingerprint codes of the employee.

If a person quits or is suspended or terminated, the human resources system is updated. This action immediately updates the Authentication Vault, and in this case, the person would be immediately locked out from accessing the system.

The Policy container (see Figure 2) stores all of the corporate enterprise policies and responds in real-time to changes from an event-driven system, as well as allow for dynamic extensions.

Figure 2: Authorization Vault, containing the Espionage department policies.

To classify and simplify auditing and reporting, attributes are added to the schema to reflect the matrix categorizations described in this AppNote. While these data values are not directly used, they provide a mechanism for consistent tracking, as well as the ability to filter policies by categorization (for example, querying the directory for all policies regarding security risk). This allows for partitioned auditing ability and the ability to help map policy overlap or collision.

Novell DirXML is used to populate the policies. Application of the policies is based on the matrix produced, the service or content protected, and the decision to deny or allow access based on the policy. Per the example scenario, the SECURITY_RISK-ESPIONAGE_DEPARTMENT-SECURE policy states that all access is denied unless an active member of the espionage department authenticates using two credentials in a secure area to the system.

So we now have a fault-tolerant, secure, and extremely fast system for storing and referencing the data. Let's take a step back and explain how the user identities get there in the first place.

Populating and Provisioning Identity Management (DirXML)

A key step in this solution is the population of the various vaults. Novell's technology for accomplishing this is an event-driven system called DirXML. It allows the solution to tightly integrate with the authoritative data source (the electronic system that is the primary keeper of the accurate identity information, typically related to payroll or human resources) of the customer.

In our example, assume that the organization uses PeopleSoft as its human resources system; this is the authoritative data source. Once the DirXML drivers are in place to transfer data between PeopleSoft and the Authentication and Authorization Vaults (eDirectory), you can automatically manage the policy that has been defined. Any time a user is created, deleted, or even changes departments in the PeopleSoft system, the DirXML engine will automatically and immediately produce the required changes in both the Authentication and Authorization Vaults, based on the coded business policies.

As an example, suppose John Q. Spy is hired into the Espionage Department. DirXML automatically provisions him into the Authentication container of the Authentication Vault with a department code corresponding to the Espionage Department (probably a fancy code). At the same time, DirXML automatically provisions him into the SECURITY_RISK-ESPIONAGE_DEPARTMENT- SECURE Authorization Vault policy based on his identity. This immediately allows him access to the Espionage data in the corporate secure location with his two-factored identification.

If agent John Q. Spy retired or was compromised or kidnapped, the relevant changes would be made in PeopleSoft. DirXML would immediately replicate the situation from PeopleSoft to the Authentication and Authorization Vaults and immediately deactivate and lock down the account. If the SECURITY_RISK- ESPIONAGE_DEPARTMENT-SECURE policy is changed, the changes are immediately applied to the various systems touched by it.

The logic that drives the DirXML system is based on the open-standard XML programming language. The following is an example of an XSL stylesheet that could be used to transform a user's Department code from PeopleSoft into a Group Membership in the Espionage group in eDirectory:

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="add[@class-name='User']">
<xsl:copy>
<xsl:apply-templates select="@*"/>
<xsl:if test="add-attr[@attr-name='OU']/value = '50143'"/>
<add-attr attr-name="Group Membership">
<value type="dn">TREEORG\GROUPS\ESPIONAGE</value>
</add-attr>
<add-attr attr-name="Security Equals">
<value type="dn">TREEORG\GROUPS\ESPIONAGE</value>
</add-attr>
</xsl:if>
<xsl:apply-templates select="node()"/>
</xsl:copy>
</xsl:template>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:transform>

We now have the policy and a deterministic way to associate it with users. So how do we enforce it?

Policy Enforcement from Within (BorderManager)

The BorderManager portion of the solution will be used to support the iAUP for internal users as well as users connected to the private network without coming in from the Internet. BorderManager will be used to support both the data content policy control and the services content policy (for example, FTP, Instant Messenger, Napster, WMC, and so on). BorderManager also has the ability to partner with third-party content protection services such as N2H2, SurfControl, and Connectotel to automatically provide updated filtering and protection against various forms of offensive content and non-work related activities.

Since BorderManager is based on a secure identity management system, it provides the ability to create a centralized policy mechanism with distributed enforcement capabilities. As an example, global policies (such as "no Napster or Instant Messenger usage") can be configured in one location in the Policy Vault, and they will be automatically applied by all BorderManager servers throughout the enterprise.

There are two basic policy groupings within the BorderManager firewall:

  • Service Based.  Packet Filtering based purely on the data level of the traffic through them (for example, Port UDP 123 - NTP Time is open from time.tock.edu to server1time.customer.gov).

  • Identity Based.  Access Control based on the identity of the user and the associated access control rules

Best practices typically involve configuring the Packet Filtering level to deny everything. Exceptions are then programmed in based on all required data flows enterprise wide. After the packet exceptions are programmed, Access Controls are applied to each exception to limit that exception to specific users, groups, organizations, or everyone in the enterprise.

In the example scenario, the goal was set to limit access to Espionage data. To meet this goal, FTP (File Transfer Protocol) should be a "secured" service. To secure this service-based protocol, BorderManager will be configured with a packet filter for FTP.

Note: BorderManager could also be configured with an FTP Proxy or an FTP accelerator as well, which would provide better security in some designs.

In BorderManager 3.7, filters can be configured at the console or through iManager. Figure 3 shows a filter exception configured with the default condition set to deny all but exceptions.

Figure 3: Configuring BorderManager to deny all packets but the exceptions.

For policy consistency and auditability, the filter names are configured to match the corresponding security policy implemented. It is typical for policies regarding security risk to be "logged" for review, as this allows for trending to help prevent internal theft. Figure 4 shows an FTP stateful filter that has been configured.

Figure 4: Configuring a stateful filter in BorderManager.

After several configuration screens, the finished packet filter should resemble the one shown in Figure 5.

Figure 5: The finished packet filter in BorderManager.

Now that the packet filter has been configured, an Access Control policy must be applied to the exception to limit access to the proper personnel. The Access Control Rule will be configured in BorderManager to point to the "group" policy named SECURITY_RISK-ESPIONAGE_DEPARTMENT-SECURE. Note that the naming standard reflects the details of the policy driver:

  • SECURITY_RISK = the general classification

  • ESPIONAGE_DEPARTMENT = the people affected

  • SECURE = the physical location of application (private LAN with login name/password and fingerprint authentication)

As shown in Figure 6, the FTP site in question is espionage.government.gov.

Figure 6: The Access Rule Definition screen in BorderManager.

The access controls in BorderManager are order sensitive. There is an implied "Deny All to All" at the bottom of the access control list. Figure 7 shows a sample populated access control list (an actual list would have a lot more entries).

Figure 7: A sample access control list.

To review everything, click on the Effective Rules button to display the rules as well as the implied Deny All. You will see a screen similar to the one shown in Figure 8.

Figure 8: The Effective Rules display.

For this particular configuration to work, BorderManager will need to provide an FTP proxy to the Espionage Data site. All users will have to authenticate to the proxy before access is granted. The Espionage FTP site has an ACL rule which only allows access if you are a member of the Espionage Policy (Group). That group was created in the last section and is updated dynamically. Depending on the environment and the level of desired security, the configuration can be quite deep and complex. Also critical to this policy is the fact that any unauthorized access to the FTP site can not only be blocked, but reported and audited.

Policy Enforcement from Without (iChain)

At this point, only part of the problem has been taken care of. Assume in this scenario that the policy has been modified to allow members of the Espionage department to retrieve Espionage data remotely. Also assume that remote Espionage department members must have two forms of authentication (a login name/password and a token card) to qualify for access to the data. Due to the sensitivity of the data, the solution will also require that the data communication be passed in an encrypted tunnel using SSL (Secure Sockets Layer).

A Novell product called iChain is used to provide this security and control over the resource from an external point of view. The particular Espionage resource is set up according to the desired configuration discussed (for example, two forms of authentication, must communicate over SSL, and the user must have his/her own computer). In order to verify that the computer used for access is a "company" computer, the policy also verifies the existence of a certificate on the browser.

iChain is configured with something called a web server accelerator (which corresponds to the internal site being protected and served by iChain-in this case, the Espionage Data server). The accelerator sets the policy for how many forms of authentication are required. Figure 9 shows an example of what this configuration might look like.

In this example, the configuration creates an SSL tunnel for encrypted data exchange via the Enable Secure Exchange setting. The browser's IP address is forwarded and multi-graded authentication (token and certificate) is required. Both authentication mechanisms are checked for validity before access is allowed. Any incorrect or invalid authentication request results in an immediate message to the system administrator, the security officer, or whichever persons or groups the system is configured to alert.

Sample iChain accelerator configuration.

Figure 10 shows the configuration of the authentication profiles.

Figure 10: Configuration of the Authentication Profiles.

The access type is defined in the Authorization Vault (eDirectory) configuration. Three possible access types can be defined in iChain:

  • Public - Anyone can access the site; no credentials required

  • Restricted - Users must authenticate; requires a valid set of credentials

  • Secure - Users must authenticate; requires a valid set of credentials; requires a rule (ACL) allowing access to the site

These configurations can be combined to provide complex authentication strategies. As an example, www.test.com\index.html may be configured as a public area to allow for a generic Web menu, while other areas within the URL (for example, www.test.com\admin\content.html) may be deemed as secure and require both authentication and policy allowing access.

As an example, the configuration screen in Figure 11 demonstrates the Espionage page configured for Secure access.

Figure 11: Sample configuration for Secure access to a protected resource.

Once the page has been configured for restricted access, an access rule must be created to allow certain users access to the site. As an example, the rule shown in Figure 12 has been created to allow the Espionage Department staff access to all content remotely except the security admin control section.

Figure 12: Sample Access Control rule configuration.

This configuration is dynamic; if John Q. Spy was hired one minute ago into the Espionage department, he would already have access to this content. If he were to be terminated, his access would be immediately revoked.

In the above example, each section is used to control access and security. For users who are not members of the Espionage department, a "Restricted Access" page can be displayed, or for more secure locations, a "dummy" page can be displayed with non-interesting content. The latter approach tends to discourage further attempts at security penetration.

Conclusion

This AppNote has presented a methodology for creating and enforcing an Internet acceptable use policy. If John Q. Spy were hired today and put into the proper department, the system described herein would automatically allow him to use appropriate services and view allowed data in the appropriate locations. The services and data that are accessible to John will change based on his location (internal, external, wireless, and so on) and on the type of authentication used (username and password, ID and fingerprint, certificate, and so on). If John retires, the services and data are immediately locked from his access.

It has been a complex journey to start from the business drivers in today's global corporate environment, work through a methodology to easily abstract and map these drivers to technology enablers, and arrive at the architecture required to support it. If anything, the issues and technological solution presented here may have been oversimplified. The goal of this AppNote was to provide a framework to help you approach and solve the problem, not to offer a definitive answer. As problems evolve, so too must the solutions.

* Originally published in Novell AppNotes


Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates