1. Purpose

This policy establishes the information security requirements to help manage and safeguard lab resources and XXX’s networks by minimizing the exposure of critical infrastructure and information assets to threats that may result from unprotected hosts and unauthorized access.

2. Scope

This policy applies to all employees, contractors, consultants, temporary and other workers at XXX and its subsidiaries must adhere to this policy. This policy applies to XXX owned and managed labs, including labs outside the corporate firewall (DMZ). 

3. Policy

3.1 General Requirements

1. Lab owning organizations are responsible for assigning lab managers, a point of contact (POC), and a back-up POC for each lab. Lab owners must maintain up-to-date POC information with IT and the Corporate Enterprise Management Team. Lab managers or their backup must be available around-the-clock for emergencies, otherwise actions will be taken without their involvement.
2. Lab managers are responsible for the security of their labs and the lab’s impact on the corporate production network and any other networks. Lab managers are responsible for adherence to this policy and associated processes. Where policies and procedures are undefined lab managers must do their best to safeguard XXX from security vulnerabilities.
3. Lab managers are responsible for the lab’s compliance with all XXX security policies.
4. The Lab Manager is responsible for controlling lab access. Access to any given lab will only be granted by the lab manager or designee, to those individuals with an immediate business need within the lab, either short-term or as defined by their ongoing job function. This includes continually monitoring the access list to ensure that those who no longer require access to the lab have their access terminated.
5. All user passwords must comply with XXX’s Password Policy.
6. Individual user accounts on any lab device must be deleted when no longer authorized within three (3) days. Group account passwords on lab computers (Unix, windows, etc) must be changed quarterly (once every 3 months).
7. PC-based lab computers must have XXX’s standard, supported anti-virus software installed and scheduled to run at regular intervals. In addition, the anti-virus software and the virus pattern files must be kept up-to-date. Virus-infected computers must be removed from the network until they are verified as virus-free. Lab Admins/Lab Managers are responsible for creating procedures that ensure anti-virus software is run at regular intervals, and computers are verified as virus-free.
8. Any activities with the intention to create and/or distribute malicious programs into XXX’s networks (e.g., viruses, worms, Trojan horses, e-mail bombs, etc.) are prohibited, in accordance with the Acceptable Use Policy.
9. No lab shall provide production services. Production services are defined as ongoing and shared business critical services that generate revenue streams or provide customer capabilities.
10. In accordance with the Data Classification Policy, information that is marked as Highly Confidential or  Restricted is prohibited on lab equipment.
11. Immediate access to equipment and system logs must be granted to members of IT and the Network Support Organization upon request, in accordance with the Audit Policy.
12. IT will address non-compliance waiver requests on a case-by-case basis and approve waivers if justified.

3.2 Internal Lab Security Requirements

1. The Network Support Organization must maintain a firewall device between the corporate production network and all lab equipment.
2. The Network Support Organization reserve the right to interrupt lab connections that impact the corporate production network negatively or pose a security risk.
3. The Network Support Organization must record all lab IP addresses, which are routed within  XXX’s  networks, in Enterprise Address Management database along with current contact information for that lab.
4. Any lab that wants to add an external connection must provide a diagram and documentation to IT with business justification, the equipment, and the IP address space information. IT will review for security concerns and must approve before such connections are implemented.
5. All traffic between the corporate production and the lab network must go through a Network Support Organization maintained firewall. Lab network devices (including wireless) must not cross-connect the lab and production networks.
6. Original firewall configurations and any changes thereto must be reviewed and approved by IT. IT may require security improvements as needed.
7. Labs are prohibited from engaging in port scanning, network auto-discovery, traffic spamming/flooding, and other similar activities that negatively impact the corporate network and/or non-XXX’s networks. These activities must be restricted within the lab.
8. Traffic between production networks and lab networks, as well as traffic between separate lab networks, is permitted based on business needs and as long as the traffic does not negatively impact on other networks. Labs must not advertise network services that may compromise production network services or put lab confidential information at risk.
9. IT reserves the right to audit all lab-related data and administration processes at any time, including but not limited to, inbound and outbound packets, firewalls and network peripherals.
10. Lab owned gateway devices are required to comply with all XXX’s product security advisories and must authenticate against the Corporate Authentication servers.
11. The enable password for all lab owned gateway devices must be different from all other equipment passwords in the lab. The password must be in accordance with XXX’s Password Policy. The password will only be provided to those who are authorized to administer the lab network.
12. In labs where non-XXX personnel have physical access (e.g., training labs), direct connectivity to the corporate production network is not allowed. Additionally, no confidential information can reside on any computer equipment in these labs. Connectivity for authorized personnel from these labs can be allowed to the corporate production network only if authenticated against the Corporate Authentication servers, temporary access lists (lock and key), SSH, client VPNs, or similar technology approved by IT.
13. Lab networks with external connections are prohibited from connecting to the corporate production network or other internal networks through a direct connection, wireless connection, or other computing equipment.

3.3 Lab Anti virus policy

All XXX PC-based lab computers must have XXX’s standard, supported anti-virus software installed and scheduled to run at regular intervals. In addition, the anti-virus software and the virus pattern files must be kept up-to-date. Virus-infected computers must be removed from the network until they are verified as virus-free. Lab Admins/Lab Managers are responsible for creating procedures that ensure anti-virus software is run at regular intervals, and computers are verified as virus-free. Any activities with the intention to create and/or distribute malicious programs into XXX’s networks (e.g., viruses, worms, Trojan horses, e-mail bombs, etc.) are prohibited, in accordance with the Acceptable Use Policy.

3.4 DMZ Lab Security Requirements

3.4.1 Ownership and Responsibilities

1. All new DMZ Labs must present a business justification with sign-off at the business unit Vice President level. The IT Team must keep the business justifications on file.
2. Lab owning organizations are responsible for assigning lab managers, point of contact (POC), and back up POC, for each lab. The lab owners must maintain up to date POC information with the IT Team [and the corporate enterprise management system, if one exists]. Lab managers or their backup must be available around-the-clock for emergencies.
3. Changes to the connectivity and/or purpose of existing DMZ Labs and establishment of new DMZ Labs must be requested through a XXX Network Support Organization and approved by the IT Team.
4. All ISP connections must be maintained by a XXX Network Support Organization.
5. A Network Support Organization must maintain a firewall device between the DMZ Lab(s) and the Internet.
6. The Network Support Organization and The IT Team reserve the right to interrupt lab connections if a security concern exists.
7. The DMZ Lab will provide and maintain network devices deployed in the DMZ Lab up to the Network Support Organization point of demarcation.
8. The Network Support Organization must record all DMZ Lab address spaces and current contact information [in the corporate enterprise management system, if one exists].
9. The DMZ Lab Managers are ultimately responsible for their DMZ Labs complying with this policy.
10. Immediate access to equipment and system logs must be granted to members of  the IT Team and the Network Support Organization upon request, in accordance with the Audit Policy
11. Individual lab accounts must be deleted within three (3) days when access is no longer authorized. Group account passwords must comply with the Password Policy and must be changed within three (3) days from a change in the group membership.
12. The IT Team will address non-compliance waiver requests on a case-by-case basis.

3.4.2 General Configuration Requirements

1. Production resources must not depend upon resources on the DMZ Lab networks.
2. DMZ Labs must not be connected to XXX’s corporate internal networks, either directly or via a wireless connection.
3. DMZ Labs should be in a physically separate room from any internal networks. If this is not possible, the equipment must be in a locked rack with limited access. In addition, the Lab Manager must maintain a list of who has access to the equipment.
4. Lab Managers are responsible for complying with the following related policies:
   1. Password Policy
   1. Wireless Communications Policy
   1. Lab Policy
5. The Network Support Organization maintained firewall devices must be configured in accordance with least-access principles and the DMZ Lab business needs. All firewall filters will be maintained by the IT Team.
6. The firewall device must be the only access point between the DMZ Lab and the rest of XXX’s networks and/or the Internet. Any form of cross-connection which bypasses the firewall device is strictly prohibited.
7. Original firewall configurations and any changes thereto must be reviewed and approved by the IT Team (including both general configurations and rule sets). The IT Team may require additional security measures as needed.
8. Traffic from DMZ Labs to the XXX internal network, including VPN access, falls under the Remote Access Policy
9. All routers and switches not used for testing and/or training must conform to the DMZ Router and Switch standardization documents.
10. Operating systems of all hosts internal to the DMZ Lab running Internet Services must be configured to the secure host installation and configuration standards. [Add url link to site where your internal configuration standards are kept].
11. Current applicable security patches/hot-fixes for any applications that are Internet services must be applied. Administrative owner groups must have processes in place to stay current on appropriate patches/hotfixes.
12. All applicable security patches/hot-fixes recommended by the vendor must be installed. Administrative owner groups must have processes in place to stay current on appropriate patches/hotfixes.
13. Services and applications not serving business requirements must be disabled.
14. XXX Confidential information is prohibited on equipment in labs where non-XXX personnel have physical access (e.g., training labs), in accordance with the Data Classification and Protection Policy.
15. Remote administration must be performed over secure channels (e.g., encrypted network connections using SSH or IPSEC) or console access independent from the DMZ networks.

3.5 DMZ Equipment Policy

3.5.1 General Configuration Policy

All equipment must comply with the following configuration policy:

• Hardware, operating systems, services and applications must be approved by IT as part of the pre-deployment review phase.
• Operating system configuration must be done according to the secure host and router installation and configuration standards [Insert a reference to any standards that you have]
• All patches/hot-fixes recommended by the equipment vendor and IT must be installed. This applies to all services installed, even though those services may be temporarily or permanently disabled. Administrative owner groups must have processes in place to stay current on appropriate patches/hotfixes.
• Services and applications not serving business requirements must be disabled.
• Trust relationships between systems may only be introduced according to business requirements, must be documented, and must be approved by IT.
• Services and applications not for general access must be restricted by access control lists.
• Insecure services or protocols (as determined by IT) must be replaced with more secure equivalents whenever such exist.
• Remote administration must be performed over secure channels (e.g., encrypted network connections using SSH or IPSEC) or console access independent from the DMZ networks. Where a methodology for secure channel connections is not available, one-time passwords must be used for all access levels.
• All host content updates must occur over secure channels.
• Security-related events must be logged and audit trails saved to IT-approved logs. Security-related events include (but are not limited to) the following:
  • User login failures.
  • Failure to obtain privileged access.
  • Access policy violations.
• IT will address non-compliance waiver requests on a case-by-case basis and approve waivers if justified.

3.5.2 New Installations and Change Management Procedures

All new installations and changes to the configuration of existing equipment and applications must follow the following policies/procedures:

• New installations must be done via the DMZ Equipment Deployment Process.
• Configuration changes must follow the Corporate Change Management (CM) Procedures.
• IT must be invited to perform system/application audits prior to the deployment of new services.
• IT must be engaged, either directly or via CM, to approve all new deployments and configuration changes.

3.5.3 Equipment Outsourced to External Service Providers

The responsibility for the security of the equipment deployed by external service providers must be clarified in the contract with the service provider and security contacts, and escalation procedures documented. Contracting departments are responsible for third party compliance with this policy.

4. Policy Compliance

4.1 Compliance Measurement

The IT team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.

4.2 Exceptions

Any exception to the policy must be approved by the Infosec team in advance.

4.3 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

1.     Overview

XXX is committed to protecting employees, partners, vendors and the company from illegal or damaging actions by individuals, either knowingly or unknowingly.  When XXX addresses issues proactively and uses correct judgment, it will help set us apart from competitors. XXX will not tolerate any wrongdoing or impropriety at any time.  XXX will take the appropriate measures act quickly in correcting the issue if the ethical code is broken. 

2.     Purpose

The purpose of this policy is to establish a culture of openness, trust and to emphasize the employee’s and consumer’s expectation to be treated to fair business practices.  This policy will serve to guide business behavior to ensure ethical conduct. Effective ethics is a team effort involving the participation and support of every XXX employee.  All employees should familiarize themselves with the ethics guidelines that follow this introduction.

3.     Scope

This policy applies to employees, contractors, consultants, temporaries, and other workers at XXX, including all personnel affiliated with third parties.

4.     Policy

4.1 Executive Commitment to Ethics

1. Senior leaders and executives within XXX must set a prime example.  In any business practice, honesty and integrity must be top priority for executives.
2. Executives must have an open door policy and welcome suggestions and concerns from employees.  This will allow employees to feel comfortable discussing any issues and will alert executives to concerns within the work force.
3. Executives must disclose any conflict of interests regard their position within XXX

4.2 Employee Commitment to Ethics

1. XXX employees will treat everyone fairly, have mutual respect, promote a team environment and avoid the intent and appearance of unethical or compromising practices.
2. Every employee needs to apply effort and intelligence in maintaining ethics value.Employees must disclose any conflict of interests regard their position within XXX
3. Employees will help XXX to increase customer and vendor satisfaction by providing quality product s and timely response to inquiries.
4. Employees should consider the following questions to themselves when any behavior is questionable:
   • Is the behavior legal?
   • Does the behavior comply with all appropriate XXX policies?
   • Does the behavior reflect XXX values and culture?
   • Could the behavior adversely affect company stakeholders?
   • Would you feel personally concerned if the behavior appeared in a news headline?
   • Could the behavior adversely affect XXX if all employees did it?

4.3 Company Awareness

1. Promotion of ethical conduct within interpersonal communications of employees will be rewarded.
2. XXX will promote a trustworthy and honest atmosphere to reinforce the vision of ethics within the company.

4.4 Maintaining Ethical Practices

