SC：試験 - 午後 - パターン＆プラクティス のバックアップ(No.10)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• SC：試験 - 午後 - パターン＆プラクティス へ行く。
  • 1 (2020-10-11 (日) 01:36:06)
  • 2 (2020-10-11 (日) 02:44:45)
  • 3 (2020-10-11 (日) 15:32:27)
  • 4 (2020-10-12 (月) 13:28:53)
  • 5 (2020-10-12 (月) 16:39:52)
  • 6 (2020-10-12 (月) 22:00:29)
  • 7 (2020-10-13 (火) 02:31:10)
  • 8 (2020-10-13 (火) 13:19:15)
  • 9 (2020-10-14 (水) 21:36:47)
  • 10 (2020-10-18 (日) 00:19:20)

---

「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る

目次 †

概要 †

ポケスタのスペシャル・テクニック「等」を参考に、

• 専門的＆
  • 補足的な知識を補う。
  • 応用的（？）な知識を補う。

• 大分類的カテゴライズを行う。

専門基礎力系 †

経路系 †

「そんな経路もあったなぁ。」みたいな。

URL †

• 直リン
  （そのまんま系でもある）
  • 問題
    • 画面１にチェック処理を実装
    • 画面２のURLを含むフィッシング

• 回答
  • 画面２の直リンなので、画面１のチェック処理は機能しない。
  • 何が別のギミックが...と考え込んだら負けなパターン。

電子メール †

電子メールには以下のような経路がある。

• エンベロープ
  • エンベロープFromは、メール・ヘッダのヘッダFromよりは信用が置ける。
  • エンベロープのFromやToは、検索機能でも利用できるらしい。

• 外部・内部メール・サーバー
  • 外部メール・サーバー（DMZ上）と
  • 内部メール・サーバー（イントラ上）がある。

• メーリング・リストを使用した経路
  • メーリング・リストの仕様
  • ...

• 投稿フォームを使用した経路
  （オープン・リダイレクター的な）
  • Fromが運営になるので安心感がある。
  • スパム・メールやフィッシング・メールなどを送信。

• その他

• フィッシング・メールのURLによる経路
  • SMTP/POPで入って
  • HTTPで出る

• マルウェア＋C&Cの経路
  • マルウェアの感染経路
  • マルウェアとC&Cの通信経路

VDI †

• クラウドのリージョン的なモノの選択
• ネットワーク遅延によるレスポンス悪化

感染 †

• 同一LAN上で感染するケース。
  （そのまんま系でもある）
  • LAN間のファイル転送に転送用PCのLAN切替方式を用いるのがNGな理由。
  • LAN-Aに対策なしに接続して感染し、その状態でLAN-Bに接続して拡散する。

• NW系の分離によって対応できる。
  • 脆弱性攻撃型マルウェア系
  • ファイルバラ撒き型マルウェア系

漏洩 †

• 社外持ち出しPC
  • リスク：社外持ち出しPCからのデータの持ち出し
  • 手段：社外持ち出しPCを、社外に持ち出してインターネット接続し持ち出し。

分離系 †

• 分離とは、感染・漏洩の経路の分離と言える。

• NW系が中心だが、サンドボックスなども分離。

物理的分離 †

USBメモリに仕込んだマルウェア系等が攻撃経路になる。

VDI-LANによる分離 †

OA-LAN → VDI-LAN → System-LAN

• 持ち出しのリスク軽減する。
  • VDI-LANを経由させることに依る効果。
  • 在宅用のVDIなんかも、コレっちゃコレ。
  • 基本的にVDI端末に業務データを保存できない。
    （プロダクトや問題によっては保存可能
    なので防止ではなく軽減と言う事もある）

• 一方、マルウェア系等の問題は、
  VDI-LANを入れても変わらない。

SANによる分離 †

• LANとSANでプロトコルが違う。

• 例えば、共有ディスクを
  • SAN（iSCSI）で実現するか？
  • LAN（FCoE、SMB3.0）で実現するか？

• SANで接続すれば、LAN分離に該当する。
• 脆弱性攻撃型マルウェア系に対する対策になる。

• レプリケーション方向

• X-LANのボリュームからY-LANのボリュームにレプリケーション

• この場合（X → Y）、
  • Y-LANはX-LANから分離されていない状態だが、
  • X-LANはY-LANから分離されている状態になる。

• ファイルバラ撒き型マルウェア系に対する対策になる。

運用管理LAN（セグメント） †

利用者LANと分離することで、
利用者PCのマルウェア系感染による攻撃を防ぐ。

キッティングLAN（セグメント） †

• （そのまんま系でもある）
• （文中にある）以下のネットワーク・アクセスに制限
  • 脆弱性修正プログラムのDLサイト
  • ウィルス定義のDLサイト
  • マルウェア系X駆除ツールのDLサイト

開発LANによる分離 †

• 開発LANを導入する。
• 開発PCは様々なツールをDLして利用するので
  • OA-LANよりウィルスに感染し易い。
  • また、セキュリティ・ポリシが緩い事がある。

可変のIPアドレス †

分離中では、例外的にデメリットが多い。

• 可変のIPアドレスには、以下のような手段がある。
  • DHCPによって可変に。
  • DNS等の名前解決によって可変に。
    ※ 後者は、攻撃の手段としても利用される。

• IPアドレスが可変だと、
  • 送信元が解らなくなる。
  • IPアドレスによる認証ができなくなる。
  • フィルタリングできなくなる。

集約系 †

集約のデメリット †

• 集約して起きる問題
  • 特定困難化
  • 被害拡大
  • 更に対応後の問題も。

• 暗号系

• 特定困難化
  ...

• 被害拡大
  共有鍵を分割しない場合、
  漏洩・危殆化時の被害が拡大。

• 経路系

• 特定困難化
  プロキシに集約する場合、
  送信元が解らなくなる。

• 被害拡大
  • 物理的分離しない
  • VDI-LANによる分離しない
  • SANによる分離
  • 運用管理LAN（セグメント）
  • キッティングLAN（セグメント）
  • 開発LANによる分離

• 認証系

• 特定困難化
  • 共有されたアカウント
    ・サーバー信頼モデルのアカウント
    ・, etc.

• IPアドレスによる認証
  ・プロキシに集約。
  ・, etc.

• 被害拡大
  「なりすまし」に依る。
  • SSO
  • ミラー・アカウント
  • 共有されたアカウント

• マルウェアの被害拡大
  • LAN経由
  • ファイル・システム経由
  • Webストレージ経由
  • メーリング・リスト経由
    メール・フィルタ機能の対象にならず拡散する。

集約のメリット †

集約で解決できる問題

• ログ解析
  プロキシ・サーバー、FW、NAPTなどのログを参照すると良い。

• リモート・アクセス
  • 前提
    • イントラはプロキシ・サーバーを導入してある。
    • リモート・アクセスには、VPNを利用できる。
    • リモート端末 → VPN → イントラ → プロキシ → インターネット
  • 問：リモート端末からのインターネットアクセスは？
  • 答：VPN（→ イントラ → プロキシ）経由でアクセスする。

• 外部・内部メール・サーバー
  • 外部メール・サーバー ⇔ 内部メール・サーバー ⇔ イントラPC
  • 故に、ウィルス・スキャンは内部で行うと良い。
    （イントラ・メールでのマルウェア拡散を防止するため）。

権限系 †

サンドボックス †

最小権限の原則 †

• 最小権限の原則 - Wikipedia
  https://ja.wikipedia.org/wiki/%E6%9C%80%E5%B0%8F%E6%A8%A9%E9%99%90%E3%81%AE%E5%8E%9F%E5%89%87

職務分離の原則 †

• セグリゲーション - Wikipedia
  https://ja.wikipedia.org/wiki/%E3%82%BB%E3%82%B0%E3%83%AA%E3%82%B2%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3

暗号系 †

鍵の数 †

• 共有鍵
• 公開鍵

ストリーム暗号・ブロック暗号 †

• ストリーム暗号
• ブロック暗号

秘密鍵、公開鍵、ハイブリッド †

• 秘密鍵
• 公開鍵
• ハイブリッド

