General Policies & Standards

Acceptable Use of Information Technology Resources Policy - Full Text (Draft Living Document)

1.0 Purpose and Benefits

Appropriate organizational use of information and information technology (“IT”) resources and effective security of those resources requires the participation and support of the organization’s workforce (“users”).  Inappropriate use exposes the organization to potential risks, including virus attacks, compromised network systems and services compromise, and legal issues.

Queens College’s computer resources are dedicated to the support of the College’s mission of education, research, and public service. In furtherance of this mission, Queens College respects, upholds, and endeavors to safeguard the principles of academic freedom, freedom of expression and freedom of inquiry.

Queens College recognizes that there is a concern among the University community that because information created, used, transmitted or stored in electronic form is by its nature susceptible to disclosure, invasion, loss, and similar risks, electronic communications and transactions will be particularly vulnerable to infringements of academic freedom. Queens College’s commitment to the principles of academic freedom and freedom of expression includes electronic information. Therefore, whenever possible, Queens College will resolve doubts about the need to access Queens College’s Computer Resources in favor of a user’s privacy interest.

However, the use of Queens College Computer Resources, including for electronic transactions and communications, like the use of other University-provided resources and activities, is subject to the requirements of legal and ethical behavior. This policy is intended to support the free exchange of ideas among members of the Queens College community and between the Queen’s College community and other communities, while recognizing the responsibilities and limitations associated with such exchange.

2.0 Authority

  • Responsible Office(s): Queens College Information Technology Services
  • Responsible Executive(s): Chief Information Officer (CIO)
  • Responsible Officer(s): Chief Information Security Officer (CISO)

3.0 Scope

This is a college-wide policy and includes requirements that must be followed if Queens College is to protect the information that is collected in the standard process of business. This policy is to be an additional layer of security on top of existing CUNY security policies and is not intended to or able to supersede CUNY policies.

This policy encompasses all systems, automated and manual, for which Queens College has administrative responsibility, including systems managed or hosted by third parties on behalf of Queens College. It addresses all information, regardless of the form or format, which is created or used in support of business activities.

4.0 Information Statement

Rules for Use of Queens College Computer resources

Authorization

    1. Users may not access a Queens College Computer Resource without authorization or use it for purposes beyond the scope of authorization. This includes attempting to circumvent Queens College Computer Resource system protection facilities by hacking, cracking or similar activities, accessing or using another person’s computer account, and allowing another person to access or use the User’s account.
    2. Notwithstanding subsection 1.a. above, a User may authorize a colleague or clerical assistant to access information under the User’s account on the User’s behalf while away from a Queens College campus or when the User is unable to efficiently access the information on the User’s own behalf (including as a result of a disability), but delegated access will be subject to the rules of Section 10 – Security, below.
    3. Queens College Computer Resources may not be used to gain unauthorized access to another computer system within or outside of Queens College. Users are responsible for all actions performed from their computer account that they permitted or failed to prevent by following ordinary security precautions.

Purpose

    1. Use of Queens College Computer Resources is generally limited to activities relating to the performance by Queens College employees of their duties and responsibilities, by students in connection with their college courses and activities, and by retired Queens College teaching faculty, librarians, and other retired employees approved by the college president or where the employee is a member of the Central Office staff then by the Chancellor or his or her designee. For example, use of Queens College Computer Resources for private commercial or not-for-profit business purposes, for private advertising of products or services, or for any activity meant solely to foster personal gain, is prohibited. Similarly, use of Queens College Computer Resources for partisan political activity is also prohibited.
    2. Except with respect to Queens College employees other than faculty, where a supervisor has prohibited it in writing, incidental personal use of Queens College Computer Resources is permitted so long as such use does not interfere with Queens College operations, does not compromise the functioning of Queens College Computer Resources, does not interfere with the User’s employment or other obligations to Queens College, and is otherwise in compliance with this policy, including subsection 2.a. above. Users should be aware that personal messages, data and other information sent or received through a User’s Queens College account or otherwise residing in a Queens College Computer Resource are subject to Queens College review pursuant to Section 13 of this policy and may also be subject to public disclosure pursuant to FOIL.

Compliance with Law

    1. Queens College Computer Resources may not be used for any purpose or in any manner that violates Queens College rules, regulations or policies, or federal, state or local law. Users who engage in electronic communications with persons in other states or countries or on other systems or networks may also be subject to the laws of those other states and countries, and the rules and policies of those other systems and networks. Users are responsible for ascertaining, understanding, and complying with the laws, rules, policies, contracts, and licenses applicable to their particular use.
    2. Examples of applicable federal and state laws include those addressing defamation, invasion of privacy, obscenity and child pornography, and online gambling, as well as the following:
      1. Computer Fraud and Abuse Act
      2. Copyright Act of 1976
      3. Electronic Communications Privacy Act
      4. Export control regulations issued by the U.S. Departments of Commerce, State and Treasury
      5. Family Educational Rights and Privacy Act
      6. FOIL
      7. New York State Law with respect to the confidentiality of library records
    3. Examples of applicable Queens College rules and policies include those listed below. Other rules and policies may be found in the Manual of General Policy and on the Queens College Legal Affairs website:
      1. Gramm-Leach-Bliley Information Security Program
      2. IT Security Policies & Procedures
      3. Policy on Maintenance of Public Order (the “Henderson Rules”) Sexual Harassment Policy
      4. University Policy on Academic Integrity
      5. Web Site Privacy Policy

Licenses and Intellectual Property

    1. Users may use only legally obtained, licensed data or software and must comply with applicable licenses or other contracts, as well as copyright, trademark and other intellectual property laws.
    2. Much of what appears on the internet and/or is distributed via electronic communication is protected by copyright law, regardless of whether the copyright is expressly noted. Users should generally assume that material is copyrighted unless they know otherwise, and not copy, download or distribute copyrighted material without permission unless the use does not exceed fair use as defined by the federal Copyright Act of 1976. Protected material may include, among other things, text, photographs, audio, video, graphic illustrations, and computer software. Additional information regarding copyright and file sharing is available on the Queens College Legal Affairs website.

False Identity and Harassment.

    1. Users may not employ a false identity, mask the identity of an account or computer, or use Queens College Computer Resources to engage in abuse of others, such as sending harassing, obscene, threatening, abusive, deceptive, or anonymous messages within or outside Queens College.

Confidentiality

    1. Users may not invade the privacy of others by, among other things, viewing, copying, redistributing, posting such data to the Internet, modifying or destroying data or programs belonging to or containing personal or confidential information about others, without explicit permission to do so.
    2. Queens College employees must take precautions by following all IT Security Policies and Procedures to protect the confidentiality of Non-Public University Information encountered in the performance of their duties or otherwise.

