15.9 EFFECTIVE APPLICATIONS OF ENTERPRISE PATCH MANAGEMENT

15.9.1 Software Updates Defined

Efforts directed toward the updating and patching of an enterprise's applications represent a significant portion of IT expenditures. The Aberdeen group estimates that U.S businesses invest nearly 2 billion dollars annually towards these efforts. With the increase of self-propagating worms, and a social shift towards security awareness, this trend will likely continue for the foreseeable future. As such, patch management is an issue that simply cannot be ignored.

An organization is best equipped to respond to the release of software updates when it understands the differences between each type. Typically, there are three generally recognized categories of software updates:

Patches- Generally repair non-critical product defects.
Hot fixes -Typically address urgent or major product defects.
Service/Feature Packs - Cumulative updates bundling patches, hot fixes, and security updates.

Each of these varying update types serves a certain purpose and requires its own set of considerations. Administrators must evaluate the pros and cons of a given update before proceeding with its installation. A closer look at each update type is included below

15.9.1.1 Patches

Patches are generally defined as small application updates that include a stand-alone installation program. Under most circumstances patches may be installed using the provided installation routine, and activated through a restart of the affected application or device. Patches generally address application problems related to bugs , security, usability, or system stability. Prior to the release of a patch, the software publisher will typically perform a series of regression tests to eliminate any undesired effects from installation of the update. This testing is one of the main differentiators between patches and hot fixes. Additionally, patches may also address multiple application issues, and may contain updated versions of code previously released as a stand-alone hot fix.

Patches are generally the preferred method of delivering application updates as they provide a good balance between thoroughly tested code, and a reduced number of simultaneous application changes.

15.9.1.2 Hot Fixes

Hot fixes help to address the need for immediate issue resolution. While the release of patches is generally more controlled and regimented, hot fixes are provided on an as-needed basis. Their creation is driven by the discovery of critical defects, vulnerabilities, or significant usability problems. By solving or addressing concerns on a per problem basis, hot fixes are the instant gratification of software updates. However, such turn -around time often comes at the expense of thorough testing. In addition, hot fixes generally are provided without polished installation routines. In many cases, administrators are required to stop applications and replace or edit files by hand. This process presents ample opportunity for error, and requires that administrators manually backup files that have been modified or replaced . It is for these varying reasons that hot fixes should only be installed on an as-needed basis.

15.9.1.3 Service Packs

Service packs represent the bundling of a significant number of application updates within a single package. These releases are typically comprised of an accumulation of previous patches and hot fixes, in addition to unpublished content. In many cases a service pack will not only resolve previous problems, but may also introduce new functionality within patched applications. Due to the volume of changes introduced through a single service pack, these updates are typically the most thoroughly tested prior to release. Service packs are generally viewed as a convenient and effective method of assuring that a system is taken to an acceptable level of security and stability.

15.9.2 Obtaining Software Updates

As resource intensive and time consuming as patch application can be, it is further complicated by the task of locating required updates. Application updates can be obtained directly from software vendors , however, access to updates is typically only available when valid support and maintenance agreements are in place. This equates to increased total cost of ownership for nearly every application running within the enterprise. Hidden costs such as these must be factored into any application's purchase.

At first glance, the availability of application updates appears trivial. However, when administrators are required to maintain up to 100 or more applications, the simple act of checking for updates can pose a significant drain on available resources. The introduction of self-updating software has helped to eliminate many of these burdens at the client level, although, such techniques are rarely applicable to an organization's servers. In most all environments, availability requirements generally dictate that patches must be thoroughly tested prior to application. Consequently, administrators are often best served by subscribing to vendor mailing lists such that e- mails are delivered upon the release of product updates. By filtering these messages accordingly , administrators can stay up to date on a product's lifecycle with minimal efforts and little to no financial investment. Following such notices, updates can be downloaded, tested, and implemented. Another approach is to utilize a patch management application/service. These tools will centralize management and implementation of the patching process. Capabilities include alerting administrators when new patches are released and identifying which servers require updating. Although these systems can be expensive, costs are generally recouped through an increase in overall productivity of IT resources.

15.9.3 Strategies for Patch Management

Patch management strategies are often dictated by an organization's change management process. This is perfectly acceptable provided that the change process properly addresses the requisite testing and evaluation criteria. In situations where regimented change management procedures are not already in place, developing sound processes around patch management can help to lay the framework for such a program. Patch management includes procedures for assessing, testing, and installing application updates. Although there is some overlap, traditional patch management techniques serve to complement the overall vulnerability management strategy discussed earlier in this chapter. In the following sections, we will take a more detailed look at each major component of the patch management strategy.

