サイバーセキュリティ

目次

• 概要
• サイバーセキュリティの基本概念
• 脅威モデルと攻撃の分類
• マルウェア攻撃の完全ガイド
• ネットワーク攻撃
• ソーシャルエンジニアリング攻撃
• 暗号化とパスワード攻撃
• 高度な攻撃：APTとゼロデイ
• Webセキュリティとの接続
• インシデント対応
• セキュリティベストプラクティス
• セキュリティフレームワーク
• 実装チェックリスト
• まとめ
• 参考文献

概要

アイデンティティ攻撃・マルウェア・ネットワーク防御・インシデント対応をつなげる

サイバーセキュリティは、個別の攻撃名を覚える章ではありません。何を守るのか、どこから侵入されるのか、侵入された後にどう広がるのか、そしてどう検知・復旧するのかを、ひとつの流れとして捉える章です。

この章で重視すること

• 攻撃名の暗記より、守る対象と侵入経路を整理すること
• 認証、ネットワーク、マルウェア、運用対応を別々ではなく連続した攻撃面として見ること
• 単一の対策ではなく、多層防御と検知・復旧まで含めて考えること
• 実装、運用、教育、組織プロセスをまとめてセキュリティとして捉えること

サイバーセキュリティの基本概念

セキュリティの三本柱(CIA: Confidentiality, Integrity, Availabilityトライアド)

サイバーセキュリティのすべての対策は、以下の3つの要素のバランスを取ることが目的です：

次の図は、どの対策も最終的には 機密性、完全性、可用性 のどれかを守るためにあることをまとめたものです。

1. 機密性 (Confidentiality)

定義： データが権限のないユーザーから保護されている状態

実現方法：

• 暗号化 — AES-256(Advanced Encryption Standard 256-bit)などの強力な暗号化アルゴリズムを使用
• アクセス制御 — ロールベースアクセス制御(RBAC: Role-Based Access Control)の実装
• 認証 — 多要素認証(MFA: Multi-Factor Authentication)による本人確認
• データ分類 — 機密度に応じたデータの分類と管理

実装例：

次のコードは、機密データをそのまま保存せず、暗号化して扱う最小例です。

// 機密データの暗号化保存
const crypto = require('crypto');

function encryptData(data, key) {
  const iv = crypto.randomBytes(16);
  const cipher = crypto.createCipheriv('aes-256-cbc', key, iv);
  let encrypted = cipher.update(data, 'utf8', 'hex');
  encrypted += cipher.final('hex');
  return iv.toString('hex') + ':' + encrypted;
}

2. 完全性 (Integrity)

定義： データが改ざんされることなく、正確で信頼できる状態

実現方法：

• デジタル署名 — メッセージ認証コード(MAC: Message Authentication Code)やHMAC(Hash-based Message Authentication Code)
• ハッシング関数 — SHA-256(Secure Hash Algorithm 256-bit)などで変更検知
• チェックサム — データ転送時の検証
• バージョン管理 — 変更履歴の追跡と監査ログ

実装例：

// HMACによるデータ整合性検証
const crypto = require('crypto');

function createHMAC(data, secret) {
  return crypto.createHmac('sha256', secret)
    .update(data)
    .digest('hex');
}

function verifyHMAC(data, secret, expectedHMAC) {
  const computedHMAC = createHMAC(data, secret);
  // タイミング攻撃を防ぐために定時間比較を使用
  return crypto.timingSafeEqual(
    Buffer.from(computedHMAC),
    Buffer.from(expectedHMAC)
  );
}

3. 可用性 (Availability)

定義： システムとデータが必要なときに、正規のユーザーに利用可能である状態

実現方法：

• 冗長性 — サーバーやネットワークの複数化
• フェイルオーバー — 障害時の自動切り替え
• DDoS対策 — トラフィック制限と分散
• バックアップ — 定期的なデータ復旧方法の確保

攻撃の分類フレームワーク

攻撃は以下のレイヤーで分類できます：

次の図は、攻撃を「どこが狙われるか」で大づかみに並べたものです。

深層防御 (Defense in Depth)

単一のセキュリティ対策に依存することは危険です。複数の重層的な防御層により、1つが破られても他が保護を続ける体制を構築します。

次の図は、防御を1か所に置かず、層として重ねる考え方を示しています。

脅威モデルと攻撃の分類

MITRE ATT&CKフレームワーク

