policy

Lab Security Policy

1.     Overview

See Purpose.

2.     Purpose

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

3.     Scope

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

4.     Policy

4.1   General Requirements

4.1.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 InfoSec 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.

4.1.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 university from security vulnerabilities.

4.1.3        Lab managers are responsible for the lab's compliance with all university security policies.

4.1.4        All user passwords must comply with university 's Password Policy.

4.1.5        PC-based lab computers must have university '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.

4.1.6        Any activities with the intention to create and/or distribute malicious programs into university 's networks (e.g., viruses, worms, Trojan horses, e-mail bombs, etc.) are prohibited, in accordance with the Acceptable Use Policy.

4.1.7        In accordance with the Data Classification Policy, information that is marked as university Highly Confidential or universityRestricted is prohibited on lab equipment.

4.1.8        Immediate access to equipment and system logs must be granted to members of InfoSec and the Network Support Organization upon request, in accordance with the Audit Policy.

4.1.9        InfoSec will address non-compliance waiver requests on a case-by-case basis and approve waivers if justified.

4.2  Internal Lab Security Requirements

4.2.1        The Network Support Organization must maintain a firewall device between the corporate production network and all lab equipment.

4.2.2        The Network Support Organization and/or InfoSec reserve the right to interrupt lab connections that impact the corporate production network negatively or pose a security risk.

4.2.3        The Network Support Organization must record all lab IP addresses, which are routed within university networks, in Enterprise Address Management database along with current contact information for that lab.

4.2.4        Any lab that wants to add an external connection must provide a diagram and documentation to InfoSec with business justification, the equipment, and the IP address space information. InfoSec will review for security concerns and must approve before such connections are implemented.

4.2.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.

4.2.6        Original firewall configurations and any changes thereto must be reviewed and approved by InfoSec. InfoSec may require security improvements as needed.

4.2.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- university networks. These activities must be restricted within the lab.

4.2.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.

4.2.9        InfoSec 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.

4.2.10    Lab owned gateway devices are required to comply with all university product security advisories and must authenticate against the Corporate Authentication servers.

4.2.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 university 's Password Policy.  The password will only be provided to those who are authorized to administer the lab network.

4.2.12    In labs where non university personnel have physical access (e.g., training labs), direct connectivity to the corporate production network is not allowed. Additionally, no university 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 InfoSec.

4.2.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.

4.2.14    The Network Support Organization and InfoSec reserve the right to interrupt lab connections if a security concern exists.
4.2.15   the university have to make all the student log in withe their account and didn't lat them log in withe the class room         

5.     Policy Compliance

5.1  Compliance Measurement

The Infosec team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, 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 Infosec 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.

6       Related Standards, Policies and Processes

·         Audit Policy

·         Acceptable Use Policy

·         Data Classification Policy

·         Password Policy

7       Definitions and Terms

The following definition and terms can be found in the SANS Glossary located at:

https://www.sans.org/security-resources/glossary-of-terms/

·         DMZ

·         Firewall

nada mufareh

Risk Assessment Policy

1.     Overview

See Purpose.

2.     Purpose

To empower Infosec to perform periodic information security risk assessments (RAs) for the purpose of determining areas of vulnerability, and to initiate appropriate remediation.

3.     Scope

Risk assessments can be conducted on any entity within  University or any outside entity that has signed a Third Party Agreement with University. RAs can be conducted on any information system, to include applications, servers, and networks, and any process or procedure by which these systems are administered and/or maintained.

4.     Policy

The execution, development and implementation of remediation programs is the joint responsibility of Infosec and the department responsible for the system area being assessed. Employees are expected to cooperate fully with any RA being conducted on systems for which they are held accountable. Employees are further expected to work with the Infosec Risk Assessment Team in the development of a remediation plan.

For additional information, go to the Risk Assessment Process.

5.     Policy Compliance

5.1  Compliance Measurement

The Infosec 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 Infosec 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.

6       Related Standards, Policies and Processes

·         Risk Assessment Process

·         Third Party Agreement

Acil Hussain

Disaster Recovery Plan Policy

1.     Overview

Since disasters happen so rarely, management often ignores the disaster recovery planning process.  It is important torealize that having a contingency plan in the event of a disaster gives <Company Name> a competitive advantage.   Thispolicy requires management to financially support and diligently attend to disaster contingency planning efforts.  Disastersare not limited to adverse weather conditions.   Any event that could likely cause an extended delay of service should be considered.  The Disaster Recovery Plan is often part of the Business Continuity Plan.

2.     Purpose

This policy defines the requirement for a baseline disaster recovery plan to be developed and implemented by <Company Name> that will describe the process to recover IT Systems, Applications and Data from any type of disaster that causes a major outage.

3.     Scope

This policy is directed to the IT Management Staff who is accountable to ensure the plan is developed, tested and kept up-to-date.  This policy is solely to state the requirement to have a disaster recovery plan, it does not provide requirement around what goes into the plan or sub-plans.

4.     Policy

4.1 Contingency Plans

The following contingency plans must be created:

·         Computer Emergency Response Plan: Who is to be contacted, when, and how? What immediate actions mustbe taken in the event of certain occurrences?

·         Succession Plan: Describe the flow of responsibility when normal staff is unavailable to perform their duties.

·         Data Study: Detail the data stored on the systems, its criticality, and its confidentiality.

·         Criticality of Service List: List all the services provided and their order of importance.

·         It also explains the order of recovery in both short-term and long-term timeframes.

·         Data Backup and Restoration Plan: Detail which data is backed up, the media to which it is saved, where that media is stored, and how often the backup is done.  It should also describe how that data could be recovered.

·         Equipment Replacement Plan: Describe what equipment is required to begin to provide services, list the orderin which it is necessary, and note where to purchase the equipment.

·         Mass Media Management: Who is in charge of giving information to the mass media?

·         Also provide some guidelines on what data is appropriate to be provided.

After creating the plans, it is important to practice them to the extent possible.   Management should set aside time to test implementation of the disaster recovery plan.  Table top exercises should be conducted annually. During these tests, issues that may cause the plan to fail can be discovered and corrected in an environment that has few consequences.

The plan, at a minimum, should be reviewed an updated on an annual basis.

5.     Policy Compliance

5.1  Compliance Measurement

The Infosec team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, 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 Infosec 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.

6       Related Standards, Policies and Processes

None.

7       Definitions and Terms

The following definition and terms can be found in the SANS Glossary located at:

https://www.sans.org/security-resources/glossary-of-terms/

·         Disaster

Sulafah Basahl