DNET_SCExamAfternoonPastExams - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

SC：試験 - 午後 - 情報処理安全確保支援士の過去問

午後Ⅰ

平成31年（令和元年）

秋（午後Ⅰ・平成31年）

  • 問1
    メールサーバ構築屋さん向けの問題。
    専門性が他の問題と比べ非常に高いが、
    午後問題あるあるの対策範囲でもある。

    • 知識
      サーバー認証（メール の該当節）

      • SPF（Sender Policy Framework）
        ・送信元ドメインに対応する送信元のIPをチェック。
        ・送信元ドメイン配下のSMTPサーバのIPアドレスを登録。
        ・転送でエンベロープFromを書き換えないとエラーになる。
        ・DNSサーバとSMTPサーバのペアは送信元、送信先になる。

      • DKIM（DomainKeys Identified Mail）
        ・送信元ドメインに対応する公開鍵で送信元と改ざんのチェック
        ・aspf=r（relaxedモード）なのは、認証ドメインがヘッダFromのサブドメインだから。

      • DMARC（Domain-based Message Authentication, Reporting, and Conformance）
        DMARCを使っても、空目系のなりすましアドレスからの攻撃は避け難い。的な話。

    • 引掛
      詳細不明でも答えられる？ → 難しそう

      • 午前Ⅱの四択で正解可能な知識レベルでは難しい。
      • 問題文中に答えはあるが、短時間で拾い選択するのは不可能。
      • 最終手段で、文中の文言でトリマ埋める程度の事しか出来ない。

  • 問2

  • 問3

春（午後Ⅰ・平成31年）

  • 問１

    • 概要

      • WebAPIのCORSの話。

      • Preflight requestの話（CORS (Cross-Origin Resource Sharing) の該当節）も。

      • 一部に、CSRF(XSRF)（SC：脅威 の該当節）の話も混じる。
        ・JSONPに認証が無い話を混ぜている。
        ・それで、CORSを採用した。的な流れになって行く。

    • 知識

      • CORSとPreflight requestの基本知識に加え以下の詳細知識。
      • Preflight requestでCookieが送信されるのは、Main request。
      • Main requestの前に、ブラウザが確認すること
        （各Access-Control-Allowの内容をクリアしているかどうか）。

  • 問２

    • 概要

      • クラウドメールサービス利用からのフィッシング。
      • 社外Wi-Fiアクセスポイントが攻撃者に仕込まれていたため。

    • 対策

      • IDMaaSを使用した認証連携
      • 2要素認証的に、WebAuthnを追加

    • 知識

      • 攻撃者のDNSの情報がDHCPで配信
      • 攻撃者のフィッシングサイトに誘導
      • サービスにHSTS（SSL/TLS の該当節、HTTP→HTTPSリダイレクト問題に対応）
        が設定されていなかった為、フィッシングされ易かった的な話が挟まれる。
      • 認証連携 + 2要素認証でフィッシング対策
      • 2要素目にOTPではなくWebAuthnを採用する理由。

    • 引掛

      • Wi-Fi設定（攻撃者の仕込み）
        DNSのDHCP配信だけでなく
        「ホテルのSSIDとパスワードと一致させておく。」
        を忘れずに...。

      • OTPに対する攻撃
        リアルタイムな中間者攻撃で認証情報を転送する。
        （リアルタイムで認証情報を手入力と書いたら？）

      • WebAuthnの
        ・4つの鍵の対応は問題文中から拾う。
        ・フィッシング防止をどう簡潔に言うか。
        　→ 秘密鍵Kを保有しておらず署名Mを生成できないから。
        　...と、登録フェーズではなく、認証フェーズの事を言う
        　（まぁ、TPMが違うとか、違う言い方もできそうだケド）。

  • 問3
    ゲームのアーキテクチャ設計のケース・スタディ

    • 概要

      • JWT化されたOAuth2的
        ・認証サーバ（AuthN）
        ・ゲーム機（Client）
        ・ゲームサーバ（Resource Server）

      • その他、ゲーム機には
        ・クライアント認証のためTPMが実装され、
        ・ブートローダとOSの改ざん対策が施される。

    • 知識

      • 上記で言っている事が理解できればOK

      • また、JWT生成に、共通鍵 or 公開鍵を選択した場合、
        ・何がどう変わるか？を説明できる知識が必要。
        ・公開鍵の場合、何処に何の鍵を配置するか？

      • ブートローダとOSの改ざん対策としては、
        ・実行ファイルのハッシュ値リストを使用する。
        ・ハッシュ値リストは改ざんされないようTPM内に保存される。

    • 引掛

      • 共通鍵の場合の利用範囲
        「同じゲーム開発会社が開発したゲーム」
        ...というのを以下の問題文中から拾う必要がある。
        ・ゲームサーバはゲーム開発会社が運用管理
        ・管理者は当該ゲーム開発会社のゲーム向けのトークンを生成できる。
        ・故に、当該ゲーム開発会社の開発したゲーム（なるほど解らん）。

      • PC（AIやボット）に操作させる的な話
        ゲーム解らんので、あまりピンとこないけど、
        （Clientの秘密鍵の入ったSSDを、そのままPCに接続するみたいな方法で）
        Clientの秘密鍵を使って、PCに操作させることで、
        ゲームを有利に進めることが出来ることが問題らしい。
        （チートbot等と言い、24時間自動で経験値を稼ぐ等の不正を行う）

  • 感想
    難易度は順に、高・中・低だそうで。

    • 問1 : 捻りがなく知識があれば簡単。
    • 問2 : 一般的だが、引掛が多い印象。
    • 問3 : ゲームのケース・スタディは、オレオレ感あって少々難しさがある。

平成30年