15.9.3.1 Assessing for Required Updates

For most organizations the identification of machines that require patching is accomplished by conducting a vulnerability assessment. The results of these tests then dictate which machines will receive application updates. While this strategy can be effective, it does have limitations. Machines that are not connected to the network or powered on during the assessment may continue to run on the network in an unpatched state. As such, a system where devices report into a centralized location can be far more efficient. This is the basis behind many patch management applications. Under a number of these models, an agent application is installed onto both clients and servers. These agents periodically check in with a master patch server that is always aware of product updates for the enterprise's supported applications. Logs are then generated indicating which machines in the enterprise require updates. A system administrator may then consult these logs and deliver patches to all necessary machines at the click of a button.

15.9.3.2 Testing and Evaluation

Once required patches and target machines have been identified, updates must be tested and evaluated prior to installation. Even if installation of the update is as simple as a double click of the mouse, testing is a necessity, not a luxury. To make testing most effective, patches should be tested in a lab environment on systems with configurations that mirror the target system(s) as closely as possible. Even the most minor discrepancies can mean the difference between a successful test run and a problem-laden production installation.

During the testing process it is good practice to record all features tested, and any anomalies or major changes that result from an update's installation. This documentation helps to prove that reasonable precautionary measures were taken should there be any negative effects when the patch is placed into production. Factors that should be tested and documented during the evaluation process include:

System utilization
Traffic volumes
Uptime/availability
Application features utilized
System/application interdependencies

It may be exceptionally difficult to test all of the above items within a lab environment. However, an organization should make reasonable efforts to replicate real world conditions as closely as possible. Some examples include:

Use traffic generating applications and devices to help to address utilization and load issues.
Stress-test patched applications through scripted actions.
Request that regular operators of the application evaluate test systems.
Install required applications and manually test interdependencies.

15.9.3.3 Installing Updates

Assuming testing and evaluation proves successful, administrators must prepare to upgrade affected devices and focus on returning them to production as quickly as possible. By ensuring that the appropriate steps are taken, administrators can greatly reduce the likelihood of encountering a serious problem. The bulleted items below outline the installation process:

Establish a maintenance window
Notify appropriate parties
Back-up affected systems
Record log entries
Halt affected applications
Install required patches
Return device to production

Upgrades and change management are best accomplished at regularly scheduled intervals. Establishing a standard time-frame for maintenance windows ensures that the proper resources are available to complete required work. Additionally, this also ensures that end users adjust work-habits around scheduled activities. Each maintenance window should include a stop, start, and back out time. These steps can directly contribute to reducing the length of maintenance windows and increasing employee satisfaction.

Prior to beginning patch installation, and time permitting, a full system backup should be completed. This minimizes the opportunity for data loss in the event a critical failure was to occur. Next, employees involved in the initial testing and evaluation of updates should brief those performing the installation. In addition, all read-me files and documentation should be thoroughly evaluated. Lastly, it is best practice to contact software vendors and ensure that support contracts are current and up-to-date. This will help to reduce the time spent resolving any unexpected problems that could occur.

When installation is ready to begin, a notification should be sent to the system's stakeholders. An entry should also be placed into a log identifying the system's name and the date/time work began . Updates should be installed by following the manufacturer's documentation as closely as possible. Providing time permits , updates should also be installed with full back-out capabilities.

After installation is complete, any remaining time in the maintenance window should be used to test and evaluate the system. In the event the upgrade proves unsuccessful , efforts must be underway to return the system to its original configuration when the previously established back out time is reached. If this occurs, further testing will be required and an additional window should be opened to schedule a second attempt. Stakeholders should be notified and change logs updated upon closure of any maintenance window.

15.9.4 Managing Security Incidents across the Enterprise

Regardless of the internal controls and security policy in place, an organization must always be prepared for the possibility of system compromise or network misuse. Monitoring for and identifying such activity requires more than just a tactical implementation of network based intrusion protection systems. In fact, HIP A A security rules promote a defense- in-depth approach towards protecting information assets. As such, organizations must strongly consider the application of intrusion protection technologies a strategic IT initiative. After-all, it is these technologies that can make the difference between identifying an attackers activities in real-time, or finding out weeks or months after compromise has occurred.