Integrity of Computer Resources

      1. Computer Configurations
        1. Users may not modify the hardware configuration of any Computer Resource without the express written permission of Information Technology Services, which can be requested through the ITS Help Desk system.
        2. Users may not modify/replace the Operating System of any Computer Resource without the without the express written permission of Information Technology Services, which can be requested through the ITS Help Desk system.
        3. Software installed on any Computer Resource is to be approved by Information Technology Services with written permission, which can be requested through the ITS Help Desk system.

Disruptive Activities

    1. Queens College Computer Resources must not be used in a manner that could reasonably be expected to cause or does cause, directly or indirectly, unwarranted or unsolicited interference with the activity of other users, including:
      1. chain letters, virus hoaxes or other e-mail transmissions that potentially disrupt normal e-mail service;
      2. spamming, junk mail or other unsolicited mail that is not related to Queens College business and is sent without a reasonable expectation that the recipient would welcome receiving it;
      3. the inclusion on e-mail lists of individuals who have not requested membership on the lists, other than the inclusion of members of the Queens College community on lists related to Queens College business; and
      4. downloading of large videos, films or similar media files for personal use.
    2. Queens College has the right to require Users to limit or refrain from other specific uses if, in the opinion of the CIO or CISO, such use interferes with efficient operations of the system, subject to appeal to the President.
    3. Users may not install, use or develop programs intended to infiltrate or damage a Queens College Computer Resource, or which could reasonably be expected to cause, directly or indirectly, excessive strain or theft of confidential data on any computing facility. This includes, but is not limited to, programs known as computer viruses, Trojan horses, and worms. Users should consult with the IT director at their college before installing any programs on Queens College Computer Resources that they are not sure are safe or may cause excess strain.

Queens College Names and Trademarks

    1. Queens College names, trademarks and logos belong to the University and are protected by law. Users of Queens College Computer Resources may not state or imply that they speak on behalf of Queens College or use a Queens College name, trademark or logo without authorization to do so. Affiliation with Queens College does not, by itself, imply authorization to present any information on behalf of Queens College.
    2. Non-Queens College Computer Resources may not use a Queens College name, trademark or logo without written authorization to do so. Affiliation with Queens College does not, by itself, imply authorization to present any information on behalf of Queens College.
    3. Notwithstanding subsection above, Queens College employees and students may indicate their Queens College affiliation on e-mail, other correspondence, and in academic or professionally-related research, publications or professional appearances, so long as they do not state or imply that they are presenting information on behalf of the College.

Security

    1. Queens College employs various measures to protect the security of its computer resources and of Users’ accounts. However, Queens College cannot guarantee such security. Users are responsible for engaging in safe computing practices such as guarding and not sharing their passwords, changing passwords regularly, logging out of systems at the end of use, and protecting Non-Public University Information, as well as for following Queens College’s IT Security Policies and Procedures.
    2. Users must report incidents of non-compliance with IT Security Policies and Procedures or other security incidents to the Chief Information Officer and Chief Information Security Officer.

Filtering

    1. Queens College reserves the right to install spam, anti-malware, and spyware filters and similar devices if necessary in the judgment of Queens College’s Office of Information Technology to protect the security and integrity of Queens College Computer Resources. Queens College will not install filters that restrict access to e-mail, instant messaging, chat rooms or websites based solely on content, unless such content is illegal, such as child pornography sites.

Confidential Research Information

    1. Principal investigators and others who use Queens College Computer Resources to collect, examine, analyze, transmit or store research information that is required by law or regulation to be held confidential or for which a promise of confidentiality has been given are responsible for taking steps to protect such confidential research information from unauthorized access or modification. In general, this means storing the information on a computer or auxiliary hard drive that provides strong access controls (passwords) and encrypting files, documents, and messages for protection against inadvertent or unauthorized disclosure while in storage or in transit over data networks. Robust encryption and passwords must be used to protect Non-Public University Information, and is strongly recommended for information stored electronically on all computers, especially portable devices such as notebook computers, Personal Digital Assistants (PDAs), and portable data storage (e.g., auxiliary hard drives, memory sticks) that are vulnerable to theft or loss, as well as for information transmitted over public networks. Software and protocols used should be reviewed and approved by Queens College’s Office of Information Technology. In addition, the steps taken to protect such confidential research information should be included in submissions to the Queens College Institutional Review Board reviewing the research protocol.

Queens College Access to Computer Resources.

Copying

    1. Queens College may copy a User’s account and/or hard drive on a Queens College Computer Resource, without monitoring or inspecting the contents of such account and/or hard drive, at any time for preservation of data or evidence, without notice to the User.

General Monitoring Practices.

    1. Queens College does not routinely monitor, inspect, or disclose individual usage of Queens College Computer Resources without the User’s consent. In most instances, if the  College needs information located in a Queens College Computer Resource, it will simply request it from the author or custodian. However, Queens College IT professionals and staff do regularly monitor general usage patterns as part of normal system operations and maintenance and might, in connection with these duties, observe the contents of web sites, e-mail or other electronic communications. Except as provided in this policy or by law, these individuals are not permitted to seek out contents or transactional information, or disclose or otherwise use what they have observed. Nevertheless, because of the inherent vulnerability of computer technology to unauthorized intrusions, Users have no guarantee of privacy during any use of Queens College computer resources or in any data in them, whether or not a password or other entry identification or encryption is used. Users may expect that the privacy of their electronic communications and of any materials stored in any Queens College Computer Resource dedicated to their use will not be intruded upon by Queens College except as outlined in this policy.