秋（午後Ⅰ・平成30年）

  • 問１

    • 概要
      IoT機器のバッファオーバーフロー系（C/C++）

    • 知識

    • 引掛

      • メモリのアドレスの方向
        下位アドレスが上に書いてある（BOF系の説明では案外デフォ）

  • 問２

    • 概要

      • ポートスキャンで感染するワームの話。
      • 問いは、この発見と対策の方法。

    • 知識

    • 略号

      • NSM (Network Security Monitoring)
      • STIX（SC：脅威 の該当節）(Structured Threat Information eXpression)

    • 引掛

      • DHCPなので１つのIPに対して複数の（感染）PCが割り当てられる。
        アドレスAが２つのPCに割当てられて、両方がワームからのアクセス。
        と言う事で、ログを最後まで読む。

      • 対策２つ。
        (1) ウィルス・スキャンと...
        (2) 定義ファイルの更新だと。

      • スイッチに接続したPCが感染しないようにするには...。
        パッチと回答したら違って、VLANによる分離だと。
        確かに、ルータ部分は、NSM＋IDPでフィルタリングとあるし、
        そう言えば問題文にはVLANと言う文字列があったなぁ...と。
        （故に、スイッチがー。となったらNW的な対策について言及する）

  • 問３

    • 概要

      • フレームワークの脆弱性によるOSコマンドインジェクション
      • 問いは、この対策としてWAF導入の方法。

    • 知識

      • NTP（ネットワークの基礎編 の該当節）サーバはよく出てくるな。
      • CVSS（SC：脅威 の該当節）（マークじゃ無いので）
      • DNSレコードではなくCNAMEレコード（DNSサーバ の該当節）

    • 略号

      • 強いていうと、AF（アプリケーション・フレームワーク）
      • ファイア・ウォールと被るので、FWとは略されない。

    • 引掛

      • 待機サーバが停止告知のWebサーバだったりする。

      • ログ管理サーバで外部メールサーバに対するSSH接続の成功を調査
        （OSログでSSHのログを取得可、F/Wはペイロードのログ無し）

      • WAFの導入話（SC：対策技術 - 防御・侵入検知 の該当節）
        ・ソフトウェア型
        　・≒エージェント型
        　・特に所見なし。
        ・ハードウェア型
        　・プロキシサーバー型（≒インライン構成）。
        　・NW経路上に配置するのでHTTPSを終端する。
        ・クラウド型
        　・プロキシサーバー型（≒インライン構成）。
        　・L7で、アドレス変更があるので、CNAMEレコードを使用。

  • 感想
    難易度は順に高・中・低だそうで。

    • 問1 : 知識が有るか / 無いか（PG未経験者には難しい）。
    • 問2 : NW知識＋引掛が多い印象。
    • 問3 : あまりセキュリティ関係ないな...（ほぼNW知識）。

春（午後Ⅰ・平成30年）

  • 問１

    • 概要
      BOF（Buffer OverFlow）ではなくUAF（Use After Free）

    • 知識

      • 32bit リトルエンディアンのバイトマシン
        データを構成するワード（汎用レジスタのサイズ）を逆順に並べる。

      • UAF（Use After Free）
        XXXXメソッドが実行されると攻撃コードが実行される。
        ・XXXXメソッドで最初に出てくる関数のアドレスに攻撃コードを仕込む。
        ・攻撃コードの仕込みはヒープ領域に対してバイト入力可能な部位で行う。
        ・合わせて関数テーブルの改ざんも必要になる（改ざん可能な脆弱性ある？）。

      • DEPやASLR（SC：システム開発 - プログラミングによるBOF対策 の該当節）
        があってもダメ
        ・DEPが効いている場合、共有ライブラリのアドレスを仕込めば攻撃可。
        ・ヒープ解放後アドレスへアクセスしASLRの共有ライブラリのアドレスが
        　判明する可能性（従って、解放の直後にnullクリアが対策になる）。

    • 略号
      なし。

    • 引掛

      • /bin/sh シェル・コマンドの実行は system関数で行う。
      • そもそも、確実に成功する攻撃の話ではなく、脆弱性への言及。

  • 問２

    • 概要
      マルウェア→メールを使用した漏洩のコンボ

    • 知識

      • プロキシ・サーバーのCONNECT（SC：試験 - 午後 - パターン＆プラクティス の該当節）の悪用＝不正中継
      • TXTレコードにはSPFの情報（DNSサーバ の該当節）として送信元のSMTPサーバの情報が入る。

    • 略号
      なし。

    • 引掛

      • 再帰クエリ？反復クエリ？→インターネットの名前解決でエエ
      • SMTPサーバが内向きと外向きで別れているので引掛る。
      • 運用PCもパッチは適用するので、プロキシ側はパッチのみ許可となる。
      • CONNECT有効下でポート制限機能に問題があると言うが見直しで言及が無い。

  • 問３

    • 概要

      • 事業拡大に伴い事務LAN(前)と研究開発LAN(奥)を分離
      • 中間セグメントにファイル受け渡しのアップろだ
      • 感染は、ありがちな研究開発LAN(奥)＋リムーバブルメディア

    • 知識

      • リスク対応計画の一般的知識

      • 感染経路のリスクが低い理由
        ・能動的（ワームの攻撃） → FWでのフィルタリング
        ・受動的（マルウェアのDL） → 作業者が気付ける。

    • 略号
      なし。

    • 引掛
      CAPTCHA（キャプチャ）と思いきや、上長の承認www
      内部犯行じゃなくてマルウェアなんだから...。

  • 感想
    難易度は順に高・中・低だそうで。

    • 問1 : 知識が有るか / 無いか（PG未経験者には難しい）。
    • 問2 : ありがちな内容だが、全体的にモヤモヤ感がある。
    • 問3 : 上長の承認を除き、モヤモヤ感がない、スッキリした内容。

平成29年