15.9.5 Monitoring and Response

The monitoring process marks the beginning of security incident remediation and escalation procedures. The mere deployment of intrusion protection technology provides little to no benefit without resources capable of providing 24/7 monitoring and escalation. However, many organizations find it difficult to justify the costs required to support such an ongoing operation. The truth of the matter is that these activities extend so far beyond most organization's core competencies, that they are frequently best outsourced to a security service provider.

Whether you choose to insource or outsource, the organization's management and IT/security teams must be aware of monitoring activities. For these initiatives to be adequately supported, those monitoring must be provided with a multitude of information. Documents such as network diagrams, critical server lists, acceptable use policies, and escalation diagrams all prove invaluable when attempting to assess risk through a network monitoring tool. Without this information on hand, analysts are required to adopt an 'assess and guess' methodology that generally results in a high degree of false alarm escalations. Even with the support of the organization, a fledgling IPS monitoring initiative may still result in unacceptable numbers of false alarms. However, the primary distinction is that with the required support in place, policies can be tuned and escalation procedures refined, such that this number will drop to acceptable levels within 30 to 60 days of most implementations .

Monitoring for intrusions requires continuous vigilance on behalf of security analysts. Each event must be examined and scrutinized such that it may be classified as an incident or dismissed as a false alarm. Events that cannot be immediately dismissed should trigger a comprehensive review of vulnerability data, past security incidents, network diagrams, and current attack trends. These requirements lay the framework for a 7 step analysis and response process.

Analyze decode data
Analyze the source address
Analyze the destination address
Prioritize the issue
Escalate
Document
Notify Service Provider

Below, we will take a closer look at each of the seven phases, and begin to outline the depth involved in investigating each event generated by an IPS system.

15.9.5.1 Analyzing Decode Data

When potentially malicious traffic is identified, a security analyst must examine the provided dataset for detail that points to the validity of the reported attack. Such information may come in the form of URLs, files executed, accounts accessed, etc. It is at this point that the analyst's expertise and understanding of the signature set becomes invaluable. If decode data does not indicate that a given attack was successful, analysis of the event may cease at this point.

15.9.5.2 Analyzing the Source Address

After confirming the validity of attack, analysts must begin to examine the source and destination addresses involved in the activity. When examining the source of a given attack, an analyst must identify the originating IP space, IP owners , and any related domain registration information. This analysis should be completed in the context of what is known to be normal for the network, such that traffic originating from an uncommon locale may be looked at with heightened suspicion.

15.9.5.3 Analyzing the Destination Address

An analyst should consult all available resources when examining the target address of an attack; this includes network diagrams, critical server lists and acceptable use policies. In addition, previous escalations should be consulted as this documentation may help to indicate how the targeted system previously withstood a similar attack.

15.9.5.4 Prioritizing the Issue

At this stage, analysts will typically have a solid understanding of what risk a given attack poses against the overall stability and integrity of the enterprise. Prior to escalating, however, the attack should be formally classified. These classifications will help to form the basis of response and remediation procedures. While there are many schools of thought surrounding how granularly events should be prioritized, event classification is truly a situation where simpler is better. As each security incident is slightly different than the last, it becomes increasingly difficult to maintain consistency across analysts when the scale is too detailed. As such, the following three point scale is recommended:

Priority 1 Security Incident- Security incidents at this level are actionable , high-risk events that have the potential to cause severe damage to an organization's environment. Investigations that result in classification to this category require immediate defensive actions. System or data compromises, worm infections/propagation, massive denial of service (DOS) attacks, and similar incidents are grouped into this classification.
Priority 2 Security Incident- This is the lowest level of actionable incidents generated by the analyst team. Incidents at this level require customers to take action within 12-24 hours of notification. Incidents such as unauthorized local scanning activity and attacks targeted at specific servers or workstations are grouped into this category.
Priority 3 Suspicious Activity- This category of investigation encompasses activity on a network or server that is not directly actionable. Discovery and vulnerability scanning, information gathering scripts, and other reconnaissance probes are grouped into this classification.

15.9.5.5 Escalation and Response

Escalating a given security incident in this context refers to notifying the appropriate parties so that response and remediation procedures can be followed. To ensure that the right parties are reachable at all times, analysts should always have on-hand a list of escalation points with multiple forms of contact. All individuals on this list must be completely aware of their duties and responsibilities should they be contacted. Analysts should escalate all priority 1 and 2 issues via telephone and e-mail, and priority 3 issues via e-mail only. When escalating via telephone, voice mail and message should be left wherever possible. In the event the contact lists is exhausted without success, a procedure for escalating beyond the list should exist.

