From 40e06a1ac7cb9292ec97de9272a210d73aedd6aa Mon Sep 17 00:00:00 2001 From: RamGcia <146842429+RamGcia@users.noreply.github.com> Date: Wed, 13 May 2026 19:12:31 +1000 Subject: [PATCH] ISMS upload for docusaurus ISMS aligned with ISO27001:2022 --- .../RO-AUD-001-Internal-Audit-Checklist.md | 49 +++++ ...CL-001-Onboarding-Offboarding-Procedure.md | 151 +++++++++++++ .../RO-GA-001-Gap-Analysis.md | 73 +++++++ .../RO-ISMS-001-Scope-Statement.md | 47 ++++ .../RO-POL-001-Information-Security-Policy.md | 79 +++++++ .../RO-POL-002-Access-Control-Policy.md | 176 +++++++++++++++ .../RO-POL-003-Acceptable-Use-Policy.md | 190 ++++++++++++++++ .../RO-POL-004-Incident-Response-Policy.md | 205 ++++++++++++++++++ .../RO-POL-005-Secure-Development-Policy.md | 168 ++++++++++++++ .../RO-POL-006-Data-Handling-Policy.md | 128 +++++++++++ .../RO-SOA-001-Statement-of-Applicability.md | 157 ++++++++++++++ 11 files changed, 1423 insertions(+) create mode 100644 docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-AUD-001-Internal-Audit-Checklist.md create mode 100644 docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-CL-001-Onboarding-Offboarding-Procedure.md create mode 100644 docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-GA-001-Gap-Analysis.md create mode 100644 docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-ISMS-001-Scope-Statement.md create mode 100644 docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-001-Information-Security-Policy.md create mode 100644 docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-002-Access-Control-Policy.md create mode 100644 docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-003-Acceptable-Use-Policy.md create mode 100644 docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-004-Incident-Response-Policy.md create mode 100644 docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-005-Secure-Development-Policy.md create mode 100644 docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-006-Data-Handling-Policy.md create mode 100644 docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-SOA-001-Statement-of-Applicability.md diff --git a/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-AUD-001-Internal-Audit-Checklist.md b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-AUD-001-Internal-Audit-Checklist.md new file mode 100644 index 00000000..17576599 --- /dev/null +++ b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-AUD-001-Internal-Audit-Checklist.md @@ -0,0 +1,49 @@ +# Internal Audit Checklist + +## Redback Operations – ISO27001:2022 ISMS + +| **Document Code** | RO – AUD – 001 | +| --- | --- | +| **Version** | 1.0 | +| **Review Interval** | Start of Each Trimester | +| **Document Owner** | Ethics / GRC Team | +| **ISO Reference** | ISO/IEC 27001:2022 – Clause 9.2 | +| **Conducted by** | | +| **Date Conducted** | | + +--- + +## Purpose + +This checklist is to verify that the information security controls established in the ISMS are active and functioning per trimester. Results should be recorded and any failures or partial responses should be registered in the Gap Analysis. + +## Utilisation of Internal Audit Checklist + +- Work through each audit question and mark Yes, No or Partial +- For any No or Partial response, document findings in Evidence / Notes column and add to the Gap Analysis for it to be identified and rectified. +- Internal Audit Checklist should be stored with the rest of the ISMS suite. +- Audit should be completed independently by a member of the Ethics / GRC Team Member or Leader. + +## Audit Questions + +| **#** | **Control Area** | **Audit Question** | **Yes / No / Partial** | **Evidence / Notes** | +| --- | --- | --- | --- | --- | +| **1** | Access Control | Has a GitHub membership review been conducted this trimester? Are all members current enrolled students or authorised tutors? | ☐ Yes ☐ No ☐ Partial | | +| **2** | Access Control | Has MFA been confirmed as enabled for all active members across GitHub, Microsoft Entra ID, and HiveMQ within 5 days of enrolment? | ☐ Yes ☐ No ☐ Partial | | +| **3** | Access Control | Have all members from the previous trimester had their GitHub access, PATs, and platform access revoked as per the offboarding procedure? | ☐ Yes ☐ No ☐ Partial | | +| **4** | Access Control | Are repository access permissions restricted to team members only, with admin access limited to SecDevOps, tutors, and team leads? | ☐ Yes ☐ No ☐ Partial | | +| **5** | Vulnerability Management | Are Dependabot alerts active across all repositories? Have alerts from the previous trimester been reviewed and actioned by SecDevOps? | ☐ Yes ☐ No ☐ Partial | | +| **6** | Vulnerability Management | Is the Trivy scanner workflow active and running on all active repositories? Are code scanning alerts being reviewed before merges? | ☐ Yes ☐ No ☐ Partial | | +| **7** | Secure Development | Are branch protection rules enabled on all active repository main branches? Is pull request review enforced before any merge? | ☐ Yes ☐ No ☐ Partial | | +| **8** | Secure Development | Has a check been performed to confirm no hardcoded credentials, API keys, or PII are present in any active repository? | ☐ Yes ☐ No ☐ Partial | | +| **9** | Incident Management | Has the Incident Register been reviewed? Are all incidents from the previous trimester documented with resolution status recorded? | ☐ Yes ☐ No ☐ Partial | | +| **10** | Policy Compliance | Have all active members acknowledged and read the ISMS policies (AUP, ACP, IRP) as part of their onboarding this trimester? | ☐ Yes ☐ No ☐ Partial | | +| **11** | Policy Compliance | Have all ISMS documents been reviewed and updated to reflect the current trimester including effective dates, team names, and member counts? | ☐ Yes ☐ No ☐ Partial | | +| **12** | Asset Management | Has the Asset Register been reviewed and updated this trimester? Are all active assets documented with correct owners and classification? | ☐ Yes ☐ No ☐ Partial | | +| **13** | Risk Management | Has the Risk Register been reviewed this trimester? Have new risks been added and treatment statuses updated from the previous trimester? | ☐ Yes ☐ No ☐ Partial | | +| **14** | Security Awareness | Have security awareness briefings been conducted with all 8 teams this trimester? Is attendance documented? | ☐ Yes ☐ No ☐ Partial | | +| **15** | ISMS Documents | Are all ISMS documents stored in the shared GitHub repository or Docusaurus wiki, not on personal drives and accessible to all current members? | ☐ Yes ☐ No ☐ Partial | | + +## Document Review + +This checklist is to be reviewed and updated at the start of each trimester to reflect any additional controls, policies or systems to the ISMS. Questions are to be added or removed based on the findings from the previous Gap Analysis diff --git a/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-CL-001-Onboarding-Offboarding-Procedure.md b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-CL-001-Onboarding-Offboarding-Procedure.md new file mode 100644 index 00000000..f56c1bd5 --- /dev/null +++ b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-CL-001-Onboarding-Offboarding-Procedure.md @@ -0,0 +1,151 @@ +# Onboarding & Offboarding Procedure + +## Redback Operations – ISO27001:2022 ISMS + +| **Document Code** | RO – CL – 001 | +| --- | --- | +| **Version** | 1.0 | +| **Document Owner** | Ethics / GRC Team | +| **ISO27001 Reference** | Annex A Controls 5.16, 5.17, 5.18, 6.1 , 6.2, 6.4, 6.5 | +| **Review Interval** | Start of each Trimester | + +--- + +## Purpose + +This procedure dictates the step-by-step process needed for onboarding new students into Redback Operations and offboarding concluding students at the end of their SIT378 Capstone Team Project (B) enrolment. All access to systems is approved and revoked in a documented and managed manner through this policy. This policy is created due to Redback Operations' nature of trimester-based student rotation. + +## Scope + +This procedure is applicable to: + +- Students who are joining Redback Operations at the start of the trimester. +- Students who are leaving Redback Operations at the end of their enrolment within the unit. +- All systems that the students are given access to. +- Ethics / GRC Team to maintain access records. + +## Roles and Responsibilities + +| **Role** | **Responsibilities** | +| --- | --- | +| **Ethics / GRC Team** | Maintain the Access Register; document all onboarding and offboarding events; conduct trimester access reviews; ensure this procedure is practiced and followed | +| **Team Leads** | Submit access requests for new members; brief new members on security policies; initiate offboarding for departing members; confirm access revocation is complete | +| **Blue Team** | Manage Microsoft Entra ID provisioning and revocation; confirm Entra ID access is removed on offboarding | +| **SecDevOps Team** | confirm GitHub access is removed on offboarding | +| **All Members** | Notify team lead immediately if they become aware of stale or unauthorised accounts; delete local project data on offboarding; complete security briefing during onboarding | + +## Onboarding + +The following checklist must be completed for every new student joining Redback Operations. Team leads need to initiate the checklist within 3 business days of when leadership is established and student is confirmed within their team. All completed checklists must be filed with the Ethics / GRC Team. + +### Before Access + +| **#** | **Task — Before Access Is Granted** | **Responsible** | **Done ✓** | +| --- | --- | --- | --- | +| **1** | Team lead confirms student is enrolled in the current trimester capstone unit | Team Lead | | +| **2** | Team lead submits access request to Ethics / GRC Team including student name, team, role, and systems required | Team Lead | | +| **3** | Ethics / GRC Team creates entry in the Access Register for the new member | Ethics / GRC | | +| **4** | New member is provided with and reads the following policies before access is granted: Information Security Policy (RO-POL-001), Acceptable Use Policy (RO-POL-003), Access Control Policy (RO-POL-002) | Ethics / GRC | | +| **5** | New member signs the Member Acknowledgement form confirming they have read and understood the policies | New Member | | + +### System Access Provisioning + +| **#** | **Task — System Access Provisioning** | **Responsible** | **Done ✓** | +| --- | --- | --- | --- | +| **6** | GitHub: add member to Redback Operations GitHub organisation | SecDevOps / Tutor | | +| **7** | GitHub: assign member to their team repository with Write access only | SecDevOps / Tutor | | +| **8** | GitHub: confirm member has MFA enabled on their GitHub account. If not, member has 5 days to enable it before access is suspended | SecDevOps / Ethics GRC | | +| **9** | Microsoft Teams: confirm member has access to relevant team channels | Tutor | | +| **10** | Microsoft Entra ID: provision role assignment aligned to team and responsibilities (if applicable) | Blue Team | | +| **11** | Physical hardware: brief member on safe use and storage procedures if team uses physical assets | Team Lead | | +| **12** | Data Warehouse systems: provision access to relevant Data Warehouse tools if member is on Data Warehouse team (MinIO, Dremio, Airflow etc.) | Data Warehouse Lead | | + +### Onboarding Completion + +| **#** | **Task — Onboarding Completion** | **Responsible** | **Done ✓** | +| --- | --- | --- | --- | +| **13** | Team lead confirms all required access has been provisioned and is appropriate to the member's role | Team Lead | | +| **14** | Ethics / GRC Team records onboarding completion date in the Access Register | Ethics / GRC | | +| **15** | New member completes Ethics module on D2L before commencing active work | New Member | | +| **16** | Team lead briefs new member on team-specific security responsibilities and any active incidents or open risks relevant to their role | Team Lead | | + +## Offboarding + +The following checklist must be completed for every departing student leaving Redback Operations. The departure can happen at any point of the trimester. Offboarding must be commenced by the team leader. + +The 32 inactive GitHub member accounts in the T1 2026 GitHub Audit is a consequence of an absent offboarding procedure. + +### Data and Knowledge Transfer + +| **#** | **Task — Data and Knowledge Transfer** | **Responsible** | **Done ✓** | +| --- | --- | --- | --- | +| **1** | Departing member transfers all active work, documentation, and project files to the team repository before their final day | Departing Member | | +| **2** | Team lead confirms all work-in-progress is documented and accessible to remaining or incoming team members | Team Lead | | +| **3** | Departing member deletes all Redback Operations Confidential data from personal devices | Departing Member | | +| **4** | Departing member confirms deletion of local data in writing to the Ethics / GRC Team | Departing Member | | +| **5** | Team lead documents any outstanding tasks or responsibilities the departing member held, outlined in the handover document, to the next cohort | Team Lead | | + +### System Access Revocation + +| **#** | **Task — System Access Revocation** | **Responsible** | **Done ✓** | +| --- | --- | --- | --- | +| **6** | GitHub: remove member from Redback Operations GitHub organisation | Tutor | | +| **7** | GitHub: remove member from all team assignments within the organisation | Tutor | | +| **8** | Microsoft Entra ID: remove all role assignments and disable or delete the account | Blue Team | | +| **9** | Shared credentials: rotate any shared passwords or secrets the member had access to | Team Lead / Blue Team | | +| **10** | Data Warehouse systems: revoke access to MinIO, Dremio, MongoDB, Airflow, and any other Data Warehouse tools (if applicable) | Data Warehouse Lead | | +| **11** | Physical hardware: confirm all physical assets are returned and in acceptable condition | Team Lead | | +| **12** | HiveMQ / MQTT: revoke broker credentials if member had access (Smartbike VR and Data Warehouse teams) | Blue Team / Team Lead | | + +### Offboarding Completion + +| **#** | **Task — Offboarding Completion** | **Responsible** | **Done ✓** | +| --- | --- | --- | --- | +| **13** | Team lead confirms all access has been revoked across all systems and signs off the offboarding checklist | Team Lead | | +| **14** | Ethics / GRC Team records offboarding completion date in the Access Register | Ethics / GRC | | +| **15** | Ethics / GRC Team verifies the member no longer appears as active in GitHub, Entra ID, or any other system | Ethics / GRC | | +| **16** | If any access could not be confirmed as revoked, raise as an Open incident in the Incident Register under RO-POL-004 | Ethics / GRC | | + +## Access Register + +The Ethics / GRC Team is responsible for maintain the Access Register which documents all active members, their access levels, and the dates they are enrolled for, per trimester. This register is to be reviewed at the start of each trimester. The access review process is defined in the Access Control Policy (RO-POL-002). + +| **#** | **Student Name** | **Team** | **Role** | **Systems Access Granted** | **Date Onboarded** | **Date Offboarded** | **Completed By** | +| --- | --- | --- | --- | --- | --- | --- | --- | +| *001* | *[Name]* | *[Team]* | *[Role]* | *[Systems]* | *[Date]* | *[Date]* | *[GRC Lead]* | +| *002* | *[Name]* | *[Team]* | *[Role]* | *[Systems]* | *[Date]* | *[Date]* | *[GRC Lead]* | +| *003* | *[Name]* | *[Team]* | *[Role]* | *[Systems]* | *[Date]* | *[Date]* | *[GRC Lead]* | +| *004* | *[Name]* | *[Team]* | *[Role]* | *[Systems]* | *[Date]* | *[Date]* | *[GRC Lead]* | +| *005* | *[Name]* | *[Team]* | *[Role]* | *[Systems]* | *[Date]* | *[Date]* | *[GRC Lead]* | + +## Mid-Trimester Offboarding + +If a student withdraws before the trimester concludes, it is to be treated as a normal offboarding procedure. The checklists must be completed immediately to ensure that the student does not have access to Redback Operations' systems. The Ethics / GRC team must be notified immediately to maintain the Access Register. + +## Trimester Start Review + +At the start of each trimester, the Ethics / GRC team must conduct a full access review to identify and remove stale accounts from the previous trimester. This review must be completed once all students are placed into their corresponding teams, no longer than one week of that placement. + +| **#** | **Task — Trimester Start Access Review** | **Responsible** | **Done ✓** | +| --- | --- | --- | --- | +| **1** | Export full GitHub organisation member list and cross-reference against current trimester enrolment | Ethics / GRC / SecDevOps | | +| **2** | Identify any members not enrolled in the current trimester and flag for removal | Ethics / GRC | | +| **3** | Confirm with tutors whether flagged accounts are legitimate (tutors, coordinators, service accounts) before removing | Ethics / GRC | | +| **4** | Remove all confirmed stale accounts from GitHub organisation and document in Access Register | SecDevOps / Tutor | | +| **5** | Review Microsoft Entra ID role assignments and remove stale accounts | Blue Team | | +| **6** | Confirm all active members have MFA enabled across all platforms | Ethics / GRC | | +| **7** | Document review outcome and any findings in the Access Register | Ethics / GRC | | + +## Non-Compliance + +Failure to complete the onboarding and offboarding procedures and checklists may lead to consequences such as: + +- A formal incident registered in the Incident Register +- Escalation to tutor or unit chair +- Stale account is counted as unmitigated in Risk Register. + +Team leaders are responsible for their member's onboarding and offboarding. If a team leader is not yet established, delegate to Ethics / GRC team. + +## Procedure Review + +This procedure must be reviewed at the start of each trimester by the Ethics / GRC team. Any changes must be version-controlled, dated, and approved before taking effect. diff --git a/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-GA-001-Gap-Analysis.md b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-GA-001-Gap-Analysis.md new file mode 100644 index 00000000..3b82eb3b --- /dev/null +++ b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-GA-001-Gap-Analysis.md @@ -0,0 +1,73 @@ +# Gap Analysis + +## Redback Operations – ISO27001:2022 ISMS + +| **Document Code** | RO – GA – 001 | +| --- | --- | +| **Version** | 1.0 | +| **Review Date** | End of Each Trimester | +| **Document Owner** | Ethics / GRC Team | +| **ISO Reference** | ISO/IEC 27001:2022 – Clauses 9.1, 10.1, 10.2 | +| **Prepared By** | Ramon Garcia – Ethics / GRC Team leader, T1 2026 | + +--- + +## Purpose + +The Gap Analysis documents the information security controls and procedures that were not active or present during Trimester 1 2026. The analysis identifies each gap, priority and the recommended action for the next cohort of the Ethics / GRC team. This document supports the continual improvement requirement under ISO/IEC 27001:2022 Clauses 10.1 and 10.2. The analysis is meant to define what actions are needed to fortify the security posture of Redback Operations for T2 2026. + +## Scope + +The Gap Analysis covers all 93 Annex A controls assessed in the Statement of Applicability. + +## What Was Completed This Trimester + +The following ISMS deliverables were completed during Trimester 1, 2026: + +- ISMS Scope Statement (RO-ISMS-001) +- Asset Register (RO-REG-001): gathered via direct team lead outreach across all 8 teams +- Risk Register (RO-REG-002): risks identified, scored, and treatment actions assigned +- Information Security Policy (RO-POL-001) +- Access Control Policy (RO-POL-002) +- Acceptable Use Policy (RO-POL-003) +- Incident Response Policy (RO-POL-004) +- Secure Development Policy (RO-POL-005) +- Data Handling Policy (RO-POL-006) +- GitHub Audit Report (RO-AUDIT-GIT-001): audit conducted on 21-22 March 2026 +- Onboarding & Offboarding Procedure (RO-CL-001) +- Statement of Applicability (RO-SOA-001): all ISO27001:2022 93 Annex A controls assessed +- Internal Audit Checklist (RO-AUD-001) + +## Gap Register + +This table documents all identified gaps. Priority is from High to Medium to Low based on Risk impact to Redback Operations. + +| **Gap ID** | **Area / Control** | **Description of Gap** | **Priority** | **Recommended Action** | +| --- | --- | --- | --- | --- | +| **GAP-001** | 5.5 – Contact with Authorities | Formal external authority contact procedure (e.g. law enforcement, CERT Australia) is not defined. Current escalation only covers internal tutor and unit chair. | **Medium** | Define an external escalation procedure referencing CERT Australia and relevant Victorian authorities. Add to IRP. | +| **GAP-002** | 5.13 – Labelling of Information | Classification levels are defined in the Asset Register and Data Handling Policy but a consistent labelling convention has not been enforced across documents and repositories. | **Low** | Establish a labelling convention (e.g. document headers, repository README classification tags) and enforce from next trimester. | +| **GAP-003** | 5.23 – Cloud Services | Personal cloud storage is prohibited for confidential data but a formal cloud configuration baseline covering approved cloud services has not been documented. | **Medium** | Document approved cloud services and their minimum security configuration requirements. Review which teams are using cloud storage. | +| **GAP-004** | 5.35 – Independent Review | The GitHub audit was conducted internally. An independent review of the ISMS has not been performed. Internal audit checklist was created but not yet operationally run by an independent reviewer. | **Medium** | Schedule an internal audit to be run in the first two weeks of next trimester by the incoming Ethics / GRC team using RO-AUD-001. | +| **GAP-005** | 6.6 – NDAs | Member Acknowledgement form covers policy acceptance but a formal Non-Disclosure Agreement for members handling confidential project data is not in place. | **Low** | Draft a simple NDA or confidentiality clause to be added to the onboarding acknowledgement form. Review with tutor before implementing. | +| **GAP-006** | 7.14 – Secure Disposal | A formal secure disposal procedure for Redback-managed hardware is not documented. The E-Waste Battery Extraction team handles disposal as a project focus but this is not formalised in the ISMS. | **Low** | Document a secure disposal procedure for hardware used by Redback teams. Coordinate with E-Waste Battery Extraction team. | +| **GAP-007** | 8.9 – Configuration Management | Secure-by-default principle and GitHub repository defaults are defined in policy but a formal configuration baseline register documenting expected states for all active systems has not been created. | **Medium** | Create a configuration baseline register covering GitHub repository settings, Entra ID role configurations, and HiveMQ access settings. | +| **GAP-008** | 8.12 – Data Leakage Prevention | GitHub secret scanning and push protection are referenced but formal DLP tooling has not been deployed. No systematic mechanism exists to detect data leakage beyond repository scanning. | **High** | Enable GitHub secret scanning and push protection across all active repositories. Evaluate lightweight DLP tooling options for next trimester. | +| **GAP-009** | 8.13 – Information Backup | ISMS documents are stored in GitHub providing version history, however a formal backup policy and schedule covering all Redback information assets has not been documented. | **Medium** | Document a backup schedule and responsibility assignment for all critical ISMS documents and registers. Confirm GitHub repository backup settings. | +| **GAP-010** | 8.31 – Dev/Test/Prod Separation | Branch protection rules are defined but formal separation of development, test and production environments has not been documented or consistently enforced across all 8 project teams. | **Medium** | Work with SecDevOps to define and enforce environment separation standards across all active repositories. Document in Secure Development Policy. | +| **GAP-011** | 8.34 – Audit Testing Protection | The GitHub audit was conducted without formal isolation procedures documented. Audit activities could potentially affect live operations if not carefully managed. | **Low** | Document audit testing procedures including scope boundaries, notification requirements, and rollback procedures for future audits. | +| **GAP-012** | Operational Evidence | The ISMS document suite describes what should happen but limited operational evidence exists of controls actually being performed, MFA confirmation, access review logs, team briefing records, and incident register entries are absent. | **High** | Collect and store operational evidence each trimester: MFA screenshots, access review sign-offs, team briefing attendance records, and at minimum one Incident Register entry. | +| **GAP-013** | Security Awareness Delivery | Policy awareness sessions were planned for all 8 teams but delivery and attendance were not formally documented. No evidence exists of security awareness training being completed. | **High** | Conduct and document security awareness sessions at the start of each trimester. Maintain attendance records as operational evidence. | +| **GAP-014** | Stale GitHub Members | GitHub audit identified 32 unaccounted members in the GitHub organisation beyond enrolled students. Status of remediation was not confirmed before end of trimester. | **High** | Confirm remediation of stale GitHub members with tutor. Implement a formal GitHub membership review as a mandatory start-of-trimester task. | +| **GAP-015** | Dependabot Vulnerabilities | Orion repository had 377 open Dependabot vulnerability flags at time of audit. Data Warehouse had 19 and Ethics repository had 6. Remediation status was not confirmed by trimester end. | **High** | Prioritise resolution of Orion Dependabot vulnerabilities with SecDevOps. Confirm all repositories have Dependabot alerts actively monitored and resolved. | + +## Priority Summary + +The incoming Ethics / GRC Team should address the gaps identified in this order: + +- High Priority Gaps (GAP – 008, GAP – 012, GAP – 013, GAP – 014, GAP – 015) should be addressed ideally within the first two weeks of T2, 2026. +- Medium Priority Gaps (GAP-001, GAP-003, GAP-004, GAP-007, GAP-009, GAP-010) should be completed by the middle of the trimester, Week 6 – 8. +- Low Priority Gaps (GAP-002, GAP-005, GAP-006, GAP-011) should be completed in the second half of the trimester. + +## Document Review + +This document should be reviewed by the Ethics / GRC Team at the end of each trimester. Utilise this document for the next cohort to rectify gaps identified. All changes should be version-controlled and dated. diff --git a/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-ISMS-001-Scope-Statement.md b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-ISMS-001-Scope-Statement.md new file mode 100644 index 00000000..2c3a1a35 --- /dev/null +++ b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-ISMS-001-Scope-Statement.md @@ -0,0 +1,47 @@ +# Scope Statement + +## Redback Operations – ISO27001:2022 ISMS + +| **Document Code** | RO – ISMS – 001 | +| --- | --- | +| **Version** | 1.0 | +| **Document Owner** | Ethics / GRC Team | +| **ISO27001 Reference** | Clauses 4.1, 4.2, 4.3 | +| **Review Interval** | Start of each Trimester | + +--- + +## Scope Statement + +This Information Security Management System (ISMS) aims to cover the assets, processes, procedures, and staff of Redback Operations for Trimester 1 2026. This ISMS will be relevant to all teams active and will be maintained by the Cyber-Security team. + +## Organisation + +Redback Operations is a student-led company at Deakin University which focuses on the development of cutting-edge technology for connected health, fitness and sport to allow safe and smart exercise. Students rotate every trimester, with a maximum duration of two trimesters. + +## Active Teams in Trimester 1, 2026 + +| **Team Name** | **Project Classification** | +| --- | --- | +| Smartbike VR | Application Development | +| Orion | Application Development | +| Garmin Watch | Application Development | +| E-Waste Battery Extraction | Robotics | +| Data Warehouse | Data Storage, Processing, Analytics and AI | +| Blue Team | Information Security | +| Ethics / GRC | Compliance Education / Awareness | +| SecDevOps | Code Monitoring / Rectification | + +## Out of scope statement + +| **Exclusion** | **Justification** | +| --- | --- | +| Personal Emails | Redback Operations does not have control over developer's personal email. | +| Personal Student Devices | Redback Operations does not have control over developer's personal tools but access to Redback systems is governed by Redback. | +| Deakin University login credentials | Deakin University IT handles the management of login credentials. | +| Network utilised for Redback tasks | The network that is used to conduct tasks for Redback is out of control for Redback Operation members to manage. The network infrastructure is managed by personal ISPs or Deakin. | +| Inactive Github Repositories | Github Repositories that have not been utilised in a while is no longer maintained. | +| Inactive Microsoft Teams channels | Teams channels that are inactive are no longer maintained. | +| Physical Environment | Redback Operations does not have control or can manage the physical environment in which the developers choose to work in. | +| Deakin University IT administrative procedures | Outside of Redback Operation's ability to manage. | +| Former developers (students and tutors) | Redback Operations is no longer responsible for those who are no longer enrolled. | diff --git a/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-001-Information-Security-Policy.md b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-001-Information-Security-Policy.md new file mode 100644 index 00000000..7676b809 --- /dev/null +++ b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-001-Information-Security-Policy.md @@ -0,0 +1,79 @@ +# Information Security Policy + +## Redback Operations – ISO27001:2022 ISMS + +| **Document Code** | RO – POL - 001 | +| --- | --- | +| **Version** | 1.0 | +| **Document Owner** | Ethics / GRC Team | +| **Review Cycle** | At the start of each trimester | +| **ISO27001:2022 Reference** | Clauses 5.1, 5.2 | + +--- + +## Organisational Context + +Redback Operations is a student-led company originating from Deakin University. It focuses on the development of technology for health, fitness and sport. Redback Operations will uphold confidentiality, integrity and availability of all assets, whether it be information, physical or digital. + +Redback Operations currently operates with 54 active members across 8 different teams. Numbers vary per trimester. Students however rotate every trimester with a maximum length of two trimesters as per Capstone Part (A) and Capstone Part (B). This ISMS is designed specifically to address issues caused by Redback Operations' rotational nature. + +## Policy Statement + +This policy highlights the framework for our Information Security Management System (ISMS), adhering to ISO/IEC 27001:2022 standards. It is applicable to all active members, assets, programs and processes that are within Redback Operations for Trimester 1, 2026 and must be adhered to by every active student. + +Information security is defined as the protection of confidentiality, integrity and availability of Redback Operations' information assets. Confidentiality is defined as ensuring that information is only accessible to those who are authorised. Integrity is defined as guaranteeing that the information is accurate and authentic. Availability allows information to be accessible to authorised individuals when it is needed. + +## Our Commitments + +Information security objectives are established at the start of each trimester by the Ethics / GRC team, educated and guided from the Risk Register from the previous trimester and the Statement of Applicability. Progress is checked at the end of each trimester. + +Redback Operations strives to: + +- Protect all information assets from unauthorised access, malicious modification and destruction. +- That access to Redback Operations' information and programs are on a least-privilege and need-to-know basis. +- Educating members on security awareness before being allowed to access Redback Operations and its systems. +- Revoke access to Redback Operations' systems when offboarding procedures commence. +- That logging, containing and treating security risks is performed each trimester. +- Be proactive in security incidents, ensure proper procedure is followed. +- That maintenance and iterations on the ISO27001:2022 ISMS are performed per trimester. +- Adhere to Victorian legal, regulatory and Deakin university rules. + +## Principles Definition + +These principles define the information security activities at Redback Operations. These principles are present in the ISMS suite. + +| **Principle** | **Definition** | +| --- | --- | +| Least Privilege | Access is granted at the minimal level for a student's role. | +| Need to Know | Information is accessible only to those who need it for their role. | +| Defence in Depth | Layers of defence are implemented. | +| Security by Design | Security is implemented throughout development rather than an afterthought. | +| Continual Improvement | ISMS is reviewed and iterated per trimester. | + +## Supporting Policies and Documents + +This policy is supported by the other various ISMS documents. + +| **Document Code** | **Title** | +| --- | --- | +| RO – ISMS – 001 | ISMS Scope | +| RO – REG – 001 | Asset Register | +| RO – REG – 002 | Risk Register | +| RO – POL - 002 | Access Control Policy | +| RO – POL – 003 | Acceptable Use Policy | +| RO – POL – 004 | Incident Response Policy | +| RO – POL - 005 | Secure Development Policy | +| RO – POL – 006 | Data Handling Policy | +| RO – CL - 001 | Onboarding & Offboarding Procedure | +| RO – AUDIT-GIT-001 | GitHub Audit Report | +| RO – SOA – 001 | Statement of Applicability | +| RO –AUD - 001 | Internal Audit Checklist | +| RO – GA - 001 | Gap Analysis | + +## Non-Compliance + +Any member who does not comply with this policy or other policies as a part of this ISMS will have their access suspended and the issue escalated to the relevant tutor. Redback Operations does not tolerate breaches of its information security. Consequences are defined as per the Incident Response Policy. + +## Policy Review + +This policy must be reviewed at the start of every trimester by the incoming Ethics / GRC Team. Any changes must be version-controlled, dated and approved. diff --git a/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-002-Access-Control-Policy.md b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-002-Access-Control-Policy.md new file mode 100644 index 00000000..e975284c --- /dev/null +++ b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-002-Access-Control-Policy.md @@ -0,0 +1,176 @@ +# Access Control Policy + +## Redback Operations – ISO27001:2022 ISMS + +| **Document Code** | RO – POL – 002 | +| --- | --- | +| **Version** | 1.0 | +| **Review Interval** | Start of Each Trimester | +| **Document Owner** | Ethics / GRC Team | +| **ISO Reference** | ISO/IEC 27001:2022 – Annex A Controls 5.15, 5.16, 5.17, 5.18, 8.2, 8.3, 8.5 | + +--- + +## Table of Contents + +1. Purpose +2. Scope +3. Policy Statement +4. Roles and their Responsibilities +5. Access Control Principles + - 5.1 Least Privilege + - 5.2 Need to Know + - 5.3 Separation of Duties + - 5.4 Team-Based Ownership +6. Access Management + - 6.1 Onboarding + - 6.2 Access Review + - 6.3 Offboarding +7. System – Specific Access Controls + - 7.1 GitHub + - 7.2 Entra ID + - 7.3 Security Tooling + - 7.4 HiveMQ +8. Multi-Factor Authentication (MFA) +9. Credentials and Secrets Management +10. Non-Compliance +11. Policy Review + +--- + +## 1. Purpose + +The policy highlights how Redback Operations manages access control to its information assets, systems, repositories and their data. This policy outlines that only authorized individuals can access certain assets that are indicative of their role. The policy also states that access to Redback's resources should be removed when a student enrolment is concluded. Redback Operation's rotation nature calls for this policy to indicate access based on time and withdrawal of access. + +## 2. Scope + +This policy is applicable to: + +- Redback Operations members operating in the 8 active teams for Trimester 1, 2026. +- All assets including GitHub Repositories, cloud environments, authorization platforms, communication platforms, data warehouse systems and documentation relating to. +- All third-party software and services used by Redback Operations project teams. +- Team leads who are responsible for managing access control with their team members. + +## 3. Policy Statement + +Redback Operations must ensure that all assets are granted on a permitted basis and least privilege principle. All access must be authorized, documented and revoked when the student is offboard or their enrolment within the capstone unit concludes. Individuals should not be granted access to assets beyond their scope of responsibilities and role. + +## 4. Roles and their Responsibilities + +| **Role** | **Responsibilities** | +| --- | --- | +| **Ethics / GRC** | Reviewing and maintaining this policy each trimester; perform access audits where possible and educate Redback Operations on access control policies | +| **SecDevOps** | Ensure that only certain students have access to code reviews on GitHub. Ensure that only certain students have access to workflow files and automatic scanning implementation. | +| **Blue Team** | Manage access to security platforms such as Microsoft Entra ID and Wazuh. Ensure that only certain members can access configurations for ModSecurity firewall. | +| **Team Leaders** | Manage access control for members in team. | +| **All Members** | Use access that has only been granted for their role. Report unauthorized access where the role should not be able to access. Do not share login credentials. | + +## 5. Access Control Principles + +### 5.1 Least Privilege + +All access must be granted on a least-privilege basis. Members can only be given the minimum level of access and authorization that is required for their role. Access should not be pre-emptively granted for future roles, only when confirmed. + +### 5.2 Need to Know + +Access to critical information and their systems is only available to those who need it to carry out their responsibilities. + +### 5.3 Separation of Duties + +Critical functions should ideally be split across individuals to minimize error or misuse. A single student should not have management responsibilities over an entire system. + +### 5.4 Team-Based Ownership + +All ownership of assets and systems can only be assigned to a team, not an individual. This can help with access management for future trimesters. + +## 6. Access Management + +### 6.1 Onboarding + +When a new student is enrolled and commencing work: + +- Access is only given based on their role +- The member is educated on security policies before access is given. +- Ensure that students report any unauthorized access. + +### 6.2 Access Review + +An access review must be undertaken per the start of each trimester: + +- Team leads have to confirm which members are enrolled in their teams and their access levels for their responsibilities. +- If unauthorized permissions or inactive permissions are found, ensure that it is reported and removed immediately. +- Ethics / GRC team have to document each review taken. + +### 6.3 Offboarding + +When a trimester concludes, these protocols should be enacted: + +- Team leads initiate offboarding at the last day of the trimester. +- GitHub membership and team assignments should be revoked. +- All authorization platforms and their members' access should be revoked. +- Microsoft Teams chat for ongoing Redback Operations' communications should be revoked. +- Any Personal Access Tokens (PAT) should be revoked. +- Offboarding is documented by the team leader. + +## 7. System – Specific Access Controls + +### 7.1 GitHub + +- All repositories are under the central Redback Operations GitHub platform +- Repository visibility should default to Private unless permitted as Public. +- Members should only be granted access to their team repository only. +- Members should only be granted the access they need to their repository. +- Admin access is permitted only for SecDevOps, tutors and team leaders. +- Collaborators outside Redback Operations needs to be permitted by Ethics / GRC. +- Branch protection rules should be enabled on all branches in all active repositories. + +### 7.2 Entra ID + +- Access utilising Entra ID is managed by Blue Team. +- Role assignments should mirror the member's team and their responsibilities. +- Privileged roles should be audited at the start of each trimester. +- MFA is compulsory for all accounts. + +### 7.3 Security Tooling + +- Access to cyber-security tools should only be restricted to Blue Team. +- No other team members should have access to dashboards or security logs. +- Access is audited at the start of each trimester and withdrawn for concluding Blue Team members. + +### 7.4 HiveMQ + +- Access utilising HiveMQ is managed by Smartbike VR Team Lead +- No other team members should have access to IoT communication via HiveMQ. +- Access to platform must be audited per trimester. + +## 8. Multi-Factor Authentication (MFA) + +MFA should be mandatory for every account with access to Redback Operations, the systems include: + +- GitHub organisation accounts +- Microsoft Entra ID +- React Native & Expo +- HiveMQ + +If student does not have multi-factor authentication enabled, ensure that they do within 5 days of enrolment and/or commencing work, otherwise, suspend responsibilities. + +## 9. Credentials and Secrets Management + +- Passwords should never be shared via communication channels. +- Passwords should never be present in repositories. +- Personal Access Tokens should be scoped to the minimal requirement and revoked when student is offboarding. +- Any exposed credentials or compromise should be reported to Ethics / GRC Team immediately. + +## 10. Non-Compliance + +If compliance with this policy cannot be reached then these protocols should be enacted: + +- Suspension of access to Redback Operations' programs. +- Escalation to tutor or unit chair. +- Formal report should be made and raised to proper authorities. + +If misuse or non-compliance is detected, report to Ethics / GRC Team. + +## 11. Policy Review + +This policy should be reviewed at the start of the trimester by the commencing Ethics / GRC team. The senior students should oversee the review. Any changes should alter the version of the document, dated and reviewed before commenced. The document version should be incremented per iteration. diff --git a/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-003-Acceptable-Use-Policy.md b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-003-Acceptable-Use-Policy.md new file mode 100644 index 00000000..ebcb8e42 --- /dev/null +++ b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-003-Acceptable-Use-Policy.md @@ -0,0 +1,190 @@ +# Acceptable Use Policy + +## Redback Operations – ISO27001:2022 ISMS + +| **Document Code** | RO – POL – 003 | +| --- | --- | +| **Version** | 1.0 | +| **Review Interval** | Start of Each Trimester | +| **Document Owner** | Ethics / GRC Team | +| **ISO Reference** | ISO/IEC 27001:2022 – Annex A Controls 5.10, 5.12, 5.14, 6.7, 7.7, 7.8 ,8.1, 8.7, 8.19 | + +--- + +## Contents + +1. Purpose +2. Scope +3. General Principles +4. Acceptable Use + - 4.1 GitHub and Company Repositories + - 4.2 Communication Channels + - 4.3 Development Tools and Software + - 4.5 Physical Hardware + - 4.6 Personal Hardware + - 4.7 Private AI Platform +5. Acceptable Use +6. Data Handling + - 6.1 Data Classification + - 6.2 Data Storage + - 6.3 Data Retention and Disposal +7. Security Responsibilities +8. Incident Reporting +9. Monitoring and Audit +10. Non-Compliance +11. Policy Review +12. Member Acknowledgment + +--- + +## Purpose + +This policy is to ensure that all the systems, programs and assets within Redback Operations is utilized in an acceptable standard by its members. It highlights the expectations for responsible behaviour within the procedures of Redback Operations. The policy dictates the appropriate use of Redback Operations' assets. + +## Scope + +This policy is applicable to: + +- Redback Operation members who are active in the active teams of Trimester 1, 2026. +- Information assets pertaining to Redback Operations' systems and programs. This includes GitHub, Microsoft Teams, Microsoft Entra ID, development tools and hardware utilized. +- Access to Redback Operations' systems, no matter the location +- Any third-party software, tools or devices within project work. + +## General Principles + +All members should be compliant within these following principles when operating Redback Operations' systems and assets: + +- Utilise organizational assets for only Redback Operations project procedures. +- Comply within terms and conditions of software and programs +- Ensure that whilst undertaking this capstone unit, that each member is behaving in a professional and appropriate manner. +- Report any security incidents, possible cyber threats, or unauthorized use to Ethics / GRC team. + +## Acceptable Use + +### 4.1 GitHub and Company Repositories + +- Utilise Github and its repositories for the sole purpose of Redback Operations. +- Code can only be approved and merged if it has been reviewed and does not contain hardcoded PII, sensitive information or vulnerable code. +- Commit code that does not contain vulnerabilities, hardcoded PII or sensitive information. +- Allow access to repositories that is applicable per team unless role and responsibilities include a plethora of repositories. +- Commit messages should be coherent, professional and applicable to the changes made. + +### Communication Channels + +This section applies to all channels that are utilized for Redback Operations' communications. + +- Professional and respectful communication should be always maintained. +- Sensitive information shall not be sent through channels, this includes credentials, confidential information and known vulnerabilities. +- Files that should be located elsewhere should not be uploaded to communication channels. + +### 4.3 Development Tools and Software + +- Utilise only open-source or licensed software for project work +- Keep software updated in order to mitigate exploits or vulnerabilities +- Do not install malicious software or unauthorized software on project systems +- Secure coding practices should be upheld whilst developing projects, if guidance is needed, reach out to SecDevOps team. + +### 4.4 Physical Hardware + +- Ensure that all hardware is utilized safely and properly within their intended use. +- Ensure that hardware is stored safely, away from accidental means. +- Report any theft, loss or damage to Ethics / GRC team. +- Do not connect personal items to Redback Operations' hardware without approval. + +### 4.5 Personal Hardware + +- If personal devices are utilized to access Redback Operations' systems and programs, ensure that devices are up to date and have anti-virus software. +- Do not store locally Redback Operations' sensitive data +- Do not allow other individuals to access your device while operating on Redback Operations' systems and programs. +- Do not share your screen whilst having Redback Operations data or systems present on your screen. +- If leaving device unattended, lock device. + +### 4.7 Private AI Platform + +- Only utilize the AI platform in its intended way. Data query, automation and knowledge access. +- Do not feed AI platform sensitive information via prompts. +- Do not take AI platform's statements as factual, always check with Data Warehouse Team Leader on authenticity of information + +## Prohibited Activity + +The following activities/ behaviour are prohibited under Redback Operations' policy: + +| **Prohibited Activity** | **Reasons for Prohibition** | +| --- | --- | +| Sharing credentials or tokens with other members or third-parties | Access control policy and its principles are breached whilst prohibited access is present. | +| Pushing insecure code, hardcoded PII and other sensitive information to repositories | GitHub repositories are public-facing, this allows the public to see confidential information. System security may be breached. | +| Accessing unauthorized repositories, systems or data beyond role or team. | Access control policy is breached and unauthorized access is present. | +| Utilising Redback Operations' assets or systems for non-Redback Operations usage | Misuse of resources and attack vectors increase | +| Implementing malicious software, exploits or unauthorized security testing | Legal Consequences. Security incident is raised and investigations will be conducted. | +| Work-arounds on MFA systems in place and access restrictions | Access control is breached and consequences will follow. Poses major security risk to systems protected by MFA. | +| Access to Redback Operations' systems after concluding enrolment | Former members cannot retain access as access should only be given to those who are active. Enforced via offboarding procedure | +| Sharing confidential information, source code or sensitive documentation | Confidentiality is breached and intellectual property violation | + +## 6. Data Handling + +### 6.1 Data Classification + +All members must handle data according to its classification level, this is defined in the Redback Operations Asset Register: + +- Confidential: restricted access and strong controls are required. +- Internal: Only Redback members are authorized. +- Public: No restrictions. + +### 6.2 Data Storage + +- Store data in approved repositories +- Utilisation of personal cloud storage services is not permitted for Redback projects. +- Do not email or message source code, login credentials or sensitive information + +### 6.3 Data Retention and Disposal + +- Do not keep copies of Redback Operations' sensitive information, source code or system after having been offboarded. +- Delete local files pertaining to Redback Operations +- Contact Ethics / GRC if confused whether it is appropriate to retain or remove information + +## Security Responsibilities + +Members of Redback Operations should follow these principles and procedures with the aim of securing systems and information: + +- Enable multi-factor authentication on all Redback Operations related accounts +- Produce strong passwords without reusing across platforms +- Report any social engineering attacks to Ethics / GRC team +- Do not access information that you do not have authorisation for +- Complete educational modules on security awareness present on D2L and Docusaurus + +## Incident Reporting + +Any member who come across a potential security incident or policy violation situation should report: + +- Unauthorised account access to personal or other members' accounts +- Accidental exposure of sensitive information or login credentials +- Malware is detected on hardware or software +- Loss, damage or theft of physical assets + +Ensure that you report to Ethics / GRC team and layout reporting template as per the Incident Response Policy on how to format report. + +## Monitoring and Audit + +Redback Operations has the right to review usage of its systems and assets for security and legal purposes. Monitoring ensures that students undertaking the capstone unit do not abuse or maliciously utilise sensitive information. + +This includes: + +- GitHub activity logs +- Security scanning results from tools +- Cloud environment utilisation + +## Non-Compliance + +Breaching this policy will incur these consequences, appropriate to situation: + +- Suspension of access to Redback Operations' systems and assets +- Escalation to tutor or unit chair +- Incident report is documented + +## Policy Review + +The policy should be reviewed at the start of each trimester by the commencing Ethics / GRC team. Changes shall be dated and approved before being implemented. The document version shall be incremented with each iteration. + +## Member Acknowledgment + +This policy should be acknowledged and read by each member at the start of their enrolment. This policy should be part of their onboarding process and acknowledgment should be documented by the Ethics / GRC team. diff --git a/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-004-Incident-Response-Policy.md b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-004-Incident-Response-Policy.md new file mode 100644 index 00000000..a73fa0ba --- /dev/null +++ b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-004-Incident-Response-Policy.md @@ -0,0 +1,205 @@ +# Incident Response Policy + +## Redback Operations + +| **Document Code** | RO – POL - 004 | +| --- | --- | +| **Version** | 1.0 | +| **Review interval** | Start of Trimester | +| **Document Owner** | Ethics / GRC Team | +| **ISO27001 Reference** | ISO27001:2022 – Annex A Controls 5.24, 5.25, 5.26, 5.27, 5.28 | + +--- + +## Purpose + +This policy is to ensure that a comprehensive and coherent incident response plan is in place for Redback Operations. This includes, detecting, reporting, managing and fixing the information security incident. + +Due to Redback Operations' nature of trimester cycles, this document will also assist in ensuring that every incident knowledge is documented. + +## Scope + +This policy is applicable to: + +- All Redback Operations members who are enrolled in Trimester 1, 2026. +- Every asset or system. +- Any event that will breach Redback Operations' systems, expose member or project information or halter active development. + +## What defines a Security Incident + +A security incident is when there is potentially negative impacts on the confidentiality, integrity or availability of Redback Operations' assets. All developers and staff of Redback Operations should report suspected malicious activity. + +## Incident Security Levels + +All incidents have to be assigned a level that determines it severity in an incident report. + +| **Severity** | Criteria | Time of attendance | Escalation | +| --- | --- | --- | --- | +| **Critical** | Live unauthorised access, PII or credentials are in GitHub repositories, harm from physical assets, malware | Within 1 Hour | Notify tutor and team lead. | +| **High** | Suspected access from malicious actor, offboarded students still have access through old accounts, physical assets are missing | Within 4 hours | Notify Ethics / GRC and your team lead within the same day. | +| **Medium** | Security controls need to be implemented, policy is breached | Within 24 hours | Notify your team or team lead. | +| **Low** | Minor policy breach, automatic scanning tools find vulnerability in code before merging | Within 1 week | Log in Risk Register or notify team. | + +## Roles and Responsibilities + +### All Members + +- Report any suspicious behaviour. +- Document evidence that relate to malicious activity. +- Cooperate with Blue Team and Ethics / GRC team. + +### Ethics / GRC Team + +- Input all incident reports in Incident Register. +- Coordinate severity level with incident and manage the appropriate response for said incident. +- Escalate to tutor or unit chair if required. +- Log incident, document every process and monitor results to asset compromised. +- Escalate to Blue Team if technical mitigation is needed. + +### Blue Team + +- Coordinate investigations for information system assets. +- Technical incidents are documented and contained. +- After incident is concluded, forward information to Ethics / GRC team for it to be documented. +- Establish new controls where it is needed to mitigate risks and breaches. + +### SecDevOps Team + +- Coordinate investigations on source code repositories. +- Ensure that automatic scanning tools are not detecting further vulnerabilities. +- Notify Ethics / GRC team of breaches and documentation. + +### Team Leads + +- Notify Ethics / GRC team of incidents within team processes. +- Offer logs, communications or documentation relating to incident. +- Educate team members on incident response policies. + +## Incident Response Procedure + +Any incident report must follow these procedures: + +### Phase 1 – Identification + +- Any developer who has suspected or recognises an incident must report it to the Ethics / GRC team, preferably the team lead on Microsoft Teams. +- Do not try to resolve or investigate by yourself. +- Document all evidence, do not tamper with digital forensics such as logs and files. +- If PII or credential was exposed, do not delete from repository aside if it is pre-merge. + +### Phase 2 – Logging + +- Ethics / GRC Team must log the incident in the Incident Register. +- The log entry must include, the date and time, overview of incident, assets affected and severity assessment. +- An incident ID is assigned, defined as INC-001, INC-002, incrementing per incident logged. + +### Phase 3 – Containment + +- Depending on nature and environment of incident, either Blue Team or SecDevOps has to direct the containment of said incident. +- If credentials are compromised, revoke immediately. +- If account is accessed maliciously, revoke account or suspend immediately. +- If source code contains PII or sensitive information, contact GitHub support and notify SecDevOps immediately. +- If physical harm occurs via physical assets, secure hardware and restrict access to physical environment. + +### Phase 4 – Investigation + +- Blue Team or SecDevOps must conduct an investigation to figure out cause, scope and result of the incident. +- Evidence collected during this investigation has to be retained and logged. +- The Ethics / GRC team has to coordinate the investigation and communicate with all parties relevant. +- Supervising tutor has to be notified if the incident is critical within the same day. + +### Phase 5 – Remediation + +- Implement fixes to ensure that the cause is solved. +- Ensure that fix is effective before concluding the incident. +- Update relevant documentation such as policies, procedures or controls if the incident has identified a gap. +- Add newly identified risks to Risk Register. + +### Phase 6 – Lessons Learned + +- Within a week of the conclusion of the incident, conduct a review on lessons learned. +- Document what had happened, what the cause was, how it was solved and what will be utilised to mitigate future incidents similar. +- Share findings with teams. +- Update Incident Register for next cohort to know of incidents. + +## Escalation + +The following table provides the contact information for escalation if an incident requires escalation and/or reaches Critical level of severity assessment: + +| **Role** | **Name** | **Contact Method** | **Hours available** | +| --- | --- | --- | --- | +| **Ethics / GRC Team Lead** | | Microsoft Teams | Full availability, no hours set. | +| **Blue Team Lead** | | Microsoft Teams | Full availability, no hours set. | +| **SecDevOps Team Lead** | | Microsoft Teams | Full availability, no hours set. | +| **Cybersecurity Team Tutor** | | Microsoft Teams / Email | Full availability, no hours set. | +| **Unit Chair** | | Microsoft Teams / Email | Full availability, no hours set. | + +## Specific Incident Scenarios + +### Credentials or PII exposed in Repository + +- Severity Level: Critical +- Immediate action: rotate the exposed credential, do not delete the commit. +- Enable push protection on the repository that the exposure is on. +- Investigate commit history to check how long the exposure had existed. +- Notify SecDevOps immediately. + +### Stale or Unauthorised Account Access + +- Severity Level: High +- Immediate Action: suspend account until further verification is conducted. +- Ensure that account is not registered with those enrolled in this trimester. +- If account belongs to a former student, remove access and document in incident register. +- Review offboarding checklist as to how the account remained on Redback Operations. + +### Critical Dependabot or Trivy Vulnerability Alert + +- Severity Level: High +- SecDevOps team reviews alert and evaluates exploitability within 24 hours of alert. +- If source code is exploitable on GitHub, classify as High and update dependencies for project. +- If not, add to Risk Register. + +### Physical Hardware Lost or Stolen + +- Severity Level: High +- Report to team lead. +- Determine if any sensitive information or credentials were on the device. +- If credentials were on device, rotate credentials. + +### ROS or IoT Safety Incident + +- Severity: Critical +- Power down systems related to incident. +- Restrict access to physical environment until cause is recognised. +- Notify tutor as physical safety is concerned. + +### Private AI Platform Data Exposure + +- Severity: Critical +- Immediate Action: Document the information that is exposed. +- Take A.I offline until security risk is solved and trialled that mistake will not be repeated. +- Notify Data Warehouse Leader and Blue Team immediately. +- Review AI security. + +## Evidence Preservation + +Evidence needs to be preserved when an incident is occurring and its response process. This information should not be deleted or modification or overwritten during an incident: + +- GitHub commit history, access logs and security alert messages. +- Communication messages related to incident +- Wazuh security logs and alert records. +- Any screenshots at the time of incident identification. + +## Incident Register + +Every incident must be logged into the Incident Register. This register should be maintained by the Ethics / GRC Team and reviewed at the start of each trimester. + +| **Incident ID** | **Date Reported** | **Reported By** | **Description** | **Severity** | **Status** | +| --- | --- | --- | --- | --- | --- | +| Example | 6.4.26 | Rick M | In GitHub repository, Ethics, found hardcoded PII from the report.json file. | Critical | Closed. SecDevOps removed hardcoded PII by deleting commit and finding solution to ignore scans from PII scanner. | +| INC-001 | | | | | | +| INC-002 | | | | | | +| INC-003 | | | | | | + +## Policy Review + +This policy must be reviewed at the start of every trimester by the incoming Ethics / GRC Team. Any changes must be version-controlled, dated and approved. diff --git a/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-005-Secure-Development-Policy.md b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-005-Secure-Development-Policy.md new file mode 100644 index 00000000..8d60f4f5 --- /dev/null +++ b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-005-Secure-Development-Policy.md @@ -0,0 +1,168 @@ +# Secure Development Policy + +## Redback Operations – ISO27001:2022 ISMS + +| **Document Version** | 1.0 | +| --- | --- | +| **Document Code** | RO – POL – 005 | +| **Document Owner** | Ethics / GRC Team | +| **Review Interval** | Start of Each Trimester | +| **ISO27001 Reference** | ISO27001:2022 – Annex A Controls 8.4, 8.8, 8.9, 8.19, 8.25, 8.26, 8.27, 8.28, 8.29, 8.32 | + +--- + +## Purpose + +The purpose of this policy is to ensure that Redback Operations' source code and its development is held to this policy's standard, adhering to ISO27001:2022 standards. This policy will outline practices that need to be implemented within the project's development lifecycle. + +## Scope + +This policy is applicable to all applications and development concerning Redback Operations' development lifecycle in its projects: + +- Source code contained within GitHub repositories and their respective projects +- All active members within Redback Operations developing code +- Development in IDEs and other code editor programs. +- React Native (Expo framework) +- Unity Simulation +- Garmin SDK +- Applications that are relevant to software development and its lifecycle are not listed. + +## Principles + +All development within Redback Operations must follow these secure development principles: + +- **Security By Design:** This principle outlines the necessity for secure programming practices, threat modelling and mitigation of security risks is performed throughout development, not just at the end of its implementation. +- **Secure By Default:** Default configurations of the applications are to be the most secure settings. Settings are to be varied per development. +- **Defense in Depth:** Defense against attacks is supported by multiple security protocols. Risks and vulnerabilities are mitigated through the implementation of layering defense controls. +- **Least Privilege:** A person or process is to be granted the minimal number of permissions / settings that are only needed for their role and its responsibilities. Only to be given those permissions within the minimal timeframe. + +## Code Review Requirements + +### Review performed prior merging + +All code committed to the GitHub repositories are to be reviewed by the SecDevOps team before being merged into the main branch in its respective repositories. No developer can review their own pull request and approve it. Applicable to all active repositories. + +### Reviewers must check + +SecDevOps and other code reviewers are responsible for ensuring that the following vulnerabilities and practices are flagged and fixed accordingly: + +- **Hardcoded Personally Identifiable Information (PII):** Information that can identify a specific person or asset and is present in source code. This can look like sensitive information that has phone number, address, license numbers and information. +- **Error Handling:** Code handles errors in a way that does not output information relating to its system and sensitive information. +- **Input validation:** Utilized for consumer-facing products and their inputs are sanitized. +- **OWASP10 Vulnerabilities:** Separate review must be performed aside from the automated scanning that is present in the current repositories. + +### Branch Protection Requirement + +The Branch Protection feature must be present in all active repositories across Redback Operations. + +## Secrets and Credentials Security + +### Hardcoded secrets in code + +If the following data is present within the GitHub repositories, then it is to be treated as a Critical severity level incident. The proper procedure is to be followed as per the Incident Response Policy (RO – POL – 004) if any of the information is present: + +- Passwords +- Login Credentials +- API Keys and Tokens +- Personally Identifiable Information (PII) +- JSON Web Tokens +- OAuth tokens + +### Response following Secret exposure + +If any of the secrets are exposed in publicly facing platforms, the following procedure is to be enacted: + +- Immediate action: rotate the exposed credential, do not delete the commit. +- Enable push protection on the repository that the exposure is on. +- Investigate commit history to check how long the exposure had existed. +- Notify SecDevOps immediately. + +## Managing Dependencies in Secure Development + +### Sources + +All dependencies and libraries are to be downloaded from official and authorised repositories. Typosquatting is a common attack where packages with a similar name to an official package is malware. + +### Pinning Dependencies + +Dependencies and their versions must be listed in an application's requirement file. Floating versions are discouraged as they automatically utilise a version. This can look like: + +Requirements.txt == mongodb == 10.0.1 + +### Dependabot + +It is a requirement that Dependabot is active in all GitHub repositories. Dependabot alerts are to be reviewed and enacted upon by the SecDevOps team. + +## OWASP Top 10 + +Redback Operations' active development teams are to be aware of the OWASP Top 10 vulnerabilities. These vulnerabilities should be considered by the developers during the projects' software development lifecycle. + +| **AO1:2025** | Broken Access Control | +| --- | --- | +| **AO2:2025** | Security Misconfiguration | +| **AO3:2025** | Software Supply Chain Failures | +| **AO4:2025** | Cryptographic Failures | +| **AO5:2025** | Injection | +| **AO6:2025** | Insecure Design | +| **AO7:2025** | Authentication Failures | +| **AO8:2025** | Software or Data Integrity Failures | +| **AO9:2025** | Security Logging and Alerting Failures | +| **AO10:2025** | Mishandling of Exceptional Conditions | + +## CI/CD Pipeline Security + +GitHub Actions Workflows are to be secured accordingly: + +- Workflow permissions are to be set to be read-only. +- If secrets are present within workflows, use GitHub Action Secrets to store those secrets, do not hardcode. +- Creation or alteration of workflow files must be reviewed by SecDevOps via pull request review. + +## Secure Coding Standards in Coding Languages + +### Python + +- Utilise virtual environments, do not install packages that are on shared systems. +- Validate all inputs if developing consumer-facing products, use libraries wherever applicable. +- Store sensitive information in environment variables or locally, do not hardcode into files. +- Utilise prepared statements for input derived from users. + +### Monkey C + +- Practice strict type checking through utilizing the strict compiler setting to mitigate runtime errors. +- Avoid deep function call stacks and recursive calls as there is limited stack space. +- Do not create unnecessary objects as Monkey C uses reference counting. This is to prevent memory errors. +- Validate data received from external sources. + +### C# + +- Avoid storing credentials or API credentials in Unity applications. +- Disable debug logging in production builds. +- Do not use Resources.Load for assets that end users should not access. + +## Pull Request Checklist + +The SecDevOps and other code reviewers must perform a review utilizing this checklist on pull requests to ensure that the code is up to standard before approving the merge. + +| **Security Feature** | **Approved** | +| --- | --- | +| No hardcoded credentials are present in the code. | | +| No hardcoded PII are present in the code. | | +| All dependencies are from verified sources and version is pinned in files. | | +| Error messages does not display information that outputs data relating to paths or systems. | | +| No commented code that presents sensitive information. | | +| Trivy scanner and Dependabot alerts are cleared before approving pull request. | | +| CI/CD pipeline passes automated scan. | | +| OWASP10 Vulnerabilities is not present in the code. | | +| Input validation is implemented in code relating to programs that are publicly-facing. | | + +## Non-Compliance Consequences + +If this policy is breached, there are multiple penalties that are to be imposed, this includes: + +- Rejection of Pull Request. +- If incidents containing sensitive information and PII is active, escalate to corresponding severity level and inform Ethics / GRC team. +- Escalate to tutor / unit chair if breaches are deliberate. + +## Policy Review + +The Secure Development Policy needs to be reviewed at the start of each trimester to reflect the current state of Redback Operations. Collaboration between SecDevOps and the Ethics/GRC team is to be enacted when reviewing this policy. Any changes should be dated and version-controlled. diff --git a/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-006-Data-Handling-Policy.md b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-006-Data-Handling-Policy.md new file mode 100644 index 00000000..6a077a3f --- /dev/null +++ b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-POL-006-Data-Handling-Policy.md @@ -0,0 +1,128 @@ +# Data Handling Policy + +## Redback Operations – ISO27001:2022 ISMS + +| **Document Code** | RO – POL - 006 | +| --- | --- | +| **Version** | 1.0 | +| **Document Owner** | Ethics / GRC Team | +| **ISO27001 Reference** | Annex A Controls 5.12, 5.13, 5.14, 5.33, 5.34, 7.10, 8.10, 8.13 | +| **Review Interval** | Start of each trimester | + +--- + +## Purpose + +This policy establishes the mandates for data handling within Redback Operations. The policy entails are assets are stored, transmitted, secured and disposed. Data is to be handled consistently based on its sensitivity. This policy is established due to the procedures of Redback Operations with a dedicated Data Warehouse team, Private AI platform and software development. + +## Scope + +This policy is applicable to the following stakeholders: + +- Active Redback Operations members +- All data that is collected and utilised by Redback Operations +- Systems that are in place that specifically handles information and data, such as the Data Warehouse's architecture. + +## Data Classification + +Data assets within Redback Operations are assigned a classification level. This determines what controls are applied to the data and how it must be handled if there is an incident. + +| **Classification** | **Definition** | **Examples** | **Controls Required** | +| --- | --- | --- | --- | +| **Confidential** | **Data that would cause harm to Redback Operations if leaked or exposed.** | **Credentials, API Keys or Tokens, Personally Identifiable Information, Database information,** | **Encryption at rest, Offboarding access to information, Access Control** | +| **Internal** | **Data that is only utilised within Redback Operations only. Not to be shared with public.** | **Documentation including policies, procedures or onboarding files. Communication between members** | **Access is available to only Redback Operations members. Secured within non-public facing systems** | +| **Public** | **Data available to the public** | **Source code. GitHub repositories. Company description and information.** | **Information must be reviewed before being made public.** | + +## Data Storage + +Data must be stored in systems relevant to their classification level. Different levels equate to different mandates on the security of storage. + +| **Classification** | **Storage method** | **Restricted storage** | **Encryption method** | +| --- | --- | --- | --- | +| **Confidential** | Virtual Machines supervised by Deakin IT. Security managed platforms. | Personal cloud storage. Public repositories. Present in communication channels. | Yes, at rest and in transit, | +| **Internal** | Virtual Machines supervised by Deakin IT. Security managed platforms. University managed programs. | Personal cloud storage. Public facing platforms such as GitHub or Docusaurus. | In transit. | +| **Public** | Appropriate GitHub repositories. Any public platform. | No Restrictions | Not Needed | + +### Personal Devices + +Confidential data is restricted on personal devices. Internal data can only be stored on personal devices if there are no other platforms to store information on. If a student has personal information relating to Redback Operations, offboarding must dictate that they will need to delete the information when concluding. + +### GitHub Repository Storage + +GitHub repositories are only storage for source code and approved documentation. The following information should not be stored in the company's repositories: + +- Credentials, including username and passwords. +- API Keys or tokens. +- Personally Identifiable Information +- Private keys or certificates. + +## Data Transmission + +### Encryption in Transit + +All data classified under Confidential must be encrypted in transit. For example, communications must be undertaken utilising encrypted channels or methods. MQTT broker connections via HiveMQ must utilise TLS. API communications should only use HTTPS. + +### Email and Communication Restrictions + +Confidential information and data should not be carried over messaging platforms. Redback Operations primarily utilises emails and Microsoft Teams as its communication platforms. Internal data can be transmitted over Teams but not be shown to the public. + +### External Sharing + +Confidential or Internal Redback Operations data cannot be shared with external or public parties without approval from the respective team tutor. External is defined as those not employed within Redback Operations. + +## Data Retention + +### Retention length + +Data should only be retained or kept for its intended purpose. + +- Active project data: retained for the duration of the project. +- Security audit findings and incidents: retained for at least two trimesters to support strengthening and continuity. +- Policy Documents and ISMS components: remains indefinitely and must be version-controlled to ensure governance. +- Onboarding and access records: retained for the trimester and one trimester after offboarding. +- Backup Data: retained according to Data Warehouse's backup schedule. + +### Trimester Rotation Consideration + +Redback Operations operates on a trimester rotation. All active project data has to be reviewed at the end of each trimester. Data that is not required should be disposed in accordance with Section 7. + +## Data Disposal + +### Secure Disposal Requirements + +When data is no longer required, it must be disposed of securely. + +- Digital data must be permanently deleted from all storage locations, which includes repositories or information in Data Warehouse's lakehouse architecture. +- Data deleted from a repository does not result in secure disposal as the information will still be present in commit histories. Ensure that the repository history is reviewed. +- Personal devices utilised in Redback Operations' procedures should have their project data removed upon offboarding. + +### Offboarding Data Removal + +As a requirement of the offboarding process, offboarding students should confirm that they have deleted all Confidential data related to Redback Operations from their personal devices. The Ethics / GRC team have the responsibilities of confirming this in the offboarding register. + +## Special Data + +### Private AI Platform Data + +The Data Warehouse's Private AI model collects and processes data from Redback Data, for the purposes of querying and automation. The AI processes information sensitive to Redback Operations and therefore these requirements are set out: + +- The data sources that the AI platform derives its from must be verified and approved by the Ethics / GRC team. +- Data sources containing PII must be approved and have the relevant controls. +- Outputs generated by this A.I must not be treated as authoritative without verifying the information. +- Access to the AI platform is only permitted to the Data Warehouse team. + +### Personally identifiable Information (PII) + +PII is defined as data that can identify someone. Redback Operations does not specifically collect PII but can be present in sensor data, onboarding records or development tools. PII is to be classified under Confidential level and handled in accordance to the Australian Privacy Act 1988. PII must never be hardcode or committed in any repositories. PII that is utilised in testing should be anonymous. Any breaches of PII should be reported to the Ethics / GRC Team as a Critical Incident, reporting to those relevant. + +## Access Controls for Data + +Access to data must be governed by the Access Control Policy (RO-POL-002). It must be governed by the principles of least privilege and need-to-know. + +## Data Breach Incident Response + +Any suspected or confirmed incidents relating to loss or corruption of Redback Operations' data must be reported to the Ethics / GRC Team. The Incident Response Policy (RO-POL-004) lays out the steps for incident response of the data. + +## Policy Review + +This policy must be reviewed at the start of each trimester by the Ethics / GRC Team. The review must assess any new data classification or types, systems or tools introduced in that trimester. Any changes must be version-controlled, dated and approved before taking effect. diff --git a/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-SOA-001-Statement-of-Applicability.md b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-SOA-001-Statement-of-Applicability.md new file mode 100644 index 00000000..5fc5a7b5 --- /dev/null +++ b/docs/company-policy/ISO27001:2022 Aligned ISMS T1 2026/RO-SOA-001-Statement-of-Applicability.md @@ -0,0 +1,157 @@ +# Statement of Applicability + +## Redback Operations – ISO27001:2022 ISMS + +| Document Code | RO – SOA – 001 | +| --- | --- | +| Version | 1.0 | +| Document Owner | Ethics / GRC Team | +| ISO Reference | ISO/IEC 27001:2022 – Annex A | +| Prepared By | Ramon Garcia – Ethics / GRC Team Lead | + +--- + +## Purpose + +This Statement of Applicability documents the 93 controls that are from Annex A, ISO: IEC27001:2022. It declares whether each control is applicable, partially applicable or not applicable to Redback Operations. It also provides a justification as to why that control is relevant / not relevant to the company. This is a mandatory document as per the ISO:IEC27001:2022 ISMS. + +## Scope + +This SoA is applicable to all assets, systems and members of Redback Operations that is defined within the scope statement document (RO-ISMS-001). + +## ISMS Document Suite Relevance + +The applicability decisions in this SoA are informed by the following Redback Operations ISMS documents: + +- RO-POL-001 – Information Security Policy +- RO-POL-002 – Access Control Policy +- RO-POL-003 – Acceptable Use Policy +- RO-POL-004 – Incident Response Policy +- RO-POL-005 – Secure Development Policy +- RO-POL-006 – Data Handling Policy +- RO-ISMS-001 – ISMS Scope Statement +- RO-REG-001 – Asset Register +- RO-REG-002 – Risk Register +- RO-AUDIT-GIT-001 – GitHub Audit Report +- RO-CL-001 – Onboarding & Offboarding Procedure + +## Applicability Summary + +| **Applicable** | **55** | +| --- | --- | +| **Partial** | **11** | +| **Not Applicable** | **27** | +| **Total Controls** | **93** | + +## Status Legend + +| **Applicable** | Control is applicable and implemented or planned within this trimester. | +| --- | --- | +| **Partial** | Control is applicable but only partially implemented; noted in Gap Analysis. | +| **Not Applicable** | Control does not apply to Redback Operations. Justification provided. | + +## Annex A Controls + +| **Control ID** | **Control Name** | **Status** | **Justification & Implementation Evidence** | +| --- | --- | --- | --- | +| **5 – Organisational Controls** | | | | +| **5.1** | Policies for information security | **Applicable** | Redback Operations operates on a rotational basis every trimester, continuity is necessity for Redback Operations' security posture, therefore policies are established and maintained. Information Security Policy is present and available to all Redback Operations Members. The Acceptable Use Policy, Secure Development Policy, Access Control Policy and Data Handling Policy is present in the ISMS suite as well. | +| **5.2** | Information security roles and responsibilities | **Applicable** | Students' roles change per trimester, therefore, the role they are assigned needs to have established responsibilities. Roles are defined across the ISMS suite. Ethics / GRC, Blue Team, SecDevOps, Team Leads and their corresponding team members are defined. Their responsibilities are documented in the Access Control Policy and Incident Response Policy. | +| **5.3** | Segregation of duties | **Applicable** | Different students have different responsibilities as per their role in Redback Operations. Separation of duties is documented in the Access Control Policy. No single student controls an entire system. | +| **5.4** | Management responsibilities | **Applicable** | Deakin staff are the leading figures in Redback Operations due to it being a student-driven company needing supervision whilst the Ethics / GRC team holds ISMS ownership. The tutor and unit chair are established as individuals for escalation. Defined in the Incident Response Policy. | +| **5.5** | Contact with authorities | **Partial** | Deakin staff such as the tutor or unit chair are the escalation points. There is no formal external authority contact procedure. | +| **5.6** | Contact with special interest groups | **Not Applicable** | Redback Operations is a student capstone company; they do not engage with external groups. | +| **5.7** | Threat intelligence | **Not Applicable** | No formal threat intelligence system is defined. Not applicable to Redback Operations it is out of scope and not at that maturity level. | +| **5.8** | Information security in project management | **Applicable** | This control applies to Redback Operations specifically as we have publicly facing repositories and a rotational nature with students. Policies include principles such as Secure by design and Need to Know, policies are established since there are no 'long-time' developers in the company. | +| **5.9** | Inventory of information and other associated assets | **Applicable** | Asset Register is established with classification, ownerships, risks and controls across all of Redback Operations. Control is applicable to Redback Operations as the company handles physical and digital assets and also important to track assets that are handled by Deakin but utilised by Redback. | +| **5.10** | Acceptable use of information and other assets | **Applicable** | Redback Operations handles sensitive information and controls publicly facing repositories. Utilisation of an Acceptable Use Policy (RO – POL – 001) is present in the ISMS suite in order to state appropriate use of Redback's systems and assets. | +| **5.11** | Return of assets | **Applicable** | Offboarding Procedure ( RO – CL – 001) requires handover and deletion of local data from personal devices. Applicable to Redback due to their rotational nature, emphasising the necessity for offboarding. | +| **5.12** | Classification of information | **Applicable** | In Data Handling Policy and Asset Register, information is categorised into Confidential, Internal and Public and what each criteria means. Applicable to Redback due to handling sensitive information and having to maintain security awareness of data across all students, across all trimesters. | +| **5.13** | Labelling of information | **Partial** | Classifications levels are defined and applied in Asset Register however there are no formal labelling conventions on systems, assets and repositories. Suggestion for next cohort. | +| **5.14** | Information transfer | **Applicable** | Data Handling Policy establishes the restrictions for transferring sensitive data via communication channels. Acceptable Use Policy restricts sharing of credentials and confidential information. Applicable to Redback as we primarily use Microsoft Teams or email secondarily, under Deakin student accounts. | +| **5.15** | Access control | **Applicable** | Access Control Policy covers least privilege, need-to-know, MFA and system specific controls. Team-based ownership is also present in policies. Applicable to Redback as the company does not have a centralised access control management system but is instead delegating responsibilities to Team leaders. Established in ROCII as implementing streamlined process for next cohort. | +| **5.16** | Identity management | **Applicable** | GitHub is managed per trimester. Onboarding and Offboarding Procedure establishes standards for access and revocation of systems. Applicable to Redback due to its rotational nature, leaving potential for shadow identities and accounts maintaining access. | +| **5.17** | Authentication information | **Applicable** | MFA is mandatory in Access Control Policy. Credentials are not to be shared or hardcoded, Personal Access Tokens are managed in Access Control Policy and Secure Development Policy. | +| **5.18** | Access rights | **Applicable** | Access onboarding and offboarding management in RO-CL-001. Access review is established as having to be done at the start of each trimester, present in Access Control Policy. Applicable to Redback specifically as rotational nature leaves potential for unnecessary stale access. | +| **5.19** | Information security in supplier relationships | **Not Applicable** | Redback Operations does not engage with formal suppliers. Tools are open-source or licensed through Deakin. | +| **5.20** | Addressing security within supplier agreements | **Not Applicable** | Redback Operations does not engage with formal suppliers and thus does not need to evaluate security within agreements as there are none. | +| **5.21** | Managing security in the ICT supply chain | **Not Applicable** | No ICT supply chain is managed by Redback. No formal third-party suppliers to assess security risks and mitigations. | +| **5.22** | Monitoring, review and change management of supplier services | **Not Applicable** | Supplier services are out of scope for Redback Operations, therefore no necessity for this control. | +| **5.23** | Information security for use of cloud services | **Partial** | Personal cloud storage is prohibited for confidential data as defined in the Data Handling Policy. Cloud storage classifications are defined in the DHP. No formal baseline for cloud services and its security. | +| **5.24** | Information security incident management planning and preparation | **Applicable** | Incident Response Policy defines severity levels, roles, escalation paths and a response procedure. Incident Register template is included. | +| **5.25** | Assessment and decision on information security events | **Applicable** | In Incident Response Policy, classification framework is defined. Critical /High /Medium and Low. | +| **5.26** | Response to information security incidents | **Applicable** | Six-phase incident response procedure (Identification, Logging, Containment, Investigation, Remediation, Lessons Learned) is defined in the Incident Response Policy. | +| **5.27** | Learning from information security incidents | **Applicable** | Lessons Learned Phase is mandated in the IRP as Phase 6. Findings are shared with teams and Incident Register is updated for continuity. | +| **5.28** | Collection of evidence | **Applicable** | Evidence preservation is required as documented in the Incident Response Policy. Commit History, access logs, Wazuh Logs, Screenshots and communications must be preserved during incidents as per the IRP. | +| **5.29** | Information security during disruption | **Not Applicable** | Business continuity / disaster recovery planning is outside the scope for Redback Operations. No production systems operated. | +| **5.30** | ICT readiness for business continuity | **Not Applicable** | No business continuity programme maintained. Redback Operations does not operate critical production infrastructure. | +| **5.31** | Legal, statutory, regulatory and contractual requirements | **Applicable** | Information Security Policy commits to adherence to Victorian Law and Deakin University policies. Acceptable Use Policy references licensing compliance for software. Applicable to Redback due handling information and under Deakin University as a capstone company. | +| **5.32** | Intellectual property rights | **Applicable** | Acceptable Use Policy prohibits sharing of confidential source code and documentation externally. Repositories default to private as per the Access Control Policy. AUP mandates the use of only open-source or licensed software. D2L Modules outline education on IP. | +| **5.33** | Protection of records | **Applicable** | ISMS Documents are shared in GitHub Repository or Docusaurus wiki. Incident and Asset Registers are maintained by Ethics / GRC Team. Data Handling Policy defines retention requirements. Applicable to Redback as ISMS suite covers registers that the company has sensitive information on. | +| **5.34** | Privacy and protection of PII | **Applicable** | PII is classified as confidential in Asset Register and Data Handling Policy. IRP includes specific scenarios for PII exposure in repositories. Secure Development Policy prohibits hardcoded PII. Applicable to Redback Operations due to its presence of PII from individuals who participate in the testing of Redback's projects. | +| **5.35** | Independent review of information security | **Partial** | GitHub audit was conducted (RO – AUDIT – GIT – 001). Internal audit checklist is planned for next cohort. Independent external audit is not feasible for Redback Operations. | +| **5.36** | Compliance with policies, rules and standards | **Applicable** | Non-compliance consequences defined in all policies. Escalation to unit chair and tutors are documented. Applicable to Redback specifically as Deakin Staff are supervising students, ensuring no harm is done to Redback Operations' systems and assets. | +| **5.37** | Documented operating procedures | **Applicable** | Onboarding and Offboarding Procedure provides step-by-step checklist. Applicable to Redback specifically due to its trimester-based rotation. | +| **6 – People Controls** | | | | +| **6.1** | Screening | **Not Applicable** | Student enrolment and background screening is managed by Deakin University, Redback Operations does not handle or have the authority to conduct student screening. | +| **6.2** | Terms and conditions of employment | **Applicable** | Member acknowledgement form required at onboarding as per the Acceptable Use Policy. Members acknowledge and accept ISMS policies before access is granted. | +| **6.3** | Information security awareness, education and training | **Applicable** | Policy briefing is mandated at onboarding. Security awareness / Ethics modules referenced on D2L. Applicable to Redback due to not all students having a security background. | +| **6.4** | Disciplinary process | **Applicable** | Non-compliance repercussions are defined across all policies. Formal disciplinary authority is held by Deakin University. | +| **6.5** | Responsibilities after termination or change of employment | **Applicable** | Offboarding Procedure dictates deletion of local data and revocation of all access during conclusion of enrolment. AUP prohibits retention of data after enrolment. | +| **6.6** | Confidentiality or non-disclosure agreements | **Partial** | Member acknowledgment form covers policy acceptance. There are no formal NDA in place. | +| **6.7** | Remote working | **Applicable** | Acceptable Use Policy governs personal device use for remote work for Redback Operations. Members required to use updated devices with anti-virus whilst not having local storage of sensitive information. Applicable to Redback Operations since there is no on-site premises to utilise company computers, students utilise their own devices. | +| **6.8** | Information security event reporting | **Applicable** | All members are required to report incidents to the Ethics / GRC team via Microsoft Teams. Reporting obligations are defined in the Incident Response Policy. Applicable to Redback Operations since a clear policy on how to report incidents is needed to ensure that the same procedure is followed per trimester. | +| **7 – Physical Controls** | | | | +| **7.1** | Physical security perimeters | **Not Applicable** | Physical environment is out of scope per the Scope Statement. Redback Operations is not responsible for the control or management of the physical premises used by members. | +| **7.2** | Physical entry | **Not Applicable** | Physical entry controls are managed by Deakin University, outside of scope of Redback operations. | +| **7.3** | Securing offices, rooms and facilities | **Not Applicable** | Redback Operations does not manage or own facilities. | +| **7.4** | Physical security monitoring | **Not Applicable** | Redback Operations does not have any physical security monitoring devices or controls. If accessing VM stored at Deakin University, Deakin University is responsible for physical monitoring. | +| **7.5** | Protecting against physical and environmental threats | **Not Applicable** | Environmental controls are managed by Deakin University. | +| **7.6** | Working in secure areas | **Not Applicable** | No dedicated secure areas operated by Redback Operations. | +| **7.7** | Clear desk and clear screen | **Applicable** | Acceptable Use Policy requires members to operate personal devices in a secure manner. This entails sharing screens when working on Redback Operations and leaving your device locked whilst unattended. | +| **7.8** | Equipment siting and protection | **Applicable** | Physical hardware handling guidelines are established in the AUP. Safe use, storage and reporting of loss or damage. Applicable to Redback Operations as projects have physical hardware such as bikes and Wahoo equipment. | +| **7.9** | Security of assets off-premises | **Applicable** | Acceptable Use Policy addresses personal device security for off-campus access. Applicable to Redback as every student has their own personal device. | +| **7.10** | Storage media | **Applicable** | Data Handling Policy defines storage requirements aligned with classification. Storage of sensitive information on the cloud or local is prohibited. Physical media containing sensitive information must not be retained after offboarding. | +| **7.11** | Supporting utilities | **Not Applicable** | Power and utility infrastructure is managed by Deakin University. Outside Redback Operations' scope. | +| **7.12** | Cabling security | **Not Applicable** | Network cabling infrastructure is managed by Deakin University. Outside Redback Operations' scope. | +| **7.13** | Equipment maintenance | **Applicable** | Acceptable Use Policy requires hardware to be utilised safely. Loss or damage must be reported to the Ethics / GRC team. Incident Response Policy also defines what to do when physical hardware loss or theft is an incident. Applicable to Redback Operations as multiple teams have physical assets such as Metaverse VR headset and Raspberry PI modules. | +| **7.14** | Secure disposal or re-use of equipment | **Partial** | E-Waste Battery Extraction team handles hardware disposal as a project focus. Formal secure disposal procedure for Redback-managed equipment is not documented. | +| **8 – Technological Controls** | | | | +| **8.1** | User end point devices | **Applicable** | Acceptable Use Policy requires end point devices to be installed with anti-virus and updated regularly. Any misuse is reported to the Ethics / GRC team. Confidential data cannot be stored locally. Applicable to Redback Operations as personal devices are the only form of devices used to access Redback systems. | +| **8.2** | Privileged access rights | **Applicable** | Admin access and tutors are the only ones with admin rights on GitHub. Privileged access is audited each trimester as per the access control policy. Applicable to Redback Operations as students belonging to certain sub-teams are the only ones responsible for GitHub management and Entra ID access management. | +| **8.3** | Information access restriction | **Applicable** | Members are restricted to team repository only for editing as per the Access Control Policy. Need-to-know principle is enforced. Applicable to Redback Operations as students in Project Orion does not need access to Wazuh Logs. | +| **8.4** | Access to source code | **Applicable** | Repository access is only restricted to team members. However public viewing is available. Branch protection is active with PRs needing reviews before merge. No student can approve their own request. Applicable to Redback Operations due to its reliance on GitHub and SecDevOps team reviewing pull requests. | +| **8.5** | Secure authentication | **Applicable** | MFA is compulsory across GitHub, Entra ID and HiveMQ as per the Access Control Policy. MFA has to be enabled within 5 days of enrolment as per the enrolment as per the policy. Applicable to Redback Operations due to its trimester based rotation, findings of stale accounts mandate MFA. | +| **8.6** | Capacity management | **Not Applicable** | Infrastructure capacity is not managed by Redback Operations. It is managed by Deakin University IT. | +| **8.7** | Protection against malware | **Applicable** | Acceptable Use Policy requires anti-virus on personal devices. The policy also restricts installation of malware. Malware is treated as critical as per the IRP. | +| **8.8** | Management of technical vulnerabilities | **Applicable** | Dependabot mandatory across all repositories as per the Secure Development policy. Trivy scanner required as well. GitHub Audit document found open vulnerabilities. OWASP TOP 10 is in code review checklist. | +| **8.9** | Configuration management | **Partial** | Secure-by-default principle is documented in Secure Development Policy. GitHub repository defaults defined in Access Control Policy. Formal configuration baseline is not present within Redback Operations yet. Applicable to Redback Operations as there Orion utilises FastAPI and security management tools. | +| **8.10** | Information deletion | **Applicable** | Offboarding procedures mandates the deletion of local data derived from Redback Operations on personal devices. | +| **8.11** | Data masking | **Not Applicable** | No publicly facing production systems with live personal data is present. Data masking is not required. | +| **8.12** | Data leakage prevention | **Partial** | Push protection is necessary in Incident Response Policy for credential exposure incidents. However, there are no formal DLP tools utilised. Applicable to the company as we utilise publicly facing repositories. | +| **8.13** | Information backup | **Partial** | ISMS is stored in GitHub or Docusaurus. Data Warehouse team utilises Restic for backups of their lakehouse architecture. No formal back up policy. | +| **8.14** | Redundancy of information processing facilities | **Not Applicable** | Redback Operations does not have any information processing facilities. | +| **8.15** | Logging | **Applicable** | GitHub activity logs and Wazuh security logs are established as evidence in the Incident Response Policy. Evidence preservation requirements are established in the IRP as well. | +| **8.16** | Monitoring activities | **Applicable** | Acceptable Use Policy defines reviewing GitHub activity logs and security scanning results whilst Blue Team manages Wazuh monitoring. | +| **8.17** | Clock synchronisation | **Not Applicable** | Clock synchronisation is per personal device and Deakin IT manages university supervised hardware. | +| **8.18** | Use of privileged utility programs | **Applicable** | Access to security tooling is only to Blue Team as per the Acceptable Use Policy. Workflow file changes are reviewed by SecDevOp through PRs as per the Acceptable Use Policy. | +| **8.19** | Installation of software on operational systems | **Applicable** | Acceptable Use Policy mandates only open-source or licensed software must be utilised for Redback operations systems. Dependency sources need to be official as per the Secure Development Policy. | +| **8.20** | Networks security | **Not Applicable** | Network security is handled by the Deakin IT team for VMs and Deakin managed software. Network is managed by ISPs for personal devices. | +| **8.21** | Security of network services | **Not Applicable** | Network services are managed by Deakin University IT for devices on network premises. Redback Operations does not manage security of network services. | +| **8.22** | Segregation of networks | **Not Applicable** | Network segregation is managed by Deakin University IT Team for devices on university premises and ISPs for personal devices. | +| **8.23** | Web filtering | **Not Applicable** | Web filtering is managed by ISPs and by Deakin University IT staff for devices on university premises. | +| **8.24** | Use of cryptography | **Applicable** | The Data Handling Policy mandates encryption at rest and in transit for data that is given the Confidential classification. | +| **8.25** | Secure development lifecycle | **Applicable** | The SDP lists security by design, secure by default, defense in depth and least privilege to be practiced in Redback Operations. The OWASP 10 and a PR checklist is also in the review process. | +| **8.26** | Application security requirements | **Applicable** | Input validation, error handling and OWASP Top 10 are checked in code reviews as per the Secure Development Policy. This is applicable to projects developing, such as Garmin Smartwatch. | +| **8.27** | Secure system architecture and engineering principles | **Applicable** | Defense-in-depth and security-by-design principles are listed in the Secure Development Policy. | +| **8.28** | Secure coding | **Applicable** | Language specific coding standards are defined for Python, Monkey C and C# in the Secure Development Policy. PR Checklist for reviews also mandates secure coding. | +| **8.29** | Security testing in development and acceptance | **Applicable** | Trivy scanner and Dependabot is mandatory for all repositories. OWASP TOP10 review is required. | +| **8.30** | Outsourced development | **Not Applicable** | All development is done by the students in Redback Operations. | +| **8.31** | Separation of development, test and production environments | **Partial** | Main branch protection rules are defined in the Access Control Policy and Secure Development Policy. However, there are no formal separation processes of dev/test/prod environments. | +| **8.32** | Change management | **Applicable** | Pull request review process mandatres review before any code is merged into the repository. Workflow file changes is to be reviewed by SecDevOps and signed off. Policy changes are also version-controlled and dated. | +| **8.33** | Test information | **Not Applicable** | No production data is used in testing environments. Test data is synthetic or project generated. | +| **8.34** | Protection of information systems during audit testing | **Partial** | GitHub audit is conducted. A formal audit procedure company wide is not documented, next cohort should communicate with tutors on how to do so. | + +## Document Review + +The Statement of Applicability must be reviewed at the start of each trimester by the Ethics / GRC team. Any changes to the ISMS document suite, scope or systems will require the SoA to be revised. All changes must be version-controlled and dated.