Monitoring without Notice.

    1. Categories. Queens College may specifically monitor or inspect the activity and accounts of individual users of Queens College computer resources, including individual login sessions, e-mail and other communications, without notice, in the following circumstances:
      1. when the User has voluntarily made them accessible to the public, as by posting to Usenet or a web page.
      2. when it is reasonably necessary to do so to protect the integrity, security, or functionality of Queens College or other computer resources, as determined by the Chief Information Security Officer or his or her designee, after consultation with Queens College’s Chief Information Officer or his or her designee;
      3. when it is reasonably necessary to diagnose and resolve technical problems involving system hardware, software, or communications, as determined by the Chief Information Security Officer or his or her designee, after consultation with Queens College’s Chief Information Officer or his or her designee.
      4. when it is reasonably necessary to determine whether Queens College may be vulnerable to liability, or when failure to act might result in significant bodily harm, significant property loss or damage, or loss of evidence, as determined by the President or a Vice President designated by the President or, in the case of the Central Office by the Chancellor or his or her designee, after consultation with the Office of General Counsel and the Chair of the University Faculty Senate (if a current Queens College faculty member’s account or activity is involved) or Vice Chair if the Chair is unavailable;
      5. when there is a reasonable basis to believe that Queens College policy or federal, state or local law has been or is being violated, as determined by the College President or a Vice President designated by the President or, in the case of the Central Office by the Chancellor or his or her designee, after consultation with the Office of General Counsel and the Chair of the University Faculty Senate (if a current Queens College faculty member’s account or activity is involved) or Vice Chair if the Chair is unavailable;
      6. when an account appears to be engaged in unusual or unusually excessive activity, as indicated by the monitoring of general activity and usage patterns, as determined by the College President or a Vice President designated by the President and the Chief Information Officer or his or her designee or, in the case of the Central Office by the Chancellor or his or her designee, after consultation with Queens College’s Chief Information Officer or his or her designee, the Office of General Counsel, and the Chair of the University Faculty Senate (if a current Queens College faculty member’s account or activity is involved) or Vice Chair if the Chair is unavailable; or
      7. as otherwise required by law.
    2. Procedures. In those situations in which the Chair of the University Faculty Senate is to be consulted prior to monitoring or inspecting an account or activity, the following procedures shall apply:
      1. if the monitoring or inspection of an account or activity requires physical entry into a faculty member’s office, the faculty member shall be advised prior thereto and shall be permitted to be present to observe, except where specifically forbidden by law; and
      2. the College President or the CIO at the President’s behest, as the case may be, shall report the completion of the monitoring or inspection to the Chair and the Queens College employee affected, who shall also be told the reason for the monitoring or inspection, except where specifically forbidden by law.
    3. Other Disclosure.
      1. Queens College, in its discretion, may disclose the results of any general or individual monitoring or inspection to appropriate Queens College personnel or agents, or law enforcement or other agencies. The results may be used in college disciplinary proceedings, discovery proceedings in legal actions, or otherwise as is necessary to protect the interests of the University.
      2. In addition, users should be aware that Queens College may be required to disclose to the public under FOIL communications made by means of Queens College Computer Resources whether in conjunction with University business or as incidental personal use.
      3. Any disclosures of activity of accounts of individual Users to persons or entities outside of Queens College, whether discretionary or required by law, shall be approved by the General Counsel and shall be conducted in accordance with any applicable law. Except where specifically forbidden by law, Queens College employees subject to such disclosures shall be informed promptly after the disclosure of the actions taken and the reasons for them.
    4. Annual Statement. The Office of General Counsel shall issue an annual statement of the instances of account monitoring or inspection that fall within categories D through G above. The statement shall indicate the number of such instances and the cause and result of each. No personally identifiable data shall be included in this statement.
    5. Privacy Policy. See Queens College’s Web Site Privacy Policy for additional information regarding data collected by Queens College from visitors to the Queens College website.

Waiver of Policy

    1. A Queens College employee or student may apply to the Chief Information Security Officer’s Office for an exception or waiver from one or more of the provisions of this policy. Such application may be for a single use or for periodic or continuous uses, such as in connection with a course or program. Any application for a waiver should be made prior to using the Queens College Computer Resource for the purposes described in the application.
    2. The written waiver application must state:
      1. the policy provision or provisions for which the User is seeking a waiver;
      2. how the User plans to use Queens College Computer Resource to be covered by the waiver and the reasons why the User believes a waiver should be approved;
      3. if the waiver involves confidential research information, what steps will be taken to protect such information;
      4. the length of time for which the waiver is being requested; and
      5. if a student, how and by whom the student will be supervised.
    3. The General Counsel shall consult with the Queens College’s Chief Information Security Officer and the Chief Information Officer prior to making a determination regarding the application.
    4. Users should be aware that Queens College cannot waive federal, state or local law; for example, the contents of Queens College Computer Resources (including confidential research information) may be subject to a valid subpoena regardless of the terms of any waiver.

Enforcement

    1. Violation of this policy may result in suspension or termination of an individual’s right of access to Queens College Computer Resources, disciplinary action by appropriate Queens College authorities, referral to law enforcement authorities for criminal prosecution, or other legal action, including action to recover civil damages and penalties.
    2. Violations will normally be handled through the College disciplinary procedures applicable to the relevant User. For example, alleged violations by students will normally be investigated, and any penalties or other discipline will normally be imposed, by the Office of Student Affairs.
    3. Queens College has the right to temporarily suspend computer use privileges and to remove from Queens College computer resources material it believes violates this policy, pending the outcome of an investigation of misuse or finding of violation. This power may be exercised only by the President or the CIO.

Additional Rules

    1. Additional rules, policies, guidelines and/or restrictions may be in effect for specific computers, systems, or networks, or at specific computer facilities at the discretion of the directors of those facilities. Any such rules which potentially limit the privacy or confidentiality of electronic communications or information contained in or delivered by or over Queens College Computer Resources will be subject to the substantive and procedural safeguards provided by this policy.

Disclaimer

    1. Queens College shall not be responsible for any damages, costs or other liabilities of any nature whatsoever with regard to the use of Queens College Computer Resources. This includes, but is not limited to, damages caused by unauthorized access to Queens College Computer Resources, data loss, or other damages resulting from delays, non-deliveries, or service interruptions, whether or not resulting from circumstances under the Queens College’s control.
    2. Users receive and use information obtained through Queens College Computer Resources at their own risk. Queens College makes no warranties (expressed or implied) with respect to the use of Queens College Computer Resources. Queens College accepts no responsibility for the content of web pages or graphics that are linked from Queens College web pages, for any advice or information received by a user through use of Queens College Computer Resources, or for any costs or charges incurred by a user as a result of seeking or accepting such advice or information.
    3. Queens College reserves the right to change this policy and other related policies at any time. Queens College reserves any rights and remedies that it may have under any applicable law, rule or regulation. Nothing contained in this policy will in any way act as a waiver of such rights and remedies.

5.0 Compliance

This policy shall take effect upon publication.  Compliance is expected with all enterprise policies and standards. Policies and standards may be amended at any time.

If compliance with this standard is not feasible or technically possible, or if deviation from this policy is necessary to support a business function, entities shall request an exception through the Chief Information Security Officer’s exception process.

6.0 Definitions of Key Terms

