stanford-oval/wikipedia huggingface dataset:
サイバーセキュリティ
攻撃・ペネトレーションテストで使われる手法やツール > 脆弱性検査ツール

→詳細は「脆弱性検査ツール」を参照
w3af、Nessus、OWASP ZAP、OpenVASなどがある。
攻撃・ペネトレーションテストで使われる手法やツール > 横断的侵害を行うためのツール

ネットワークに侵入して横断的侵害を行う攻撃の手口の典型的パターンは
ipconfigやsysteminfoといったWindows標準コマンドで侵入した端末の情報を収集
net等のツールでネットワーク上の他の端末の情報、ドメイン情報、アカウント情報等を収集し、次に侵入する端末を選ぶ
mimikatzやPwDump等のパスワードやそのハッシュ値をダンプするツールで次に侵入する端末のユーザーのパスワード情報を入手
netやat等のツールを駆使して他の端末に侵入
というものである。
またプロキシやリダイレクタを使ってファイヤーウォールを突破する事で、侵入した端末からC&Cサーバや組織内の別の端末との通信経路を確立する。その他ファイル圧縮ツールやステガノグラフィーツールもデータ内容を隠蔽して送信する目的で使われる。
攻撃・ペネトレーションテストで使われる手法やツール > その他・複数機能を持つツール

netcatは正規のネットワークユーティリティで、「接続モードでは、任意のサーバ、ポートを指定し接続を行うことができ、telnetのように対話的に使用したり、ポートスキャナとして使用することもできる。待ち受けモードでは、任意のポートをで待ち受けを行い、接続してきたクライアントと対話することができる」。バックドアのように使用する事も可能である。
LanSpy：ネットワークディスカバリーツール、ポートスキャナ
tcptraceroute、tracetcp：ICMPの代わりにTCPレイヤでtracerouteを行う
SMTP Relay Scanner：SMTPの不正中継調査
snmpcheck、snmpwalk、SNScan：SNMPデバイスのディスカバリーツール
SiteDigger、metagoofil：Googleハッキングツール
dig：DNSへの問い合わせツール
tcpdump、Wireshark：パケットモニタリングツール
Cain and Abel：パスワードクラッキング、スニッファ、VOIPキャプチャ、RTPストリームリプレイ
MSN Protocol Analyzer：MSN Messengerのキャプチャ・プロトコルアナライザ
hping：パケットジェネレータ、パケットキャプチャ・アナライザ。パケットジェネレータ機能はファイアウォールのテストなどに利用可能。
攻撃・ペネトレーションテストで使われる手法やツール > 攻撃・ペネトレーションテストに利用できるサイト

以下のものがある：
| 類別 | サイト | 概要 |
| --- | --- | --- |
| マルウェア検体の調査 | Threat Crowd | 過去のマルウェア情報や関連情報の確認が可能 |
| マルウェア検体の調査 | Passive Total | 同上。WHOIS履歴の参照も可能 |
| マルウェア検体の調査 | Virus Total | ファイルやウェブサイトの検査が可能 |
| インターネット接続機器の検索 | SHODAN | ウェブサーバやIoT機器など、インターネットに接続している機器を調査可能 |
| インターネット接続機器の検索 | Censys | 同上 |
| 脆弱性チェック | QUALYS SSL Server Test | SSLサーバの脆弱性や設定のチェック |
| エクスプロイト集 | Exploit Databsae | エクスプロイト集 |
| Googleハッキング | Google Hacking Database | 「パスワードや機密情報を探し出すGoogle検索ワードがカテゴリーごとに、集約されている」 |
| 流出情報共有 | Pastebin | 元来は情報共有サイトだが、個人情報や機密情報の投稿にも用いられている |
| 流出情報共有 | Dumpmonitor | Pastebinに載った流出情報をつぶやくtwitterアカウント |
| 脆弱性情報検索 | PunkSPIDER | 脆弱なウェブサイトとそのサイトの脆弱性を検索 |
攻撃・ペネトレーションテストで使われる手法やツール > 攻撃・ペネトレーションテストに利用できるサイト > SHODANとCensys

ウェブサーバやIoT機器など、インターネットに接続している機器を調査できるウェブサービスとして、SHODANやCensysなどがある。SHODANはポートスキャンにより接続している機器を特定し、特定した機器に対してバナーチェックを行う事により、機器の情報を得ている。SHODANの利用者が例えば東京にあるApacheサーバの一覧を得たければ、SHODANに「apatch city:Tokyo」と打ち込んで検索する事ができる。また、SHODAN MAPSの機能により、検索した機器の位置を地図上に表示可能である。
バナー情報により、検索結果には製品名やバージョン等もわかるため、攻撃者はこれを利用して脆弱性が適用可能な機器を見つける事ができる。なお、SHODANを使うには事前にユーザ登録が必要であり、基本無料であるものの全機能を使うには低額の利用料を支払う必要がある。
CensysはZmapというネットワークスキャナでIPv4のインターネット空間をスキャンして情報を収集し、ZGrabというプロトコル解析ライブラリにより収集したデータを構造化データに加工する。なお、ZmapがIPv4のアドレス空間全てをスキャンするのにかかる時間は45分に過ぎない。
Censysは無料で利用でき、ユーザ登録は必須ではないが、登録していないユーザは1日4回までしか検索できない。Censysはミシガン大学の研究者らが公開したものである。
攻撃・ペネトレーションテストで使われる手法やツール > ツール一覧

