UCSF is required by a number of laws, regulations and policies to assess the risk of information systems that create, store, process or transmit UCSF data. This activity helps UCSF meet federal and state laws and regulations and University policies.
What is an IT security risk assessment at UCSF?
The IT security risk assessment process collects information about each of our information systems and scores their security compliance. The process, called a distributed systems technical risk assessment, measures the security aspects of all computing devices associated with the system including servers, desktop computers and laptops, phones, tablets, routers, switches, network connections and other technologies.
The goal of measuring system security is to protect the information. A risk assessment demonstrates how well the protections built into the system design positively support the confidentiality, integrity and availability of its data. Note: The information system must be fully designed before the risk assessment can be started.
All the questions inside the risk assessment are answered by assertions, meaning that the UCSF system owner (the person who purchases or leases the system on behalf of UCSF) must understand the system and have completed all design elements, including creation of the supporting documentation.
Risk assessment requirements
To perform a risk assessment, the system owner or a technical delegate must:
- Identify the name of the system.
- Have a full system-asset inventory (list of all equipment).
- Identify the data classification, which determines the sensitivity of the information being created, stored, transmitted or otherwise processed inside or outside UCSF. Please see the UCSF Data Classification Standard.
Examples of systems that would need risk assessments: a new or changed email system, a research application or a clinical-care solution.
Important: It is essential that risk assessment be performed on systems that handle UCSF information outside of UCSF.
Do you need a distributed systems technical risk assessment?
UCOP Policy BFB-IS-3 (Electronic Information Security)
identifies that security risk assessments must be conducted on all systems, applications and vendors (1) when they are initially introduced into the UCSF infrastructure and (2) at times when significant changes are made, such as a new server or new operating system or other substantive change. Additionally, systems may require an annual re-assessment.
If you are introducing a new or modified system, please ensure that the system is in final design state or as close to it as possible, with a data flow diagram that shows all ports, protocols and IP addresses used. Here's an example of what the data flow diagram should look like to show all data flows, ports and protocols as well as whether the information is inside or outside UCSF: example_data_flow_diagram.pptx
Have you prepared for this type of risk assessment?
- Have you completed the UCSF minimum security standards checklist? https://it.ucsf.edu/sites/it.ucsf.edu/files/650-16_minimum_security_standards_checklist-v5.pdf
- Do you have a completed data flow diagram? This is a document describing the data flow of the system from every asset and endpoint, both internal and external, showing the specific ports and protocols that are to be used (e.g., port 443) to protect the data in transit.
If you need assistance preparing the data flow diagram, please work with the Customer Solutions Management group by submitting an IT Consultation Request at https://ucsf.service-now.com/ess/consulting_planning.do.
- Do you have all management roles of the system identified (e.g., who "owns" the system, who will manage accounts, who will perform patching)?
- Have the security procedures you will use to manage the system been documented?
- Have you worked with UCSF IT to complete a Business Impact Analysis (BIA) for the system? If not, you must initiate a BIA by contacting Bernie Conlu (Bernie.Conlu@ucsf.edu) – this can be done in parallel with the risk assessment. See http://itsm.ucsf.edu/business-impact-analysis-bia-0 for more information.
When systems are implemented, many decisions, assumptions and operational plans are made. Reviewing these systems for security risks requires documentation of these decisions, assumptions and plans, allowing the aggregate product of the system to be reviewed to ensure that adequate protections are in place.
As stated in the HIPAA guidance on risk analysis, there is no one-size-fits-all blueprint for compliance and documentation. That's because these systems comprise many different types of distributed systems and operating systems, database software, application software, programming languages and so on.
However, to support the UCSF community, we have created general recommendations for the types of information to be created and documented for projects. Leveraging this information to create a complete view of the pertinent details of the system will support the risk assessment review and ensure timely project implementation.
Note: The type of risk assessment discussed here does not require additional documentation, because all the documentation should be present before the assessment is initiated.
How to request a security risk assessment
Once (1) the system is in final design, with a data flow diagram that shows what ports are used, and (2) the resource owner and system name are known, use the following link to submit a request for a system security risk assessment: https://ucsf.service-now.com/ess/sec_risk_assessment.do.
What to expect during the risk assessment process
Step 1: Preparation/background questions
The assessor will send the UCSF contact an email outlining the assessment process and requirements. The assessment tool will then send the UCSF contact an invitation to complete the preparation/background questions using the assessment tool web interface (30-minute customer time commitment).
Step 2: Technical questions
The assessor will send an email to the technical contact identified in the preparation/background questions (this may be a vendor contact or an internal UCSF contact) as notification that they will need to answer the technical assessment questions. The assessment tool will then send the technical contact an invitation to complete the technical assessment questions (60-minute customer or vendor time commitment).
Step 3: Assessment review
The assessment tool assigns a weight to each response to automatically calculate a security compliance score. The assessor will then confirm the results by manually reviewing the assessment responses and the data flow diagram, ensuring that UCSF security compliance requirements are addressed.
Depending on the results, the assessor may need to discuss findings or required remediations with the UCSF system owner. If the system meets security compliance requirements, the assessor will request final approval from IT Security management.
Step 4: Completion
The assessor will email the system owner with notification that the assessment is complete and that final approval was or was not granted (0-minute customer commitment).
Who is the audience for the information documented by the risk-assessment process?
Depending on the data classification and use case, the audience will vary. The information gathered and documented should be organized and formatted in such a way that someone who has a technical background can understand the various components of the system and its purpose, data flows and life-cycle, the security controls put in place and the management controls for the system.
In addition to the primary purpose of risk assessment review, the project documentation may be referred to by a wide-ranging audience for tasks such as contractual review, grant review, incident response, board review, third-party review and other security attestation activities. Some of these circumstances are uncommon, but preparation for them supports appropriate diligence and information stewardship in the event a breach or other incident occurs.
The audience may typically include any or all of the following: University of California entities (e.g., Office of the President, UCSF IT Security, UCSF Audit & Advisory Services, other UC campuses or medical centers), federal and state government entities (e.g., HHS Office for Civil Rights [OCR], National Institutes of Health [NIH], California Department of Public Health [CDPH]), and federal, state, local or UC law enforcement.