署名・検証 †

• 基本的に
  • 秘密鍵で署名し、
  • 公開鍵で検証する。
  • （逆パターンは公開鍵暗号化）

• X.509
  • クライアント、サーバーの識別名を秘密鍵で署名する。
  • クライアント、サーバーの識別名を公開鍵で検証する。

• コード署名
  • コードに出処を付与し秘密鍵で署名する。
  • コードの出処を公開鍵で検証する。

• 電子文書の長期保存
  

• タイムスタンプ（＋署名）により、以下を確認できる。
  • その時点での存在。
  • 改ざんされていないこと。
  • SAではなくTSAが登場する（保証する第三者機関）。

• アーカイブ・タイムスタンプ
  • 暗号の危殆化に対応
  • 有効期間内に危殆化していないことを確認。
  • 危殆化していない＝改ざんされない暗号化強度がある。
  • アーカイブする物件
    公開鍵証明書関連の情報をアーカイブする。
    ・公開鍵証明書
    ・公開鍵証明書のチェーン
    ・収集した公開鍵証明書の失効情報

通信系 †

プロトコル上の脆弱性と、暗号化通信。

TCP/UDP †

特にUDPはパケット詐称され易い。

DNS †

• 以下のような脆弱性がある。

• UDPを使うのでポイズニング対策が必要
  UDPのレスポンスとしてタイミングとポートを合わせてパケットをブチ込む。

• その他、
  • ゾーン転送系
  • 踏み台系（オープン・リゾルバ）

• 以下が効果的

• 分割配置
  • 機能の分割
    ・コンテンツ・サーバー（リゾルバ）
    ・キャッシュ・サーバー（キャッシュ）

• キャッシュ・サーバー設定
  ・ポイズニングの対象でもある。
  ・内部からのアクセスに限定する。
  ・若しくは、外部からの再起クエリを受け付けないように設定する。

• ポイズニング対策で、
  ブチ込めないようにする。
  • 送信元ポートのランダム化（元々ランダムでは？）
  • TxIDの推測を困難にする（問い合わせに16bitのTxIDを付与）。

• DNSSECの導入
  • 署名された応答。
  • 検証して正規の応答か確認できる。

電子メール †

HTTP †

• 部分の名称
  • リクエスト
    • ヘッダ
    • ボディ
  • レスポンス
    • ヘッダ
    • ボディ

• リクエスト行 / ステータス行

• リクエスト行
  • GET
  • POST
  • HEAD
  • PUT
  • DELETE
  • CONNECT

• ステータス行
  • 200 OK
  • 301 Moved Permanently
  • 302 Found
  • 304 Not Modified
  • 307 Temporary Redirect
  • 308 Permanent Redirect
  • 400 Bad Request
  • 401 Unauthorized
  • 403 Forbidden
  • 404 Not Found
  • 500 Internal Server Error
  • 503 Service Unavailable

• セキュリティ強化のHTTPヘッダ
  • X-XSS-Protection
  • X-Frame-Options
  • Content-Security-Policy
  • Strict-Transport-Security (HSTS)

HTTPS †

• 共通
  • サーバー認証とクライアント認証
  • 暗号化通信に依る暗号化の自動化

• X.509の
  • サーバー認証：サーバー証明書を利用する。
  • クライアント認証：クライアント証明書を利用する。

• CONNECTメソッド

   CONNECT www.example.com:443 HTTP/1.1

  • トンネリングでHTTPSのプロキシ経由
  • 初回のみL7、以降L4でプロキシする。
  • 詳しくはコチラを参照。

• HTTPS化（リダイレクト、HSTS）

SSH †

• 共通
  • サーバー認証とクライアント認証
  • 暗号化通信に依る暗号化の自動化

• サーバー認証
  • サーバー証明書ではなくサーバの秘密鍵（ホスト鍵）。
  • HTTPS的に、暗号化通信で使用される。

• クライアント認証
  • パスワード認証方式
    Linuxユーザー・アカウントでログイン
  • 公開鍵認証方式
    クライアントの秘密鍵→サーバに公開鍵を登録。

無線LAN †

• APのスキャン
  • 問：IEEE 802.11b/g（2.4 GHz）で
    　　スキャンしたが規格的に検査できないもの。
  • 答：IEEE 802.11a or 5G Hz帯と答える。

認証系 †

ログイン試行系 †

• パスワード・クラック中のオフライン攻撃
  • レインボー・テーブル

• パスワード・クラック中のオンライン攻撃
  • パスワード・リスト
  • ブルート・フォース
  • 逆ブルート・フォース
    （リバース・ブルートフォース）

IdP仕様 †

• ログイン試行系に関連し

• レインボー・テーブル対応
  ソルト、ストレッチング

• ブルート・フォース攻撃対策
  同一ユーザIDの単位時間中のログイン試行失敗ｘ回で
  → 一定時間アカウント・ロックなど。

• 逆ブルート・フォース攻撃、パスワード・リスト攻撃対策
  同一IPアドレスからの単位時間中のログイン試行失敗ｘ回で
  → 一定時間IPアドレスを遮断など。

• 多数のIPアドレスからのパスワード・リスト攻撃対策
  単位時間中のログイン試行失敗ｘ回で
  → Webサイトをロックダウンなど。

• LoAのIAL系
  • システム上で承認を行う。
  • 本人に直接、申請の事実を確認する。
  • , etc.

共通鍵→公開鍵 †

よりセキュアに（SSHなど）。

X.509 †

• サーバー証明書（サーバー認証）
  • クロスルート証明書
  • 復号機能を持つプロキシの証明書

• クライアント証明書（クライアント認証）

X.500 †

GDSとDS間で信頼関係を結ぶ
（ADのドメイン、フォレスト信頼関係的な）。

SPNEGO †

The [S]imple and [P]rotected GSS-API [Nego]tiation Mechanism (IETF RFC 2478)

• NTLMやKerberosのネゴシエーションを行うプロトコル。
• 設定は、PC側（DesktopとBrowser）と認証サーバー側に必要（ADと同じ）

認証・認可 †

• OAuth2の例
  • IdPでの認証
  • scopeの認可とか。

• 認証カードの例
  • 認証カードの認証
  • システム登録された権限の認可とか。

SAML2 †

OAuth2/OIDC †

• 認証・認可

• Resource Serverのキー
  • Tokenは認証ではなく認可
  • 故に、Transaction Dataは、Tokenのsubと関連付ける。
  • コレにより、Tx Data を Resource Ownerに紐付ける。

認証カード †

• 貸与の防止
  • 前提：入館だけでなく、退館でも認証カードを用いるようにする。
  • 問：これが、認証カードの貸与の防止に効果的である理由は？
  • 答：退館時にも必要になると、置き忘れや定位置保管が無くなる。

二要素認証 †

認証カードも、2要素目（have）であることが多いかな。

テスト系 †

（セキュア・コーディング系を含む）

類似不良 †

• 脆弱性にQA的な発想を加える。
• 不具合原因から類似不具合が潜在している可能性があるのでテスト。

デグレード †

• 脆弱性にQA的な発想を加える。
• 修正・対策で新たな脆弱性が発生している可能性があるのでテスト。

レース・コンディション †

「マルチスレッド環境下でテストする。」

だと思ったが、

「デバッガを使用して、並列実行する。」
（意図的に、高確率で、競合を起こさせる）

みたいな回答だった。

※ デバッガはパラで動かんだろ...とか思いながら。

WAF、IPS、IDS †

• パッチ適用との比較
  • WAF、IPS、IDSによる対策はパッチ適用による対策と比べたら、対応が早い。
  • これは、WAF、IPS、IDSの方がパッチに比べテスト項目が少なくて済むため。

• 検知と遮断
  • 検知後、遮断の前に、一定期間猶予を与える。
  • すると、誤遮断によるビジネス機会損失を軽減できる。

• ポリシのテスト
  • 攻撃の通信を遮断する（見逃しをテスト）。
  • 正常な通信を通過させる（誤検知をテスト）。

• 用語
  • 見逃し：フォールス・ネガティブ
  • 誤検知：フォールス・ポジティブ