攻撃に利用可能なツール、コマンド、脆弱性として下記のものがある。なお、下記の表にはRDPのように、本来は攻撃ツールではないものの攻撃用にも利用できるものもリストアップされている。
| 分類 | 分類 | ツール・コマンド・脆弱性の例 |
| --- | --- | --- |
| コマンド実行 | リモートでのコマンド実行 | PsExec PsExec2 wmiexec.vbs BeginX WinRM WinRS BITS |
| コマンド実行 | 任意のタイミングでコマンド実行 | schtasks2 |
| パスワード、ハッシュの入手 | パスワード、ハッシュの入手 | PWDump7 PWDumpX Quarks PwDump Mimikatz(パスワードハッシュ入手 lsadump::sam、 sekurlsa::logonpasswords、チケット入手 sekurlsa::tickets) WCE gsecdump lslsass AceHash Find-GPOPasswords.ps1 Get-GPPPassword (PowerSploit) Invoke-Mimikatz (PowerSploit) Out-Minidump (PowerSploit) PowerMemory (RWMC Tool) WebBrowserPassView |
| Pass-the-hash Pass-the-ticket | Pass-the-hash Pass-the-ticket | WCE (リモートログイン) Mimikatz (リモートログイン) |
| 通信の不正中継 （パケットトンネリング） | 通信の不正中継 （パケットトンネリング） | Htran Fake wpad ZXProxy ZXPortMap |
| リモートログイン | リモートログイン | RDP |
| 権限昇格・窃取 | 権限昇格 | MS14-058 Exploit MS15-078 Exploit SDB UAC Bypass |
| 権限昇格・窃取 | ドメイン管理者権限アカウントの窃取 | MS14-068 Exploit Golden Ticket (Mimikatz) Silver Ticket (Mimikatz) |
| ホストログインしたりするためのローカルユーザー・グループの追加・削除 | ホストログインしたりするためのローカルユーザー・グループの追加・削除 | net user |
| 共有ポイント経由での攻撃ツール送信やファイルサーバーからの情報取のためのファイル共有ツール | 共有ポイント経由での攻撃ツール送信やファイルサーバーからの情報取のためのファイル共有ツール | net use |
| 痕跡の削除 | 攻撃に利用したファイルの復元できない削除 | sdelete |
| 痕跡の削除 | タイムスタンプ修正によるファイルアクセスの隠蔽 | timestomp  |
| 痕跡の削除 | 攻撃に使ったKerberosチケットのホストからの削除 | klist purge |
| 痕跡の削除 | 攻撃関連のイベントログの削除 | wevtutil |
| 情報収集 | パスワード解析の為NTDS.DIT(NTDSのデータベース)を抽出 | ntdsutil vssadmin  |
| 情報収集 | 攻撃対象選定等のためActive Directoryからアカウント情報を収集 | csvde ldifde dsquery |
| 情報収集 | 攻撃に利用可能なドメインコントローラーの問題を調査 | dcdiag |
| 情報収集 | ホストが所属するドメインコントローラーの情報を取得 | nltest |
| 情報収集 | ネットワーク内のホストの列挙、接続可能なポートの調査等 | nmap |
| 情報収集 | APIやアプリの出すデバッグ情報を取得 | dbgview |
攻撃への対策のフレームワークや考え方 > サイバーセキュリティフレームワーク

NIST（アメリカ国立標準技術研究所）のサイバーセキュリティフレームワーク(正式名称：重要インフラのサイバーセキュリティを向上させるためのフレームワーク)によれば、重要インフラのサイバーセキュリティ対策は以下の５つのフェーズに分類できる：
|  | 具体例 | 担当する組織 | 担当する組織 | 担当する組織 |
| --- | --- | --- | --- | --- |
| 特定 | 資産管理、ビジネス環境、ガバナンス リスクアセスメント、リスク管理戦略 | リスク管理部門 | リスク管理部門 | 活動範囲の広い CSIRT |
| 防御 | アクセス制御、意識向上およびトレーニング、データセキュリティ、情報を保護するためのプロセスおよび手順、保守、保護技術 | - | (2018年現在から見た)従来型のIT管理部門 | 活動範囲の広い CSIRT |
| 検知 | 異常とイベント、セキュリティの継続的なモニタリング、検知プロセス | いわゆるSOC、CSIRT | (2018年現在から見た)従来型のIT管理部門 | 活動範囲の広い CSIRT |
| 対応 | 対応計画の作成、伝達、分析、低減、改善 | いわゆるSOC、CSIRT | 危機管理部門 | 活動範囲の広い CSIRT |
| 復旧 | 復旧計画の作成、改善、伝達 | - | 危機管理部門 | 活動範囲の広い CSIRT |
上の表でSOC、CSIRTはセキュリティ対応のための組織である。両者の役割分担や関係性、業務内容等は企業毎に異なるが、概ねSOCは「平時」の分析運用を行い、CSIRTは「有事」のインシデント対応を行う。
このフレームワークは、それ以前の類似のフレームワークと比較した場合、攻撃が行われた後の検知、対策、復旧のフェーズの重要性を明確化した事と、各フェーズの習熟度について言及した事に特徴がある。
このフレームワークでは「ガバナンスのサイクル」と「マネジメントのサイクル」を回すことがサイバーセキュリティ対策で重要だと主張している。
またおなじNISTが発行したSP800-61「コンピュータセキュリティ・インシデント対応ガイド」ではインシデント対応プロセスは、準備、検知および分析、封じ込めおよび根絶、インシデント後の活動の4段階に分類されるとしている。
以下、サイバーセキュリティフレームワークの各フェーズを説明するが、一部JPCERT/CCの文献を元に加筆した。
攻撃への対策のフレームワークや考え方 > サイバーセキュリティフレームワーク > 特定

サイバーセキュリティ対策をする上で基本となるのは、守るべき資産を特定し、各資産のリスクを把握することである。
攻撃への対策のフレームワークや考え方 > サイバーセキュリティフレームワーク > 特定 > 組織の置かれた状況の特定

産業分野やサプライチェーンにおける自社の位置づけ、重要サービスを提供する上での依存関係と重要な機能等を把握し、自組織のミッション、目標、活動に関する優先順位を決め、伝達する必要がある。JPCERT/CCは、守るべき資産を特定する前準備として、組織のプロファイルを作成することを推奨している。このプロファイルには規模や提供製品のような基本的事項のみならず、システムダウンの影響度合いや規制のレベルなどリスクアセスメントに必要となる情報も含める。また、組織のサイバーセキュリティ防御能力に関する文書を作成する。
またセキュリティに関する法規制を把握し、自組織の情報セキュリティポリシーを定め、セキュリティに関する役割と責任について内外のパートナーと調整や連携を行う。さらにガバナンスやリスク管理のプロセスをサイバーセキュリティリスクに対応させる。
攻撃への対策のフレームワークや考え方 > サイバーセキュリティフレームワーク > 特定 > 守るべき資産とそのリスクの特定

