マルウェア配布サイトやフィッシングサイトなど既知の悪意あるFQDNへの接続を阻止するシステム

実行場所の違い XSS→Webブラウザ(Client) CSRF→Webアプリサーバ(Server)

電子政府推奨/推奨候補/運用監視...暗号リスト

ARPテーブルを確認するコマンド エージェントが夜間に「arpコマンド」の実行を確認したら、当該PCをネットワークから隔離する。 ※マルウェアはarpコマンドで割り出したIPアドレスにpingで起動を確認

コネクター、エージェント、認証基盤（IAM）連携

HMAC認証 事前に受信者と送信者が双方で「共通鍵」を保有 入力データに「共通鍵」を含めてハッシュ値を計算

最近では、無線LANやSSL/TLS通信などのセキュリティプロトコルにおいて、 ストリーム暗号よりも主流 。 暗号化とデータ認証を同時に →データの機密性と完全性を同時確保

無線LANが盗聴されるリスクを低下できる

IAP

知識　所有物　生体認証

SSOの認証情報さえあれば、あらゆるユーザーやエンティティーがVPNにログオン。ラテラルムーブメントでよってネットワーク内を自由に移動し、データ漏洩

①第三者への証明 ②否認防止 送受信者共にMAC値の生成ができるから。 送信者が「そんなもの送ってない」と言えば否認可能 →ディジタル署名(電子証明書がある)で対応可能

メッセージ認証では「共通鍵暗号方式」や「ハッシュ関数」を使ってチェック用データを作ります。 デジタル署名では「公開鍵暗号方式」を使ってチェック用データを作ります。 理屈や考え方は似ているけど、実際のやり方が違う

Brand Indicators for Message Identification DMARCと呼ばれる認証が成功したメールに対し企業ロゴを付与し信頼性を高める技術

定期的な更新とパッチ適用

ペネトレーションテスト リスク↓ C&Cサーバへの通信可否などのマルウェア感染 ・一般ユーザから管理者権限への権限昇格 ・推測されやすいパスワードやパスワードハッシュ