秋（午後Ⅰ・平成29年）

  • 問１

    • 概要

      • ランサムウェアに感染したインシデント。
      • インシデント対応と再発防止策の実施

    • 知識

      • RLO : Right-to-Left Override
        アラビア語などは右から左へ書かれる。
        RLOを挿入すると、以降の記述方向を制御できる。
        マルウェア類の拡張子を騙すのに使われる。
        （逆は、LRO : Left-to-right override）

    • 略号

      • AP：アプリケーション
      • 検体：検査・分析の対象として取り上げる物体。

    • 引掛

      • Gを忘れない。
        ・Dサーバ（Dドラ）
        ・Gサーバ（Gドラ）

      • 出荷指示の書き出しは、
        クライアント（担当のアカウント）ではなく
        サーバ（サーバの実行アカウント）で実行される。

      • 公開鍵で生成された共通鍵を暗号化してメモリから削除する。
        ・「メモリから削除されるから（入手できない）」ではなく、
        ・「秘密鍵を入手できないから（復号化できない）」と書くらしい。

      • シャットダウンすると揮発メモリは消える。
        物理メモリと仮想アドレスとのマップが解除されるとか深読みダメｗ

      • ランサムウェアXはワーム的に管理者権限で感染する。
        「初期感染したPC以外のPCのドライブだけでなく他のPCのドライブも暗号化される。」
        ではなく「管理者権限でしかアクセスできないドライブも暗号化される。」らしい。
        （バックアップ先が管理者権限でしかアクセスできないドライブらしい。空気読めと。）
        （ディテールの無い記述で管理者権限で感染するから管理者権限で実行されるんか？と。）

  • 問２

    • 概要
      Webアプリのコードレベルの脆弱性の
      診断と対策（JavaとJavaScript）。

    • 知識

      • プレペア（Java）

        String sql = "select * from XXX where yyy =?";
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setString(1, "YYY");
ResultSet rs = pstmt.executeQuery();

      • XSS防止のCookie系の属性
        ・Secure属性：HTTPSの時ダケ送出
        ・HttpOnly属性：JSアクセス不可能

      • オープン・リダイレクタ対策は、
        ホワイトリストの完全一致（これはOAuth2でやったね）。

      • ブラウザによっては、XSSフィルタ機能があり、
        テストで脆弱性が検出されないんだと（知らんかった）。

    • 略号
      なし。

    • 引掛
      設問3がアレ

      • 改善すべき検査手順
        「手作業ではなくツール（新しく発見された脆弱性を診断可能）」ではなく、
        「デプロイしてからテストしようね。」だと（問題文中にデプロイ忘れが書かれている）。

      • WAFで「低減できる"リスク"」
        ・「未対応の脆弱性を検出してブロック可能」ではなく、
        ・「新しく発見された未対応の脆弱性を攻撃される"リスク"」（答え方に注意）

  • 問３

    • 概要
      証明書関係のインシデントの発生とその対策。

    • 知識

      • セットでDNSによるフィッシング（SC：脅威 の該当節）が出てくる。

      • 証明書の秘密鍵側が漏れた場合の対応としては、
        ・失効の申請を行う。
        ・以下を公表する。
        　・漏れたサーバのサービスの内容
        　・利用開始から失効までの期間

      • その他、証明書、SSL/TLS、暗号化の各種の脆弱性について。
        ・POODLEはSSL3.0を止める。（SSL/TLS の該当節）
        ・PFS (Perfect Forward Secrecy)鍵交換（暗号化アルゴリズム の該当節）はDHE系
        ・証明書のランクにはDV、OV、EVがあり、DVは実在証明無し。

    • 略号

      • EC：electronic commerce
      • 危殆化（危たい化）：危険な状態になること、危うくなること

    • 引掛

      • 新しい証明書 → 新しい鍵ペア（正解かも？）

      • RSA鍵が危たい化すると、すべての通信が傍受可能。
        ・RSA鍵とは秘密鍵のことを言っている。
        ・危たい化により、共有鍵を復号可能。
        ・危たい化時点より前・後の選択肢があるが、
        　各種鍵は危たい化前後で変更されないので「全て」となる。

  • 感想
    難易度は順に、低・中・高だそうで。

    • 問1 : 引っ掛け多過ぎ（もはや「セキュリティ」では無いレベル）。
    • 問2 : 設問1, 2は楽だが、設問3がセキュリティじゃない感じ。
    • 問3 : 証明書に関する深い知識が必要だが、引掛は少ない。

春（午後Ⅰ・平成29年）

  • 問１

    • 概要

      • 遠隔操作型のマルウェア
      • ARPポイズニング（SC：脅威 の該当節）による盗聴
      • この盗聴は中間者（MITM）攻撃的。

    • 知識

      • ARPポイズニングによる盗聴ツールは、
        ・NW中の機器のARPテーブルを改ざんする。
        ・これにより、通信が盗聴PCに転送されるようになる。
        ・盗聴がバレないように盗聴したパケットを転送する。

      • LDAPでSSHログインできるようにすると言う構築パターンがあるらしい。
        これを盗聴し管理者PCを特定...と言うか、攻撃対象のIPを入手。
        LDAPは平文なので、盗聴でアカウントを入手できるとか無駄に脆弱じゃね？

      • この手の攻撃はMITM攻撃ができるが、サーバー証明書があると吉。

      • セグメントの分割とルーティング設定が効果的。
        ・ARPポイズニングによる盗聴が不可能になる。
        ・IP詐称でTCP/IPコネクション確立ができなくなる。

    • 略号
      なし

    • 引掛

      • 「盗聴されている。」じゃなくて、「盗聴している。」だな。
      • 総当たりのIPスキャンを行うと拒否のログが出る。
        （→ 管理セグメント じゃなくて → サーバセグメントでも出るので）

  • 問２

    • 概要

      • CSRF（XSRF）
      • XSS → セッション・ハイジャック

    • 知識

      • POSTでXSS攻撃し難いが、CSRF対策無いと可能。

    • 略号
      なし

    • 引掛

      • 不正ログイン確認はアカウント名＋ログイン日時
      • [　　　　　]情報 → [知り得ない]情報（マジか...）

  • 問３

    • 概要
      クラウド・サービス利用時のフィッシング
      によるアカウント漏洩対策としてSAMLを導入

    • 知識
      SAML

      • SAMLは、リダイレクトなので、
        SP－IdP間の直接通信は無し。
        （Artifact Bindingを除く）

    • 略号
      SAML用語（クレームベース認証 の該当節）

    • 引掛

      • シーケンス図が下記順番
        ・SP
        ・WWWブラウザ
        ・IdP
        ・LDAP

      • IdPの証明書を利用している処理、
        と言われたら、SP側の署名検証処理をポイント

  • 感想

    • 問1 : 要、ARPポイズニング盗聴経験
    • 問2 : チープ過ぎて考える気力を奪われる。
    • 問3 : 専門性の中でもセコい引掛けをしてくる。