→詳細は「ソフトウェア資産管理」、「リスクマネジメント」、および「リスクアセスメント」を参照
自組織内の物理デバイス、システム、ソフトウェアプラットフォーム、アプリケーション、外部情報システムといったリソースの一覧を作成し、ネットワークの通信やデータフローを図示し、これらのリソースやデータのうち、守らなければならないものとその理由、およびそれが抱える脆弱性を特定する。この際、ビジネスに対する潜在的な影響とその可能性も特定する。そしてそれら守るべき対象を守れなかった場合に発生するリスクを、脅威、脆弱性、可能性、影響等を考慮して分析し、リスクに対処するためのコストやリスクが顕在化した場合の減損、対処後の残存リスクを特定し、自組織の役割、事業分野等を考慮してリスク許容度を明確化する。そしてビジネス上の価値に基づいてこれらのリソースやデータを優先度付けをする。さらに自組織の従業員や利害関係者に対し、サイバーセキュリティ上の役割と責任を定める。リスク管理のプロセスを自組織の利害関係者で確立、管理、承認する必要がある。
なお、保有資産の特定にはIT資産インベントリ検出ツールが利用でき、未登録機器の発見にはDHCPサーバのロギング機能等が利用できる。またアクセス監視の際、資産リストと突合する事で、承認されたデバイスのみがネットワークに接続されている事を確認できる
なおリスク分析の際にはどのようなタイプの攻撃者が自組織が属する業界を攻撃するのかを事前に特定しておくのが望ましい。
攻撃への対策のフレームワークや考え方 > サイバーセキュリティフレームワーク > 防御 > 脆弱性管理による防御

脆弱性管理計画の作成・実施を行い、脅威と脆弱性に関する情報を入手する必要がある。JPCERT/CCによれば、脆弱性スキャンはセキュリティ設定共通化手順「SCAP」のチェックリストにより検証済みのスキャナを用いて、毎週ないしそれ以上の頻度で行う必要がある。これによりコードベース・構成ベース方法の脆弱性を検出する事が可能である。攻撃検知のイベントログと脆弱性スキャン結果を突合することで、どの脆弱性が標的にされたのかを判別できる。アプリケーション、OS双方に対し自動パッチ適用ツールを用いる事が望ましい。
攻撃への対策のフレームワークや考え方 > サイバーセキュリティフレームワーク > 防御 > ID管理とアクセス制御による防御

自組織の全ての従業員のIDに対してアクセス制御リスト(ACL)を定義し、ACLに従って従業員の資産や関連施設への物理アクセスやリモートアクセス、データへのアクセスを制限する。ACLは定期的に棚卸し、人事の異動、追加、削減に際してアクセス権限の無効化や従業員の審査を行う。従業員等にシステムや資産に対する権限を与える場合には、最小権限の原則に従う。
攻撃への対策のフレームワークや考え方 > サイバーセキュリティフレームワーク > 防御 > システム開発時の防御

システムの開発ライフサイクルや設定変更を管理する。また開発の際には開発環境やテスト環境を実環境と分離することで情報漏えい等を防ぐ。
攻撃への対策のフレームワークや考え方 > サイバーセキュリティフレームワーク > 防御 > 意識向上やトレーニングによる防御

全てのユーザをトレーニングし、権限ユーザ、上級役員、利害関係者、 物理および情報セキュリティ担当者にポリシー、手順、契約に基づいた役割と責任を理解させる必要がある。またAPTなどの攻撃に対する演習を事前に行っておく必要がある。
攻撃への対策のフレームワークや考え方 > サイバーセキュリティフレームワーク > 防御 > データの防御

自組織のリスク戦略に従って、保存されたデータや伝送中のデータの機密性、完全性、可用性を保証する。データの可用性の保証に関しては十分な容量を確保し、機密性に関しては漏洩対策を実施し、完全性に関しては何らかの完全性チェックメカニズムを導入する。データは定期的にバックアップ・テストする。またデータはポリシーに従って破壊し、資産の撤去、譲渡、廃棄も管理する。
なお情報はその機微度に応じて「高、中、低」等の格付けを事前に実施し、自組織を狙う可能性がある攻撃者がどのような情報に関心を示すのかを特定しておく事が望ましい。
攻撃への対策のフレームワークや考え方 > サイバーセキュリティフレームワーク > 防御 > 保守運用作業における防御

システムのベースラインを設定・維持する必要がある。保守と修理はポリシーや定められた手順に従って実施する。重要な資産を保護するプロセスを定め、重要なシステムに対して適用可能なセキュリティ管理策を全て実施していることを確認する。保守や修理の際は、管理されたツールを用いてタイムリーに行い、ログを記録する。特に遠隔保守の際には、承認、ログの記録、不正アクセス防止を行う必要がある。監査記録やログの対象をポリシーに従って決め、取得した監査記録やログをレビューする。ログデータは、DNS、プロキシ、ファイアウォールなど重要機器に対して取得し、時刻はNTPにより同期する。事前にセキュリティを強化し、構成管理を厳密に行ったOS等のイメージを作成しておき、従業員のPCや新規導入システムにはこのイメージをインストールする。
ネットワークのセキュリティ構成は、変更管理委員会によって文書化、確認、承認を行う。
攻撃への対策のフレームワークや考え方 > サイバーセキュリティフレームワーク > 防御 > その他の防御方法

セキュリティポリシー、プロセス、手順を維持し、資産の物理的な運用環境に関するポリシーと規制を満たすようにする。また保護プロセスを継続的に改善する必要がある。
インシデント対応、事業継続、インシデントや災害からの復旧計画の実施・管理・テストを行う。保護に使う技術の有効性の情報共有を行う。
取外し可能な外部記憶媒体はポリシーに従って保護したり、使用を制限したりする。
またJPCERT/CCによれば下記を行う事が望ましい：
自組織のセキュリティ方針やセキュリティ計画に情報システム・重要データが扱う必要がある。
自組織のネットワーク境界の外部および内部からペネトレーションテストを定期的に実行する必要がある。ペネトレーションテストに用いるアカウントはコントロール・モニタリングし、テスト終了後に除去するか通常機能に戻ることを確認する。
システムで使うソフトウェアが限定されている場合には、実行可能なソフトウェアのホワイトリストを作り、そうでない場合は利用して良いソフトウェアとそのバーションを定めて無許可のソフトを検知できるようにする事でリスクを低減できる。利用して良いソフトウェアが改竄されるリスクを低減する為、ファイル完全性チェックツールでモニタする事が望ましい。
攻撃への対策のフレームワークや考え方 > サイバーセキュリティフレームワーク > 検知

