OWASP ZAP
OWASP ZAPを使う
Burp Suiteを使って、アプリケーションの脆弱性診断を、と思っていたのですが、
Burp SuiteのUIは、日本語化出来るらしいのですが、OWASP ZAPはデフォルトで日本語表示できる、というのもあり、Burp Suiteとの機能比較も兼ねて、OWASP ZAPをセットアップ。
セットアップは、以下を参考にさせて頂きました。
基本的には、
・インストール
・プロキシの設定
・証明書の設定
という流れは、Burp Suiteと同じ。
OWASP ZAPにはJavaが必要で、Javaが32bit版の場合、ダウンロードするOWASP ZAPも32bitにする必要がある。
Burp Suiteとの違い
Burp Suiteと同じようなイメージいたのですが、いきなり戸惑いました。
Burp Suiteの場合、Webサイトにアクセスすると、Interceptがオンになっているので、ブラウザが表示されない。OSWASP ZAPでは、普通にブラウジングできる。
デフォルトで、すべてのHTTP通信をパッシブスキャンしている、とのこと。
ここで重要になってくるのが、「モード」の考え方。
「プロテクトモード」にすべし。
「標準モード」・「攻撃モード」では、ブラウジングした瞬間に、アクティブスキャンが発動するらしい。不正アクセスと通報されるリスクもあるので、ここは気を付けたい。
「セーフモード」・「プロテクトモード」では、コンテキストに指定したURLに対してのみ、以下が実行できるようになる。
- Spidering
- Active Scanning
- Fuzzing
- Force Browsing
- Breaking (intercepting)
- Resending requests
ZAP HUD
OSWASP ZAP経由でブラウジングしていると、以下の画面が起動する。
HUD = Heads Up Displayの略らしく、ブラウジングしているページの脆弱性の確認を、そのページ内でするためのUI。
ZAPの操作することなく、Webページをブラウジングしながら結果を見られるのは、秀逸だと思います。
スキャン自体は問題ないけれど、難点は、肝心のレポート出力で文字化けがあって読めない部分がある。日本語UIのせいなのか、解消を期待したい。
更なる自動化
OWASP ZAPで、パラメーターを改変したリクエストの再送などもできるが、Burp Suiteにある、Intruderのような手動＋自動での攻撃機能は見あたらない。
自動化に重心が置かれているように見え、
などが可能となっている。
GitHub Actionsなどを使えば、アプリケーションのデプロイ時に、ZAPによるセキュリティチェックを適用し、脆弱性診断をパスしないと、公開されない、というフローを作ることも可能になる。
まとめ
OWASP ZAPで、全体のスキャンをして、ビジネスロジックの欠陥などは、Burp Suiteで個別にチェックしていくと、広い範囲をカバーしつつ、深い診断が可能する、という使い分けが必要と思う。
セキュリティの原則
セキュリティの原則とは？
改めて、「セキュリティの原則」とは何だろう？と考えた。
セキュリティとは、C（Confidentiality:機密性）・I（Integrity:完全性）・A（Availability:可用性）の維持、と簡単に説明する事が多い。これは、ISO/IEC 27000に記載されている。
CEHのテキストでは、CIAに加えて、Authenticity：真正性、non-repudiation：否認防止を情報セキュリティの要素（Element of Information Security）として、テキストの最初の方に記載があった。
それ以外に、Accountability：責任追及性、Reliability：信頼性、を追加して、7要素としている情報も見受けられる。
それらの要素を維持するための原則がいろいろ存在するようです。
以下のブログで、基本原則が７つ紹介されています。
- Defense In Depth（多層防御）
- Least Privilege（最小権限の原則）
- System Hardening（システムの堅牢化）
- CIA Triangle Triad（セキュリティの３原則）
- Separation of Duties（職務分掌）
- AAAs of Security（認証・認可・監査）
- Patch Vulnerable Systems and Software（パッチ・マネジメント）
前述の7要素に対する原則かと思いきや、CIAが含まれていたりして、少し混乱。
OWASP SAMMの中にセキュリティ原則（security principles）に関する記述があった。
セキュリティ原則のリストを作りましょう、それには以下などが含まれる。
- defense in depth
- securing the weakest link
- use of secure defaults
- simplicity in design of security functionality
- secure failure
- balance of security and usability
- running with least privilege
- avoidance of security by obscurity
etc.
多層防御/最小権限の原則は、前述の7原則と重複している。
最後が、etc.になって、それ以外にも存在する、ということか。
SAMMに関しては、ソフトウェア開発における原則、という側面が強い。
こちらでも、アプリケーションのセキュリティに関して７つの原則を挙げている。
- Least Privilege
- Separation of Duties
- Defense in Depth
- Failing Securely
- Open Design
- Avoiding Security by Obscurity
- Minimizing Attack Surface Area
前述のブログやSAMM、どちらともかぶっている。
「security principles」で検索していると、CISSPのテキストが出てきたりして、似たような、それでいてまた別のことを言っていたりする。
www.pearsonitcertification.com
まとめ
セキュリティの原則、に明確な回答はなく、セキュリテイの７つの要素を守るための考え方・行動を端的にまとめたものが該当するのか、と思いました。
- Confidentiality:機密性
- Integrity:完全性
- Availability:可用性
- Authenticity：真正性
- non-repudiation：否認防止
- Accountability：責任追及性
- Reliability：信頼性
広く情報を集めて、守るべきシステム・資産に応じて組み合わせていくのがよいのでしょうか。
久々のBurp Suite
Portswigger Academy
以前、Portswigger Academy卒業、と浮かれていたら、全然、終わってなかった。
久々に、Burp Suiteで遊ぼうとおもって、ログインしてみると、クリアしていない課題がある。
知らぬ間に、課題が14個増えていた。
追加された課題
ファイルアップロードのカテゴリが新たに追加になっていた。
他に、HTTP リクエストスマグリングに６個追加。
あとは、クロスサイトスクリプティングで１個追加。
いつのまに追加になったのか、と思っていたら、Twitterでフォローしていれば分かるようです。
Hall of fame を見ると、12月16日にコンプした人がいて、前回も12月にリリースされたようで、年1回の更新なのかと想像する。
未だBurp Suiteを無料の範囲内で使用していますが、こんな情報を提供してくれるPortswigger Academyは本当にありがたいです。
脆弱性情報について
CVE、CWE、CVSS
log4jの脆弱性はCVSSが10です、なんてワードを見る。
改めて、その辺の整理をする。
こちらで、さっぱりとまとめてくれています。
CVE：脆弱性を識別するための共通ID（CVE識別番号(CVE-ID)）
CWE：脆弱性のカテゴリ分けするための共通ID（CWE識別子(CWE-ID)）
CVSS：脆弱性の危険度を評価するための共通方法
CVE
wikiによれば、CVEは辞書とのこと。
CVEの目的は「識別可能性の確保＝個々の脆弱性に固有のCVE番号を割り当て、CVE番号によって脆弱性を識別可能とすること」と「命名＝個々の脆弱性に（業界標準的な）名前を付けること」であり、詳細情報は外部サイトや他の脆弱性データベースに任せるというものである。
CVEのサイトで提供される情報としては、「脆弱性の概要(Description)」「参考URL(References)」など。
CWE
CWEは脆弱性のカテゴリ、ということだが、全体像が良く分からない。
こちらに詳細の説明があった。
HIRT-PUB18002：共通脆弱性タイプ一覧 (CWE: Common Weakness Enumeration)：Hitachi Incident Response Team：日立
CWEのサイトで、検索が準備されていて、開発者の視点から関係するものを見たり、ワード検索で引っ掛かるものを検索することができる。
それ以外に、外部サイトとの関連からも見つけることができる。
中を見れば、CVE・CAPECとの関連が表示される。
CWEの中には、サンプルコードが表示されているものもある。
CWE TOP25という、危険性が高いものをランキングしていたりします。
CWE - 2021 CWE Top 25 Most Dangerous Software Weaknesses (mitre.org)
CAPEC
CAPECはCommon Attack Pattern Enumerations and Classificationsで、攻撃手法の分類。
CVE・CWE同様にMITREによって運営されている。
WEBサイトもほぼ、同じ面構え。
全体像は、こちらのサイトで紹介されています。
CAPECから読む脆弱性のメカニズム. 概要 | by syuya yuikura | 這いよれ! Pentest Lab ep2 | Medium
CVEで脆弱性が特定され、CWEで分類され、その脆弱性に対する攻撃手法はCAPECで分類、という住み分け。
これで十分な気がしますが、脆弱性DBがいくつか存在する。
脆弱性情報DB
NISTはMITRE/CVEのスポンサーであり、CVEで命名された脆弱性情報の詳細情報をNVDで提供するという住み分けを行なっている。
というこらしい。
NVDのサイトでは、CVE、CWEへのリンクがあり、同期されている。
日本では、Japan Vulnerability Notes (JVN)、JVN iPediaがあり、JPCERT/CCと情報処理推進機構（IPA）が共同で管理している。
Japan Vulnerability Notes (jvn.jp)
CVEとも連携が取れており、日本での脆弱性も含めて対応している。
オープンソースの脆弱性情報DBとして、Open Source Vulnerability Databaseがある。
と、世の中の脆弱性情報の流れはつかめた。
問題は、これらの脆弱性情報をタイムリーに取得し、環境にその脆弱性が存在しないのか、を確認できなければ意味がない。
人手にばかり頼っていられない。
開発者には、静的アプリケーションセキュリティテスト（Static Application Security Testing：SAST）ツールなどで、さっくり出来ないと、鈍感化からのセキュリティホールになってしまうのでしょうね。
MITRE
MITREって？
みとれ、とか読んでしまいますが、まいたー、が正しい発音らしいです。
マサチューセッツ州ベッドフォードとバージニア州マクリーンに本社を置くアメリカの非営利団体です。連邦政府が資金提供する研究開発センター（FFRDC）を管理し、航空、防衛、ヘルスケア、国土安全保障、サイバーセキュリティなどの分野でさまざまな米国政府機関をサポートしています。
米国国立標準技術研究所（NIST）の連邦研究開発センターを運営していたり、共通脆弱性識別子 (CVE) の管理は、米国国土安全保障省の一機関であるサイバーセキュリティおよびインフラストラクチャ・セキュリティ庁から資金援助を受けて MITRE 社が行っています。
MITRE ATT&CK
ATT&CKは、「Adversarial Tactics, Techniques, and Common Knowledge」の略。
CVEを元に作られたナレッジとなっている。
詳細は、こちらの記事でガッツリ説明されている。
https://www.intellilink.co.jp/article/column/attack-mitre-sec01.html
ATT&CKの現物はこちらから。
この時点でのバージョンは、ATT&CK v10 で、2021年10月21日に公開された。
14個の戦略（Tactics）に、それぞれ戦術（Techniques）があり、合計は218個。
もの凄い量のナレッジが体系的にまとめられている。
それ以外にも、ハッカー集団が、「Groups」というカテゴリでまとめられており、どのような活動をしたかわかるようになっている。
これをひたすら暗記するのか？
どうやって使うか
以下のサイトで、
“机上評価でかつリスクベース・アプローチ”という分類がされている。
MITREのサイトでは、ナレッジの表示だけでなく、ATT&CK Navigatorというツールが準備されている。
Treat Groupsでグループを選択し、色付けすることができる。
こうすることで、攻撃者のプロファイルが作成できて、実際の攻撃手法を把握することができる。コンビネーション攻撃を仕掛けられた際に、有効な防御をどうするか？という検討が可能になる。
エクセルにも落とすこができる。
セキュリティにおいて網羅性が重要で、ATT&CKのようにナレッジが体系化され、更新されているのは有難い。日本語化を望んでしまうけれど、原文のまま触れて、慣れておいた方がいいのでしょうね。こういう部分でも、ハンデを感じてしまう。
脅威モデリング
脅威モデリングについて
OWASP SAMMの中で、脅威モデリング（Threat modeling）という言葉がある。
ビジネス機能:Design
セキュリティ対策：Threat Assessmentの中で、
StreamとしてThreat modelingが定義されている。
その内容をGoogle翻訳で翻訳すると、
「脅威モデリングを使用して、アーキテクチャ設計の欠陥を特定して管理していますか？」
- リスクの高いアプリケーションの脅威モデリングを実行します
- STRIDEなどの単純な脅威チェックリストを使用します
- 後で使用するために脅威モデルの結果を永続化します
以下、それぞれの項目について確認をする。
リスクの高いアプリケーションの脅威モデリングを実行します
脅威モデリングはどのようにするのか？
OWASPでしっかりと定義されています。が、なかなかイメージしづらい。
以下2つのサイトで、概要が理解できた。
上記からの抜粋
- 脅威モデリングとは
新しいシステムや既存のシステムについて継続的なディスカッションを促進するためのプロセスです。
セキュリティを全員の責任にすることへの第一歩です。
- 脅威モデリングのステップ
図を作成する。何を構築するのか？
脅威を特定する。何が脅威となる可能性があるか？
低減する。脅威から防御するために何を行うか？
バリデーションを行う。以前の各ステップに対して措置を講じたか？
STRIDEなどの単純な脅威チェックリストを使用します
STRIDEは以下のカテゴリの頭文字をとっている。
| カテゴリ | 説明 | |
| S | なりすまし Spoofing |
他のユーザーの認証情報 (ユーザー名、パスワードなど) に不正にアクセスし、それを使用する行為などです |
| T | 改ざん Tampering |
悪意のあるデータの変更などです。 例としては、データベースに保持されているような永続的なデータに対する許可されていない変更や、インターネットなどのオープン ネットワーク経由で 2 台のコンピューター間を流れるデータの変更などがあります |
| R | 否認 Repudiation |
反証できる関係者がいない状況でアクションの実行を否定するユーザーに関連するものです。たとえば、禁止されている操作を追跡できる機能がないシステムでユーザーが不正な操作を行うような場合です。 否認防止とは、否認の脅威に対抗するシステムの機能のことです。 たとえば、商品を購入するユーザーは、受け取り時に署名をする必要があります。 販売者は、署名された受領書をユーザーが荷物を受け取ったことの証拠として使用することができます |
| I | 情報漏えい Information Disclosure |
情報へのアクセスが想定されていない個人への情報の暴露などです。たとえば、アクセスが許可されていないファイルをユーザーが読み取ることができたり、侵入者が2 台のコンピューター間で送信されるデータを読み取ることができたりする場合です |
| D | サービス拒否 Denial of Service |
サービス拒否 (DoS) 攻撃では、有効なユーザーへのサービスが拒否されます。たとえば、Web サーバーを一時的に使用できなくする行為です。 システムの可用性と信頼性を向上させるために、特定の種類の DoS 脅威からシステムを保護する必要があります |
| E | 特権の昇格 Elevation of Privilege |
特権のないユーザーが特権的なアクセスを取得すると、システム全体を侵害したり破壊したりできるようになります。 特権の昇格の脅威には、攻撃者が効果的にすべてのシステム防御を破り、信頼されているシステム自体の一部となる、本当に危険な状況が含まれます |
脅威 - Microsoft Threat Modeling Tool - Azure | Microsoft Docs から引用
脅威分析のアプローチは、以下の2通りに分類される。
- チェックリスト・ベースのアプローチ
- 非チェックリスト・ベースのアプローチ
前者で用いられるのが、STRIDE
後者では、ブレーンストーミングなどによることになる。
チェックリストを用いた方が漏れなく、属人的になりづらい点がある。
STRIDEの変化形には以下の２つがある。
- STRIDE-per-Element
- STRIDE-per-Interaction
後で使用するために脅威モデルの結果を永続化します
脅威モデリングのツールとして、無料で使えるものがある。
- MicrosoftのThreat Modeling Tool
- OWASPのThreat Dragon
成果物が目的ではないですが、ツールで自動化できる部分は頼りたいところ。
クラウドの脅威モデリングについては、Cloud Security Alliance (CSA)が公開している「Cloud Thread Modeling」がある。
https://www.cloudsecurityalliance.jp/site/?p=20247
とのこと。
その中で、付録2: クラウド脅威モデリングカード、というのが気になります。
まとめ
組織における様々な立場の人たちが、セキュリティを全員の責任とするための共通認識を作成するのに、脅威モデリングは有効と思える。そして、それが通常のプロセスに組み込まれて、継続されることが重要。
OWASP ASVSとその周辺
OWASP ASVSとは？
Application Security Verification Standard=ASVSで、OWASPのプロジェクトで、日本語の訳では「アプリケーションセキュリティ検証標準」が当てられている。
ASVS は現代の Web アプリケーションおよび Web サービスを設計、開発、テストする際に必要となる、機能的および非機能的なセキュリティ管理策の定義に焦点を当てた、セキュリティ要件および管理策のフレームワークを確立するコミュニティ主導の取り組みです。
https://github.com/owasp-ja/asvs-ja/blob/master/5.0/ja/0x02-Preface.md
という説明があり、Webアプリケーションのセキュリティに関する叡智が詰まっている、はず。
最新版は、4.0.3らしい。
OWASP Application Security Verification Standard | OWASP Foundation
日本語訳は、２つありました。
OWASP「アプリケーションセキュリティ検証標準 4.0」の日本語邦訳文書公開について | SAJ 一般社団法人ソフトウェア協会
アプリケーションセキュリティ検証標準では 3 つのセキュリティ検証レベルが定義されている。
- ASVS レベル 1 は低保証レベル向けであり、すべてがペネトレーションテスト可能です。
- ASVS レベル 2 は機密データを含むアプリケーション向けであり、保護を必要とし、ほとんどのアプリに推奨されるレベルです。
- ASVS レベル 3 は極めて重要なアプリケーション向けであり、高額取引を行うアプリケーション、機密性の高い医療データを持つアプリケーション、最高レベルの信頼性を必要とするアプリケーションのためのものです。
各 ASVS レベルはセキュリティ要件のリストを含みます。これらの各要件はセキュリティ固有の機能や開発者がソフトウェアに組み込む必要のある機能にもマップできます。
と書いてあるものの、良く分からなくなってくる。
ASVSは難解？
以下のサイトで概要と実際の活用方法が分かりました。
ASVSでは、包括的な枠組みを提供してくれるものの、具体策は別の話になってくる。
上記サイトでは、以下の３つの使用を薦めている。
- OWASP Proactive Controls（OPC）
- OWASP Cheat Sheet Series Project（OCSS）
- OWASP DevGuide
OPCは、セキュリティを高めるために考慮するべき10個のポイント（セキュリティ要件の定義、セキュリティフレームワークとライブラリの利用など）が重要度順に列挙されている。
OCSSは、77ジャンルにおけるベストプラクティスがまとめられている。
こちらのサイトで、ASVS・OPC・OCSSの関連性がまとめられている。
Introduction - OWASP Cheat Sheet Series
ASVSのV1.1と関連するチートシートとそのリンク。
SSDLを回す為に、３つのチートから具体策を検討してみよう、ということになる。
まとめ
ASVSという枠組みをOPCやOCSSという具体策で補うことで、組織にとって有効な対策の実行ができそう。
ASVSはDefectDojoというセキュリティ管理ツールとも連携が取れるらしい。
DefectDojo | CI/CD and DevSecOps Automation
SAMMも枠組みの提供であり、その実現のために、ASVSを用いて具体化していく流れになるのだろうか。