※ 誤検知はポジティブ

Public Client系 †

root権限 †

Android OSに対し責任を負う携帯メーカーの手により、
端末出荷時点ではrootを含む特権ユーザの存在は隠されている。

サンドボックス †

• Android アプリのサンドボックス
  アプリを跨いだResourceアクセスは禁止されている。
  （root化されたケースでも、不正なアクセスを防ぐことが出来る）
  • システムとアプリの分離
  • 使用を許可されたシステムコール
  • ファイル システムの raw データのビュー

※ ファイル共有に関してはガイドラインが存在する。
※ .NETにはCASというモノが在ったが、今は無い。

JavaScript無効化 †

• 脆弱性が判明したら対策として利用されることもあるが、
• チェックのスキップ等で、攻撃に利用されることもある。
• 対策としては、サーバ・サイドでのチェック処理を追加する。

マルウェア系 †

初動 †

検出、駆除、NWから切断
（未検出のマルウェアが居る可能性があるため）

C&C †

マルウェアとC&Cとの通信について

• DNSで名前解決することがある。

• その場合、FQDNに対応するIPアドレスが可変になる。

• 故にIPではなくURLフィルタをC&Cの通信ログから行う。

• User-Agent（UA）ヘッダ
  • C&Cの通信はUAヘッダ等の情報から調査する。
  • 逆にC&Cは、マルウェアのUAヘッダ以外を無視（≒404）することもある。

MITM †

• 暗号化通信（HTTPS、SSH）に対して行われる。

• サーバー証明書（ホスト鍵）を盗むと、MITMがより容易になる。
  • これは、中継（中間）ポイントがサーバー認証されてしまうため。
  • SSHで、組み込み機器でホスト鍵が同じというケースがあるらしい。

• サーバー証明書検証に不備があると、MITMが可能になる。

• MITMのMiddle部分

• 無線LANのAP
  以下の設定を公共APと同じにしておく。
  ※　ココの問題と同じ（と言うか、そのもの）。
  • SSID
  • 共通鍵

• Browserの場合はMITB
  • M = Browser
  • 送信の改ざんと受信の改ざんがある。

ランサムウェア †

ファイルレス †

• マルウェアのファイルがない
  • 正規のプログラムの脆弱性を悪用する。
  • C&Cから得た攻撃内容を正規のプログラムで実行

• ビヘイビアで検出する。

ウィルス検出 †

• ビヘイビア系

• ≒ ダイナミック・ヒューリスティック

• ビヘイビア検出
  User and Entity Behavior Analytics (UEBA)
• ビヘイビアの例
  問題のコンテキストに沿って回答。
  • レジストリ書き換え
  • ファイルを標準のフォルダ外に配置

フィルタリング系 †

分離した経路をフィルタリングみたいな。

電子メール †

• 経路については
  • コチラを確認。
  • 応用についてはコチラを確認。

• ホワイト・リストとブラック・リスト（IPアドレス）。

• 社内メアドがエンベロープFormのメールが外部メール・サーバー（DMZ上）に届く話。

• 社内ドメインを外部メール・サーバーのブラック・リストに追加する。

• 配信処理にSaaSを使用している場合は、
  社内ドメインを外部メール・サーバーのホワイト・リストに追加する。

• ブラック・リスト、ホワイト・リストのフィルタリング設定

• フィッシング・メールのフィルタ
  プロキシのURLのブラック・リストを一致させると、
  フィッシング・メール等をフィルタできる。

ファイアウォール †

• HTTPアウトバウンド
  設定をプロキシ経由のみ許可に設定（一般的にそうする）。

プロキシ †

• 機能
  • フィルタリング
    • URL
      ・ブラック・リスト
      　フィッシング・サイトや、
      　マルウェアとC&Cの通信の遮断。
      ・ホワイト・リスト
      　ブラック・リストより優先度が高く、
      　ブラック・リスト条件に適合するモノの内、
      　許可するモノをホワイト・リストに追加する。
      ・フィルタ・オプション

• カテゴリ単位フィルタリング
  ・許可
  ・検知
  ・遮断
  ※ 詳しくは下記の運用を参照。

• プロキシ認証
  マルウェアとC&Cの通信の遮断に有効。

• HTTPSの扱い
  ・L7で復号化する（ヘッダやボディも復号化される）
  ・L4で複合化しない（トンネリングでは、FQDNまでで、パスは見えない）

• 運用
  
  • 判断の付き難いカテゴリを検知に変更
  • 検知の状態で一ヶ月間、運用＆ウォッチ。
  • 判断して、設定変更を行う。
    • 業務に必要なURLを許可
    • 問題のあるカテゴリを遮断

• 証明書

• 復号化機能を持つプロキシの証明書

• 復号化しない単純なトンネリングでは不要

WAF、IPS、IDS †

• テスト系の話し
• WAF、IDS（NIDS・HIDS）・IPS（NIPS・HIPS）

TCP Wrapper †

• TCP Wrapperとは、
  • Unix系OS上のTCP/IPのフィルタリング・プログラム
  • 全サービスのリスナをtcpd経由（アクセス制限）で動作させる。
  • クライアントのIPアドレス、ホスト名でアクセス許可が設定可能。
  • 実行中にACLの再構成が可能でワーム対策スクリプトが使い易くなる。

• 回答は、
  クライアントのIPアドレス、ホスト名等でアクセス許可を設定する。

CAPTCHA †

• 何気に本Wikiに未登場。

• 当たり前だが、認証ではない。

• 以下のようなシーンで活用できる。

• フォールス・ポジティブ対策

• ボットと人間を見分け、
  ボットの得意な攻撃を回避する。

• DoS
• アカウント生成
• ログイン試行

SaaS系 †

• SaaS系をフロントに配置すると、そこでフィルタリングできる。
  • CDN
  • ファイアウォール
  • プロキシ
  • WAF、IPS、IDS

• 切替（SaaS ⇔ オンプレ）。
  • DNSのAレコード差替で対応可能
  • SaaSのフロント ⇔ オンプレのフロント。

• 送信用メール・サーバーを使用すると、
  • 外部メール・サーバーのホワイト・リストへの追加が必要になる。
  • 通常は、「なりすまし」としてブラック・リストに登録されている。

フィルタリング設定 †

• 正規表現、文字列照合
  • 正規表現
  • 文字列照合（完全一致 / 部分一致 / 前方一致 / 後方一致）
  • 問題としては、C&C系が多い。

• ブラック・リスト、ホワイト・リスト

• ホワイト・リストは、ブラック・リストより優先される。

• ブラック・リスト
  送信元のIPアドレスが変更されるとフィルタされなくなることがある。

• ホワイト・リスト
  送信元のIPアドレスが変更されるとフィルタされることがある。

可変のIPアドレス †

（フィルタリング不可）のような問題が発生し得る。

• ホワイト・リストやブラック・リストが機能しなくなることがある（電子メールの例）。

• 認証を行うケースでは、認証の機能要件を満たせなくなる事がある

• 認証済みIPに他のユーザが割り当てられる（POP before SMTPなど）。

• PC共有では、ログオフ的なことをシないと（と言う逆パターン）。

セキュア・コーディング系 †

レース・コンディション †

バッファ・オーバーフロー †

• データ実行防止機能（DEP）
• コンパイラに依る対策
  • SSP（Stack Smashing Protection）
  • ASLR（Address Space Layout Randomization）
  • PIE（Position Independent Executable）
  • AF（Automatic Fortification）

ヒープ・オーバーフロー †

ヒープ・マネージャの仕様によるが、
アドレスのランダム化によって攻撃が成功し難くなっている。

※ なお、BOF系の攻撃への対策は、効果無し。

整数オーバーフロー †

• 整数オーバーフローからのバッファ・オーバーフロー
• 確保した領域のサイズも正しいものではないため。
• 確保するサイズの検証処理を追加して回避する。
  • kMaxInteger? / fhBuff.rows < byteOfRow?
  • kMaxInteger? < byteOfRow? * fhBuff.rows

JavaScript関連 †

• CSRF(XSRF)
  • POSTを使ったり、
  • POST中の乱数を検証したり。