Term Definition
Queens College Computer Resources “Queens College Computer Resources” refers to all computer and information technology hardware, software, data, access and other resources owned, operated, or contracted by CUNY. This includes, but is not limited to, desktop and laptop computers, handheld devices that allow or are capable of storing and transmitting information (e.g., cell phones, tablets), mainframes, minicomputers, servers, network facilities, databases, memory, memory sticks, and associated peripherals and software, and the applications they support, such as e-mail, cloud computing applications, and access to the internet.
Email “E-mail” includes point-to-point messages, postings to newsgroups and listservs, and other electronic messages involving computers and computer networks.
Faculty “Faculty” includes full-time, part-time, and adjunct faculty.
FOIL “FOIL” is the New York State Freedom of Information Law.
Non-Public University Information “Non-Public University Information” has the meaning set forth in CUNY’s IT Security Policies and Procedures found at security.cuny.edu, namely: personally identifiable information (such as an individual’s Social Security Number; driver’s license number or non-driver identification card number; account number, credit or debit card number, in combination with any required security code, access code, or password that would permit access to an individual’s financial account; personal electronic mail address; Internet identification name or password; and parent’s surname prior to marriage); information in student education records that is protected under the Family Educational Rights and Privacy Act of 1974 (FERPA) and the related regulations set forth in 34 CFR Part 99; other information relating to the administrative, business, and academic activities and operations of the University (including employee evaluations, employee home addresses and telephone numbers, and other employee records that should be treated confidentially); and any other information available in University files and systems that by its nature should be treated confidentially .
User “User” means a user of Queens College Computer Resources, including all current and former users, whether affiliated with Queens College or not, and whether accessing those resources on Queens College campus or remotely.

7.0 Contact Information

Submit all inquiries and requests for future enhancements to the policy owner at:

Chief Information Security Officer

Damon Vogel

CISO@qc.cuny.edu

8.0 Revision History

This policy shall be reviewed at least once every year to ensure relevancy.

Date Description of Change Reviewer
     

9.0 Related Documents

Identification Policies & Standards

Security Awareness and Training Standard - Full Text (Draft Living Document)

1.0   Purpose and Benefits

To ensure that the appropriate level of information security awareness training is provided to all Information Technology (IT) users.

 

2.0 Authority

  • Responsible Office(s): Queens College Information Technology Services
  • Responsible Executive(s): Chief Information Officer (CIO)
  • Responsible Officer(s): Chief Information Security Officer (CISO)

3.0 Scope – College-Wide

This is a college-wide standard and includes requirements that must be followed if Queens College is to protect the information that is collected in the standard process of business. This standard is to be an additional layer of security on top of existing CUNY security policies and is not intended or able to supersede CUNY policies.

This standard encompasses all users for which Queens College has administrative responsibility, including Faculty, Staff, Administrators, Students as well as outside Contractors as applicable.

4.0       Information Statement

  1. Security Awareness Training
    1. Schedule security awareness training as part of initial training for new users.
    2. Schedule security awareness training when required by information system changes and then yearly at minimum thereafter.
    3. ITS shall determine the appropriate content of security awareness training and security awareness techniques based on the specific organizational requirements and the information systems to which personnel have authorized access. The content shall:
      1. Include a basic understanding of the need for information security and user actions to maintain security and to respond to suspected security incidents.
      2. Address awareness of the need for operations security. Security awareness techniques can include, for example, displaying posters, offering supplies inscribed with security reminders, generating email advisories/notices from senior organizational officials, displaying logon screen messages, and conducting information security awareness events.
    4. Security Awareness | Insider Threat
      1. Include security awareness training on recognizing and reporting potential indicators of insider threat.
    5. Role-Based Security Training
      1. Provide role-based security training to personnel with assigned security roles and responsibilities
        1. Before authorizing access to the information system or performing assigned duties
        2. When required by information system changes and at minimum yearly thereafter.
      2. Practical Exercises
        1. Provide practical exercises in security training that reinforce training objectives; practical exercises may include, for example, security training for software developers that includes simulated cyber-attacks exploiting common software vulnerabilities (e.g., buffer overflows), or spear/whale phishing attacks targeted at senior leaders/executives. These types of practical exercises help developers better understand the effects of such vulnerabilities and appreciate the need for security coding standards and processes.
      3. Suspicious Communications and Anomalous System Behavior
        1. Provide training to its specified staff on how to recognize suspicious communications and anomalous behavior in organizational information systems.
      4. Security Training Records

Queens College shall:

 

  1. Designate personnel to document and monitor individual information system security training activities including basic security awareness training and specific information system security training.
  2. Retain individual training records for a minimum of 1 year.

 

5.0 Compliance

This standard shall take effect upon publication. Compliance is expected with all enterprise policies and standards. Policies and standards may be amended at any time; compliance with amended policies and standards is expected.

If compliance with this standard is not feasible or technically possible, or if deviation from this standard is necessary to support a business function, entities shall request an exception through the Chief Information Security Officer’s exception process.

6.0 Definitions of Key Terms

Term Definition
   

7.0 Contact Information

Submit all inquiries and requests for future enhancements to the standard owner at:

 

Chief Information Security Officer

Damon Vogel

CISO@qc.cuny.edu

 

8.0 Revision History

This standard shall be subject to periodic review to ensure relevancy.

Date Description of Change Reviewer
10/13/22 Initial changes to apply to Queens College DVogel
07/12/2023 Continues Changes to Apply to Queens College DVogel
09/08/2023 Add #10, Converted to Standard, Aligned to Gartner Recommendations DVogel

9.0 Related Documents

10.0 External Documents

National Institute of Standards and Technology (NIST) Special Publications: NIST SP 800-53 – Awareness and Training (AT), NIST SP 800-12, NIST SP 800-16, NIST SP 800-50, NIST SP 800-100; Electronic Code of Federal Regulations (CFR): 5 CFR 930.301

 

Protection Policies & Standards

Patch Management Standard - Full Text (Draft Living Document)

1.0 Purpose and Benefits

Security patch management (patch management) is a practice designed to proactively prevent the exploitation of IT vulnerabilities that exist within an organization. By applying security related software or firmware updates (patches) to applicable IT systems, the expected result is reduced time and money spent dealing with exploits by reducing or eliminating the related vulnerability.

 

2.0 Authority

  • Responsible Office(s): Queens College Information Technology Services
  • Responsible Executive(s): Chief Information Officer (CIO)
  • Responsible Officer(s): Chief Information Security Officer (CISO)

 

3.0 Scope

This standard relates specifically to vulnerabilities that can be addressed by a software or firmware update (patch) and applies to all software used on the entity’s systems.  The Vulnerability Scanning Standard should be followed for requirements on addressing non-patched vulnerabilities.