...（午後Ⅰ・平成28年〜25年）

（元 Wiki でも内容は未記載。）

平成24年

秋（午後Ⅰ・平成24年）

  • 問１

    • 概要
      JSONP周辺
    • 知識
      JSONP周辺
    • 略号
      なし。
    • 引掛
      • 一般サイトではなくブラウザ
      • DNSポイズニングではなくCSRF（XSRF）的

  • 問２

    • 概要
      不正アクセスのモニタリング時のしきい値
    • 知識
      上記に関するしきい値の初期設定・運用ノウハウ
    • 略号
      なし。
    • 引掛
      • 今回は無かったが、下手すると、
        引っ掛かりそうな感じはある。
      • 解答欄が、自由記述欄風なので。

  • 問３

    • 概要
      標的型攻撃

    • 知識

      • メール添付とフィッシング
      • SPFとSMTPプロトコル
      • 標的型攻撃対応セット
        ・標的型攻撃メール（入口）対策
        ・ウィルス、マルウェア対策
        ・SMTP、HTTPの出口対策

    • 略号

      • PRX：プロキシサーバ
      • AUT：AD的なDNS＋X.500ディレクトリ

    • 引掛
      多い印象（問題を良く読めが多過ぎる感）

      • TXTのIPアドレスはNATの値
        ・エンベロープFromは、DMZのIPアドレス値になる。
        ・何処でNATされるのかNW屋じゃないとピンと来ない。
        ・よくよく読むとFWの所に書かれているので、DMZの出口か...と。

      • 運用は国内と明記されている
        （なお、中継無しでも問題無い）

      • 「A、B、C、D」の「C」はどうも
        マルウェアの通信をポイントしているらしい（ホスト上の活動はA、B）。
        ・故に、HIDSではなく、NIDS（ネットワークモニタ）。
        ・設置場所も、LAN内とか、ファジーな事を言う。

      • 出口対策はHTTPに対して言及している
        ので回答もHTTPのみにする（SMTPは除く）。

  • 問４

    • 概要
      HTTPでの攻撃のログ解析

    • 知識

      • NW機器のログを紐付ける。
      • NATとか、XFFとか（SC：対策技術 - ログの分析・管理 の該当節）。

    • 略号

      • LB
      • IDS

    • 引掛

      • 証明書 → 秘密鍵（PFXなら...部分点？）
      • NATで...
        ・外 → 内は、送信元IPは変換されない。
        ・内 → 外で、送信元IPが変換される。

春（午後Ⅰ・平成24年）

（元 Wiki でも内容は未記載。）

...（午後Ⅰ・平成23年以前）

量が多くて、やってられない（非効率な）ので、
→ SC：試験 - 午後 - パターン＆プラクティス

午後Ⅱ

平成31年（令和元年）（午後Ⅱ）

秋（午後Ⅱ・平成31年）

  • 問1
  • 問2