• XSS（クロスサイトスクリプティング）
  スクリプト・インジェクション
  • JSで情報を抽出し、別サイトに送付。
  • 主に、Cookie（認証、Session）を盗む。
  • これにより、Sessionハイジャックを行う。

• XSSの型

• 反射型
  データ入力で、input要素にインジェクションする。

• 格納型
  データ出力で、input要素にインジェクションする。

• DOMベース
  ・DOMに書き出す部分でインジェクションする。
  ・代表的な例は、FragmentをDOMに書き出す場合など。
  ・「JavaScript:」JavaScriptスキームによるXSS攻撃への対応のように、
  　要求がサーバーに飛ばず、攻撃の検出ができないことがある。

• Cookie（XSSに関連）

• 属性

• HttpOnly?
  JavaScriptからの操作不可

• Secure
  HTTPSでのみ利用可能

• Access-Control-Allow-Credentials (CROS)

  Access-Control-Allow-Credentials: true

• Sessionハイジャック
  • 通常、XSSによる。
  • 逆パターンで、自分のSession Cookieを、
    フィッシング的に送り込みXSSする方法もある。

• セッション・フィクセーション（セッションID固定化攻撃）
  • 指定のSessionIDでSessionを開始させる。
  • 対策
    ・ログイン後は新規SessionIDを採番する。
    ・SessionIDを指定できないようにする
    　（GETはNG。POSTやCookieを使用する）。

• JSON関連
  JSON (JavaScript Object Notation)

• eval()
  eval インジェクションが可能。

• JSON.parse()
  evalの代替（文字列のJavaScript Object化）

• JSON.stringify()
  JavaScript Objectの文字列化

• Origin

• Same-Origin（SameSite?）
  • Understanding "same-site" and "same-origin"
    https://web.dev/same-site-same-origin/

• Cross-Origin
  • CORS (Cross-Origin Resource Sharing)

• HTTPヘッダ・インジェクション
  • URLエンコ文字列中に改行文字を入れておく。
  • このURLを使用してリダイレクトする際に、
    URL中の改行で、以降の文字列がHTTPヘッダ・HTTPボディ化する。

• 以下のような攻撃が可能になる。
  • フィッシングサイト等へリダイレクト
  • 任意の Cookie が生成（Sessionハイジャック系）
  • 任意の HTTP レスポンスボディが生成（不正なJSの実行）

• 対策
  • URLエンコ文字列中の
    改行文字を削除するか、
    改行以降の文字列を削除する。
  • 対策済みAPIを使用する。

インジェクション系 †

JavaScript系を除く。

• SQLインジェクション
  • 認証回避
    • 問：どうやって？
    • 答：WHERE句が真になるようにインジェクションとか。
      https://blog.tokumaru.org/2013/06/sql-injection-golf-3-letters-bypass-login-authentication.html

• OSコマンド・インジェクション

• ディレクトリ・トラバーサル
  基本的には以下がエラーにならないことを利用し、
  相対パスではなく、ルートから検索する。

• Linux
  

  ../../../../../ ...

• Windows

  ..\..\..\..\..\ ...

• インジェクション・ベクタ
  • インジェクションのペイロード中の攻撃を行う部分。
  • WAF、IPS、IDSは、インジェクション・ベクタを検知・破棄する。

• DLLインジェクション
  少々、毛色が違うが。

情シス・マター系 †

VDI系 †

• VDIの方式
  • 今日日は、ほぼ、VDI型の画面転送方式
  • VDI端末と仮想PCから構成される。

• VDIの経路

• VDI-LANによる分離

BCM、BCP系 †

近年、出題は、下火らしい。

• 物理媒体でのデータ保管
  • 支店等にデータ転送 → DVD作成＆保管
  • DVD作成 → 業者によって遠隔地保管
  • , etc.

• Webストレージ

• Webストレージの障害時の対応計画
  • オンプレのFSにデータを同期しておく。
  • 同期したデータを使用して業務を再開する。

• Webストレージのサービス終了時の対応計画
  • 代替サービスの選定
  • データ移行手順の調査

・捻りの無い、そのまんま。だから？
・若しくは、ITIL ≒ SMの範囲だから？

ISMS系 †

• 規格
  • ISMS 規格についての概要と基本用語集
    （ISO/IEC 27000:2013、JIS Q 27000:2014）
  • 組織のISMSを認証するための要求事項
    （ISO/IEC 27001:2013、JIS Q 27001:2014）
  • 組織でISMS（管理策）を実践するための規範
    （ISO/IEC 27002:2013、JIS Q 27002:2014）
    
  • その他、色々。
    （ISO/IEC 2700X:201X）

• 監査部署と管理部署は分ける。
  • 客観的な監査を行うため。
  • システム監査人の独立性と客観性の保持

JIS Q 27002 †

組織でISMSを実践するための規範

• 運用管理要件

• Webサーバー
  • 前提
    Webサーバーのリスクは、推測可能なアカウント
    各種脆弱性（アプリ、基盤、認証・認可）
    リスクNoで辿ると、基盤のセキュリティ・ホールとある。
    

• 問：Webサーバーの運用管理要件は？
• 答：セキュリティ・ホールがあったらパッチを適用する。

• 運用端末

• 使用しないソフトウェア
  ・問：マルウェアに感染しないよう「」を禁止することにした。
  ・答：「使用しないソフトウェア」（「許可されていない」...は実質、禁止しか）
  　　　元ネタは、「JIS Q 27002:2014 12.6.1」

• セキュリティ・ホール
  ・問：セキュリティ・ホールの情報が公開された後の対応
  ・答：影響を調査し、必要に応じてパッチを適用する。
  　　　元ネタは、「JIS Q 27002:2014 12.6.2」

• アカウント管理

• 離席する場合、
  • 問：どうする？
  • 答：（ロックする、ではなく、）操作禁止状態にする。
    　　元ネタは、「JIS Q 27002:2014 11.2.9」

• 使用するパスワードは
  • 問：どうする？
  • 答：（強度を高くする、ではなく、）他人が推測できないものにする。
    　　元ネタは、「JIS Q 27002:2014 9.3.1」

• パスワードの運用は
  • 問：どうする？
  • 答：（ローリングする、ではなく、）他人に知られないようにする。
    　　元ネタは、「JIS Q 27002:2014 9.3.1」

フォレンジック †

• 分野
  • デジタル・フォレンジック
  • コンピュータ・フォレンジック

• ポイント

• 以下と関連している。
  • 付加的特性の真正性、責任追跡性、否認防止
  • 対策機能の予防の抑止・抑制効果

• 証跡を消さないように保全するのは触らないのが一番

• ウィルススキャンやOS再起動でメモリ情報が消えてしまう。

• ウィルススキャンの検疫機能（隔離・削除）の使い分け。
  ・検疫隔離なら良いが、検疫削除で証跡が消える可能性がある。
  ・ただ、某社運用を見ていると、ウィルススキャン駆動にはなっている。
  　（いきなり、ネットワーク隔離の保全とか言う話にはならない）

• OS再起動で改ざんコンテンツ・ファイルが戻るようなマルウェア。

攻撃（物理） †

物理的攻撃は、結構、想定外。

• 災害、障害、人的

• 人的な脅威
  • フット・プリンティング

• ソーシャル・エンジニアリング
  • 構内侵入
  • トラッシング
  • ショルダー・ハッキング
  • なりすましによる聞き出し

• 電子メールでよく来る
  • フィッシング系
  • 標的型攻撃

• 機器に対する物理攻撃
  デジタル的ではなく物理的にアクセスする場合、
  機密情報が秘匿されていないことも多い。

• 対象
  ・携帯電話、スマホ
  　・IMEI番号
  　・アプリのシークレット
  ・Wi-FiのAP、Wi-Fiルータ
  　・各種鍵の情報
  　・, etc.
  ・IoT機器、産業機械
  　・各種鍵の情報
  　・, etc.

• 方法
  ・ログインしてファイル・システムから。
  ・リバース・エンジニアリングによって。
  ・その他にも、ストレージから直接とか色々ありそう。

