---
# System prepended metadata

title: CSSLP
tags: [ISC2, CSSLP]

---

# CISSP - CSSLP
陳詰昌 Jeff Chen
power.shell@gmail.com

## 參考書籍
* CSSLP Certification All-in-One Exam Guide
* Official (ISC)2 Guide to the CSSLP CBK ((ISC)2 Press)
* Essential CSSLP Exam Guide: Updated for the 2nd Edition
* Certified Secure Software Lifecycle Professional Exam Questions and Dumps Latest Version : Exam Prep Tests for CSSLP

## 章節內容與比重
1. Secure Software Concepts 12%
    * General Security Concepts
    * Risk Management
    * Security Policies and Regulations
    * Software Development Methodologies
2. Secure Software Requirements 11%
    * Secure Software Requirements
    * Policy Decomposition
    * Data Classification and Categorization Requirements
3. Secure Software Design 13%
    * Secure Software Design
    * Design Processes
    * Design Considerations
    * Securing Commonly Used Architecture
    * Technologies 
4. Secure Software Implementation/Programming 15%
    * Secure Software Implementation/Programming
    * Common Software Vulnerabilities and Countermeasures
    * Defensive Coding Practices
    * Secure Software Coding Operations
5. Secure Software Testing 14%
    * Secure Software Testing
    * Security Quality Assurance Testing
    * Security Testing 
6. Secure Lifecycle Management 14%
    * General Security Concepts
7. Software Deployment, Operations, and Maintenance 11%
    * Software Deployment, Operations, and Maintenance
    * Secure Software Installation and Deployment
    * Secure Software Operations and Maintenance
10. Supply Chain and Software Acquisition 10%
    * Supply Chain and Software Acquisition

## 考試
* 時間：3小時
* 考題：125題

# Domain 1:安全軟體概念
## 1.1 - 核心概念
### 軟體開發方法
* 開發方法重要性
    * 提供結構化方法處理複雜問題
    * 改善品質並降低風險
    * 強化團隊間溝通
    * 增加彈性與效率
    * 使系統持續改善
#### SDLC
* 階段：規劃、分析、設計、開發、測試、佈署及維護
#### 開發方法
* 瀑布式
    * 傳統循序式
    * 需求明確
* 調適式（敏捷，可參閱PMP筆記）
    * 迭代與增量
    * 彈性與協作
    * 
* 迭代式（Prototyping）
    * 將專案切分為較小版本並分階段交付
    * 系統開發時以嘗試錯誤程序來降低風險
    * 可能風險是當系統完成時控制措施較差
    * 變更管理相對複雜
* RAD
* SAFe
    * 企業級敏捷
* 螺漩式
    * 風險驅動開發
### 軟體與授權形式 
#### 軟體產品類型
* COTS商用軟體(Commercial Off-The-Shelf)：如微軟Office
* 客制化軟體：為特定需求委外或自行開發
* 開源(open source)軟體：原始碼開放，使用者可以修改、分享及強化程式碼
* 專有(proprietary)軟體：原始碼封閉，限制存取來保護原始碼（如微軟Windows）
#### 授權類型
* 專屬proprietary:授權使用但限制修改與再傳播
* 開源open source：允許修改與再傳播
* 免費freeware：個人免費使用，但限制作為商業用途
* 共享shareware：購買前允許使用者試用
* 支持support license：廠商支援故障排除與更新

* 創意共享(Creative Commons)
* 著作傳(Copyleft):要求所有修改之後和延伸而出的程式版本都必須同樣自由
* 確保軟體持續開源並鼓勵協作
* OEM and Site licenses
* 允許製造商運送硬體與預先安裝軟體
* 授權軟體在特定位置或單位內無限使用
* SLA與支援層級
* 高層級較快反應時間，較低層級支持需要較久反應時間