春（午後Ⅱ・平成31年）

  • 問1

    • 概要

      • マルウェアからC&Cサーバに接続があったというインシデントから始まる。
      • 調査をすすめると、Wi-Fiの盗聴によりNW接続可能になりアカウント漏れが起きた。
      • それにより攻撃者が、ネットワークに侵入し、PCをマルウェアに感染させた。

    • 原因

      • Wi-Fiの盗聴は、WPA2のAES-CCMPに対する
        KRACKs中間者攻撃により、暗号化されていないAPを作り出す。

      • アカウント漏れは、単純にHTTPだったため。

    • 対策

      • Wi-Fiの対策は、Wi-Fiの認証を
        EAP-PEAPからEAP-TLSへ変更するというもの。

      • アカウント漏れの対策は、HTTP → HTTPS化

      • その他、以下のマルウェア対策
        ・対策１：SPI-FWのHTTPS解除機能の有効化
        ・対策２：ウィルス対策ソフトの導入

    • 知識

      • HDDの複製と保全
        マルウェアの痕跡を調査するための複製
        ・複製はセクタ単位（削除済みファイルも調査可能のため）。
        ・複製元は証拠保全（デジタル・フォレンジック（高度午前 - 技術要素 - セキュリティ の該当節）的にも）

      • AES-CCMPのブロック暗号化とCTRモード（暗号化アルゴリズム の該当節）の方式について、
        ・同一端末間の通信の最初のヘッダは同じになるので暗号解読がやり易い。
        ・ECBでは平文ブロックが同じだと暗号ブロックも同じになる。
        ・ココではECB以外を使用しているが平文ブロックを推測できると、
        　暗号化したカウンタ（暗号鍵＋初期化ベクタ）自体を推測できる。

      • Wi-Fi-NW 中のMAC
        ・MACアドレスはヘッダから確認できる。
        ・MACを偽装可能（NICドライバに依ると思うが）

      • TCP ソケットバッファ中継型のプロキシ
        ・コネクションで上り下りのスレッドを用意して、それぞれ、
        　受送信バッファを読み取って反対の送受信バッファに書き込む。
        ・このような方式なので、HTTPSも処理可能だが、
        　HTTPトンネリングのCONNECTの宛先しか解らない。

      • SPI-FW
        ・一方、こちらはHTTPプロトコルをサーバ側＋クライアント側で理解する。
        ・サーバとしてHTTPSを解いて、ペイロードをインスペクション可能、
        　そして、その後、クライアントとしてHTTPSリクエストを送信。
        ・電文の中を確認可能だが、以下の証明書の問題が発生し得る。
        　・クライアント証明書が使用できない。
        　・クライアントの証明書ストアと異なり通信できない。

      • 証明書ストア関連
        ・信頼されたルート証明書機関の証明書ストアと証明書
        ・信頼されたルート証明書機関のストアに無い
        　機関が発行した証明書を使用するWebサーバとの通信

    • 略号

      • W-AP → Wi-Fi-Access Point
      • D-PC → Desktop-PC
      • FW → Firewall
      • SW → Switch
      • L2-7 → Layer2-7(OSI)
      • 代替HTTPポート → 8080番ポート

    • 引掛

      • プロキシとFWが逆
        FWがプロキシの前か後か？
        ・FW1とFW2のフィルタ・ルールから見破る。
        　・FW1は、三脚境界（SC：対策技術 - 防御・侵入検知 の該当節）を構成するFW。
        　・FW2は、ネットワーク分割のルータみたいな感じ。
        　・FW1とFW2が数珠繋ぎになっていて、一瞬？
        ・Intra → FW2 → Proxy → FW1 → Internet

      • TCP ソケットバッファ中継型のプロキシ
        ・L7で理解しなくても、FTP等の任意のプロトコルを中継可能。
        ・プロキシサーバのCONNECTを悪用しSMTPに接続する等して踏み台にできる。

      • 「見る」→「見て情報を取り出す。」（...）

  • 問2

    • 概要

      • 営業秘密ファイルがインターネットにUPされていたというインシデントから始まる。
      • 調査を進めると、マルウェアXがC&CからマルウェアYをDLしたことが判明する。

    • 原因

      • 関係者ではないK氏がマルウェアX,Yに感染
      • マルウェアYがC&Cから受け取ったアカウントでログイン成功

    • 対策

      • 直近
        ・マルウェア検疫
        ・全社的PCスキャン
        ・ML系アカウントのパスワード変更

      • 事後
        ・アクセス制御の追加、このケースはNWアドレスで制限。
        ・初期パスワードの変更運用は初回ログオン時に、
        　必須の運用・仕組みにする（とあるが、どうやって？）。
        ・ウィルス対策ソフトの集中管理機能の導入
        　・ウィルス定義ファイルの配信＆状況管理機能
        　・脆弱性修正パッチの配信＆状況管理機能
        　・ウィルス検知時、管理者への即時通知機能

    • 知識

      • 営業秘密の定義（SC：法制度 - 知的財産権を保護するための法律 の該当節）

      • 踏み台にならないようにするには
        「オープンリレー（第三者中継）」対策を行う。

      • ZIP解凍スキャンは平時は不要である理由
        ・解凍しないと感染しない。
        ・解凍時にリアルタイム・スキャンで検知可能。

      • 時刻を合わせるプロトコルは、NTP（ネットワークの基礎編 の該当節）だよ。

      • 共通鍵暗号はAES（高度午前 - 技術要素 - セキュリティ - 暗号・認証 の該当節）
        （ホントに流行ってるなぁ...。）

      • 日本の暗号モジュールの試験及び認証制度は
        JCMVP（高度午前 - 技術要素 - セキュリティ の該当節）

      • 電子政府推奨暗号リストを作成している組織は
        CRYPTREC（暗号化アルゴリズム の該当節）

    • 略号
      DPC : Desktop PC

    • 引掛

      • 「自社DMZ上のDNS」と「クラウドサービス上のDNS」
        （其々、利用者は誰か？オープンリゾルバ対策が必要なのは？）

      • 共通アカウント＋IPアドレスでは操作者は解らない。
        （うーんナルホド、なんか、名探偵的な知識か？と思ったり。）

      • 打ち合わせ中だからPCは触れない（キリッ）（名探偵的か？）。

      • アカウントを無効化ではなくパスワード漏れなのでパスワード変更する。

  • 感想
    テキストでは、問1の難易度が高く、問2の難易度は易しいとされている。

平成30年（午後Ⅱ）

秋（午後Ⅱ・平成30年）

  • 問1

    • 概要

      • オンプレからのクラウド移行
      • 社内基準とクラウドベンダ基準のFit&Gap分析

    • Gap

    • 知識

      • GDPR（マークじゃ無いので）

      • SAML、SPNEGO（ネゴシエーション）

      • NIST CSF（SC：法制度 - 情報セキュリティ、ITサービス（規格と制度） の該当節）

      • SSO
        一度のログインで複数のシステムを利用可能。

      • エンドポイント管理ソフトウェア
        ・標準ソフトの脆弱性情報の収集とパッチの適用。
        ・脆弱性のある端末の一覧と、一括のパッチ適用。
        ・標準ソフト以外ではセキュリティ標準を満たせなくなる（Gap）。

    • 略号

      • SAML用語：IdPとSP
      • クラウド用語：IaaS、SaaS

    • 引掛

      • B1認証サーバのオンプレ → クラウド移行時のボトルネック
        ・B1のClientはオンプレのUnix、Linuxなので、ココとの通信。
        ・A1連携とSAMLの話は関係ない（A1のClientはオンプレのみ）

  • 問2

    • 概要

      • ファイルの漏洩
      • 調査するとマルウェアによるものだった。

    • 原因

      • マルウェア１がC&Cからマルウェア２をDL
      • マルウェア２経由で遠隔操作がされる。

    • 対策

      • CSIRTを設立
      • インシデント対応ポリシの作成

    • 知識

      • NIST SP 800-61（SC：法制度 - 情報セキュリティ、ITサービス（規格と制度） の該当節） Rev.2

      • ログのポリシ
        ・取得
        　・機器
        　・種類
        ・保存
        　・保存期間
        　・バックアップ
        　・アクセス許可
        ・時刻
        　・（NTPによる時刻同期）
        　・タイムゾーンの統一化

      • この手のマルウェア
        ・リクエスト：指示要求やファイル送信を実行
        ・レスポンス：C&Cサーバからの指示を実行

      • 対応に問題（事前に行うべきこと）
        ・デジタル・フォレンジック
        ・大概、なにかする前にバックアップしておけという話。
        　ココでは、NWから切り離す前にバックアップしておく。

    • 略号
      なし。

    • 引掛

      • ログオフの失敗
        初回成功前の失敗回数

      • できていないこと
        対策の作業手順の明確化と文書化（そんなことかよ...。）

  • 感想
    テキストでは両方「易しい」と評されていた。

    • 問1 : まさに日本語の問題は、五里霧中で総合力が求められる。
    • 問2 : 問1と比べると専門性を求められているが日本語の問題もアリ。

