Frequently Asked Questions

Please see Instructions for Registering P4 Workstations in Socreg for step-by-step instructions.

The degree of monitoring on campus varies depending on the location of the system. For most users the only traffic that is inspected for signs of compromise is traffic that goes off of the campus network or is directed at systems protected by our firewalls. For people on networks protected by a firewall there is additional monitoring at the firewall location. 

When it comes to the Restricted VPN the monitoring occurs for almost every packet that leaves the systems connected to the VPN.

Traffic from this service is blocked if it is going to or coming from a list of IP addresses, hostnames and URLs the security department believes are involved in malicious activity. These lists are derived from both our own monitoring and from reputable third party sources. Additionally, traffic that is detected as malicious, where the severity of the activity is set as a medium (or higher) level by Palo Alto networks (our VPN and firewall vendor), is also blocked.

Because of the increased monitoring, most users will only want to use the Restricted VPN for access to the systems that host the restricted data. Beyond that, it is probably preferable to use the normal VPN. 

The normal VPN has only minimal traffic monitoring beyond information about logins. In comparison, the Restricted VPN monitors all traffic as it exits the VPN and employs the vulnerability, anti-spyware, AV, file monitoring, and threat detection and blocking features of the Palo Alto firewalls.

The regular VPN service is intended to allow members of the campus community to access campus resources without having to be physically present on the campus. The Restricted VPN is meant to not only allow people remote access to the network, but to also enforce stricter security controls including blocking some traffic, logging all network traffic, detecting signs of unusual activity to or from the clients and using security profiles to block any malicious or vulnerability related traffic that has a rating of medium severity or higher.

As part of its monitoring service, information about the security of the host system (information like the OS, malware protections, disk encryption, and missing patches) is also monitored and recorded. As the service evolves this information will also be used to further restrict access to the network.

Individuals who access and control a large quantity of restricted data or key IT infrastructure as part of their normal business activity may be eligible for this service. Individuals who use the data are not necessarily eligible. This service is for those with a high level of access to bulk quantities of this data. Additionally, researchers working in heavily targeted areas may be eligible for this service.

To confirm eligibility, please contact rvpn@berkeley.edu with a description of the types and quantities of data you are accessing, and where it is stored.

First off, what is a disclosure?

It's the intentional or unintentional release of protected or private/confidential information to an untrusted environment or to unauthorized individuals.

Process for reporting a disclosure

1. Remove the disclosed information as soon as possible
2. Immediately report the incident to the Information Security Office
3. Notify your supervisor

Now that your CalNet account has been unlocked, you must reset your passphrase as follows:

1. Go to https://mycalnet.berkeley.edu

2. Select "Forgot my CalNet ID / Passphrase"

3. Enter your Student, Employee, or Affiliate ID NUMBER, or recovery email address

4. Confirm that you are not a robot by selecting all of the applicable images

5. Once you receive the email to reset your passphrase, enter your Student, Employee, or Affiliate ID number again to set a new passphrase

Because your exposed CalNet passphrase puts the security of your personal data at risk, you must also complete each of the following tasks after you reset your passphrase.

1. If you are a UC Berkeley employee, confirm that no changes have been made to your Direct Deposit account. From a safe and malware-free computer, access the Direct Deposit link from https://ucpath.berkeley.edu/ or call Payroll (510-642-1336).  