### 軟體授權法規面向
### 軟體再造工程與逆向工程
### 命令式(imperative)與宣告式（declarative）程式rograming 
#### 命令式
* 定義：命令編程是開發人員明確指定計算機為達到結果所需的步驟，著重於描述程序的運行方式。
* 特性：
    1. 逐步指令：程式編寫為一序列命令用以改變程序狀態
    2. 流程控制：程序員必須明確管理控制流程
    3. 範例：C、C++、Java和Python等程式語言是命令式。例如，在一串數字求總和時，您會編寫一個迴圈以迭代對數字列進行累積加總
    4. 狀態變化：它通常涉及隨著時間的推移改變變量的狀態。 
```
pythonCopy codenumbers = [1, 2, 3, 4, 5]
total = 0
for num in numbers:
    total += num
print(total)
```
#### 宣告式
* 定義：宣告式編程是開發人員在無法明確指定程序如何完成的工作下，所以專注於結果而不是過程。
* 特性:
    1. 高階抽象：程式代碼表示邏輯而不描述控制流程
    2. 無明確狀態變化：內部狀態和控制流程通常由基礎系統處理
    3. 範例：SQL、HTML、CSS和功能編程語言（如Haskell、Python）使用SQLalchemy等函式庫進行資料庫查詢
    4. 簡潔：宣告代碼往往更簡潔，更易於根據所需結果進行推理。
```
pythonCopy codenumbers = [1, 2, 3, 4, 5]
total = sum(numbers)
print(total)
``` 
#### 主要差異
* 焦點：命令式編程與如何執行任務有關，而宣告式編程則重點關注任務本身
* 流程控制：命令式需要手動控製程式流程；宣告式以摘要抽象方式
* 狀態管理：命令式代碼通常會明確更改狀態，而宣告式代碼則最小化或隱藏狀態變化

