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?
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 to 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
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