• CIS Homepage
  • CIS HelpDesk
  • CIS SharePoint
  • CIS Internal Wiki


Skip to end of metadata
Go to start of metadata


Statement and Purpose


This policy describes the criteria for authorization, and procedures relating to, the use of CIS elevated privileges to retract and delete spam and phishing messages deemed to have a high probability of success. CIS employs automatic, advanced email filtering technologies to detect and block known-bad malware and phishing messages before they are delivered to mail stores. Despite these technologies, targeted attempts to deceive email recipients continue to get through our defenses and arrive at users' Inboxes. Such attacks are sophisticated, designed specifically to evade automated malware detection algorithms, and pose a high threat for the compromise of user credentials and/or disclosure of protected University data. Consequently, there are instances when manual intervention into the mail store is deemed prudent and necessary, particularly for those phishing attempts that are emergent and hold a high probability for malicious success. The purpose of this policy is to authorize CIS email administrative action on behalf of email users, and to outline the parameters for which this activity is approved.

Download Policy as PDF



Table of Contents

 

Version: 1.0

Effective Date: October 4, 2017
Last Updated:
 October 4, 2017

Responsible Office:
Computer & Information Systems
Responsible Executive:
AVP Technology Services/CIO


Procedures for Email Retraction Activity


Detection

Various vectors exist whereby CIS becomes aware that an emergent and targeted phishing campaign is hitting University email servers. These include but are not limited to: help desk inquiries; system logs and warning messages, receipt of messages by internal staff, and warnings/alerts by third party agents such as REN-ISAC and related spam watchdog groups. Any means by which CIS becomes aware of an emerging threat are to be treated with concern and processed accordingly.

Communication

Threat identification - CIS will use all means at their disposal to discern and evaluate the criticality of suspect email messages. Aspects of threat discovery, assessment and decision will be documented in the CIS project/ticket tracking system. Conversations and facts leading up to the decision to authorize email retraction will be clearly documented in the work flow.

Remediation - unless extenuating circumstances dictate otherwise, CIS will not communicate retraction activities to the campus community at large. This activity is to be done largely behind-the-scenes of user awareness.

Decision Criteria

The decision to authorize email retraction activities rests with the senior CIS executive (director or above) available at the time of the emergent threat. If no executive is available the decision to retract rests with the senior email administrator. In all instances, details of the decision to authorize will be clearly documented as set forth above.

Recognizing that threats of this nature are often unique in their methods, timing, distribution and payload, each decision must be considered on its own merit. Specific criteria for the decision to retract may include any of the following:

  • Phishing messages for which there has been an alarmingly high frequency of success in harvesting credentials or responses from the user community;
  • Phishing campaigns that are sophisticated in nature and that, in the opinion of CIS staff reviewing the message, are well crafted and pose a high probability for deception;
  • Campaigns that are excessively high in volume, targeting large portions of the SPU email population; and
  • Messages that have detectable malware or other nefarious or destructive content.

Authorization

Authorization to delete suspect email messages includes: Deletion of messages currently in transit as well as messages that have arrived in individual email stores. Once authorization to delete said messages is given, CIS staff should act quickly to arrest the propagation of such threats. Retraction activities, and any resultant affects, are to be clearly documented in the incident report/ticket.

 





Invalid License

License is not configured.

  • No labels