STRIDEモデル ペネトレーションテスト(実現しうるシナリオをもとにリスクを評価,MITRE ATT&CK) 脆弱性診断(OWASP top10 に関連）

DoH(DNS over HTTPS)

ASCIIコード Shift_JIS

ZTNA。ソフトウェア定義の境界(SDP)上で動作

「攻撃者が真正なサーバがもつ真正な公開鍵を事前に入手しておき、その値から計算したフィンガプリントを送りつけてしまう」 「ホスト認証」。 真正な公開鍵と対をなす秘密鍵を、このサーバは本当に持つか？をチャレンジレスポンスで検証する方法です。

CSIRT

セキュリティチップ Trusted Platform Module（TPM）、 自己暗号化ドライブ Self Encrypting Drive（SED）、 高信頼ネットワークTrusted Network Communications（TNC）

①IAPでアプリにアクセスするのはコネクターであり、ユーザーは社内のリソースに直接アクセスできない。 ②IAPはアプリアクセスのたび、認証/認可。 ③IAPコネクターはFWの内側で運用可能 (コネクターは内→社外の通信（ポート 80/443）のみできればよい。FWの穴開け不要！！ IAPコネクターからインターネット上のIAPに通信を開始するため

バックアップデータを復元する手順を追加する

WEBサーバの証明書のCAのデジタル署名がブラウザの持つルート署名と一致しない

Due care 遵守すべき要件を過失なく満たしている Due diligence 正当な注意義務及び努力

前方秘匿性

①DNSSECでリクエストをデジタル署名で確認 ②キャッシュサーバとコンテンツサーバの分離。インターネットから問い合わせできないようにする。

リソースレコードに対するデジタル署名

ポイズニングは、DNSの仕様によって有効期限内のキャッシュが 存在する間は再帰問合せできない！

GET メソッド→外部に送信するRefererに秘密情報が含まれる CSRF（クロスサイト・リクエスト・フォージェリ） 「hidden パラメータ」に秘密情報を出力

DNSKEY

DNS-Based Authentication of Named Entities MTA-STS強化 STARTTLS　必須 TLS1.0以上、できれば1.2以上 DNSSECが検証できなければ配送しない 公開鍵　必須

ウイルス検出方法 ①パターンマッチング方式　定義ファイル ②ヒューリスティックスキャン方式　プログラムの動き →動的ヒューリスティックスキャン方式　(ビヘイビア法)　サンドボックス

GDPR General Data Protection Regulation

P346 プロセスハロウィング

ハッシュ関数とブロック暗号

①中間者（MITM）攻撃で平文ダウングレードさせられる ②送信サーバーの身元を認証する方法がない。 SMTPメールサーバーは証明書を検証しないから。

送信者のTXTレコードの「IPアドレス」が， 送信元✉のIPアドレス(「MAIL FROMコマンド」のアドレス（＝エンベロープFrom）) と一致するか？ ▽SPFレコード 『IN TXT "v=spf1 +ip4：58.13.7.83( IPアドレス )　-all』 💬どうぞ見に来て頂戴～エンベロープFROMと一緒でしょ?

①送りたいファイルを、１回限りの乱数によるセッション鍵で暗号化 ②①で用いたセッション鍵を、送り先相手の公開鍵で暗号化 ③暗号化ファイルとセッション鍵の両方を送信 なお、通信時、通信そのものの暗号化は行わない。 ④ファイルの送り先にて、自身の秘密鍵で、１回限りのセッション鍵を復号 ⑤④で得た１回限りのセッション鍵で、ファイルの中身を復号

X.509

TCPコネクションの確認 コマンド

ログイン時に送られるデータを攻撃者が記録し、それをそのまま再現することで不正にログインする ノンスと呼ばれるランダムな値を用いてメッセージと一緒にMAC値を生成

「我々にメールを送るときには必ず有効な証明書とともにTLSで送ってください、そうじゃない場合は受け取りません！」 STARTTLSの弱点である「MTA同士でお互いTLSを使えたら使う（使えない場合は平文でOK）」を強化 SMTPクライアントがサーバの身元を確認 →TLSハンドシェイクでサーバーに証明書要求

「number used once」の略で、「一度だけ使われる数」

①SMTPにアクセスするユーザー認証 ②サーバはCAのデジタル署名を持ち、クライアントの証明書の妥当性を確認する

検査・隔離・治療 ①DHCP方式→手動IP設定はDHCPスプーで対策 ②認証スイッチ方式

2n、複数の人に同じ公開鍵を渡しても問題ない

OCSP （online certificate status/CRL（Certificate Revocation List OCSPの方がリアルタイム性が高いが、OCSPレスポンダが必要。仕組みが整っていない場合が多い。

本社ネットワーク管理者へVPN接続に用いるIDを一時停止するように連絡する

存在証明 日時に確かにデータが存在していた事の証明 完全性証明 日時以降そのデータが改ざんされていない事の証明

＝郵便配達(中間サーバ)では復号、解読されない 逆)TLS ：ブラウザとウェブページ間の通信を暗号化し、メッセージは中間サーバーで復号化 →サーバーを管理するサービスプロバイダーはメッセージの内容を読むことができる！！

CRYPTREC

💛Ping監視💛(死活監視) ICMP、装置のアップダウン エコー要求/応答 👕 🩵SNMP監視🩵👕　(状態監視) CPU/メモリ使用率、障害発生 「 コミュニティ」 コミュニティごとにMIBへのアクセス権限を分ける UDPの161（ポーリング）番、162（Trap）番

ユニバーサルプラグアンドプレイ（UPnP）

Endpoint Protection Platform　エンドポイント保護 エンドポイント監視、脅威の検知、対処 ネットワーク全体を監視、脅威の検知、対処 IT機器から大量ログを収集、相関関係をもとに分析 SIEMの拡張、インシデント対応プロセスの自動対処 /総合分析、自動対処

iptables

n(n－1)/2

・Spoofing Identity なりすまし ・Tampering with data 改ざん ・Repudiation 否認 ・Information disclosure 情報漏洩 ・Denial of service サービス妨害 ・Elevation of privilege

サーバ証明書を発行する過程で、発行依頼元のSNSがもつCAAレコードを確認

ソースポートランダマイゼーション/DNSSEC

①URLにセッションIDを埋め込む ②スクリプトを使用し、セッションIDを強制(クロスサイトスクリプティング) ③HTTPヘッダインジェクション 攻撃者がSet-Cookieヘッダを挿入することで利用者にCookieを強制