運用ノウハウ †

• 標準ソフトウェア
  • 問：使用しなくなったソフトウェアが発生。
  • 答：標準ソフトウェアの「見直し」を行う。
    　　元ネタは、「システム管理基準 6. ソフトウェア管理」

• パッチ適用
  • 影響範囲を確認し、
  • テスト面でテストし正常動作を確認。

※ 風が吹けば桶屋が儲かる系

• 退職後のアカウント削除
  • 前提：
    • 人事部が退職届受理
    • 運用管理者は退職者の退職日の定時後にアカウント削除

• 問：運用管理者はなんの後、退職者のアカウント削除をするか？
• 答：（退職届受理後、ではなく、）退職者の退職日の定時後

• ハンドリング

• トリアージ
  医療で使われる用語たが、一般的に、対応の
  • 重要度＋優先度付
  • →対応の要否（選別決定）

• IRTと部門間の連携
  • 部門が収集している脆弱性情報の提供を受ける。
  • （工数の発生を最小限に抑えることができる。）

• 復旧時の問題

• バックアップ・リストアの問題

• バックアップ（に）も
  ・マルウェアが潜んでいる。
  ・既に改ざんされている。

• リストア時の問題
  以下が最新でない状態に戻る。
  ・パッチ
  ・ウィルス定義

• モバイル・デバイスの紛失

• VPNアカウントの停止
  • 問：どの様な問題が発生するか？
  • 答：PCからのアクセスも出来なくなる。
    　　（→ 共有されたアカウント）

• BYODのMDM
  • 問：BYODの端末データ消去を行うための前提は？
  • 答：事前に同意をとっておく必要がある。
    　　（BYODなので個人データも削除されることになる）

その他 †

情シス的に常識。

• リスクの分析

• 問：どうやって設定するか？
  　　→リスクレベル３の条件

• 答：マトリックスから、
  　　重要な情報を持っている（漏洩する）
  　　＆社外からのアクセス（侵入）可能

• 不正競争防止法 - 営業秘密
  • 秘密性　：秘密として管理されていること。
  • 有用性　：技術上又は営業上の有用な情報であること。
  • 非公知性：公然と知られていないこと。

その他 †

メーリング・リスト †

受信者の自アドレスをヘッダに含まないケースがある。

• 送信時、Fromは自アドレス、ToはMLアドレス
• 受信時、Fromは送信元アドレス、ToはMLアドレス（自アドレスを含まない）

専門応用力系 †

経路系 †

プロキシ経由 †

• フィルタリング設定
  • 問：マルウェア系がC&Cサーバーと通信できない理由は？
  • 答：ファイアウォールを、その様に設定しているから！

• プロキシ上での攻撃
  Webサーバーの通信内容をプロキシ経由で攻撃社のサイトに送信。

• 問：
  攻撃社のサイトと通信できるのは、
  どの様な"OSコマンド"が使える場合か？

• 答：
  OSコマンドで攻撃者のコンピュータと通信できる場合。

電子メール系 †

• ヘッダ / エンベロープ From

• エンベロープ Fromで、オープン・リレーの軽減が可能
  • ただし、エンベロープ Fromは、Return-Path含め、詐称可能。
  • 「オープン・リレー」（第三者中継）と記述させる問題がぼちぼち多い。

• ただし、ウィルス・スキャンで問題が検知された場合の通知等は、
  ヘッダ / エンベロープ To と言うケースもある（スパムの踏み台になる）。
  

• エンベロープFromは、SPFで利用される
  （SPFは「送信元ドメイン認証技術」と記述させる問題があった）

• ブラック・リスト登録には、ヘッダFromが利用される。
  
  • エンベロープFrom（送信元SMTPサーバ）は、SPFで使用する。
  • ブラック・リスト登録には、送信元アドレスである送信元アドレスを使用する。

• 外部・内部メール・サーバー応用

• 外部・内部メール・サーバーの間にフィルタリング機能がある。

• 外部メール・サーバーからのSMTPは、
  ロードバランサ経由でメールのフィルタリング装置に転送する。

• 電子メールのフィルタリング装置の障害時の転送機能による経路
  • 外部メール・サーバー → フィルタリング装置 → 内部メール・サーバー
  • 外部メール・サーバー → 内部メール・サーバー

• 外部メール・サーバーが、内部メール・サーバーの名前解決を行うため、
  • 外部メール・サーバーのDNSとして設定しておく。
  • そして、外部メール・サーバー → DNSの再帰クエリを許可しておく必要がある。
  • 通常は、外部からの再帰クエリは許可しない（反復クエリは許可）。

• 内部メール・サーバーの名前解決
  
  • 外部DNSをDNSフォワーダに設定していなければ、
    　内部のみの名前解決で、内部メール専用になる。
  • マルウェアも、名前解決自体ができないのでC&Cと通信できない。