When appropriate parties have been contacted, the response and remediation process begins. Responding to a given incident typically involves examining affected machines for evidence of compromise, and closing off any vulnerabilities that may be present. This effectively leverages the vulnerability management and patch management programs previously discussed. As the response process may require communication across multiple levels of the organization, individuals responsible for incident response must be recognized accordingly. Further, as the process is very technical, the mechanics of a forensic investigation will not be covered in this book.

In the event of system compromise and identifiable losses, contacting outside authorities should be considered a requisite activity. Such a contact provides the means to bring responsible parties to justice, and may allow an organization to initiate claims against its cyber-insurance policies. The United States Department of Justice recommends that crimes committed across the Internet be reported to appropriate agencies at the local, state, federal, and international levels, commensurate with the scope of the reported criminal activity. A detailed matrix of agency authority is available directly from the DOJ at http://www. usdoj .gov/criminal/ cybercrime /reporting.htm.

15.9.5.6 Documentation

All incidents should be documented in a single location. A trouble ticketing system is highly recommended for the purpose of documenting all relevant event data. Analysts should record all of the following in addition to any details specific to their environment:

Dates/Times
IP addresses
Ports
Attack names
IP and domain ownership
Investigations completed
Actions Taken
Impacts of the incident
Response and remediation actions taken

Tickets generated for each escalation will form the foundation for any actions that must be taken outside of the organization. This includes but is not limited to contact of outside authorities and legal actions. These reasons alone provide the justification for thorough documentation. However, as escalations of incidents can be a detailed and time consuming process, documentation also serves to properly justify resource allocations and a return on the organization's investment

15.9.5.7 Notifying Service Providers

The final step of the escalation and response process can be completed by the monitoring analysts while designated contacts are working through the initial response process. Notifying the offending Internet service provider serves as a means to place a halt on malicious activity and network misuse. In most cases attacks have ceased by the time the ISP is contacted, however, this step still allows the ISP to take after-the-fact corrective actions. These steps may minimize the potential for a repeat occurrence of the activity at a later point in time. ISPs should generally be contacted via e-mail; however a telephone call is warranted provided the activity is ongoing or severe in nature.

15.9.6 User Account Management

In order to function effectively, each organization must provide the necessary information access requirements for its users. Conversely, it is incumbent upon the organization to ensure that these access requirements are limited. Limitations should be based on the concept of least privilege where authorizations are granted contingent upon an individual's minimum necessary access requirements. This means that user account access requirements should only include that information that is necessary to fill each individual role within the organization. The concept of role based access control is used to limit user account access to one or more specific roles-a role being defined as a specific set of access authorizations required to fulfill a job function.

15.9.6.1 User Registration and Deregistration Process

To meet the least privilege access requirements, each organization must codify the specific processes for user registration and deregistration. Each user should be identified using a unique user ID so that actions may be tracked to a specific user and not a group of individuals. Each user should be made aware of his/her responsibilities and the organization's policies with regard to the acceptable use of the organization's information assets. Each user should also sign a formalized statement acknowledging his/her understanding of the organization's acceptable use policy. Also, account termination should occur immediately upon the voluntary termination or dismissal of any individual.

The user registration and deregistration processes must also encompass the procedures around which least privilege access is maintained when an individual changes roles within the organization. All too frequently, as an individual's access requirements change and new rights are granted; former rights are not revoked . This creates a situation where an individual gains unnecessary access rights as he/she moves within the organization. To combat this problem, a formalized process should be instated via technical and/or non-technical means to periodically review the access rights of individual user accounts.

15.9.6.2 Password Management

As discussed above, each user must be uniquely identified on the organization's systems. This identification is tied to the individual's specific role based authorizations. In order to validate that an individual making use of the user account is the same as the individual that owns the account, some form of authentication mechanism must be utilized. Authentication is generally based upon one or more of the three following principles:

Something the user knows (a secret such as a password, Personal Identification Number (PIN), or cryptographic key)
Something the user possesses (a token such as a SecurID card, key fob or smart card)
Something the individual is (a biometric such as a fingerprint , voice pattern or retinal characteristics)

The most common method of authenticating a user's identity is via the use of a password. The use of passwords should be controlled by a formal management process. This management process should include the method(s) by which initial passwords are securely given to users. These initial passwords should only be temporary and require a change after their initial use.