4.0 Information Statement

  1. Entities must assign an individual or group within IT operations to be responsible for patch management.
  2. If patch management is outsourced, service level agreements must be in place that address the requirements of this standard and outline responsibilities for patching. If patching is the responsibility of the third party, entities must verify that the patches have been applied.
  3. A process must be in place to manage patches. This process must include the following:
  • monitoring security sources (Appendix A) for vulnerabilities, patch and non-patch remediation, and emerging threats;
  • overseeing patch distribution, including verifying that a change control procedure is being followed;
  • testing for stability and deploying patches; and
  • using an automated centralized patch management distribution tool, whenever technically feasible, which:
    • maintains a database of patches;
    • deploys patches to endpoints; and
    • verifies installation of patches.
  1. Appropriate separation of duties must exist so that the individual(s) verifying patch distribution is not the same individual(s) who is distributing the patches.
  2. As per the Information Security Policy, all entities must maintain an inventory of hardware and software assets. Patch management must incorporate all installed IT assets. 
  3. Patch management must be prioritized based on the severity of the vulnerability the patch addresses. In most cases, severity ratings are based on the Common Vulnerability Scoring System (CVSS). A CVSS score of 7-10 is considered a high impact vulnerability, a CVSS score of 4-6.9 is considered a moderate impact vulnerability and a CVSS of 0-3.9 is considered a low impact vulnerability.
  4. To the extent possible, the patching process must follow the timeline contained in the table below:

Impact/Severity

Patch Initiated

Patch Completed

High

Within 24 hours of patch release

Within 1 month of patch release

Medium

Within 1 week of patch release

Within 2 month of patch release

Low

Within 1 month of patch release

Within 3 months of patch release, unless ISO determines this to be an insignificant risk to the environment

  1. If patching cannot be completed in the timeframe listed in the table above, compensating controls must be put in place within the timeframes above and the exception process must be followed.
  2. If a patch requires a reboot for installation, the reboot must occur within the timeframes outlined above.

5.0 Compliance

This standard shall take effect upon publication. Compliance is expected with all enterprise policies and standards.  Policies and standards may be amended at any time.

If compliance with this standard is not feasible or technically possible, or if deviation from this policy is necessary to support a business function, entities shall request an exception through the Chief Information Security Officer’s exception process.

 

6.0 Definitions of Key Terms

This standard shall be subject to periodic review to ensure relevancy.

Date

Description of Change

Reviewer

 

 

 

 

7.0 Contact Information

Submit all inquiries and requests for future enhancements to the policy owner at:

Chief Information Security Officer

Damon Vogel

CISO@qc.cuny.edu

8.0 Revision History

This standard shall be subject to periodic review to ensure relevancy.

Date

Description of Change

Reviewer

10/17/2022

Initial Changes to apply to Queens College

DVogel

07/12/2023

Final Changes to apply to Queens College

DVogel

09/08/2023

Added #10, Converted to Standard, Aligned to Gartner Recommendations.

DVogel

9.0 Related Documents

10.0 External Documents

National Institute of Standards and Technology, Special Publication 800-40, Guide to Enterprise Patch Management Technologies

Common Vulnerability Scoring System

 

Planning Standard - Full Text (Draft Living Document)

1.0   Purpose and Benefits

To ensure that Information Technology (IT) resources and information systems are established with effective security controls and control enhancements that reflect applicable federal and state laws, Executive Orders, directives, regulations, policies, standards, and guidance.

 

2.0 Authority

  • Responsible Office(s): Queens College Information Technology Services
  • Responsible Executive(s): Chief Information Officer (CIO)
  • Responsible Officer(s): Chief Information Security Officer (CISO)

3.0 Scope – College-Wide

This is a college-wide standard and includes requirements that must be followed if Queens College is to protect the information that is collected in the standard process of business. This standard is to be an additional layer of security on top of existing CUNY security policies and is not intended or able to supersede CUNY policies.

This standard encompasses all systems, automated and manual, for which Queens College has administrative responsibility, including systems managed or hosted by third parties on behalf of Queens College. It addresses all information, regardless of the form or format, which is created or used in support of business activities.

4.0 Information Statement

  1. System Security Plan
    1. Develop a security plan for each information system that:
      1. Is consistent with the Queens College enterprise architecture.
      2. Defines explicitly the authorization boundary for the system.
      3. Describes the operational context of the information system in terms of missions and business processes.
      4. Provides the security categorization of the information system including supporting rationale.
      5. Describes the operational environment for the information system and relationships with or connections to other information systems.
      6. Provides an overview of the security requirements for the system.
      7. Identifies any relevant overlays, if applicable.
      8. Describes the security controls in place or planned for meeting those requirements including a rationale for the tailoring decisions.
      9. Is reviewed and approved by the authorizing official or designated representative prior to plan implementation.
    2. Distribute copies of the security plan and communicate subsequent changes to the plan to authorized personnel and/or business units.
  • Review the security plan for the information system at least annually.
  1. Update the plan to address changes to the information system/environment of operation or problems identified during plan implementation or security control assessments.
  2. Protect the security plan from unauthorized disclosure and modification.
  1. Rules of Behavior
    1. Establish, and make readily available to individuals requiring access to the information system, the rules that describe their responsibilities and expected behavior with regard to information and information system usage.
    2. Receive a signed acknowledgment from such individuals, indicating that they have read, understand, and agree to abide by the rules of behavior, before authorizing access to information and the information system.
  • Review and update the rules of behavior.
  1. Require individuals who have signed a previous version of the rules of behavior to read and resign when the rules of behavior are revised and updated.
  1. Information Security Architecture
    1. Develop information security architecture for the information system that will:
      1. Describe the overall philosophy, requirements, and approach to be taken with regard to protecting the confidentiality, integrity, and availability of organizational information.
      2. Describe how the information security architecture is integrated into and supports the enterprise architecture.
      3. Describe any information security assumptions and dependencies on external services.
    2. Review and update the information security architecture no less than annually, to reflect updates in the enterprise architecture.
  • Ensure that planned information security architecture changes are reflected in the security plan, the security operations and procurements/acquisitions.
  1. Defense-in-Depth Approach
    1. Design security architecture using a defense-in-depth approach that:
      1. Allocates security safeguards to Queens College defined locations and architectural layers.
      2. Will ensure that the allocated security safeguards operate in a coordinated and mutually reinforcing manner.

 

5.0 Compliance

This standard shall take effect upon publication. Compliance is expected with all enterprise policies and standards. Policies and standards may be amended at any time; compliance with amended policies and standards is expected.