春（午後Ⅱ・平成30年）

  • 問１

    • 概要
      インシデントは起きていないが、
      検出事項から対応方針を立てる話。

    • ...

    • 知識

      • HttpOnly属性（HTTPヘッダ の該当節）：Scriptでアクセス不可になる。
        ・Cookie毎に適用可で主にSession Cookieや認証Cookieが対象。
        ・ちなみに、Secure属性はHTTPSの場合のみ送信されるように設定可能。

      • DOMベースのXSS（XSS対策の実装方針 の該当節）
        DOMベースのXSSのスクリプト挿入にFragmentが使われるので
        サーバに飛ばないのだと思うが、レスポンスに違いがないと言う。
        （Webサーバでは機能的にFragmentが見えないがキャプチャすれば解ると思う）。

      • 踏み台での証跡
        以下のような証跡を取得する（ありがちな内容だが）。
        ・画面キャプチャ
        ・キーロガー

      • DRM方式とコンテナ方式
        ・DRM方式（高度午前 - 開発技術 - ソフトウェア開発管理技術 の該当節）：
        　暗号ファイルと復号機能を持ったクライアント・サーバ
        ・コンテナ方式：コンテナ・クライアント（CC）とWebストレージ。
        ※ コンテナ方式は１PC１CCインストーラで、サンドボックス的機能を提供する。

    • 略号
      CC：コンテナ・クライアント

    • 引掛

      • コンテナ方式
        ・CCサーバにアクセスできるかではなく、利用するCCIの数だと。
        ・CCIを送信するのではなく、CCをインストールしたPCを輸送するだと。

  • 問２

    • 概要

      • サイト書き換えのインシデントが発生。
      • インシデントに伴う検査でXSSなどの脆弱性が検出された。

    • 知識

      • POSTのパラメタはログに残らない。

      • 改ざんの確認は構成管理のマスタとDIFFっしょ。

      • SSHは公開鍵に依るクライアント認証があると尚良。

      • 収集する情報は、
        ・OS・ミドルのバージョンとあるが、
        ・パッチ適用状況などのOSインストール後の構成管理情報でも良いのでは？

      • 脆弱性の名称（選択でない）（いずれも SC：脅威 の該当節）
        ・ディレクトリ・トラバーサル
        ・CSRF(XSRF)：クロスサイト・リクエスト・フォージェリ
        ・HTTPヘッダ・インジェクション
        ・クリック・ジャッキング

      • 具体的な攻撃方法と検知方法（いずれも SC：脅威 の該当節）
        ・SQLインジェクション
        ・XSS：クロスサイト・スクリプティング

    • 略号
      WF：ウェブ・フレームワーク（30秋午後1-3ではAFだった）

    • 引掛
      「日本語の作文の問題。」と言えるのかも知れないが、
      過去問をやって、回答例を知っておくのも重要と思われる。

      • アクセス制御
        ・（う）で限定商品のcodeを含むPOSTを生成する
        　（codeはどうやって確認すんねんという疑問を持ったら負けらしい）。
        ・テスト方法は複数の権限のアカウントを作成し、
        　許可されていない操作ができないか確認する。

      • 検収条件の追加
        ・Webセキュリティ・ガイドに準拠しているかどうかを確認する方法。
        ・セキュリティ専門業者（第三者）の脆弱性診断かと思ったが、
        　「Webセキュリティ・ガイドに従ったレビューを行い問題がないことを確認する。」らしい。
        ・確かに「セキュリティ専門業者」も文中に出てくるが、
        　ガイドに準拠を検証ってサービスは普通ないよね。

      • Webセキュリティ・ガイドへのフィードバック
        作り込みの工程とレビューポイントを明らかにし、テスト方法や修正方法を追記できる。

  • 感想
    問1は、難易度は低いが問題文が長い。問2は、専門性高めで難しいとのこと。

    • 問1 : 難しくないけど、コンテナ方式が色々とアレで結局、難関化。
    • 問2 : 初期インシデントは投げっぱなして、あとは作文の問題。

平成29年（午後Ⅱ）

秋（午後Ⅱ・平成29年）

  • 問１

    • 概要

      • ビデオ監視システムの全方位的セキュリティ対策的な。
      • 問題文の量が異常で、NW知識も必要になる（パスすべき問題ｗ）。

    • 知識

      • SYNスキャンに対する応答（TCP, UDP の該当節）
        ・ポートが空いている場合：SYN-ACK
        ・ポートが空いていない場合：RST-ACK or 応答なし

      • IoT機器とサーバに対する攻撃（いずれも SC：脅威 の該当節）
        ・中間者攻撃
        ・DNSポイズニング

      • リバース・ブルートフォース攻撃（SC：脅威 の該当節）

      • コンテンツ改ざんの可能性
        ・管理者アカウントのなりすまし。
        ・OS、ミドル脆弱性。
        ・内部犯行 & 内部過失。
        ※ WebApp脆弱性にはワンチャン無しだった。

      • 脆弱性に関する契約
        平成30年 春の検収条件（契約条項にも書く）は、
        レビュー済みかどうかだったが、
        純粋に契約となると当然「脆弱性に関する保証条項と瑕疵担保責任条項」か...。

      • 共通鍵の生成は、
        ・IoTデバイス側ではなく、
        ・利用アプリ側で（利用者が再生成できるからか）。

    • 略号

    • 引掛

      • ポートスキャン → SYNスキャン（そこまで書かす？）

      • カメラの脆弱性の対策、
        ・管理者アカウントが有効ではなく、TELNETでログイン可能な点。
        ・これには、デバッグ用プログラムを取り除くことが必要。
        ・更に手段は回収ではなくカメラIFからのファーム更新（問題文に記載あり）。

      • 管理者アカウントの端末認証の追加
        クライアント証明書（問題文中に書いてない）

      • 転売対策の追加情報
        「利用者番号」なるものを問題文中から拾う。

      • 平常時と異なる状況
        ・リスクベース認証（高度午前 - 技術要素 - セキュリティ - 暗号・認証 の該当節）的に
        　異なるPC・ブラウザかと思ったが、
        ・全ユーザを対象とした認証失敗回数（≒攻撃）だと。

  • 問２

    • 概要
      主に、DB内の契約情報の暗号化の話。

    • 知識

      • 用語を書ききる知識
        ・FISC（誰も知らんやろ！）
        ・CRYPTREC（暗号化アルゴリズム の該当節）暗号リスト
        ・FIPS（SC：法制度 - 情報セキュリティ、ITサービス（規格と制度） の該当節）140-2 level4
        ・耐タンパ性（高度午前Ⅰ - 応用情報の過去問（３年分） の該当節）

      • マルチシグ的な
        部分鍵をICカードに書き出し人に分散すると
        相互監視になって不正を行い難くなる。

    • 略号
      HSMサーバ：H製品 Security Module サーバかな。

    • 引掛

      • 計算問題で248まで計算されてるので「問題よく読め。」的な。
      • 指摘、対策、要件、仕様１-ｎで何処か解らなくなる。
      • クラスタ内の鍵共有と、ラウンドロビンの負荷分散方式
        （ラウンドロビンの負荷分散方式を文中から拾い直すのが大変）

  • 感想

    • 問1 : コレは無理だね（長過ぎ＆ファジー）。選択した者負け。
    • 問2 : 用語を書ききる知識がネックだが、それ以外は難しくない。