検知を行う前提条件として、ネットワーク運用のベースラインを定め、データフローを特定・管理する。そしてセキュリティイベントを検知できるよう、ネットワーク、物理環境、個人の活動、権限のない従業員・接続・デバイス・ソフト、外部サービスプロバイダの活動等をモニタリングし、マルウェア対策ソフトなどで悪質なコード、特にモバイルコードを検出できるようにする。
そしてイベントログを複数の情報源やセンサーから収集し、SIEMなどで一元管理して、相互に関連付け、検知したイベントを分析し、その影響範囲を特定する。また事前に定めたしきい値に従って、検知したイベントをインシデントとみなすかどうかを判断する。
検知プロセスはテストし、継続的に改善する必要がある。また説明責任が果たせるようにする必要がある。
攻撃への対策のフレームワークや考え方 > サイバーセキュリティフレームワーク > 対応

CSIRTの主たる担当業務である。検知フェーズで発見したセキュリティイベントにタイムリーに対応できるよう対応計画を事前に定めておき、法執行機関の支援が得られるよう情報共有や利害調整を行う。そして対応計画にしたがってインシデント分類し、フォレンジックを行うなどしてセキュリティイベントを調査し、その影響範囲を把握し、事前に定めた基準に従ってインシデントの封じ込めないし低減を行う。インシデント対応の結果学んだ教訓を生かして対応計画を更新する。
攻撃への対策のフレームワークや考え方 > サイバーセキュリティフレームワーク > 復旧

タイムリーに復旧できるよう事前に復旧手順を定め、復旧の際にはその計画を実施する。システムの復旧を行うのみならず、広報活動を管理するなどして評判回復に努める。対応フェーズと同様、教訓を生かして復旧計画の更新も行う。
攻撃への対策のフレームワークや考え方 > 開発ライフサイクルにおけるセキュリティ確保

システムの安全性を確実に担保するにはシステム開発ライフサイクルの初期段階からセーフティ、セキュリティ、プライバシーなどを考慮しておくことが望ましい。開発プロセスのより早い段階でセキュリティを考慮する事を（開発プロセスを左から右に書いたときにセキュリティを考慮するのを左に寄せる事から）シフトレフトという。特に、情報セキュリティを企画・設計段階から確保するための方策をセキュリティ・バイ・デザイン（Secure By Design、SBD）といい、プライバシーに対する同様の概念をプライバシー・バイ・デザインという。
またDevOps（デブオプス、開発 (Development) の担当者と運用 (Operations) の担当者が一体となった開発手法）の普及に伴い、これにセキュリティの確保も一体になった開発手法であるDevSecOpsも注目を集めるようになっている。DevSecOpsでは設計段階からセキュリティを意識することはもちろん、セキュリティ対策ツールを開発ライフサイクルに組み込むなどして脆弱性診断を自動化し、アプリケーションを修正するたびに脆弱性を作り込まないようチェックし、利用しているライブラリの脆弱性を日々チェックするような活動も含む。
攻撃への対策のフレームワークや考え方 > 開発ライフサイクルにおけるセキュリティ確保 > サプライチェーンにおけるセキュリティ確保

システム開発ではその工程の一部を外注する事も多いため、サプライチェーン全てでセキュリティを担保する事が重要となる。このような調達時の脅威に対応する事をサプライチェーンチェーンリスクマネジメント(Supply Chain Risk Management、SCRM)という。ISO/IEC 27036ではアウトソーシングの際のセキュリティのガイドラインが規定されている。米国ではNIST SP800-161やNIST IR 7622にSCRMの規定がある。またISO/IEC 20243には不良品や偽造品を排除するためのベストプラクティス等が規定されている。
また事業継続計画(BMC)の観点からもサプライチェーンの継続を図ることも重要であり、SCCM(Supply Chain Continuity Management)と呼ばれ、ISO 22318に規定されている。なお災害復旧とサプライチェーンマネジメントをあわせてSCDRM(Supply Chain Disaster Recovery Management)と呼ぶ。
攻撃への対策のフレームワークや考え方 > 多層防御

→詳細は「多層防御 (セキュリティ)」を参照
多層防御とは、様々な階層で複数のセキュリティ対策を施す事で、重要部への侵入前に攻撃の検知および対応を行う事で、軍事・戦闘の世界のDefense in Depth (縦深防御) を応用したものである。複数の防御壁を設けて、一つの壁を突破されても次の壁で阻止して、機密情報に到達されてしまう確率を下げる事を目的とする。
多層防御の手法として以下で述べる入口対策、内部対策、出口対策の３つを取り入れる組織内対策や、複数組織をまたがった攻撃連鎖を上流で断つ国レベルでの対策などがある。
攻撃への対策のフレームワークや考え方 > 多層防御 > 入口対策、内部対策、出口対策

入口対策はファイアウォール、ウイルス対策ソフト、脆弱性対策など、攻撃者やマルウェアが組織内に侵入するのを防ぐ対策手法で標的型攻撃やAPTが普及する以前は有効であった。しかし標的型攻撃やAPTでは組織に侵入する方法が巧妙化しており、しかも侵入方法の変化が激しいので、入口対策だけで攻撃を防御するのは難しい。そこで、攻撃者が組織内部に侵入しているのを前提として、組織の内部対策を行う事より侵入の拡大を防ぎ、攻撃の外向き通信を遮断・監視する出口対策により組織からの情報の持ち出しやC&Cサーバとの通信を防ぐ必要がある。
攻撃への対策のフレームワークや考え方 > サイバーレジリエンス