If compliance with this standard is not feasible or technically possible, or if deviation from this standard is necessary to support a business function, entities shall request an exception through the Chief Information Security Officer’s exception process.

6.0 Definitions of Key Terms

Term

Definition

 

 

7.0 Contact Information

Submit all inquiries and requests for future enhancements to the standard owner at:

 

Chief Information Security Officer

Damon Vogel

CISO@qc.cuny.edu

 

8.0 Revision History

This standard shall be subject to periodic review to ensure relevancy.

Date

Description of Change

Reviewer

9/20/22

Initial changes to apply to Queens College

DVogel

07/12/2023

Added New Policy Number Scheme & Tagging

DVogel

09/08/2023

Added #10, Converted to Standard, Aligned to Gartner Recommendations.

DVogel

9.0 Related Documents

10.0 External Documents

Sanitization/Secure Disposal Standard - Full Text (Draft Living Document)

1.0 Purpose and Benefits

Information systems capture, process, and store information using a wide variety of media, including paper. This information is not only located on the intended storage media but also on devices used to create, process, or transmit this information. These media may require special disposition in order to mitigate the risk of unauthorized disclosure of information and to ensure its confidentiality. All computer systems, electronic devices and electronic media must be properly cleaned of data and software before being transferred outside of Queens College (QC) or if being repurposed or reused within (QC). When electronic storage devices cannot be sanitized, the media will be destroyed using Office of CIO approved vendors and processes.

The large volume of electronic data stored on computer systems and electronic media throughout the College includes confidential, FERPA-Restricted, HIPA-Restricted, and COPA-Restricted information as defined in the Data Classification Policy, such as student records, financial data, personnel records and research information.  The College is subject to federal laws that set forth responsibilities for protecting this information, copyright laws and software license agreements that protect vendor rights regarding the use of software.

Unauthorized disclosure of confidential, FERPA-Restricted, HIPA-Restricted, and COPA-Restricted information may subject the College to legal liability, negative publicity, monetary penalties and loss of funding.

This policy outlines the responsibilities for carrying these protective measures.

2.0 Authority

  • Responsible Office(s): Queens College Information Technology Services
  • Responsible Executive(s): Chief Information Officer (CIO)
  • Responsible Officer(s): Chief Information Security Officer (CISO)

3.0 Scope – College-Wide

This is a college-wide standard and includes requirements that must be followed if Queens College is to protect the information that is collected in the standard process of business. This policy is to be an additional layer of security on top of existing CUNY security policies and is not intended or able to supersede CUNY policies.

This standard applies to all departments, faculty, employees, students and contracted personnel that use or maintain (QC) information systems or media which contains confidential, FERPA-Restricted, HIPA-Restricted, and COPA-Restricted information.

The primary responsibility for sanitizing and/or disposal of data that resides on computer systems or electronic media devices rests with the units that procured, purchased, or leased the electronic media.

4.0 Information Statement

  1. All computer systems, electronic devices and electronic media must be properly cleaned of data and software before being transferred outside of Queens College (QC) or if being repurposed or reused within (QC). When electronic storage devices cannot be sanitized, the media will be destroyed using Office of CIO approved vendors and processes.
  2. The entity must ensure through training and/or instruction that users and custodians of information are aware of its sensitivity and the basic requirements for media sanitization and secure disposal.
  3. The entity must ensure that all workforce members, including property management and custodial staff, are made aware of the media sanitization and secure disposal process in order to establish proper accountability for all data.
  4. The entity must ensure that confidential material is destroyed only by authorized and trained personnel, whether in-house or contracted, using methods outlined in this standard.
  5. The entity may use service providers for destruction purposes provided that the information remains secure until the destruction is completed. The service providers must follow this standard. The entity must ensure that maintenance or contractual agreements are in place and are sufficient in protecting the confidentiality of the system media and information commensurate with the information classification standards.
  6. Deans, directors and department heads are responsible for ensuring the sanitation of all College electronic devices and computer systems in their units prior to removal from the campus.
  7. Software used to sanitize computer hard drives must be compliant with Department of Defense standards. Any medium that cannot be sanitized with such software must be physically destroyed.
  8. The Office of Information Technology will:
    1. publish guidelines and approved software on the Information Technology Policy website. Sanitization and disposal forms and additional sanitization and data disposal information can also be found on the website.
    2. accept for destruction, any electronic data storage medium from any department.
  9. Property Services is responsible for the disposition of surplus computer systems and electronic devices. Any computer system or device sent to Property Services for disposition must have an Electronic Data Disposal Verification form (available from the IT website) affixed to it indicating that the system has been sanitized, the date, the name and phone number of the person responsible for sanitizing the system.
  10. Property Services will not accept any computer system without this information. If the original operating system media and certificate of license are available, they should also be sent to Property Services with the computer system.
  11. Any disposal of computer systems and media must comply with all environmental regulations.
  12. All confidential, FERPA-Restricted, HIPA-Restricted, and COPA-Restricted University information maintained on electronic media must be carefully removed before the media are made available for re-use within the College.

Methods of Media Sanitization

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.

 

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.

Figure 4.1- Sanitization and Disposition Decision Flow

(from NIST 800-88, Rev. 1, Guidelines for Media Sanitization)

 

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.

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.

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.

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

Table 5-1 – Sanitization Methods

(from NIST 800-88, Rev. 1, Guidelines for Media Sanitization)

Validation

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

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.

Verification of Personnel Competencies

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

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.

5.0 Interpretation

The office of the CISO in conjunction with Queens College General Counsel if necessary has the authority to interpret this policy.

6.0 Compliance

This standard shall take effect upon publication. Compliance is expected with all enterprise policies and standards.  Policies and standards may be amended at any time.

If compliance with this standard is not feasible or technically possible, or if deviation from this policy is necessary to support a business function, entities shall request an exception through the Chief Information Security Officer’s exception process.

 

7.0 Definitions of Key Terms

Term

Definition

Sanitation

Sanitation of a hard drive or other electronic medium means placing the medium in a condition so that the prior data stored on it cannot be read or recovered.

Electronic Media

Electronic Media refers to any device that can store data and includes, but is not limited to, computers (servers, desktop, laptop and tablets), disk drives, portable disks, backup tapes, CD-ROMS, flash/thumb drives, portable drives, cell phones and PDAs.

8.0 Contact Information

Submit all inquiries and requests for future enhancements to the policy owner at:

 

Chief Information Security Officer

Damon Vogel

CISO@qc.cuny.edu

9.0 Revision History