春（午後Ⅱ・平成29年）

  • 問１

    • 概要
    • ...
    • 知識
    • 略号
    • 引掛

  • 問２

    • 概要
    • ...
    • 知識
    • 略号
    • 引掛

  • 感想

    • 問1 :
    • 問2 :

...（午後Ⅱ・平成28年〜25年）

（元 Wiki でも内容は未記載。）

平成24年（午後Ⅱ）

秋（午後Ⅱ・平成24年）

  • 問１

    • 概要
      サイトの脆弱性診断

      • PF脆弱性診断
      • WebApp脆弱性診断

    • 知識

      • 脆弱性診断に関する知識

      • その他
        ・SSHのポート・フォワーディング（SSH の該当節）
        　シェルではなく、クライアント・サーバー間の
        　任意プロトコルを使用した暗号化通信を行う機能
        ・Cache無効化は、以下の様なCache-Controlヘッダ（HTTPヘッダ の該当節）

        Cache-Control: no-cache
Cache-Control: private

    • 略号
      PF：プラットフォーム

    • 引掛

      • 問１の検知ではテストフェーズではなく
        本番フェーズの話をしていて、答えは監視だと。

      • 問４の以下の点
        ・構成管理と脆弱性チェックかと思ったが、
        　脆弱性チェックと診断ツールの最新化だった。
        　確かに、ツールの仕様で検知できなかった件があった。
        　また、講評には、自動アップデートは違うと書いているが、
        　検知は監視と、本番フェーズの話をしてるよね？？）
        ・ガイドとテンプレート、レビューと書いたが、
        　→ コーディング規約の整備とあった。

  • 問２

    • 概要
      Wi-Fi導入の話。

    • 知識
      Wi-Fi導入周辺。

    • 略号
      なし

    • 引掛

      • AP
        ・802.1X：ざっくり「認証方式」の意で出てくる。
        ・WPA-PSK（TKIP）は引掛けででてくる（覚えてない）。
        ・ANYプローブ：SSIDを指定しないプローブ要求でプローブ応答させる。
        ・マネジメント・フレーム（ビーコン / プローブ要求・応答）を停止し、
        　SSIDステルス化 → SSIDは傍受可能なので効果は限定的。

      • 顧客用AP
        プロキシ経由しないでインターネット
        ・プロキシ認証とログが機能しなくなる。ではなく、
        ・ウィルス・スキャンとURLフィルタらしい。

      • マトリックス通りに日本語を書く。
        ・（Wi-Fi中の）会議室のAPのみ選択可能。ではなく、
        ・有線LANか、会議室のAPのみ選択可能。

  • 感想
    午後の慣習にも大分慣れ、
    ボチボチ出来たかなと。

    • 問1 : ボチボチ出来たかな...と。
    • 問2 : ボチボチ出来たかな...と。

...（午後Ⅱ・平成23年以前）

量が多くて、やってられない（非効率な）ので、
→ SC：試験 - 午後 - パターン＆プラクティス

専門性系

基礎力系

専門基礎力系

  • 専門基礎力系（SC：試験 - 午後 - パターン＆プラクティス の該当節）

用語を書ききる系

応用力系

専門応用力系

  • 専門応用力系（SC：試験 - 午後 - パターン＆プラクティス の該当節）

名探偵系

以下のような感じのもの。

  • 共通アカウント＋IPアドレスでは操作者は解らない。
  • 彼は、打ち合わせ中だったから、PCは触れないハズ（キリッ）。

推理力的なモノをスペシャリスト系資格で求めるなと思ったりはする。

スーパー・ハカー系

攻撃側の知識っぽい気がする。

  • （攻撃者の設置したAPの）
    ホテルのSSIDとパスワードと一致させておく。

※ 攻撃の手口を知ることで対策できる。

国語問題系

  • コチラ（SC：試験 の該当節）で「国語問題」と呼ばれているもの。
  • 長文になるので、自ずと、読解力的なものが必要になる。
  • そして、出題や回答もそれ前提のモノになって行く。

作文系（文系）

  • フリーフォーマットで回答を作文する。
  • 小中時代の国語のテスト問題を思い出す。

２つ捻り出せ系

二種類の回答を書く

  • 同じ回答を別の言い方にしてもダメ。
  • 視点の違う２つの回答を「捻り出す」。

問に適切に対応する系

  • 「～はなぜか？」と聞かれたら「～だから」と答えるヤツ。
  • SCの試験なので、基本は仕組み（仕様など）を簡潔に答える。

※ 理詰め系でもある。