サイバーレジリエンスは攻撃を受けてしまう事を前提として、攻撃を受けた際に、どのように組織の機能を維持し、いかにすばやく対処・復旧するかという回復力（レジリエンス）を高めるべきという考え方である。 世界経済フォーラムによる「グローバルリスク2013」を契機として「レジリエンス」という用語がビジネス等で使われるようになり、それと時期を同じくしてサイバーレジリエンスという用語も広まった。なお「レジリエンス」という用語はISO22300では「複雑かつ変化する環境下での組織の適応能力」と定義されている。
攻撃への対策のフレームワークや考え方 > セキュアなネットワーク構成 > 非武装地帯 (DMZ)

非武装地帯(DMZ、DeMilitarized Zone)はメールサーバ、ウェブサーバ、DNSコンテンツサーバ、Proxyサーバといった、組織内、インターネット双方とアクセスする必要があるサーバ群を置いておくためのネットワーク領域で、組織内ネットワーク・インターネット・DMZの３つの領域間の通信をファイアウォールで制限する。ウェブサーバ等をDMZではなく組織内ネットワークに設置すると、ウェブサーバが用いるポートを開けて置かなければならない為、そのポートを利用してインターネットから組織内に攻撃を行う事が可能になってしまう。これを防ぐためにウェブサーバ等をDMZに設置する。
攻撃への対策のフレームワークや考え方 > セキュアなネットワーク構成 > マイクロセグメンテーション

ネットワークを細かくセグメント分けする事。マイクロセグメンテーションにより、セグメントをまたいだラテラルムーブメントやウィルスの二次感染を防ぐ事ができる。実現手法としてh、スイッチングハブの各ポートにそれぞれ1台の機器を接続するというものがある。また仮想マシン（ないし仮想デスクトップ）の場合は各仮想マシンに仮想ファイヤーウォールを立てる事で、同一ネットワーク上にある仮想マシンであっても、仮想マシン一台で一つのセグメントを構成できる。
攻撃への対策のフレームワークや考え方 > セキュアなネットワーク構成 > ゼロトラスト

→詳細は「ゼロトラスト・セキュリティモデル」を参照
ゼロトラストはForrester ResearchのアナリストJohn Kindervag（ジョン・キンダーバグ）により提唱された概念である。従来のセキュリティ対策ではネットワークの境界で攻撃の遮断が可能であり、境界内は信頼できる事を前提としていたが、標的型攻撃や内部犯行の広がりによりこうした前提は崩れており、攻撃者が内部に侵入してくるのを前提とした対策が必要となる。
それに対しゼロトラストは従来型のセキュリティ対策よりも「性悪説」に基づいており、組織内ネットワークであっても、ユーザがデータやリソースにアクセスする際、ユーザが利用しているデバイスの信頼性とユーザ自身の信頼性とを動的に評価してデータやリソースへのアクセス認可を行う。一般的にはゼロトラストネットワークはユーザ関連情報を管理する ID プロバイダ、リソースにアクセスできるデバイスのリストを管理するデバイス ディレクトリ、管理者が設定したポリシーにユーザとデバイスが適合しているかを判断するポリシー評価サービス、リソースへのアクセス制御を行うプロキシから構成され、ゼロトラストネットワークのプロキシはユーザとリソースの間に置かれ、ユーザはプロキシでアクセス認可を受けた場合のみがデータやリソースにアクセスできる。
攻撃への対策のフレームワークや考え方 > セキュアなネットワーク構成 > アクティブディフェンス

アクティブディフェンス（Active defense、能動的防御）は、実際の攻撃に先んじて脆弱性や攻撃方法を発見して予防策を積極的に構築する取り組みの事。攻撃者が防御技術を研究して回避・無効化する事で、対応が後手に回って攻撃側に主導権を握られるのを防ぐ。
アクティブディフェンスの基本的手法としては以下のものがある：
アノイヤンス（Annoyance）：攻撃の労力を増加させる事。デコイサーバや偽のDNSエントリなど各種デセプション技術で攻撃者を騙し、時間を稼ぐ等。
アトリビューション（Attribution）：攻撃者の属性（Attribution）を明らかにする事。攻撃されそうなサーバやファイルにウェブビーコンやマクロ等を仕込んで攻撃者のIPアドレスや位置情報を取得する等。
アタックバック(Attack Back)：攻撃者に攻撃し返す事。
なおアタックバックはアクティブディフェンスに含まないとする意見もある。
フリーのアクティブディフェンスツールとしては、ADHD(active defence harbindger distribution)、Artillery、Nova (Network Obfuscation and Virtualized Anti-Reconnaissance)、BearTrap、Decloak、Honey Badgerなどがある。
攻撃への対策のフレームワークや考え方 > セキュアなネットワーク構成 > Moving Target Defense

アクティブディフェンスの手法の一つ。これまでのセキュリティ対策では、静的なシステムに検知技術や防御技術を導入することでセキュリティを担保していたが、それに対しMoving Target Defense (MTD)は、守るべきシステムの構成、特にネットワークを動的に変更する事で、攻撃者がシステム内を探索したりシステム構成を予測したりするのを難しくする手法である。従来のセキュリティ対策では、攻撃側がシステムを熟知しているのに対策側は攻撃者に関して断片的にしか知りえないという非対称ゆえの不利が対策側にあったが、MTDはこの種の不利を攻撃者にも背負わせようというアイデアである。
優先的に対策すべき箇所

優先的に対策すべき場所を示したガイドラインとして下記のものがある：
| 名称 | 概要 |
| --- | --- |
CISコントロール: Center for Internet Securityが「最も危険な脅威からのリスクを最大限に減らす」ための評価項目（コントロール）を上位20項目をあげたもの。2018年現在の最新版はVersion 7で、Version 6までは「CIS Critical Security Controls」(CIS CSC)と呼ばれていた。Tripwireによれば、Version 6の20の評価項目のうち最初の6つを利用するだけで85％の攻撃を防ぐことができ、20個全てを利用すれば、97％超の攻撃を防げるという。
OWASP Top 10: OWASP（ウェブアプリケーションセキュリティに関する国際的なオープンコミュニティ）が作成した、ウェブアプリケーションにおける重要な脆弱性１０項目とその脆弱性を作りこまないようにする方法とを記した資料。
Strategies to Mitigate Cyber Security Incidents: オーストラリアサイバーセキュリティセンター（Australian Cyber Security Centre：ACSC。元はAustralian Signals Directorate(ASD)が作成していたものを引き継いだ）が提唱する重要項目。
優先的に対策すべき箇所 > CISコントロール