攻撃者の行動を体系的に分類するフレームワークです(参考：https://attack.mitre.org)。ここでいう MITRE は米国の非営利研究組織、ATT&CK は実際の攻撃観測をもとにした戦術・技術の体系です。

APT(Advanced Persistent Threat: 高度で持続的な脅威)攻撃のライフサイクル(図解)

脅威インテリジェンスの使い方

IOC をただ集めるだけでは、防御はあまり強くなりません。大事なのは、どの粒度の情報を、誰が、どの判断に使うかを分けて考えることです。

特に実務では、「値がすぐ変わる IP や ハッシュ」だけに頼るより、PowerShellの悪用、正規アカウントの不自然な利用、DNSを使った持ち出し のような行動パターンを見る方が有効なことが多いです。

共有形式と運用の接続

脅威情報の共有では、STIX と TAXII という標準がよく使われます。

• STIX: 脅威情報の表現形式
• TAXII: その情報を共有するためのAPI / プロトコル

これらの標準を意識しておくと、SIEM、EDR、チケットシステム、外部の脅威情報ソースをつなぎやすくなります。

マルウェア攻撃の完全ガイド

マルウェアとは？

マルウェア(Malicious Software) = 悪意あるソフトウェアの総称

コンピュータシステムに意図的に損害を与えるために設計されたプログラムで、個人情報の盗難、システムの破壊、経済的利益の獲得などを目的とします。

マルウェアの分類体系(図解)

図の中に出てくる用語は、まず「どう増えるか」「何をするか」「どう隠れるか」で見ると整理しやすいです。たとえば トロイの木馬 は正規ソフトに見せかける型、キーロガー は入力を盗む型、ルートキット は侵入後に見つかりにくくする型です。

マルウェアの12+ 種類

1. ウイルス (Virus)

定義： 他のプログラムに寄生し、自己複製するマルウェア

特徴：

• 感染したプログラム実行時に作動
• ホストプログラムが必要(単独では動作不可)
• 自己複製して他のファイルに感染拡大

感染経路：

• 感染ファイルのダウンロード
• USB等の外部メディア経由
• メールの添付ファイル

実装的特性：

元のプログラムの実行ファイル
↓
ウイルスコードが挿入
↓
ウイルス実行 + 元のプログラム実行
↓
他のファイルに自己複製

対策：

• アンチウイルスソフトの導入と常時更新
• 信頼できないファイルの実行を避ける
• メールの添付ファイルを慎重に扱う
• ファイアウォール・エンドポイント検知と対応(EDR: Endpoint Detection and Response。端末上の不審挙動を検知し、隔離や調査まで行う仕組み)

2. ワーム (Worm)

定義： 自己複製し、ホストプログラムなしで独立して動作・拡散するマルウェア

特徴：

• 単独で動作(ウイルスと異なる)
• ネットワークを通じて自動拡散
• ウイルスより伝播速度が速い

有名な例：

• WannaCry (2017年)— Windows SMB脆弱性を悪用し、150カ国で23万台以上に感染
• Stuxnet (2009年)— イランの核施設を狙った国家支援型ワーム

Stuxnet は、産業機器を制御するシステムまで狙ったことで有名なワームです。EternalBlue は、Windowsのファイル共有機能 SMB にあった欠陥を悪用する攻撃手法として知られています。

被害例(WannaCry)：

感染経路：EternalBlueという脆弱性(Windows SMB: Server Message Block)
    ↓
システムの全ファイルを暗号化
    ↓
身代金メッセージ表示
    ↓
150カ国で230,000台以上に感染
    ↓
推定損害額：50億ドル以上

対策：

• OSとソフトウェアのセキュリティパッチを迅速に適用
• ネットワークセグメンテーション(感染の隔離)
• 定期的なバックアップ(ネットワークから分離)
• ファイアウォール設定で外部ネットワークからのアクセス制限

3. トロイの木馬 (Trojan)

定義： 正規ソフトウェアに偽装し、ユーザーに実行させてシステムを侵害するマルウェア

特徴：

• 自己複製しない(手動実行が必要)
• 一見無害なプログラムに見える
• 実行後、悪意ある活動を実行

種類と目的：

感染シナリオ：

ユーザーが「無料ソフト」をダウンロード
    ↓
実は悪意あるトロイが混在
    ↓
インストール時に自動実行
    ↓
・キーロガー起動
・バックドア開放
・ファイル窃取
    ↓
攻撃者がシステムを遠隔操作

対策：

• 信頼できるソースからのみダウンロード
• 実行ファイルのデジタル署名を確認
• VirusTotalなどのマルウェア判定サービスでファイルスキャン
• サンドボックス環境で未知のプログラムをテスト

4. ランサムウェア (Ransomware)

定義： ファイルを暗号化またはシステムをロックし、身代金を要求するマルウェア

2026年の進化：

• 二重身代金 (Double Extortion) — 暗号化＋データ盗難＋公開脅迫
• 三重身代金 (Triple Extortion) — 加えて取引先や顧客への脅迫も追加

ランサムウェア攻撃のフロー：

暗号化の仕組み：

// ランサムウェアの簡略的な仕組み(教育目的)
// 実際にはこのようなコードで強力な暗号化を行う

const crypto = require('crypto');

// 被害者ごとに異なる鍵を生成
const victimKey = crypto.randomBytes(32);

// すべてのファイルを暗号化
function encryptFile(filepath, key) {
  const data = fs.readFileSync(filepath);
  const iv = crypto.randomBytes(16);
  const cipher = crypto.createCipheriv('aes-256-cbc', key, iv);
  let encrypted = cipher.update(data);
  encrypted = Buffer.concat([encrypted, cipher.final()]);

  // 復号に必要な秘密鍵は攻撃者が保管
  // ユーザーは復号不可能

  fs.writeFileSync(filepath + '.locked', encrypted);
}

有名なランサムウェア攻撃：

対策：

• バックアップ戦略 — 外部接続ネットワークから分離したバックアップ
• セグメンテーション — ネットワークを小分けにして感染拡大を制限
• EDR導入 — エンドポイント検出応答ツール
• アクセス制御 — RDP、VPN等のリモートアクセスを制限
• パッチ管理 — 既知脆弱性の迅速な修正
• ユーザー教育 — フィッシング認識トレーニング

5. スパイウェア (Spyware)

定義： ユーザーの許可なく、個人情報やアクティビティを監視・記録するマルウェア

監視対象：

• Webブラウジング履歴
• キーストローク(パスワード等)
• 位置情報
• 金融情報
• メール・メッセージ内容

実装方法：

// スパイウェアの例(教育目的)
// 実際の悪意あるコードではない

// キーストロークをログ
document.addEventListener('keypress', function(e) {
  logKeystroke(e.key);  // 入力内容を記録
});

// 位置情報を取得
navigator.geolocation.getCurrentPosition(function(pos) {
  sendLocationToAttacker(pos);  // 攻撃者に送信
});

// 定期的にWebブラウジング履歴を送信
setInterval(function() {
  sendBrowsingHistoryToAttacker();
}, 3600000);  // 1時間ごと

対策：

• 信頼できるセキュリティソフト導入
• ブラウザプラグインを慎重に管理
• 定期的なシステムスキャン
• プライバシー設定の強化

6. アドウェア (Adware)

定義： ユーザーの同意なく、目的を定めた広告を表示するソフトウェア

特徴：

• スパイウェアとの組み合わせが多い
• 閲覧履歴を追跡して広告をカスタマイズ
• ブラウザのホームページやデフォルト検索エンジンを改変

被害：

• システムパフォーマンス低下
• プライバシー侵害
• セキュリティリスク増加

対策：

• 広告ブロッカーの使用
• フリーソフト導入時に注意(アドウェアがバンドルされていないか)
• 定期的なシステムクリーニング

7. ルートキット (Rootkit)

定義： 管理者(root)権限を取得し、システムの深層に隠れるマルウェア

特徴：

• カーネルレベルで動作
• 通常のセキュリティツールから隠蔽
• 検出が極めて困難

動作イメージ：

対策：

• セキュアブート(UEFI)の有効化
• カーネルパッチの適用
• 信頼できるメディアからのOS再インストール
• BIOS/UEFI更新

8. キーロガー (Keylogger)

定義： キーボード入力を記録し、パスワードや機密情報を盗むマルウェア

種類：

1. ソフトウェアキーロガー

// ソフトウェアキーロガーの例(教育目的)
// 実際に実装しないでください

document.addEventListener('keypress', (e) => {
  const keystroke = {
    key: e.key,
    timestamp: new Date(),
    url: window.location.href
  };

  // 攻撃者のサーバーに送信
  sendToAttacker(keystroke);
});

2. ハードウェアキーロガー

• キーボードとコンピュータの間に物理的に挿入
• 検出が難しい

盗まれる情報：

• ログインID・パスワード
• クレジットカード番号
• 銀行取引情報
• メールアドレス

対策：

• スクリーンキーボード(オンスクリーン)の使用(銀行サイト等)
• MFA導入(パスワードだけでなく別の認証方法)
• セキュリティソフト導入
• 定期的なパスワード変更

9. ボットネット (Botnet)

定義： 攻撃者がリモートから操作できる、感染コンピュータのネットワーク

「ボット」の意味： Robot(ロボット)の略で、自動化されたコンピュータという意味

ボットネットの構造：

命令例：「DDoS攻撃を実行」 →すべてのボットが同時に目標を攻撃

ボットネットの用途：

有名なボットネット：

• Mirai (2016年) — IoTデバイスを感染させ、100万超のボット化
• Emotet (2018-2021年) — バンキングトロイ + ボットネット

対策：

• ファイアウォール設定で不審な通信をブロック
• ネットワークトラフィック監視(IDS)
• 定期的なセキュリティ監査
• メールフィルタリング(ボット配布メール検知)

10. 拡張マルウェア類

ファイルレス マルウェア (Fileless Malware)

定義： ハードディスクにファイルを書き込まず、メモリ上で動作するマルウェア

特徴：

• ディスク検索では検出されない
• システム再起動で消滅(永続性なし)
• 既存のシステムプロセス(PowerShell等)を悪用
• 検出が困難

例： Astaroth(PowerShellを悪用)

対策：

• メモリスキャン機能のあるEDR
• PowerShellの実行ポリシー制限
• 監査ログの有効化と監視

ワイパー マルウェア (Wiper Malware)

定義： ファイルを暗号化ではなく、完全に削除するマルウェア

特徴：

• ランサムウェアと異なり、復旧不可
• 身代金ではなく、純粋な破壊が目的
• 国家レベルの攻撃に利用

例： WhisperGate(ウクライナ侵攻時に使用)

対策：

• オフラインバックアップ(ネットワーク分離)
• 定期的なバックアップテスト
• インシデント対応計画

ウーティスルマルウェア (Footpath Rootkitなど)

定義： システムの正当な機能を悪用して隠蔽するマルウェア

対策：

• カーネルレベルの監視(HIDS: Host-based Intrusion Detection System)
• セキュアブート検証
• メモリダンプ分析

11. 可視的な兆候：マルウェア感染の警告信号

マルウェア対策の多層防御戦略

ネットワーク攻撃

ネットワークセキュリティの基本

ネットワーク攻撃とは： データが転送される過程で、通信をインターセプト(横取り)・改ざん・破壊したり、サービスの可用性を奪う攻撃

ネットワーク攻撃とOSI(Open Systems Interconnection)レイヤー(図解)

主要なネットワーク攻撃

1. DDoS攻撃(分散型サービス妨害)

定義： Distributed Denial of Service

複数のコンピュータから同時に標的システムへ大量のトラフィックを送信し、サービスをダウンさせる攻撃

一般的なDoS攻撃との違い：

DDoS攻撃のタイプ：

L3/L4攻撃(容量ベース)

目的：ネットワークパイプを飽和
方法：大量のパケットを送信

・SYN Flood
  TCP 3ウェイハンドシェイクを悪用
  SYNパケットで接続リソースを枯渇

・UDP Flood
  UDPパケットで帯域を浪費

・ICMP Flood
  ping(ICMP)で帯域を消費

SYN Floodの仕組み：

1. 攻撃者が大量のSYNパケットを送信
2. 標的は各SYNに対しSYN-ACK返信
3. 攻撃者は確認ACKを返さない(半開状態)
4. 接続テーブルが満杯になり、正規の接続ができなくなる

時系列：
[SYN] → [SYN] → [SYN] → ...(攻撃者から)
      ↓      ↓      ↓
   [SYN-ACK](標的が応答、ただし応答ACK来ない)
      ↓
接続リソース枯渇 → サービス停止

L7攻撃(アプリケーションベース)

目的：アプリケーション層で処理を遮断
方法：アプリケーションの脆弱性や処理負荷を悪用

・HTTP Flood
  HTTP GETリクエストを大量送信(見た目は正常)

・Slowloris攻撃
  接続を遅くゆっくり送信、接続を開いたままにして枯渇

・DNS Query Flood
  DNSクエリを大量送信

実際のDDoS攻撃規模：

• 2016年Mirai攻撃 — 1.2 Tbps(テラビット/秒)
• 2020年AWS DDoS — 2.3 Tbps
• 2021年Google DDoS — 5.3 Tbps(当時最大)

DDoS攻撃の利用目的：

DDoS対策：

// Node.jsでのDDoS対策実装例

const rateLimit = require('express-rate-limit');

// レート制限：1分あたりのリクエスト数を制限
const limiter = rateLimit({
  windowMs: 60 * 1000,  // 1分
  max: 100,              // 最大100リクエスト
  message: 'Too many requests, please try again later',
  standardHeaders: true,
  legacyHeaders: false
});

app.use(limiter);

// さらに厳しい制限：ログインエンドポイント用
const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,  // 15分
  max: 5,                     // 5試行まで
  skipSuccessfulRequests: true
});

app.post('/login', loginLimiter, (req, res) => {
  // ログイン処理
});