コンテキストを読む系

  • 専門性の低い問題は特にファジー

    • 行間があるので、この行間を読む必要がある。
    • 主に、文中の文字列から行間（コンテキスト）を読む。
    • これには、文中の文言を使用した解答を作成する。

  • なるべく文中のコンテキストに合わせて書く。

    • "スイッチ"に接続されたPCの...の場合、
      「パッチの適用。」ではなく、「"スイッチ"のVLANによる分離。」となる。

    • 「ランサムウェアXはワーム的に"管理者権限"で感染する」...とある場合、

      • 「このランサムウェアは、ワーム的に感染する。」が既出なので、
      • 「"管理者権限"でアクセス可能なリソースを攻撃し得る。」となる。
      • 感染時の権限と実行時の権限って関係あるのか？（仕組みに依る）気もするが。

問題よく読め系（文理）

文系でも理系でも、問題の読解力は必要。

構成≒設問系

  • 送信時と受信時で違う系

    • DNSサーバ

      • 受信：DMZ上のコンテンツ サーバ
      • 送信：イントラ上のフルサービス リゾルバ（キャッシュ サーバ）

    • SMTPサーバ

      • 受信：DMZ上のSMTPサーバ
      • 送信：DMZ上のSMTPサーバ（OP25B、SPF）

  • 通信経路はルーティング・テーブルから読む。

  • 待機サーバが

    • クラスタ（ホットスタンバイ）ではなく、
    • 停止告知のWebサーバだったり。

計算過程の値が書いてある

時間もないので、計算過程の値が書いてあるケースがある。

問うている内容を理解する。

  • 「低減できる"リスク"」を問われているのに、
    「どうやって脆弱性を防止するか？」を書いてた。

そのまんま系

  • 「国語問題」の一種。
  • 想定外で、慣れていないと、
    何を問われているのか一瞬？になる。

問題文中から拾う系

長い問題文中から拾うのは大変

  • 共通鍵の場合の利用範囲は、
    同じゲーム開発会社が開発したゲーム。

  • OSログでSSHのログを取得している。

  • カメラIFからファーム更新可能。

  • 転売対策の追加情報は「利用者番号」

  • アルゴリズムはラウンドロビンでした。

理詰め系（理系）

高校数学Ⅰ・Ａ、集合と条件みたいな感じのやつ。

集合・命題・条件・論理・証明系

  • 部分集合ではなく集合を書く。

  • ミニマムな対策系
    なるべくミニマムな対策で済む様に書く。
    （アカウント無効化ではなく、パスワード変更）

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

  • 以下の様なケースでは、
    • AだからB
    • BだからC
    • CだからD

※ 文字数制限も有るので、
　　最後の「CだからD」を書く。

  • ただし、原因か？対策か？で回答が異なる。

    • 原因
      最初の「AだからB」を書く。

    • 対策
      最後の「CだからD」を書く。

具体例 → パターン＆プラクティス

参考

追加対策

用語一覧

専門性系対策

パターン＆プラクティス

国語問題、そのまんま系対策

IT資格の歩き方

n 週間で仕上げる 情報処理安全確保支援士

3週間

2週間

過去問

道場

  • 午前Ⅰ（高度午前Ⅰ - 応用情報の過去問（３年分） の該当節）
  • 午前Ⅱ（SC：試験 - 午前Ⅱ - 情報処理安全確保支援士の過去問 の該当節）

IPA

ツボ

  • インフラエンジニアが情報処理安全確保支援士(セキスペ)に合格した勉強法
    https://pentalouge.com/1510/

    • 午後Ⅰ

      • 2/3問を回答。
      • 1問、約45分、合計90分

    • 午後Ⅱ

      • 1/2問を回答。
      • 1問、約120分。

    • ツボ

      • 先ずは、問題を確認。
      • 次に、設問を重点的に確認。
      • 穴埋め式問題があったら回答できそうな箇所か確認する。
        ・穴埋めは正解 or 不正解なので部分点がもらえない。

移行メモ

  • 元 Wiki で見出しそのものが他ページ・同ページ内へのリンクになっていた箇所は、 GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の本文に置いた。
  • PukiWiki のページ内アンカ（#xxxxxxxx）は GitHub Wiki では再現できないため、 同一ページ内のアンカは見出しから生成されるアンカに張り替え、 他ページのアンカを指すリンクは「〜（ページ名 の該当節を参照）」の形に置き換えた。
  • 「午後Ⅰ」「午後Ⅱ」の下に同じ年度・季節の見出しが並び GitHub Wiki では アンカが衝突するため、年度は午後Ⅱ側に「（午後Ⅱ）」を付し、 季節は「秋（午後Ⅰ・平成31年）」のように区分と年度を補って一意にした。 内容が無く「...」だけだった見出しも、対象年度を補って一意にした。
  • 「問に適切に対応する系」から「理詰め系」へのリンクは、元 Wiki 側に存在しない ページ内アンカを指していたため、「理詰め系（理系）」に張り替えた。
  • 元 Wiki の行頭空白によるコード・設定例は、フェンス付きコードブロックにした。
  • 元 Wiki の赤字強調は太字にした。
  • マイクロソフト系技術情報 Wiki（techinfoofmicrosofttech.osscons.jp）への URL リンクは、移行済みのページへのリンクに張り替えた。
  • 元 Wiki の「エンベロープFrom書き換えないと」→「エンベロープFromを書き換えないと」、 「改ざんれないよう」→「改ざんされないよう」、「ディテイール」→「ディテール」、 「DEPが聞いている」→「DEPが効いている」、「モヤモヤが感ある」→「モヤモヤ感がある」、 「じゃくて」→「じゃなくて」、「クラアント認証」→「クライアント認証」、 「テストフェース」→「テストフェーズ」、「WPA-PKS」→「WPA-PSK」、 「フィードバッグ」→「フィードバック」、「攻撃社」→「攻撃者」、 「日経xTEXH」→「日経xTECH」に正した。

Tags: 移行, 資格, SC, 情報処理安全確保支援士, 午後Ⅰ, 午後Ⅱ, 過去問, 国語問題, 専門性, 引掛

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

⚠️ **GitHub.com Fallback** ⚠️