RiskSonar - IT Security Risk Assessment
What is a "RiskSonar" risk assessment at UCSF?
RiskSonar is a web-based software tool used as the UCSF system of record to collect information about each of our information systems and score their security compliance. The process is called a distributed systems technical risk assessment and measures the security aspects of all computing devices associated with the system, including servers, desktop computers/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 the protections built into the system design positively support the confidentiality, integrity, and availability of its data. Note that the information system must be fully designed before the risk assessment can be started. All of the questions inside the risk assessment are answered by assertions, meaning that the UCSF system owner must understand the system and have completed all design elements, including creation of the supporting documentation.
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.
To perform a risk assessment - the system owner (the person who purchases or leases the system on behalf of UCSF) or their technical delegate must:
- identify the name of the system,
- have a full system asset inventory (list of all equipment), and
- know the data classification, which is the measure of the sensitivity of the information being created, stored, transmitted or otherwise processed inside or outside UCSF. Please see the UCSF Data Classification Standard.
These are the minimum essential items required by UCOP policy. (page 4 of UCOP Policy IS-3 found here).
Examples of a system that would need a Risk Assessment would be a new or changed email system, a research application, or a clinical care solution.
It is important to note that it is essential that risk assessment be performed on systems that handle UCSF information outside of UCSF.
Do You Need a Distributed Systems Security Risk Assessment?
UCOP BFB IS-3 identifies that security risk assessments must be conducted on all systems, applications, and vendors when they are initially introduced into the UCSF infrastructure and at times when making significant changes such as a new server or new operating system or other substantive change. Additionally, every system requires 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 as possible with a diagram showing all ports and IP addresses used. This one required item in the risk assessment is for a completed diagram to show what the system will look like when the system goes into final production so that an auditor can understand the system at a glance.
Have you prepared for a System/Technical Risk Assessment?
- Do you have a completed UCSF minimum security standards checklist? https://it.ucsf.e du/sites/it.ucsf.edu/files/650-16_minimum_security_standards_checklist-v4.pdf
- Do you have a completed data flow diagram? This is a document showing the data flow of the system from every asset and endpoint both internal and external showing the exact ports and protocols that are to be used (ie. port 443) to protect the data in transit. If not, please go here and work with Solutions Architects: https://ucsf.service-now.com/ess/consulting_planning.do
- Do you have all management roles of the system identified - as in who will manage accounts, who will perform patching and at what intervals, and how the data will be managed?
When systems are implemented there are many decisions, assumptions and operational plans made. Reviewing these systems for security risks requires documentation of these decisions, assumptions and plans so that the aggregate product of the system can be reviewed to ensure adequate protections are in place. This assessment does not require additional documentation because all of the documentation should be present before the assessment is initiated.
UCSF recommended controls may be administrative safeguards (non-technical) and/or technical controls which result in a reduction in risk to the data. For a complete list of recommended security controls please see the ITS Check List Template that is also used by our Project Management Office for collecting background information prior to entering the security risk assessment. It is found here its-check-list-template-v1.docx
As stated in the HIPAA guidance on risk analysis there is no one-size-fits-all blueprint for compliance and documentation. This is because there are many different types of distributed systems and operating systems, database software, application software, programming languages, etc. which make up these systems. However to support the UCSF community we have created general recommendations for the types of information that is created for projects. Leveraging this information to create a complete view of the pertinent details of the system will support the review and ensure timely project implementation.
How To Request a Security Risk Assessment:
Once the system is in final design, and there is a data flow diagram that shows what ports are used, and the resource owner and system name are known - then
please use the following link to submit a request for system risk assessment: https://ucsf.service-now.com/ess/sec_risk_assessment.do
What should you expect during the risk assessment process?
Step 1: Preparation:
The assessor will send the UCSF system owner an email outlining the assessment process and requirements. RiskSonar.com will then send the UCSF technical contact an invitation to register with the RiskSonar tool and to complete the preparation questions (30 minute customer time commitment).
Step 2: Main Assessment:
The assessor will send an email to the technical contact identified in the preparation questions (this may be a vendor contact or internal UCSF contact) to notify them that they will need to answer the more technical main assessment questions. RiskSonar.com will then send the technical contact an invitation to register with the RiskSonar tool and to complete the main assessment questions (30 minute customer/vendor time commitment).
Step 3: Assessment Review:
The RiskSonar tool assigns weights to each assessment response and automatically calculates a security compliance score. The assessor will then confirm the results by manually reviewing the assessment responses and the data flow diagram to assure UCSF security compliance requirements are addressed (0 min customer commitment). Depending on the results, the assessor may need to discuss findings or required remediations with the UCSF system owner (customer commitment depends on findings). 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 whether final approval was granted. (0 min customer commitment)
Step 5: Feedback:
We will request your feedback on the process (5 min commitment). This is an optional step that will help us improve our overall process.
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 a system, purpose, data flows/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, 3rd 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, and/or UC law enforcement.