組織的なDDoS対策：

• DDoS対策専門ツール(Cloudflare、Akamai等)
• WAF(Web Application Firewall)
• ネットワークセグメンテーション
• ISPレベルでの流入トラフィック監視
• 事前にいくつかのISPと契約(バイパスルート確保)

2. 中間者攻撃 (Man-in-the-Middle / MitM)

定義： 攻撃者が通信の途中に割り込んで、送受信側に知られないうちに通信を盗聴・改ざんする攻撃

攻撃のシナリオ：

正規の通信(攻撃なし)：
Aさん ←→ Bさん

MitM攻撃：
Aさん ←→ [攻撃者] ←→ Bさん
        ↑           ↑
   Aからのデータを盗聴・改ざん
   Bからのデータを盗聴・改ざん

双方に「相手と通信している」と思わせる

MitM攻撃の種類：

ARPスプーフィング

WifiネットワークでのMitM

攻撃手順：
1. 攻撃者がARP(Address Resolution Protocol)を偽造
2. ネットワークに「私はGatewayだ」と嘘を放送
3. デバイスが攻撃者を経由して通信
4. すべての通信が攻撃者に見える

IPv4アドレス ←→ MACアドレス の対応関係を改ざん

実装例(教育目的)：

# ARPスプーフィング(scapy使用、教育目的のみ)
# 実際に悪用しないでください

from scapy.all import Ether, ARP, sendp
import time

def spoof(target_ip, spoof_ip):
    """
    target_ip: 標的のIPアドレス
    spoof_ip: なりすまし対象のIPアドレス
    """
    # 標的に「spoof_ipは私だ」と嘘をつく
    arp_packet = Ether(dst="ff:ff:ff:ff:ff:ff") / ARP(
        pdst=target_ip,
        psrc=spoof_ip,
        op=2  # is-at(応答)
    )
    sendp(arp_packet, verbose=False)

SSL/TLS中間者攻撃

HTTPS通信をインターセプト

攻撃者が自分の証明書を使用して通信を仲介

被害者 ←→ [攻撃者(偽の証明書)] ←→ サーバー

被害者はHTTPSと思っているが、
実は攻撃者が間に入っている

DNSスプーフィング

DNS応答を偽造

被害者：example.comは何IPですか？
DNS:「192.168.1.1」(正しい)

攻撃版：
被害者：example.comは何IPですか？
攻撃者が偽DNS応答：「192.168.1.100」(攻撃者のサーバー)

結果：被害者が偽サイト(フィッシングサイト等)へ接続

MitM攻撃の対策：

実装例：

// Node.jsでHTTPSを強制

const https = require('https');
const fs = require('fs');
const express = require('express');

const app = express();

// HTTP → HTTPSリダイレクト
app.use((req, res, next) => {
  if (req.header('x-forwarded-proto') !== 'https') {
    res.redirect(`https://${req.header('host')}${req.url}`);
  } else {
    next();
  }
});

// HTTPSサーバー起動
const options = {
  key: fs.readFileSync('/path/to/key.pem'),
  cert: fs.readFileSync('/path/to/cert.pem')
};

https.createServer(options, app).listen(443);

3. ポートスキャン

定義： 対象システムのネットワークポートを調査し、どのサービスが実行されているかを探る偵察活動

ポートとは？ ネットワーク通信の「窓口」(0～65535の番号で識別)

よく使われるポート：
・80   → HTTP (Webサイト)
・443  → HTTPS (暗号化Webサイト)
・22   → SSH (リモートシェル)
・3306 → MySQL (データベース)
・5432 → PostgreSQL (データベース)
・3389 → RDP (Windows Remote Desktop)

ポートの状態：

ポートスキャンの種類：

TCPコネクトスキャン

各ポートに完全なTCP接続を試みる
(最も遅いが、検出可能性も高い)

1. ターゲットにSYNパケット送信
2. SYN-ACK返信あれば、ポートはOpen
3. ACKを送信して接続確立
4. 完全な接続がログに記録される

SYNスキャン

TCP 3ウェイハンドシェイクを完了しない
(「ハーフオープン」スキャン)

1. SYNパケット送信
2. SYN-ACK返信あればOpen
3. 接続を完了しない(RSTで切断)
4. ログに残りにくい(昔)

現在は検出されることも多い

UDPスキャン

UDPプロトコルでポートを調査
(ICMPレスポンスを基に判定)

実装例(nmap):
nmap -sUターゲット

有名なスキャンツール：

• nmap — 業界標準のポートスキャナ
• Wireshark — ネットワークパケット解析
• Masscan — 超高速マルチスレッドスキャナ
• Shodan — インターネット上のデバイスを検索

ポートスキャンの検出と対策：

検出：
・IDS(Intrusion Detection System: 侵入検知システム)で異常なパケットパターン検知
・ファイアウォールログで大量の接続試行を記録
・SIEM(Security Information and Event Management。複数システムのログを集約し、相関分析で異常を見つける仕組み)で関連イベントを相関分析

対策：
・ファイアウォール設定で不要なポートを閉鎖
・デフォルトサービスポートを変更(SSHを2222等)
  ※ただしセキュリティ向上効果は限定的
・非常に疑わしいスキャンパターンをブロック
・IDS/IPSでアラート生成

ソーシャルエンジニアリング攻撃

概要

ソーシャルエンジニアリングとは？

技術的な脆弱性ではなく、人間の心理や信頼を悪用して、機密情報を盗んだり、システムアクセスを奪う攻撃。

特徴：

• 技術的スキルが不要な場合が多い
• 攻撃の成功率が高い(人間は最も脆弱)
• 検出が難しい(技術ツールでは検知できない)

補足： 実務では、フィッシングや認証情報の窃取が初期侵入の主要要因として繰り返し報告されます。正確な比率は調査機関や対象業界で変わるため、年次レポートと併読してください。

ソーシャルエンジニアリング攻撃フロー(図解)

ソーシャルエンジニアリングの種類

1. フィッシング (Phishing)

定義： 正規の組織を装ったメール、SMS(Short Message Service)、電話で個人情報やクレデンシャルを騙し取る

フィッシングメールの特徴：

典型的なフィッシングメール例

From: support@amazon.co.jp
件名: 【重要】お客様のアカウントが制限されました

本文：
セキュリティ上の理由により、
お客様のAmazonアカウントが一時的に制限されています。

以下のリンクをクリックして、
すぐに確認・再認証してください：

[このリンクをクリック]
↑ このリンクが詐欺サイト(example.jpではなくattacker.com)

----------
⚠️ 赤い旗：
・緊急性を強調(制限、期限切れ、問題が発生)
・クリックを促す
・公式な見た目だが、ドメインが異なる
・個人情報入力フォーム

フィッシングのバリエーション：

Spear Phishingの例：

一般的なフィッシング：
「すべてのAmazonユーザーへ」

Spear Phishing：
「John Smithさんへ」
・名前を知っている
・部門を知っている
・最近の取引を言及
・個人的な詳細を含む

一般的なばらまき型より信じ込ませやすく、被害につながりやすい

フィッシング対策：

// メール検証・フィルタリング実装例

const validateEmailSignature = (email) => {
  // SPF, DKIM, DMARCを検証

  // 1. SPF (Sender Policy Framework)
  // 「example.comからのメール」が本物か確認

  // 2. DKIM (DomainKeys Identified Mail)
  // メール署名を暗号的に検証

  // 3. DMARC (Domain-based Message Authentication, Reporting, and Conformance)
  // SPF + DKIMの組み合わせで強力な認証
};

// メール内のリンクを検証
const validateLinks = (emailBody) => {
  const links = emailBody.match(/href=["']([^"']+)["']/g);

  links.forEach(link => {
    const displayedURL = link.display;
    const actualURL = link.href;

    // 表示URLと実際URLが異なるかチェック
    if (displayedURL !== actualURL) {
      flagSuspicious();
    }
  });
};

ユーザー教育：

2. スプーフィング (Spoofing)

定義： 信頼できるソースになりすまして、ユーザーを騙す攻撃

スプーフィングの種類：

メールアドレススプーフィング

IPアドレススプーフィング

攻撃者が別のIPアドレスになりすまし
パケットの送信元IPを偽造する

BGPハイジャッキング：
攻撃者がBGP(Border Gateway Protocol)を悪用
ネットワークルーティングを乗っ取る

例：CloudflareのBGP障害(2020年)
→ 某国のスポーフィングでインターネットが一時ダウン

DNSスプーフィング

前述(MitM攻撃内で説明)

Caller IDスプーフィング

電話のCallerIDを詐欺者の好きな番号に設定
「銀行です」と偽って電話

技術的背景：
・PSTN(Public Switched Telephone Network)は
  送信者を検証しない
・SIP(Session Initiation Protocol)で容易に変更可能

例：Vishing攻撃で利用
「あなたの銀行です。セキュリティ確認のため...」
実は詐欺犯

スプーフィング対策：

3. プリテキスティング (Pretexting)

定義： もっともらしい架空のシナリオを作成して、ターゲットが情報を開示するよう誘導する

例シナリオ：