• フィッシング・メールのURL文字列置換処理が不完全
  • 不完全なURL文字列置換処理

    str = str.replaceAll("(?i)https?://", "");

  • 以下のケースで対策になっていない（[]はガイド）。

     htt[https://]ps://

企業内でのWebストレージ利用 †

先ず、一般的な、Webストレージがあり、
ファイルを暗号化ソフトで暗号化してデータ交換するようにしている。
ここに、マルウェア拡散防止用の同期FSストレージを追加する話。

• 前提：Webストレージのファイル更新時、ウィルススキャンし、問題があったら、
  　　Webストレージと同期FSストレージの両方からファイルを削除する。

• 問：マルウェア検出時の追加機能の内容
• 答：マルウェア検出時の電子メール通知機能

• 前提：暗号化でファイルサイズは変化しない。
  • 問：秘匿されない情報は？
  • 答：ファイル名、ファイル・サイズ。
    　　（ファイル名は文脈から判断）

• 前提：更新されるとバックアップされる。
  　　同期FSは、平文保存されたファイルの通知を行う。
  • （１）
    • 問：平文ファイルが保存され続けるケース
    • 答：同期FSではなくWebインターフェイスから平文ファイルを保存した場合。
  • （２）
    • 問：同期FSに追加するべき機能。
    • 答：（既出の通知に加え）平文ファイルのバックアップを削除する機能。

画面遷移 †

ログインされていない時は画面A-Gは
ログイン画面にリダイレクトされる。

• 問：画面Dの内容の窃取に成功する条件は？
• 答：ログインされている場合。

サーブレット・コンテナ管理画面 †

（言うたら、IISマネージャーみたいなものでは？）

• 問：アクセス元をローカルループバックアドレスに限定する理由
• 答：インターネットからの管理画面に対する不正アクセスを防止する。

分離系 †

開発LAN分離の問題 †

• 前提
  • 利用者セグメント、開発クライアント・セグメント、開発サーバー・セグメントがある。
  • 開発クライアント・セグメントから開発サーバー・セグメントへ通信が必要。
  • 開発サーバーと開発クライアントのセグメントを開発サーバー・セグメントに片寄する。
  • 実質的に「開発サーバー・セグメント → 開発セグメント」となる。

• 問：ルータに追加すべきルールは？
• 答：利用者セグメントから開発セグメントへの通信をフィルタリングするルール。

集約系 †

秘密鍵の生成・保持の仕様上の問題 †

• 前提：Webストレージの秘密鍵が、
  　　サーバー毎に生成・保持される場合。

• 問：仕様上の問題点を挙げよ。

• 答：
  • サーバー毎に秘密鍵を生成
  • サーバー上で秘密鍵を管理

• 補足説明：
  • 漏洩時、サーバーの全データが復号可能になる。
  • Webストレージの運営会社が複合化できる。

権限系 †

アカウントの無効化 †

管理者の権限がマルウェアなどに乗っ取られると危険
この場合は、管理者のアカウントの無効化などを行う。

暗号系 †

ストリーム暗号・ブロック暗号 †

• ブロック暗号では、
  • 平文が、同じ暗号文になるので、平文を予測し易い。
    （暗号文一致攻撃、暗号文改ざん攻撃に弱い）
  • そのため通常は、秘匿用の利用モードを使用する。

証明書 †

• 証明書チェーンがある自己（署名）証明書を
  独自認証局から発行した自己（署名）証明書検証する場合。

• 証明書チェーンがある自己（署名）証明書の利用
  • 問：その範囲は？
  • 答：
    発行者の管理下のクライアントやサーバー
    （第三者の認証が無くても良い範囲）

• 独自認証局から発行した
  自己（署名）ルート証明書をインストールするPCの限定
  • 問：その効果は？
    
  • 答
    独自認証局なので秘密鍵の漏洩が有り得る。
    不正なサーバーへアクセスが発生し得る。

• 証明書の失効について
  • 問：そのタイミングは？
  • 答
    • 秘密鍵の漏洩時
    • マシンの滅却（廃棄・交換）時

セキュリティ・プロトコル †

• データ送信を電子メールの暗号化したファイルの添付
  

• 前提：
  HTTPSのアップロダ的なものに変更した場合、
  ...利点には、送信ミスの防止、パスワード漏洩などがあるが...。

• 問：それ以外の利点は何か？
• 答：暗号化の自動化

アーカイブ・タイムスタンプ †

• 導入時の確認事項として、
  有効期限内に危殆化していないことを確認する。

• 危殆化に関して。
  コンピュータの計算速度の進化から
  当該強度が何時まで有効化予測可能。

通信系 †

HTTP †

• ログから401→200に変わって攻撃者がログインとか言う問題（設問）があった。
• ...

HTTPS †

• アドレスバー系
  • 警告画面で問題に気付く（チェーンが切れていたり失効していたり）。
  • また、EV証明書の問題が多い。
    • FQDN名に対応するサーバーの運営組織を確認できる（OVでも可能だが、EVの方が確認方法が容易）。
    • 復号化機能を持つプロキシだと、EV（OV）が機能しない（可能なのはDVか）。

• アドレスバー＋HSTS
  • HSTS対応ブラウザは、警告画面を無視して先に進めない。
  • MITM攻撃対応のためにアドレスバーのチェックは難しいのでHSTSを使用。

DNSポイズニング †

• 分割配置

• 分割
  • リゾルバ
  • キャッシュ

• 配置
  • リゾルバはDMZ、キャッシュはイントラ内に配置する。
  • 本社、支社などあれば、双方で配置する。
    ・リゾルバはインターネットからの再帰問い合わせを抑止するので。
    ・再帰はDNSクライアントから、反復はDNSサーバから。
    

• DNSレコード

• MXレコード
  • 宛先ドメインの電子メールが、攻撃社のSMTPサーバーに転送されてしまう。
  • 盗聴とか改ざんとか書いたけど、上の答えでOK。
  • 多分、宛先ドメインとか、その辺を書かせたいのだろう
    （宛先ドメインに対応するMXレコードがある）。

• TXTレコード
  • SPFが機能しなくなるので、不正な送信元の電子メールを受信してしまう。
  • 攻撃としては「不正な送信元の電子メールを外部メール・サーバーに送信。」とか。

SMTPのSPF †

• TXTレコードを書かせる問題
  （SPFレコード末尾の"~all"と"-all"の違い）

  "v=spf1 +ip4:192.168.100.0/24 -all"
  "spf2.0/pra +ip4:192.168.100.0/24 -all"
  "spf2.0/mfrom +ip4:192.168.100.0/24 -all"

  「-all」が正解。

• TXTが書き換わっている場合、
  • 問：どういう攻撃が想定されるか？
  • 答：DNSポイズニングで、不正な送信元の電子メールを受信してしまう。
    　　（従って、標的型攻撃などを仕掛けてくる可能性が高い）

• SPFが機能しなくなるケース。
  ・問：どういうケースでSPFが機能しなくなるか？
  ・答：攻撃者が正当なドメインを取得した場合
  　　（犯罪未満のスパム・メールのケースが多い）

認証系 †

共有アカウント †

• 基礎的な問題点
  • 特定困難化
  • 被害拡大

• 更に対応後の問題も。
  • 前提
    機器Aマターでアカウントが漏れた場合、
    • 共有アカウントを停止すると、
    • 機器Bでは、アカウントが使えなくなる。

• 問：対策としては、
• 答：機器A・Bで使用するアカウントを別にする。

Forms認証的な †

• （永続化）認証クッキーの有効期限
  • 問：90日の場合に、不正使用された場合、不正使用が長引く理由
  • 答：認証に使用される永続化認証クッキーの有効期限が長いため。

• ログイン試行のリバース・ブルートフォース攻撃関連

• レインボー・テーブルと、ソルト、ストレッチの関連
  • レインボー・テーブルは、ありがちなパスワードのハッシュ値に
    　対応した文字列を準備して突合するオフライン攻撃を行うモノ。
  • ソルトの追加によって、同一パスワードでも異なるハッシュ値になるため、
    　レインボー・テーブルを新規作成する必要が出てくる。
    
  • 更にストレッチの追加によって、ハッシュ値の算出に時間が掛かるため、
    　当該システムのレインボー・テーブル作成を困難化できる。

• リバース・ブルートフォース攻撃の検知
  • （１）
    ・問：運用チーム４名がログイン可能
    ・答：運用チーム以外のID入力を検知

• （２）
  ・問：リバース・ブルートフォース攻撃の検知は？
  ・答：同じIPアドレスからの単位時間中の試行失敗回数の閾値超えで検知

• パスワード・リスト攻撃

• 多数のアドレスからのパスワード・リスト攻撃の検知
  ・問：検知方法は？
  ・答：単位時間中の試行失敗回数の閾値超えで検知
  　　　（ユーザ・アカウントやIPアドレスによらない）

• リバース・ブルートフォース攻撃を振っておいて、
  パスワード・リスト攻撃を問うと言うセコい引掛け。

X.509 †

証明書（認証）を使用しているからセキュア

認証方式 †

認証方式をプロキシ型からエージェント型に変更する。
（とは言えISAPやmod_xxxではなく、メソッドを呼ぶと問題文中にある）

• 問：本方式変更の際の改修ポイントは？
• 答：アプリ内でメソッドを呼び出す。

二要素認証 †

• 問題文中に二要素が書かれている（パスワードとOTP）。
  • 問：二要素は？（とあるので）
  • 答：「パスワードとOTP」と答える。

• 突破
  • 二要素が漏れた。
    • 問：原因の「不適切な行為」は？
    • 答：二要素を漏らす行為。

• 漏洩時の対策
  • 問：不正利用が長引くので対策。
  • 答：二つの要素に対して行う。
    ・１つ目の要素（パスワード）を変更
    ・２つ目の要素（デバイス）紛失の連絡。

なりすましの話 †

（と言うか、IdPのLoA認定のような話だが）。

• 問：追加認証オプションの仮パスワード発行までの手順上の問題は？
• 答：申請自体がなりすまし（仮パスワード発行先のメアドを変更する）。
  　　　対策は、管理責任者が申請をした利用者に申請の事実確認を確認する。

テスト系 †

• レースコンディションの防止の規約

• 問：DBから読み込んだ値の更新処理の規約
• 答：他のスレッドから更新されていないことを確認。
  　　DBなのにTxが関係無いが、問題文中で「今回のように」とあるので、
  　　フォーカスすべきはTxではなく、レースコレクションへの対応。
  　　ただ、確認する方法ってあるっけ？と言うのが微妙。
  　　スレッドセーフな実装。位が実現的だと思うが？

• サーバー認証の試験

• サーバー認証に失敗したらサーバー認証エラー画面を表示する。
  • 問：サーバー認証試験に失敗した場合のどの様な結果になるか？
  • 答：サーバー認証エラー画面を表示する。

• 期間外の試験の条件

• 問：期間外の条件のテストを行う際の証明書の条件
  　　・有効期限の開始（日）：サイトの証明書と同じ値
  　　・有効期限の終了（日）は？

• 答：テスト日より前の値

• BYOD（Bring Your Own Device）
  BYODで、ICカードを使用しなかった。
  • 問：この理由はどの様な検証がテスト工程で必要になるためか？
  • 答：BYODのデバイスとICカードの互換性検証が必要になるため。

※ BYODのデバイス ≒ 多種の個人所有機

• セキュリティ脆弱性対策ツール

• スコープ（アプリのみ、機器のみ）がある。

• クラウドやデータセンタに事前通知が必要な事がある。

• Webアプリ

• WAF、IPS、IDSがある場合は、
  ・OFFにして脆弱性診断を行う。
  　（試験の回答ではIPアドレスでフィルタ解除）
  ・若しくは、内側から脆弱性診断を行う。
  

• 外部から攻撃されない場合、
  対象の脆弱性は優先度を下げることが出来る。
  ・社員だとバレるとクビなので。社外なら（社内でも）逮捕になる。
  ・そう言うことで、匿名アクセスやなりすましの対策の優先度が高い。

• ネットワーク機器
  • ...。
  • ...。

• 負荷テスト・ツール
  • スコープ（アプリのみ、システム全体）がある。
  • 事前通知は不要だが、従量課金されるのは問題。

Public Client系 †

• スマホOSでのルート特権化（１）
  • 前提：スマホではルート権限を与えないため制限されている。
  • 問：脆弱性のあるソフトXが制限なしで実行可能になる条件は？
  • 答：ルート権限を持って実行される場合。

• スマホOSでのルート特権化（２）
  • 前提
    • スマホOSには、BOFでルート特権化される脆弱性がある。
      
    • あるバーションのOSから、BOF対策機能が実装された。

• 問：
  意図しないルート化はどういうケースで起き得るか？

• 答：
  BOF攻撃を行うマルウェアに感染した場合
  （「アプリにBOFの脆弱性がある場合。」ではなかった。
  アプリの場合は、別途、攻撃される必要があるからか。）

• 携帯電話網では不可（MDM）
  問題文に、携帯電話網ではデータ消去が不可とある。
  • 問：データ消去が不可のケースは？
  • 答：携帯電話網を使用している場合。となる。

マルウェア系 †

• 准、そのまんま系

• 利用可能ソフトウェア一覧とパッチ一覧と、
  適用対象マシンと適用手段の情報がある。
  • 問：パッチの適用対象は？
  • 答：利用可能ソフトウェア。

• パッチ配信サーバー経由でマルウェアを配信してしまった。
  そのため、パッチ検査の対策を追加した。
  • 問：追加された検査は、どのような攻撃方法を想定している？
  • 答：パッチ配信サーバーにパッチとしてマルウェアを配置する攻撃
    ※ 他力に依る拡散（≠ ワーム、≒ ウィルス）。

• ML1-5がパックされていて、ML2-5がファイルのタイムスタンプを変更する。
  • 問：MLを発見され難くする特徴を２つ挙げよ。
  • 答：
    （１）パックされていた。
    　　　ドロッパによるパッキングなどがコレに該当するっぽい。
    （２）ファイルのタイムスタンプを変更する。
    　　　タイムスタンプ変更はフォレンジックに影響を与える模様

• C&Cとの通信

• FW、プロキシ上のログ活動履歴情報として使用できる。

• C&Cが404を返す。
  • 問：ログ上は200だが、ブラウザからアクセスすると404
  • 答：C&CのサーバーがUAヘッダをチェックしている。

• プロキシ認証に対応
  • 問：どの様に対応しているか？
  • 答：クレデンシャル（認証情報）を盗聴
    　　（キーロガーとかの可能性は無いのか？と）

• MITB
  • 送信だけでなく受信を改ざんする理由を問う問題（設問）
  • HMAC導入の場合、ソフトウェアが攻撃される可能性 → デバイス化
    （攻撃はソフトウェアの差し替えかと思ったが、出力の改ざんと言っている）

• 暗号化によるウィルススキャンの回避
  「暗号化ファイルの復号化後のウィルススキャン」を様々なシーンで応用
  • 電子メールの添付ファイル
  • 共有フォルダ
  • Webストレージ

フィルタリング系 †

• 分離した経路をフィルタリングみたいな。

• フィルタリングのスコープ
  • ドメイン（≒ 後方一致）
  • FQDN、URL、メアド（≒ 完全一致）

• C&C通信

• JREの脆弱性を突いたマルウェアのC&C通信は、
  JavaのUAヘッダでフィルタリングするなど。

• CONNECTの443以外を使用するC&C通信を拒否した場合、
  • 前提
    ・CONNECTの443を許可
    ・CONNECTの443以外を拒否
    ・ソレ以外をすべて拒否
  • 問：どの業務に支障が出るか？
  • 答：問題中から、HTTPSでポートが443以外の
    　　サービスを利用する業務を探して回答する。

セキュア・コーディング系 †

コチラと大差なく、素直な問題が多い。

• URL中にSessionIDを含める場合、
  Referrerで漏洩する（昔、ガラケーブラウザで使ってたり）。

• XSS

• Secure属性を付与しない場合、
  HTTPで盗聴→Sessionハイジャックなどに繋がる。

• 「URL」の書き出し部位をチェック。

• チェック方法としては、
  ・先頭が「http://」,「https://」で始まるかどうか。
  ・ココでは、JavaScriptスキームによるXSS攻撃を対象とする。

• 「URL」→「テキスト」や「文字列」ではダメか？
  ・JavaScriptスキームによるXSS攻撃が対象。
  ・「テキスト」や「文字列」ではアンカータグ化されないため。

• CSRF(XSRF)

• 「乱数」をHidedenに入れる。

• 以下はNG？

• SessionIDをInput項目に入れる。

• フレームワークでのサポートを活用する。

• OSコマンド・インジェクション

• bash ShellShock?
  bashの脆弱性を利用したOSコマンド・インジェクション
  • GNU Bash には、
    ・環境変数にシェル関数定義を設定して他のシェルプロセスに渡す機能と
    ・環境変数で設定されたシェル関数定義を取り込む機能が存在します。
    存在します。
    
    関数定義に続きシェルコマンドが記述されている形で環境変数が設定されているとき、
    GNU Bash は関数定義を取り込む際にそのシェルコマンドを実行してしまいます (CWE-78)。

• 以下のような文字列を環境変数に取り込むと、
  「echo vulnerable」の部分が、インジェクションされる。

  '() { xxxx; }; echo vulnerable'

• bash ShellShock?のテスト結果

  env x='() { xxxx; }; echo vulnerable' bash -c set
  vulnerable　← シェルコマンド（echo vulnerable）実行の結果
  BASH=/bin/bash　← シェルコマンド（bash -c set）実行の結果
  （省略）
  x ()　← 関数定義
  {
      :
  }

情シス・マター系 †

• VDI
  • モバイルPC → VDIの話。

• 前提
  ・モバイルPCのインターネット・アクセスは、HTTP、HTTPSのみ許可。
  ・SaaSのプロキシ＆VDIを導入し、モバイルPCはVDI端末として運用。

• 問：SaaS（プロキシ）導入後のセキュリティ・ガイドライン
• 答：（プロキシは）社内LANとVDIからのHTTP、HTTPSアクセスのみ許可。

• パッチ適用
  製品によって手順が違うので、文中から拾う。

• 仮想PCへのパッチ適用
  VDI端末と仮想PCを間違わないこと。
  ・問：３つの手順
  ・答：
  　・マスタ・イメージの更新
  　・仮想PCの複製
  　・再ログオン

• VDI端末へのパッチ適用
  VDI端末と仮想PCを間違わないこと。
  ・問：管理者と利用者の手順
  ・答：
  　・配信パッチ一覧の更新
  　・OA-LANへの接続（と更新）
  　（手間なのでVDI-LANでの自動配信という話へ）

• ISMS系

• インシデント

• 対応方法
  報告すべきインシデントの範囲が明確に定義されていない。
  ・問：「」が不明瞭、「」の明確化。
  ・答：「報告すべきインシデントの範囲」

• 対応が部門主導で行われている。
  IRT（Incident Response Team）主導で行うように変更した。
  ・問：部門主導からIRT主導に変更する目的は何か？
  ・答：部門都合ではなく前者都合を優先するため。
  （問題文中に「部門都合を優先した対応を行っている」とある。）

• 構成管理を活用系

• IRTによる活用
  問題の迅速な把握・特定。
  ・現状の脆弱性情報の把握。
  ・脆弱性を含む機器の特定。
  ・インシデント・ハンドリングにおける活用
  　インシデント発生・対策時の影響範囲の特定に活用できる。

• 管理ソフト
  ・スマホの場合
  　・モバイル端末管理（MDM）を使用する。
  　・MDM：Mobile Device Management
  ・他社ハードウェア資産を含む場合
  　・サーバーのみ、エージェント不要なものにする。
  　・他社資産にエージェントのインストールが不要なので。
  　　（他社ハードウェア資産上のソフトウェア資産管理が発生する）

• フォレンジック
  • 対策の基礎的項目（付加的特性、対策機能）の確認
    ・実装する対策機能。
    　・ログイン時にメッセージ表示
    　・電子メールのアーカイブ機能の実装とその説明
    ・対策機能の効果。
    　・付加的特性（真正性、責任追跡性、否認防止）に関する周知を行う。
    　・これにより、対策機能の予防の抑止・抑制効果抑止・抑制効果を発揮する。

• バックアップ
  ・OSのバックアップとの差分でマルウェアによる変更を発見する。
  ・ログのバックアップとの差分でログ改ざんを発見する。
  ・作業サーバでの入力コマンドのログと操作履歴のログが取得される。
  　このうち、操作履歴のログは管理サーバに転送されるので、
  　作業サーバのログ改ざんがあっても、証跡から追跡が可能。

• PCI DSS v3

• クレジットカード番号
  PAN：Primary Account Number

• PANをVIPサポート業務の対応の迅速化のため保存している。
  ・問：何が以下の方針に反しているか？
  　・業務上不要な利用や保存はしない。
  　・業務上の利便性だけの理由による利用や保存も禁止。
  ・答：PANの保存（は、業務上の利便性だけの理由）

• PANを主キーではなく、顧客コードに関数従属させる
  PCI DSSでは、暗号化を施せばPAN保存を認めている（PCI DSS v3要件的に改善）。
  ・問：これにより、どの様に改善出来るか？
  ・答：対応時、PANではなく、顧客コードを聞く
  ・コチラと繋がっている。

• 無線LANはNG（PCI DSS v3 - 11.1 要件）
  • 問：何故、APスキャンするか？
  • 答：無線LANはNGであるため。
    　　（外部APと盗聴に限定しない。無線LAN自体がNGなので。）

• 暗号化キーはアカウントに関連付かない事（PCI DSS v3 - 3.4.1 要件）
  • 問：ログイン時に復号化する。何が問題（動作・内容）？
  • 答：
    　・動作：ログイン時に復号化する動作。
    　・内容：暗号化キーはアカウントに関連付く。

• その他

• ICカード

• 貸与
  ・前提
  　・Gr社員＋取引先従業員
  　・業務に必要
  　・１人１枚
  ・問：申請時の確認事項
  　　（Gr社員＋取引先従業員以外で）
  ・答：
  　・業務に必要
  　・１人１枚

• 返却
  ・前提
  　・失効情報開示は１営業日以内に行う。
  　・申請受付・情報開示は毎週火曜（月～日申請分）
  ・問：問題点は？
  ・答：最短でも２営業日を要する。

• 方式案
  A案：PJ毎 or B案：１枚貸与
  ・問：要件の対応優先度（１）事業部門負荷の軽減、（２）管理部門負荷の軽減
  ・答：B案は、事業部門が関与せず、カードの貸与回収の回数（工数）も少ない。

• 委任・委託系

• 外部委託における特権IDと個人IDの紐付け。
  （個人ID：アカウント、特権ID：グループ的な）
  ・問：製品機能だけでは不十分で管理が必要
  ・答：管理内容は作業者の個人IDと本人確認

• 外部委託における顧客データ利用の遵守。
  ・問：IPAの「組織における内部不正防止ガイドライン」を参考にした対策
  ・答：委託先のデータ管理の実態を監査で把握して監督する。

• クライアント証明書
  ・利用の開始時、
  　インストールを担当者に委任。
  　（代表者は不正行為を行わない前提で）。
  　・問：担当者が不正行為を行う可能性がある。
  　・答：
  　　・代表者による確認を行う（代表者がインストールではなく）。
  　　・一方、失効の問題では、代表者に失効操作の権限を付与。
  ・利用の停止時、
  　・問１：クライアント端末の失効手続きが必要になるのはどの様なケースか？
  　・答１：
  　　・秘密鍵の漏洩が疑われる場合。
  　　・クライアント端末の廃棄・交換の場合。
  　・問２：失効手続きの注意点はなにか？
  　・答２：失効の申請があった識別番号の証明書の更新を拒否する。
  

• 規則に準拠系

• スマホは既定でWebストレージと同期
  ・問：管理対象外のサーバー・システムの利用を禁止する。
  　　　...と言う規則に準拠するために設定することは何か？
  ・答：スマホのWebストレージ同期はOFFにする。

• 不正競争防止法 - 営業秘密
  • 定義を書かせる問題がいくつか。
  • 紙媒体の表紙の秘マークは、
    電子媒体の場合、透かし文字などで全ページに表示。

業務の仕様っぽい話 †

• ココの件をオレオレ＆業務っぽく書く。
  • 問：設問では、AuthKey?とYoyakuCode?とか言ってる。
  • 答：AuthKey?のユーザ情報とYoyakuCode?を関連付ける。
    　　（敢えてResource Server的な書き方をしない）

• 電子メール・アドレス帳の全件送信
  クライアントがアドレス帳にアクセスする認可は取る。
  ただ、サーバーに送信するアドレスは最小限に留める。
  • 問：アドレス帳を全件サーバー送信。が問題→代案。
  • 答：アドレス帳から選択してサーバー送信を行う。

その他 †

• 一連のストーリーを終えて。
  • 問：今後の備えは？
  • 答：
    • 体制の整備
    • 手順の規定

国語問題、そのまんま系 †

国語問題 †

作文系（文系） †

問題よく読め系（文理） †

そのまんま系 †

問題文中から拾う系 †

• 情シス・マター系に多いらしい。

• あとは問題文が離れている系というものがあるらしい。

• A社の機密情報：新薬の研究情報
  • 問：情報を外部に送信するマルウェアによる想定される攻撃。
  • 答：新薬の研究情報を外部に送信する攻撃。

• 日本と欧米地域

• ID体系は同じだが、重複がある。
  ・問：SSO実現に向けてどういう問題があるか？
  ・答：日本と欧米地域でID重複がある。

• 正社員の社員情報は、
  日本DSからグローバル（DS）にレプリケーションされる。
  ・問：契約社員が居る場合の問題点は？
  ・答：契約社員の社員情報が取り込まれない。
  ※ 問い掛けは、こんな解かり易く書いていない。

• ウィルススキャン
  • 前提
    ・AS-ISのウィルススキャン運用
    ・導入製品のウィルススキャンの集中管理機能

• 問：TO-BEの導入製品の活用方法
• 答：前提から適用可能箇所を抽出
  ・ウィルス定義の更新の自動化
  ・定期スキャン開始の自動化
  ・観戦情報から感染端末を特定し駆除を実施する。

• PANは暗号化できない主キー列に使用できない。
  • 問：PANを主キー列に使用できない理由は？
  • 答：主キー列は、暗号化できないため。

• ハードディスク暗号化は透過的（API経由であれば平文と同じ）
  • 問：ハードディスク暗号化がマルウェア対策に役立たない理由。
  • 答：マルウェアから透過的（API経由であれば平文と同じ）にアクセス可能。
    ※ 設問中の文言を使用して答えたほうが良さそう。

理詰め系（理系） †

経路系、暗号系とマルウェア系、
セキュア・コーディング系など、
攻撃手口に関連したものが多い印象。

参考 †

• ポケットスタディ 情報処理安全確保支援士
  https://books.google.co.jp/books?id=seWoDwAAQBAJ&source=kp_book_description&redir_esc=y&hl=ja

     

Site admin: TechInfoOfMicrosoftTech

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.277 sec.