The complexity and expiration requirements of the organization's passwords should be developed based upon a reasonable assessment of the risks associated with password compromise. These requirements should be provided to all users along with a signed acknowledgement of the user's responsibilities regarding the creation, use, confidentiality and protection of passwords. This acknowledgement should be supported by appropriate awareness training related to password protection. Additionally, the organization's complexity and expiration requirements should be enforced by technical means whenever possible.

Procedures for resetting passwords should include an identity validation process. This could include callback, a challenge/response system or management approval for password resets.

15.9.6.3 Review of Account Access Privileges

To ensure that inactive user accounts do not remain active, an account review mechanism should be used to locate and disable inactive or invalid user accounts. This validation process should be used annually for user accounts, and quarterly for accounts with administrative privileges. This mechanism should identify accounts that have:

Never been accessed
Have been inactive for a time period in violation of the organization's policy
Have access rights that are not accurate with regard to least privilege
Belong to an individual that is no longer in the organization's employ

All inactive and invalid accounts should then be either disabled or updated.

15.9.7 Disaster Recovery and Business Continuity Plans

To prevent an extended interruption to normal operations, every organization must develop and continually review its Disaster Recovery and Business Continuity Plans (DRP/BCP). A disaster is described as any accidental, natural or malicious event that threatens or disrupts normal business operations for sufficient time as to significantly affect or cause failure of the specific business operations. This plan should be considered a living document that requires continual testing and revision to ensure that if remains accurate and effective.

15.9.7.1 Business Impact Analysis

Business Continuity Planning begins with a thorough Business Impact Analysis (BIA). The BIA determines the financial exposures and operational impacts resulting from major business disruptions. This analysis helps each department or business unit identify its time sensitive functions and services, determine timeframes in which those functions and services must resume and estimate the resources necessary for successful resumption and recovery.

15.9.7.2 DR/BCP Planning Framework

Business Continuity Plans should be developed using a consistent framework across the organization. Each plan should clearly identify the circumstances necessary to activate the plan, and the specific individuals responsible for initiating the plan and carrying out its components . Events that might initiate the plan include natural disasters, accidental or intentional technical events, internal or external human threats, etc. The location(s) of recovery sites, contact names, vendor information, insurance information and required documentation must all be outlined in the plan. The Business Continuity Planning framework should include:

Response Procedures- the steps outlining the immediate reaction to an incident or emergency. The response procedures should include the following:
- Protection of personnel
- Containment of the incident
- Assessment of the effect
- Decisions on the optimum actions to be taken
- Crisis communication with stakeholders (including media)
- Taking account of the powers of public authorities

Resumption Procedures-the steps for implementing the recovery of critical business operations immediately following a disaster or major interruption. The resumption procedure should include the following:
- Manual procedures for accomplishing certain critical business processes

Recovery Procedures-the steps necessary to resume less time critical functions/servers/systems/processes in the days/weeks following a disaster. Recovery procedures should include:
- How to recover data since the previous back up period
- Manual and automated recovery procedures to meet timeframe criticality requirements

Restoration Procedures-the steps necessary for repair or relocation of the primary site and the restoration of normal operations.

15.9.7.3 Testing

Finally, the procedures for testing and maintaining the plan should be made part of each Business Continuity Plan. The results of all tests should be kept and analyzed for the purpose of improving the plan and identifying the necessary training required to prevent a successful return to normal operations should a major disruption occur.

15.9.7.4 Compliance Issues

Each organization should have a defined process for identifying any applicable laws or regulations with regard to its information systems. This process should include the responsible roles in the organization for investigating the legal, contractual and regulatory compliance of its information systems operations. The identified compliance requirements should then be documented for each identified system. To assist in this process, the organization should maintain contact with suitable external resources in addition to internal legal counsel. The organization's security policy should be updated, as necessary, to mandate compliance with any relevant statutory , regulatory or contractual requirements.

15.9.7.5 Compliance with Intellection Property Rights

A specific area of compliance that should be addressed is the liability associated with the use, and misuse, of copyrighted information. The organization should take steps to ensure compliance with any applicable restrictions under intellectual property right protection, including licenses, copyrights, trademarks, etc.

In addition to explicit policies prohibiting copyright infringement and unlicensed software, the organization should keep proper records of the software licenses in use. To help ensure compliance with copyright policy, the user community should be provided with recurring training that includes specific explanation as to why it is vital to the organization to maintain compliance with licenses and copyrights.