攻撃者：「こんにちは、給与システムのITです。
        パスワードリセットのため、現在のパスワードを
        教えていただけますか？」

被害者：「分かりました...」

現実：攻撃者がパスワードを聞き出した

プリテキストの構成要素：

1. 信頼できる身分の確立

   • 「私は会社のITサポートです」
   • 「Amazonのセキュリティチームです」
   • 「銀行の調査部門です」

2. 説得力のある理由

   • セキュリティ侵害の調査
   • 定期的なシステムメンテナンス
   • アカウント検証

3. 心理的プレッシャー

   • 緊急性(「すぐに対応が必要」)
   • 権威性(「これは必須です」)
   • 恐怖(「アカウントがロックされます」)

実例(大企業へのプリテキスト攻撃)：

攻撃フロー：
1. HR部門のスタッフに成りすまし
   「新入社員のオンボーディング確認」
2. IT部門のスタッフを装う
   「セキュリティ監査のため、アクセス権確認」
3. 法務部からのメール
   「機密文書アクセステスト」

複数の部門の認識を巧みに利用
→ 被害者が統一された身分確認をしない
→ 情報開示

プリテキスティング対策：

4. ベイティング (Baiting)

定義： 物理的または仮想のアイテムで誘惑し、ユーザーが悪意あるアクションを取るよう仕向ける攻撃

物理的ベイティング：

USBスティック ベイティング(最も有名)

攻撃者が駐車場や会社の入り口に
感染ファイルが入ったUSBを落とす

「Lost USB - PRIVATE」というラベル

被害者が拾って接続
→ マルウェア自動実行
→ システム感染

対策：
✓ 外部デバイスのオートラン無効化
✓ USB使用ポリシー(禁止)
✓ ユーザー教育

仮想的ベイティング：

魅力的なファイル名のダウンロード

例：
・「2024給与表.xlsx」
・「セキュリティアップデート.exe」
・「CEO給与.xlsx」
・「ボーナス支給予定.pdf」

ファイルは実はマルウェア

対策：
✓ ファイルタイプ検証(拡張子だけでなく)
✓ サンドボックス実行
✓ デジタル署名検証

Webベイティング：

魅力的なテキストリンク

例：
「有名人がこれを無料でダウンロード」
「激安チケット」
「クリック → $50ギフトカード」

リンク先：
マルウェア、詐欺ページ、ランサムウェア

対策：
✓ リンク検証(ホバーして確認)
✓ URLレピュテーション検査
✓ Webフィルタリング

対策実装：

// Webベイティング防止実装例

// 1. ダウンロードファイル検証
app.post('/download', (req, res) => {
  const file = req.body.file;

  // ファイルタイプをMagic Numberで検証
  const actualType = detectFileType(file);
  const claimedType = mime.getType(file.name);

  if (actualType !== claimedType) {
    return res.status(400).json({ error: 'File type mismatch' });
  }

  // ファイルスキャン
  const scanResult = await scanFileWithAntivirus(file);
  if (scanResult.infected) {
    return res.status(400).json({ error: 'Malware detected' });
  }

  res.download(file);
});

// 2. リンク検証
const validateLink = (url) => {
  // URLレピュテーション照会
  const reputation = checkURLReputation(url);

  if (reputation.isKnownMalicious) {
    showWarning('This link may be dangerous');
    return false;
  }

  return true;
};

5. その他のソーシャルエンジニアリング

Quid Pro Quo (見返りのための詐欺)

「何かを与える代わりに、情報をください」

例：
攻撃者：「HRです。給与計算システムのアップグレードのため、
        全従業員のID番号が必要です。
        情報を提供した方には$50のアマゾンギフトカード」

効果：
利益の約束で情報開示を促す

リバースソーシャルエンジニアリング

攻撃者が「助者」として現れる

例：
1. 攻撃者が偽のシステムエラーを作成
2. ユーザーがサポートに連絡
3. 攻撃者が「サポート」として応答
4. 「対策のため、これを実行して」とマルウェアを指示

ユーザーが攻撃者に連絡するよう仕向ける

ソーシャルエンジニアリング対策の統合戦略

暗号化とパスワード攻撃

パスワード攻撃の種類

1. ブルートフォース攻撃 (Brute Force Attack)

定義： パスワードのあらゆる組み合わせを試行して、正しいパスワードを探す攻撃

計算量の例：

パスワードの長さと可能な組み合わせ数：

1文字:  26字  = 26通り
2文字:  26²   = 676通り
3文字:  26³   = 17,576通り
4文字:  26⁴   = 456,976通り
8文字:  26⁸   = 208,827,064,576通り(約2.08億)
12文字: 26¹²  = 95,428,956,661,682,176通り(約95兆)

大文字+小文字+数字+特殊文字 の場合：
8文字:  94⁸   ≈ 6.1 × 10¹⁵通り

攻撃の現実性：

GPUでの試行速度は、利用するハードウェア、ハッシュアルゴリズム、
ソルトの有無、パスワードクラッキング設定で大きく変わる

単純パスワード破解時間：
・8文字(小文字のみ): < 1秒
・10文字(大小混在): 数秒～分
・12文字(複雑): 数時間～日
・16文字(複雑): 数ヶ月～数年

ブルートフォース攻撃の実装イメージ：

# ブルートフォース攻撃(教育目的、実際に実行しないでください)

import itertools
import string
import hashlib

def brute_force_password(target_hash, password_length=8):
    """
    target_hash: 破るべきハッシュ値
    password_length: パスワード長
    """
    characters = string.ascii_lowercase + string.digits
    attempts = 0

    for password in itertools.product(characters, repeat=password_length):
        password_str = ''.join(password)
        password_hash = hashlib.sha256(password_str.encode()).hexdigest()
        attempts += 1

        if password_hash == target_hash:
            return password_str, attempts

        # 進捗表示(毎100万試行)
        if attempts % 1000000 == 0:
            print(f"{attempts:,} 試行中...")

    return None, attempts

# 実行例(実際には実行しない)
# result, attempts = brute_force_password(target_hash)
# print(f"Found: {result} in {attempts} attempts")

対策：

実装例：

```javascript
// ログイン試行の監視と制限

const failedAttempts = new Map();

app.post('/login', (req, res) => {
  const username = req.body.username;
  const ip = req.ip;
  const key = `${username}:${ip}`;

  // 過去の失敗試行を確認
  const attempts = failedAttempts.get(key) || { count: 0, timestamp: Date.now() };

  // 1時間以内に5回失敗したらロック
  if (Date.now() - attempts.timestamp < 3600000 && attempts.count >= 5) {
    return res.status(429).json({
      error: 'Too many failed attempts. Try again later.'
    });
  }

  // ログイン処理
  const user = authenticateUser(username, req.body.password);

  if (!user) {
    // 失敗をカウント
    attempts.count++;
    attempts.timestamp = Date.now();
    failedAttempts.set(key, attempts);

    return res.status(401).json({ error: 'Invalid credentials' });
  }

  // 成功時は記録をリセット
  failedAttempts.delete(key);
  res.json({ success: true, token: generateToken(user) });
});

2. 辞書攻撃 (Dictionary Attack)

定義： ブルートフォースと異なり、実際に使われる可能性の高い単語や既知のパスワードリストを試行する攻撃

有名なパスワード漏洩データベース：

2013年Adobe漏洩
  → 600万パスワード

2016年Yahoo漏洩
  → 5億アカウント

2019年Collection #1
  → 7.73億メールアドレス+パスワード

2021年LinkedIn漏洩
  → 7億ユーザーのメール+名前+電話番号

これらの情報は辞書攻撃用のリストに組み込まれる

攻撃プロセス：

よく使われるパスワードTOP 10(実際のデータ)：

1. password
2. 123456
3. 12345678
4. qwerty
5. abc123
6. monkey
7. 1234567
8. letmein
9. trustno1
10. dragon

対策：

実装例：

```javascript
// Have I Been Pwned APIを使用してチェック

const crypto = require('crypto');
const fetch = require('node-fetch');

async function checkPasswordBreached(password) {
  // パスワードのSHA-1ハッシュを計算
  const hash = crypto.createHash('sha1').update(password).digest('hex').toUpperCase();

  // 最初の5文字を送信(プライバシー保護)
  const prefix = hash.slice(0, 5);
  const suffix = hash.slice(5);

  const response = await fetch(`https://api.pwnedpasswords.com/range/${prefix}`);
  const data = await response.text();

  // 返されたハッシュに一致するか確認
  if (data.includes(suffix)) {
    return true;  // ブリーチ済みパスワード
  }

  return false;  // 安全
}

app.post('/register', async (req, res) => {
  const password = req.body.password;

  // パスワードがブリーチ済みかチェック
  const isBreached = await checkPasswordBreached(password);

  if (isBreached) {
    return res.status(400).json({
      error: 'This password has been exposed in a data breach. Please choose another.'
    });
  }

  // ユーザー登録処理続行
});

3. レインボーテーブル攻撃 (Rainbow Table Attack)

定義： 事前に計算した膨大なハッシュ値テーブルから、盗んだパスワードハッシュに対応する元のパスワードを素早く検索する攻撃

仕組み：

