Common questions about The Information Security Office service offerings
Application Security Testing Program (ASTP)
- My application received a Pass grade. Does this mean my application is certified for Protection Level 2 data?
- What if I cannot meet the remediation due dates presented to me in the final report?
- Based on my data, I have external regulatory requirements like PCI, HIPAA, or CPHS. Does an ASTP assessment cover me for those requirements?
- How often am I required to have an assessment against my application?
Nessus Network Vulnerability Scanning
- What are the privileges for members in a security contact?
- What are Group Security Contacts used for?
- What are Service Provider Security Contacts and how do they work?
- How are security notices routed?
- Does the application support IPv6?
- Does the application support DHCP registration?
- What is the process if another contact is non-responsive when I want to claim or transfer something immediately?
- Security contact X and my security contact used to both claim subnet A. Why can't we still do that?
- Why can I see the name of another security contact that claims an individual IP address on some subnets but not on others?
- Can you display the email address of the other security contacts so I can contact them directly?
- What are the different types of email generated by NetReg? Can I opt out from receiving any/all of them?
- I've received an "IP address to transfer" message.
- Can I self-register Fixed IP address assignments?
- Can I self-register Dynamic DNS hostnames?
Restricted Data Management (RDM)
Vendor Security Assessment Program
Frequently asked questions concerning the ISP Vendor Security Assessment Program (VSAP).
- What is a "3rd-party service provider"?
- What is the purpose of the Vendor Security Assessment Program?
- Who needs to be involved in a vendor security assessment?
- Are vendor services available that have already been approved?
- I have PL1 data, what do I do?
- The contract has already been signed, what do I do?
- The Data Security & Privacy Appendix was not included in the vendor contract, what do I do?
- How do I get started?
ISO Security Notices
How to interpret and respond to security notices from the Information Security Office
- Why did I get a Compromised Host / Possibly Compromised System notice and what should I do?
- Why did I get a Vulnerability Detected notice and what should I do?
- Why did I get a Credential Exposure notice and what should I do?
- Search for Sources
- I received a Security Notice saying my operating system is unsupported. How do I know if my operating system is supported?
Common questions campus departments may have concerning procurement and management of "cloud" services:
- Having identified a service with attractive functionality, how do I find out whether there are similar services available or in use on campus?
- How do I determine if there is an existing contract in place with the supplier?
- How do I know if my intended use of service is in compliance with University policies?
- Who is responsible for my data?
- Where do I find additional Information about Cloud Services?
Copyright & File Sharing
Questions about Phishing and how you can protect yourself against these extremely common scams
- What is Phishing?
- What can I do to avoid Phishing attacks?
- How can I identify a Phishing scam?
- Why is understanding the risk of Phishing important?
- Who do I contact if I think my CalNet credentials were compromised?
- How would I know if my CalNet credentials were compromised?
- What if my personal email account, bank account, or other accounts were compromised?
- How do I report a Phishing or suspicious email?
- Do I only need to worry about Phishing attacks via email?
Common privacy-related questions. For more information, please visit the UC Berkeley Privacy Office web site.
Shared Firewall Service
- Is this service suitable for me?
- What are the benefits of using this service?
- Are there any drawbacks to using this service?
- Can I use the shared firewall service if I store sensitive or restricted data?
- Can I make customizations to the shared firewall rules?
- What if I have issues or feedback about this service?
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.
- 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 dependant on the protection level of the data you have: PL0 and PL1 data can be stored on Google Drive and Box. PL2 data may only be stored on Calshare
- 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
- 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.
Feb. 1, 2020 - The Information Security Office will begin sending notifications to the responsible individual or group for the Windows 7 system connected to the campus network asking these devices be upgraded to a supported operating system or removed from the network.
Mar. 1, 2020 - The Information Security Office will begin blocking all Windows 7 devices seen on the campus network.
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
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 and Policy team 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 PL2 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 Information Security Office scanning is initiated from the following subnet:
Scanning will be initiated only from IP addresses with DNS hostnames in the "security.berkeley.edu" subdomain. All ISO scanners have hostnames that reflect their role, such as "sns-campus-scanner-1.security.berkeley.edu".
If you detect scanning activity and are unsure if an ISO scanner is the source, please contact firstname.lastname@example.org for verification.
Credentialed scans are scans in which the scanning computer has an account on the computer being scanned that allows the scanner to do a more thorough check looking for problems that can not be seen from the network. Examples of the sorts of checks that a credentialed scan can do include checks to see if the system is running insecure versions of Adobe Acrobat or Java or if there are poor security permissions governing a service. Information Security Office (ISO) runs Nessus scanners that are capable of running these credentialed scans; however, without accounts on the local machines, we are unable to use this functionality. With this in mind, ISO will create accounts on one of the Nessus scanners for departmental security administrators to do their own credentialed scans. In order to use the ISO scanners to perform a credentialed scan of a Windows system, the following settings are required by Nessus:
- The Windows Management Instrumentation (WMI) service must be enabled on the target.
- The Remote Registry service must be enabled on the target or the credentials used by Nessus must have the permissions necessary to start the remote registry service and be configured appropriately.
- File & Printer Sharing must be enabled on the system to be scanned.
- An SMB account must be used that has local administrator rights on the target. A non-administrator account can do some limited scanning; however, a large number of checks will not run without these rights. According to Tenable, the company behind Nessus, in Windows 7 it is necessary to use the Administrator account, not just an account in the Administrators group. ISO is currently in the process of testing this and looking for potential workarounds.
- Ports 139 (TCP) and 445 (TCP) must be open between the Nessus scanner and the computer to be scanned. Information on what IP block to open in the firewalls can be found here: What is the source network for security scans conducted by Information Security and Policy?
- Ensure that no Windows security policies are in place that blocks access to these services. Two common problems are the SEP configurations that block off the scanners even after the scanners is authenticated and a network access model that sets network access to "Guest only" permissions (see below for information on changing this).
- The default administrative shares (i.e. IPC$, ADMIN$, C$) must be enabled (AutoShareServer = 1). Since these are enabled by default and can cause other issues if disabled, this is rarely a problem.
To check if a system has a "Guest only" sharing and security model go to the Control Panel, open "Administrative Tools," and then "Local Security Policy". In that window go to Local Policies --> Security Options --> Network access: Sharing and security model for local accounts. On some Windows installations, this is set to "Guest only - local users authenticate as Guest" by default. If this is the setting on your box, you will need to change it to "Classic - local users authenticate as themselves".
PLEASE NOTE: Some of the settings above may, in some environments, actually decrease the security of a system. If this is the case, once the credentialed scan is performed, it is advisable to return the system to its previous state.
There are four privilege levels for any member of a security contact:
View-only: can view registration information.
Device: can make changes to Device registrations.
IP Information: can claim subnets, request IP Addresses, register subdomains and offsite hostname. Can register RD Applications. Can also make changes to Device registrations.
Admin: includes Device and IP Information privileges. Can also make profile and membership changes to the security contact itself.
A Group Security Contact (GSC) is created by a Department Security Contact (DSC) when a separation of responsibilities is needed. Each DSC will have an orgnode set, and the GSC will be associated to the department via its parent, the DSC.
A Group Security Contact can be used to help departments separate devices into sets that receive (or do not receive) IT support from a Service Provider Security Contact (SP SC). Additionally, when responses to security incidents is the responsibility of different groups (e.g., a research lab within a larger department, student systems vs. an administrative one) a DSC can create a GSC to receive targeted notices.
Service Provider Security Contacts (SCs) are a special purpose security contact. As a service provider, they don't have registered network assets, but they are flagged within NetReg as providing support for another SC. For example, the Service Provider SC might register devices for the Client SC. Service Provider SCs have "device-based" privileges with the Client SC; they can create, edit and delete devices from the Client SC.
Service Provider SCs can be grouped or departmental. Notifications about security events (compromises, vulnerabilities, etc.) will go to members of both Service Provider and Client SCs.
Security notices are routed based upon the most specific registration information available in NetReg.
For example, if an IP address has a registered security contact, the security notice is sent to that contact. If there is no specific IP address registration then the notice is sent to the security contact that claimed the subnet. Notices will also be sent to:
• the registrant contact role's service provider if any
• its departmental / parent contact role if any,
• and any contact roles that have 'CC SC' status for the IP address
OR, if the IP addresses is for a DHCP device (in the LIPs subdomain) the security notice will go to whomever was using the address at that time (to CalNet ID).
NetReg supports IPv6.
DHCP registration was added to NetReg in Oct 2015. For instructions on how to use NetReg to register devices for use with the Campus DHCP Service, please visit the "Register Devices" page in the NetReg documentation.
Overlap is not allowed in NetReg. If two departments share a subnet, during the data conversion 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 SC will own and be primarily responsible for an IP address, although other SCs may be provided shared notification..
For complicated situations, e.g., where two different groups are responsible for systems on a subnet, a Contact Role created just for that shared responsibility might be the best solution.
NetReg is designed to facilitate communication between security contacts for the purpose of keeping network registration information up-to-date, without revealing private security mailing list addresses or allowing out-of-band communication between security contacts on other issues.
If you claim the entire subnet you can view the names of the security contacts that claim individual IP addresses on that subnet. If you only claim an individual address then you cannot see the names of the other security contacts.
No. Requests for IP addresses, CC IP Address status are handled via the request/approve/deny process. Any other communication issue can be handled by contacting ISO.
There are three types of email generated by NetReg:
- FYI emails: These emails are rolled up into a single digest which is sent once per day. Users can opt out of receiving the digest by setting "Receive FYI digest" to off. However, at least one Security Contact (SC) member should continue to receive them.
- Notices of "requests to approve or deny": These are sent within 5 minutes from when the request is made via the NetReg application, and are sent to all members in the SC. Users do not have the option to opt out of receiving these.
There are 4 kinds of "requests to approve or deny" which users may receive:
- Request to transfer an individual IP address. (Note: the request can be initiated by either the SC that currently claims it (request to give), or by the SC that wants it (request to take).)
- Request for CC SC status for an IP address
- Request for membership within a SC
- Request to create of a group SC within a department SC
- Notices to "outside" entities (i.e., ISO RT ticketing system, Hostmaster, or IT Policy): These are initiated by NetReg backend processes or sometimes by NetReg users and are cc'd to any relevant SC's membership.
For example, when a request is made for a new departmental SC the request will go to the Information Security Office (ISO). ISO will conduct an intake process and will create the DSC.
You've received the message because Netreg 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 Netreg 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:
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: NetReg 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.
Department and Group Security Contact roles can register devices for Fixed IP address assignment – where a device always gets the same IP on its primary subnet, but a Dynamic IP on any other subnet – provided that the contact role has a registered subnet, with available IP address space, and a registered subdomain.
For details about registering devices for Fixed IP address assignment, please review the "Register Devices" page in the NetReg documentation.
Yes. Security Contacts can assign a Dynamic DNS (DDNS) hostname to a device when using Dynamic IP addressing (DDNS is not available for devices registered with a Fixed IP address assignment). Please review the "Register Devices" page in the NetReg documentation for details.
Note: Dynamic DNS hostnames will be reviewed by the campus hostmaster and changed if inappropriate.
The Information Security Office (ISO) takes privacy issues very seriously, and we use the same approach for balancing security and privacy for restricted 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 restricted data hosts are:
- More frequent scanning -- network vulnerability scans for NetReg registered hosts occur nightly
- A greater range of intrusion detection signatures are reviewed with notifications sent to the security contact
- Elevated responses to alerts – ISO staff are alerted immediately and will attempt to reach an administrator as soon as possible.
- Longer retention of network data for future analysis if a breach is confirmed -- this can help to confirm if a hacker was able to access the restricted data during the breach incident
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 ISP vendor security assessment are technologies used to store, process, and/or transport covered 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 covered 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 Protection Level 2 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:
|Resource Owner or Proprietor||Campus unit representative who has overall responsibility for the application (e.g., budgeting and resource allocation).|
|Implementation Project Manager||Unit member responsible for the roll-out of the application or service, including (but not limited to) vendor selection, contract specifications, configuration, process-flow design, personnel training, etc.|
|UC Buyer||Representative in the UC Procurement department responsible for the vendor contract negotiation.|
|Vendor Representative||Staff member of the service provider responsible for completing the Vendor Security Assessment Questionnaire. Ideally, this person is affiliated with the IT department and is knowledgable regarding the vendor's security framework. Often times, the person in this role is a Sales or Customer Support Representative who facilitates communication between the vendor's IT staff and the ISO Assessor.|
|ISO Assessor||A member of the ISO analysts team assigned as the primary assessor responsible for the engagement with the unit.|
There are several 3rd-party vendor services that are readily available to campus that have been approved for PL1 and PL2 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.
PL2 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 that’s core purpose is to provide automated workflows and document management and storage and can be integrated with other campus systems if needed.
PL1 Approved Services
- The bConnected suite of collaboration services, including Google Apps for Education (bMail, bCal, bDrive)
- 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 Protection Level 1 (PL1) data through the following actions:
- Be sure to include the UCOP Data Security & Privacy Appendix (link is external), 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 with the requirements of the UC Berkeley Minimum Security Standard for Electronic Information (MSSEI) policy for the protection of PL1 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 Protection Level 2 (PL2) data:
- If the overall risk level is acceptable, the unit is assured that the vendor meets campus policy for the protection of PL2 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 email@example.com.
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
Congratulations on searching for "sources" in the search box. This is the best way to find content on our site.
- 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.
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:
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 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 firstname.lastname@example.org.
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 PL2 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 PL2 system that is vendor managed, review the Details of the Vendor Security Assessment Program and then send an email request to email@example.com (link sends e-mail).
If there are particular services or types of services that you believe would add significant value, please contact David Willson (firstname.lastname@example.org).
For questions concerning IT policy, contact email@example.com.
For all other questions, contact firstname.lastname@example.org.
1. As a "takedown notice" under the DMCA:
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.
Phishing is a type of attack carried out in order to steal usernames, passwords, credit card information, Social Security Numbers, and other sensitive data by masquerading as a trustworthy entity. Phishing is most often seen on campus in the form of malicious emails pretending to be from credible sources such as UC Berkeley technology departments or financial organizations related to the university.
By tricking campus users into giving away their information, attackers can:
- Steal money from victims (modify direct deposit information, drain bank accounts)
- Perform identity theft (run up charges on credit cards, open new accounts)
- Send spam from compromised email accounts
Use your credentials to access other campus systems, attack other systems, steal confidential University data, and jeopardize the mission of the campus
The goal of most Phishing emails is to trick you into visiting a web site in order to steal your CalNet credentials. Attackers will set up web sites under their control that look and feel like legitimate web sites. Often the Phishing emails will have an immediate call to action that demands you to "update your account information" or "login to confirm ownership of your account". If you enter your CalNet credentials into these illegitimate web sites you are actually sending your CalNet username and password directly to the attackers.
Review these 5 essential tips to avoid being "Phished":
- Passwords in Email = Epic Fail. Never send your passwords in an email!
- If you didn't expect it, reject it. Don't click unexpected links!
- Hover to Discover. Look out for deceptive links!
- Check for Trash Before the Slash. Verify "https://auth.berkeley.edu/" in your browser bar before entering CalNet credentials!
- Is it a Phish? Drop us a line.
- 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
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 an ongoing threat to campus and are becoming increasingly sophisticated. Successful Phishing attacks can cause financial loss for victims and put their personal information at risk.
- Passwords in Email = Epic Fail. Never send your passwords in email!
- If you didn't expect it, reject it. Don't click unexpected links!
- Hover to Discover. Look out for deceptive links!
- Check for Trash Before the Slash. Verify "https://auth.berkeley.edu/" in your browser bar before entering CalNet credentials!
- Is it a Phish? Drop us a line.
If you believe your CalNet credentials have been compromised, you must reset your CalNet passphrase immediately.
- Contact the Cal 1 Card Office at 180 Cesar Chavez Center
- Email email@example.com (link sends e-mail) or call (510) 643-6839
FACULTY, STAFF, AFFILIATES, AND GUESTS:
- Contact your CalNet Deputy. Click here to view a list of CalNet Deputies by department.
- 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 firstname.lastname@example.org or CSS-IT Service Desk at 510-664-9000
- Only use devices that are rigorously maintained. Rigorously maintained means patches for all software is installed 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 anti-virus scans should result in a "clean" report (no infections) for the machine you intend to use to change your CalNet passphrase from.
Note: Information Security and Policy 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.
- 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.
If you receive an email you are not sure about, forward the suspicious email -- don't reply -- to email@example.com or call the ITCS Service Desk at 510-664-9000. The email can be blocked from the campus system to prevent others from falling victim to the Phishing attack.
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.
Authorization to access electronic communications, with or without consent, is coordinated through the the Campus Privacy Officer, Office of Ethics, Risk and Compliance Services:
Departments can contact firstname.lastname@example.org to discuss how to de-activate employee CalNet ID or Berkeley email (bMail) service either immediately or otherwise earlier than the normal "grace period".
Signed approval by an authorized requestor is required. Download the Exceptional Disabling of CalNet ID or Email Accounts form [Word] for detailed information. 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.
Ransomware is often spread through phishing emails that contain malicious attachments or through drive-by downloading. Drive-by downloading occurs when a user unknowingly visits an infected website and then malware is downloaded and installed without the user’s knowledge.
Crypto ransomware, a malware variant that encrypts files, is spread through similar methods and has also been spread through social media, such as Web-based instant messaging applications. Additionally, newer methods of ransomware infection have been observed. For example, vulnerable Web servers have been exploited as an entry point to gain access to an organization’s network.
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.
Here are some tell-tale 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
If you believe your system has been infected with Ransomware:
- Unplug your system (e.g. Ethernet cables) from the campus network and disable any other network adapters such as wireless network interfaces. Ensure your system is fully disconnected from campus networks and the Internet. This can aid in preventing the spread of the Ransomware to shared network resources such as file shares. Contact CSS-IT if you need assistance in disconnecting your system.
- Report the possible infection to Information Security and Policy.
If you do not have safe backups of your system, there may be options for unlocking your data:
Some variants of Ransomware have flaws in the way they implement the encryption used to lock your files. A collaboration between Intel Security, Kaspersky Lab, and Europol called No More Ransom! has a collection of decryption tools for Ransomware that has been cracked by researchers:
- 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.
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.
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.