1. XXX will reinforce the importance of the integrity message and the tone will start at the top.  Every employee, manager, director needs consistently maintain an ethical stance and support ethical behavior.
2. Employees at XXX should encourage open dialogue, get honest feedback and treat everyone fairly, with honesty and objectivity. 
3. XXX has established a best practice disclosure committee to make sure the ethical code is delivered to all employees and that concerns regarding the code can be addressed.
4. Employees are required to recertify their compliance to Ethics Policy on an annual basis.

4.5 Unethical Behavior

1. XXX will avoid the intent and appearance of unethical or compromising practice in relationships, actions and communications. 
2. XXX will not tolerate harassment or discrimination.Unauthorized use of company trade secrets & marketing, operational, personnel, financial, source code, & technical information integral to the success of our company will not be tolerated.
3. XXX will not permit impropriety at any time and we will act ethically and responsibly in accordance with laws.
4. XXX employees will not use corporate assets or business relationships for personal use or gain.

5.     Policy Compliance

5.1 Compliance Measurement

The CISO will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback.

5.2  Exceptions

None.

5.3  Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

1 Policy.

The protection of the physical environment is one of the most obvious yet most important tasks within the area of information security. A lack of physical access control can undo the most careful technical precautions and potentially put lives at risk. XXX is committed to ensuring the safety of its employees, contractors and assets and takes the issue of physical security very seriously. This policy sets out the main precautions that must be taken and, together with the supporting documented listed, forms a significant part of our Information Security Management System (ISMS). This control applies to all systems, people and processes that constitute the organization’s information systems, including board members, directors, employees, suppliers and other third parties who have access to XXX systems.

1.1 Secure areas
Information must be stored securely according to its classification. A risk assessment must be conducted to identify the appropriate level of protection to be implemented to secure the information being stored. Physical security must begin with the building itself and an assessment of perimeter vulnerability must be conducted. A building must have appropriate control mechanisms in place for the classification of information and equipment that is stored within it. These may include, but are not restricted to, the following:

• Alarms fitted and activated outside working hours
• Window and door locks
• Window bars on lower floor levels

Access control mechanisms fitted to all accessible doors (where codes are utilized they should be regularly changed and known only to those people authorized to access the area/building)

• CCTV cameras
• Staffed reception area
• Protection against damage – e.g. fire, flood, vandalism
• Staff working in secure areas must challenge anyone not wearing a badge.

Identification and access tools/passes (for example badges, keys, entry codes etc.) must only be held by persons authorized to access those areas and must not be loaned/provided to anyone else. Visitors to secure areas are required to sign in and out with arrival and departure times and are required to wear an identification badge. An organization employee must always monitor all visitors accessing secure areas. Keys to all secure areas housing IT equipment and lockable IT cabinets are held centrally by the Service Provider as appropriate. Where breaches do occur, or an employee leaves outside normal termination circumstances, all identification and access tools/passes (for example badges, keys etc.) must be recovered from the employee and any door/access codes should be changed immediately.

1.3 Paper and equipment security
Paper based (or similar non-electronic) information must be assigned an owner and a classification. Appropriate information security controls must be put in place to protect it according to the provisions in the Asset Handling Procedure. Paper in an open office must be protected by the controls for the building and via appropriate measures that could include, but are not restricted to, the following:

• Filing cabinets that are locked with the keys stored away from the cabinet
• Locked safes
• Stored in a secure area protected by access controls

All general computer equipment must be located in suitable physical locations that:

• Limit the risks from environmental hazards – for example heat, fire, smoke, water, dust and vibration
• Limit the risk of theft-e.g. if necessary, items such as laptops should be physically attached to the desk
• Allow workstations handling sensitive data to be positioned so as to eliminate the risk of the data being seen by unauthorised people.

Data must be stored on network file servers or approved cloud locations where available. This ensures that information lost, stolen or damaged via unauthorized access can be restored and its integrity maintained. All servers located outside of the data centre in XXX’s premises must be sited in a physically secure environment. All servers located outside of the data centre in XXX’s premises must be sited in a physically secure environment. Business critical systems must be protected by an Un-interruptible Power Supply (UPS) to reduce the operating system and data corruption risk from power failures. All items of equipment must be recorded in the Service Provider inventory. Procedures must be in place to ensure the inventory is updated as soon as assets are received or disposed of. All equipment must be security marked and have a unique asset number allocated to it. This asset number must be recorded in the Service Provider inventory. Cables that carry data or support key information services must be protected from interception or damage. Power cables must be separated from network cables to prevent interference. Network cables must be protected by conduit and where possible avoid routes through public areas.

1.4 Equipment life cycle management
Service Provider and third-party suppliers must ensure that all of XXX’s IT equipment is maintained in accordance with the manufacturer’s instructions and any documented internal procedures to ensure it remains in effective working order. Staff involved with maintenance must:

• Retain all copies of manufacturer’s instructions
• Identify recommended service intervals and specifications
• Enable a call-out process in event of failure
• Ensure only authorised technicians complete any work on the equipment
• Record details of all remedial work carried out
• Identify any insurance requirements
• Record details of faults incurred and actions required

A service history record of equipment must be maintained so that decisions can be made regarding the appropriate time for it to be replaced. Manufacturer’s maintenance instructions must be documented and available for support staff to use when arranging repairs. The use of equipment off-site must be formally approved by the user’s line manager. Equipment that is to be reused or disposed of must have all its data and software erased / destroyed. If the equipment is to be passed onto another organization (for example returned under a leasing agreement) data removal must be achieved by using approved, appropriately secure software tools. Equipment deliveries must be signed for by an authorised individual using an auditable formal process. This process must confirm that the delivered items correspond fully to the list on the delivery note. Actual assets received must be recorded. Loading areas and holding facilities must be adequately secured against unauthorised access and all access must be auditable. Subsequent removal of equipment must be via a formal, auditable process. Information security arrangements must be subject to regular independent audit and security improvements recommended where necessary.

2. Procedure

2.1 Secure Areas

2.1.1 Physical Security Perimeter
(a) University information processing facilities must be protected by a physical security perimeter.
(b) Information Owners must ensure appropriate controls are in place to establish secure areas. Sensitive information and assets must be protected while considering the safety of personnel. Control selection must be supported by an appropriate Risk Assessment.
(c) Controls that must be applied are:

• security perimeters must be clearly defined, and the siting and strength of each of the perimeters must depend on the security requirements of the assets within the perimeter and the results of a risk assessment;
• perimeters of a building or site containing information processing facilities must be physically sound (i.e. there must be no gaps in the perimeter or areas where a break-in could easily occur); the external walls of the site must be of solid construction and all external doors must be suitably protected against unauthorised access with control mechanisms, e.g. bars, alarms, locks, etc.; doors and windows must be locked when unattended and external protection must be considered for windows, particularly at ground level;
• a manned reception area or other means to control physical access to the site or building must be in place; access to sites and buildings must be restricted to authorised personnel only;
• physical barriers must, where applicable, be built to prevent unauthorised physical access and environmental contamination;
• all fire doors on a security perimeter must be alarmed, monitored, and tested in conjunction with the walls to establish the required level of resistance in accordance to suitable regional, national, and international standards;
• suitable intruder detection systems must be installed to national, regional or international standards and regularly tested to cover all external doors and accessible windows; unoccupied areas must be alarmed at all times; cover must also be provided for other areas, e.g. computer room or communications rooms.

(d) A secure area may be a lockable office, or several rooms surrounded by a continuous internal physical security barrier. Additional barriers and perimeters to control physical access may be needed between areas with different security requirements inside the security perimeter.
(e) Special consideration must be given towards physical access security when the facility houses multiple organisations or business units

2.1.2 Physical Entry Controls
(a) Secure areas must be protected by appropriate entry controls to ensure that only authorised personnel are allowed access.
(b) The following controls must be implemented:

• access to areas where sensitive information is processed or stored must be restricted to authorised personnel only;
• authentication controls, e.g. access control card system, must be used to authorise and validate such access;
• an audit trail of all access must be maintained;
• visitors must be escorted by authorised personnel;
• visitors must only be allowed access for specific and authorised purposes;
• the date and time of entry and departure of visitors must be recorded;
• all employees and other authorised personnel must wear visible identification;
• visitors must be issued badges or tags of a different colour than employees;
• employees must notify security personnel when they encounter unescorted visitors or anyone not wearing visible identification;
• third-party support personnel may be granted restricted access only when required; their access must be authorised and monitored; and
• access rights must be regularly reviewed

2.1.3 Securing Offices, Rooms and Facilities
(a) Controls to ensure security of information and information systems located in University offices, rooms and other facilities must be designed, applied and documented.
(b) Information Owners and IT Security Officers must regularly assess the security of areas where sensitive information is processed and/or stored. Controls that may be implemented to reduce associated risks are:

• physical entry controls ;
• ensure sensitive information is stored properly when not in use; and
• directories that identify the locations of data centres and other areas where sensitive information is stored must not be made public

2.1.4 Protecting Against External and Environmental Threats
2.1.5 Physical protection against natural disasters, malicious attack or accidents must be designed and applied.
2.1.6 Information Owners, Data Center Managers, IT Security staff, planners and architects must incorporate – to the extent possible – physical security controls that protect against damage from fire, flood, earthquake, explosion, civil unrest and other forms of natural and man-made disaster. Consideration must be given to any security threats presented by neighbouring premises or streets. In addition to building code and fire regulations:
(a) combustible or hazardous materials must be stored at a safe distance from the secure area;
(b) bulk supplies, e.g. stationary, must not be stored in a secure area;
(c) backup equipment and backup media must be located at a safe distance to avoid damage from a disaster affecting the main site; and
(d) environmental alarm systems, fire suppression and firefighting systems must be installed

2.1.7 Working in Secure Areas
(a) Additional security controls and procedures must be used by personnel when working in secure areas.
(b) Information Owners and IT Security Officers must identify and document requirements that apply to personnel who have been authorised to work in secure areas. Authorised personnel must be informed that:

• sensitive information cannot be discussed in a non-secure area;
• sensitive information cannot be disclosed to personnel who do not have a need-to-know;
• no type of photographic, smartphone, video, audio or other recording equipment can be brought into a secure area unless specifically authorised;
• maintenance staff, cleaners and others who require periodic access to the secure area must be screened and their names added to an access list; and
• visitors must be authorised, logged and escorted

2.1.8 Delivery and Loading Areas
(a) Access points such as reception, delivery and loading areas and other points where unauthorised persons may enter the premises must be controlled and, if possible, isolated from secure areas or offices to avoid unauthorised access.
(b) Information Owners, University IT Security Officers, planners and architects must ensure that:

• access to a delivery and loading area from outside of the building must be restricted to identified and authorised personnel;
• the delivery and loading area must be designed so that supplies can be unloaded without delivery personnel gaining access to other parts of the building;
• the external doors of a delivery and loading area must be secured when the internal doors are opened;
• loading docks and delivery areas must be regularly inspected and actively monitored;
• incoming material must be inspected for potential threats before this material is moved from the delivery and loading area to the point of use;
• incoming material must be registered in accordance with asset management procedures on entry to the site; and
• incoming and outgoing shipments must be physically segregated where possible

2.2 Equipment

2.2.1 Equipment Siting and Protection
(a) Equipment must be protected to reduce the risks from unauthorised access, environmental threats and hazards.
(b) Information Owners, IT Security Officers, planners and architects must ensure that facilities are designed in a way that safeguards sensitive information and assets.
(c) Servers, routers, switches and other centralised computing equipment must be located in a room with access restricted to only those personnel who require it.
(d) Workstations, laptops, digital media and storage devices should be located and used in an area that is not accessible to the public.
(e) Equipment must be located, and monitors angled, in such a way that unauthorised persons cannot observe the display.
(f) Shared printers, scanners, copiers and fax machines should not be located in an area that is accessible to the public.
(g) Kiosks and other devices that are intended for public use must be clearly labelled and placed in a publicly accessible area

2.2.2 Supporting Utilities
(a) Equipment must be protected from power supply interruption and other disruptions caused by failures in supporting utilities.
(b) The following controls must be implemented to help ensure availability of critical services.
(c) All supporting utilities such as electricity, water supply, sewage, heating/ventilation and air conditioning must be adequate for the systems they are supporting. Support utilities must be regularly inspected and as appropriate tested to ensure their proper functioning and to reduce any risk from their malfunction or failure. A suitable electrical supply must be provided that conforms to the equipment manufacturer’s specifications.
(d) An uninterruptible power supply (UPS) to support orderly close down or continuous running is recommended for equipment supporting critical business operations. Power contingency plans must cover the action to be taken on failure of the UPS. A back-up generator must be considered if processing is required to continue in case of a prolonged power failure. An adequate supply of fuel must be available to ensure that the generator can perform for a prolonged period. UPS equipment and generators must be regularly checked to ensure it has adequate capacity and is tested in accordance with the manufacturer’s recommendations. In addition, consideration could be given to using multiple power sources or, if the site is large, a separate power substation.
(e) Emergency power off switches must be located near emergency exits in equipment rooms to facilitate rapid power down in case of an emergency. Emergency lighting must be provided in case of main power failure.
(f) The water supply must be stable and adequate to supply air conditioning, humidification equipment and fire suppression systems (where used). Malfunctions in the water supply system may damage equipment or prevent fire suppression from acting effectively. An alarm system to detect malfunctions in the supporting utilities must be evaluated and installed if required.
(g) Telecommunications equipment must be connected to the utility provider by at least two diverse routes to prevent failure in one connection path removing voice services. Voice services must be adequate to meet local legal requirements for emergency communications