15.9.7.5.1 Evidence Collection

If the organization has made the determination that it would like to be prepared to take legal action against a person or organization regarding its information assets, specific rules of collection must be followed. Evidence gathered outside of the rules of admissibility will be of little use in a legal proceeding.

Improperly or illegally collected evidence can lead to unnecessary legal exposure and reputation loss. The rules of admissibility may vary slightly by court , but will all have specific requirements regarding admissibility, quality and custody. Generally, evidence should only be gathered by personnel that have been trained in the proper collection and preservation of evidence. To achieve this, proper contacts should be maintained with suitable third parties and law enforcement. All evidence discovered needs to be collected, including exculpatory evidence which points to any mistakes made by the collector. Failure to collect and preserve all forms of evidence can not only lead to an unsatisfactory investigation outcome, but legal exposure to the collector and the organization. Marking, dating and properly entering evidence into the chain of custody is critical. The collector must be able to positively identify all collected evidence at a subsequent hearing or legal proceeding.

Be advised that the decision to include law enforcement in an investigation is a decision to relinquish control of the organization's information assets for the duration of the proceedings . Law enforcement should only be contacted on the advice of legal counsel, and with appropriate executive approval according to the organization's incident management practices.

Compliance with the organization's policies is an important measuring tool for proper risk management within the organization. Each functional unit within the organization should then review its operations with regard to policy compliance. Any gaps identified between the security policy and the current operation should be documented as such and remediated to unnecessary exposure.

15.9.7.6 Vendor and Contractor Relationships

Granting access to a vendor or contractor can place the organization's information at risk. Such risk arises when a third party's security controls and management do not meet the necessary criteria as defined by the organization's risk model. The decision to grant third party access should only be done when a business need arises and after an assessment of the associated risks has been completed. This risk assessment may include review of the security controls and security management in place at the third party's physical site. If the third party makes use of one or more subcontractor, an appropriate assessment of relevant risks should be conducted as well.

In all cases, a third party should not be granted access until appropriate controls have been applied and a suitable agreement has been signed between both parties.

15.9.7.6.1 Third Party Agreements

To ensure the proper protection of the organization's information assets, the security responsibilities and requirements for third party access should be explicitly defined in a fully executed contract prior to gaining access to the organization's facilities. The contract should be written to ensure that the third party agrees to comply with the organization's security policies, standards and practices. When possible, specific requirements should be defined so that there is no confusion regarding third party security responsibility.

Minimally, the contract should contain the following provisions:

Policy Compliance-All third parties should agree to follow all of the organization's security policies and practices. Specific components and training requirements of the security policy may also be included in the agreement.
Legal Responsibilities and Liabilities-The contract should outline each party's responsibilities regarding any applicable legislation or regulation. In addition, the respective liabilities of each party should be defined.
Intellectual Property Rights-The contract should outline the compliance responsibility with any licenses or copyrights. In addition, any collaborative work should be protected by Intellectual Property Rights as defined in the agreement.
Non-Disclosure and Confidentiality Requirements-Appropriate language should define each party's confidentiality requirements with regard to information that may be obtained or controlled. This provision should also include responsibilities for handling, returning or destructing data once the service obligation is completed.
Service Level Requirements-The services to be performed, as well as specific levels of service, should be defined in the agreement. If hardware or software will be installed, the appropriate responsibilities should be defined including compliance with licenses and copyrights.
Issue Resolution-The process for resolving issues and reporting service status should be described.
Change Management-The organization's Change Management requirements and processes with respect the third party's activities should be clearly outlined.
User Management and Access Control Requirements-The methods and requirements for third party user access should be defined. The contract should mandate that the third party maintain a fiduciary responsibility for the staff that they permit to gain access to the organization's information.
Physical Access Requirements-Any physical access control requirements should be detailed in the agreement.
Malicious Code Control Requirements-Appropriate controls against malicious code must be used if a third party will be given access to the organization's information assets. At a minimum, this must include the use of current anti-virus protection.
Right to Audit and Monitor-The organization should maintain the right to audit the third party's security controls. In addition, the organization should maintain the right to monitor activities related to its information and to revoke access if contractual obligations are not met.
Incident Management Responsibilities-The mutual responsibilities in identifying, reporting and handling security incidents should be detailed in the agreement.
Subcontractors-Third party agreements should address the third party use of subcontractors .