最小可行安全產品的檢查清單

banq發表於2021-11-04

最小可行安全產品是 B2B 軟體和業務流程外包供應商的簡約安全檢查表。
設計時考慮到了簡單性，清單僅包含必須實施的那些控制措施，以確保產品的安全狀態最低限度。
我們建議所有構建 B2B 軟體或以其他方式處理其最廣泛定義下的敏感資訊的公司至少實施以下控制措施，並強烈鼓勵在其安全計劃中遠遠超出這些控制措施。
 

1 業務控制
控制描述
1.1 漏洞報告

  • 在您的網站上釋出安全報告的聯絡人
  • 在合理的時間範圍內響應安全報告


1.2 客戶測試
  • 根據要求，讓您的客戶或其代表能夠測試您的應用程式的安全性
  • 如果非生產環境在功能上與生產環境非常相似，則在非生產環境上進行測試
  • 確保非生產環境不包含生產資料


1.3 自我評估使用本文件進行年度（至少）安全自我評估
1.4 外部測試與安全供應商簽約，對您的系統進行年度全面的滲透測試
1.5 培訓為您的員工實施與其業務職能相關的特定角色安全培訓
1.6 合規性
  • 遵守與您的業務相關的所有行業安全標準，例如 PCI DSS、HITRUST、ISO27001 和 SSAE 18
  • 遵守適用於您的公司和您的客戶的司法管轄區的當地法律和法規，例如 GDPR、具有約束力的公司規則和標準合同條款


1.7 事件處理
  • 不遲於發現後 72 小時通知您的客戶有關違規的資訊，不得無故拖延
  • 在通知中包含以下資訊：
    • 相關聯絡人
    • 漏洞的初步技術分析
    • 具有合理時間表的補救計劃


1.8 資料清理確保實施基於 NIST SP 800-88 或同等標準的媒體清理流程
 

2 應用設計控制
控制描述
2.1 單點登入使用現代和行業標準協議實現單點登入
2.2 僅HTTPS

  • 將流量從 HTTP 協議（​​埠 80）重定向到 HTTPS（埠 443）
    這不適用於旨在在未加密連線之上執行的安全協議，例如 OCSP
  • 使用廣泛採用的 TLS 掃描工具生成清晰的掃描
  • 使用includeSubdomains指令在所有頁面上包含 Strict-Transport-Security 標頭


2.3 內容安全政策設定最低限度的內容安全策略
2.4 密碼政策如果除單點登入外還使用密碼身份驗證：
  • 不限制可以使用的允許字元
  • 不要將密碼的長度限制在 64 個字元以下
  • 不要使用秘密問題作為唯一的密碼重置要求
  • 要求對密碼更改請求進行電子郵件驗證
  • 更改密碼時除了新密碼外還需要當前密碼
  • 根據常用密碼列表或洩露的密碼資料庫驗證新建立的密碼
  • 定期檢查現有使用者密碼是否洩露
  • 使用記憶體硬或 CPU 硬的單向雜湊函式以雜湊和加鹽格式儲存密碼
  • 對帳戶訪問實施適當的帳戶鎖定和暴力保護


2.5 安全庫使用框架、模板語言或庫，透過轉義輸出和淨化輸入來系統地解決實施弱點。
示例：用於資料庫訪問的 ORM，用於渲染 DOM 的 UI 框架
2.6 打補丁應用嚴重性評分為“中等”或更高的安全補丁，或確保在補丁釋出後的一個月內為應用程式堆疊的所有元件提供等效的緩解措施
2.7 記錄保留以下日誌：
  • 使用者登入和退出
  • 對應用程式和系統使用者和物件的讀、寫、刪除操作
  • 安全設定更改（包括禁用日誌記錄）
  • 應用程式所有者訪問客戶資料（訪問透明）


日誌必須包括使用者 ID、IP 地址、有效時間戳、執行的操作型別以及此操作的物件。日誌必須儲存至少 30 天，並且不應包含敏感資料或負載。
 2.8 備份與容災
  • 將所有資料安全備份到應用程式執行位置以外的其他位置
  • 維護並定期測試災難恢復計劃
  • 定期測試備份恢復


2.9 加密使用可用的加密方式來保護系統之間傳輸的敏感資料以及線上資料儲存和備份中的靜態資料
 

3 應用實施控制
控制描述
3.1 資料列表維護應用程式預期處理的敏感資料型別列表
3.2 資料流圖維護一個最新的圖表，表明敏感資料如何到達您的系統以及它最終被儲存在哪裡
3.3 漏洞預防培訓您的開發人員並實施開發指南，以至少防止以下漏洞：

  • 授權繞過。示例：從常規帳戶訪問其他客戶的資料或管理功能
  • 不安全的會話 ID。例子：Guessable token；儲存在不安全位置的令牌（例如，沒有設定安全和 httpOnly 標誌的 cookie）
  • 注射。示例：SQL 注入、NoSQL 注入、XXE、OS 命令注入
  • 跨站指令碼。示例：呼叫不安全的 JavaScript 函式、執行不安全的 DOM 操作、將使用者輸入回顯到 HTML 中而不轉義
  • 跨站請求偽造。示例：接受來自不同域的帶有 Origin 標頭的請求
  • 使用易受攻擊的庫。示例：使用具有已知漏洞的伺服器端框架或 JavaScript 庫


3.4 修復漏洞的時間在發現後 90 天內生成和部署補丁以解決嚴重影響安全性的應用程式漏洞。
 

4 運維控制
控制描述
4.1 物理訪問透過確保以下控制措施到位，驗證相關設施的物理安全：

  • 分層周界控制和內部障礙
  • 對金鑰的託管訪問
  • 進入和退出日誌
  • 入侵者警報的適當響應計劃


4.2 邏輯訪問
  • 僅限有合法需求的使用者訪問敏感資料。資料所有者必須授權此類訪問
  • 及時停用冗餘帳戶和過期的訪問許可權
  • 定期審查訪問以驗證需要知道的


4.3 分處理商
  • 在您的網站上釋出可以訪問客戶資料的第三方公司列表
  • 每年根據此基準對第三方公司進行評估

相關文章