従来のブルートフォース：
パスワード "password123" を入力
   ↓
ハッシュ計算SHA256("password123") = 0x1a2b3c...
   ↓
盗んだハッシュと比較
   ↓(毎回計算が必要なので遅い)

レインボーテーブル：
事前に計算済みテーブル：
  password    → 0x1a2b3c...
  123456      → 0x4d5e6f...
  qwerty      → 0x7g8h9i...
  ...
   ↓
盗んだハッシュ0x1a2b3c... を検索
   ↓(テーブル検索は非常に速い)
即座に "password" が一致

特徴：
✓ ハッシュ値があれば即座にパスワード発見可能
✓ 計算は事前にすべて完了
✓ 数GB～TB規模のテーブル

有名なレインボーテーブル：

対策：Salting(ソルト化)とHashing(ハッシング)：

問題：
password → SHA256("password") = 0x5e884...

同じパスワードなら同じハッシュ
→ レインボーテーブルで検索可能

解決策：Saltを追加

password + salt → SHA256("password" + salt) = 0x7g9h2...
password + salt → SHA256("password" + salt) = 0x9k1m3...
(saltが異なれば、ハッシュも異なる)

レインボーテーブルは無効化
(各ユーザーごとに異なるハッシュ)

実装例：

// bcryptで自動的にsaltが追加される

const bcrypt = require('bcryptjs');

// ユーザー登録時
async function registerUser(username, password) {
  // bcryptが自動的にsaltを生成してハッシング
  const hashedPassword = await bcrypt.hash(password, 10);
  //         ↑ saltラウンド数(高いほど安全＆遅い)

  // hashedPassword例：
  // $2b$10$O4x6RZpQbVF8wQAhO3XFBuKeOlKfZGlXYrM0Y0Y2Y0Y0Y0Y0Y0Y...
  //  ↑    ↑  ↑ salt (salt rounds, salt値 を含む)
  //  version round

  db.save({ username, hashedPassword });
}

// ログイン時
async function loginUser(username, password) {
  const user = db.findByUsername(username);

  // 入力パスワードとハッシュを比較
  const isMatch = await bcrypt.compare(password, user.hashedPassword);

  if (isMatch) {
    return { success: true, token: generateToken(user) };
  }

  return { success: false };
}

// ⚠️ 注意：MD5, SHA-1はpassword hashingに使用してはいけない
// NG: var hash = require('crypto').createHash('sha1').update(password).digest('hex');
// OK: var hash = await bcrypt.hash(password, 10);

推奨されるPassword Hashing関数：

その他の暗号化関連攻撃

サイドチャネル攻撃 (Side-Channel Attack)

暗号化アルゴリズム自体ではなく、
実装の「副作用」を悪用

例：
・タイミング攻撃 — 処理時間の差異から情報推測
・キャッシュ攻撃 — CPUキャッシュアクセスパターン
・電力分析 — 消費電力の揺らぎから情報抽出
・音響暗号解析 — 電子機器の音声周波数パターン

例：タイミング攻撃

# タイミング攻撃の例(簡略版)

# ❌ 脆弱な実装：字句比較
def check_password_weak(input_pwd, stored_pwd):
    return input_pwd == stored_pwd  # 最初の文字で不一致なら即終了
    # 処理時間がパスワードの一致度で変わる

# 入力が "password1" の場合：
#   正答 "password123"
#   比較時間が短い → "p" だけ一致
# 入力が "passwordX" の場合：
#   正答 "password123"
#   比較時間が長い → "passwor" までは一致、次で異なる
#
# 攻撃者が処理時間を測定 → パスワードを段階的に特定

# ✅ 安全な実装：定時間比較
import secrets
import hmac

def check_password_safe(input_pwd, stored_pwd):
    # hmac.compare_digest = 定時間で比較
    return hmac.compare_digest(input_pwd, stored_pwd)
    # 入力内容に関わらず、常に同じ時間

対策：

✓ 定時間比較(Constant-Time Comparison)
✓ 実装時にCPUタイミングを意識
✓ ハードウェアレベルでの保護
✓ 継続的なセキュリティ監査

高度な攻撃：APTとゼロデイ

Advanced Persistent Threat (APT: 高度で持続的な脅威)

定義： 高度で持続的な脅威。国家支援または組織的な犯罪グループが、数ヶ月～数年にわたって対象ネットワークに潜入し、情報窃取や破壊を行う攻撃

APTの4つの特性：

      高  度  な  (Advanced)
      ↓
    複雑なマルウェア、ゼロデイ悪用
    高度な偵察・エスケープ
    多段階の攻撃チェーン

      継  続  的  (Persistent)
      ↓
    数ヶ月～数年の潜入期間
    バックドア複数配置
    検出回避策の常時改良

      標  的  型  (Targeted)
      ↓
    特定の組織・個人を狙う
    事前調査の徹底
    カスタマイズされた攻撃

      脅  威  (Threat)
      ↓
    悪意ある意図
    実行能力
    攻撃機会

APT攻撃のライフサイクル

有名なAPTグループと攻撃

ゼロデイ (Zero-Day) 脆弱性と攻撃

定義： 開発者が知らない、または知っているが未修正のセキュリティ脆弱性。公開されていないため、防御策が存在しない。

用語の区別：

ゼロデイ脆弱性 = 未発見/未公開の脆弱性
ゼロデイexploit = それを悪用するコード
ゼロデイ攻撃 = 脆弱性を実際に悪用する行為

    脆弱性発見 → (公開前) → 攻撃開始
    ← 0日(ゼロデイ)→

    脆弱性公開 → パッチ公開 → 脆弱性修正
    ← ゼロデイ期間 →

ゼロデイ攻撃の脅威

従来のセキュリティ対策が機能しない

シグネチャベース検出：✗
  → 既知のパターンをベース
  → ゼロデイは未知なので検出不可

パッチ適用：✗
  → パッチが存在しない
  → 修正は攻撃後に来る

既知の脆弱性対策：✗
  → ゼロデイは既知ではない

ゼロデイ の悪用フロー

実例：SolarWindsサプライチェーン攻撃

2020年、SolarWinds Orionプラットフォーム侵害

流れ：
1. APT29がSolarWindsのビルドシステムに侵入
2. バージョン2020.2.1に悪意あるコード挿入
3. 約18,000のSolarWinds顧客が自動更新で感染
4. 米国政府機関、Fortune 500企業が侵害対象
5. 9ヶ月以上検出されず

被害者：
・Microsoft, Intel, Cisco, Malwarebytes
・米国財務省、商務省
・FBI, NSA, CIA等の政府機関も侵害か

根本原因：
・供給チェーン経由の侵害
・ソフトウェア更新プロセスの信頼を悪用
・複数のゼロデイ脆弱性を使用

ゼロデイ防御戦略

ゼロデイ対策の実装例：

// ゼロデイ対策：異常検知ベースの監視

class AnomalyDetector {
  constructor() {
    this.userBaselines = new Map();  // 通常の動作パターン
    this.threshold = 0.8;             // 異常スコアの閾値
  }

  // ユーザーの通常動作をプロファイリング
  buildUserBaseline(userId, activityLog) {
    const patterns = {
      accessTimes: this.extractAccessTimes(activityLog),
      dataAccess: this.extractDataAccessPatterns(activityLog),
      locations: this.extractLocations(activityLog),
      devices: this.extractDevices(activityLog)
    };
    this.userBaselines.set(userId, patterns);
  }

  // リアルタイムで異常を検知
  detectAnomaly(userId, currentActivity) {
    const baseline = this.userBaselines.get(userId);

    const anomalyScore = this.calculateAnomalyScore(
      baseline,
      currentActivity
    );

    // 異常スコアが高い場合
    if (anomalyScore > this.threshold) {
      this.logSecurityEvent({
        type: 'POTENTIAL_ZERO_DAY_ACTIVITY',
        userId: userId,
        anomalyScore: anomalyScore,
        activity: currentActivity,
        recommendation: 'INVESTIGATE'
      });

      // 即座にアラート発行
      this.triggerAlert(userId, anomalyScore);

      // 追加認証を要求
      return { allowed: false, requireMFA: true };
    }

    return { allowed: true };
  }

  calculateAnomalyScore(baseline, current) {
    // 複数の特徴から異常スコアを計算
    // (時間帯、データアクセスパターン、地域、デバイス等)

    let score = 0;

    // 時間帯の異常
    if (!baseline.accessTimes.includes(current.time)) {
      score += 0.3;
    }

    // データアクセスパターンの異常
    if (current.dataAccess > baseline.dataAccess * 5) {
      score += 0.4;  // 異常な量のデータアクセス
    }

    // 地域の異常(不可能な移動速度)
    if (this.isImpossibleLocationChange(baseline, current)) {
      score += 0.5;  // 数秒で別大陸への移動は物理的に不可能
    }

    return Math.min(score, 1.0);
  }

  isImpossibleLocationChange(baseline, current) {
    const lastLocation = baseline.lastLocation;
    const distance = this.calculateDistance(
      lastLocation.lat,
      lastLocation.lon,
      current.lat,
      current.lon
    );

    const timeDiff = (current.time - baseline.lastAccessTime) / 1000; // 秒
    const maxSpeed = 900; // m/s (Mach 3, 実現不可)
    const maxDistance = maxSpeed * timeDiff;

    return distance > maxDistance;
  }

