鳩小屋

落書き帳

CSSLP:Certified Secure Software Lifecycle Professional ~勉強中~

最近、(ISC)²のCSSLPの勉強も始めました。
現在の学習率は50%程度ですが中間報告です。

位置づけ

こちらはセキュリティ関連の国際資格マップです。

pauljerimy.com

いっぱいありますね。

冬に受けたCISSPはExpertカテゴリで範囲も広いですが、CSSLPはIntermediateカテゴリで範囲がソフトウェア開発に絞られています。
一見、CISSPの下位互換に見えなくもないのですが、求められる粒度間が異なり、CSSLPの方がより実践的、つまり実務者寄りの内容になっています。

一応補足をしておくと、セキュリティに限らず、職務はガバナンス、マネジメント、実務の層に分類できます。

ガバナンス層は、組織全体の方針やルールを決定することで、組織全体のかじ取りをする経営寄りの役割。(軍隊の将官)
マネジメント層はガバナンス層ほどではないものの、部門単位やPJ単位のかじ取りをする役割。(軍隊の尉官)
実務層は、実際に現場で設計をしたり、コードを書いたり、運用したりする役割。(軍隊の兵卒)

実務層は、さらにテクニック層・エンジニアリング層あたりに分類できるとおもいますが、比重は職種(開発職、運用職、研究職など)によって異なるかと思います。
・テクニック層は既存ノウハウを適切に実装・運用する役割。
・エンジニアリング層は新規の課題解決や新しい価値を生みだす役割。

話を戻すと、CISSPがガバナンス層、マネジメント層、テクニック層を浅く広くカバーするCISO向けの資格であるのに対して、CSSLPはテクニック層のソフトウェア開発に重点を置いた設計者、開発者、テスター、プログラム マネージャー向けの内容になっています。強いて類似資格との違いを挙げるとすれば、設計、実装、テストなどを広めにカバーしている点かもしれません。

~参考書より~
安全な開発ライフサイクルを構築するために必要なプロセスを作成および管理することは重要なタスクです。

ソフトウェアの脆弱性は防ぐことができます。ソフトウェアの脆弱性の数と深刻度を減らすことは簡単な作業ではありません。それは複雑で実⾏が難しいものです。
多数のソフトウェア開発会社での⻑年の経験により、ソフトウェア開発プロセスを改善する実証済みの⽅法が⽣まれました。
これらの原則を使⽤することで、開発チームは脆弱性の少ないソフトウェアを作成でき、⾒つかった脆弱性のリスクも低くなります。
これにより、開発ライフサイクル全体で開発の総コストが削減されます。
これにより、ソフトウェアのユーザーの全体的な企業セキュリティ体制も改善され、コストも削減されます。
リスクの軽減、コストの削減、顧客との関係の改善、および開発プロセスの改善による利点により、必要な困難なタスクを実⾏する価値があります。

ソフトウェア開発はチーム活動であり、企業内の⼀連のプロセスを必要とするものです。
セキュリティ重視の開発環境での運⽤に必要なタスクには、⾼度なスキルセットを持つ従業員が必要です。
チーム メンバーは、専⾨分野における個々のスキルに加えて、セキュリティが強化されたソフトウェア開発ライフサイクル プロセスがどのように機能するかを理解する必要があります。 
CSSLP の知識体系は、これらの重要な要素を網羅しており、設計者、開発者、テスター、プログラム マネージャーのいずれであっても、この知識体系はこの環境での運⽤に備えます。

所感

Amazon | CSSLP Certified Secure Software Lifecycle Professional Exam Guide (All-In-One) | Conklin, Wm. Arthur, Ph.D., Shoemaker, Daniel, Ph.d. | Testing

参考書の章構成(自動翻訳)は下記のとおりです。

第 1 章コアコンセプト
第 2 章セキュリティ設計の原則
第 3 章ソフトウェア セキュリティ要件の定義
第 4 章コンプライアンス要件の特定と分析
第 5 章誤⽤•乱⽤事例
第 6 章安全なソフトウェア アーキテクチャ
第 7 章安全なソフトウェア設計
第 8 章安全なコーディングの実践
第 9 章セキュリティ リスクについてコードを分析する
第 10 章セキュリティ制御の実装
第 11 章セキュリティ テスト ケース
第 12 章セキュリティ テストの戦略と計画
第 13 章ソフトウェアのテストと受け⼊れ
第 14 章安全な構成とバージョン管理
第 15 章ソフトウェアのリスク管理
第 16 章安全なソフトウェア展開
第 17 章安全なソフトウェアの運⽤と保守
第 18 章ソフトウェアサプライチェーンリスク管理
第 19 章サプライヤーのセキュリティ要件

第 10 章まで読みましたが、前述どおりの内容みたいです。

CISSPでは技術脅威、人的脅威、物理脅威、法的要件など、組織のリスクとなり得る要素を網羅的にカバーしていましたが、CSSLPの範囲はソフトウェア成果物や開発プロセスに限定される分、アプリケーション実装(メモリ空間、プロセス間通信など)にまで踏み込んでいる印象です。サーバルームの消火剤とか、武器輸出規制とか、合衆国憲法とか、知らんがなと叫んでしまいそうな内容が少ないところはありがたいですね。