2.2.3 Cabling Security
(a) Power and telecommunications cabling carrying data or supporting information services must be protected from interception or damage.
(b) Power and telecommunications lines into information processing facilities must be underground, where possible, or subject to adequate alternative protection.
(c) When identified in a Risk Assessment, network cabling must be protected from unauthorised interception or damage by using a conduit and by avoiding routes through public areas.
(d) Power cables should be segregated from communications cables to prevent interference.
(e) Cables and equipment must be clearly marked to minimise handling errors such as accidental patching of wrong network cables. A documented patch list must be used to reduce the possibility of errors.
(f) When a Risk Assessment finds a need for more safeguards, consider:

• installation of rigid conduit and locked rooms or boxes at inspection and termination points;
• use of alternative routings and/or transmission media providing appropriate security;
• use of fibre optic cabling;
• use of electromagnetic shielding to protect the cables;
• initiation of technical sweeps and physical inspections for unauthorised devices being attached to the cables; and
• controlled access to patch panels and cable rooms

2.2.4 Equipment Maintenance
(a) Equipment must be correctly maintained to help ensure availability and integrity of sensitive information and assets.
(b) When equipment is serviced Information Owners must consider the sensitivity of the information it holds and the value of the assets. The following controls must be applied:

• equipment must be maintained in accordance with the supplier’s recommended schedule and specifications;
• only authorised maintenance personnel may carry out repairs and service equipment;
• records must be kept of all suspected faults and all preventive and corrective maintenance;
• maintenance must be scheduled at a time of day that limits interference with services or operations;
• users must be notified before equipment is taken off-line for maintenance.

(c) If off-site maintenance is required then the asset must be cleared of all sensitive information. If it’s not possible to de-sensitise assets before sending for maintenance then the CISO and Information Owner must consider destruction of the asset

2.2.5 Removal of Assets
(a) XXX-owned equipment, information and software must not be removed from XXX’s premises without prior authorisation.
(b) Information Owners must establish a formal authorisation process for the removal of assets for re-location, loan, maintenance, disposal or any other purpose. Authorisation must include:

• item description and serial number(s);
• information indicating where the asset will be located;
• the removal date and return date;
• the name of the individual responsible for the asset; and
• the reason for removal.

(c) The description and serial numbers must be verified when the asset is returned.
(d) Personnel must be informed of and accept responsibility for protection of the asset

2.2.6 Security of Equipment and Assets Off-Premises
(a) Assets must be safeguarded using documented security controls when off-site from XXX premises.
(b) Information Owners must ensure that equipment used or stored off-site is safeguarded in accordance with the sensitivity of the information and the value of the assets. Controls to apply include:

• encrypt sensitive data;
• use a logical or physical access control mechanism (BIOS password, USB key, smart card) to protect against unauthorised access;
• use a physical locking or similar mechanism to restrain the equipment;
• ensure personnel are instructed on the proper use of the chosen controls. Personnel in possession of equipment:
• must not leave it unattended in a public place;
• must ensure the equipment is under his/her direct control at all times when traveling;
• must take measure to prevent viewing of sensitive information by unauthorised personnel;
• must not allow other persons to use the equipment;
• must report loss or stolen equipment immediately

2.2.7 Secure Disposal or Re-Use of Equipment
(a) All data and software must be erased from equipment prior to disposal or redeployment.
(b) Information owners must consider the sensitivity of information and the value of the assets when determining whether or not hardware or media will be reused or destroyed.
(c) Prior to re-use within XXX:

• the integrity of University records must be maintained by adhering to the Records Management policy;
• information and software must be backed up by the original Information Owner; and
• the storage media must be wiped in accordance with the Asset Management Procedure (Disposal of Media).

(d) Storage media that will no longer be used in the University must be wiped by a method approved by the IT Security team, in compliance with the Asset Management Procedure. Asset inventories must be updated to record details of the data wiping including:

• asset identifier;
• date of erasure;
• names of personnel conducting the erasure.

(e) When a supplier conducts the data wiping there must be contractual and audit procedures to ensure complete destruction of the information. XXX must receive certification that the destruction has occurred.

2.2.8 Unattended User Equipment
(a) Users must ensure unattended equipment has appropriate protection.
(b) User must safeguard unattended equipment by:

• terminating the active session when finished;
• lock the session with a password protected screen saver or other approved mechanism;
• logoff computers, servers, terminals and other devices when the session is finished;
• enabling password protection on mobile devices, printers, kiosks and portable storage devices; and
• secure devices with a cable lock when enhanced physical security is justified

2.2.9 Clear Desk and Clear Screen Policy
(a) Users must safeguard sensitive information from unauthorised access, loss or damage.
(b) Users must secure their work space when it cannot be monitored by authorised personnel. Secure work spaces by:

• clearing desktops and work areas;
• locking hard copy sensitive information in an appropriate cabinet;
• locking portable storage devices with sensitive information in an appropriate cabinet;
• activating a password-protected screen saver;
• safeguarding incoming and outgoing mail;
• retrieving documents from printers and fax machines; and
• ensuring that sensitive hard copy documents no longer needed are placed in shredding bins, not recycle bins.

(c) When visitors, cleaning staff or other personnel without a “need-to-know” are in the area, safeguard sensitive information by:

• covering up and maintaining control of hard copy files;
• blanking computer screens or activating the password-protected screen saver.
• Sensitive information must not be discussed in public or other areas where there is a risk of being overheard by unauthorised personnel

2.3 Physical security Monitoring

The purpose is to detect and deter unauthorized physical access.Physical access monitoring includes publicly accessible areas within XXX. XXX shall

1. Monitor physical access to the facility where the system resides to detect and respond to physical security incidents;
2. Review physical access logs at least once every week and upon occurrence of  events or potential indications of events and
3. Coordinate results of reviews and investigations with the organizational incident response capability.

In XXX physical access monitoring include the employment of guards, video surveillance equipment (i.e., cameras), and sensor devices. Reviewing physical access logs should be done to identify suspicious activity, anomalous events, or potential threats. The reviews should be supported by audit logging controls. Organizational incident response capabilities include investigations of physical security incidents and responses to the incidents. Incidents include security violations or suspicious physical access activities. Suspicious physical access activities include accesses outside of normal work hours, repeated accesses to areas not normally accessed, accesses for unusual lengths of time, and out-of-sequence accesses.

1 Introduction

To ensure that information security is designed and implemented within the development life cycle for applications and information systems. The purpose of this document is to set out XXX’s policy in the development of software applications and components in a way which maximizes their inherent security. Secure development contributes to the reliability of the IT environment by ensuring that as many vulnerabilities as possible are designed and tested out of software before it is deployed into the live environment. Many security breaches around the world occur due to the exploitation of such vulnerabilities in system and application software, including the use of data that was not envisaged when the software was designed and tested. The growth of cloud applications that are developed using methods such as Agile and DevOps and incorporate very fast development to deployment times means that emerging techniques such as DevSecOps are evolving rapidly to try to keep pace. This document sets out the precautions that must be taken during the software development life cycle to minimize the risk to the organization whilst ensuring that the benefits set out in the original business case for the software are still realized. As such, this document will represent an initial design for the enhancement of existing development processes and will be updated on at least an annual basis thereafter as XXX and its needs develop.

2 Software development approaches

The process of software development fits in with the higher-level process of project management of new or enhanced information systems.
This process has the following major stages in a project:

• Proposal
• Planning
• Design and Development
• Transition
• Project Closure
  

The software development life cycle sits mainly within the Design and Development stage and consists of the following sub-stages:

• Design and Development
• Business requirements specification
• System design
• Development
• Testing

The way in which the stages of the software development life cycle are approached will depend upon the development approach used. The two main models of software development used within XXX are Waterfall and Iterative. The choice of approach will be made on a project by project basis.

2.1 Waterfall development approach
The classic Waterfall approach to software development involves the planning and completion of each stage before moving on to the next, in a sequential manner. Functional requirements are defined in detail and signed off before the design stage may begin. In turn, design must be completed before development starts etc. This has the advantage that it is possible to ensure that adequate planning takes place and to include security checkpoints at the end of each stage. These will ensure the inclusion of adequate security criteria at the requirements stage and correct security controls at the design stage. The common disadvantage with the Waterfall approach is that it is less flexible as circumstances and requirements change. If the project lasts for an extended period of time, there is the danger that what is delivered is no longer what is required.

2.2 Iterative development approach
As an alternative to Waterfall, an Iterative approach may be taken. Such approaches include Rapid Application Development (RAD), Prototyping and, more recently, Agile and DevOps. The Iterative approach typically involves significant stakeholder involvement throughout the development lifecycle and concentrates on producing frequent new versions of the software that may be evaluated and tested before further functionality is added. The process loops round with each of the stages being carried out many times in small iterations (in the Agile method these are called “Sprints”). Approaches such as CI/CD (Continuous Integration/Continuous Delivery) and Continuous Deployment have evolved from the use of readily available cloud environments, and further reduce the time between code completion and its deployment. An Iterative approach may be appropriate where exact requirements are less certain and frequent communication between developers and users (and within the development team) is possible. The inclusion of security requirements and controls within an Iterative development approach needs to be carefully managed to ensure that functionality is not preferred to the exclusion of effective security measures. The speed involved and the potential lack of structured design documentation mean that effective training of developers in security matters and possibly the regular involvement of a security specialist are recommended. The use of roles such as Security Champion or Security Advocate within the development team may be appropriate to achieve the required focus on the security of the code deployed. The set of techniques used to provide security in a highly iterative development environment is often referred to as “DevSecOps”.

3 Security in the software development lifecycle

This section describes the way in which information security considerations must be incorporated into the various stages within the software development lifecycle.

3.1 Business requirements specification
The focus within the business requirements stage is on the functionality of the new system. This will be expressed in business rather than technical terms and should tie in with the business case that was produced prior to the initiation of the project. The business is uniquely placed to give a clear understanding to the development team of the security requirements of the information that the new system will hold and process. In particular the business requirements must specify:

• The value of the information involved
• The sensitivity of the information-will personal data be held?
• Who the information owner is or will be
• The classification of the information according to the scheme used within the organization
• The environment in which the information will be accessed or processed-will access be available in public areas?
• The criticality of the new system and the information it holds – what is the business impact if it is not available?
• The legal, regulatory and contractual environment the system must operate within

A risk assessment must be carried out as part of the project to ensure that the implications of the above issues are fully understood by all parties.

3.2 System design
Based on the risk assessment and the classification of the information that is to be held in and processed by the new system, the design must provide for appropriate security features to be available. These will be largely defined by XXX’s established security architecture as documented in Principles for Engineering Secure Systems. This extends not only to the creation and maintenance of user accounts and permissions but also the following areas:

• Data input validation controls
• Data flow
• Data output
• Interfaces with other systems
• Reporting
• Restart and recovery
• Time stamps
• Logging (e.g. of transactions and access)
• Journaling of before and after images
• Batch and transaction counters
• Monitoring facilities
• How non-repudiation requirements will be met
• Ongoing patching arrangements
• Use of cryptography
• Need for digital certificates and signatures

For systems designed as part of a Waterfall approach these aspects will be included as part of the design documentation. If an Iterative approach is used, the development team will need to ensure that these areas are considered during every iteration and that changes do not invalidate controls implemented during an earlier iteration.

3.3 Development
Before starting to write code, a secure development environment must be established for the project. Depending on the coding environment, languages, databases, tools and other components selected, the appropriate guidelines for secure coding and configuration must be adopted. These must be evaluated to ensure they will provide adequate protection from the various types of potential attack identified in the risk assessment, such as:

• Buffer overflow
• Time of Check/Time of Use
• Memory Reuse
• Malformed input
• SQL injection

For a lengthy project it will be necessary to obtain regular updates regarding newly identified vulnerabilities and exploits associated with the technology components in use.

3.4 Testing
During the lifecycle of a software application, many different forms of testing will be carried out, including unit, system, integration, performance, user acceptance and operational acceptance testing. Security controls will to some extent be tested as part of these exercises. However, it is recommended that a separate exercise of security testing be carried out against the security requirements that were established during the business requirements and design stages. Initial security testing must be carried out within the development project with the same degree of rigour and formality as other forms with a suitable range of test inputs being specified. Once this has been completed to the development team’s satisfaction a further phase of security testing must be carried out by an independent party separate to the development team to verify correct operation of controls. Adequate controls must be put in place to protect test data. Where appropriate (and with prior approval on each occasion), a live to test copy may be made in order to provide representative test data. However, if this contains sensitive information such as personally identifiable data this must be removed or obscured before use. In a CI/CD (Continuous Integration/Continuous Delivery) or Continuous Deployment scenario, in which the testing and deployment of code to the cloud may be automated, testing frameworks such as the OWASP (Open Web Application Security Project) Application Security Verification Standard (ASVS) must be used as a basis for testing application technical security controls.

4.0 Secure Coding

All software written for or deployed on systems must incorporate secure coding practices, to avoid the occurrence of common coding vulnerabilities and to be resilient to high-risk threats, before being deployed in production. The items enumerated in this standard are not an exhaustive list of high-risk attacks and common coding errors but rather a list of the most damaging and pervasive. Therefore, code written must contain mitigating controls not only for the items specifically articulated in the standard below, but also for any medium and high-risk threats that are identified during a system’s life cycle.
High risk threats include, but are not limited to:

1. Code Injection
2. Cross-site scripting (XSS)
3. Cross-site request forgery (CSRF)
4. Information leakage and improper error handling
5. Missing Authentication for Critical Function
6. Missing Encryption of Sensitive Data
7. URL Redirection to Untrusted Site (‘Open Redirect’)