This standard shall be subject to periodic review to ensure relevancy.

Date

Description of Change

Reviewer

9/20/22

Initial Changes to apply to Queens College

DVogel

07/12/2023

More Changes to Apply to Queens College

DVogel

09/08/2023

Added #11, Aligned to Gartner Recommendations

DVogel

10.0 Related Documents

11.0 External Documents

NIST 800-88, Rev. 1, Guidelines for Media Sanitization

Detection Policies & Standards

Patch Management Standard - Full Text (Draft Living Document)

1.0 Purpose and Benefits

Security patch management (patch management) is a practice designed to proactively prevent the exploitation of IT vulnerabilities that exist within an organization. By applying security related software or firmware updates (patches) to applicable IT systems, the expected result is reduced time and money spent dealing with exploits by reducing or eliminating the related vulnerability.

 

2.0 Authority

  • Responsible Office(s): Queens College Information Technology Services
  • Responsible Executive(s): Chief Information Officer (CIO)
  • Responsible Officer(s): Chief Information Security Officer (CISO)

 

3.0 Scope

This standard relates specifically to vulnerabilities that can be addressed by a software or firmware update (patch) and applies to all software used on the entity’s systems.  The Vulnerability Scanning Standard should be followed for requirements on addressing non-patched vulnerabilities.

4.0 Information Statement

  1. Entities must assign an individual or group within IT operations to be responsible for patch management.
  2. If patch management is outsourced, service level agreements must be in place that address the requirements of this standard and outline responsibilities for patching. If patching is the responsibility of the third party, entities must verify that the patches have been applied.
  3. A process must be in place to manage patches. This process must include the following:
  • monitoring security sources (Appendix A) for vulnerabilities, patch and non-patch remediation, and emerging threats;
  • overseeing patch distribution, including verifying that a change control procedure is being followed;
  • testing for stability and deploying patches; and
  • using an automated centralized patch management distribution tool, whenever technically feasible, which:
    • maintains a database of patches;
    • deploys patches to endpoints; and
    • verifies installation of patches.
  1. Appropriate separation of duties must exist so that the individual(s) verifying patch distribution is not the same individual(s) who is distributing the patches.
  2. As per the Information Security Policy, all entities must maintain an inventory of hardware and software assets. Patch management must incorporate all installed IT assets. 
  3. Patch management must be prioritized based on the severity of the vulnerability the patch addresses. In most cases, severity ratings are based on the Common Vulnerability Scoring System (CVSS). A CVSS score of 7-10 is considered a high impact vulnerability, a CVSS score of 4-6.9 is considered a moderate impact vulnerability and a CVSS of 0-3.9 is considered a low impact vulnerability.
  4. To the extent possible, the patching process must follow the timeline contained in the table below:

Impact/Severity

Patch Initiated

Patch Completed

High

Within 24 hours of patch release

Within 1 month of patch release

Medium

Within 1 week of patch release

Within 2 month of patch release

Low

Within 1 month of patch release

Within 3 months of patch release, unless ISO determines this to be an insignificant risk to the environment

  1. If patching cannot be completed in the timeframe listed in the table above, compensating controls must be put in place within the timeframes above and the exception process must be followed.
  2. If a patch requires a reboot for installation, the reboot must occur within the timeframes outlined above.

5.0 Compliance

This standard shall take effect upon publication. Compliance is expected with all enterprise policies and standards.  Policies and standards may be amended at any time.

If compliance with this standard is not feasible or technically possible, or if deviation from this policy is necessary to support a business function, entities shall request an exception through the Chief Information Security Officer’s exception process.

 

6.0 Definitions of Key Terms

This standard shall be subject to periodic review to ensure relevancy.

Date

Description of Change

Reviewer

 

 

 

 

7.0 Contact Information

Submit all inquiries and requests for future enhancements to the policy owner at:

Chief Information Security Officer

Damon Vogel

CISO@qc.cuny.edu

8.0 Revision History

This standard shall be subject to periodic review to ensure relevancy.

Date

Description of Change

Reviewer

10/17/2022

Initial Changes to apply to Queens College

DVogel

07/12/2023

Final Changes to apply to Queens College

DVogel

09/08/2023

Added #10, Converted to Standard, Aligned to Gartner Recommendations.

DVogel

9.0 Related Documents

10.0 External Documents

National Institute of Standards and Technology, Special Publication 800-40, Guide to Enterprise Patch Management Technologies

Vulnerability Scanning Standard - Full Text (Draft Living Document)

1.0 Purpose and Benefits

Entities utilize automated tools to scan systems, computing and network devices, web applications and application code. The results of these scans help inform management and system administrators of known and potential vulnerabilities.

Vulnerability management is a process by which the vulnerabilities identified through scanning are tracked, evaluated, prioritized and managed until the vulnerabilities are remediated or otherwise appropriately resolved. Managing the vulnerabilities identified during scans ensures that appropriate actions are taken to reduce the potential that these vulnerabilities are exploited and thereby reduce risk of compromise to the confidentiality, integrity and availability of information assets.

2.0 Authority

  • Responsible Office(s): Information Technology Services
  • Responsible Executive(s): Chief Information Officer (CIO)
  • Responsible Officer(s): Chief Information Security Officer (CISO)

3.0 Scope: College-Wide

This is a college-wide standard and includes requirements that must be followed if Queens College is to protect the information that is collected in the standard process of business. This policy is to be an additional layer of security on top of existing CUNY security policies and is not intended or able to supersede CUNY policies.

4.0 Information Statement

As per the Information Security Policy, all systems must be scanned for vulnerabilities.  In addition, each system must be inventoried and have an individual or group assigned responsibility for maintenance and administration.

4.1          Types of Scans

The type of vulnerability scans appropriate for a given target depends on the target type (i.e., hardware, software, source code) and the target’s location (i.e., internal or external to the network). The table below lists the types of vulnerability scans required by this standard.

Type

Description

External Infrastructure Scan

Scans of the perimeter of networks or any externally available hosted infrastructure to identify potential vulnerabilities in Internet accessible IT infrastructure.

Internal Infrastructure

Scan

Scans of IT infrastructure on protected networks or any hosted infrastructure to identify potential vulnerabilities.

“Lite” Web Application Scan

Cursory unauthenticated scans of externally facing production web applications to identify security vulnerabilities.

In-depth Web Application Scan

When implemented, authenticated in-depth scans of web applications to identify security vulnerabilities.

Application Source Code Analysis

Scans of application source code run during development to identify problems in the code that could cause potential vulnerabilities.

 

4.2          Scanning