  // ... その他のメソッド
}

// 使用例
const detector = new AnomalyDetector();

// ユーザーの通常動作をプロファイリング
detector.buildUserBaseline('user123', historicalActivityLog);

// ログイン要求時に検査
app.post('/login', (req, res) => {
  const currentActivity = {
    time: new Date().getHours(),
    location: req.geoip,
    device: req.headers['user-agent'],
    dataAccess: getExpectedDataAccess(req.user.role)
  };

  const result = detector.detectAnomaly('user123', currentActivity);

  if (result.requireMFA) {
    // MFAを要求
    res.json({ requireMFA: true });
  } else {
    // ログイン成功
    res.json({ success: true, token: generateToken(user) });
  }
});

Webセキュリティとの接続

• Webアプリの代表的脆弱性 XSS、CSRF、SQLインジェクション、SSRF、CORS、CSP
• 認証と認可の実装論 MFA、JWT、OAuth 2.0 / OIDC、セッション管理、Cookie属性
• ブラウザとHTTPの防御設定 HSTS、X-Frame-Options、Referrer-Policy、Permissions-Policy
• 開発と診断の実践 OWASP Top 10、OWASP ASVS、OWASP WSTG、実装チェックリスト

詳しくは 15 Webセキュリティ を参照してください。

インシデント対応

インシデント対応計画(IRP)

定義： セキュリティ侵害や脅威が発生した際の組織的な対応手順

インシデント対応の5段階(図解)

インシデント対応テンプレート

以下のテンプレートに出てくる IOC は Indicator of Compromise の略で、侵害の痕跡を示す情報です。たとえば不審なハッシュ値、悪性ドメイン、攻撃者のIPアドレス、C2 通信先などが該当します。

初動で見るログソース

初動では「全部のログ」を均等に見るより、侵害の入口と横展開の痕跡が出やすい場所から見る方が効率的です。

優先度が高いログ

• Webサーバーアクセスログ Web攻撃、異常なUser-Agent、大量リクエスト
• 認証ログ ブルートフォース、不自然な時間帯のログイン、権限昇格
• ファイアウォール / VPNログ 不審な接続元、遠隔接続の異常
• DNSログ マルウェア通信、長すぎるクエリ、外向きの不自然な名前解決
• EDR / エンドポイントログ 不審プロセス、PowerShell、資格情報窃取、永続化

次に見るログ

• アプリケーションエラーログ
• データベースログ
• バッチやスケジューラの実行ログ

ログは「保存されている」だけでは足りません。時刻同期、改ざん耐性、集約先、保持期間まで含めて設計しておくと、事後調査の精度が大きく変わります。

セキュリティベストプラクティス

現在のセキュリティ重要戦略

1. ゼロトラスト セキュリティ

原則： すべてのアクセスを信頼できないものと仮定し、常に認証・認可・監視を実施

ゼロトラスト セキュリティアーキテクチャ(図解)

ゼロトラストの基本原則

ゼロトラストは「VPNをやめること」ではなく、アクセス判断の軸を変える考え方です。要点は次の4つです。

• 明示的に検証する 誰か、どの端末か、どの状況かを毎回確認する
• 最小権限を適用する いま必要な範囲だけ許可する
• 侵害を前提に考える すでに内部へ入られている可能性を前提に設計する
• 継続的に評価する 一度のログイン成功で永続的に信頼しない

NIST SP 800-207 でも、ネットワークの場所だけで信頼せず、アイデンティティ、デバイス状態、ポリシー、リスク文脈を組み合わせて判断する考え方が中心です。

導入時に見るべき観点

ゼロトラストは、一気に完成させるものではありません。現実には次のような順で強くしていくことが多いです。

1. アイデンティティの強化 MFA、SSO、権限レビュー、特権ID管理
2. デバイス状態の確認 パッチ適用、EDR、証明書、準拠状態
3. アクセス経路の見直し VPN前提の広い信頼を減らし、アプリ単位・条件単位で制御
4. 継続的な監視と応答 ログ、異常検知、ITDR、セッション再評価

よくある誤解

• ZTNA 製品を入れれば終わりではない
• MFAだけでゼロトラストになるわけではない
• ネットワーク制御だけで完結するわけでもない

ゼロトラストは製品名ではなく、アイデンティティ、デバイス、アプリ、データ、監視を通した設計原則です。

2. AIを活用した脅威検知

3. サプライチェーン セキュリティ

4. クラウド セキュリティ

5. インシデント対応の自動化

従来：手動による時間がかかるプロセス

現代：
自動化された対応フロー

例：ランサムウェア検知時
1. EDRが疑わしいファイル動作を検知(自動)
2. システムを隔離(自動)
3. 管理者にアラート(通知)
4. インシデント対応チーム起動(手動→管理画面で管理)
5. 分析開始(半自動)

時間削減：
手動の場合：担当者の確認待ちや切り分けで長引きやすい
自動化：検知から初動隔離までを大幅に短縮しやすい

JWT (JSON Web Token) とその脆弱性

JWT は、ヘッダー・ペイロード・署名を点で区切った形式で、ステートレス認証に広く使われています。構造は header.payload.signature です。

よくある実装エラー：

1. 署名検証の省略 — 署名を検証しないと、トークンの改ざんが可能
2. 既知の秘密鍵 — デフォルト値や推測可能な鍵を使うと攻撃者に破られやすい
3. アルゴリズム切り替え攻撃 — ヘッダーで alg: "none" に変更すると署名を削除できる

防止方法：

• 署名アルゴリズムを明示的に指定し、none を拒否する
• 署名検証を必ず実装する（RFC 7519）
• トークンに有効期限(exp)を設ける
• 秘密鍵を安全に管理し、定期的にローテーションする
• kid（Key ID）を使って鍵バージョンを管理する

実装例（Node.js）：

const jwt = require('jsonwebtoken');

// トークン生成時
const token = jwt.sign({ userId: 123, role: 'user' }, secret, { 
  algorithm: 'HS256',  // 明示的に指定
  expiresIn: '1h',     // 有効期限を設ける
  issuer: 'app.example.com'  // issuerで発行者を検証可能に
});

// 検証時
const decoded = jwt.verify(token, secret, { 
  algorithms: ['HS256'],  // 許可するアルゴリズムをホワイトリスト
  issuer: 'app.example.com'  // issuerを検証
});

参考： PortSwigger “JWT attacks”、RFC 7519

XSS (Cross-Site Scripting) の完全な分類

XSS は、<script> タグなどを使い、JavaScriptコードを被害者のブラウザで実行させる攻撃です。

3つの主要な型：

具体的な防止パターン：

1. 入力検証 — 許可リストアプローチで明示的に許可する形式を定義

// 安全でない（すべての入力を受け取る）
element.innerHTML = userInput;

// 安全（テキストとして扱う）
element.textContent = userInput;

// または明示的にエスケープ
element.innerHTML = DOMPurify.sanitize(userInput, { ALLOWED_TAGS: [] });

2. Content Security Policy (CSP) — RFC 7762相当で script-src を制限

Content-Security-Policy: default-src 'self'; script-src 'self'

3. HTTPOnly クッキー — JavaScriptからアクセス不可にする

参考： PortSwigger “XSS” チュートリアル、OWASP Top 10 A03:2021

CSRF (Cross-Site Request Forgery) と SameSite Cookie

CSRF は、被害者のブラウザに認証済みのリクエストを強制的に送らせる攻撃です。

攻撃フロー：

1. 被害者が bank.com にログイン（セッションクッキー取得）
2. 攻撃者の evil.com にアクセス
3. evil.com が被害者のブラウザに bank.com/transfer?amount=1000&to=attacker を送出
4. ブラウザが自動的にクッキーを送信し、リクエストが実行される

防止方法：

1. CSRF トークン — フォーム送信時にサーバー生成の一意トークンが必須

<form method="POST" action="/transfer">
  <input type="hidden" name="csrf_token" value="abc123xyz789">
  <input type="text" name="amount">
</form>

2. SameSite Cookie — 属性で Strict または Lax を設定

Set-Cookie: session=xyz; SameSite=Strict; Secure; HttpOnly

• Strict: クロスサイトリクエストでは一切クッキーを送信しない
• Lax: トップレベル遷移(リンククリック)のみ許可

3. Referer チェック — 本来のドメインからのリクエストか確認

参考： RFC 6265-bis (SameSite)、PortSwigger CSRF チュートリアル

SQL Injection の変種と防止

SQL Injection は、ユーザー入力が SQL クエリに直接埋め込まれたとき、攻撃者が任意の SQL を実行できる脆弱性です。

典型的な脆弱性コード：

# 危険：入力をそのまま結合
query = "SELECT * FROM users WHERE username='" + username + "'"
result = db.execute(query)

# 攻撃例：username = "admin' --"
# 実行されるクエリ：SELECT * FROM users WHERE username='admin' --'

安全な実装：

# 推奨：プリペアドステートメント（パラメータ化クエリ）
query = "SELECT * FROM users WHERE username = ?"
result = db.execute(query, (username,))

