Frequently Asked Questions - ISO Services

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)