2018年現在の最新版であるVersion 7の20個の評価項目は以下の通りである：
| 分類 | 番号 | 評価項目 | 評価項目（和訳） |
| --- | --- | --- | --- |
| Basic | 1 | Inventory and Control of Hardware Assets | ハードウェア資産の目録作成とコントロール |
| Basic | 2 | Inventory and Control of Software Assets | ソフトウェア資産の目録作成とコントロール |
| Basic | 3 | Continuous Vulnerability Management | 継続的な脆弱性管理 |
| Basic | 4 | Controlled Use of Administrative Privileges | 管理権限のコントロールされた利用 |
| Basic | 5 | Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations and Servers | モバイルデバイス、ラップトップ、ワークステーションおよびサーバにおけるハードウェアとソフトウェアのセキュアな設定 |
| Basic | 6 | Maintenance, Monitoring and Analysis of Audit Logs | 監査ログのメンテナンス、モニタリング、解析 |
| Foundational | 7 | Email and Web Browser Protections | eメールとウェブブラウザの保護 |
| Foundational | 8 | Malware Defenses | マルウェア対策 |
| Foundational | 9 | Limitation and Control of Network Ports, Protocols and Services | ネットワークポート、プロトコル、およびサービスの制限とコントロール |
| Foundational | 10 | Data Recovery Capabilities | データ復旧能力 |
| Foundational | 11 | Secure Configuration for Network Devices, such as Firewalls, Routers and Switches | ファイヤーウォール、ルータ、スイッチといったネットワークデバイスのセキュアな設定 |
| Foundational | 12 | Boundary Defense | 境界防御 |
| Foundational | 13 | Data Protection | データ保護 |
| Foundational | 14 | Controlled Access Based on the Need to Know | 「Need to Know」原則に基づいてコントロールされたアクセス |
| Foundational | 15 | Wireless Access Control | ワイヤレスネットワークのコントロール |
| Foundational | 16 | Account Monitoring and Control | アカウントのモニタリングとコントロール |
| Organizational | 17 | Implement a Security Awareness and Training Program | セキュリティの意識向上とトレーニングプログラムの実施 |
| Organizational | 18 | Application Software Security | アプリケーションソフトウェアのセキュリティ |
| Organizational | 19 | Incident Response and Management | インシデントへの対応とマネージメント |
| Organizational | 20 | Penetration Tests and Red Team Exercises | ペネトレーションテストとレッドチーム演習 |
優先的に対策すべき箇所 > OWASP Top 10

2017年度版の10項目は下記のとおりである：
| 番号 | 項目 |
| --- | --- |
A1：2017: インジェクション
A2：2017: 認証の不備
A3：2017: 機微な情報の露出
A4：2017: XML外部エンティティ参照（XXE）
A5：2017: アクセス制御の不備
A6：2017: 不適切なセキュリティ設定
A7：2017: クロスサイトスクリプティング（XSS）
A8：2017: 安全でないデシリアライゼーション
A9：2017: 既知の脆弱性のあるコンポーネントの使用
A10：2017: 不十分なロギングとモニタリング
優先的に対策すべき箇所 > Strategies to Mitigate Cyber Security Incidents

2018年現在は下記８項目：
| 項目 | 項目（和訳） |
| --- | --- |
application whitelisting: アプリケーションのホワイトリスト化
patching applications: アプリケーションへのパッチ適用
configuring Microsoft Office macro settings: マイクロソフトオフィスの設定のコンフィグレーション
application hardening: アプリケーションのハードニング
restricting administrative privileges: 管理者権限の制限
patching operating systems: OSへのパッチ適用
multi-factor authentication: 他要素認証
daily backups: デイリーバックアップ
脆弱性診断とその関連

本節では、システムのセキュリティ上の問題点を洗い出す検査や診断について述べる。なお、こうした検査や診断は脆弱性検査、脆弱性診断、セキュリティ検査、セキュリティ診断等と呼ばれるが、これらの語の指す範囲は論者やセキュリティ企業により異なる場合があるので注意されたい。
このような用語上の混乱をさけるため、本節ではペネトレーションテスト等も含めた最広義の意味での脆弱性検査(すなわちIPA意味での脆弱性検査)の事を「脆弱性診断関連の検査」と呼ぶことにする。
IPAによると、脆弱性診断関連の検査にはソースコードセキュリティ検査、ファジング、システムセキュリティ検査、ウェブアプリケーションセキュリティ検査、ペネトレーションテストの５つがあり、これらの検査を行うフェーズと主な検査対象は下記のとおりである。なお本節では、これら５つにレッドチームを加えた６つの検査について述べる。
| 検査名 | 主な利用フェーズ> 開発 | 主な利用フェーズ> 運用 | 主な検査対象> PC向けソフト | 主な検査対象> 組み込みソフト | 主な検査対象> ウェブアプリケーション | 主な検査対象> その他 |
| --- | --- | --- | --- | --- | --- | --- |
| ソースコードセキュリティ検査 | ○ | ー | ○ | ○ | ○ |  |
| ファジング | ○ | ー | ○ | ○ | ー |  |
| システムセキュリティ検査 | ○ | ○ | ー | ○ | ー | ネットワークシステム |
| ウェブアプリケーションセキュリティ検査 | ○ | ○ | ー | ー | ○ | クライアントサーバ |
| ペネトレーションテスト | ー | ○ | ー | ○ | ー | サーバ |
上の表の「主な利用フェーズ」は検査対象となる機器のシステムライフサイクルの中でどのフェーズでこれらの検査が利用されるのかを示している。なお、一般的にシステムの開発フェーズは企画、要件定義、設計、実装、テスト、納入という工程からなるが、これらの工程のうち脆弱性診断関連の検査が行われるのは実装工程とテスト工程である。
脆弱性診断関連の検査はPCI DSSやコモンクライテリアのような基準や規格で定期的に実施する事が要求される場合がある。
脆弱性診断とその関連 > ソースコードセキュリティ検査

