Risk Sonar Security Risk Assessment (IT Security)
What is a "Risk Sonar" - Risk Assessment at UCSF?
Using RiskSonar is a way to measure the security of a system design that is complete in every respect. The process is called a distributed Systems Technical Risk Assessment and it includes measuring the security aspects of all computing devices involved in a system such as - phones, tablets, computers, servers, routers, switches, network connections, and other types of technologies. The goal of measuring system security is to protect the information. A risk assessment demonstrates how the system protections that are designed into the system positively affect the confidentiality, integrity, and availability of the information, NOTE: the end to end system must be fully designed before the risk assessment is started. All of the questions inside the risk assessment are answered by assertions. This means that the person bringing in a system to UCSF must understand the system and have proceded through all design elements - including creation of the supporting documentation. www.risksonar.com is a software application that is used by UCSF as the system of record to collect and score the information about each of our systems.
UCSF is required by a number of laws, regulations and policies to perform an assessment of risks. This activity helps UCSF meet Federal and State laws, 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.
UCOP BFB IS-3 governs the data classification.
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 new 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. 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, there is a data flow diagram that shows what ports are used, and the resource owner and system name are known - please use the link that follows to submit a request for system risk assessment. This is a Service Now request item that is selected by using the "IT Security Risk Assessment Request" - here: https://ucsf.service-now.com/ess/it_security.do
What Should Be Expected during the Risk Assessment Process?
Step 1: Preparation; The assessor will send the UCSF Resource Owner an email to request system registration and once inside https://risksonar.com - the answers to the Preparation Questions (30 Minute commitment) are submitted by clicking on "ANSWER."
- Preparation questions are inside the application and the invitation to register comes to the UCSF technical contact via email from risksonar. com
Step 2: Main Assessment; The assessor will send an email to the identified vendor contact (if vendor is involved) or to the UCSF respondent (if the system is entirely managed internally) - to answer a set of more Technical Questions. (30 min commitment)
- Main questions are inside the application and the invitation comes to the vendor or technical contact via email from risksonar.com
Step 3: Review; The application assigns weights to each response and automatically scores the responses. The assessor reviews the results. (0 min commitment)
- The UCSF Security Team will then manually review the results in order to ensure compliance. There will be follow up via phone or email with you on the findings to identify mitigations necessary to meet UCSF Minimum Security Standards.
Step 4: Completion; The assessor will let you know that the assessment is finalized. (0 min commitment)
a. Once the assessment has been deemed as meeting the standards - the recommendation is sent for final approval
Step 5: Feedback; The assessor sends a separate assessment to obtain your experience and feedback on the process (5 min commitment)
This is a voluntary step of the security risk assessment that will help us improve our overall assessment process.
Who is the audience for the information you document during the design and risk analysis phases of your project?
Depending on the data classification (more information can be found here) and circumstances for which the documentation is reviewed 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 not common by any means however preparation for them ensures appropriate diligence and information stewardship in the event the situation does occur.
The audience may typically include any or all of the following:
University of California Entities
- UC Office of the President
- IT Security and Policy
- UCSF Audit
- Other UC Campuses
Federal and State government entities
- Office for Civil Rights (HIPAA)
- National Institutes of Health (NIH)
- California Department of Public Health (CDPH)