主要な変種：

防止チェックリスト：

• [ ] すべての入力フィールドでプリペアドステートメントを使用
• [ ] ORM フレームワーク（SQLAlchemy, Hibernate等）の安全な機能を利用
• [ ] エラーメッセージに詳細情報を含めない（一般的なメッセージのみ）
• [ ] 最小権限の原則で DB ユーザーを制限（特定テーブルのみアクセス可）
• [ ] WAF（Web Application Firewall）で既知パターンをブロック

参考： OWASP Top 10 A03:2021、PortSwigger “SQL Injection”、CWE-89

セキュリティフレームワーク

NIST Cybersecurity Framework (CSF) 2.0

概要： 米国国立標準技術研究所(NIST)が策定したセキュリティリスク管理フレームワーク。2024年公開のCSF 2.0では、従来の重要インフラ中心の文脈から、規模や業種を問わず使える枠組みへ広がり、Govern が新しい中核機能として明示されました。

CSF 2.0は、具体的な製品や手順を強制するものではありません。組織がサイバーセキュリティ活動を理解し、優先順位をつけ、関係者へ説明するための共通語彙として使います。実装では、CSFをCIS Controls、NIST SP 800-53、OWASP ASVS、MITRE ATT&CKなどの具体的な管理策や攻撃知識へ接続します。

フレームワークの6つの関数：

1. ガバナンス (Govern)

目的： 全社的なセキュリティ戦略・方針・プロセスを確立

実装項目：

• セキュリティポリシーとリスク管理フレームワークの策定
• 責任と権限の明確化
• ステークホルダーとのコミュニケーション
• 規制要件の把握と対応
• セキュリティ文化の構築

ガバナンス例：
- CEO(Chief Executive Officer)はCISO(Chief Information Security Officer: 最高情報セキュリティ責任者)に月次報告
- リスク委員会が四半期ごとにセキュリティ予算を決定
- 全従業員がセキュリティトレーニング受講(年2回以上)

2. 特定 (Identify)

目的： 資産、業務、依存関係、リスクを把握し、防御対象を明確にする

実装項目：

• 資産・システムの棚卸
• 脅威の特定
• 脆弱性の評価
• ビジネス影響度の分析
• リスクスコアの算出

3. 保護 (Protect)

目的： リスクを低減するためのセキュリティ対策を実装

実装項目：

• アクセス制御(RBAC、MFA)
• 暗号化(転送中・保存中)
• ネットワークセグメンテーション
• エンドポイント保護
• データバックアップ

4. 検知 (Detect)

目的： セキュリティインシデントを早期に発見

実装項目：

• ログ収集・分析(SIEM: Security Information and Event Management)
• 脅威インテリジェンス連携
• EDR(Endpoint Detection and Response: エンドポイント検知・対応)
• ネットワーク監視
• 異常検知(AI駆動)

検知の効果測定：
- 平均検知時間(MTTD: Mean Time To Detect)：短いほど良い
- 組織成熟度が高いほど短縮しやすい
- 比較するときは同じ定義・同じ計測条件で見る

5. 対応 (Respond)

目的： インシデント発生後の封じ込め、連絡、分析、改善を実施

実装項目：

• インシデント対応計画(IRP: Incident Response Plan)
• 対応チームの編成と訓練
• 通信・報告体制
• 封じ込めと根絶
• 事後分析(RCA: Root Cause Analysis)

6. 復旧 (Recover)

目的： 業務を安全に再開し、再発防止を反映した状態へ戻す

実装項目：

• 復旧手順の確立
• バックアップからの復元
• 再発防止策の反映
• 利害関係者への復旧連絡

CSFとZero Trustを改善バックログに落とす

NIST CSFは、セキュリティ活動を Govern、Identify、Protect、Detect、Respond、Recover に分けて、現在地と目標状態を整理するための地図です。一方、Zero Trustは、アクセス判断を「社内ネットワークにいるから信頼する」から「利用者、端末、アプリ、データ、リスクを毎回評価する」へ移す設計原則です。両者は競合せず、CSFで全体を棚卸し、Zero Trustでアクセス制御と監視を具体化する関係として使えます。

改善バックログに落とすときは、抽象的な「セキュリティを強化する」ではなく、運用で確認できる単位へ分解します。

CISAのZero Trust Maturity Modelは、従来型から最適化された状態までを段階として見るための材料になります。すべてを一度に移行するより、重要データや管理機能など、影響が大きい経路から「明示的な検証」「最小権限」「継続監視」を適用していく方が現実的です。

CIS Controls v8.1

概要： Center for Internet Security (CIS) が策定した、優先度付きの実践的セキュリティコントロール集です。

3つの実装レベル：

CIS Controlsの18個のコアコントロール(概要)：

実装ロードマップ例(小規模組織)：

ここでいう IG1 IG2 IG3 は、CIS Controlsが示す実装グループです。小さい組織はまず IG1 の基本対策から始め、運用が回るようになってから IG2 以降へ広げる考え方です。

Month 1-2   : コントロール1,2,5,6,9,10,11,17(基本)
Month 3-4   : コントロール3(監視開始)
Month 5-6   : コントロール8,9(スキャン・更新自動化)
Month 7-12  : 高度なコントロール(IG2へ向かう)

MITRE ATT&CKフレームワーク詳細

概要： 実際のサイバー攻撃に基づいて、攻撃者が使用するタクティクスとテクニックを分類したナレッジベース。脅威モデリング、検知ルール開発、防御戦略の策定に活用。

13のタクティクスと主要テクニック：

1. Reconnaissance(偵察)

目的： 標的システムに関する情報を収集

主要テクニック：

• Active Scanning — ポートスキャン(nmap等)
• Gather Victim Identity Information — 従業員情報の収集(LinkedIn等)
• Gather Victim Org Information — 組織情報の収集
• Phishing for Information — フィッシング経由での情報収集
• Search Open Websites/Domains — DNSレコード、WHOIS等の公開情報収集

防御：

• 公開情報の最小化
• ファイアウォール設定でスキャン検知
• ソーシャルメディア監視

2. Resource Development(リソース開発)

目的： 攻撃インフラを構築

主要テクニック：

• Acquire Infrastructure — 攻撃用の サーバー・ドメイン取得
• Develop Capabilities — マルウェア開発
• Establish Accounts — 踏み台となるアカウント作成
• Obtain Capabilities — 攻撃ツール取得

防御：

• ドメイン登録監視
• DNS Sinkhole(悪質ドメインへの通信を安全な宛先へ誘導して観測・遮断する仕組み)

3. Initial Access(初期侵入)

目的： 対象ネットワークへの足がかり確保

主要テクニック：

• Phishing — メール経由のマルウェア配付(最多)
• Supply Chain Compromise — 開発元や配布経路を汚染して侵入する手法
• Exploit Public-Facing Application — 公開Webアプリの脆弱性利用
• Valid Accounts — 盗んだ認証情報を使用

侵入経路の傾向:

• Phishing: 人の判断に依存するため、訓練やメール防御の影響を受けやすい
• Web Exploit: 公開面の脆弱性管理やパッチ適用状況に左右される
• USB/Physical: 物理的な接触条件や運用統制の有無に左右される

防御：

• フィッシング訓練(定期実施)
• メールフィルタリング(SPF/DKIM/DMARC)
• WAF(Web Application Firewall)
• 脆弱性スキャン・パッチ管理

4. Execution(実行)

目的： マルウェア・コマンド実行

主要テクニック：

• User Execution — ユーザーに実行させる
• Command and Scripting Interpreter — PowerShell、bash等での実行
• Exploitation for Client Execution — クライアント側脆弱性利用

防御：

• AppLocker(許可したプログラムだけ実行させるWindowsの実行制御)
• PowerShell Logging(スクリプト実行ログ記録)
• User Access Control(UAC: User Account Control)

5. Persistence(永続化)

目的： システムへのアクセスを長期維持

主要テクニック：

• Create Account — バックドアアカウント作成
• Boot or Logon Autostart Execution — スタートアップ登録
• Scheduled Task/Job — タスクスケジューラに登録
• Web Shell — Webサーバー上に置く遠隔操作用スクリプト
• Registry Run Keys — Windows起動時に自動実行されるレジストリ設定

防御：

• 定期的なアカウント監査
• 重要システムの監視
• ファイル整合性監視(FIM: File Integrity Monitoring)

6. Privilege Escalation(権限昇格)

目的： 限定的な権限を管理者権限に昇格

主要テクニック：

• Exploitation for Privilege Escalation — 脆弱性利用
• UAC Bypass — ユーザーアクセス制御回避
• Token Impersonation — 他ユーザーの認証トークンを借りて成り代わる手法

防御：

• OSパッチ管理(優先度：高)
• 最小権限の実装
• 特権アクセス管理(PAM: Privileged Access Management)

7. Defense Evasion(防御回避)

目的： 検知・対応を回避

主要テクニック：

• Modify Registry — レジストリ改変
• Clear Logs — ログ削除
• Disable or Modify Tools — セキュリティツール無効化
• Obfuscated Files or Information — マルウェア難読化
• Living off the Land — OS標準ツールを悪用して不審な実行ファイルを減らす手法