2. Confirm that your email is not being redirected to any account you do not recognize via unauthorized email forwarding, and make sure there are no filters you did not create (e.g. send all <my bank emails> to my Trash folder.

1.  How to forward emails from bMail account: https://support.google.com/mail/answer/10957?hl=en

2. How to use filters in bMail: https://support.google.com/mail/answer/6579?hl=en

3. Review bMail account logs and sign out of active sessions

1. Log into your bMail account

2. In the very lower right corner, under "Last account activity" click the "Details" link

3. This will show the last few connections to your account; review for unknown logins

4. On the same page, click the large gray button "Sign out of all other web sessions"

4. Re-secure your Recovery Email Address by changing the password. The recovery email address is a non-"berkeley.edu" email address attached to your CalNet account. Resetting the password on this account helps ensure that it is also not compromised.

5. Recreate your bConnected Google Key. If you had a Google key set, it has been scrambled. Create a new one using the Manage My Keys application: https://idc.berkeley.edu/mmk/  or contact bConnected support: bconnected@berkeley.edu or 510-664-9000 press 1 and follow the prompts.

6. Review your CalNet 2-Step devices to make sure no changes have been made. Log in to mycalnet.berkeley.edu, click on Manage 2-Step Verification, perform a 2nd 2-Step to see the Device Control Panel, and review your devices, there. See: https://calnetweb.berkeley.edu/calnet-2-step

Units interested in detailed information about IS-3 controls; roles and responsibilities; and implementation tools from the UC Systemwide Policy Office can contact ISO at security@berkeley.edu to request access to the systemwide materials. 

Please fill out this request form only if you have not already been in contact with campus IT professionals (either through your department or IT Client Services) regarding the upgrade of your current Windows 7 computer, purchase of a new computer, or security exception application.

1. Begin by backing up your files. You can do this to a local device or move your data from the computer to servers or cloud-based platforms. Please note that location is dependent on the protection level of the data you have: UC P1 and UC P2/P3 data can be stored on Google Drive and Box. UC P4 data may only be stored on Calshare
2. Confirm that any software (outside of the standard MS Office, Chrome, Adobe Acrobat) is compatible with Windows 10 and that you have the installation files and activation keys needed 
3. Go to: https://software.berkeley.edu/microsoft-os and download your desired operating system.

Exceptions are allowed only if the system cannot be upgraded and depending on the data classification level and the amount of data of that type. Submit your security exception request by November 1, 2019, to allow time to implement mitigations needed before End of Life.

Visit here for the exception process

If you are running Windows 7 you are unsupported and out of compliance with campus policy.

What happens next:

• Feb. 1, 2020 - ISO notifies Windows 7 systems users to disconnect from the campus network
• Mar. 1, 2020 - ISO blocks Windows 7 devices seen on the campus network

Please note: In the event that a Windows 7 exploit is released before Mar. 1, ISO reserves the right to immediately block any vulnerable device per the Blocking Network Access Policy.

Exceptions

Exceptions are allowed only if the system cannot be upgraded and depending on the data classification level and the amount of data of that type. Learn more about security exceptions at our Exception Process for Windows 7 End of Life (EOL) page.

If the computer is managed by ITCS: Submit a ticket: https://sharedservices.berkeley.edu/it/(link is external)

If the computer is managed by your department IT: Submit a ticket directly to them

If you do not have campus IT support you can download the software here: https://software.berkeley.edu(link is external)

Is it a personal computer? Yes, then you can download the software here: https://software.berkeley.edu

1. Upgrade to a supported operating system. Red Hat Enterprise Linux (RHEL) subscriptions are available for departments who have a large number of systems and wish to migrate to RHEL8 or RHEL9 and manage their own RHN organization instance.  Software download location and links to installation instructions will be provided with delivery of access keys. Contact unix-tickets@berkeley.edu(link sends e-mail)(link sends e-mail) to request access.

2. Remove or retire the system.

Exceptions will only be approved if there is a valid reason why the system cannot be upgraded and remediation steps such as obtaining extended support, EDR clients, and network firewalls have been put in place (these are just examples and not an exhaustive list). Submit a security exception as early as possible, to allow time to implement mitigations needed before End of Life. More information on exception requests here

Berkeley prioritizes privacy and data protection for individuals with Endpoint Detection and Response (EDR) software installed on university-owned computers and servers. Campus EDR is not intended for installation on personally owned devices.

The Campus Privacy Office and the Information Risk Governance Committee (IRGC) are currently reviewing our EDR program. The IRGC provides the campus framework for institutional governance of information risk under campus and systemwide privacy policies, including the Electronic Communications Policy. 

• See our detailed EDR Service article for more information.

We are only installing the EDR software on campus-owned machines. Additionally, we strongly encourage staff to utilize Berkeley-owned and managed machines because IT staff will be better able to support those devices and configurations.

Most campus users are required to use EDR. Before requesting an exception, please review the exception requirements and process

Although the UC Electronic Communications Policy allows for the incidental personal use of University electronic resources, and use of EDR-collected information is limited to what is required for analysis and remediation of security incidents, you may feel that you do not want your personal online activity included in EDR data collection that security analysts could review. We recommend conducting such personal online activity on a device not owned or managed by the University.

Note: Per UC-wide requirements, in future phases of the campus EDR project, personally-owned devices used to connect to University "trusted networks" and "enterprise systems" (to be defined by the campus) will also require EDR software.

EDR scans continuously and keeps a 10-minute record of your machine's activity, which is saved only if a security alert is triggered.

The regular scan includes:

• Network activity, such as URL data and DNS lookups
• File activity, such as downloads
• Images loaded
• System processes and registry events (applications and tasks running on the device)

When a security alert is triggered, EDR takes a copy of a second 10-minute interval, including:

• Applications running
• Web sites visited
• File activity, such as downloads
• Processes running on the machine

See our detailed EDR Service article (CalNet Authentication required) for more information.

Berkeley IT uses Trellix for our Endpoint Detection and Response software. To see if Trellix has been installed on your university machine, follow these steps based on your operating system.

Apple machines:

Search for a file called “FireEye Helper” in the applications folder

- or -

Open terminal and run:

ps aux | grep xagt

If you get a result that includes this in response to this prompt, Trellix is likely running:

/Library/FireEye/xagt/xagt.app/Contents/MacOS/xagt -M DAEMON 

Windows machines:

Look for this image on your taskbar:

Linux machines:

Open terminal and run:

ps aux | grep xagt

If you get a result that includes this in response to this prompt, Trellix is likely running:

/opt/fireeye/bin/xagt -M DAEMON

Once installed, the software runs seamlessly in the background while you do your regular work. It uses real-time information and machine learning to detect, contain, and respond to threats quickly to mitigate further damage.

Specifically, EDR uses several techniques, including:

• Signature-based engine to find and block known malware (akin to traditional anti-virus and anti-malware software).
• MalwareGuard machine learning using seeded threat intelligence.
• Behavior-based analytics engine to stop advanced threats.
• Real-time discovery of Indicators of Compromise (IOC) using frontline threat intelligence.

See our detailed EDR Service article (CalNet Authentication required) for more information.

In general, you can tell if your computer is centrally managed if you see the Self Service app on your Apple machine, or the BigFix Self Service app on your Windows machine.

If your desktop or laptop computer is centrally managed by campus, EDR will automatically be installed on your machine. Beginning in October 2024, ISO will be working to roll out installation across campus for workstations.

If you wish to install EDR on your server before, please email us at endpoint-security@security.berkeley.edu

Trellix was formerly named FireEye. You may see references to FireEye on your computer after this product is installed on your machine. The screenshot below shows a popup message you may receive on your Apple machine after Trellix is installed via BigFix.

For questions or issues with this installation, email endpoint-security@security.berkeley.edu

No. Information Security and Policy does not "certify" applications. A Pass or Fail grade is intended to indicate whether or not an application meets the campus minimum security requirements for application security at the time at which it was assesssed. 

An application security assessment is intended to find the most critical and high risk vulnerabilities; however, the assessment process is often accelerated due to time and resource constraints meaning all vulnerabilities may not be discovered in a single assessment.

Remediation due dates are generated based on the risk and the breadth of the vulnerability. Due dates can be negotiated with the Information Security Office at the time of disclosure. For example, some due dates may be changed for reasons like:

• Reliance upon a vendor to implement a fix for a discovered vulnerability
• Development time
• Retirement of a vulnerable portion of an application

Ultimately, it is the responsibility of the application owner to make or coordinate best efforts to remediate and/or adequately mitigate the risks in a timely fashion.

No. ASTP assessments only measure compliance with campus minimum application security requirements. Though, it should be noted that achieving compliance with campus standards will lay a lot of ground work for meeting PCI, HIPAA, CPHS, or other external standards. The campus Minimum Security Standards for Electronic Information (MSSEI) is based off the SANS Top 20 Critical Controls, so there is some overlap with external standards.

Currently, applications handling UC P4 data should plan for an application security assessment once every two years. However, scheduling will depend on available resources and other factors such as how drastically an application has changed since the prior assessment.

All Information Security Office network vulnerability scanning is initiated from the following network subnets:

IPv4:

• 128.32.30.64/27 

IPv6:

• 2607:f140:1:14::/64

If you detect scanning activity and are unsure if an ISO scanner is the source, please contact security@berkeley.edu for verification.

To change your profile settings in Socreg, log in and click your name in the top bar and then click ‘Settings’.  Current options are:

• Receive Release Email - this toggles whether or not you would like to receive the Socreg release notifications.

Note: This setting is different than the ‘Receive FYI messages’ setting.  FYI messages are set per unit Security Contact and are FYI messages about the Security contact and its assets.

The Information Security Office (ISO) takes privacy issues very seriously and we use the same approach for balancing security and privacy for Protected Data hosts as for all hosts on campus. Monitoring of systems occurs through two methods, monitoring of network traffic crossing the campus border and vulnerability scanning of hosts on the campus network. The methods used to do this are similar for all hosts on the campus network.

The enhanced services for Protected Data hosts are:

• More frequent scanning 

• A greater range of intrusion detection signatures are used

• Elevated responses to alerts by ISO staff 

• Longer retention of network data for future analysis if a breach is confirmed -- this can help to confirm if an attacker was able to access the Protected Data during a breach incident.

Security notices are routed based on the registration information in Socreg.

For example, if an IP address has a registered Security Contact, the security notice is sent to that Security Contact, but if there is no specific IP address registration, then the notice is sent to the Security Contact that registered the subnet that contains the IP Address. Notices will also be sent to:

• The registrant Security Contact’s Service Provider, if any.

• The registrant Security Contact’s Departmental / Parent Security Contact, if any.

• Any Security Contacts that have 'CC' status for the IP address.

• The Device registrant if the IP Address is a DHCP IP address.  

Yes, Socreg supports IPv6.

Overlap is not allowed in Socreg. If two departments share a subnet, the department who claims the most IP addresses for that subnet will get the entire subnet. The other department will get individual IP addresses.

Additionally, one Security Contact will register and be primarily responsible for an IP address, although other Security Contacts may also receive security notices for that IP address.  

For complicated situations, e.g., where two different groups are responsible for systems on a subnet, a Security Contact created just for that shared responsibility might be the best solution.

Contact the Information Security Office at: socreg@berkeley.edu

There are three types of email generated by Socreg:

1. FYI emails: These emails are rolled up into a single digest which is sent once per week. Users can opt-out of receiving the digest by setting "Receive FYI digest" to “off”. However, at least one member of the Security Contact should continue to receive them.  Some FYI emails are sent immediately, for example when a PD Application or one of its components is modified.

2. Notices about Access or Asset Requests.  Others may submit a request in Socreg for:

• Membership within a Security Contact

• New Group Security Contact

Or an asset:

• IP Address

• CC IP Address

• Device

• PD Application

Notifications are sent when the request is made and will repeat weekly until either approved or denied in Socreg.  

3. Notices to "outside" entities (i.e., ISO ticketing system, DNS Administrator, or IT Policy): These are initiated by Socreg backend processes or sometimes by Socreg users and are copied to the Security Contact’s membership.For example, when a request is made for a new Department Security Contact, the request will go to ISO and we will conduct an intake process before creating the Department Security Contact.

You've received the message because Socreg has encountered a mismatch between the security contact that claimed an IP address (individually or by subnet) and the security contact that registered a subdomain.

(Note: In Socreg the assignment of a subdomain enables the transfer of IP address responsibility to the right party, but does not assign security contact responsibility).

For example, if security contact A registers a subdomain xyz.berkeley.edu and another security contact B claims subnet a.b.c.0/24 and there is a set of hostnames defined in DNS:

a.b.c.11   h1.xyz.berkeley.edu

a.b.c.12   h2.xyz.berkeley.edu

a.b.c.13   h3.xyz.berkeley.edu

security contact A and B will each get a message suggesting that the IP addresses be transferred from B to A.

Either security contact can initiate the transfer: Security contact A can 'request to take'; B can 'request to give'.

If the other party agrees and approves the transfer then B ends up with the subnet and A has 3 individual IP records out of that subnet because of its subdomain registration.

Remember: Socreg does not automatically make the transfer because there may be alternate solutions to resolve the discrepancy.  In the above example, security contact A could relinquish the IP addresses, or have their DNS hostname changed to something not in the xyz subdomain.

You are receiving this "IP address to transfer" message so that you can choose the best solution.

A "vendor" or "3rd-party service provider" is an entity (e.g., a person or a company), separate from the University, that offers something for sale.  The typical types of vendor services that require an ISO vendor security assessment are technologies used to store, process, and/or transport protected data on behalf of the University, such as:

• Software as a Service (SaaS) providers - companies that provide hosted application services (e.g., Google bmail)
• Infrastructure as a Service (IaaS) providers - companies that provide hosted data storage or processing services (e.g., Amazon AWS)

These types of vendors are required to meet the same campus policy standards for the protection of protected data that is required for applications and services that are managed by internal campus IT resources.

The Vendor Security Assessment Program is intended to ensure that service providers who handle UC P4 data on behalf of the University meet campus security policy requirements.  This is achieved in two ways:

• By evaluating the vendor's security controls in comparison to campus policy.
• Ensuring that the UCOP Data Security & Privacy Appendix is included in the vendor contract to provide baseline protection for the University in the event of a data breach.

The roles that are typically involved in participating with a vendor security assessment include the following:

There are several 3rd-party vendor services that are readily available to campus that have been approved for UC P2/P3 or UC P4 data.  Campus units that adopt these 3rd-party services for the purpose of storing and sharing covered data can be assured that these vendors meet campus policy requirements.

Campus units that utilize these services for the handling of protected data should keep in mind that careful configuration and management of these applications is required to meet campus policy standards.

 UC P4 Approved Services

• CalShare, a web-based document management and collaboration system utilizing Microsoft SharePoint. 
• The Imagine document imaging and workflow service is a campus service with the core purpose to provide automated workflows and document management and storage and can be integrated with other campus systems if needed. 

UC P2/P3 Approved Services

• The bConnected suite of collaboration services, including Google Apps for Education (bMail, bCal, bDrive)
• Box
• bCourses Project Sites
  

Please visit the bConnected website to learn more about the MSSEI protection level ratings for each of these products:  https://bconnected.berkeley.edu/collaboration-services

Units can ensure that 3rd-party service providers meet the campus data security policy requirements for the handling of UC P2/3 data through the following actions:

• Be sure to include the UCOP Data Security & Privacy Appendix, required for all UC contracts involving 3rd-party access to protected data, without edits, in the service provider contract.  This ensures baseline protection for the University in the event of a data breach, including:
• Service provider compliance with applicable laws (e.g., FERPA, HIPAA), regulations and campus policy.
• Requirements for a vendor information security plan and breach reporting process.
• Adequate cyber-insurance to cover the cost of investigating and responding to a breach.
• Notify the service provider that by signing off on the Data Security & Privacy Appendix, they are obligated to abide by campus policy, including adherence to the requirements of the UC Berkeley Minimum Security Standard for Electronic Information (MSSEI) policy for the protection of UC P2/3 data.

Although there is less bargaining power with the service provider to address security concerns after the contract has already been signed, it is still a good idea to perform a vendor security assessment for service providers who are handling UC P3 or P4 data:

• If the overall risk level is acceptable, the unit is assured that the vendor meets campus policy for the protection of UC P3 or P4 data.
• If the overall risk level is High or Critical, it may be necessary to postpone or suspend the service until these issues have been addressed.

Vendors may be more inclined to participate in a security assessment after the contract has been signed, but before the service has been initiated - as billing often does not begin until services have started. 

For VSAP reports with an overall acceptable risk rating, any medium-level risk findings identified in the report should be discussed with the vendor during the next contract renewal period.

For all UC contracts involving third-party access to covered data, the University of California Office of the President (UCOP) requires the inclusion of the Data Security and Privacy Appendix.  The appendix establishes baseline protection for the University in the event of a data breach.  Campus units that engage with service providers to handle covered data must ensure the appendix is included in new contracts without edits.

For VSAP engagements that have been initiated after the contract has been approved, and the UCOP appendix has been omitted, the final assessment report will include contract-related risk findings.  These findings are generally of a Critical risk nature, e.g.:

• No guarantee of service provider compliance with applicable laws (e.g., FERPA, HIPAA) or campus policies for the protection of covered data.
• The absence of requirements for a vendor information security plan and breach reporting process.
• Inadequate cyber-insurance to cover the cost of investigating and responding to a breach.

In these cases, the unit may be required to suspend the use of the service until the contract issues have been resolved with the vendor.

To request a Vendor Security Assessment Program evaluation for a PL2 system that is vendor managed, review the Details of the Vendor Security Assessment Program and then send an email to security@berkeley.edu. 

Please include the following information:

• Name of the unit requesting VSAP service
• Project Lead contact information
• UC Provisioning Representative contact information (if applicable)
• Name of third-party vendor/product/service
• Service description
• List of protected data elements that are known to be processed, stored, or transmitted by the service provider (see the UC Data Classification Standard for details)
• Estimated number of records containing PL2 data

A typical VSA takes 4 to 6 weeks to complete starting from the date the Vendor has provided all the information requested. Please plan accordingly.

Yes, the Requester will be responsible for providing the following information when requesting a VSA:

• Vendor primary point of contact (name, title, phone number, and email address)

• Vendor name and product/service being purchased

• A description of the Vendor product/service and how it will be used on campus

• A completed UC Appendix DS Exhibit 1 form

Additionally, the following security documents will speed up the assessment process:

• SOC 2 Type II report

• If available, include the Vendor’s SOC 2 Type II report. NOTE: Venminder will need the Vendor’s own report and not the report of the Vendor’s hosting provider such as AWS, Azure, GCP, etc.

• PCI DSS compliance documentation for Vendors that accept payment card data on behalf of UC.

• Please include the vendor’s PCI DSS Self-Assessment Questionnaire (SAQ), Attestation of Compliance (AOC), and any other supporting policies or PCI compliance documentation.

ISO will no longer ask for the statement of work, contract/agreement, or the Vendor’s security plan.

The Requester is responsible for signing any Non-Disclosure Agreements with the Vendor and informing ISO which documents are under NDA. 

Inform the ISO Assessments Team on the corresponding ServiceNow ticket for your VSA request if the Vendor is asking that ISO or Venminder sign the NDA.

Once a VSA is complete, ISO recommends reviewing the guidance letter and the Venminder report with your Unit Information Security Lead (UISL) to decide on the appropriate course of action for responding to the findings identified in the Venminder report. The ISO guidance letter in particular will provide information regarding what type of response the Unit requires per campus security policy.

Units are allowed a maximum of one (1) resubmission for Vendors that receive an overall Not Recommended rating. Prior to resubmission, significant deficiencies identified in the previous assessment must be addressed. If a Vendor receives an overall Not Recommended rating after the one (1) resubmissions, then alternative Vendors should be considered or apply for an exception.

Why is there a limit on the number of resubmissions?

• A limit on reassessments encourages Vendors to take the necessary steps to improve their offerings before seeking another evaluation. This fosters a culture of accountability and continuous improvement, ultimately benefiting both parties.

• Our assessment team has finite capacity. Frequent reassessments of Vendors who have previously failed can overwhelm our resources, leading to delays in evaluating other potential vendors. By setting a limit, we ensure that our team can maintain a balanced workload and continue to assess new vendors effectively.

• Each reassessment requires considerable time and effort from both our team and the Vendor. Limiting reassessments helps streamline our operations and ensures that we can focus on Vendors who meet our expectations.

• Reassessing a Vendor incurs costs to order assessments from Venminder. By limiting reassessments, we can better manage our budget.

Units requesting a Vendor Security Assessment (VSA) should review the following document and share it with the Vendor so that they are prepared for the VSA process.

• UC Berkeley Vendor Security Assessments (VSA) - Responsibilities & Expectations (PDF)

Did you receive an email from security@berkeley.edu with Compromised Host / Possibly Compromised System in the Subject line?

Please see our Respond to a Security Notice page for detailed information and instructions on how to respond.

Did you receive an email from security@berkeley.edu with Vulnerability Detected in the Subject line?

Please see our Respond to a Security Notice page for detailed information and instructions on how to respond.

Did you receive an email from security@berkeley.edu with Credential Exposure in the Subject line?

Please see our Respond to a Security Notice page for detailed information and instructions on how to respond.

Congratulations on searching for "sources" in the search box. This is the best way to find content on our site.

aHR0cHM6Ly9mb3Jtcy5nbGUvVWtCNjVKOEFxSGFXcGZpdzc=

                                                       - All your base are belong to us

Security best practices, as well as campus Minimum Security Standards for Network Devices (MSSND), require the use of supported software for which the vendor will make security updates available in a timely fashion. As vendors are unable to support all previous versions of software, older programs are dropped from support and must be upgraded or removed from the network. It is especially important to be aware of your operating system “end of life”, as major upgrades often require time and planning.

Windows

Microsoft publishes current lifecycle information for Windows operating systems. If your version of Windows is past the date for extended support, or not listed, your operating system is not supported and you must retire the system or upgrade to a supported version of Windows. When planning for department equipment purchases and upgrades, be aware of any upcoming “end of life” dates for your version of Windows.

Mac OS X

While Apple does not officially acknowledge the end of support for Mac OS X operating systems, past experience shows that security updates addressing critical vulnerabilities are only released for the current and one previous version of Mac OS X. When Apple releases security updates for Mac OS X, operating systems with vulnerabilities that are not patched by Apple will be considered unsupported.

Mac OS X users should plan on upgrading their operating systems regularly as Apple releases new versions. We recommend updating to either the latest version, or one previous version, no more than 90 days after a new version is released.

A list of current security updates can be found on the Apple Support site:  https://support.apple.com/en-us/HT20122

Other Operating Systems

Check with your vendor to confirm whether or not your version is still under support and receiving security updates for known vulnerabilities. Operating system vendors often publish lifecycle information to assist customers with upgrade planning:

• Red Hat Enterprise Linux
• Debian
• Solaris

MSSND Exception Requests

If your operating system is not currently supported, and you cannot immediately upgrade to a supported release, you must request a policy exception to keep the machine connected to the campus network. Your request should include details such as:

• Why you cannot upgrade your current unsupported operating system
• Timeframe for upgrading or retiring the system
• Full inventory of software running on the system
• Expected use of the system including all network use
• Firewall rules and other security controls mitigating the risk

The best campus resource for this the IST Service catalog. Additionally, the IST Procurement department may be able to assist you in finding services that have already been purchased on behalf of the campus.

Contact the UCB Procurement Office directly to find out whether an existing contract is in place with a service provider:  supplychain@berkeley.edu

The distinction here is that just because there is a contract in place with a supplier doesn't mean that it is appropriate for all use cases.

An example is our Google agreement which will meet the overwhelming majority of our needs in the e-mail/calendar space, but that is not HIPAA compliant and as such is not a good fit for use cases where Protected Health Information is in play. For assistance with IT policy questions, contact security-policy@berkeley.edu.

By engaging with a service provider, you have the responsibility as the Resource Proprietor for ensuring compliance with laws, regulations and policies, including standards (UC Business Finance Bulletin IS-2 and IS-3).

For example, if notice-triggering data is involved, the service (whether on or off campus) must meet the protective measures defined in the campus Minimum Security Standard for Electronic Information.

Information that is subject to state or federal regulations will have use and disclosure restrictions that must be maintained.  Student records are protected by FERPA regulations.  Medical records are protected by HIPAA, FERPA, and state laws.

The Resource Proprietor, in consultation with the Resource Custodian, is responsible for determining the level of risk (subject to law, regulation, and policy) and ensuring the implementation of appropriate security controls to address that risk.  This puts responsibility for evaluation of the service's security controls (e.g., hardening, patching and monitoring) in the hands of the Resource Proprietor. Although not directly applicable to services outside of the campus network, the campus Minimum Security Standard for Networked Devices provides a useful set of baseline security requirements.

For evaluating cloud service providers that handle P4 data on behalf of the University, the Information Security Office offers the Vendor Security Assessment Program (VSAP).  The VSAP is intended to ensure that campus third-party service providers adhere to the same baseline level of security practices required for campus systems and applications that contain protected information and are managed and maintained by internal campus resources.

To request a VSAP evaluation for a P4 system that is vendor managed, review the Details of the Vendor Security Assessment Program and then send an email request to security@berkeley.edu (link sends e-mail).

If there are particular services or types of services that you believe would add significant value, please contact David Willson (dwillson@berkeley.edu).

For questions concerning IT policy, contact security-policy@berkeley.edu.

For all other questions, contact security@berkeley.edu.

1.  As a "takedown notice" under the DMCA:

See The Digital Millennium Copyright Act (DMCA) and Related Resources

2.  As a legal action taken by the copyright holder’s legal representative, e.g. an Early Settlement Offer or a Subpoena:

Campus legal counsel cannot represent individuals in matters of alleged copyright infringements.  Students may seek information from the Student Legal Services office, employees will need to obtain their own personal legal counsel.

General information:

• Copyright Resources

EDUCAUSE maintains a list of legitimate download services.

Phishing is a type of attack carried out in order to steal information or money. Phishing attacks can occur through email, phone calls, texts, instant messaging, or social media. Attackers are after your personal information: usernames, passwords, credit card information, Social Security numbers. However, they are also after intellectual property, research data, and institutional information. Phishing scams can have several goals, including:

• Stealing from victims - modifying direct deposit information, draining bank accounts.
• Performing identity theft - running up charges on credit cards, opening new accounts.
• Purchasing items - buying gift cards, tricking victims into working on their behalf.
• Getting victims to act - clicking on malicious links, installing malware on their devices.

The first rule to remember is to never give out any personal information in an email.  No institution, bank or otherwise, will ever ask for this information via email.  It may not always be easy to tell whether an email or website is legitimate and phishing emails are using social engineering tactics to make create sophisticated scams.

• In the body of an email, you might see questions asking you to “verify” or “update your account” or “failure to update your records will result in account suspension.” It is usually safe to assume that no credible organization to which you have provided your information will ever ask you to re-enter it, so do not fall for this trap.
• Any email that asks for your personal or sensitive information should be seriously scoured and not trusted. Even if the email has official logos or text or even links to a legitimate website, it could easily be fraudulent. Never give out your personal information.

Phishing attacks are a constant threat to campus and are becoming increasingly sophisticated. Successful Phishing attacks can:

• Cause financial loss for victims
• Put their personal information at risk
• Put university data and systems at risk

We encourage the UC Berkeley community to take an active role in protecting themselves against phishing attacks. Use our helpful tips in our Fight the Phish campaign to recognize and report phishing attacks.

Additionally:

• If you are worried about an account, call the organization which maintains it (like your bank)
• Check the email address—does it really match the text of the email? Does it match the legitimate email of the organization it is supposed to be tied to?
• Check the security certificate of any website into which you are entering sensitive data. They should usually begin with https:// Some browsers will display padlock symbols in the address and status bars. Anything on a website saying it is safe can be falsified and is not verified by the browser you are using, and so shouldn’t be trusted
• Keep your software current
• Install antivirus software

• Being tricked to giving up your credentials at a real-looking but scam website (AKA Phishing)
• Malware or other compromises of your device which installs software designed to run in the background and steal passphrases
• Re-using CalNet credentials for non-UCB websites, and the non-UCB websites are hacked and all credentials exposed

However, a couple of tell-tale signs of credential compromise are:

• Your colleagues and friends have received unexpected messages from your email account (spam or additional Phishing emails)
• You suddenly cannot login with your CalNet credentials because an attacker has changed your passphrase

• Know how to evaluate whether websites asking for your passphrase are legitimate. When in doubt, ask by sending an email to itcsshelp@berkeley.edu or contacting ITCS at 510-664-9000
• Only use devices that are up-to-date. This means patches for all software are installed as soon as the patches become available, that the browsers are configured for maximum security, and the device otherwise meets the campus Minimum Security Standards for Networked Devices.
• Do not reuse your CalNet passphrase for other websites

If in doubt regarding the security of your CalNet account, change your CalNet passphrase!

When changing your CalNet passphrase, be sure to do so from a machine you believe is not infected by malware or otherwise compromised. Anti-malware and antivirus scans should result in a "clean" report (no infections) for the machine you intend to use to change your CalNet passphrase from.

Additionally, if you answer yes to any of the following questions, you should also reach out to the ISO office, by emailing security@berkeley.edu:

• While performing your normal duties, do you access protected data (UC P4) from the workstation for University business, including access to the data through central campus applications/services (ImageNow, PeopleSoft, HCM, Payroll/PPS, BFS, etc)?
• Do you suspect there are University (non-personal) documents containing protected data stored on the workstation?
• Are there file shares (also known as network drives or mapped drives) mounted on your workstation with stored protected data, whether or not you work with those files?
• Do you use accounts on this workstation that have privileged [administrator, superuser, database owner (dbo)] access to other systems with protected data?
• Do you store any usernames and passwords in plain-text (not encrypted) on the workstation?
• Do you work with Research data regulated by Campus Institutional Review Boards (IRB),  California Committee for the Protection Human Subjects(CPHS), or subject to other Data Access Agreements?

Note: The Information Security Office is sometimes informed when passwords associated with UC Berkeley accounts are exposed in public forums or discovered during breach investigations. In these cases, we may test the exposed passwords to see if they are valid CalNet passphrase. If the passphrase is validated, it will be scrambled immediately and the account deactivated until the account owner is contacted to create a new passphrase. This testing is done only for validation purposes and is not used for access to the account holder's email or other electronic services.

Please see Why did I get a Credential Exposure notice and what should I do? for information on what to do if you receive an ISO Security notification for exposure of your account credentials.

If you believe your CalNet credentials have been compromised, and you still have access to your account, change your password immediately.  Instructions for changing your passphrase can be found online: https://calnetweb.berkeley.edu/calnet-me/manage-my-calnet-account#passph....

• If you are not able to access your account, contact security@berkeley.edu.
• If you have received notice from CalNet that your account has been locked, email calnet@berkeley.edu.
• To regain access to your accounts, you will need to verify your ID by showing a government-issued photo ID via Zoom or in person, so be prepared.
• To open a ticket with CalNet, email: calnet@berkeley.eduor call 510-664-9000 (Option 1, 1). 

Additionally, if you answer yes to any of the following questions, email the Information Security Office at security@berkeley.edu immediately to report the compromise.

• While performing your normal duties, do you access protected data (UC P4) from the workstation for University business, including access to the data through central campus applications/services (ImageNow, PeopleSoft, HCM, Payroll/PPS, BFS, etc)?
• Do you suspect there are University (non-personal) documents containing protected data stored on the workstation?
• Are there file shares (also known as network drives or mapped drives) mounted on your workstation with stored protected data, whether or not you work with those files? 
• Do you use accounts on this workstation that have privileged [administrator, superuser, database owner (dbo)] access to other systems with protected data?
• Do you store any usernames and passwords in plain-text (not encrypted) on the workstation?
• Do you work with Research data regulated by Campus Institutional Review Boards (IRB), California Committee for the Protection Human Subjects(CPHS), or subject to other Data Access Agreements?

• Immediately change your passwords for any potentially compromised accounts
• Contact your bank or financial advisor to let them know your accounts may be compromised and ask them to put a fraud alert on your accounts
• Check your bank and financial statements and credit reports to regularly identify any false charges or suspicious activity
• If you believe you are a victim of identity theft, please see the Federal Trade Commission's Immediate Steps to Repair Identity Theft.

Reporting suspicious emails can dramatically reduce the duration and impact of an active phishing attack.

Using the bMail web interface:

1. Open the message
2. To the right of 'Reply' arrow, select 'More' (typically denoted with three vertical dots)
3. Then 'Report phishing'

Reporting through Google allows the email to be blocked from further attacks against and may prevent others from falling victim to the attack.

If you are unable to log into bMail, forward the message to phishing@berkeley.edu or call the ITCS Service Desk at 510-664-9000. 

No.  Phishing attacks can also occur through phone calls, texts, instant messaging, or malware on your computer which can track how you use your computer and send valuable information to identity thieves. It is important to be vigilant at all times and remain suspicious of sources that ask for your credentials and other personal information.

As an employee of UC Berkeley, any information you create or receive during your employment that has anything to do with the business of UC or the Campus belongs to the Regents.  Whether it is information stored in your paper files, on your computer, voice messages, portable media, home laptop, or another account or device used by you,  the information is Regential property and must be created and managed according to policy.

Any personal information you may accumulate during your employment belongs to you.  You are responsible for the management of your own information.  This means at a minimum that if you move location, transfer to a new position, or separate from University employment you must take your personal information with you.  Any personal information left behind will be treated in the same manner as any tangible personal property.  It will be disposed of according to the campus procedure. 

FERPA, shorthand for the Family Educational Rights and Privacy Act, was enacted by Congress in 1974 [20 U.S.C. 1232g].   This legislation gives parents of minor students, and students who are over 18, the right to inspect, correct, amend, and control the disclosure of information in education records. It obliges educational institutions to inform parents and students of their rights and to establish policies and procedures through which their rights can be exercised. 

FERPA gives students of any age enrolled in a university or college the right to give or withhold consent for the educational institution to use or disclose personal information about them.  There are a number of exceptions to this general right. The main one is that institutions may use student information for legitimate business purposes. Requests to use or disclose UC Berkeley student information are approved by the Registrar who is the authorized data steward for all student information.

FERPA training:

https://studentprivacy.ed.gov/request-ptac-training-or-technical-assistance(link is external)

https://studentprivacy.ed.gov/content/online-training-modules

Access to former employee email or files is coordinated through the Campus Privacy Officer, Office of Ethics, Risk and Compliance Services:

• Accessing Former Employee Email or Files

Authorization to access electronic communications, with or without consent, is coordinated through the the Campus Privacy Officer, Office of Ethics, Risk and Compliance Services:

• Authorization to Access Electronic Communications

Employees have a standard 90-day grace period after they have separated from UC Berkeley, during which they can access limited campus services, such as bMail. In rare cases, a department may want to request early termination of a former employee’s CalNet or Berkeley email (bMail) account before the end of the standard 90-day grace period.

Departments can contact policy-access@berkeley.edu to discuss how to deactivate employee (including volunteer and affiliate) CalNet or bMail accounts immediately or otherwise earlier than the normal grace period. 

Forms and Process:

• For early disabling of a separated employee’s access, download the Request for Exceptional Disabling of CalNet Account form below for information and instructions. This form is intended to be used for emergency early CalNet account termination. Signed approval by an authorized departmental official is required.
  • Request for Exceptional Disabling of CalNet Account form (Word version)

• If the account suspension is temporary and the employee may eventually return to their position, download the Request for TEMPORARY Disabling of CalNet ID or bMail Account form below for information and instructions. This action is for exceptional circumstances only and must be approved by the employee's Department, Human Resources, and Campus Counsel. 
  • Request for TEMPORARY Disabling of CalNet ID or bMail Account form (Word version)

• A scanned image of the printed form (with signature) may be submitted by email in lieu of a hard-copy.

Ransomware is a type of malicious software that infects a computer and restricts users’ access to it until a ransom is paid to unlock it.  Ransomware variants have been observed for several years and often attempt to extort money from victims by displaying an on-screen alert. Typically, these alerts state that the user’s systems have been locked or that the user’s files have been encrypted. Users are told that unless a ransom is paid, access will not be restored. The ransom demanded from individuals varies greatly but is frequently $200–$400 dollars and must be paid in virtual currency, such as Bitcoin.

The authors of ransomware instill fear and panic into their victims, causing them to click on a link or pay a ransom, and users systems can become infected with additional malware. Ransomware displays intimidating messages similar to those below:

• “Your computer has been infected with a virus. Click here to resolve the issue.”
• “Your computer was used to visit websites with illegal content. To unlock your computer, you must pay a $100 fine.”
• “All files on your computer have been encrypted. You must pay this ransom within 72 hours to regain access to your data.”

Ransomware not only targets home users; businesses can also become infected with ransomware, leading to negative consequences, including

• temporary or permanent loss of sensitive or proprietary information,
• disruption to regular operations,
• financial losses incurred to restore systems and files, and
• potential harm to an organization’s reputation.

Paying the ransom does not guarantee the encrypted files will be released; it only guarantees that the malicious actors receive the victim’s money, and in some cases, their banking information. In addition, decrypting files does not mean the malware infection itself has been removed.

Infections can be devastating to an individual or organization, and recovery can be a difficult process that may require the services of a reputable data recovery specialist.

US-CERT recommends that users and administrators take the following preventive measures to protect their computer networks from ransomware infection:

• Employ a data backup and recovery plan for all critical information. Perform and test regular backups to limit the impact of data or system loss and to expedite the recovery process. Note that network-connected backups can also be affected by ransomware; critical backups should be isolated from the network for optimum protection.
• Keep your operating system and software up-to-date with the latest patches. Vulnerable applications and operating systems are the targets of most attacks. Ensuring these are patched with the latest updates greatly reduces the number of exploitable entry points available to an attacker.
• Maintain up-to-date anti-virus software, and scan all software downloaded from the internet prior to executing.
• Restrict users’ ability (permissions) to install and run unwanted software applications, and apply the principle of “Least Privilege” to all systems and services. Restricting these privileges may prevent malware from running or limit its capability to spread through the network.
• Avoid enabling macros from email attachments. If a user opens the attachment and enables macros, embedded code will execute the malware on the machine.
• Do not follow unsolicited Web links in emails. Refer to the Phishing resources found on this website for more information.

Individuals or organizations are discouraged from paying the ransom, as this does not guarantee files will be released.  However, the FBI has advised that if Cryptolocker, Cryptowall or other sophisticated forms of ransomware are involved, the victim may not be able to get their data back without paying a ransom.

Signs your system may have been infected by Ransomware:

• Your web browser or desktop is locked with a message about how to pay to unlock your system and/or your file directories contain a "ransom note" file that is usually a .txt file
• All of your files have a new file extension appended to the filenames
• Examples of Ransomware file extensions: .ecc, .ezz, .exx, .zzz, .xyz, .aaa, .abc, .ccc, .vvv, .xxx, .ttt, .micro, .encrypted, .locked, .crypto, _crypt, .crinf, .r5a, .XRNT, .XTBL, .crypt, .R16M01D05, .pzdc, .good, .LOL!, .OMG!, .RDM, .RRK, .encryptedRSA, .crjoker, .EnCiPhErEd, .LeChiffre, .keybtc@inbox_com, .0x0, .bleep, .1999, .vault, .HA3, .toxcrypt, .magic, .SUPERCRYPT, .CTBL, .CTB2, .locky or 6-7 length extension consisting of random characters

Yes, if: 

• Your service contains printers and workstations only.
• You don't have any custom rules.
• You don't have technical staff who can configure your firewall rules. 
• Your security needs are not extensive. 

No, if: 

• Your subnet(s) hosts servers and services used outside the firewall.

• You host sensitive data.

• You have regulatory or contractual obligations to safeguard data that resides on your network.

• Restricting traffic based on malicious content or destinations known to be malicious is unacceptable to the users on your subnet.

• You don’t need to write your own firewall rules.

• You don’t need to define security profiles.

• Increased security using profiles that block systems from connecting to or receiving traffic from known bad addresses

• Malicious content (spyware, attempts to exploit known vulnerabilities, etc.) will be stopped by the firewall

• This service should not be used if you store restricted data.

• Rules and profiles in the shared firewall are not customizable.

• The only services on the protected side of the firewall that can be accessed from the unprotected side are printing and remote desktop services. These services can only be accessed from non-Calvisitor campus addresses.

• Campus vulnerability scanners are allowed and there will be no firewall exceptions for devices that have issues with scanning

• Since systems using the shared firewall service are not isolated from each other,  malicious insiders may still be able to access the systems on the protected side of the firewall.

• This service can only accommodate entire subnets. If you only want a subset of your systems to use it,  those systems must be put on a new network.

The shared firewall service is not intended for systems storing sensitive data. Depending on the circumstances, you should either use a fully customizable Departmental Firewall or the High Security Managed Firewall service.

No. Customizations are not made for individual departments. However, it is an evolving service and changes will be made if necessary to support the general needs of campus workstation computing.

If you have comments or suggestions for the service, please email bsecure@berkeley.edu(link sends e-mail) or share with the bSecure Mailing list(link is external).