Developers are required to independently remain aware of updates to these lists and incorporate any new recommendations. Use of common security control libraries and common API’s, that have undergone security testing, is required to ensure a consistent approach that minimizes defects and prevents exploitation. When available, publicly available or vendor-supplied libraries or APIs should be used unless there’s a business case developed and exception granted by the Chief Information Security Officer (CISO)/designated security representative to develop a custom library. To prevent defects or detect and remove them early, thereby realizing significant cost and schedule benefits to the entity, code must be checked for errors throughout development and during maintenance. Entities must verify that the software assurance model used by the vendor is in line with this standard through vendor assurances, security testing and/or contract requirements

5 Security in outsourced development

Where software development is wholly or partially outsourced to a third party, due care must be taken to ensure that the policies of XXX are still followed where possible. XXX will remain legally responsible for the use of the software created an the information contained within it even though it didn’t write the software. Therefore, the same level of rigour must be applied to outsourced software development as that created in-house.

5.1 Selection of outsourced developer
Standard procurement procedures must be used in the selection and engagement of an appropriate outsourced developer. Use of these procedures will ensure the developer:

• Is capable of delivering the software to the required standard
• Can meet the delivery timescales required
• Represents best value for the organization
• Can meet the security requirements specified
• Use of sub-contractors by the outsourced developer for any aspects of the development must be understood and an assessment of these sub-contractors included.
  

5.2 Communication of requirements
The contract with the outsourced developer must require compliance with this policy and include a clear statement of the requirements for secure design, coding and testing of the software. The developer must also be required to establish a secure development environment in accordance with XXX standards. Requirements definition must be carried out by XXX so that a clear definition of the software to be created (including its security features) is agreed with the business and used as a contractual starting point for development. Whilst the outsourced developer may in some circumstances assist in the definition of requirements, the exercise should be led, managed and ideally carried out by internal resources so that there is a clear separation between requirements and design/development. A comprehensive picture of the anticipated threat model faced by the software should be provided to the outsourced developer so that a clear understanding is gained of the types of vulnerabilities that must be avoided if the software is to be secure.

5.3 Supervision and monitoring
Measures must be put in place to ensure adequate supervision of the activities of the outsourced developer and regular monitoring of progress. For a large project with significant time gaps between deliverables, an agreed method of verifying interim progress must be in place so that early warning is given of delays.

5.4 Reviews and acceptance
Review points must be established as part of the project planning process to verify progress and give formal acceptance of the software deliverables created. These will involve appropriate testing activities and code reviews. The outsourced software developer must be required to provide evidence of the security testing activities carried out during the development, including tests for concealed malware, back doors and known vulnerabilities. Where appropriate a security review of developed code may be engaged with a suitable third party with the relevant security expertise.

5.5 Audit of development methods
XXX must have the contractual right to undertake a second party audit of the outsourced development provider. This may be to review whether the development methods used comply to our policies and that all information provided to the supplier is protected by appropriate security controls. For larger projects it is recommended that an audit be carried out prior to the placing of the order for software development to ensure that assurances given during the sales process are valid.

5.6 Intellectual property
Unless the software is licensed under a formal agreement, contractual arrangements with an outsourced software developer must state that the ownership of the code produced on our behalf rests with XXX. It is important that any software that is developed under an outsourcing contract is understood to be our intellectual property. Appropriate legal advice must be taken particularly if the outsourcer is based outside of our home country.

5.7 Escrow
Arrangements must be made for XXX to be able to legally access the source code of any developments undertaken, in the event that the outsourcer ceases trading for any reason. This must be the case during development and if appropriate after the code has been delivered.

6 The Secure Software Development Framework

6.1 Prepare the Organization (PO): Organizations should ensure that their people, processes, and technology are prepared to perform secure software development at the organization level. Many organizations will find some PO practices to also be applicable to subsets of their software development, like individual development groups or projects.

1. Define Security Requirements for Software Development: Ensure that security requirements for software development are known at all times so that they can be taken into account throughout the SDLC and duplication of
   effort can be minimized because the requirements information can be collected once
   and shared. This includes requirements from
   internal sources (e.g., the organization’s policies,
   business objectives, and risk management strategy) and external sources (e.g., applicable laws and regulations).
2. Implement Roles and Responsibilities: Ensure that everyone inside and outside of the organization involved in the SDLC is prepared to perform their SDLC-related roles and responsibilities throughout the SDLC.
3. Implement Supporting Tool chains: Use automation to reduce human effort and improve the accuracy, reproducibility, usability, and comprehensiveness of security practices throughout the SDLC, as well as provide a way to document and demonstrate the use of these practices. Tool chains and tools may be used at different levels of the organization, such as organization-wide or project-specific, and may address a particular part of the SDLC, like a build pipeline.
4. Define and Use Criteria for Software Security Checks : Help ensure that the software resulting from the SDLC meets the organization’s expectations by defining and using criteria for checking the software’s security during development
5. Implement and Maintain Secure Environments for Software Development: Ensure that all components of the environments for software development are strongly protected from internal and external threats to prevent compromises of the environments or the software being developed or maintained within them. Examples of environments for software development include development, build, test, and distribution environments.

6.2 Protect the Software (PS): Organizations should protect all components of their software from tampering and unauthorized access.

1. Protect All Forms of Code from Unauthorized Access and Tampering : Help prevent unauthorized changes to code, both inadvertent and intentional, which could circumvent or negate the intended security characteristics of the software. For code that is not intended to be publicly accessible, this helps prevent theft of the software and may make it more difficult or time-consuming for attackers to find vulnerabilities in the software.
2. Provide a Mechanism for Verifying Software Release Integrity : Help software acquirers ensure that the software they acquire is legitimate and has not been tampered with.
3. Archive and Protect Each Software Release: Preserve software releases in order to help identify, analyze, and eliminate vulnerabilities discovered in the software after release

6.3 Produce Well-Secured Software (PW): Organizations should produce well-secured software with minimal security vulnerabilities in its releases.

1. Design Software to Meet Security Requirements and Mitigate Security Risks : Identify and evaluate the security requirements for the software; determine what security risks the software is likely to face during operation and how the software’s design and architecture should mitigate those risks; and justify any cases where risk-based analysis indicates that security requirements should be relaxed or waived. Addressing security requirements and risks during software design (secure by design) is key for improving software security and also helps improve development efficiency.
2. Review the Software Design to Verify Compliance with Security Requirements and Risk Information: Help ensure that the software will meet the security requirements and satisfactorily address the identified risk information.
3. Verify Third-Party Software Complies with Security Requirements
4. Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality : Lower the costs of software development, expedite software development, and decrease the likelihood of introducing additional security vulnerabilities into the software by reusing software modules and services that have already had their security posture checked. This is particularly important for software that implements security functionality, such as cryptographic modules and protocols.
5. Create Source Code by Adhering to Secure Coding Practices : Decrease the number of security vulnerabilities in the software, and reduce costs by minimizing vulnerabilities introduced during source code creation that meet or exceed organization-defined vulnerability severity criteria.
6. Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security : Decrease the number of security vulnerabilities in the software and reduce costs by eliminating vulnerabilities before testing occurs.
7. Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements : Help identify vulnerabilities so that they can be corrected before the software is released to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities. Human-readable code includes source code, scripts, and any other form of code that an organization deems human- readable.
8. Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements : Help identify vulnerabilities so that they can be corrected before the software is released in order to prevent exploitation. Using automated methods lowers the effort and resources needed to detect vulnerabilities and improves traceability and repeatability. Executable code includes binaries, directly executed bytecode and source code, and any other form of code that an organization deems executable.
9. Configure Software to Have Secure Settings by Default : Help improve the security of the software at the time of installation to reduce the likelihood of the software being deployed with weak security settings, putting it at greater risk of compromise.

6.4 Respond to Vulnerabilities (RV): Organizations should identify residual vulnerabilities in their software releases and respond appropriately to address those vulnerabilities and prevent similar ones from occurring in the future.

1. Identify and Confirm Vulnerabilities on an Ongoing Basis : Help ensure that vulnerabilities are identified more quickly so that they can be remediated more quickly in accordance with risk, reducing the window of opportunity for attackers
2. Assess, Prioritize, and Remediate Vulnerabilities : Help ensure that vulnerabilities are remediated in accordance with risk to reduce the window of opportunity for attackers.
3. Analyze Vulnerabilities to Identify Their Root Causes: Help reduce the frequency of vulnerabilities in the future.

1.    Overview

Computer logs are essential to the operational management of an organization.  They provide a primary mechanism for automated tracking and reporting for review, audit, and compliance functions as well as a useful mechanism for tracking changes and troubleshooting.

2.    Purpose

Frequent monitoring and logging components are required to effectively assess information system controls, operations, and general security.  This policy provides a set of logging policies and procedures aimed to establish baseline components across the XXX. 

3.    Scope

This policy applies to all XXX staff that create, deploy, or support application and system software.

4.     Policy

A.    GENERAL

Access to XXX’s network, systems and communications shall be logged and monitored to identify potential misuse of systems or information.  Logging activities shall include regular monitoring of system access to prevent attempts at unauthorized access and confirm access control systems are effective.  Log servers and documents shall be kept secure and only made available to personnel authorized by the CISO or their designee.  These logs shall be kept as long as necessary or required for functional use or appropriate state regulation or law. XXX’s information systems (servers, workstations, firewalls, routers, switches, communications equipment, etc.) shall be monitored and logged to:

• Ensure use is authorized
• Manage, administer, and troubleshoot systems
• Protect against unauthorized access
• Verify security procedures and access
• Verify system and operational security
• Comply with XXX policies and procedures
• Detect and prevent criminal or illegal activities

The CISO or their designee shall implement automated audit trails for all critical systems and components.  At a minimum, these logs shall be used to reconstruct the following events:

• Individual user accesses to systems and sensitive information
• All actions taken by any individual with administrative privileges
• Access to audit trails
• Invalid logical access attempts and failures
• Use of and changes to identification and authentication mechanisms—including but not limited to creation of new accounts and elevation of privileges—and all changes, additions, or deletions to accounts with administrative privileges
• Initialization, stopping, or pausing of the audit logs
• Creation and deletion of system level objects

B.    UNDERLYING REQUIREMENTS

All systems that handle confidential information, accept network connections, or make access control (authentication and authorization) decisions shall record and retain audit logging information to:

• Determine the activity that was performed
• Who or what performed the activity, including where or on what system the activity was performed (subject)
• Systems and objects involved
• When the activity was performed
• Status (such as success vs. failure), outcome, and/or result of the activity

XXX shall implement a suitable logging infrastructure and configure all critical devices, systems, and applications with logged audit trails.  The [Insert Appropriate Role] or their designee shall ensure important events and audit trails are logged.  File integrity monitoring/change detection software shall review logs and issue alerts if the log data is altered.

C.    ACTIVITIES TO BE LOGGED

Support staff shall be assigned to review and monitor the logs for systems under their control.  Logs shall be reviewed on a regular and on-going basis.  The frequency of review shall be determined according to the sensitivity of the information stored, the function of the system, and other system requirements as determined by the CISO.  Procedures should verify that logging is active and working properly to:

• Ensure events are properly classified
• Review logging for performance delays
• Ensure compliance related logging cannot be bypassed
• Verify access to log files is properly restricted
• Assist with investigations

Logs shall be created whenever the following activities are performed by a system, application, or user:

• Creating, reading, updating, or deleting confidential information, including confidential authentication information such as passwords
• Initiating or accepting a network connection
• Authenticating user access and security authorizations
• Granting, modifying, or revoking access rights to include new user or group additions, user privilege modifications, file or database object permissions, firewall rules, and user password changes
• Configuring systems, networks, or services for maintenance and security changes including installation of software patches and updates, or other installed software
• Changing statuses of application process startup, shutdown, and/or restart
• Application process aborts, failures, or abnormal conditions due to resource limits or thresholds (such as for CPU, memory, network bandwidth, disk space, or other key system resources), failure of network services, or hardware faults
• Detection of suspicious/malicious activity such as from an intrusion detection or prevention system, anti-virus, or anti-spyware system

D.    SYSTEM LOG ELEMENTS

System events and activities that shall be monitored and logged are as follows:

• System administrator and system operator activities
• System start-ups and shut-downs
• Logging start-ups and shut-downs
• Backups and restorations/roll-backs
• Exceptions and security events
• Database commits and transactions
• Protection software and hardware (firewalls, routers, etc.)
• Intrusion Detection Systems (IDS) and Intrusion Prevention Systems
• Modifications to data characteristics including permissions, location, file type
• Authentication successes and failures (e.g. log in, log out, failed logins)

E.    APPLICATION LOG ELEMENTS

Third party and custom application software logging requires more than just relying on server based system logs. Application logs help identify security incidents, establish baselines, provide information about problems and unusual conditions, assist with incident investigation, and help detect intrusions and errors.  Application events and activities that shall be monitored and logged include:

• Application authentication (e.g. successes, failures, logouts)
• Data audit trails (e.g. access to sensitive data, adding data, modifying data, deleting data, exporting and importing data)
• Input validation failures (e.g. protocol violations, unacceptable encodings, invalid parameter names and values)
• Output validation failures (e.g. database record mismatch, invalid data encoding)
• Suspicious behavior (e.g. multiple records deleted in a short period of time, invalid access attempts)
• Session management failures (e.g. cookie session identification value modifications)
• Application errors and events (e.g. syntax and runtime errors, connectivity problems, third party service error messages, file system errors, sequencing failure)
• Higher-risk functionality (e.g. adding and deleting users, changes to access privileges, use of administrative privileges, access by application administrators, and access to sensitive data)
• Legal compliance services (e.g. permissions to transfer information, terms of use, and parental consent)
• Security events or warnings

F.    LOGGING ELEMENTS

Log entries can contain a number of elements based on the type and function of the audited system/process.  Generally, automated audit trails shall include the following information:

• Host name, system component, or resource
• Date/Time Stamp
• Application ID (e.g. name and version)
• Initiating Process ID or event origination (e.g. entry point URL, page, form)
• Code location (e.g. module, subroutine)
• User initiating action (e.g. user ID)
• Event type
• Result status (e.g. success, failure, defer)
• Resource (e.g. identity or name of affected data, component)
• Location (e.g. IP address or location)
• Severity of event (e.g. emergency, alert, fatal error, warning, information only)
• Other (e.g. parameters, debug information, system error message)

G.    FORMATTING AND STORAGE

The system shall support the formatting and storage of audit logs to ensure integrity enterprise-level analysis and reporting.  Mechanisms known to support these goals include but are not limited to the following approaches:

• Collecting Microsoft Windows Event Logs from servers by a centralized logging management system
• Storing logs in a documented format and sent via reliable network protocols to a centralized log management system
• Storing log entries in a SQL database that generates audit logs in compliance with the requirements of this policy

H.    INFORMATION SECURITY ISSUES

Logs are one of the primary tools used by system administrators and management to detect and investigate attempted and successful unauthorized activity and to troubleshoot problems.  Detailed procedures that support this policy shall be developed to protect against and limit log security risks such as:

• Controls that limit the ability of administrators and those with operating system command line access to disable, damage, or circumvent access control and audit log mechanisms
• Protecting the contents of system logs from unauthorized access, modification, and/or deletion
• Limiting outside access to logging systems to extreme or emergency circumstances.  Any emergency access should be authorized by the [Insert Appropriate Role] and use of tools bypassing security controls should be documented
• Limiting changes to the auditing policies to stop logging of an unauthorized activity.  Log settings should be set to track and record user policy changes

I.      ADMINISTRATIVE RESPONSIBILITIES

The CISO shall be responsible for:

• Separating duties between operations and security monitoring
• Ensuring a regular review of activity audit logs, access reports, and security incidents
• Approving the types of logs and reports to be generated, review activities to be performed, and procedures that describe the specifics of the reviews
• Procedures that specify monitoring log-in attempts, reporting discrepancies, and processes used to monitor log-in attempts
• Procedures that specify audit controls, hardware, software, and/or procedural mechanisms that record and examine activity in information systems
• Procedures ensure that the audit controls meet security requirements by recording and examining activity related to sensitive information
• Securing audit trails by limiting viewing to those with a job-related need
• Protecting audit trail files from unauthorized modifications
• Ensuring audit trail files are promptly backed up to a centralized log server or media

5.    Audit Controls and Management

On-demand documented procedures and evidence of practice should be in place for this operational policy as part of XXX procedures.  Examples of auditable controls include:

• On demand and historical log reviews of areas described in this policy
• Documented communications surrounding logging activities
• Incident response procedures

6.    Enforcement 

Staff members found in policy violation may be subject to disciplinary action, up to and including termination.

1. Purpose

The purpose of this Policy is to preserve the confidentiality, integrity and availability of the XXX’s information assets by restricting access to enterprise application databases that store XXX’s data

2. Scope

1. This database security policy applies to database platforms. If the role is outsourced to a vendor, the vendor must ensure compliance with the identified standards.
2. Security controls should be implemented based on the level of confidentiality of the data determined by Data Owner.
3. Database management system should provide accurate and reliable business data as well as preventing unauthorized data modification.
4. XXX should ensure the roles and responsibilities of Database Administrator is established and formalized. Only authorized users are allowed to access business data.

3. Policy

3.1 General

1 Storage of Data Base Usernames and Passwords

• Database usernames and passwords may be stored in a file separate from the executing body of the program’s code. This file must not be world readable or writable.
• Database credentials may reside on the database server. In this case, a hash function number identifying the credentials may be stored in the executing body of the program’s code.
• Database credentials may be stored as part of an authentication server (i.e., an entitlement directory), such as an LDAP server used for user authentication. Database authentication may occur on behalf of a program as part of the user authentication process at the authentication server. In this case, there is no need for programmatic use of database credentials.
• Database credentials may not reside in the documents tree of a web server.
• Passwords or pass phrases used to access a database must adhere to the Password Policy.

2 Retrieval of Database User Names and Passwords

• If stored in a file that is not source code, then database user names and passwords must be read from the file immediately prior to use. Immediately following database authentication, the memory containing the user name and password must be released or cleared.
• The scope into which you may store database credentials must be physically separated from the other areas of your code, e.g., the credentials must be in a separate source file. The file that contains the credentials must contain no other code but the credentials (i.e., the user name and password) and any functions, routines, or methods that will be used to access the credentials.
• For languages that execute from source code, the credentials’ source file must not reside in the same browsable or executable file directory tree in which the executing body of code resides.

3 Access to Database Usernames and Passwords

• Every program or every collection of programs implementing a single business function must have unique database credentials. Sharing of credentials between programs is not allowed.
• Database passwords used by programs are system-level passwords as defined by the Password Policy.
• Developer groups must have a process in place to ensure that database passwords are controlled and changed in accordance with the Password Policy. This process must include a method for restricting knowledge of database passwords to a need-to-know basis.
• Users and/or software accessing sensitive data must be subjected to proper access control and should not be able to perform privileged operations that are out of scope of said user and/or software.

3.2 Information Classification

Data is classified to its sensitivity level. This sensitivity level is the level of risk to the Organization if the data is lost or disclosed to unauthorized parties.

3.3 Access control

1 Authorization, Access Rights and Privilege

1. All system installation and database files with directories must be protected to prevent unauthorized access.
2. The respective System Owner shall authorize all user access to database.
3. The database server and its network components shall be physically secured.
4. Select privilege grants a user’s access on views and tables should be limited to authorized personnel.
5. All users’ access privileges of database is based on the Application Access Matrix (according to duties segregation), owned by the Data Owner and endorsed by the senior management.

2 Audit Trails

1. Database audit data shall be archived according to the following requirements:-
   • Daily Back-ups are retained for a minimum of 1 month,
   • Monthly Back-ups are retained for every 7 years and
   • Yearly Back-ups are retained for 7 years.
2. ll requests to link database should formally be approved by IT Security Department and relevant parties. Database maintenance utilities that bypass controls should be adequately restricted and monitored.
3. Minimum Audit Information: The minimum audit trail for a database must be able to provide information on access to a database at any point of time. The following scenarios will require minimum audit trails.
   • Multi-site access (Connections from different IP or point of access) to a database is needed to be audited. The access is through a system (i.e. application server accessing a database server).
     • Failed login
     • Database exceptions
   • Multi-user ID accessing a database. This connection is mainly by individual user (through database client i.e. SQL Plus, Toad or log on locally to the database server)

The following audits are suggested.

• Who logged into the database
• Successful login and failed login (authorization failure/non existent users).
• Where the connection was initiated from (source)
• When the connection was made
• What client was used to access the database
• What was performed during the connection

3. Availability, Backup and Recovery

1. Database Administrator shall monitor the database periodically to ensure its availability and maintaining the performance.
2. Data Administrator should determine the level of required backup and strategy being used (e.g. Full backup, incremental, online or offline backup) for different databases.
3. Backup files for all databases must be sent to an offsite location for storage.
4. The DBA shall backup the database periodically according to documented procedures.
5. Where possible, the database redundancy should be implemented whereby the archive and redundancy are written to multiple physical locations for recovery purposes.
6. Recovery testing of the off-site backup tapes shall be carrying out o a half yearly basis.

4. Database User Management

1.Privileged Accounts

1. Database Administrator (DBA) shall not have system administrator rights to the operating system for any server on which a database is installed.

2. User Accounts

1. Where possible, all database users should have a unique user account within the database
2. The use of shared user accounts in the database application is not allowed.
3. The Database Administrator (DBA) shall not transfer or share administrator account privileges with unauthorized users.
4. Where possible, database session timeout for accounts should be implemented to mitigate the risk of unauthorized access when the terminal is left unattended.
5. In the event of changes in job function of the user, the access rights of the user accounts shall be reviewed to ensure that minimum access rights are granted.
6. All user accounts that have been inactive for 90 days shall be disabled.

3. Default Accounts

1. Default fault accounts shall be deleted disabled or removed from the production database management systems.

4. Creation of Accounts

1. Requests for creating user accounts and granting access privileges shall be approved by the respective Data Owner.

5. Deletion of Accounts

1. All user accounts should be deleted immediately after the user leaves the Organization, unless requested and approved otherwise.

6. Application and System Development

1. The database production and development environments shall be segregated.
2. Developers shall not have an access to the production database.

7. Operating System security

1. The operating system where the database is installed shall be secured according to XXX platform-specific operating system technical control guideline.

8. Data Confidentiality Controls

1. Where possible, database passwords and other relevant authentication information should be appropriately encrypted.
2. Where possible, “Classified” data (e.g. Customer PIN and Credit Card number) in the database should be stored in encrypted form.
3. Where possible, database links or connection (e.g. Oracle SSL) should be encrypted.

 3.4 Change Control

1. Any database changes shall be approved by the Data Owner and the relevant parties and a notification concerning about the changes will be sent to the IT Security Department for an updates on the changes made.
2. Both outsourcer and XXX IT Security Department shall assess database changes that are not specific to business application.
3. The changes specific to business application data (e.g. Database tables, data) shall be tested on the development system prior to implementation on the production system and shall be approved ahead of making any changes.
4. Changes to the audit trail settings highlighted in this policy shall require assessment from both outsourcer and XXX IT Security Department.

3.5 Monitoring and Review

1.Access Control Matrix Review

The Data Owner on a half yearly basis shall review the access control matrix. Updated access matrix should be forwarded to the outsourcer.

2 Audit Trail Reviews

1. The integrity of business data should be upheld by providing assurance of accuracy and reliability of the database management system as well as preventing unauthorised modification of data.
2. For all databases, audit trail, error logs and access violation review shall be performed by the Database Administrator periodically and as needed in accordance with the standards.
3. An independent party who does not have access to the same database shall review audit trails of Database Administrator and Database Security Officer Activities.

3 Security Patches

1. The Database Administrator shall monitor the availability of database updates and patches releases by the vendors.
2. Once done with the evaluation on impact on the database, database Administrator shall apply these database updates and prepare the impact analysis documentation to the Data Administrator for concurrence and acceptance.

3.6 Data Base Administrator Roles and Responsibilities

1. A database administrator is responsible for the usage, accuracy, efficiency, security, maintenance, administration and development of an organization’s computerized database(s), providing support to some or all departments depending on the size of the organization.
2. Typical responsibilities are likely to include:-

1. Ensuring that the database(s) is updated accurately and regularly
2. Controlling the access, performance monitoring and tuning
3. Assisting development staff with application design
4. Identifying and resolving user’s problem
5. Developing and implementing maintenance procedures
6. Collaborating in the design and development of database to meet new user needs and respond to/anticipate technological innovations
7. Facilitating and negotiating the increasing demand for access to data-increasingly via an organization’s intranet or website
8. Devising, developing and implementing disaster recovery and archiving procedures
9. Supporting users by talking then through a search or by customizing the ‘front ends’ to incorporate new fields for data entry
10. Capacity planning
11. Working closely with IT project managers and database programmers
12. Liaising with web developers to enable on-line database access and resolve associated problems
13. Planning and coordinating database security measures
14. Communicating regularly with internal technical, applications and operational staff to ensure the database integrity and security
15. Commissioning and installing new applications.

4.0 Policy Compliance

4.1 Compliance Measurement
The IT team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.
4.2 Exceptions
Any exception to the policy must be approved by the IT team in advance.
4.3 Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. A violation of this policy by a temporary worker, contractor or vendor may result in the termination of their contract or assignment with .

1.Purpose

The purpose of this policy it to define the guidelines for the disposal of Information technology equipment and components owned by XXX.

2. Scope

This policy applies to any computer/technology equipment or peripheral devices that are no longer needed within XXX including, but not limited to the following: personal computers, servers, hard drives, laptops, mainframes, smart phones, or handheld computers ( i.e., Windows Mobile, iOS or Android-based devices), peripherals (i.e., keyboards, mice, speakers), printers, scanners, typewriters, compact and floppy discs, portable storage devices (i.e., USB drives), backup tapes, printed materials.

All XXX employees and affiliates must comply with this policy.

3. Policy

3.1 General

1. When Technology assets have reached the end of their useful life they should be sent to the office for proper disposal.
2. The will securely erase all storage mediums in accordance with current industry best practices.
3. All data including, all files and licensed software shall be removed from equipment using disk sanitizing software that cleans the media overwriting each and every disk sector of the machine with zero-filled blocks.
4. No computer equipment should be disposed of via skips, dumps, landfill etc. Electronic recycling bins may be periodically placed in locations around XXX. These can be used to dispose of equipment. The will properly remove all data prior to final disposal.
5. All electronic drives must be degaussed or overwritten with a commercially available disk cleaning program. Hard drives may also be removed and rendered unreadable (drilling, crushing or other demolition methods).
6. Computer Equipment refers to desktop, laptop, tablet or netbook computers, printers, copiers, monitors, servers, handheld devices, telephones, cell phones, disc drives or any storage device, network switches, routers, wireless access points, batteries, backup tapes, etc.
7. The will place a sticker on the equipment case indicating the disk wipe has been performed. The sticker will include the date and the initials of the technician who performed the disk wipe.
8. Technology equipment with non-functioning memory or storage technology will have the memory or storage device removed and it will be physically destroyed.

3.2 Assets Tracked

Defines which IT assets should be tracked and to what extent.

1 IT Asset Types
Categorized the types of assets subject to tracking – including:

1. Desktop workstations
2. Laptop mobile computers
3. Mobile phones and tablets
4. Printers, Copiers, Fax machines, multi-function machines
5. Handheld devices
6. Scanners
7. Servers
8. Firewalls
9. Routers
10. Switches
11. Memory devices

2 Assets Tracked
Assets that cost less than $ 100 and do not contain date should not be specifically tracked. These include components such as video or sound cards. However, all assets that store data should be tracked regardless of cost. Examples include:

• Hard Drives
• Temporary storage drives
• Tapes – including system backup data.

Although not specifically tracked, other storage devices such as CD ROM disks and floppy disks are covered by this policy for disposal and secure storage purposes

3 Small Memory Devices
Small memory storage assets will not be tracked by location but by trustee. These assets include:

• Floppy disks
• CD ROM disks
• Memory sticks

Trustees of the devices must sign for receipt of the devices in their possession. All employees must also agree to handle memory sticks, floppy disks, and CD ROM disks in a responsible manner and follow the following guidelines:

• Never place sensitive data on a device or media without authorization. Once permission has been obtained, the data-bearing item must be kept in a secure area.
• Never use these devices to download executable programs from outside the network without prior authorization and without first scanning the program with an approved and updated anti-virus and malware scanner. Any software brought into the network should be on the IT department’s approved list.

The Memory Device Trustee Agreement requires employees to sign for receipt of these devices and agree to handle these assets in accordance with the terms of this policy. This form must be executed by all employees that will work with any organizational data on the first day of employment. The form should also be updated whenever and employee receives one or more memory sticks, temporary storage drives, or data backup drives.

4. Asset Tracking Requirements

1. All assets must be assigned an ID number. Either an internal tracking number will be assigned when the asset is acquired or the use of Manufacturer ID numbers must be specified in this policy.
2. An asset tracking database shall be created in order to track assets. It will include all information on the Asset Transfer Checklist table and the date of the asset change.
3. When an asset is acquired, an ID number will be assigned to the asset and the relevant information shall be entered in the asset tracking database.

5. Asset Transfer

1. When an asset listed on the Asset Types list is transferred to a new location or trustee, the IT Asset Transfer Checklist must be completed by the trustee of the item and approved by an authorized representative of the organization. The trustee is the person in whose care the item resides. If the item is a workstation, then the trustee is the most common user of the workstation. For other equipment, the trustee is the primary person responsible for maintenance or supervision of the equipment. The trustee must fill out the Asset Transfer Checklist form and indicate whether the asset is a new asset, moving to a new location, being transferred to a new trustee, or being disposed. The following information must be included:
   • Asset Type
   • ID number
   • Asset Name
   • Current Location
   • Current Trustee
   • New Location
   • New Trustee
2. Locations of Sensitive Data: Once the trustee fills out and signs the Asset Transfer Checklist form, it must be signed by an authorized representative.
3. Data entry – After the Asset Transfer Checklist has been completed, it will be submitted to the asset tracking database manager. The asset tracking database manager will ensure that the information on the form is entered into the asset
   tracking database within one week.
4. Checking the database – Managers who oversee projects that result in a change to equipment location should check periodically to see if the assets that were moved have been updated in the asset tracking database. The database should include a recent move list that can be easily checked.

3.3 Media Sanitization

When transferring assets to another trustee, any confidential information on the device must be protected and/or destroyed. The method of data destruction is dependent upon the sensitivity of the data on the device and the next user of the device (i.e. within the organization and its control or outside the organization).
The following table depicts the three types of sanitization methods and the impact of each method

Sanitization Method	Appropriate Use	Description
Clear	If the media will be reused and will not be leaving the entity’s control.	Protects confidentiality of information against an attack by replacing written data with random data. Clearing must not allow information to be retrieved by data, disk or file recovery utilities.
Purge	If the media will be reused and leaving the entity’s control.	Protects confidentiality of information against an attack through either degaussing or Secure Erase.
Physical Destruction	If the media will not be reused at all.	Intent is to completely destroy the media.

1.Sanitization Decision Process
The decision process is based on the confidentiality of the information, not the type of media. The entities choose the type of sanitization to be used, and the type of sanitization is approved by the Information Owner. The technique used may vary by media type and by the technology available to the custodian, so long as the requirements of the sanitization type are met. Recommended Sanitization techniques for specific types of media are outlined in Appendix A of NIST 800-88, Rev. 1, Guidelines for Media Sanitization, Minimum Sanitization Recommendations.
Disposal without sanitization should be considered only if information disclosure would have no impact on organizational mission, would not result in damage to organizational assets, and would not result in financial loss or harm to any individuals.
The security categorization of the information, along with internal environmental factors, should drive the decisions on how to deal with the media. The key is to first think in terms of information confidentiality, then apply considerations based on media type.

The cost versus benefit of a sanitization process should be understood prior to a final decision. Entities can always increase the level of sanitization applied if that is reasonable and indicated by an assessment of the existing risk. For example, even though Clear or Purge may be the recommended solution, it may be more cost-effective (considering training, tracking, and validation, etc.) to destroy media rather than use one of the other options. Entities may not decrease the level of sanitization required.

2) Asset Disposal
Asset disposal is a special case since all sensitive data must be removed during or prior to disposal. The manager of the user of the asset should determine the level of sensitivity of the data stored on the device. The data erasure requirements for the device are based upon the sensitivity of the data as determined during the data assessment process:

• None (Unclassified) – No requirement to erase data. However, in the interest of prudence normally erase the data using any available means such as software based sanitization, physical destruction, or degaussing.
• Low (Sensitive) – Erase the data using any available means such as sanitization, physical destruction, or degaussing.
• Medium (Confidential) – The data must be erased using an approved technology in order to ensure that data is not recoverable using advanced forensic techniques.
• High (Secret) – The data must be erased using an approved technology to ensure that the data is not recoverable using advanced forensic. Approved technologies are to be specified in a Media Data Removal Procedure document. Asset types include:
  • Floppy disk
  • Memory stick
  • CD ROM disk
  • Storage tape
  • Hard drive.
  • RAM memory
  • ROM memory or ROM memory devices.

3) Media Use
This policy defines the types of data that may be stored on removable media, whether that media may be removed from a physically-secure facility, and under what conditions such removal would be permitted. Removable media includes the following:

• Floppy disk
• Memory stick
• CD ROM disk
• Storage tape

Removable media should be handled according to the sensitivity of data stored on the device as determined by the data assessment process:

• Unclassified – Data may be removed with approval by the first level manager and the permission is perpetual for the employee throughout the duration of employment unless revoked. The device may be sent to other offices using any
  public or private mail carrier.
• Sensitive – Data may only be removed from secure areas with the permission of a director level or higher level of management. Approvals are effective on a onetime bases only.
• Confidential – The data may only be removed from secure areas with the permission of a Vice President or higher level of management. Procedures for maintain data security while in transit and at the new destination of the media must
  be documented.
• Secret – The data may only be removed from secure areas with the permission of the President or higher level of management. Procedures for maintain data security while in transit and at the new destination of the media must be documented
• Top Secret – The data may never be removed from secure areas.

4. Control of Media
A factor influencing a sanitization decision is who has control and access to the media. This aspect must be considered when media leaves organizational control. Media control may be transferred when media are returned from a leasing agreement or are being donated or resold to be reused outside the organization. The following are examples of media control:

• Under SE Control:
  • Media being turned over for maintenance are still considered under the entity’s control if contractual agreements are in place and the maintenance provider specifically provides for the confidentiality of the information.
  • Maintenance being performed on an entity’s site, under the entity’s supervision, by a maintenance provider is also considered under the control of the entity.
• Not Under Entity Control:
  • Media that are being exchanged for warranty, cost rebate, or other purposes and where the specific media will not be returned to the entity are considered to be out of the entity’s control.

5. Reuse of Media
Entities should consider the cost versus benefit of reuse. It may be more cost-effective (considering training, tracking, and validation, etc.) to destroy media rather than use one of the other options.

6. Clear / Purge / Destroy

Method	Description
Clear	One method to sanitize media is to use software or hardware products to overwrite user- addressable storage space on the media with non-sensitive data, using the standard read and write commands for the device. This process may include overwriting not only the logical storage location of a file(s) (e.g., file allocation table) but also should include all user- addressable locations. The security goal of the overwriting process is to replace Target Data with non-sensitive data. Overwriting cannot be used for media that are damaged or not rewriteable and may not address all areas of the device where sensitive data may be retained. The media type and size may also influence whether overwriting is a suitable sanitization method. For example, flash memory-based storage devices may contain spare cells and perform wear levelling, making it infeasible for a user to sanitize all previous data using this approach because the device may not support directly addressing all areas where sensitive data has been stored using the native read and write interface. The Clear operation may vary contextually for media other than dedicated storage devices, where the device (such as a basic cell phone or a piece of office equipment) only provides the ability to return the device to factory state (typically by simply deleting the file pointers) and does not directly support the ability to rewrite or apply media-specific techniques to the non-volatile storage contents. Where rewriting is not supported, manufacturer resets and procedures that do not include rewriting might be the only option to Clear the device and associated media.  These still meet the definition for Clear as long as the device interface available to the user does not facilitate retrieval of the Cleared data.
Purge	Some methods of purging (which vary by media and must be applied with considerations described further throughout this document) include overwrite, block erase, and Cryptographic Erase, through the use of dedicated, standardized device sanitize commands that apply media-specific techniques to bypass the abstraction inherent in typical read and write commands. Destructive techniques also render the device Purged when effectively applied to the appropriate media type, including incineration, shredding, disintegrating, degaussing, and pulverizing. The common benefit across all these approaches is assurance that the data is infeasible to recover using state of the art laboratory techniques. However, Bending, Cutting, and the use of some emergency procedures (such as using a firearm to shoot a hole through a storage device) may only damage the media as portions of the media may remain undamaged and therefore accessible using advanced laboratory techniques. Degaussing renders a Legacy Magnetic Device Purged when the strength of the degausser is carefully matched to the media coercivity. Coercivity may be difficult to determine based only on information provided on the label. Therefore, refer to the device manufacturer for coercivity details. Degaussing should never be solely relied upon for flash memory-based storage devices or for magnetic storage devices that also contain non-volatile non-magnetic storage. Degaussing renders many types of devices unusable (and in those cases, Degaussing is also a Destruction technique).
Destroy	There are many different types, techniques, and procedures for media Destruction. While some techniques may render the Target Data infeasible to retrieve through the device interface and unable to be used for subsequent storage of data, the device is not considered Destroyed unless Target Data retrieval is infeasible using state of the art laboratory techniques.   Disintegrate, Pulverize, Melt, and Incinerate. These sanitization methods are designed to completely Destroy the media. They are typically carried out at an outsourced metal Destruction or licensed incineration facility with the specific capabilities to perform these activities effectively, securely, and safely.Shred. Paper shredders can be used to Destroy flexible media such as diskettes once the media are physically removed from their outer containers. The shred size of the refuse should be small enough that there is reasonable assurance in proportion to the data confidentiality that the data cannot be reconstructed. To make reconstructing the data even more difficult, the shredded material can be mixed with non-sensitive material of the same type (e.g., shredded paper or shredded flexible media). The application of Destructive techniques may be the only option when the media fails and other Clear or Purge techniques cannot be effectively applied to the media, or when the verification of Clear or Purge methods fails (for known or unknown reasons).

7. Validation

Entities must test a representative sampling of media for proper sanitization to assure that proper protection is maintained.

8 Verification of Equipment

If the entity is using sanitization tools (e.g., a degausser), the entity must have procedures to ensure that the tools are operating effectively.

9 Verification of Personnel Competencies

Entities must ensure that equipment operators are properly trained and competent to perform sanitization functions.

10 Document

Entities must maintain a record of their sanitization to document what media were sanitized, when, how they were sanitized, and the final disposition of the media.

3.4 Employee Purchase of Disposed Equipment

1. Equipment which is working, but reached the end of its useful life to XXX, will be made available for purchase by employees.
2. A lottery system will be used to determine who has the opportunity to purchase available equipment.
3. All equipment purchases must go through the lottery process. Employees cannot purchase their office computer directly or “reserve” a system. This ensures that all employees have an equal chance of obtaining equipment.
4. Finance and Information Technology will determine an appropriate cost for each item.
5. All purchases are final. No warranty or support will be provided with any equipment sold.
6. Any equipment not in working order or remaining from the lottery process will be donated or disposed of according to current environmental guidelines. Information
7. Technology has contracted with several organizations to donate or properly dispose of outdated technology assets.
8. Prior to leaving XXX premises, all equipment must be removed from the Information Technology inventory system.

3.5 Waste Disposal

Computer monitors, printers, scanners and fax machines are defined as hazardous waste due to the metals and chemicals used in their construction, and arrangements for their disposal must be handled in compliance with the organisation’s waste policies. This organisation must comply with its requirements under the Waste Electronic and Electrical Equipment Directive (WEEE). Small amounts of obsolete or broken IT equipment that has been effectively wiped of any data or does not contain any data storage potential can be disposed of through the electrical waste stream at a municipal site, or disposed of via the manufacturer or an electrical supplier. IT equipment must never be disposed of through general waste routes. It is illegal to mix computer waste with general waste or to send untreated computer waste to landfill.

4.0 Policy Compliance

4.1 Compliance Measurement
The IT team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.
4.2 Exceptions
Any exception to the policy must be approved by the IT team in advance.
4.3 Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