防御：

• ログの不変性確保(リモート記録)
• EDR(Endpoint Detection and Response: エンドポイント検知・対応)
• File Integrity Monitoring

8. Credential Access(認証情報窃取)

目的： ユーザー認証情報を盗用

主要テクニック：

• Brute Force — ブルートフォース攻撃
• Credential Stuffing — 流出パスワードの再利用
• Keylogging — キーロガー
• Input Capture — フォーム盗聴
• OS Credential Dumping — メモリから認証情報を抜き出す手法(mimikatz等)

防御：

• MFA(Multi-Factor Authentication: 多要素認証)
• パスワード管理ツール
• EDR(異常なアクセス検知)
• Have I Been Pwned監視

9. Discovery(探索)

目的： ネットワーク・システム構成を把握

主要テクニック：

• Network Share Discovery — 共有フォルダ検索
• Account Discovery — ユーザーアカウント列挙
• Software Discovery — インストール済みソフト確認
• System Information Discovery — OS・ハードウェア確認

防御：

• ネットワークセグメンテーション
• アクセス制御(RBAC)
• ネットワークトラフィック監視

10. Lateral Movement(横方向移動)

目的： ネットワーク内を横に移動し、他システムに侵入

主要テクニック：

• Remote Services — RDP、SSH等を悪用
• Windows Admin Shares — 管理者共有フォルダ利用
• SMB/Windows Admin Shares — ネットワーク共有利用

防御：

• ネットワークセグメンテーション
• MFA(リモートアクセス)
• 異常なネットワーク通信検知

11. Collection(情報収集)

目的： 機密情報を収集

主要テクニック：

• Email Collection — メール盗聴
• Screen Capture — スクリーンショット
• Clipboard Data — クリップボード内容盗聴
• Data from Cloud Storage — クラウドストレージからのデータ窃取

防御：

• DLP(Data Loss Prevention: データ損失防止)
• 機密情報の分類・ラベリング
• クラウドアクセス制御

12. Command and Control(通信・制御)

目的： 侵害されたシステムをコントロール

主要テクニック：

• Web Service — HTTP/HTTPS通信
• DNS — DNS通信
• Application Layer Protocol — メール、IRC等

防御：

• ファイアウォール(出口制御重要)
• DNSフィルタリング
• ネットワークトラフィック分析

13. Exfiltration(データ流出)& Impact(影響)

目的： 盗んだデータを流出、またはシステムに被害を与える

主要テクニック(Exfiltration):

• Data Compressed — 圧縮してからアップロード
• Data Obfuscation — 難読化
• Exfiltration Over C2 Channel — C2経由での流出
• Scheduled Transfer — スケジュール実行で徐々に流出

主要テクニック(Impact):

• Data Destruction — ランサムウェア、データ削除
• Resource Hijacking — 侵害した計算資源を暗号資産マイニングなどに勝手に使う行為
• Service Stop — サービス停止

防御：

• DLP(Data Loss Prevention: データ損失防止)
• ネットワーク出口監視(Egress Filtering: 外向き通信を制限・監視する対策)
• バックアップ(復旧用)

MITRE ATT&CK活用方法：

実装チェックリスト

組織全体のセキュリティチェックリスト

ガバナンス・リスク管理

• [ ] セキュリティポリシーが文書化され、全社に周知
• [ ] リスク評価が定期的(年1回以上)に実施
• [ ] セキュリティ委員会が設置され、定期的に開催
• [ ] セキュリティインシデント対応計画が策定・テスト
• [ ] 規制要件(GDPR: General Data Protection Regulation、個人情報保護法等)が把握され、遵守
• [ ] サードパーティセキュリティ評価が実施

アクセス制御

• [ ] 最小権限の原則が実装
• [ ] ロールベースアクセス制御(RBAC)を使用
• [ ] 定期的なアクセスレビュー実施(年1回以上)
• [ ] 離職者のアクセス即座に削除
• [ ] 特権ユーザーはPAM(Privileged Access Management: 特権アクセス管理)下
• [ ] MFAが すべての管理アクセスに必須

認証・認可

• [ ] パスワード要件が強力(最小12文字、複雑性)
• [ ] パスワード履歴管理で再利用を防止
• [ ] パスワード有効期限が設定(又は無期限だが変更強制)
• [ ] MFAが すべてのユーザーに導入
• [ ] 認証情報の安全な保管(bcrypt, argon2等)

暗号化

• [ ] 転送中のデータはHTTPS/TLSで暗号化(全通信)
• [ ] 保存データが暗号化(機密データ)
• [ ] 暗号化キーが安全に管理・保管
• [ ] 前方秘匿性(PFS: Perfect Forward Secrecy)が実装
• [ ] TLS 1.2以上のみを使用(TLS 1.0/1.1は無効化)

脅威検知・監視

• [ ] SIEM(Security Information and Event Management)が導入・設定
• [ ] ログが中央で集約・保存
• [ ] リアルタイムアラート設定
• [ ] 定期的なログ分析と監査
• [ ] インシデント検知の平均時間が測定
• [ ] EDR(Endpoint Detection and Response)がエンドポイント配置
• [ ] 異常検知が実装

インシデント対応

• [ ] 対応計画が文書化・テスト済み
• [ ] 対応チーム24/7体制で待機可能
• [ ] 対応時間目標(RTO: Recovery Time Objective)が定義
• [ ] ホットラインと連絡体制が確立
• [ ] 定期的な訓練・シミュレーション実施
• [ ] ポストモーテムプロセスが確立

脆弱性管理

• [ ] 脆弱性スキャンが定期実施(週1回以上)
• [ ] 脆弱性評価が実施(年1回以上)
• [ ] パッチ管理プロセスが確立
• [ ] Criticalパッチは24-48時間以内に適用
• [ ] 依存関係の脆弱性も追跡(SCA: Software Composition Analysis)
• [ ] ペネトレーションテストが定期実施(年1回以上)

ユーザー教育・意識向上

• [ ] 全従業員がセキュリティ意識向上トレーニング受講
• [ ] 定期的なフィッシング訓練実施
• [ ] セキュリティニュースレター配信
• [ ] 新規入社時のセキュリティ研修
• [ ] 事件報告を奨励する文化醸成

データ保護

• [ ] データ分類が実施(公開、内部限定、機密等)
• [ ] 機密データへのアクセスが記録
• [ ] DLP(Data Loss Prevention: データ損失防止)が導入
• [ ] 定期的なバックアップ
• [ ] バックアップのテスト復旧が定期実施
• [ ] データ保有期間ポリシーが確立

セキュアな開発

• [ ] Secure SDLC(Secure Software Development Life Cycle)プロセスが確立
• [ ] コードレビューがセキュリティを含む
• [ ] 静的セキュリティテスト(SAST: Static Application Security Testing)が実施
• [ ] 動的セキュリティテスト(DAST: Dynamic Application Security Testing)が実施
• [ ] 依存関係が定期的にスキャン
• [ ] セキュアコーディング標準が文書化

物理・デバイスセキュリティ

• [ ] オフィス アクセス制御が実装
• [ ] デバイス暗号化が標準化
• [ ] USB等外部デバイス使用ポリシーが確立
• [ ] デバイス紛失時の対応手順が確立
• [ ] デバイスのリモートワイプ能力あり

zero-trust)

• CISA Zero Trust Maturity Model
• CIS Critical Security Controls
• MITRE ATT&CK
• OWASP Cheat Sheet Series

まとめ

サイバーセキュリティは、単発の対策を増やすことではなく、攻撃の流れに沿って防御・検知・対応・復旧を配置する営みです。認証、Web防御、マルウェア対策、ネットワーク防御、インシデント対応、フレームワークを横断して見ることで、個々の対策がどこで効くのかを整理しやすくなります。

参考文献

公式・標準

• ISO 27001 Information Security Management
• NIST Cybersecurity Framework 2.0
• NIST Post-Quantum Cryptography
• NIST SP 800-207 Zero Trust Architecture
• NIST Cybersecurity Framework 2.0
• NIST CSF 2.0 Publication
• NIST SP 800-53 Rev. 5
• NIST SP 800-63 Digital Identity Guidelines
• NIST SP 800-63-4: Digital Identity Guidelines
• NIST SP 800-63B-4: Authentication and Authenticator Management
• RFC 5280: X.509 PKI
• RFC 6234: US Secure Hash and HMAC
• RFC 8446: TLS 1.3
• RFC 9700: Best Current Practice for OAuth 2.0 Security
• MITRE ATT&CK
• OWASP Authentication Cheat Sheet
• OWASP Authorization Cheat Sheet
• OWASP Cheat Sheet Series
• OWASP Cryptographic Storage Cheat Sheet
• OWASP Top 10
• OWASP Top 10
• OWASP Web Security Testing Guide
• CISA Zero Trust
• Let’s Encrypt Documentation
• OASIS SAML 2.0
• OpenID Connect Core 1.0
• CIS Critical Security Controls
• CISA Zero Trust Maturity Model

書籍

• The Crypto Handbook

解説・補助

• Passkeys.dev