具体例

参考程度ですがメモの一部抜粋です。
SBOM、RASP、IAST、宣言的セキュリティ、アジャイル開発、DevOpsなど、比較的新しい概念への言及もあり、実用性は高そうです。

⾝元確認(認証要素)

基本項目
• あなたが知っているもの(パスワードなど) 
• あなたが持っているもの(トークンなど)
• あなたについての何か  (指紋や虹彩パターンなどの静的⽣体認証)

新しい要素
• ユーザーの⾏動 (⼊⼒パターンや歩き⽅などの動的⽣体認証)
 • ユーザーがどこにいるか (実際の物理的な位置)

セキュリティ機能 != 安全なソフトウェア

ソフトウェア開発ライフサイクルにセキュリティ(安全)を追加して、作成中のソフトウェアのセキュリティ バグ(欠陥)の数を減らすことが重要。

セキュリティ機能:安全の⼀部を提供するために特別に設計されたプログラムの要素でしかない
品質機能:設計されたとおりに機能し、設計されたとおりにしか機能しないこと

脆弱性:機能仕様通りに動いているが悪性挙動がある。
品質欠陥(バグ):そもそも文書化されていない機能が存在する。意図しない機能がある。

ソフトウェア依存関係・コード再利用

継承するライブラリを使⽤して構築され、良い機能と悪い機能 (バグと脆弱性) の両⽅をもたらす可能性
安全な開発ライフサイクル (SDL) の各段階で、すべての依存関係が⽂書化されていることを確認することが不可⽋です。
ソフトウェア部品表(SBOM)と呼ばれる動きもあります。

コード再利用で時間が節約され、それによってコストが削減されます。また、再利⽤可能なパーツから⽣成されるコードの品質管理と標準レベルの機能も保証されます。
ただし、問題は、侵害された単⼀の再利⽤モジュールが、その後の広範なアプリケーションにリスクをもたらす可能性があることです。

シングル サインオン

資格情報をアプリケーションの外部に保存し、その資格情報を別のシステムに対して再利⽤する
Kerberos と Security Assertion Markup、Language (SAML) 
SSO ベースのシステムは、単⼀障害点のシナリオを作成する可能性があるため、リスクの⾼い特定の実装では、その使⽤は推奨されません。

動的リンク

依存関係の名前と相対位置をコードに配置することが含まれ、これらは実⾏時にすべての要素がメモリに読み込まれるときに解決されます。
動的リンクは、より⼩さなファイルを作成できますが、ハイジャックされた依存プログラムによるリスクを引き起こします。

型安全性

プログラムによるデータ型の管理を指し、厳密に型指定された⾔語がデータ型と型の処理における⼀貫性を強制

命令的セキュリティと宣⾔的セキュリティ

宣⾔的セキュリティ
達成すべきタスクに関して、プログラミングが何をどのようにではなく、何を指定するかを指定する

命令的セキュリティ
セキュリティの実装がコード⾃体に組み込まれています。これにより、セキュリティへのアプローチの粒度を⼤幅に⾼めることができます。
このタイプのきめの細かいセキュリティは、プログラムによる制御の下で使⽤でき、オール オア ナッシングのコンテナ ベースのアプローチでは不可能な複雑なビジネス ルールを適⽤できます。
コードの移植性や再利⽤性が低下する傾向があります。

⼼理的受容性

ユーザーが⼼理的に受け⼊れられるようにセキュリティの側⾯を設計する必要。使いやすさの考え⽅を、セキュリティ機能にも拡張する必要。

規制とコンプライアンス

企業内の多くの活動を推進
規則や規制を順守しないと、直接、場合によっては実質的な⾦銭的罰則につながる可能性があるという単純な事実
コンプライアンスの失敗は、精査の強化、将来の規制の強化、悪評など、追加のコストをもたらす可能性
従順であっても安全ではない場合があるため、コンプライアンスがセキュリティと同じではない

規制は、業界団体、貿易団体、政府機関など、いくつかのソースからもたらされる可能性があります。違反に対する罰則もさまざまであり、違反の重⼤度に基づく場合もあれば、政治的要因に基づく場合もあります。

スクリプト キディ

攻撃者の最も基本的な形態を表すために使⽤されます。
攻撃コミュニティの 80 〜 85% を占めると⾒られています。
攻撃ベクトルは既知であり、通常、これらの攻撃が⽬的を達成するのを防ぐための特定の防御策があります。
悪いニュースは、それらの数が⾮常に多いため、対処しなければならないレベルのバックグラウンド ノイズが発⽣し、管理するリソースが必要になることです。

エリートハッカー

攻撃⼈⼝全体のわずか 1 〜 3% です。このグループを際⽴たせる重要な要素は、ほとんどのユーザーが不可能と考えるスキル レベルを持つ真のスキル ベースです。
このレベルに⼊るのに不可⽋なスキルの 1 つは、⾃分の痕跡を事実上検出および追跡不可能にするまでカバーするスキルです。
このグループは、防御⼒をほぼ証明するスキルを備えており、⾮常にデリケートな業界でない限り、このグループを防御するためにリソースを費やすことは特に効率的ではありません。