clause no	ISO 27001:2022 REQUIRED DOCUMENTATION	DOCUMENT DESCRIPTION
4.3	ISMS Scope	The ISMS Scope Statement defines the information assets your organization and ISMS is required to protect. ISO 27001 requirements state organizations must take into account the context of your organization, interested parties or stakeholders, and a description of your business location and org chart.
4.1	Organization and context	Company org chart, including key stakeholders
4.2	Stakeholders	List of key ISMS stakeholders that’s updated periodically. ISMS stakeholders include personnel that oversee and manage the ISMS, as well as those who depend on it to operate effectively.
4.4	ISMS Description	System description documentation including details of the ISMS purpose and high level overview of the system architecture. This can include a boundary overview and/or a high level description of the ISMS IT infrastructure and system diagram. Often times these descriptions can be found in ISMS policies, procedures, and guidelines.
5.1	Leadership	Evidence demonstrating company leadership is committed to maintaining and improving the ISMS. Documentation can include budgets, strategies, meeting minutes, and communications from senior management
5.2	Information Security Policy	The information security policy explain’s how management approaches information security. It defines how the company protects the confidentiality, integrity, and availability of sensitive data.
5.3	Information Security Roles and Responsibilities	Org charts and job descriptions including control owners responsible for particular security controls and processes
6.1.1	Actions to address risks and opportunities	ISMS management meeting minutes, audit reports and recommendations, remediation plans and corrective actions.
6.1.2, 6.1.3	Information Security Risk Assessment/Treatment Process and Plan	Documented Risk Assessment and Risk Treatment Process, which explains how you identify, evaluate, and prioritize risks. This document should also include how often you reviews and update your risk assessment and treatment plans.  Other documentation includes your Risk Treatment Plan, Risk register, and Risk matrix.
6.1.3	Statement of Applicability	The Statement of Applicability explains which Annex A security controls are — or aren’t — applicable to your organization’s ISMS. It should list the controls your organization has selected to mitigate risk, explain why these controls were chosen for your ISMS, state whether the controls have been fully implemented, and explain why any controls were excluded
6.2	Information Security Objectives and Plans	Document that outlines your organization’s business objectives and the risks associated with them, along with internal control objectives and metrics. Documentation can include budgets, strategies, meeting minutes, and communications from senior management.
7.1	ISMS Resources	Any documents concerning resources dedicated to maintaining and improving the ISMS, including audit reviews, incident reports, remediation plans, strategy/planning/budgeting documents, management meeting minutes, etc.
7.2	Competence	ISO 27001 requires organization to “retain documented information as evidence of competence.” For example, evidence of security awareness training for personnel directly involved with maintaining the ISMS
7.3	Employee Security Awareness and Training	Include any security awareness training materials, including posters, presentations, leaflets, quizzes, training course certificates, attendance records, etc.
7.4	Communication	Include any communications made about the ISMS, such as a certification announcement. Document any processes or policies made around what needs to be communicated, when, and to whom.
7.5.1	General documentation	How will you organize, review, and update your ISMS documentation? A spreadsheet like this one can be used as evidence, or a separate document management system.
7.5.2	Templates for creating and updating documentation	All ISMS documents should have templates that include elements like version control, revision history, management approval, etc.
7.5.3	Documentation control	Any reports about who has access to ISMS documents and the type of access they have (view/edit), classification type, etc.
8.1	Operational planning and control procedures	ISO 27001 requires organizations to maintain documentation that information security processes are being followed and carried out as they were intended. This can include budgets demonstrating the appropriate resources are being dedicating to maintaining and improving the ISMS, compliance activities relating to internal audits, incident reports, vulnerability assessments, penetration test reports, etc.
8.2	Risk assessment results	Periodic risk assessment reports, updated risk registers, meeting minutes where business risks were discussed — any documentation that shows your auditor that your processes yield useful information concerning business risks.
8.3	Risk treatment results	Risk treatment plan, penetration test reports, vulnerability assessments, internal audit reports, management reviews, control test reports
9.1	Metrics	Any security metrics reports, dashboards, presentations, emails, etc. that show the efficacy of the ISMS is being measured and those metrics are being acted upon.
9.2	ISMS Internal Audits	Internal audit reports, nonconformity reports and remediation timelines, audit calendars.
9.3	ISMS Management Reviews	Management review reports, calendars and plans for management reviews, recommendations.
10.1	Continuous improvement	Any documents that show continuous improvement of the ISMS. This can include internal/ external audit reports, incident reports, corrective action, ISMS planning, management meeting minutes etc.
10.2	Nonconformity and Corrective action	List of nonconformity and remediation plans, including owners and timelines. Incident reports, audit findings, or complaints may also be used as documentation. Your auditor needs to see that nonconformists are being identified and resolved.

The Policies

In addition, the following policy documents should be in place. Each policy applies to either all staff or specific functions, i.e. IT, HR, Facilities etc.

Control	Policy
A.5.1	Information Security Policy and Topic-Specific Policies such as a)access control; b) physical and environmental security; c) asset management; d) information transfer; e) secure configuration and handling of user endpoint devices; f) networking security; g) information security incident management; h) backup; i) cryptography and key management; j) information classification and handling; k) management of technical vulnerabilities; l) secure development.
A 5.7	Threat intelligence
A.5.9	Inventory of Information and Other Associated Assets
A.5.10	Rules For the Acceptable Use and Procedures for Handling Information and Other Associated Assets
A 5.12	Classification of information based on confidentiality, integrity, availability and relevant interested party requirements.
A.5.13	Procedures for Information Labeling
A.5.14	Information Transfer Rules, Procedures or Agreements
A.5.15	Topic-Specific Policy on And Rules for Access Control
A 5.18	Access rights to information and other associated assets based on Topic-Specific Policy on And Rules for Access Control
A.5.19	Processes And Procedures to Manage the Information Security Risks Associated with the Use of Supplier’s Products or Services
A.5.21	Processes and Procedures to Manage the Information Security Risks Associated with the ICT Products and Services Supply Chain
A.5.23	Processes for Acquisition, Use, Management and Exit from Cloud Services
A.5.24	Information Security Incident Management Processes, Roles and Responsibilities
A.5.28	Procedures for the Identification, Collection, Acquisition and Preservation of Evidence related to information security events
A 5.29	process for Information security during disruption
A 5.30	Plan for ICT readiness for business Continuity
A.5.31	Legal, Statutory, Regulatory and Contractual Requirements Relevant to Information Security
A.5.32	Procedures To Protect Intellectual Property Rights
A.5.37	Operating Procedures for Information Processing Facilities
A.6.2	Employment Contractual Agreements
A.6.4	Disciplinary Process
A.6.6	Confidentiality or Non-Disclosure Agreements
A 6.7	Remote working process and Remote access policy
A 7.7	Clear desk and clear screen rules
A 7.4	System monitoring
A 7.5	Protection against physical and Environmental threats
A 7.6	Working in secure area
A 7.9	Security of assets off-premises such as mobile device and laptop
A 7.10	Handling of storage media
A 7.14	Secure Disposal of equipment
A 8.1	User end point device
A.8.3	Topic-Specific Policy on Access Control for information and other associated assets restriction
A.8.5	Secure authentication technologies and procedures as per Topic-Specific Policy on Access Control
A 8.6	Capacity Management
A 8.7	Protection against malware
A 8.8	Management of technical vulnerabilities
A.8.9	Configurations, Including Security Configurations, of Hardware, Software, Services and Networks
A 8.11	Data Masking as per as per Topic-Specific Policy on Access Control
A.8.13	Topic-Specific Policy on Backup
A.8.15	Logs that Record Activities, Exceptions, Faults, and Other Relevant Events
A 8.19	Installation of software
A.8.21	Security Mechanisms, Service Levels and Service Requirements of Network Services
A 8.23	Web filtering
A.8.24	Rules for the Effective Use of Cryptography
A.8.25	Rules for the Secure Development of Software and Systems
A.8.26	Information Security Requirements for applications
A.8.27	Principles for Engineering Secure Systems in information system development activity
A.8.29	Security Testing Processes in development life cycle.
A 8.32	Change Management

Back to Home

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

1. Purpose

The use of desktops, laptops, mobile, and other Endpoint Devices (hereafter referred to as Endpoint Devices) are integral to a modern working environment. Many Endpoint Devices are increasingly mobile, which significantly increases the risk to the security of data both contained on and accessed by these devices. This policy addresses that risk by establishing the responsibilities of both Users and the Office of Information Technology (OIT) to maintain the security of data that is stored, accessed, or transmitted via Endpoint Devices.

2. Scope

This policy applies to any mobile device, or endpoint computer issued by XXX or used for XXX business which contains stored data owned by XXX.

3. Policy

All employees shall assist in protecting devices issued by XXX or storing XXX data. Users are expressly forbidden from storing XXX data on devices that are not issued by XXX, such as storing XXX email on a personal cell phone or PDA.

3.1 Information Security

• All care is taken to prevent unintended exposure, modification, or removal of private, copyright, or confidential information as a result of leaving this information on the screen or desk, or exposed in such a way that it can be viewed or accessed by an unauthorised individual. This includes information stored on portable storage media or hard copy.
• Any private, sensitive, or confidential information that is stored on such an Endpoint device has the appropriate security controls to restrict and prevent retrieval or intercept by an unauthorised third-party.
• Business information and work is stored in such a way as to enable an authorised back-up service to store and protect the information.

3.2 Workstation Security

1. Workforce members using workstations shall consider the sensitivity of the information, that may be accessed and minimize the possibility of unauthorized access.
2. XXX will implement physical and technical safeguards for all workstations that access electronic protected information to restrict access to authorized users.
3. Appropriate measures includes:
   • Restricting physical access to workstations to only authorized personnel.
   • Securing workstations (screen lock or logout) prior to leaving area to prevent unauthorized access.
   • Enabling a password-protected screen saver with a short timeout period to ensure that workstations that were left unsecured will be protected.  The password must comply with XXX‘s Password Policy.
   • Complying with all applicable password policies and procedures. See XXX‘sPassword Policy.
   • Ensuring workstations are used for authorized business purposes only.
   • Never installing unauthorized software on workstations.
   • Storing all sensitive information, on network servers 
   • Keeping food and drink away from workstations in order to avoid accidental spills.
   • Securing laptops that contain sensitive information by using cable locks or locking laptops up in drawers or cabinets.
   • Installing privacy screen filters or using other physical barriers to alleviate exposing data.
   • Ensuring workstations are left on but logged off in order to facilitate after-hours updates.
   • Exit running applications and close open documents
   • Ensuring that all workstations use a surge protector (not just a power strip) or a UPS (battery backup).
   • If wireless network access is used, ensure access is secure by following the Wireless Communication policy

3.3 Endpoint Software
All software contains security vulnerabilities, and software vendors are constantly supplying updates (patches) to address these vulnerabilities when they are identified.

• Endpoint software Operating Systems (OS) and application software are to be kept up to date with the latest security related patches, as soon as it is practical to do so, i.e.:
  • Critical security patches are applied within 1 week of them being released by vendors.
  • Important security patches are applied within 8 weeks of them being release by vendors.
  • Endpoint systems must be restarted following installation, to ensure security patches have been fully installed.
  • Where possible, it is recommended that Endpoint devices are set to auto-update their security patch levels, and restart if necessary to complete the installation.
• OSs that reach end of support life are by default not permitted to connect to the University network. This is because security patches are no longer provided by vendors and this poses a growing security threat to the environment over time. If a special exemption is required, this must be requested formally via the IT Service Desk and approved by the CIO.
• IT will install Endpoint device management software, as required, on any Endpoint connected to the XXX network in order to manage XXX policy, legal, and commercial compliance requirements.
• The removing or disabling of Endpoint device management software without prior approval of IT is considered a breach of this policy.
• IT will audit XXX owned Endpoint devices as required, and has the ability to install updates to software on these devices to address software vulnerabilities or licensing issues with IT’s managed software.
• Departments who choose to operate and manage their own specific software on Endpoint devices accept responsibility for the associated licensing, installation, updates, and security as it relates this software, in accordance with this policy.

3.4 Administrative Access
In accordance with the principle of least privilege, unnecessary administrative access on XXX owned Endpoint devices will be restricted.

3.5 Authentication
Endpoint devices containing XXX information assets that are not publicly available, or devices which attach to XXX’s network, must be secured as appropriate by a network or locally based user code and password or a PIN.

3.6 Antivirus Software & Firewalls

• All Endpoint devices capable of running an antivirus software program are required to do so before being connecting to the Massey internal network. Additionally, any such antivirus software must be running the latest virus definitions to accurately detect the latest viruses and malware, and be set to automatically update when newer definitions become available.
• Disabling or removing of Antivirus software, or disabling of Antivirus software definition updates on endpoints is prohibited.
• All Endpoint devices capable of running local Firewall software are required to do so to protect the device from external threats such as hacking by unauthorised parties.

3.7 Servers & Web Applications

• All Servers (or devices exposed to the internet, in the DMZ, or running web services), will be ‘hardened’, meaning they will have all the necessary security updates applied to their Operating System’s, hardware patches (firmware updates), and installed software; to reduce the chances of vulnerabilities being exploited. All such updates must be reviewed and maintained regularly to ensure they remain up to date. It is the Server Administrator’s responsibility to manage this.
• New Services that are externally (internet) facing will require independent security vulnerability and penetration testing to be performed by a security specialist prior to implementation, and subsequently added to the IT Security Review Schedule, to provide assurance that data or services won’t be exposed to medium or high risk security threats.

3.8 Network Segmentation
Endpoint devices will be attached to XXX’s network within the appropriate network segment as determined by applicable Endpoint security controls.

3.9 Personal devices
Personal devices (i.e. those not purchased or owned by XXX) that are authorised to connect to the XXX’s network remain the responsibility of the owner, and must comply with this policy.

3.10 Information Technology (IT) Security Services
IT Security Services will:

• Provide support and advice on this policy via the IT Service Desk,
• Maintain and manage the XXX’s security infrastructure, such as firewalls, and implement intrusion detection and prevention practices in order to limit threats and provide early detection of security breaches where possible.
• Provide anti-spam and anti-virus protection on endpoints they are directly responsible for, and ensure these are kept up to date.
• Work with departments on the security principle of “least privilege” in order to manage the security model for both user and endpoint devices.
• Manage the accounts and user code policies and technology necessary to manage device and user authentication, as well as install any necessary controls required to manage Endpoint devices that connect to the network.
• Monitor endpoint device connectivity and activity as it relates to managing and protecting the XXX’s network.
• Disconnect, isolate, or restrict, any endpoint device without notice that is identified to pose a threat or is impacting the confidentiality, integrity, or availability of the XXX’s network.
• Manage the IT infrastructure network Internet Protocol (IP) numbering and network segmentation scheme to administer and isolate the environment, and apply necessary protective controls to manage endpoints as securely as possible.
• Apply any required security or encryption standards necessary to protect endpoints that are identified as storing sensitive or confidential data.
• Apply security updates as per this policy for Endpoint devices, on-behalf of the XXX.

3.11 Browser Add-ons
In general, XXX does not recommend using Browser Add-ons, however we do not forbid the use of these tools if they enhance productivity. After installing a Browser Add-on, employees shall run a browser testing tool. See MS Endpoint Privacy & Security Guidelines for recommended testing tools.

4. Policy Compliance

4.1 Compliance Measurement

The IT team will verify compliance to this policy through various methods, including but not limited to, periodic walk-through, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner.

4.2 Exceptions

Any exception to the policy must be approved by the IT team in advance.

4.3 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

1. Purpose

The purpose is to define the appropriate uses of the Internet by XXX’s employees and affiliates. Also define standards for systems that monitor and limit web use from any host within XXX’s network. These standards are designed to ensure employees use the Internet in a safe and responsible manner, and ensure that employee web use can be monitored or researched during an incident.

2. Scope

The Internet usage Policy applies to all Internet users (individuals working for the company, including permanent full-time and part-time employees, contract workers, temporary agency workers, business partners, and vendors) who access the Internet through the computing or networking resources. The company’s Internet users are expected to be familiar with and to comply with this policy, and are also required to use their common sense and exercise their good judgment while using Internet services. It also applies to all end user initiated communications between XXX’s network and the Internet, including web browsing, instant messaging, file transfer, file sharing, and other standard and proprietary protocols. Server to Server communications, such as SMTP traffic, backups, automated data transfers or database communications are excluded from this policy

3. Internet Usage Policy

3.1 Resource Usage

Access to the Internet will be approved and provided only if reasonable business needs are identified. Internet services will be granted based on an employee’s current job responsibilities. If an employee moves to another business unit or changes job functions, a new Internet access request must be submitted within 5 days. User Internet access requirements will be reviewed periodically by company departments to ensure that continuing needs exist.

1 Internet Services Allowed
Internet access is to be used for business purposes only. Capabilities for the following standard Internet services will be provided to users as needed:

• E-mail — Send/receive E-mail messages to/from the Internet (with or without document attachments).
• Navigation — WWW services as necessary for business purposes, using a hypertext transfer protocol (HTTP) browser tool. Full access to the Internet; limited access from the Internet to dedicated company public web servers only.
• File Transfer Protocol (FTP) — Send data/files and receive in-bound data/files, as necessary for business purposes.
• Telnet — Standard Internet protocol for terminal emulation. User Strong Authentication required for Internet initiated contacts into the company.
  Management reserves the right to add or delete services as business needs change or conditions warrant.
  All other services will be considered unauthorized access to/from the Internet and will not be allowed.

2 Request & Approval Procedures
Internet access will be provided to users to support business activities and only as needed to perform their jobs.

• Request for Internet Access: As part of the Internet access request process, the employee is required to read both this Internet usage Policy and the associated Internet/Intranet Security Policy The user must then sign the statements (located on the last page of each document) that he/she understands and agrees to comply with the policies. Users not complying with these policies could be subject to disciplinary action up to and including termination. Policy awareness and acknowledgment, by signing the acknowledgment form, is required before access will be granted.
• Approval: Internet access is requested by the user or user’s manager submitting an IT Access Request form to the IT department along with an attached copy of a signed Internet usage Coverage Acknowledgment Form.
• Removal of privileges: Internet access will be discontinued upon termination of employee, completion of contract, end of service of non-employee, or disciplinary action arising from violation of this policy. In the case of a change in job function and/or transfer the original access code will be discontinued, and only reissued if necessary and a new request for access is approved.

All user IDs that have been inactive for thirty (30) days will be revoked. The privileges granted to users must be reevaluated by management annually. In response to feedback from management, systems administrators must promptly revoke all privileges no longer needed by users.

3.2 Allowed Usage

Internet usage is granted for the sole purpose of supporting business activities necessary to carry out job functions. All users must follow the corporate principles regarding resource usage and exercise good judgment in using the Internet. Questions can be addressed to the IT Department. Acceptable use of the Internet for performing job functions might include:

• Communication between employees and non-employees for business purposes;
• IT technical support downloading software upgrades and patches;
• Review of possible vendor web sites for product information;
• Reference regulatory or technical information.
• Research

3.3 Personal Usage

Using company computer resources to access the Internet for personal purposes, without approval from the user’s manager and the IT department, may be considered cause for disciplinary action up to and including termination. All users of the Internet should be aware that the company network creates an audit log reflecting request for service, both in-bound and out-bound addresses, and is periodically reviewed. Users who choose to store or transmit personal information such as private keys, credit card numbers or certificates or make use of Internet “wallets” do so at their own risk. The company is not responsible for any loss of information, such as information stored in the wallet, or any consequential loss of personal property

3.4 Prohibited Usage

Information stored in the wallet, or any consequential loss of personal property. Acquisition, storage, and dissemination of data which is illegal, pornographic, or which negatively depicts race, sex or creed is specifically prohibited. The company also prohibits the conduct of a business enterprise, political activity, engaging in any form of intelligence collection from our facilities, engaging in fraudulent activities, or knowingly disseminating false or otherwise libelous materials. Other activities that are strictly prohibited include, but are not limited to:

• Accessing company information that is not within the scope of one’s work. This includes unauthorized reading of customer account information, unauthorized access of personnel file information, and accessing information that is not needed for the proper execution of job functions.
• Misusing, disclosing without proper authorization, or altering customer or personnel information. This includes making unauthorized changes to a personnel file or sharing electronic customer or personnel data with unauthorized personnel.
• Deliberate pointing or hyper-linking of company Web sites to other Internet/WWW sites whose content may be inconsistent with or in violation of the aims or policies of the company.
• Any conduct that would constitute or encourage a criminal offense, lead to civil liability, or otherwise violate any regulations, local, state, national or international law including without limitations US export control laws and regulations.
• Use, transmission, duplication, or voluntary receipt of material that infringes on the copyrights, trademarks, trade secrets, or patent rights of any person or organization. Assume that all materials on the Internet are copyright and/or patented unless specific notices state otherwise.
• Transmission of any proprietary, confidential, or otherwise sensitive information without the proper controls.
• Creation, posting, transmission, or voluntary receipt of any unlawful, offensive, libelous, threatening, harassing material, including but not limited to comments based on race, national origin, sex, sexual orientation, age, disability, religion, or political beliefs.
• Any form of gambling.

Unless specifically authorized under the provisions of section 4.3, the following activities are also strictly prohibited:

• Unauthorized downloading of any shareware programs or files for use without authorization in advance from the IT Department and the user’s manager.
• Any ordering (shopping) of items or services on the Internet.
• Playing of any games.
• Forwarding of chain letters.
• Participation in any on-line contest or promotion.
• Acceptance of promotional gifts.

Bandwidth both within the company and in connecting to the Internet is a shared, finite resource. Users must make reasonable efforts to use this resource in ways that do not negatively affect other employees. Specific departments may set guidelines on bandwidth use and resource allocation, and may ban the downloading of particular file types.

3.5 Software License

The company strongly supports strict adherence to software vendors’ license agreements. When at work, or when company computing or networking resources are employed, copying of software in a manner not consistent with the vendor’s license is strictly forbidden. Questions regarding lawful versus unlawful copying should be referred to the IT Department for review or to request a ruling from the Legal Department before any copying is done. Similarly, reproduction of materials available over the Internet must be done only with the written permission of the author or owner of the document. Unless permission from the copyright owner(s) is first obtained, making copies of material from magazines, journals, newsletters, other publications and online documents is forbidden unless this is both reasonable and customary. This notion of “fair use” is in keeping with international copyright laws. Using company computer resources to access the Internet for personal purposes, without approval from the user’s manager and the IT department, may be considered cause for disciplinary action up to and including termination. All users of the Internet should be aware that the company network creates an audit log reflecting request for service, both in-bound and out-bound addresses, and is periodically reviewed. Users who choose to store or transmit personal information such as private keys, credit card numbers or certificates or make use of Internet “wallets” do so at their own risk.

3.6 Review of Public Information

All publicly-writeable directories on Internet-connected computers will be reviewed and cleared each evening. This process is necessary to prevent the anonymous exchange of information inconsistent with company business. Examples of unauthorized public information include pirated information, passwords, credit card numbers, and pornography.

3.7 Expectation of Privacy

1 Monitoring
Users should consider their Internet activities as periodically monitored and limit their activities accordingly. Management reserves the right to examine E-mail, personal file directories, web access, and other information stored on company computers, at any time and without notice. This examination ensures compliance with internal policies and assists with the management of company information systems.
2 E-mail Confidentiality
Users should be aware that clear text E-mail is not a confidential means of communication. The company cannot guarantee that electronic communications will be private. Employees should be aware that electronic communications can, depending on the technology, be forwarded, intercepted, printed, and stored by others. Users should also be aware that once an E-mail is transmitted it may be altered. Deleting an E-mail from an individual workstation will not eliminate it from the various systems across which it has been transmitted.

3.8 Maintaining Corporate Image

1 Representation
When using company resources to access and use the Internet, users must realize they represent the company. Whenever employees state an affiliation to the company, they must also clearly indicate that “the opinions expressed are my own and not necessarily those of the company”. Questions may be addressed to the IT Department.
2 Company Materials
Users must not place company material (examples: internal memos, press releases, product or usage information, documentation, etc.) on any mailing list, public news group, or such service. Any posting of materials must be approved by the employee’s manager and the public relations department and will be placed by an authorized individual.

3.9 Periodic Reviews

1 Usage Compliance Reviews
To ensure compliance with this policy, periodic reviews will be conducted. These reviews will include testing the degree of compliance with usage policies.
2 Policy Maintenance Reviews
Periodic reviews will be conducted to ensure the appropriateness and the effectiveness of usage policies. These reviews may result in the modification, addition, or deletion of usage policies to better suit company information needs.

4. Web Filtering policy

4.1 Web Site Monitoring

The Information Technology Department shall monitor Internet use from all computers and devices connected to the corporate network. For all traffic the monitoring system must record the source IP Address, the date, the time, the protocol, and the destination site or server. Where possible, the system should record the User ID of the person or account initiating the traffic. Internet Use records must be preserved for 180 days.

4.2 Access to Web Site Monitoring Reports

General trending and activity reports will be made available to any employee as needed upon request to the Information Technology Department. Computer Security Incident Response Team (CSIRT) members may access all reports and data if necessary to respond to a security incident. Internet Use reports that identify specific users, sites, teams, or devices will only be made available to associates outside the CSIRT upon written or email request to Information Systems from a Human Resources Representative.

4.3 Internet Use Filtering System

The Information Technology Department shall block access to Internet websites and protocols that are deemed inappropriate for XXX’s corporate environment. The following protocols and categories of websites should be blocked:

• Adult/Sexually Explicit Material
• Advertisements & Pop-Ups
• Chat and Instant Messaging
• Gambling
• Hacking
• Illegal Drugs
• Intimate Apparel and Swimwear
• Peer to Peer File Sharing
• Personals and Dating
• Social Network Services
• SPAM, Phishing and Fraud
• Spyware
• Tasteless and Offensive Content
• Violence, Intolerance and Hate
• Web Based Email

4.4 Internet Use Filtering Rule Changes

The Information Technology Department shall periodically review and recommend changes to web and protocol filtering rules. Human Resources shall review these recommendations and decide if any changes are to be made. Changes to web and protocol filtering rules will be recorded in this Policy.

4.5 Internet Use Filtering Exceptions

If a site is mis-categorized, employees may request the site be un-blocked by submitting a ticket to the Information Technology help desk. An IT employee will review the request and un-block the site if it is mis-categorized.

Employees may access blocked sites with permission if appropriate and necessary for business purposes. If an employee needs access to a site that is blocked and appropriately categorized, they must submit a request to their Human Resources representative. HR will present all approved exception requests to Information Technology in writing or by email. Information Technology will unblock that site or category for that associate only. Information Technology will track approved exceptions and report on them upon request.

5. Policy Compliance

5.1 Compliance Measurement

The IT team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.

5.2 Exceptions

Any exception to the policy must be approved by the IT Team in advance.

5.3 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Additionally, the company may at its discretion seek legal remedies for damages incurred as a result of any violation. The company may also be required by law to report certain illegal activities to the proper enforcement agencies. Before access to the Internet via company network is approved, the potential Internet user is required to read this Internet usage Policy and sign an acknowledgment form (located on the last page of this document). The signed acknowledgment form should be turned in and will be kept on file at the facility granting the access. For questions on the Internet usage Policy, contact the Information Technology (IT) Department.