需求

現在要重新設計產品核心架構, 先前只有套用OSCAL"概念", 現在要將正式的使用模式以及流程, 資料架構, 引入系統, 成為正式專業的 OSCAL GRC 系統 這邊整個捨棄原本討論的FR-037, 請用全新的需求進行 目前有幾個項目需要整個大調整

• 外部套件
• 主專案後端
• 主專案前端 如下

1. OSCAL 資料結構重新設計, jedi-oscal 整個砍掉重練, 進入v2.0, 符合OSCAL V1.2.2資料模型
   • 新版本的db schema 請參考 /Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be/docs/features/FR-037-2606-oscal-schema-gap-audit/oscal-catalog-and-roots-schema-v2.sql
   • 存放方式要依據正式的oscal物件以及欄位存放, 目前舊版本很多自定義欄位, 要調整完全符合oscal 物件的使用方式存放
   • 幫我設計一個專業的第三方套件模式, 可以被我的主專案運用, 因應各種情境讀寫資料給主專案使用
   • 不在原本jedi-oscal 下開發, 請新開一個新的套件資料夾 jedi-oscal-v2, 整個重新設計開發
   • 需要建立全新的model, db schema name 一樣先採用 oscalv2 後續完工會rename替代回oscal, 或是你建議直接drop oscal 重新建立也行, 開發資料庫會備份以及任意使用

2. 調整合規框架, 合規資源庫資料存放方式

合規框架

• 合規框架主檔: oscal.oscal_frameworks -> rename oscal.frameworks
• 合規框架版本: oscal.oscal_framework_versions -> rename oscal.framework_versions
• catalog主檔以及其關聯資料庫對應結構更新, 這邊請參考Outline:
  • catalog 主檔: catalogs(會對應一個framework_versions)
  • control group: catalog_groups
  • control: catalog_controls
  • assessment object(AO): catalog_parts
  • 其他欄位使用方式,請參考sql schema
• 匯入合規資源庫版本, 後面接的功能要調整成使用新的資料結構

合規資源庫

目前合規資源庫, 被設定為公版的稽核範本, 由專業的稽核顧問來制定以及維護自己的稽核範本, 會針對各種不同的稽核框架內容做設計, 當有客戶提出需求要協助做導入時, 就可以拿自有的合規資源庫, 來成立客戶專案, 輔導以及協助客戶完成整個稽核的流程

合規資源庫的調整, 目前會由三個物件組成

• catalog
• profile
• ssp(公用版本用) 相關規則邏輯如下:

1. 新增合規資源庫時, 會選擇一個framework_versions, 把該對應的catalog snapshot 一份起來, 給該合規資源庫用

2. 會依據profile的設定, 決定有多少控制項, AO 要被納入這份合規資源庫

3. 一樣要提供匯入ssp 功能, docx/excel 只是後面存放資料要改用新的資料庫架構

4. 新增專案的模式會改變, 會使用最新版本以及發布的合規資源庫, snapshot定版複製一份給專案使用, 該專案後續都是用這份合規資源庫下的 catalog, profile, ssp, 來往後作業,

5. 調整專案流程

專案流程

專案(project) -> 專案規劃(SSP) -> 稽核計畫(AP) -> 稽核(AS) -> 改善計劃(POA&M)

專案將會由下面幾個物件組成

• projects: 專案主檔, 會有專案的基本資料, 引用哪一個合規資源庫以及版本, 屬於哪一種稽核的導入
• project_audit_rounds: 專案稽核輪次, 每一輪的專案稽核紀錄, 舊的版本是用AP來做, 這設計是不對的, 改由新的table來替代, schema 參考下面, 有需要增加可以討論

id: int, auto_increse, pk
name: varchar(255), NN, 輪次名稱
round_no: int, 輪次編號
start_at: datetime, 開始時間
end_at: datetime, 結束時間
status: enum(尚未開始, 專案規劃種, 稽核規劃中, 稽核進行中, 改善計劃中, 結案), 狀態, 這邊參數可以討論
ssp_id: int, 關聯SSP, 可為null, 等到正式進入稽核階段SSP鎖定時,才會填入
created_at: datetime, 建立時間
updated_at: datetime, 最後更新時間
created_user: int, 建立人員
updated_user: int, 修改人員