#### 使用上下文
* 命令式：適用於需要對系統行為進行細粒度控制的情況。
* 宣告式：最終結果比如何實現的步驟更為重要，例如查詢語言或UI設計。
![image](https://hackmd.io/_uploads/ryixlspt1x.png)

### CIA
* 機密性(加密保護)
    * 非經授權無法取得
* 完整性(雜湊、數位簽章、 程式碼簽章、可靠性、修正與真實性)
    * 非經授權於儲存或傳輸過程中無法刪除或更改
* 可用性(備援、備份、叢集、彈性與韌性)
    * 想取得資訊時隨時可取得
* 不可否認性(數位簽章、區塊鏈)
    * 確保不能否認某件事的有效性
    * 不可否認性是法律上概念，用來確保資料來源與資料完整（真實性）
![image](https://hackmd.io/_uploads/HyND24pFyx.png)

### 3A
* 驗證Authentication
    * 驗證使用者是他所宣稱的那個人
    * 驗證3類型
        * Something you know：密碼
        * Something you have：Token
        * Something you are:生物特徵

* 授權Authorization
    * 經過驗證後授予某人使用資源或功能的權限
    * 常與存取控制(access control)或端點權限(privilege)交叉使用

* 審計Accountability
    * 審計原則是委託個人保管設備、密鑰和資訊，並對這些設備或資訊遺失或濫用向適當主管部門負責
    * 紀錄、監控及追蹤
    * 確保每一使用者的行為都可以被追溯

### GRC
* Governance, risk and compliance (GRC) standards (e.g., regulatory authority, legal, industry)

## 1.2 - 安全設計原則
1. 最小權限Least privilege
    * 將系統或使用者限制為完成分配任務所需的最低限度權限的安全原則
    * 設計安全體系結構時，每個實體授予其執行功能所需的最低系統資源和授權。
    * 在網路與系統安全中最重要的一項原則
    * 降低資料外洩、

2. 權責分離Segregation of Duties (SoD) 
    * 不管是在商業邏輯層級或是系統層級，都應該做到責任分離。例如：付款模組跟訂單模組應該要分開，前端介面跟後端資料庫要分開，各司其職。 這樣的原則跟出納跟會計要分開很像，責任分離避免安全性的疑慮。(e.g., multi-party control, secret sharing, split knowledge)

3. 縱深防禦Defense in depth (e.g., layered controls, geographical diversity, technical diversity, distributed systems)
4. 韌性Resiliency (e.g., fail safe, fail secure, no single point of failure, failover)
5. 機制經濟Economy of mechanism (e.g., single sign-on (SSO), password vaults, resource efficiency)
6. 完全中介Complete mediation (e.g., cookie management, session management, caching of credentials)
7. 開放設計Open design (e.g., Kerckhoffs’s principle, peer review, open source, crowd source)
8. 最少共通機制Least common mechanism (e.g., compartmentalization/isolation, allow/accept list)
9. 心理可接受度Psychological acceptability (e.g., password complexity, passwordless authentication, screen layouts, Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA))
10. 元件重複使用Component reuse (e.g., common controls, libraries)

# Domain 2:安全軟體需求（requirement）
1. 識別安全需求
2. 資料分類需求
3. 識別隱私需求
4. 建立誤用與濫用案例
5. 軟體需求規格內含安全需求
6. 安全需求追溯矩陣
## 2.1 - Manage security within a software development methodology (e.g., Agile, waterfall)

## 2.2 - Identify and adopt security standards (e.g., implementing security frameworks, promoting security awareness)

## 2.3 - Outline strategy and roadmap
Security milestones and checkpoints (e.g., control gate, break/build criteria)
## 2.4 - Define and develop security documentation

## 2.5 - Define security metrics (e.g., criticality level, average remediation time, complexity, Key Performance Indicators (KPI), objectives and key results)

## 2.6 - Decommission applications
End of Life (EOL) policies (e.g., credential removal, configuration removal, license cancellation, archiving, service-level agreements (SLA))
Data disposition (e.g., retention, destruction, dependencies)
## 2.7 - Create security reporting mechanisms (e.g., reports, dashboards, feedback loops)

## 2.8 - Incorporate integrated risk management methods
Regulations, standards and guidelines (e.g., International Organization for Standardization (ISO), Payment Card Industry (PCI), National Institute of Standards and Technology (NIST), Open Web Application Security Project (OWASP), Software Assurance Forum for Excellence in Code (SAFECode), Software Assurance Maturity Model (SAMM), Building Security in Maturity Model (BSIMM))
Legal (e.g., intellectual property, breach notification)
Risk management (e.g., risk assessment, risk analysis)
Technical risk vs. business risk
## 2.9 - Implement secure operation practices
Change management process
Incident response plan
Verification and validation
Assessment and Authorization (A&A) process



# Domain 1. 安全軟體概念
## 1.1 核心概念
### CIA
- **Confidentiality**
  - Covert channel: communication path that is intentionally hidden. Leaves almost no trace. Receiver has to be actively listening for message
  - Overt channel: communication path that is not hidden. Leaves evidence behind but receiver doesn't have to be listening for message
  - Side channel: unintentional communication. Think power consumption changes to get information about encryption used
- **Integrity**
  - Also includes stability and reliability for authorized subjects
- **Availability**
- **Authentication**
- **Authorization**
- **Accountability**
- **Nonrepudiation**

## 1.2 安全設計概念
- **Least Privilege**
- **Separation of duties**
- **Defense in depth**
- **Resiliency**
  - fail safe, fail secure, no single point of failure
- **Economy of mechanism**
  - less complexity is better
  - eliminate nonessential services and protocols
- **Complete mediation**
  - authorization cannot by bypassed
  - authorization checked every time subject requests access to an object
- **Open design**
  - security of a system is independent of the design (don't rely on security by obscurity)
  - Kerckhoffs's principle: security of a cryptosystem is reliant on choice of keys, not algorithm
- **Least common mechanism**
  - isolation to protect against sharing of information
- **Psychological acceptability**
- **Component reuse**
- **Diversity of defense**
  - layers of defense should be diverse
- **Safeguard**
  - _Proactive_ controls to protect assets
  - controls can be physical, administrative, or technical
- **Countermeasure**
  - _Reactive_ controls to protect assets
  - controls can be physical, administrative, or technical

# 2. 安全軟體要求
## 2.1 定義
- **功能性**
  - business requirements
  - use cases
  - user stories
- **非功能性**
  - operational
  - deployment
  - systemic qualities

## 2.2 識別與分析合規要求
- **FISMA**
  - an agency-wide information security program is required for federal agencies
- **Sarbanes-Oxley**
  - internal control measures for financial accounting
- **Gramm-Leach-Bliley**
  - protection of PFI (Personal Financial Information)
  - protects against falsely pretending to obtain PFI
- **HIPAA and HITECH**
- **Payment Card Industry Data Security Standard (PCI DSS)**

## 2.3 識別與分析資料分類要求
- **Data ownership**
- **Labeling**
  - sensitivity and impact
  - primarily driven by cost
- **Types of data**
  - structured, unstructured
  - categories: security sensitive, PII, hidden
- **Data life-cycle**
  - if persistent, data needs to be classified, labeled, assigned retention policy
  - retention policies include backups, DR sites, legal holds
  - legal hold data is excluded from normal disposal procedures

## 2.4 識別與分析隱私要求
- **Data anonymization**
- **User consent**
- **Disposition**
  - right to be forgotten
- **Data retention**
- **Cross borders**

## 2.5 建置濫用(abuse)與誤用(misuse)案例
- **Use cases**
  - helpful for clarifying complex/confusing/ambiguous situations
  - not intended for all subject-object relationships

## 2.6 建置安全要求追蹤矩陣(SRTM,Secure Requirement Traceability Matrix)
- document relationships between security requirements, controls, and test/verification efforts

## 2.7 確認安全要求落實至供應商

# 3. 安全軟體架構與設計
## 3.1 威脅塑模
- **Understand common threats**
- **Attack surface evaluation**
- **Threat intelligence**

## 3.2 定義安全架構
- **Security control identification and prioritization**
- **Distributed computing**
- **Service-oriented architecture**
- **Rich internet applications**
- **Pervasive/ubiquitous computing**
  - IOT
  - RFID
  - NFC
- **Embedded**
  - Field-programmable gate array (FPGA) security features
- **Cloud architecture**
- **Mobile applications**
- **Hardware platform concerns**
- **Cognitive computing**
  - machine learning, AI
- **Control systems**

## 3.3 安全介面設計
- **Security management interfaces, out-of-band management, log interfaces**
- **Upstream/downstream dependencies**
- **Protocol design choices**

### 3.4 架構風險評鑑

### 3.5 模型 (Non-Functional) 安全特性與限制

### 3.6 模型及資料分類

### 3.7 評估及選擇可重複使用安全設計

- **Credential management**
- **Flow control**
  - proxies, firewalls, protocols, queueing
- **Data loss prevention**
- **Virtualization**
- **Trusted computing**
- **Database security**
- **Programming language environment**
- **Operating system controls and services**
- **Secure backup and restoration planning**
- **Secure dat retention, retrieval, and destruction**

## 3.8 安全架構及設計審視

## 3.9 定義安全維運架構

## 3.10 安全架構與設計原則、模型及工具

# 4. 安全軟體執行
## 4.1 Adhere to Relevant Secure Coding Practices

- **Declarative vs imperative (programmatic) security**
- **Concurrency**
- **Output sanitization**
- **Error and exception handling**
- **Input validation**
- **Secure logging & auditing**
- **Session management**
- **Trusted/Untrusted APIs and libraries**
- **Type safety**
- **Resource management**
- **Secure configuration management**
- **Tokenizing**
- **Isolation**
- **Cryptography**
- **Access control**
- **Processor micro-architecture security extensions**

### 4.2 Analyze Code for Security Risks

- **Secure code reuse**
- **Vulnerability databases/lists**
- **Static application security testing**
- **Dynamic application security testing**
- **Manual code review**
- **Look for malicious code**
- **Interactive application security testing**

### 4.3 Implement Security Controls

### 4.4 Address Security Risks

- **Risk response**

### 4.5 Securely Reuse Third-Party Code or Libraries

### 4.6 Securely Integrate Components

- **Systems-of-systems integration**

### 4.7 Apply Security During the Build Process

- **Anti-tampering techniques**
- **Compiler switches**
- **Address compiler warnings**

# 5. 安全軟體測試

## 5.1 建立安全測試案例

- **Attack surface validation**
- **Penetration tests**
- **Fuzzing**
- **Scanning**
- **Simulation**
- **Failure**
  - break testing
  - fault injection: introducing faults to see how software behaves. Test error handling code paths
- **Cryptographic validation**
- **Regression tests**
- **Integration tests**
- **Continuous**
  - synthetic transactions: write code to mimic user behavior using a browser
  - real-user monitoring: collect data based on actual user data (e.g. Google Analytics)

## 5.2 建立安全測試策略與計畫

- **functional security testing**
- **nonfunctional security testing**
  - reliability
  - performance
  - scalability
- **testing techniques**
  - white box
  - black box
- **environment**
- **standards**
  - ISO
  - Open Source Security Testing Methodology Manual (OSSTMM)
  - Software Engineering Institute (SEI)
- **crowd sourcing**
  - bug bounty

## 5.3 確認與驗證文件

## 5.4 識別未記錄功能

## 5.5 分析測試結果的安全影響

## 5.6 分類與追蹤安全錯誤

- **Bug tracking**
- **Risk scoring**
  - CVSS

## 5.7 安全測試資料

- **Generate test data**
- **Reuse of production data**

## 5.8 執行確認與驗證測試

## 6. Secure Software Lifecycle Management

### 6.1 Secure configuration and version control

### 6.2 Define strategy and roadmap

### 6.3 Manage security within a software development methodology

### 6.4 Identify security standards and frameworks

### 6.5 Define and develop security documentation

### 6.6 Develop security metrics

### 6.7 Decommision software

- **End of life policies**
- **Data disposition**

### 6.8 Report security status

### 6.9 Incorporate integrated risk management (IRM)

### 6.10 Promote security culture in software development

### 6.11 Implement continuous improvement

## 7. Secure Software Deployment, Operations, and Maintenance

### 7.1 Perform operational risk analysis

- **Deployment environment**
- **Personnel training**
- **Safety criticality**
- **System integration**

### 7.2 Release software securely

- **Secure continuous integration and continuous delivery pipeline**
- **Secure software tool chain**
- **Build artifact verification**

### 7.3

- **Credentials**
- **Secrets**
- **Keys/certificates**
- **Configurations**

### 7.4 Ensure secure installation

- **Bootstrapping**
- **Least privilege**
- **Environment hardening**
- **Secure activation**
- **Security policy implementation**
- **Secrets injection**

### 7.5 Perform post-deployment security testing

### 7.6 Obtain security approval to operate

### 7.7 Perform information security continuous monitoring (ISCM)

- **Collect and analyze observable data**
- **Threat intel**
- **Intrusion detection/response**
- **Secure configuration**
- **Regulation changes**

### 7.8 Support incident response

- **Root cause analysis**
- **Incident triage**
- **Forensics**

### 7.9 Perform patch management

### 7.10 Perform vulnerability management

### 7.11 Runtime protection

### 7.12 Support continuity of operations

- **Backup, archiving, retention**
- **Disaster recovery**
- **Resiliency**

### 7.13 Integrate service level objectives and service level agreements

## 8. Secure Software Supply Chain

### 8.1 Implement software supply chain risk management

- **Identify**
- **Assess**
- **Respond**
- **Monitor**

### 8.2 Analyze security of third-party software

### 8.3 Verify pedigree and provenance

- **Secure transfer**
- **System sharing/interconnections**
- **Code repository security**
- **Build environment security**
- **Cryptographically-hashed, digitally-signed components**
- **Right to audit**

### 8.4 Ensure supplier security requirements in teh acquisition process

### 8.5 Support contractual requirements