ソースコードセキュリティ検査は、開発中のソフトウェアのソースコードをチェックする事で、セキュリティ上の問題点を発見する検査であり、おもに実装工程で行われる。その目的は、脆弱性を引き起こしやすい関数をソースコードから抽出したり、構文解析により脆弱性であると思われる箇所を特定する事である。
検査は人間によるソースコードレビューにより行われることもあるし、何らかのツールやサービスを用いて自動的にソースコードを検査することもある。
なお、ソースコードセキュリティ検査は実装段階で混入する脆弱性を発見するものであるので、そもそもソフトウェアの設計そのものに脆弱性があってもそれを発見するのは難しい。
脆弱性診断とその関連 > ファジング

→詳細は「ファジング」を参照
ファジングは開発したソフトウェアに脆弱性を引き起こしやすい様々な入力を与える事で、脆弱性を発見する手法である（インプットとして極端に大きな値を入力してみるなど）。ファジングは実装工程やテスト工程において、何らかのツールやサービスを利用して実行される。
ソースコードセキュリティ検査がソースコードを利用するホワイトボックステストであるのに対し、ファジングはソースコードを使わないブラックボックステストないしグレーボックステストである。
ソースコードセキュリティ検査と同様、ソフトウェアの設計そのものに含まれる脆弱性を発見するのは難しい。
制御システムセキュリティのEDSA認証ではファジングが必須になっているなど、ファジングの標準化の流れがある。
ファジングを出荷前に行う事により、出荷後に脆弱性が原因で回収等で莫大なコストが発生する可能性が下げられる。ファジングも導入費用とツールの保守費用をあわせて数百万から数千万円程度かかるが、半年程度で投資回収できるとされる。
脆弱性診断とその関連 > システムセキュリティ検査

→「脆弱性検査ツール § ネットワーク脆弱性検査ツール」も参照
システムセキュリティ検査は、システム上の機器に対してパッチのあたっていない脆弱性が存在しないか、不必要なポートが空いているなどの設定上の不備がないかを調べる検査である。何らかのツールやサービスを用いて主に開発時のテスト工程と運用時に行われる。なお性能の良いシステムセキュリティ検査ツールであれば、既知の脆弱性はもちろん、未知の脆弱性も発見できる。
システムセキュリティ検査では検査のためにシステムをスキャン（脆弱性スキャン）する必要があり、スキャンにはパッシブスキャンとアクティブスキャンがある。パッシブスキャンはミラーポートを使ったりWiresharkなどのアナライザを使ったりした受動的なパケットキャプチャ等で脆弱性を発見する手法である。それに対しアクティブスキャンはスキャナが機器にパケットを送信してその反応を見るなど能動的な方法で脆弱性を発見する手法である。
パッシブスキャンよりもアクティブスキャンのほうがより多くの脆弱性を発見できる可能性が高いが、その分システムに負荷をあたえたり、障害の原因になったりする可能性がある。
また脆弱性スキャンはネットワークの外部から行う外部スキャンとネットワークの内部から行う内部スキャンに分類できる。外部スキャンの場合、スキャンのための通信がネットワーク境界にあるファイヤーウォールに阻まれるため、内部スキャンほど多くの情報がとれない。しかし外部スキャンは攻撃者が外部から侵入可能な入口を発見できるなど、内部スキャンとは異なった役割を果たす事ができる。
システムセキュリティ検査は障害の原因になったり、検査対象が増えるにつれて検査費用が高くなるなどの事情があるため、ネットワーク全体に対して検査を行うとは限らず、一部の機器に限定して行われる事もある。
脆弱性診断とその関連 > ウェブアプリケーションセキュリティ検査

→詳細は「ウェブアプリケーション脆弱性診断」を参照
→「脆弱性検査ツール § Webアプリケーション脆弱性検査ツール」も参照
ウェブアプリケーションセキュリティ検査はウェブアプリケーションに文字列を送信したり、ページ遷移を確認したり、ログ解析したりするなど、ウェブアプリケーションに特化した検査である。何らかのツールやサービスを用いて主に開発時のテスト工程と運用時に行われる。他の検査と同様、実装時に作り込んだ脆弱性は発見できるものの、設計段階で入り込んだ脆弱性を発見するのは難しい。
IPAによるとウェブアプリケーションセキュリティ検査ツールは３タイプに分けられる。第一のタイプのものは、ブラウザとウェブサイトの間のプロキシとして動作するもので、検査実施者がブラウザでウェブサイトにアクセスした際に発生するリクエストをプロセスである検査ツールが補足し、取得したリクエストの一部を検査実施者が手動で検査用のコードを埋め込む形で書き換え、書き換えたリクエストをウェブサイトに送信してその反応をみる事で脆弱性検査を行う。
第二のタイプは検査ツールがウェブクライアントとして動作し、検査用コードの入ったリクエストをウェブサイトに自動送信し、ウェブサイトからのレスポンスを元に検査実施者にレポートを出力する。第二のタイプのものはツールに予め用意されている量の検査用コードを試自動で試せるのが利点であるが、人力に頼る第一のタイプほど細かな検査はできない。
第三のタイプでは検査ツールは検査実施者が操作するブラウザとウェブサイトとの通信を（書き換えずに）補足し、補足した情報から不審な動作等を探して検査実施者にレポートとして出力する。第一、第二のタイプと違い検査用コードをウェブサイトに送りつける事がないので、詳細な検査はできないが、その分検査によりウェブサイトに障害が発生する可能性が格段に低いという利点がある。
脆弱性診断とその関連 > ペネトレーションテスト

→詳細は「ペネトレーションテスト」を参照
ペネトレーションテストは実際の攻撃で使われる手口をそのまま利用する事で、人間が検査システムに攻撃をしかける事によりシステムの弱点を見つけ、システムが実際に攻撃されたときどこまで侵入され、どのような被害が発生するのか明らかにする検査であり、基本的に運用フェーズに行われる。ペネトレーションテストを実施するには攻撃手法に関する高度な知識を必要とするため、セキュリティ企業に依頼して実施する形が普通である。実際の攻撃手法を用いて検査を行うため、脆弱性のみならずシステムの不適切な運用等も発見できる。
その性質上、他の検査よりもシステムに不具合を生じさせる危険が大きいため、影響範囲を事前に特定し、復旧計画を立てて実施する必要がある。
テストは対象システムの構造をテストする人（ペンテスター）が知っているホワイトボックステストとシステム構造を知らないブラックボックステストにわけられ、さらに攻撃を開始する場所がシステム外部である外部テストとシステム内部である内部テストにわけられる。
脆弱性診断とその関連 > レッドチーム