• ssp 系統安全計劃: 每個專案會有一個主要的SSP, 這會是專案的本體, 他會被持續的維護內容, 直到PM決定目前的內容已經足以進行稽核了, 會做啟動稽核的動作 在還沒啟動稽核前, 都是對專案公版的SSP來做編輯, 啟動之後, 系統會將當前的SSP做定版的動作, 此時就不能夠再修改SSP的內容了, 也同樣會複製一份起來做定版, 填入該project_audit_rounds對應的SSP資料(例如ssp_id)

  • 原本UI上的一些資料, 請幫我依照OSCAL的規範, 寫入該對應的物件
    • 受評標的 → system-characteristics
    • 人員/單位 → parties + roles
    • 證據 → by-component.links → back-matter
    • 實施計劃 → props(planned 日期)
    • 實作狀態 → props(implementation-status)
    • 控制實作描述, SoA → implemented-requirement（一條控制一筆） ├─ props │ ├─ applicability ← SoA(適用性) │ ├─ inclusion-justification ← SoA(理由) │ └─ implementation-status ← 實作狀態 └─ statements[].by-components[] ├─ description ← 控制項實作描述 └─ links(evidence) ← 證據綁定

• ap 稽核計畫: 由稽核人員制定, 會提出他這次來稽核會要看什麼內容, 通常會在實際稽核前先給受檢單位, 讓他們提前準備 例如:

  • 要驗證控制項
  • 有哪些人, 設備, 服務, 地點要被稽核,
  • 什麼時間點
  • 會怎麼檢驗
  • 會用什麼工具或方式 目前的沒有這項流程, 要另外新增整個UI以及後端邏輯設計, 這邊請你建議做法, 請幫我參考外面專業產品或是OSCAL官方建議做法來做設計

• as 稽核結果:

  • 稽核人員會依照稽核計畫的內容, 填寫檢查結果, 判定每一條的檢查狀況
  • 依照判定結果, 填寫系統風險,並且由哪幾條組成風險
  • 目前沒有填寫判定系統風險的設計, 需要另外製作要討論

• poam 改善計劃:

  • PM會依據 AS 的 risk 來建立改善計劃, 設定milestone以及指派人員, 做限期改善
  • 等到確定都改善完畢後, 可以在啟動一個新的 audit_round, 但是是改善計劃用, 只會針對這次有缺失的項目做稽核
  • 這時候要進行公用版本的SSP維護, 將改善後的新證據, 以及提出說明補上, 再做一次稽核(覆核)
  • 結案判斷請幫我餐靠下面業務邏輯html教材

OSCAL官方參考資料

• 8大主要Object Outline: https://pages.nist.gov/OSCAL-Reference/models/v1.2.2/complete/json-outline/
• 各項Object JSON資料範例: https://github.com/usnistgov/oscal-content/tree/main/examples
• 完整schema 以及欄位說明: https://pages.nist.gov/OSCAL-Reference/models/v1.2.2/complete/json-reference/
• 物件介紹:
  • catalog: https://pages.nist.gov/OSCAL/learn/concepts/layer/control/catalog/
  • profile: https://pages.nist.gov/OSCAL/learn/concepts/layer/control/profile/
  • system-security-plan (SSP): https://pages.nist.gov/OSCAL/learn/concepts/layer/implementation/ssp/
  • assessment-plans (AP): https://pages.nist.gov/OSCAL/learn/concepts/layer/assessment/assessment-plan/
  • assessment-results (AR): https://pages.nist.gov/OSCAL/learn/concepts/layer/assessment/assessment-results/
  • plan-of-action-and-milestones (POA&M): https://pages.nist.gov/OSCAL/learn/concepts/layer/assessment/poam/
  • component-definition: https://pages.nist.gov/OSCAL/learn/concepts/layer/implementation/component-definition/
  • mapping-collection : https://pages.nist.gov/OSCAL/learn/concepts/layer/control/mapping/

業務邏輯

• docs/features/FR-038-2606-oscal-redesign/OSCAL_稽核生命週期_PM教材.html

我想要用多個Agent的模式平行開發, 麻煩你規劃任務的時候, 規劃成可以平行開發的模式, 要加快開發速度, 規劃完告訴我你會怎麼安排

• 先幫我分析這份整分需求, 開新的, ap, as, poam可能需要討論

• 後端: 不要被OSCAL舊的流程以及資料影響, 這次要整個大調整, 討論時可能要用新舊流程對照來做討論, 後端部分我自己初步分析基本上是要整個大改

• 前端: 合規框架, 合規資源庫, 專案, 專案總覽, 專案規劃, 任務執行, 到這幾階段UI應該是不會大更動 會改的應該是 AP, AR, POA&M 這幾個,

  AP的概念目前是完全沒有, 這邊應該是要另外做新的畫面

  AR的話只有一半, 目前是逐項填寫判定結果 但是應該還會有一個總結的動作 稽核人員應該會做總結, 列出你系統的風險, 然後是哪些項目造成這些風險的, 風險等級為何

  POA&M 應該是依照這些系統風險, 去設定改善計劃, 指派人員執行, 可以再從這邊發起新的一次稽核, 是針對改善用的, 只會針對要改善的項目來做稽核 這邊應該是小改,

  再麻煩你幫我分析跟判斷