Skip to content

Functionality and Technical Specifications

Is the threat detection and identification system deployed at all campuses?

Yes – all campuses use the threat detection and identification system.

Is this an on-going program?

Yes. Systemwide threat detection and identification is an important part of UC’s overall approach to cyber-risk reduction.

What types of attacks are being searched for?

The system searches for:

  • Advanced malware
  • Crimeware, ransomware and other dangerous malware
  • Known bad IPs and command-and-control (C2) traffic nodes – threat intelligence
  • General malware and compromise indicators

What data does the threat detection and identification system store?

The threat detection and identification (TDI) system stores metadata about network sessions crossing to and from the public internet. The technology uses and inspects metadata similar to other security tools used at UC locations.

Content is stored in an alert if there is a match for malware or an indicator of compromise (IoC).

The TDI system scans traffic for signatures of known malware and IoCs.

Examples of IoCs are communications with a known bad internet address, use of covert channels of communication used by attackers, or metadata flagged as dangerous.

Alert data are stored for the duration of the investigation of the alert or as required by law or policy.

The metadata stored is derived from  internet data that is public.

Is the data stored by the threat detection collector component the raw metadata that the sensor analyzes, the results of the sensor’s analysis, or both?

Both. The raw metadata is stored together with some computed values or values resulting from analysis.

Examples of the output of the analyses are the threat found, hash values and bytes transferred.

What is a hash value and is using a hash value a common cybersecurity technique?

Files and some content are processed through a one way function called a hash. The hash algorithm processes the file to compute a number that represents the file. For example, a file containing “Faculty research is a cornerstone of UC success!” would have a hash value of: 30698beffcc23beed890396afedd2ece and it will always hash to that number. The hash value is stored, not the contents of the file. You can’t get from the hash value back to the file content.

This technique is ubiquitous and is useful to look back to see if files matching malware were loaded on other UC systems.

How and when is the metadata deleted?

Deletion is a feature of the threat detection and identification system/product and occurs automatically. The retention period is a setting.

Metadata are deleted when the retention period ends. Retention is set for 30 days.

Does the threat detection and identification system analyze all internet traffic?

All internet-facing traffic is analyzed. Although location-specific network architectures vary, the TDI systems generally are located on the transition between the location network and the internet.

Does the threat detection and identification system capture all data transmitted over the network?

No. Although location-specific network architectures vary, the system generally captures public routing information related to traffic going to and from the public internet. In some cases, depending on where the TDI appliances are located, traffic moving between two sites at a single location may also be analyzed.

Files and some content are processed through a one way function called a hash. The hash algorithm processes the content to compute a number that represents the content. For example, a file containing “Faculty research is a cornerstone of UC success!” would have a hash value of: 30698beffcc23beed890396afedd2ece and it will always hash to that number. The hash value is stored, not the contents of the file. A person with access to the hash value cannot translate that value to obtain the contents of the file.

While the hash cannot be used to access content in a human-readable format, the hashing technique is useful to determine whether files matching known malware signatures were loaded on other UC systems.

The current TDI solution is not what the industry calls a “full packet capture” solution. The system analyzes network sessions – commonly called session based. It does not offer “play-back” capability like a DVR.

The only circumstance where content is stored is when it is both unencrypted and flagged as malicious.

Is there an example where an email might be analyzed and flagged for action?

The best practice for e-mail client to server communication uses encryption. The threat detection and identification system cannot access the content of e-mails using any standard e-mail provider as those sessions are encrypted.

cybersecurity tip:  Unrelated to TDI, all UC users should remember that e-mail is not secure!  Although communication from an e-mail application (client) to the e-mail server may be secured, if e-mail leaves the e-mail server, users must always assume it is readable by an unrelated party.

If an e-mail is sent insecurely and contains malware or another indicator of compromise, an alert could be generated flagging that e-mail for action at the location.

Who determines what is an “alert” for the threat detection and identification system?

Alerts are configurable.  In general, location analysts and the vendor analysts will set thresholds for that location.

Generating alerts or not generating alerts will not impact overall security metrics for cyber-risk governance.

Location analysts have the flexibility to increase sensitivity for a time period or for an area of the network.

When would the vendor analyst set an alert?

During the course of an investigation (at one or more UC locations) the vendor analyst can set an alert for other UC locations. This allows the threat detection and identification system to let UC know if it has been subject to the same/similar attack somewhere else.

Copyright © Regents of the University of California | Terms of use