diff --git a/.github/workflows/regular-review.yml b/.github/workflows/regular-review.yml index 9bdb735..690380c 100644 --- a/.github/workflows/regular-review.yml +++ b/.github/workflows/regular-review.yml @@ -20,7 +20,7 @@ jobs: - name: Get team members and create issue run: | TEAM_MEMBERS=$(gh api orgs/yeatmanlab/teams/roar-infosec-maintainers/members --jq '.[].login') - ISSUE_BODY="It is time for the biannual review of the Data Privacy and Information Security Manual. Please ensure all sections are up to date and in compliance with current regulations. @yeatmanlab/roar-infosec-maintainers" + ISSUE_BODY="It is time for the biannual review of the Data Privacy and Information Security Manual and the Software Development Lifecycle Policies. Please ensure all sections are up to date and in compliance with current regulations. @yeatmanlab/roar-infosec-maintainers" # Create the issue and mention the team ISSUE_NUMBER=$(gh issue create --title "Biannual Review of Data Privacy and Information Security Manual" --body "$ISSUE_BODY" --json number --jq '.number') diff --git a/.github/workflows/render-pdf.yml b/.github/workflows/render-pdf.yml index 683bc87..774f669 100644 --- a/.github/workflows/render-pdf.yml +++ b/.github/workflows/render-pdf.yml @@ -39,13 +39,17 @@ jobs: - name: Replace placeholders in markdown run: | - sed -i "s/{{ version }}/$VERSION/g" ROAR-data-privacy-and-information-security-manual.md - sed -i "s/{{ commit }}/$COMMIT_HASH/g" ROAR-data-privacy-and-information-security-manual.md - sed -i "s/{{ commit_date }}/$COMMIT_DATE/g" ROAR-data-privacy-and-information-security-manual.md + sed -i "s/{{ version }}/$VERSION/g" roar-data-privacy-and-information-security-manual.md + sed -i "s/{{ commit }}/$COMMIT_HASH/g" roar-data-privacy-and-information-security-manual.md + sed -i "s/{{ commit_date }}/$COMMIT_DATE/g" roar-data-privacy-and-information-security-manual.md + sed -i "s/{{ version }}/$VERSION/g" roar-sldc.md + sed -i "s/{{ commit }}/$COMMIT_HASH/g" roar-sldc.md + sed -i "s/{{ commit_date }}/$COMMIT_DATE/g" roar-sldc.md - name: Convert Markdown to PDF run: | - pandoc --number-sections ROAR-data-privacy-and-information-security-manual.md -o ROAR-data-privacy-and-information-security-manual.pdf + make infosec + make sldc - name: Commit and push changes run: | diff --git a/.gitignore b/.gitignore index 4764e9b..ce966f8 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,3 @@ -ROAR-data-privacy-and-information-security-manual.pdf \ No newline at end of file +roar-data-privacy-and-information-security-manual.pdf +roar-sdlc.pdf +roar-bcdr.pdf \ No newline at end of file diff --git a/Makefile b/Makefile index 08feaad..372d149 100644 --- a/Makefile +++ b/Makefile @@ -1,23 +1,34 @@ # Makefile for generating PDF from Markdown # Variables -INFOSEC_MD = ROAR-data-privacy-and-information-security-manual.md +INFOSEC_MD = roar-data-privacy-and-information-security-manual.md INFOSEC_PDF = $(patsubst %.md, %.pdf, $(INFOSEC_MD)) +SDLC_MD = roar-sdlc.md +SDLC_PDF = $(patsubst %.md, %.pdf, $(SDLC_MD)) + +BCDR_MD = roar-bcdr.md +BCDR_PDF = $(patsubst %.md, %.pdf, $(BCDR_MD)) + MD_FILES = $(wildcard vendor-assessments/*.md) VENDOR_ASSESSMENTS_DIR = vendor-assessments # Default target -all: pdf +all: infosec sldc bcdr PANDOC_OPTS = -f gfm --template ./template/eisvogel.latex \ -V linkcolor=blue \ -V header-includes:'\usepackage[export]{adjustbox} \let\includegraphicsbak\includegraphics \renewcommand*{\includegraphics}[2][]{\includegraphicsbak[frame,\#1]{\#2}}' -# Command to generate PDF from Markdown -pdf: $(INFOSEC_MD) +infosec: $(INFOSEC_MD) @pandoc $(INFOSEC_MD) $(PANDOC_OPTS) -o $(INFOSEC_PDF) +sldc: $(SDLC_MD) + @pandoc $(SDLC_MD) $(PANDOC_OPTS) -o $(SDLC_PDF) + +bcdr: $(BCDR_MD) + @pandoc $(BCDR_MD) $(PANDOC_OPTS) -o $(BCDR_PDF) + # Command to generate PDFs for all markdown files in the vendor-assessments folder vendor-assessments: $(MD_FILES) @mkdir -p $(VENDOR_ASSESSMENTS_DIR) @@ -30,9 +41,11 @@ install: # Install pandoc (Linux or macOS). For Windows, use the installer from the official website which pandoc || (sudo apt-get update && sudo apt-get install -y pandoc || brew install pandoc) -# Clean command to remove the generated PDF +# Clean command to remove the generated PDFs clean: rm -f $(INFOSEC_PDF) + rm -f $(SDLC_PDF) + rm -f $(BCDR_PDF) # Phony targets -.PHONY: all pdf clean install vendor-assessments +.PHONY: all clean install vendor-assessments bcdr sdlc infosec diff --git a/ROAR-data-privacy-and-information-security-manual.md b/ROAR-data-privacy-and-information-security-manual.md index 2ee2a41..7129425 100644 --- a/ROAR-data-privacy-and-information-security-manual.md +++ b/ROAR-data-privacy-and-information-security-manual.md @@ -24,9 +24,11 @@ This manual applies to all ROAR employees, contractors, and third-party vendors --- -## Data Privacy Policy +## Data Privacy -ROAR is committed to protecting the privacy of students, educators, and other stakeholders. This policy explains how we collect, use, share, and protect data, including personally identifiable information (PII). +Data privacy refers to the policies and practices that govern how ROAR collects, uses, shares, and retains personal information. This section outlines the measures ROAR takes to protect user privacy and comply with relevant data protection regulations. +ROAR is committed to protecting the privacy of students, educators, and other stakeholders and to transparency in its data practices. +This section covers how data is collected, how it is used for operational and research purposes, the rights of users regarding their data, the conditions under which data may be shared, and the policies for retaining and securely disposing of data when it is no longer needed. ### Data Collection and Use @@ -42,7 +44,11 @@ The data that ROAR collects from users can be broadly separated into two categor Assessment data is stored separately from personal data. personally identifiable information (PII). The personal data is stored in the "admin" database, while the assessment data is stored in the "assessment" database. -While this data is stored separately, it is recombined when ROAR transmits back to the student’s teacher, school administrator, or district administrator student name, grade level, scores, and support levels for the purpose of score reporting. +While this data is stored separately, it is recombined when ROAR transmits back to the student's teacher, school administrator, or district administrator student name, grade level, scores, and support levels for the purpose of score reporting. + +### Data Flow Diagrams + +ROAR maintains detailed data flow diagrams (DFDs) that describe how data moves through the system. The DFDs can be accessed [using this link][link_roar_dfd]. ### User Rights @@ -53,15 +59,68 @@ Parents and guardians have the right to opt out of participation in ROAR and req > Include the steps that each team takes to respond to an opt-out data deletion request. > Do we include other GDPR-like rights. For example do data subjects (students and their guardians) have the right to access, correct, and delete their data? -### Sharing Data +### Data Sharing ROAR only shares data with authorized individuals or entities, such as teachers or schools, and only when necessary to transmit score reports back to educational partners. +> TODO: +> Insert more specific language about how we share data, which data we share, and for what purpose. + +### Data Retention and Destruction + +ROAR retains and destroys data in compliance with applicable privacy regulations, internal policies, and its obligations to both research and educational partners. To ensure clarity, data is categorized into two types: research data and partnership data. Each type is subject to specific retention and destruction policies to meet the needs of ongoing research as well as obligations to educational partners. + +#### Data Categories + +- Research Data: + - Purpose: research data is used exclusively for academic purposes, such as peer-reviewed publications and ongoing research by ROAR team members. + - Composition: this data comprises de-identified assessment data (as defined above) and a subset of personal data for participants that have consented to participant in ROAR research. + - Retention: this data is retained for the duration of the ROAR project, as defined below, to ensure reproducibility of research and to facilitate further studies. + - Destruction: Within one year of project conclusion, as defined below, all research data will be reviewed. Data that is no longer needed for reproducibility or archival research will be securely deleted. + If continued retention is required for archival or legal purposes, the necessity for this retention will be documented, and the data will be de-identified to the fullest extent possible. + +- Partnership Data: + - Purpose: partnership data is collected and maintained to fulfill ROAR’s obligations to educational partners, such as providing score reports, progress updates, and other services required by partner schools and districts. + - Composition: this data comprises all assessment and personal data for participants that have opted out of ROAR research. + - Retention: this data is retained only as long as necessary to meet contractual and reporting obligations to our educational partners. This may include providing student score reports, assessment data, and other partner-requested services. + - Destruction: Once partnership data is no longer required to meet the contractual or operational obligations to educational partners, it will be securely deleted within one year. This applies to both data stored in production systems and backup environments. + +#### Defining the end of the ROAR Project + +The end of the ROAR project for the purposes of Research Data retention will be determined by the absence of significant academic research activity. Specifically, the project will be considered concluded if no peer-reviewed academic publications authored by ROAR team members, based on ROAR data, have been submitted within the preceding three years. + +#### Data Destruction Methods + +ROAR will employ secure data destruction methods that ensure the complete and irretrievable deletion of personal and research data, in compliance with industry standards and applicable data protection regulations. These methods may include: + +- Cryptographic erasure for encrypted data. +- Secure overwriting or wiping for data on physical storage devices. +- Deletion of cloud-stored data through provider-managed processes to ensure it is permanently removed from all systems. +- Shredding of paper records. + +Following data destruction, a final audit will be conducted to confirm that all required data has been securely deleted and that no residual data remains in any systems, backups, or storage devices. + --- -## Information Security Policy +## Information Security + +Information security encompasses the policies, procedures, and technologies that protect ROAR's information systems and data from unauthorized access, disclosure, alteration, or destruction. This section details the security controls ROAR implements to safeguard its infrastructure, protect sensitive information, and ensure compliance with industry standards, best practices, and [Stanford's Minimum Security Standards for Applications][link_stanford_minsec] (hereafter referred to as "minsec"). + +The section includes details on -ROAR's Information Security Policy ensures that all sensitive data, including student PII and assessment data, is protected against unauthorized access, breaches, and misuse. This policy follows industry best practices and complies with [Stanford's Minimum Security Standards for Applications][stanford-minsec] (hereafter referred to as "minsec"). +- [**Roles and responsibilities**](#roles-and-responsibilities) +- [**Access Control**](#access-control) +- [**Encryption**](#encryption) +- [**Audit logging and monitoring**](#audit-logging-and-monitoring) +- [**Incident Response**](#incident-response) +- [**Vulnerability Scanning**](#vulnerability-scanning) +- [**Penetration Testing**](#penetration-testing) +- [**Security certification of third-party vendors**](#security-certifications-and-third-party-vendor-assessments) +- [**Employee Training**](#employee-training) +- [**Data Flow Diagrams**](#data-flow-diagrams) +- [**Software Development Lifecycle Security Controls**](#software-development-lifecycle-security-controls) + +These security measures are designed to protect both ROAR's internal systems and user data from threats and vulnerabilities. The ultimate goal is to ensure that ROAR's information assets remain secure and resilient against both internal and external risks. ### Roles and Responsibilities @@ -74,7 +133,10 @@ ROAR's Information Security Policy ensures that all sensitive data, including st - Follow security best practices - Review this manual quarterly - Complete required security training - - Enroll all personal and Stanford-owned devices used for work with [Stanford Device Registration][]. Enroll each device for use with high risk data. + - Enroll all personal and Stanford-owned devices used for work with [Stanford Device Registration][link_stanford_device_registration]. Enroll each device for use with high risk data. Ensure that this registration includes + - enrollement in either [BigFix][link_bigfix] or [Jamf][link_jamf], + - whole disk encryption using the operating system's native encryption facilities, and + - malware scanning using Crowdstrike Endpoint Antivirus or a similar [Stanford approved and managed anti-malware solution][link_stanford_anti_malware]. - Enable multi-factor authentication on all GitHub accounts used for ROAR development. - For the following following third-party vendors, enable multi-factor authentication and always use a Stanford email for authentication: - Google, GCP, and Firebase @@ -84,19 +146,14 @@ ROAR's Information Security Policy ensures that all sensitive data, including st - Clever - ClassLink - Redivis / Stanford Data Farm + - Use only your `@stanford.edu` email address to conduct ROAR business. +- **Developers, QA Team, and ROAR's Director of Technology and Integration** (in addition to the employee responsibilities above) + - Complete annual information security training from the [Stanford Information Security Academy][link_stanford_sisa] + - Adhere to and enforce the [ROAR software development lifecycle][link_roar_sdlc]. -### Key Security Controls - -- [**Access Control**](#access-control-policy): Role-based access control (RBAC) ensures that only authorized users can access sensitive data. -- [**Encryption**](#encryption-policy): All data is encrypted at rest using AES-256 encryption and in transit using TLS/HTTPS. -- [**Regular monitoring and auditing**](#audit-logging-and-monitoring-policy): ROAR employs regular audits and monitoring of access logs as defined in [Regular monitoring and auditing](#regular-monitoring-and auditing) -- [**Incident Response Plan**](#incident-response-plan): Defined procedures for responding to data breaches. - ---- - -## Access Control Policy +### Access Control -### Role-Based Access Control (RBAC) +#### Role-Based Access Control (RBAC) To protect sensitive data, access to ROAR systems is controlled based on user roles and responsibilities. The ROAR team defines the following roles: @@ -107,125 +164,133 @@ To protect sensitive data, access to ROAR systems is controlled based on user ro - **Researchers**: Access to de-identified data for research purposes. - **Caregivers**: Access to only their students' data for the purpose of viewing assessment scores. - **Participants**: Access to only their own data for the purpose of completing assessments. + +Access to data on Firestore is governed by Firestore security rules, which ensure that data is only accessible to authorized users. There are separate security rules for the [admin database][link_security_rules_admin] and the [assessment database][link_security_rules_assessment]. -### Multi-Factor Authentication (MFA) +#### Authentication -In accodance with minsec, all ROAR employees must use **Stanford Duo Mobile** for multi-factor authentication when accessing privileged accounts. +ROAR uses Firebase Authentication to manage user sign-ins and identity verification across its platform. Firebase Authentication is enhanced with the Google Identity Platform, providing an additional layer of security and flexibility. This integration allows ROAR to support multiple authentication methods, including email/password, OAuth providers (such as Google, Clever, and ClassLink), and anonymous authentication. -### Onboarding and Offboarding +The only password requirement for participants, caregivers, educators, and school and district administrators is a minimum length of six characters. ROAR employees, either in their role as researchers or super administrators, are required to authenticate into the ROAR platform using Google SSO with their Stanford email addresses. This, in turn, uses Stanford's Duo Mobile for multi-factor authentication. -User accounts are created for new employees based on their roles. Access is removed immediately upon termination of employment or change in role. +ROAR users can also authenticate using the Clever or ClassLink SSO providers. For these, ROAR uses the modern and secure OpenID Connect (OIDC) protocol, which is built on top of OAuth 2.0. OIDC is widely adopted for web and mobile applications and is considered a secure and streamlined protocol for identity management. ---- +All ROAR employees have `@stanford.edu` email accounts and use only those accounts to conduct business. In accodance with minsec, all ROAR employees must use **Stanford Duo Mobile** for multi-factor authentication when accessing privileged accounts. + +#### Onboarding and Offboarding -## Encryption Policy +User accounts are created for new employees based on their roles. Access is removed immediately upon termination of employment or change in role. The information security officer is responsible for maintaining both an [onboarding checklist][link_onboarding_checklist] and an [offboarding checklist][link_offboarding_checklist] to ensure access control. ROAR managers are responsible for completing these checklists when employees join or leave the team. + +### Encryption ROAR enforces strict encryption policies to protect sensitive data. All data in transit, either between the ROAR application and users, or between different ROAR storage systems, is encrypted using **TLS/HTTPS**. +When data is transmitted internally between ROAR employees, it is transmitted using secure mail or the Stanford managed, non-consumer Google Drive (described below), which is approved for high-risk data. Data at rest is stored in multiple possible locations. Below, we describe each location along with it's associated encryption policy and key management policy: - **Firebase Firestore** and other **Google Cloud Platform (GCP)** services - Encryption: This data is encrypted using the **AES-256** encryption standard. - - Key management: The encryption keys themselves are encrypted and rotated regularly to ensure security. The management of encryption keys is handled by Google Cloud’s internal processes, which follow strict security protocols. + - Key management: The encryption keys themselves are encrypted and rotated regularly to ensure security. The management of encryption keys is handled by Google Cloud's internal processes, which follow strict security protocols. - **Google Drive** - Description: Data shared between districts and ROAR researchers, especially via CSV file uploads, is often stored in secure, shared Google Drive folders. This data is manually imported by authorized staff into the ROAR platform when necessary, using encrypted communication channels. - Encryption: This data is encrypted using the **AES-256** encryption standard. - - Key management: The encryption keys themselves are encrypted and rotated regularly to ensure security. The management of encryption keys is handled by Google Cloud’s internal processes, which follow strict security protocols. + - Key management: The encryption keys themselves are encrypted and rotated regularly to ensure security. The management of encryption keys is handled by Google Cloud's internal processes, which follow strict security protocols. - Employee-owned or Stanford-owned **encrypted devices**: - - Description: ROAR employees may perform manual file handling with data that is downloaded to and processed on Stanford-managed encrypted devices. Whether this device is employee-owned or Stanford-owned, it's security is managed by Stanford. These devices are required to be registered with Stanford University and approved for use with high-risk data. - - Encryption: Device registration includes enrollment in [Jamf][] and [BigFix][] and whole disk encryption using the operating system's native encryption facilities. + - Description: ROAR employees may perform manual file handling with data that is downloaded to and processed on Stanford-managed encrypted devices. Whether this device is employee-owned or Stanford-owned, it's security is managed by Stanford through [Stanford Device Registration][link_stanford_device_registration]. These devices are required to be registered with Stanford University and approved for use with high-risk data. + - Encryption: Device registration includes enrollment in [Jamf][link_jamf] and [BigFix][link_bigfix] and whole disk encryption using the operating system's native encryption facilities. - Key management: The use of Jamf and BigFix ensure that operating system patches and updates are deployed in a timely manner and that encryption is verified in an ongoing way that can be centrally audited. The encryption keys themselves are managed by each individual employee. - Stanford Data Farm (Redivis) - Description: The [Stanford Data Farm][] is a data storage and analytics platform. It integrates with other ROAR data storage through manual or automated data export from the ROAR assessment Firestore database. It contains assessment results with de-identified data only (i.e., it excludes PII). Access is restricted to authorized ROAR researchers. + Description: The [Stanford Data Farm][link_stanford_data_farm] is a data storage and analytics platform. It integrates with other ROAR data storage through manual or automated data export from the ROAR assessment Firestore database. It contains assessment results with de-identified data only (i.e., it excludes PII). Access is restricted to authorized ROAR researchers. ---- +### Audit Logging and Monitoring -## Incident Response Plan +User activities within the ROAR system are logged to ensure transparency and traceability. +**Login events**, **data access**, and **data modifications** are logged in Firebase audit logs. +IP addresses and device information may be logged for security purposes. Firebase audit logs are retained for 400 days. These logs are monitored as described in the [incident response plan section](#incident-response). -In the event of a data breach or security incident, ROAR follows a detailed incident response process to contain the breach, mitigate damage, and notify affected parties. As ROAR relies on Google Cloud Platform (GCP) and Firebase for its infrastructure, the breach response procedures are aligned with Google's established protocols for handling security incidents. Additionally, ROAR follows Stanford's minimum security (minsec) requirements, which further specify steps for breach management. Here’s an overview of the procedures and response timings: +### Incident Response + +In the event of a data breach or security incident, ROAR follows a detailed incident response process to contain the breach, mitigate damage, and notify affected parties. As ROAR relies on Google Cloud Platform (GCP) and Firebase for its infrastructure, the breach response procedures are aligned with Google's established protocols for handling security incidents. Additionally, ROAR follows Stanford's minimum security (minsec) requirements, which further specify steps for breach management. Here's an overview of the procedures and response timings: 1. Detection and Reporting of a Breach - - Monitoring and Detection: Google Cloud and Firebase utilize automated systems for constant monitoring and logging of all access and activity across their platforms. Any abnormal behavior or access patterns are flagged for immediate review by Google's security teams. + - Monitoring and Detection: Google Cloud and Firebase utilize automated systems for constant monitoring and logging of all access and activity across their platforms. Any abnormal behavior or access patterns are flagged for immediate review by Google's security teams. Further details on Google's intrusion detection measures are available in [Appendix 2, section 1(b) of the Firebase data processing terms][link_firebase_data_processing_terms]. - Incident Reporting: If ROAR detects or suspects a breach (internally or through Google's detection systems), it is required to notify relevant stakeholders, including school districts and partners, per their data use agreements. - - Timing: Immediate detection and notification systems are in place. For suspected breaches, Stanford’s internal policies require that affected parties be informed as soon as possible, typically within 72 hours of detecting the issue. -1. Initial Response and Containment - - Initial Assessment: Once a breach is suspected or confirmed, the vendor (Google Cloud, in this case) initiates an immediate investigation to assess the scope and impact of the incident. At the same time, ROAR’s internal team would begin containment procedures, including suspending access or isolating affected systems. - - Containment Measures: GCP’s infrastructure provides automated tools to block further unauthorized access, including halting affected services, rotating encryption keys, or revoking compromised credentials. - - Timing: Containment actions are typically initiated within hours of detecting the breach. + - Timing: Immediate detection and notification systems are in place. For suspected breaches, Stanford's internal policies require that suspected breaches are reported immediately to the University's Information Security Office. +1. Initial Notification, Response, and Containment + - Initial Assessment: Once a breach is suspected or confirmed, the vendor (Google Cloud, in this case) initiates an immediate investigation to assess the scope and impact of the incident. At the same time, ROAR's internal team would begin containment procedures, including suspending access and isolating affected systems. + - Suspected information security incidents are reported immediately to the Stanford University Privacy Office and Information Security Office. Following those reports, Stanford follows its [information security incident response][link_stanford_infosec_incident_response]. + - Containment Measures: GCP's infrastructure provides automated tools to block further unauthorized access, including halting affected services, rotating encryption keys, or revoking compromised credentials. 1. Investigation and Root Cause Analysis - - Forensic Analysis: Google’s security team works on identifying the root cause of the breach using forensic tools to trace the source and scope of the compromise. They examine logs, system changes, and any unauthorized access points. - - ROAR Team’s Role: The ROAR team collaborates with Google to provide context for the incident and ensure Stanford’s data is safeguarded. ROAR's internal team, governed by Stanford’s security policies, plays a key role in determining what data, if any, has been compromised. - - Timing: The investigation process can take 24 to 72 hours, depending on the complexity of the breach. + - Forensic Analysis: Google's security team works on identifying the root cause of the breach using forensic tools to trace the source and scope of the compromise. They examine logs, system changes, and any unauthorized access points. + - ROAR Team's Role: The ROAR team collaborates with Google to provide context for the incident and ensure Stanford's data is safeguarded. ROAR's internal team, governed by Stanford's security policies, plays a key role in determining what data, if any, has been compromised. 1. Notification of Affected Parties - - Stakeholder Notification: In the event that personally identifiable information (PII) or sensitive information is compromised, ROAR, following Stanford’s minsec requirements, would notify affected school districts and individuals. The notification includes the type of data affected, the estimated scope, and steps taken to mitigate further risk. - - Timing: Stakeholders are notified within 72 hours of confirming the breach. + - Stakeholder Notification: In the event that personally identifiable information (PII) or sensitive information is compromised, ROAR, following Stanford's minsec requirements and any data usage agreements that ROAR has signed with affected parties, would notify affected school districts and individuals. The notification includes the type of data affected, the estimated scope, and steps taken to mitigate further risk. 1. Remediation and Recovery - - Remediation Plan: Once the breach is contained, the vendor (Google Cloud) and ROAR initiate a remediation process, which may involve restoring systems from secure backups, reconfiguring security settings, or enhancing system defenses to prevent future occurrences. - - Data Restoration: Any lost or corrupted data is restored from encrypted backups maintained on Google Cloud’s infrastructure, and system integrity is verified before returning services to normal operation. - - Timing: Depending on the severity, the recovery process can take between 24 hours to several days. + - Remediation Plan: Once the breach is contained, the vendor (e.g., Google Cloud) and ROAR initiate a remediation process, which may involve restoring systems from secure backups, reconfiguring security settings, or enhancing system defenses to prevent future occurrences. + - Data Restoration: Any lost or corrupted data is restored from encrypted backups maintained on Google Cloud's infrastructure, and system integrity is verified before returning services to normal operation. + - Remediative modifications to the ROAR platform are not deployed until after Stanford's Information Security Office has completed its investigation and authorizes such activity. 1. Post-Incident Review and Reporting - - Post-Mortem Analysis: After the issue is fully resolved, ROAR and Google Cloud perform a post-mortem analysis to identify lessons learned and implement additional security measures where needed. This analysis is shared with relevant parties if necessary. + - Post-Mortem Analysis: After the issue is fully resolved, ROAR, in concert with Stanford's Information Security Incident Response Team and Google Cloud, perform a post-mortem analysis to identify lessons learned and implement additional security measures where needed. This analysis is shared with relevant parties if necessary. - Reporting: ROAR provides a detailed report to stakeholders (e.g., school districts) on the nature of the breach, the steps taken to mitigate it, and the corrective actions to prevent future incidents. - - Timing: The post-incident report is generally provided within two weeks of the breach being fully resolved. - -Key Timing Overview: -- Detection/Initial Notification: Immediate; stakeholders notified within 72 hours. -- Containment: Within hours of breach detection. -- Investigation: Completed within 24 to 72 hours. -- Full Remediation and Recovery: Can take 1-5 days, depending on complexity. -- Post-Incident Report: Delivered within two weeks. - -### Response Steps - -1. **Detection**: Incidents are detected through automated monitoring and user reports. -1. **Containment**: Immediate actions are taken to limit exposure (e.g., disabling compromised accounts). -1. **Investigation**: Forensic analysis is conducted to identify the root cause and affected data. -1. **Notification**: Affected users and regulatory authorities are notified within 72 hours, as required by law. -1. **Remediation**: Systems are restored, and security controls are strengthened to prevent future incidents. - ---- - -## Audit Logging and Monitoring Policy - -All user activities within the ROAR system are logged to ensure transparency and traceability. - -### Logging - -- **Login events**, **data access**, and **data modifications** are logged in Firebase audit logs. -- IP addresses and device information may be logged for security purposes. - -### Monitoring - -> TODO: How long are logs maintained -> TODO: Add information about GCP monitoring -> TODO: Add information about ROAR monitoring - ---- +### Vulnerability Scanning - +The third-party penetration testers will provide a detailed report on the findings, including any vulnerabilities identified and their associated risk levels (e.g., low, medium, high, critical). +ROAR will prioritize remediation of identified vulnerabilities based on severity, with high and critical issues addressed immediately. +A post-test review will be conducted to verify that all issues have been adequately resolved before any affected systems are brought back online. -## Security Certifications +### Security Certifications and third-party vendor assessments ROAR operates on Google Cloud Platform (GCP) and Firebase, which are certified under various security standards including FedRAMP Moderate, SOC 2 Type II, and ISO/IEC 27001. These platforms provide the secure infrastructure that underpins ROAR's operations, ensuring that data is stored and processed in a compliant, secure environment. We provide details below on GCP and Firebase compliance with those standards. - FedRAMP Certification: - FedRAMP Level: Google Cloud Platform and Firebase are FedRAMP Moderate certified. - - Environment: ROAR is hosted in Google Cloud Platform’s nam5 multi-region, which complies with FedRAMP requirements for government data protection. + - Environment: ROAR is hosted in Google Cloud Platform's nam5 multi-region, which complies with FedRAMP requirements for government data protection. - Security Controls: The certification includes compliance with over 325 security controls based on NIST SP 800-53, which covers areas such as access control, incident response, data encryption, and continuous monitoring. - Why This Matters: FedRAMP Moderate certification ensures that GCP meets strict U.S. federal security requirements, including those related to confidentiality, integrity, and availability of cloud services. - SOC 1/2/3 Reports: @@ -241,86 +306,64 @@ However, it is important to note that ROAR itself does not hold these security c The **Information Security Officer is responsible** for ensuring that all ROAR third-party vendors, such as Google Cloud Platform, Clever, and ClassLink, maintain **SOC 2 Type II** or **ISO 27001** certifications. For each vendor, the Information Security Officer shall generate a third-party vendor assessment report that assesses the security practices of the vendor and verifies compliance with the above privacy and security standards. The Information Security Officer shall review these vendor assessments quarterly. ---- - -## Employee Training and Awareness Documentation - -> TODO: Review this +### Employee Training ROAR requires all employees and contractors to complete regular training on data privacy and information security best practices. +All ROAR employees that access participant data must complete the "CITI Biomedical Responsible Conduct of Research" training and training on the Health Insurance Portability and Accountability Act (HIPAA) to protect PII. Additionally, all ROAR developers complete annual information security training from the [Stanford Information Security Academy][link_stanford_sisa], covering the importance of PII protection, the specifics of our data privacy policies, and their roles in maintaining these standards. -### Training Program - -- **Initial Training**: All new employees must complete security training within 30 days of hire. -- **Annual Training**: Refresher courses covering changes to security policies and new threats. -- **Role-Specific Training**: Specialized training for roles with elevated access to sensitive data. - ---- - -## Security Risk Assessments - -ROAR conducts periodic security risk assessments to identify vulnerabilities and implement corrective actions. - -### Vulnerability Scanning - -> TODO: Add information on Qualys vulnerability scanning - -### Penetration Testing +### Software Development Lifecycle Security Controls -> TODO: Add information on pen testing +ROAR enforces secure [Software Development Lifecycle (SDLC) policies][link_roar_sdlc] that govern how software changes are managed, implemented, and deployed. The SDLC process ensures that changes to the system are tracked, reviewed, tested, and implemented in a manner that prioritizes security, confidentiality, and compliance with industry best practices. +All ROAR software developers, including ROAR assessment developers, are responsible for complying with the [ROAR SDLC][link_roar_sdlc]. --- -## Business Continuity and Disaster Recovery Plan +## Operational Security and Resilience -> TODO: Fix this - -ROAR maintains a disaster recovery plan to ensure the availability of services in case of system outages or disasters. +Operational security and resilience refers to the measures and processes in place to ensure that ROAR can maintain business continuity, recover from unexpected disruptions, and protect the integrity and availability of its data. This section focuses on how ROAR safeguards critical data and infrastructure, ensures swift recovery in the event of failures or disasters, and maintains operational continuity under various circumstances. ### Backup and Restoration -- **Data Backups**: Regular backups of all critical data are stored securely in Google Cloud’s geographically redundant storage. -- **Recovery Time Objective (RTO)**: ROAR aims to restore services within 24 hours of an outage. - ---- - -## Data Flow Diagrams (DFDs) - -ROAR maintains detailed data flow diagrams that describe how data moves through the system. - -> TODO: link to the DFDs - -[stanford-minsec]: https://uit.stanford.edu/guide/securitystandards#security-standards-applications -[Jamf]: https://uit.stanford.edu/service/StanfordJamf -[BigFix]: https://uit.stanford.edu/service/bigfix -[Stanford Device Registration]: https://uit.stanford.edu/service/registration -[Stanford Data Farm]: https://redivis.com/Stanford - -> TODO: Add information on auth and using the identity platform. +ROAR uses comprehensive backup and restoration processes to ensure the continuity of critical data and services in the event of a system failure, data corruption, or other disruption. +All backups are encrypted to maintain data confidentiality and protect sensitive information. +ROAR's **Recovery time objective (RTO)** is to restore services within 72 hours of an outage. -While ROAR does not use SAML 2.0, we provide a modern and secure Single Sign-On (SSO) solution through OpenID Connect (OIDC), which is built on top of OAuth 2.0. OIDC is widely adopted for web and mobile applications and is considered a secure and streamlined protocol for identity management. This is the protocal that we use for integrating with SSO providers like Clever and ClassLink. This solution offers the same high level of security and ease of integration as SAML, with the added flexibility and simplicity of the OAuth framework. +#### Firestore Database Backup -## Software Development Lifecycle Security Controls +All Firestore backups are encrypted at rest using industry-standard encryption protocols to ensure that sensitive data remains protected during the retention period. ROAR backs up its production databases into Google Cloud's geographically redundant storage according to two schedules: -All ROAR software developers, including ROAR assessment developers, must adhere to the following security controls: +- Daily Backups: ROAR's production databases are automatically backed up on a daily basis. These daily backups are encrypted to ensure that sensitive information remains secure. Daily backups are retained for one week before they are overwritten. +- Weekly Backups: In addition to daily backups, ROAR performs weekly backups of the database. These weekly backups are retained for 14 weeks, providing an extended archive in case of longer-term recovery needs. -1. **Access Control** Access to GitHub must be performed using two-factor authentication and is restricted to authorized personnel. -1. **Code Review** Code changes must be reviewed and approved in order to progress through the software development life cycle (SDLC) and deploy a version to production. -1. **Code Vulnerability Scanning**: Vulnerability scans for the source code are performed to identify security issues. High/critical issues are remediated in a timely manner. -1. **Automated Tests**: A successful test result is mandatory in order to continue with the SLDC and deploy a version to the production environment. -1. **Test Failure**: In case test failures are detected, a notification is sent to relevant stakeholders. Any code change with a failed test cannot be deployed into production. -1. **Change Approval**: All code changes need to be approved/authorized, prior to being deployed into production. +If the Firestore database becomes unavailable or data is corrupted, the most recent uncorrupted backup is restored following [Firebase's restoration protocols][link_firestore_restoration]. Restoration can be performed from either the daily or weekly backups, depending on the specific recovery needs and the time elapsed since the incident. -## 6. Data Retention and Destruction Policy +#### Codebase Backup and Restoration -### Data Retention +The ROAR codebase, including all application components and infrastructure-as-code scripts, is stored and maintained in GitHub repositories. GitHub acts as the primary system for version control and code storage, providing built-in redundancy and security features. -- Student PII and assessment data are retained only as long as necessary for educational and research purposes. -- Data required for compliance with legal obligations will be retained for a minimum duration as mandated by applicable laws. +- GitHub Version Control: All code changes are tracked using GitHub's version control system, ensuring that code can be restored to any previous state. Each commit serves as a snapshot, and branches are protected to ensure only authorized changes are merged into production. +- Disaster Recovery: In the event of code corruption or accidental deletion, ROAR's GitHub repositories allow for quick restoration by reverting to a previous commit or tag. The decentralized nature of GitHub ensures that the codebase is backed up across multiple locations and systems. This restoration process follows the same security controls described in [ROAR's SDLC](#software-development-lifecycle-security-controls). -### Data Destruction +### Business Continuity and Disaster Recovery -- Data no longer required is securely deleted, using cryptographic wiping for electronic records. -- Paper records are shredded. +ROAR maintains a disaster recovery plan to ensure the availability of services in case of system outages or disasters. Further details are in the [ROAR Business Continuity and Disaster Recovery Plan][link_roar_bcdr]. -> TODO: Add onboarding/offboarding checklist info +[link_bigfix]: https://uit.stanford.edu/service/bigfix +[link_firebase_data_processing_terms]: https://firebase.google.com/terms/data-processing-terms#appendix-2:-security-measures +[link_firestore_release_notes]: https://cloud.google.com/firestore/docs/release-notes +[link_firestore_restoration]: https://firebase.google.com/docs/firestore/backups#restore_data_from_a_database_backup +[link_jamf]: https://uit.stanford.edu/service/StanfordJamf +[link_offboarding_checklist]: https://github.com/yeatmanlab/roar-infosec/blob/main/employee-lifecycle/onboarding-checklist.md +[link_onboarding_checklist]: https://github.com/yeatmanlab/roar-infosec/blob/main/employee-lifecycle/onboarding-checklist.md +[link_owasp_top10]: https://owasp.org/www-project-top-ten/ +[link_roar_bcdr]: https://github.com/yeatmanlab/roar-infosec/blob/main/roar-bcdr.pdf +[link_roar_dfd]: https://miro.com/app/board/uXjVNY-_qDA=/?share_link_id=967374624080 +[link_roar_sdlc]: https://github.com/yeatmanlab/roar-infosec/blob/main/roar-sdlc.pdf +[link_security_rules_admin]: https://raw.githubusercontent.com/yeatmanlab/roar-dashboard/main/firebase/admin/firestore.rules +[link_security_rules_assessment]: https://raw.githubusercontent.com/yeatmanlab/roar-dashboard/main/firebase/assessment/firestore.rules +[link_stanford_anti_malware]: https://uit.stanford.edu/software/antimalware +[link_stanford_data_farm]: https://redivis.com/Stanford +[link_stanford_device_registration]: https://uit.stanford.edu/service/registration +[link_stanford_infosec_incident_response]: https://adminguide.stanford.edu/chapters/computing/information-security-incidents/information-security-incident-response +[link_stanford_minsec]: https://uit.stanford.edu/guide/securitystandards#security-standards-applications +[link_stanford_sisa]: https://uit.stanford.edu/sisa diff --git a/github-templates/security-review.md b/github-templates/security-review.md new file mode 100644 index 0000000..2e16b54 --- /dev/null +++ b/github-templates/security-review.md @@ -0,0 +1,43 @@ +# Security Review Checklist + +## Authentication and Authorization + +- [ ] The change does not bypass existing authentication and authorization mechanisms. +- [ ] The change adheres to least privilege principles (e.g., ensuring minimum access rights). + +## Data Handling and Confidentiality + +- [ ] All sensitive data (e.g., PII, passwords, API keys) is handled securely. +- [ ] Proper encryption methods used for data at rest and in transit (e.g., TLS/HTTPS, AES-256). +- [ ] The change avoid exposing sensitive data through logs, error messages, or URLs. + +## Input Validation and Output Encoding + +- [ ] All inputs are properly validated and sanitized to prevent injection attacks (e.g., SQL Injection, XSS). +- [ ] All outputs are properly encoded to avoid data leaks or injection risks. + +## Error Handling and Logging + +- [ ] Error messages are sanitized to prevent exposing system details. +- [ ] Security-related events are logged properly (e.g., failed login attempts, access control violations). +- [ ] Logging is aligned with data privacy regulations (e.g., no logging of sensitive data). + +## Dependencies and Vulnerabilities + +- [ ] All third-party libraries and dependencies have been checked for known vulnerabilities (via tools like Dependabot or CodeQL). +- [ ] Dependencies are up to date. + +## Access Control + +- [ ] New changes are aligned with existing access control policies (e.g., Role-Based Access Control). +- [ ] The change ensures that users can only access resources and data they are permitted to access. + +## Security Impact Assessment + +- [ ] The potential impact of this change on overall system security been evaluated. +- [ ] The change does not introduce any new attack vectors or security risks. + +## Compliance Check + +- [ ] This change complies with ROAR's existing data protection regulations. +- [ ] The change does not introduce any new compliance considerations. diff --git a/roar-bcdr.md b/roar-bcdr.md new file mode 100644 index 0000000..fa0615e --- /dev/null +++ b/roar-bcdr.md @@ -0,0 +1,92 @@ +--- +title: "ROAR Business Continuity and Disaster Recovery" +subject: "ROAR Business Continuity and Disaster Recovery" +keywords: [ROAR, Business Continuity, Disaster Recovery] +lang: "en" +... + +**Version**: `{{ version }}`\ +**Last Updated by Commit**: `{{ commit }}`\ +**Last updated on**: `{{ commit_date }}` + +> Note: This document is in draft form and is not currently enforced. + +The Business Continuity and Disaster Recovery (BC/DR) Plan for ROAR outlines the processes and strategies in place to ensure the continuation of critical operations and the rapid recovery of essential services in the event of a disruption. The plan is designed to address a range of potential disruptions, including system failures, security incidents, natural disasters, and other unforeseen events that could impact ROAR's ability to provide its services. + +The goal of the BC/DR plan is to minimize downtime, protect the integrity of data, and ensure that ROAR can continue to meet its obligations to educational partners, researchers, and other stakeholders. + +1. Business Continuity Strategy + + The business continuity strategy focuses on maintaining essential services during disruptions and ensuring that ROAR can operate effectively even under adverse conditions. Key components of the strategy include: + + - Critical Service Identification: Identifying the critical services that must be maintained for ROAR to function. These services include: + + - Access to ROAR’s platform for users (students, teachers, and administrators). + - Data availability for research and reporting purposes. + - Security controls to protect personal data and comply with privacy regulations. + + - Priority Levels: ROAR's services are classified into priority levels based on their criticality: + + - High-Priority Services: Services that must remain operational with minimal downtime, such as the core platform, data access for partners, and security monitoring systems. + - Medium-Priority Services: Services that can withstand limited interruptions but must be restored within a specified time frame, such as non-essential reporting tools or background data processing. + - Low-Priority Services: Services that can be temporarily paused during a crisis without immediate impact, such as development environments or non-critical internal tools. + + - Alternate Operations Plan: In the event of a major disruption, alternative operational processes may be implemented, including: + + - Rerouting essential services to secondary infrastructure or cloud environments. + - Temporarily reducing non-critical operations to focus on restoring high-priority services. + +1. Disaster Recovery Plan + + The disaster recovery plan focuses on restoring normal operations as quickly as possible following a disruption. The plan ensures that ROAR can recover from hardware failures, system outages, cyberattacks, or other emergencies that could affect service availability. + + Key Elements of the Disaster Recovery Plan include: + + - Incident Response Coordination: In the event of a disaster, the incident response team will be activated to assess the scope of the disruption and implement the disaster recovery plan. This team is responsible for: + + - Coordinating the initial response. + - Communicating with stakeholders. + - Implementing restoration procedures. + + - Disaster Recovery Teams and Roles: + + - Incident Response Lead: Oversees the overall response effort, assesses the severity of the incident, and activates the disaster recovery plan. + - Technical Recovery Team: Responsible for restoring the affected infrastructure, including servers, databases, and network components. + - Communications Lead: Manages communication with internal teams, educational partners, and other stakeholders to ensure timely and transparent updates. + - Data Integrity Officer: Ensures the integrity and security of data throughout the recovery process and works with the backup and restoration teams to validate data post-recovery. + + - Disaster Scenarios: The plan covers a variety of potential disaster scenarios, including: + + - System Failures: Hardware or software malfunctions that cause a loss of service. + - Cyberattacks: Ransomware attacks, data breaches, or other malicious actions that disrupt service or compromise data. + - Natural Disasters: Floods, fires, or other physical events that could damage infrastructure or data centers. + + - Recovery Time Objective (RTO): ROAR aims to restore critical services within 24 hours of a major disruption. Non-critical services may take up to 72 hours to fully restore. + + - Recovery Point Objective (RPO): ROAR’s objective is to recover data up to the point of the last successful backup. This ensures minimal data loss in the event of a system failure or other disaster. + +1. Communication and Reporting Protocols + + Clear communication is critical during a disaster or significant disruption. ROAR’s BC/DR plan includes the following communication protocols: + + - Internal Communication: Immediate notification to internal teams and key stakeholders about the nature and scope of the disruption. Regular updates are provided throughout the recovery process. + - External Communication: ROAR will notify educational partners, researchers, and users in the event of a disruption that affects service delivery. These notifications will provide details on the nature of the incident, expected recovery times, and any potential impact on data or services. + - Post-Recovery Reports: Once normal operations are restored, a detailed post-recovery report will be prepared. This report will include an assessment of the incident, the effectiveness of the recovery efforts, any data that was affected, and actions taken to prevent future incidents. + +1. Testing and Updating the BC/DR Plan + + To ensure the effectiveness of the BC/DR plan, ROAR regularly conducts disaster recovery drills and business continuity simulations. These tests are conducted at least annually and involve: + + - Simulating various disaster scenarios. + - Testing the recovery of critical systems. + - Evaluating the response time and coordination among recovery teams. + + Additionally, the BC/DR plan is reviewed and updated as necessary to reflect changes in infrastructure, technology, or organizational priorities. Any lessons learned from real incidents or test exercises are incorporated into the plan to improve future responses. + +1. Dependencies on Third-Party Services + + ROAR relies on several third-party services, including cloud infrastructure and security monitoring tools, to maintain its operations. As part of the BC/DR plan, ROAR ensures that: + + - Service Level Agreements (SLAs) with third-party vendors include clear recovery time commitments. + - Third-party vendors have their own disaster recovery and business continuity plans that align with ROAR’s requirements for service restoration. + - Continuous monitoring of third-party services is in place to detect potential disruptions and coordinate responses as needed. diff --git a/roar-sdlc.md b/roar-sdlc.md new file mode 100644 index 0000000..2458fcd --- /dev/null +++ b/roar-sdlc.md @@ -0,0 +1,115 @@ +--- +title: "ROAR Software Development Lifecycle Policies and Procedures" +subject: "ROAR Software Development Lifecycle" +keywords: [Software development lifecycle, ROAR] +lang: "en" +... + +**Version**: `{{ version }}`\ +**Last Updated by Commit**: `{{ commit }}`\ +**Last updated on**: `{{ commit_date }}` + +## Overview + +The secure Software Development Lifecycle (SDLC) at ROAR outlines the procedures, policies, and security measures that govern how software changes are managed, implemented, and deployed within the ROAR platform. The SDLC process ensures that changes to the system are tracked, reviewed, tested, and implemented in a manner that prioritizes security, confidentiality, and compliance with industry best practices. + +Changes to ROAR are managed via GitHub, where GitHub Issues, Projects, and Pull Requests serve as the core tools for ticketing, prioritizing, and tracking change requests throughout the SDLC process. + +## Environment Segregation + +To maintain the integrity, security, and stability of the ROAR platform, separate environments are used throughout the SDLC process. + +- Emulated Environment: This ephemeral environment exists only on ROAR developers' local machines during development. +- Development Environment: Used by developers for implementing and testing code changes. +- Staging Environment: A controlled environment where QA testing occurs, and the security review is conducted. +- Production Environment: The live environment where only authorized personnel can deploy changes. Developers do not have direct access to this environment. + +Environment segregation ensures that development, testing, and production activities occur in isolated, controlled spaces. This approach minimizes the risk of unauthorized changes, enhances the accuracy of testing, and protects the production environment from potential disruptions. + +## Roles and Responsibilities + +The ROAR development team comprises the following roles: + +- Developer: Responsible for developing the changes according to specifications in the ticket and ensuring all tests pass. +- QA Team: Responsible for testing the change in the Staging environment. +- Information Security Officer: Responsible for reviewing the [security checklist][link_security_checklist] and ensuring the change meets all security and compliance requirements. +- Director of Technology and Integration: Responsible for authorizing and approving changes before deployment to the production environment. + +## SDLC Process + +The following steps outline the full SDLC process for managing code changes: + +1. Request and Documentation: + + - Any change, whether a new feature requests or a bug fix, begins with the creation of a ticket. + - Tickets are logged and prioritized using GitHub Issues in the centralized [ROAR repository][link_roar_issues]. Each ticket should document the required change, the impact of the change, and any relevant security, confidentiality, and privacy considerations. + - ROAR maintains issue templates to assist issue authors in providing required information. + +1. Change Development: + + - Code changes are first developed in either the Emulated environment (local developer machines) or the Development environment. + - Before changes can be merged into the main branch, they must: + 1. Pass automated tests that run in either the Emulated or Development environment to ensure code correctness. + 1. Pass automated security vulnerability scanning managed by GitHub's CodeQL tool. + 1. Undergo a line-by-line code review by at least two authorized developers. + 1. Pass acceptance testing that validates the relevant behavior of the feature or bug fix. + - Once the above steps are completed, the code can be merged into the main branch via a pull request. + - After merging, the code is automatically deployed to the Staging environment for further testing. + +1. Change Testing: + + In the staging environment, changes undergo + - Quality Assurance (QA) testing to validate functionality and performance. + - A [security review][link_security_checklist] to assess potential impacts on security, confidentiality, and privacy. + - Automated pre-deployment tests that verify the code’s readiness for production. + Vulnerabilities must be addressed before changes can move from staging to production. + +1. Change Approval and Deployment: + + - Approval for code changes is required before they can be merged into production. + - The ROAR Director of Technology and Integration or their designee reviews and authorizes changes. Individual developers cannot deploy code directly to the production environment. + - Approval is recorded by minting a new version number tag and release on GitHub. These actions then trigger deployment through GitHub actions. + +1. Post-Deployment Monitoring: + + Once in production, changes are monitored to ensure the system operates as expected, with a focus on identifying any security or operational issues that may arise. + +## Security Controls + +The SDLC process integrates the following security controls to ensure the safety and integrity of the ROAR platform: + +1. Access Control + + Access to ROAR GitHub repositories is restricted to authorized personnel only. All users must use two-factor authentication (2FA). + +1. Code Review + + - All pull requests must undergo code review before being merged into the master branch. + - ROAR repositories are configured to enforce code reviews by designated code owners. Code cannot be merged without an approving review. + +1. Code Vulnerability Scanning + + - CodeQL scanning is integrated into GitHub to detect vulnerabilities and coding errors in the source code. + - Dependency Review via GitHub's Dependabot tool automatically detect vulnerabilities in third-party dependencies. + - High or critical issues must be remediated before a change can proceed through the SLDC. + +1. Automated Tests + + - Automated tests are run via GitHub Actions for each pull request. These tests include: + - Code linters to check for style and formatting issues. + - Security checks to ensure the codebase remains free from vulnerabilities. + - Functional tests to verify code correctness. + - All tests must pass before proceeding to the next stage in the SDLC process. + - Branch protection rules are applied to prevent merging changes with failed tests. + +1. Change Approval + + - All code changes must be approved by the ROAR Director of Technology and Integration or a designated reviewer. + - Approval is required before deploying the change to production. + +## Conclusion + +The ROAR Secure SDLC process ensures that all code changes are properly documented, tested, and reviewed, with security considerations integrated into each step of the lifecycle. By maintaining rigorous access controls, automated testing, vulnerability scanning, and structured approval processes, ROAR can protect the integrity and security of its platform throughout development and deployment. + +[link_roar_issues]: https://github.com/yeatmanlab/roar/issues +[link_security_checklist]: https://github.com/yeatmanlab/roar-infosec/blob/main/github-templates/security-review.md