Queens College Information Technology Services is responsible for confirming that vulnerability scans are conducted.  Entities must use a scanning tool approved by the CISO’s Office.  Any approved scanning tool must be able to provide remediation suggestions and be able to associate a severity value to each vulnerability discovered based on the relative impact of the vulnerability to the affected system. 

As per the Information Classification Standard, scan reports are classified with moderate confidentiality and moderate integrity and should be protected as such.

Entities are required to provide all external IP addresses and Uniform Resource Locators (URLs) for all externally facing web applications to the CISO’s Office.

Network and system administrators must provide sufficient access to allow the vulnerability scan engine to scan all services provided by the system.  No devices connected to the network shall be specifically configured to block vulnerability scans from authorized scanning engines.

Scans must be performed within the system development life cycle (see SSDLC Standard) while in pre-deployment environments, when deployed into the target implementation environment, and periodically thereafter as specified below:

  1. Pre-deployment scans occur prior to the move of the system or web application to the target implementation environment:
  1. All systems must undergo an authenticated internal infrastructure scan, where technically feasible or required, before being deployed to the target implementation environment. Any infrastructure vulnerability discovered must be remediated or determined to be a false positive or insignificant risk, by the CISO’s Office, prior to the system being deployed for intended use.
  2. When source code is available, applications must undergo source code scanning before the updated code moves into the target implementation environment if there has been a change to application code.
  3. Scans must be authenticated when the application requires authentication before being deployed into the target implementation environment or into an environment that is externally accessible. When authentication is required to access the application, scans must be run with authenticated access at each access level (e.g., user, admin) supported by the application, except where limitations in the tool prevent authenticated scanning. Any web application vulnerability discovered must be remediated or determined to be a false positive or insignificant risk by the ISO/designated security representative, prior to the system being placed into the target implementation environment. 
  4. Any system or application deployed to its target implementation environment with un-remediated vulnerabilities must have a formal remediation plan and the documented approval of the executive responsible for risk management or their designee.
    1. Implementation scans occur the first time a system or web application is moved to its target implementation environment:
  5. Systems must be scanned immediately upon being placed into the target implementation environment with an authenticated internal infrastructure scan, where technically feasible or required. If the system is accessible from the internet or an external network, then the system must be scanned with an external infrastructure scan.
  6. Web applications must be scanned within the first month of being placed into the target implementation environment. An authenticated in-depth web application scan is required if feasible, but at minimum a “lite” web application scan is required. Sensitivity and criticality of the application must be considered when determining the schedule for the initial implementation scan.
    1. Recurring Scans: After the initial scan in the target implementation environment, the frequency of scans are to occur according to the system or application’s risk rating (see Table 2).
  7. When performing internal infrastructure scans on systems built using a shared image, such as workstations, scans may be run on a sampling of systems but the sample set must vary from scan to scan.
  8. Web applications in production are required to undergo recurring scans. At minimum, web applications in production are required to undergo recurring “lite” application scans.
  9. All vulnerabilities found during scans must be addressed as per the remediation section

4.3          Determine Risk Rating and Frequency of Scans

The risk that vulnerabilities pose to systems and applications is based on the likelihood of a vulnerability being exploited and the impact if the confidentiality, integrity or availability of the information assets were compromised. The likelihood of a vulnerability being exploited is increased in direct relation to the system’s or application’s accessibility from other systems.

The impact to the information assets is based on the asset’s information classification (see Information Classification Standard).  Impact (i.e., high, moderate or low) if the confidentiality, integrity or availability is compromised must be considered and the highest individual impact rating for confidentiality, integrity or availability utilized within the table below.

Table 2: RISK RATING

Impact

(Confidentiality, Integrity, Availability)

Exposure

Systems with no network connectivity to production data

           

Systems with network connectivity to production data (not internet facing)

System that is publicly available from the internet

High

Medium

High

High

Medium

Low

Medium

High

Low

Low

Low

Medium

Minimum frequency of scans is dependent on the risk rating. Systems without a risk rating must be scanned as if they had a risk rating of “High” until they are rated.

 

 

 

TABLE 3: FREQUENCY OF SCANS

Risk Rating

Frequency

Infrastructure scans

High

Monthly

Medium

Quarterly

Low

Semi-annually

Web Application Scans

High

Quarterly or after significant change

Medium

Semi-annually

Low

Annually

 

4.4          Remediation

Vulnerabilities discovered during scans must be remediated based on risk rating (see Table 2) and vulnerability severity identified by the scanning tool as per the table below.

TABLE 4: REMEDIATION TIMEFRAMES

Risk Rating (from Table 2)

Vulnerability Severity

Low or Below

Above Low to Below High

High or Above

High

At the discretion of the ISO/designated security representative

Action Plan in 2 Weeks, Resolved in 6 Months

Action Plan in 1 Week, Resolved in 1 Month

Medium

At the discretion of the ISO/designated security representative

Action Plan in 3 Weeks, Resolved in 1 year

 Action Plan in 2 Weeks, Resolved in 6 Months

Low

At the discretion of the ISO/designated security representative

At the discretion of the ISO/designated security representative

Action Plan in 3 Weeks, Resolved 1 year

The ISO/designated security representative may review vulnerabilities to adjust the severity rating if necessary.  Testing must be done to verify that remediation has been completed.

Individuals managing vulnerability scans are required to notify the ISO/designated security representative within 1 business day of scan completion for new vulnerabilities and at least monthly of un-remediated vulnerabilities on systems or applications that are running in production.

ISOs/designated security representatives must notify management of any un-remediated vulnerabilities not addressed in the timeframes prescribed in this standard, so that risk is accepted by the appropriate party.

5.0 Compliance

This standard shall take effect upon publication. Compliance is expected with all enterprise policies and standards.  Policies and standards may be amended at any time; compliance with amended policies and standards is expected.

If compliance with this standard is not feasible or technically possible, or if deviation from this policy is necessary to support a business function, Entities shall request an exception through the Chief Information Security Officer’s exception process.

6.0 Definitions of Key Terms

Term

Definition

 

 

7.0 Contact Information

Submit all inquiries and requests for future enhancements to the policy owner at:

 

Chief Information Security Officer

Damon Vogel

CISO@qc.cuny.edu

 

 

8.0 Revision History

This standard shall be subject to periodic review to ensure relevancy.

Date

Description of Change

Reviewer

07/12/2023

Initial Alignment to Queens College

DVogel

09/08/2023

Conversion to Standard, Add # 10, Align to Gartner Recommendations

DVogel

9.0 Related Documents

Patch Management Standard

10.0 External Documents