Research Cybersecurity

Do you have questions about research technology and cybersecurity compliance? Whether you're in the early stages of your research or further along, we're here to help you understand the technology, processes, security requirements, and potential associated costs. Get in touch with us at [email protected] to start the conversation.

A security gap analysis is a process that evaluates security posture and framework. The goal is to identify security risks and areas of improvement. Our team is ready to collaborate with your research staff and primary IT support, to assess your IT environment based on data security criteria outlined in data access requests, incoming data use agreements, contracts, or grants.

CUI is a category of unclassified data that federal agencies create or possess, or that a non-federal entity (e.g. SDSU) receives, possesses, or creates for, or on behalf of, the federal government, which is required by a law, regulation, or government-wide policy to have safeguarding or dissemination controls. In conjunction with the Research & Cyberinfrastructure (R&CI), SDSU is in the process of deploying a computing and data enclave that adheres to all 110 National Institute of Standards and Technology Special Publication 800-171 (NIST SP 800-171) cybersecurity standards controls. If you plan to respond to a federal government RFP or RFI and anticipate that CUI may be involved, then you must have adequate cybersecurity measures in place to accept said contract.

A SSP is a Defense Federal Acquisition Regulation Supplement (DFARs) mandatory living document that describes the security controls associated with a given system. The IT Security Office has developed a SSP template, in accordance with NIST SP 800-171, that is used to document any contract or grant that requires it.

According to NIST 800-171, the SSP should include the following elements:

• System Overview: This section provides a general description of the system, its purpose, and its function within the organization. It might include details about the system's operational context and the environment in which it operates.
• System Environment: This includes details about the physical and technical environment of the system. It covers hardware, software, network connections, and any other relevant components.
• Security Requirements: The SSP should detail the security requirements specific to the system. These requirements could be derived from laws, regulations, policies, or other sources of security controls.
• Security Controls Implementation: This is a core part of the SSP, where each required security control is listed along with a description of how it is implemented (e.g. not applicable, planned, or implemented). This could include technical measures (like encryption and access controls), as well as administrative and physical controls.
• Operational Processes and Procedures: This section covers the procedures and processes associated with operating and maintaining the system securely, including user access management, incident response, and security patching.
• Roles and Responsibilities: This part defines the roles and responsibilities of personnel involved in the management, operation, and use of the system. It includes those responsible for implementing and maintaining security controls.
• Data Flows and Network Diagram: An explanation of how data moves through the system, which is important for understanding potential vulnerabilities and implementing appropriate protections.
• Security Policies and Procedures: This includes the specific policies and procedures established to maintain the system's security posture.
• Risk Assessment and Management: The plan should discuss how risks to the system are assessed and managed, including any ongoing or periodic assessments.
• Plan Maintenance: The SSP is a living document and should include a schedule or method for regular updates and reviews.