→詳細は「レッドチーム」を参照
レッドチームはペネトレーションテストと同様、「レッドチーム」と呼ばれる攻撃チームが実際に攻撃をしかけてみる検査であり、レッドチームに対抗する防御側をブルーチームと呼ぶ。これらの言葉は元々軍事用語であり、敵軍であるレッドチームの視点で、自軍であるブルーチームの防御力や対応力を検証するものである。レッドチーム検査は「脅威ベースペネトレーションテスト（Threat-Led Penetration Testing : TLPT）」とも呼ばれる。
レッドチーム検査はペネトレーションテストよりもさらに実践的な検査である。ペネトレーションテストと違い、防御側であるブルーチームが攻撃の発生を認知しておらず、この状態でブルーチームがどこまで攻撃に耐えられるのかが試される。
レッドチーム検査ではハクティビスト、愉快犯、内部犯、金銭目的の犯罪者等、攻撃者の「ペルソナ」を作り、レッドチームのメンバーはそのペルソナになりきって攻撃を行う。典型的には攻撃前に初期調査を行い、マルウェアの配送、システム上への攻撃基盤構築、権限昇格、内部調査、目的達成といった手順をたどる。
レッドチームはサイバー攻撃だけではなく、物理セキュリティや人的要素に対しても攻撃をしかける。例えば初期調査では、ゴミ漁り、エレベーターでの盗み聞き、受付に「入館カードを忘れた」といって入り込むなどのソーシャル・エンジニアリング的な手法、偽Wifiポイントの立ち上げによる盗聴、SNSで情報発信を行っている社員からのOSINTなども行われる。
レッドチームのようなサービスをセキュリティベンダーが提供するようになったのは、標的型攻撃が一般化したことにある。標的型攻撃では上述のような物理要素・人的要素を犯す攻撃手法により情報収集されることもあり、こうした攻撃に耐えられるかを試すためにレッドチームのサービスが提供されるようになったのである。
脆弱性診断とその関連 > その他の診断

ネットワークに接続された不正機器の検出を目的とするネットワークディスカバリや、不正な無線通信を検出するワイヤレススキャンなどがある。
脆弱性ハンドリングと脆弱性管理 > 脆弱性ハンドリング

脆弱性情報ハンドリングとは、新たに発見された脆弱性関連情報の届け出を発見者に促し、届けられた情報を整理して製品開発者の担当窓口に提供して対策方法の立案を促し、適切なタイミングで脆弱性関連情報と対策情報を周知することで、被害を最小化するための活動である。ここで脆弱性関連情報とは脆弱性情報、脆弱性が存在する事の検証方法、およびその脆弱性を利用した攻撃方法（例えばエクスプロイトコード）の事を指す。また脆弱性への対策方法は、修正方法（＝パッチ適用）と回避方法に分類でき、回避方法とはパッチ以外の方法で脆弱性の影響度を回避・低減する方法、例えば脆弱性のある機能の無効化、代替ソフトへの移行、WAFの導入等がある。
攻撃者に脆弱性関連情報を悪用されるのを防ぐため、複数の製品が影響を受ける脆弱性の場合などにおいて、情報の公表に関して関係者間で一定の足並みをそろえる事(公開日一致の原則)が重要である。特に海外機関と調整が必要な際にこの原則を破って単独で情報公開を行うと、今後の脆弱性ハンドリングから外される場合がある。
脆弱性ハンドリングと脆弱性管理 > 脆弱性ハンドリング > 脆弱性ハンドリングの標準・ガイドライン

国際標準として以下のものがある：
ISO/IEC 30111 – Vulnerability handling process (脆弱性取扱い手順)
ISO/IEC 29147 – Vulnerability disclosure (脆弱性開示)
日本において脆弱性ハンドリング方法の概略は経済産業省告示「ソフトウエア製品等の脆弱性関連情報に関する取扱規程」に規定され、その詳細は「情報セキュリティ早期警戒パートナーシップガイドラライン」に規定されている。規定されている手順は、脆弱性が発見されたのがソフトウェア製品なのかウェブサイトなのかで異なる。
脆弱性ハンドリングと脆弱性管理 > 脆弱性ハンドリング > ソフトウェア製品の脆弱性に対するハンドリング手順

ソフトウェア製品の脆弱性関連情報の発見者はその情報をIPAの窓口に届け出し、IPAはその情報をJPCERT/CCに通知する。JPCERT/CCは製品開発者にその情報を連絡し、製品開発者は脆弱性の検証や対応方法を考える。JPCERT/CCは製品開発者と調整しながら脆弱性関連情報の公開スケジュールを決める。IPAとJPCERT/CCはスケジュールで定められた期日に脆弱性への策方法および対応状況を公表すする。IPAは原則四半期毎に統計情報を公表する。
脆弱性ハンドリングと脆弱性管理 > 脆弱性ハンドリング > ウェブサイトの脆弱性に対するハンドリング手順

ウェブサイトの脆弱性関連情報の発見者がその情報をIPAの窓口に届け出するところまでは上の手順と同様だが、ウェブサイトの場合、IPAはJPCERT/CCを介さずに直接ウェブサイト運営者に脆弱性関連情報を通知し、ウェブサイト運営者が脆弱性を修正する。ソフトウェアの場合と異なりIPAやJPCERTの側が脆弱性情報を公開する事は基本的にはない。個人情報漏洩等があった場合、その事実を公表するなどの処置はウェブサイト運営者が行う。
個人情報が漏洩している可能性があるにもかかわらず、ウェブサイト運営者が対応しない場合は、IPAが個人情報保護法34条に従った措置（主務大臣による勧告や命令）を依頼する。
IPAは原則四半期毎に統計情報を公表する。
脆弱性ハンドリングと脆弱性管理 > 脆弱性に関する情報源

脆弱性の情報源としては、各種ニュースサイト以外に、脆弱性情報データベース、ベンダアドバイザリ、注意喚起サイトがある。また攻撃情報の情報源としては、前述した脆弱性の情報源の他、攻撃コードデータベースがある。