H.21春
問1
設問1
図3では、DNS（p1.p2.p3.p4）からインターネット上（r1.r2.r3.r4)へのDNSクエリレスポンスが存在している。(V)で判るが、インターネット側から、インターネット上の(s1.s2.s3.s4)の名前解決問い合わせ受ける必要は無いので、これはDNS reflection攻撃と判る。
なお(IV)はA社のWebサーバの名前解決なので、正当なものである。(III)はA社のサブドメイン問い合わせに失敗しているか、A社以外の名前解決の問い合わせなのでやや怪しい。
修正箇所はインターネット側からの名前解決を受けない事であるが、Webサーバ,Mailサーバの名前解決は必要なので「A社ドメイン以外の」を回答文に入れる。
設問2
(1)(2)図4では感染端末(a1.a2.a3.a4)からインターネット上へMXレコードの問い合わせが発生している。MXレコードの問い合わせを社内端末が発する必要は無い。（メールサーバのみが行う）
(VII)はIPアドレス直接指定で外部との通信を行なう事は考えずらい。一般的には名前解決を用いる。またTCP/IPの3wayコネクション(SYN,SYN+ACK,ACK)の最初のSYNのみが発生して、それ以降の通信が発生していない。
設問3
(2)hostsファイルでウイルスパターンファイル配付ソフトのIPアドレスを127.0.0.1のループバック（自分自身）アドレスに書き換えられている。これにより、パターンファイル配付ソフト宛の通信先が自分自身になってしまい、パターンファイル更新が出来なくなる。結果、定期的に発生するパターンファイル更新の通信パケットが観測されなくなっている。
問2
設問1
図3にてWebサーバでOSのコマンドを実行できる脆弱性が指摘されている。この脆弱性があれば、DBへのアクセス、システムの停止は容易に行なえる。
Exploitコード（脆弱性実証コード）も公開されているので、試行も容易であり、攻撃は直ぐに始まると想定する必要がある。
設問2
(1)(2)
（HTML手打ちの時代は随分前なので、送信フィールドのHTMLがfrom,inputというのは忘却の彼方であった。getでデータを送信する問題点は富士通の以下のsiteが初心者向けに詳しく書いている。
http://www.fujitsu.com/jp/solutions/infrastructure/dynamic-infrastructure/sdas/technology/web-apl/01-http-protocol/
）
(3)X-Senderの文字列が含まれるgetが送られてきたら攻撃とIPSに判断させる
(4)そもそもhttpdやWebアプリを特権ユーザで稼動させてはいけない。実行できる事が限定されたユーザで稼動させるべき。
（昔のcgiの教科書とかは結構うるさく書いていましたね...）
設問3
(1)(2)負荷分散装置を使っていると有難い事は、分散先のサーバ群から保守対象を切り離して順次メンテナンス可能な事である。これにより利用者から見て無停止でメンテナンスができる。重要システムへいきなりパッチ適用はしないのが常識だが、試験問題では明示しない限り検証作業はしない事になっている点に留意する。
問3
設問1
(1)ログイン認証はcookieの文字列で行なっている。それも暗号化していない会員番号と前回のログイン年月日を使っている。これであれば、文字列を変えて順次試行すれば容易に突破可能である。
(2)図3はHTMLを出力するプログラムであるが、24行目はhttp、50行目はhhtpsで画像を出力している。この実装をすると、HTML中の一部要素がhttpになるためブラウザからは安全な接続と認識されない。
(3)プログラミング問題なのでパス
設問2
(1)透過型暗号化は、DBの中のデータのみを暗号化して、外部からは平文で扱える（透過的）というものである。よって、DBまでの通信経路、DBの暗号化機構直前までは一切暗号化されていない。DBの実データ部分が暗号化されているので、記録媒体の持ち出しには有効である。
(2)定番のハッシュ化とソルト付加の設問。
問4
設問1
(1)金融商品取引法は証券、銀行の店頭での商品購入等へ関連したものと思われがちだが、「上場企業」であればその企業の証券や債権格付けに影響する企業財務が正確である事も範囲に含んでいる。
(2)(3)IDの使いまわしは個人特定に支障がある。良く問われる設問。同じ特権IDでも個人の役割にってサーバAのみ付与、サーバABに付与と役割毎に制御する必要がある。
（個人的には設問の様な特権IDを作るというより、個人毎にIDを割当、IDへ必要な権限付与、という説明や思想が良いと思われる）
設問2
(1)unixの基本知識
(2)セキュリティの基本知識
(3)設問1(3)に同じ
(4)攻撃方法の基本知識
(5)H.24秋 問2に類似問題あり。￥
(6)設問1(1)(3)に同じ。完全な（改竄されてない）財務データを上場企業は公表する事が求められている。
H.21秋
問1
設問1
常識問題
設問2
(1)5.9(4)は②のリモートデータ消去機能を使える様に思えるが、本設問時に②は実施していないので、情報システム部に報告されても何も出来ない。
(2)携帯電話紛失時はメール送受信データだけではなく、電話帳周りの連絡先情報も流出する可能性がある。連絡先の確認はcc:でも良さそうだが、電話帳に登録しただけで送受信履歴がない相手の場合は流出の判定が難しい（電話帳を全部記憶している必要がある）ため回答例の様に、電話帳のバックアップが適切。
設問3
設問2(1)を参照
設問4
(1)(2)携帯電話にSSLクライアント証明書を導入して許可された端末か認証する。認証はA社DC設置のY社ポータルサーバが行う。ポータルサーバはLDAPへ問い合わせをする。この時、端末認証に確実に使えるのはSSLクライアント証明書のコモンネームである。表にも「電子証明書のコモンネームにはSIMカードを一意に識別できる」とある。Y社ポータルへアクセス後はメールサーバへアクセスするが、その際のID,パスワードはポータルサーバで連携し自動的に処理されるため、携帯電話自体のアクセスセキュリティが施されていないとメールへ容易にアクセス可能となってしまう。
(3)携帯電話-ポータル間はメール系のプロトコル（POP3,IMAP4）は使わず、ポータルがメールクライアントとしてA社DC設置のメールサーバへアクセスしている。そのため、メールクライアント-メールサーバ間はIMAP4で通信している。
(4)設問4は社内宛に届いたメールは携帯電話自身のメール機能を使わず、謂わばwebメールの形式でポータル経由で閲覧をするアーキテクチャである。携帯電話自身のメール機能は削除出来ないので、回答例の様に携帯電話のキャリアメールアドレスへメールを転送されてしまうと、端末紛失時の情報流出リスクが発生する。
問2
プログラミングを含むのでパス。
問3
問4
設問2
[管理状況の把握](2)を参照する。
設問3
ハードディスク暗号化はハードディスクが取り外された場合、単体で読み出し不可の特徴がある。しかし、OS起動後はOSや利用者からは暗号化を意識せず、平文として（透過的に）ファイルへアクセスできる。そのためOS起動後で操作を受け付ける状態で盗難に合うとファイル読み出しを防げない。
設問4
図1(ii)の利用形態からUSBメモリ経由で顧客に情報を渡す事を考慮する必要がある。この場合、顧客PCへ復号ソフトウエアを導入してもらうのは困難と思われるのでQ製品の自己復号型が望ましい。
（但し、これは自己実行のexe形式ファイルを渡した相手に実行させる事になる。これに慣れるとexeを警戒無く実行する癖がついてしまい、セキュリティ教育上著しく望ましくない。）
設問5
(1)これ意味不明。P製品は鍵メモリとNPCとがセット使用が必須なので、図2(i)の様な「同時に持ち歩く必要がなく」という前提が良く判りません。いろいろ見てみると、P製品は起動時には鍵メモリが必須なので安全、対してQ製品はTPMへ起動時パスワードを投入するので、パスワードが簡単だったりすると相対的に危険、という判断なのかと思います。
使用しないけど、NPCを運搬している、という前提なのか？
(2)USB型鍵メモリよりTPMの方が攻撃に強い点に留意する。TPMはパスワードを間違えると次回パスワード入力まで一定期間時間を空けることが必要なので、パスワード総当たり攻撃には強い、
(3)R製品はUSBメモリ暗号化が出来ないので除外。P製品、Q製品は前述(2)からQを選択。（？）
H.22春
問1
プログラミングを含むのでパス
問2
設問1
(1)図1を確認すると、TPMで秘密鍵、公開鍵を作成し、これでファイルを暗号化する共通鍵をさらに暗号化している。
よって、b.は公開鍵で暗号化されたものを復号するものなので秘密鍵となる。
設問2
(1)(2)図3では、営業所サーバへ個人データをコピーする際に復号され平文でテープへ格納される点に注目する。現在は媒体上のデータ暗号化も普及しているが、本設問では使用していないのでテープ紛失時は容易に読み取られてしまう。
設問3
(1)(2)ファイル暗号化をしている表(a)(c) はPC上のHDDは暗号化されているが、営業所サーバ上へ平文でバックアップが取られている。一方(b)はS/MIMEであり、PC上のHDD、営業所サーバ両方共に暗号化されている。S/MIMEの秘密鍵がPCのTPMに格納されているので(b)はTPM交換後復号出来なくなる。
(3)TPMの仕様上、秘密鍵は読み出しが出来ない。よって、TPMで鍵生成して秘密鍵をバックアップという手順が取れない。
鍵ペアをTPM外で作成し、秘密鍵のみをTPMに保存する必要がある、
問3
設問1
(1) a.は「S/MIME証明書」が最適で一般的な「ディジタル証明書」「公開鍵証明書」は次点かも？
(2)所謂「オレオレ証明書」の諸問題。自己証明書では発行体が本当に正しいのか誰も証明してくれない。
(3)PGPフィンガープリントはwebやメールに記載しても良いのだが、それが改竄されていないのは100%確定出来ない。類似事例として、Webからのダウンロード時にハッシュ値が記載されている場合も多いが、ダウンロード対象ファイルとWebコンテンツの両方を改竄されてしまうと無力である。よって、ネットワークを使わない他の方法でフィンガープリントを入手すれば、より確実である。
(4)典型的なブルートフォース攻撃とその対策方法を回答すればよい。
設問2
(1)実在する求人企業の社員を名乗って申し込みされた場合を想定する。実在する企業と異なる住所、メールアドレスで申し込まれる可能性を考慮して、登記簿の住所、「責任者宛」へ郵送とすれば前述の様な不正申込を防げる。
(2)複数のIDとパスワードとの組み合わせを比較するとパスワード生成のルールが判る。設問では3名の初期パスワードを見た、とあるので、これに該当する。（他人の初期パスワードを見る責任者も如何なものかと思うが）
(3)(4) (3)の様にパスワード再設定前に他社に盗聴されても、さらに1種類の鍵（初期パスワード）が無いと再設定が出来ないシステムとする。（但し、この様な事象では初期パスワードも失念していることが多々あるので、運用は楽にならない）
問4
設問1
設問に回答が書いてある珍しい例？
設問2
TCP/IP通信の特性と図4の「L2SWにはモニタポートは付いてない」の記述に留意する。
TCP/IP通信にはMACアドレスとIPアドレスとが必要となる。同一セグメントのPCへ感染するには、各PCのMACアドレス入手が必要となりブロードキャスト通信でARPを発行する。モニタポート（ミラーリングポート）であればブロードキャスト以外の通信も見えるが、通常のポートはブロードキャスト通信しか見えない。本設問ではa.にTCPパケットと書きたくなるが、ブロードキャスト通信を観察している点に留意して回答する。
設問3
Xウイルスを削除しても、OSセキュリティホールは残存しているので再感染の可能性がある。
設問4
(1)所謂「検疫ネットワーク」の簡易版を作ってパッチ適用を行なう。
(2)図3 感染方法2を見ると、脆弱性を突くのではなく1000種類の用意済パスワードを用いるとあるので、複雑なパスワードへ変更すれば感染を防止できる。
H.22秋
問1
設問2
(1)指摘1の（ウ）は「Webサーバ自身」ではなく、「Webサーバにおける、【ディレクトリに対する】アクセス制御」となっている。案1はWebサーバが各社専用Webサーバ、案2は共用Webサーバとなっている。そのため、共用Webサーバ内のディレクトリに対して各社別の権限を付与する必要がある。
(2)当たり前過ぎるが、「他ベンダの専用ディレクトリ」「保守担当者」の組み合わせ。もしくは「各SIベンダの専用ディレクトリ」「他のSIベンダの保守担当者」。模範解答は後者。
設問3
(1)監査問題。ログと作業指示書とを突合する。本設問では「Webサーバの通信ログ」（表より）「作業報告書」（図3より）とを突合する。
(2)図3で「運用管理者が1IDを共有」「SIベンダ毎に1ID」の記述がある。一方作業報告書では個人名レベルの粒度で管理をしている。あるべき論から言っても、利用者IDはグループで共有せず、個人毎に設定するのが望ましい。
(3)日時、利用者ID、ファイル名が回答例であるが、利用者IDやパスワードは盗難可能なので「通信元IPアドレス」も追加するのが望ましいだろう。監査視点では回答例で良い。
設問4
（ア）はSSL証明書をPCに入れるため、「ソフトウエア等を勝手に導入してはいけない」というポリシーがあった場合抵触する。（イ）はWebアクセスやWebからのダウンロードを許可しないポリシーがあった場合抵触する。これらはセキュリティポリシーでも良く見かけるので、案2の運用が取れるかを各SIベンダへ確認する必要がある。
問2
設問1
(1)(2)(3)頭の体操
設問2
(1)(2)(3)第一案は契約終了後はアカウントが100日後に自動的に無効になるので、それを削除すればよいだろう、というもの。第二案は契約終了日を契約書基づき入力しておき、それを基準に削除する、というもの。p.11で契約が自動継続されないこと、厳格に管理されていることを鑑みると、案2が適切である。また、厳密に管理する契約管理部門からの通知を基にUIDを削除すれば確実である。
設問3
[従業員のUID管理]（エ）を参照のこと。典型的なソーシャル・エンジニアリング（クラッキング）の手法。
設問4
仮パスワードの送付先を本人に確実に、かつ他者に間違って届かない手法を考えれば良い。
問3
webプログラミングを含むのでパス
問4
設問1
a.では「検疫システム」の文字に注目する。所謂、社内LAN接続前にOSセキュリティパッチ、ウイルスパターンファイルが最新かを検疫システムで確認後、接続するというもの。
設問2
(2)p.20に「インターネットへ向けたFTPアクセスは、プロキシサーバに限定」の記述がある。また、FTP専用PC以外からはFTPを禁止したいとあるので、PCを固定IPアドレスとして端末識別するか、プロキシサーバで利用者認証をすれば良い。
設問3
(2)感染は「不正プログラム送り込みサイトへリダイレクトされる」「不正プログラムをダウンロードさせられる」「感染したPCでFTPアクセスしているWebを不正プログラム送り込みサイトに書き換えさせられる」が連鎖して起きる。当初は「送り込みサイト」がブラックリストに登録されて気付くが、これが書き換えられた元正規サイトであった場合はURLフィルタで気付かなくなってしまう。
H.23春
問1
プログラミングを含むのでパス
問2
簡単
問3
設問1
(1)定番問題。PC,HDDの盗難には暗号化と覚える。
(2)リスク回避（リスクテイクを諦める。他の方法を取る）、低減（リスク対策する）の使い分け。自社レビューでも「低減」の意味で「回避」を使う人が多いから要注意。
設問2
自社の持ち出しPC規則に同じ。
設問3
(1)PC盗難時はPCの全データ、PCからアクセス可能な社内システムにアクセスされると考える。本問は所謂モバイル環境の有無に触れられていないので、前者のみと回答が必要と思われる。
(2)公開している期間を必要最小限に、という原則。良くあるzip復号パスワード入力は短時間でパスワード総当りにより簡単にクラックされてしまうので、気休め程度にしかならない。
(3)送付内容の複数回チェック。
設問4
簡単過ぎて逆に不安なのだが、表3 （イ）と「E社における左記対策の実施状況」の交差部分を参照のこと。
問4
難易度は低いが、N社、R社の役割を理解しておかないと回答に迷う問題である。
設問1
(4)
FWでWebサーバからインターネットへftp,sftp,scpを拒否設定。定期的にFWのドロップ（拒否）がログにあるかを確認するという趣旨。N社はコンテンツ作成だけなので、httpサーバログを見たりはしないから、前述の拒否設定をしても管理上問題が無い。
(5)(6)
図2でスクリプトファイルに対してRWX権限付与をしている点に注目する。これであれば、会員データ出力スクリプトをアップロードし、実行すれば会員データを閲覧できる。
アカウントCNT-MGRはコンテンツ作成N社が使用する。RアプリのスクリプトはR社が開発するので、R社にスクリプト周りの権限は本来不要である。よってCNT-MGRからスクリプトRWX権限を削除して構わない。
設問2
IDを固定してパスワードを順次試行するのを「ブルートフォース攻撃」と称する。表1のV-1が相当する。
一方、IDを固定せずログイン試行するのを「リバースブルートフォース攻撃」と称する。他のwebサイトより盗んだID,パスワードを順次試行するのはこれに相当する。同一IPアドレスからIDを変化させて攻撃するので、同一IDアドレスでログイン失敗が連続するのを検知、遮断する対策を取る。
H.23秋
問1
問2
設問1
暗号化とハッシュ化とが回答選択肢に混在している。ハッシュ化を選択する。
設問2
プログラムロジック問題。落ち着いて考えれば解ける。
設問3
(1)(2)図1（オ）でサスペンドは利用責任者からの申請で解除するとある。しかしながら図4ではサスペンドに対する判定がないため、サスペンドでもパスワード初期化が可能である。
設問4,5
H.22春 問2と類似部分あり。
問3
設問1
(1)(2)https通信ではhttpリクエスト全体が暗号化されて通信する。p.14の「インターネットサイト向けに送信された内容」をログにすることは出来なくなる。そのため、ウイルスチェックも送受信内容が復号できないので不可能となる。
設問2
(1)(2)中間者攻撃（端末-中間攻撃者（代理応答）-Webサーバ）の設問。中間者攻撃を受けると、httpsの証明書は中間攻撃者のものになる。ブラウザ上でhttps通信となっていても、証明書が「Webサーバ」のものかを確認する必要がある。また、証明書が自己証明書でないこと（オレオレ証明書でもOKを押させる事を推奨するWebサイトが多いので、そういうものだ、と思っている人も多い）、信頼に足りる証明局から発行されている事も確認が必要。（建前としてCA局は信頼に値する前提だが、怪しい本人確認で証明書を発行してしまうCA局があるとか、無いとか）
設問3
(1)(2)(3)設問2と同様。図4ではLプロキシが設問2の中間者と同様の動きをするので、LプロキシのSSL証明書2のコモンネームは証明書1と同一としないと、Webブラウザで証明書を確認した時に、正しく「webサーバ」に接続出来ているか判らない。
問4
H.24春
問1
Webアプリケーション。セキュアプログラミング、セッション維持（パス）
問2
設問1
(1)(2)(3)どのアクセスが、どの様な攻撃かを判断する問題。
攻撃1は「会員ID」「パスワード」両方の全員分を窃取している部分に留意する。
ip毎の攻撃内容は以下の通り。
ipB
攻撃4
cust51に対して複数のパスワードを試行
ipD
SQLインジェクション。但しunion select対象はpwdのみ
ipE
リバースブルートフォース攻撃。異なるIDに対して、パスワード'password'でのログイン試行
ipF
SQLインジェクション。但しunion select対象はcust_idのみ
ipG
ディレクトリトラバーサル攻撃。'../ls'で上位ディレクトリのリスト出力を試行
ipJ
攻撃2
コンテンツの一部を'www.evil.example.com'へのリンクに書き換えて誘導する。
ipH
攻撃1
union selectでcust_id,pwd両方を対象としている。
ipI
攻撃3
コンテンツの一部をjavascriptによりdocument.writeのスクリプト実行に書き換えている。
設問2
(1)(2)暗号化の基礎知識を問うもの。g.は平文（本問ではパスワードの文字列）を入れてどのような暗号文が出力されるかを確認する。そしてアルゴリズムを推測する方法である。
よって、このシステムに格納された暗号化済みパスワードは平文が攻撃者に判ってしまったと考えて行動する必要がある。p.10の②はそれを踏まえて、何をするべきかを問うもの。パスワードを使いまわしている場合、他のサイトのパスワードが判ってしまったということなので、他のサイトのパスワードを変更する必要がある。
設問3
(1)回答例は「プラグイン」である。「レンダラー」も良さそうだが設問で「ブラウザ本体への攻撃は実施されない」とあるので、「プラグイン」が正しい。
(2)設問1を参照。
問3
案1, 案2のサーバログ取得方法を図にすると理解し易い。
設問1
(1)(2)ログをハッシュ関数に入れてハッシュ値を取得。ログが改竄された後、再度ハッシュ値を取得すると元のハッシュ値と異なるため改竄が判明する。SHA-1はセキュリティ脆弱性が発見されているので、SHA-256（SHA-2に含まれる）の使用が望ましい。
設問2
各モジュールの配置と通信とを問う。
(1)エージェントモジュールは無害で他システムへ影響しない前提であるが、実環境で検証後、運用が必要。
(2)保守担当者（Z社）は中継サーバ経由で保険サーバへアクセスに変更する。そのため、保険サーバの通信可否を見直す必要がある。
設問3
(1)(2)保険サーバからログサーバへの通信を妨害にするには、保険サーバのネットワークセグメントを変更、またエージェントモジュール自体を停止してしまえば良い。通信不可時には保険サーバのローカルディスクにログを一時保管するが、このログを削除してしまえば、ログ記録と、ログ内容から検出するファイル操作の警告もなされない事になる。
(3)表1 一番下の「機密ファイルへアクセスした場合（中略）メールアドレス宛に電子メールを送信」機能を用いる。ネットワーク設定「ファイル｣、エージェントモジュールの設定「ファイル」等への変更を監視すると実現できる。（筈、ちょっと弱い気がするが...）
設問4
(1)当たり前過ぎて気付かなかった....。
(2)表1 案2(d)に「中継サーバの利用IDごとに（後略）」の記述があるので、この機能を利用する。
問4
設問1
所謂フィッシングメール。②は正直、偽装してもウイルス対策ソフトでウイルスのコード本体のパターンマッチングをして検出されてしまう気もするが....。
設問2
図4、各プログラムが使用するTCPポートをパケットキャプチャで絞っていく。
設問3
HDDを取り外して、当該HDDで起動しなければウイルスは活動できない。このHDDを正常なPCへ接続してファイルを取り出す。（ファイルシステムにアクセスしただけでウイルス感染しない、という前提になっていると思われる。そういうウイルスはあるんですかね？）
設問4
どの時点の対策を問うのか、今一つ判りづらいが...。フィッシングメールかを送信者へ確認する。
それ以外には、以下を設定、操作手順とする。
1)ファイル拡張子を表示
2)拡張子がexeなどの実行形式のものは開かない
3)文書形式のものはマクロ実行を禁止後開く
H.24秋
問1
Webアプリ&マッシュアップサービス（パス）
問2
設問1
(1)監視閾値を定めるにはどの程度が正常な業務なのかを利用部門に確認する必要がある。
(2)表1 注記1から、個人情報アクセスは機能番号8000番台である。表1 中から、無権限者はメニューに表示された8000番台へアクセスすると、利用は出来ないがログに記録されると判る。
(3)利用者IDが登録されていない場合は、端末を貸与された従業員以外が端末を利用してログイン試行したと考えられる。
設問2
(1)ログ取得の目的は抑止効果と事後の調査が可能となる、の2点。
(2)(3)監視閾値を公開すると、閾値以内で不正を行えば、検知されないようにできる。
(4)異常と看做す閾値を50回とするが、別途急激な増加をしている利用者を検知したいという条件になっている。（とは言え、急なキャンペーンだと、最初の1回目のピークは通知されてしまう）
設問3
監査のPDCAサイクルを意識する。業務形態は常に変化するので現在の閾値が妥当であるかを定期的に見直す。
問3
設問1
ア
各サーバの時間帯を見ると、3番目のReceivedはCET（中央ヨーロッパ時間）で表示されている。適切ではないが、ミスもありえる。
イ
Receivedの経路は全て繋がっている
ウ
DNSで名前解決をしない設定となっていると、この様な結果となる（DNSで名前解決出来ないと怪しいsmtpと看做す判定もあるので、設定が望ましい）
エ
アドレスはグローバル、ローカル共に図3でどちらを使用しているか判別できない。
設問2
(1)SMTPのコマンドなので普段馴染みがない。覚えましょう。
(2)SPFのTXTレコードで+ip4:の部分は「送信元SMTPサーバのIPアドレスはxxxです」を意味する。よってxxxから送信されたメールであれば正当である、という判断ができるようになっている。
Z社はDMZに外部メールサーバMX1を配置しているので、MX1はグローバルIPアドレスを割当てていると通常考えるが、図2文末に「社内とインターネットとの間の通信には、グローバルIPアドレスx.y.z.1をNATアドレス」とある。判りづらいが前述の「社内」とは「社内LAN」ではなく、DMZを含むZ社の社内という意味でインターネットからDMZへ入ってくるとNATされてSMTPサーバはx.y.z.1とインターネット側からは見える。
設問3
(1)HTMLメールでは
http://canon.jp/の様な騙しリンクを作れる。そもそもメーラは原則HTMLメールを表示するべきではないし、送信側もHTMLメールを送るべきではない。HTMLメールのハイパーリンクは画面上の表示と実際のリンク先とが同一であると思ってはいけない。
(2)社内に侵入された後の対策となるので異なるセグメント間の通信を制御ファイアウオールでは防御できない。
(3)(4)バックドア通信がインターネット向けに行なわれても、FWで拒否される。しかしながら、http通信としてバックドア通信を行なわれた場合、PRX経由で外部へ通信可能なので、防御できない。
これはPRXの通信先が妥当なものかを判断して通信可否を制御する。（回答はURLフィルタリングでも良さそうである）
問4
設問1
業務ピーク以外で計算機資源が大量消費されているのは、何らかの異常を示唆している。
設問2
(1)(2)(3)脆弱性はCPUリソースが枯渇するとあるので、図3のピークを確認する。表2,表3,表4の同時刻帯にLBのdown,upが、またFW1で△△,123,123,123から送信バイト数が多い通信が発生している。表5,表6を参照すると、ステータスコード500となっているものがある。一般的にステータスコード200は正常通信なので、500(Internal Server Error)が怪しいと判る。
設問3
(1)LBのSSLアクセラレータ機能の理解を問う問題。（d.の回答が秘密鍵というのは一寸参った）
(2)[インシデントの発生]で記述しているように、アクセス数増加に伴う最大同時セッション数が不足している。これが不要なイベント通知の発生原因となっている。
(3)図2 (7)に「LBはX-Forwarded-Forヘッダフィールドは利用していない」旨記述している。これを設定していないため、表5,6のLBの送信元IPアドレスだけがログとして取得されている。XFFを設定すると、HTTP通信元のIPアドレスが下流であるWebサーバ群へ付加して送信されるため、Webサーバのログに本来の通信元IPアドレスが記録される。設問では「攻撃元を特定しやすくする」「FW1とWebサーバ群のログを関連付ける」の表記があるので、これを利用する。
H.25春
問1
設問1
(1)(2)ML4の侵入経路はML2,ML3が候補となる。ML2はプロキシ経由でWebサーバ、ML3は直接Webサーバへの通信を試行する。J社のhttp通信はプロキシ経由としているのでML2が正解。ML3はインターネット上のWebサーバへの通信を試行するため、FWに通信失敗ログが残る。
設問2
(1)[マルウエア解析後の暫定対策]ではDMZの全サーバ、OA-LANの残PC、RD-LANのPC、RDサーバを検査するとある。マルウエアが保存される可能性のある全サーバ&PCのHDDを検査して記録媒体として残るものはRD-LANとの情報交換に用いるUSBメモリとなる。
(2)SC試験の定番。マルウエアの通信先をプロキシ、ファイアウオールで遮断すればよい。また、プロキシで認証を行う方法も考えられるが、マルウエアに認証情報を読み出されている可能性もあるので、前者が望ましい。
(3)表2 ML2の特徴を見るとZブラウザの脆弱性を攻撃するとある。問題文p.3で脆弱性のあるver.2以外にver.3が存在している事がわかるので、ver.3へ更新をする。
設問3
(1)表2 マルウエアの共通する特徴を参照する。新しいファイルがあると「最近追加変更されたファイルの検索」で発見されてしまうので、タイムスタンプを書き換えして発見されにくくする。パック処理でウイルス対策ソフトの単純なバイナリ、コード検索から逃れられる。
(2)(3)ML5はUSBメモリ経由で感染するもの。攻撃者はMLから得た情報で社内にRD-LANの隔離されたネットワークが存在する事を知り、USBメモリ経由での攻撃を検討したと考えられる。
問2
設問1
(1)DNS,TCP,UDPの基本知識を問うもの
(2)CP攻撃はDNSの問い合わせパケットに対して、偽装した応答パケットを送りつけるもの。問い合わせ時のポート（=応答を受け取るポート）をランダムに変更すると、偽装した応答パケットを受信してしまう確率を下げられる。
(3)B-DNSはDNSコンテンツサーバであり、外部からA社のサービス（例えばhttp://a-sha.co.jp/のIPアドレス）に対する名前解決のみ、行なう。リゾルバ、DNSキャッシュ機能は提供しないとある。リゾルバ、DNSキャッシュ機能はC-DNSが受け持つため、外部へメールを送信する際はC-DNSがリゾルバとして名前解決を行なう
(4)項番3,5,7を見るとIF-2,3,4は接続している送信元のみからの通信を許可し、それ以外を拒否している。IF-1は記載ルールが異なるが、インターネット側からの通信を許可し、それ以外を拒否する設定とするのが正しいが、DMZ2からの通信が拒否設定していない。
(5)CP攻撃でSPFのTXTレコードが汚染されると、汚染したTXTレコードに記載されているSMTPサーバのIPアドレスを正当なものと判断し、そこから送出されたメールを受け取ってしまう。
設問2
(1)(2)C-DNSはIF-1からの名前解決を依頼される事はない。設問1(2)も参照。しかし、支社LANをB社基幹ネットワーク経由で接続すると、支社からの通信はIF-1から入ってくる。支社へPXYを設置すると名前解決のため本社C-DNSへIF-1経由アクセスする必要が発生する。これは正当な通信で許可する必要がある。
すると、支社PXYを送信元としてインターネット側から送出されたパケットと区別がつかなくなってしまう。そのため、本社と同様に支社DMZにリゾルバ、DNSキャッシュを設置する必要がある。
問3
設問1
微妙な設問だが、支店に共通端末があるから社外持ち出しPCで作業しなくても済む、よって情報流出リスクが下がる、という事かと思われる。
設問2
(1)(2)端末紛失時を考慮すると「HDD暗号化」「端末にデータを保存しない」の2種類が考えられる。表2 案2（ウ）で「（業務データ）の保存を制限」の項目があるので、b.は残る「HDD暗号化」となる。
(3)図1 (d)(e)(h)(i)を参照のこと。特に(i)のログオフしないと使用中の複製V-PCが維持される点に留意する。
設問3
図1 (g)を参照のこと。
設問4
(1)図5 (ii)(iii)を参照のこと。
(2)業務システムをVDI経由で使用するのであれば、端末から直接業務システムへ通信で接続する必要は無い。
問4
設問1
基礎知識
設問2
Digital Forensicsなので「デジタル・フォレンシクス」が正しい発音で「フォレンジクス」と濁るのは本当は誤り。
設問3
(1)情報が届き次第遅滞無く、と書きそうだが、アクセス禁止にするのは契約が終了する終業時刻になってから。
(2)インターネット直結の社外持ち出し用PCであれば、インターネットのサービス全てにアクセス可能であり、L社の社内システムでは制御できない。速度は遅くなるが、一旦社内へVPNで接続し、折り返してインターネットへ出る方式とすれば社内のFW、URLフィルタ等を適用出来る。
設問4
設問1と同様。（自社で当たり前の様に実施していると意外に気付かない）
H.25秋
問1
Webアプリケーション開発のXSS脆弱性問題（パス）
問2
設問1
(1)IMEIは端末で表示できるし、設問のシステム以外でも収集されている。パスワードの様な秘密情報ではない。回答では考慮していない様だが、Android端末では書き換えも可能であろう。
(2)(3)IMEIをハッシュ化して送信すればIMEIをそのまま送信するより安全だろうか？という趣旨だが、ハッシュ化キーをリバースエンジニアリングで突き止めれば、成りすましは可能。ハッシュ化でメッセージダイジェストを送信する方式をHMACという。H.26春でも出題しているが、午前2では出題されていない。
設問2
「電話帳データ全員分」という個人情報の不必要な取得と、その対応を問うもの。必要な個人情報のみを収集するということなのだろうが、（送信に必要な分を）「 APで選択して送信する」という当たり前すぎる回答は逆に思いつかなかった。
設問3
表2 のアプリケーション設計の問題を問うもの。良く判らないのだが、DateTimeを変更せずYoyakuCodeだけ変更しても当該の予約明細コードの予約を表示できそうな気もするが...。
問3
設問1
図2 (1),(2)を見ると管理責任者は利用者が指定した携帯電話メールアドレスを確認せずCサービスに登録してしまう。第三者が実在する利用者の名前、第三者の携帯電話メールアドレスで申請メールを出すと、第三者の携帯電話メールアドレスに仮パスワードが送られてくる。
設問2
個人の携帯電話が盗まれ、かつ利用者ID、パスワードが漏洩している前提で、図3を確認してみる。攻撃者は盗んだ携帯、利用者ID、パスワードの3点でワンタイムパスワードを入手する(3)。その後、ログインし有効期限90日のクッキーを受け取る(6)。次回からはクッキーのみでログインできる(2)ため、90日間はパスワードを変更しても不正使用が可能となる。
（そもそも、このようなログイン方式が脆弱なのである。最低でも重要なデータの表示、トランザクションの前にパスワード認証を行なう構造とするべきである。回答では携帯電話が盗難されたら電話を停止して、パスワードを変更するとしているが、十分な対策とは思えない）
設問3
BCPと不測のクラウドサービス終了の対応。クラウドだから安心、というと痛い目にあうので代替手段の検討は必要である。
H26.春
問1
Webアプリケーション開発（パス）
問2
設問1
(1)unixの基本
(2)SPF記述の基本。文頭から評価されるので、図3では、SMTPサーバはx1.y1.z1.4のIPアドレス、（それ以外は）全てSMTPサーバのIPアドレスではない、という設定。
設問2
図3のMXレコードを見ると、SMTPはmsv1.a-sha.co.cjp、msv2.a-sha.co.jpの2サーバが指定されている。優先順位はmsv1が高いため、通常はmsv1（迷惑メール対策装置）へ送られ、msv1が停止していると次のmsv2（外部メールサーバ）へ送られる。
この構造の場合msv2を直接指定してメールを送ると受け取ってしまう。
設問3
(1)通常SMTPサーバ等のグローバルIPアドレスは変更しないものだが、プロバイダ変更等で異なるグローバルIPアドレスが割当てられる可能性がある。DNSコンテンツサーバで解決先IPアドレスを新しいものに変更すれば外部からの接続には問題ないのだが、IPアドレスでのWL,BLでは影響がある。
(2)迷惑メール業者自身でドメインの取得とSMTPサーバ立ち上げ、MXレコードにSPFを記述されたらSPFでの対策は無力だ。
(3)ドメインBLはなるべく色々な情報を元に、という趣旨。アクセス先webとして許可できるが、メールの送信元として許可できない相手先、というのは存在しない。両方とも許可できるか、拒否、のどちらかである。
設問4
（正直問題と回答とが良くない。確かに迷惑メール対策装置が正常であれば、MXレコードの指定先をmsv1だけにしても良いだろうが、実運用でありえるのだろうか？
LBが冗長化されていれば、SMTPをLBで受け、MXレコード宛先をLBとする。外部からはmsv1,msv2は見せない。LBからmsv1優先、msv2次候補として負荷分散設定するのが良さそうだが...。）
問3
設問1
(1)(2)フィッシングの基本知識。法人向けサービスではクライアント証明書による認証も行なうため、セキュリティが厳しい。
（乱数表カードを加えたログイン認証が多いが、私見では振込等の重要なトランザクション時に限って乱数表を使わせた方が安全な気がする。ログイン毎に入力するとそれだけ盗聴の危険も増す）
設問2
(1)(2)中間者攻撃とSSLに関する知識を問う。SSLでは証明書を確認すれば、x-bank.jpに接続されているかブラウザ上で確認できる。（スマートフォン向けサイト等でURL部分を隠したり、ポップアップでウインドを開くものを見掛けるが、デザイン優先でユーザの安全性を損なう実装である。でも、ブラウザで警告してくるのか？）
設問3
(1)(2)(3)HMACツールは簡易的なクライアント証明書として機能する、という事なのだろうか？
H.26秋
問1
プログラム開発におけるメモリ管理、スタックオーバーフローの知識が必要（パス）
問2
設問1
(1)(2)暗号化方式と名称の基本知識を問う。AESアルゴリズムは共通鍵暗号である。表2から256ビット安全性と判るので、RSA（素因数分解）、ハッシュ関数でそれぞれ鍵ビット数を求める。
(3)表2とシステム要件から、必要なビット安全性を求める。
設問2
公開鍵暗号方式の基本知識を問う。
設問3
問3
設問1
(1)(2)p.15のSaaS型クラウド、サービスXのメール周りの動作を理解する。
設問2
(1)(2)(3)利用者セグメントからインターネットへは直接接続できず、プロキシサーバ経由となる点に留意する。また顧客管理のSaaSへは特定ポートを指定した接続が必要なので、これをプロキシサーバで許可する必要がある。（表4）
設問3
(1)設問がわかりづらいが、図1 開発サーバセグメントに開発専用PCを配置して、開発は当該セグメントで閉じた環境で行なう。
(2)色々考えられるので、設問が良くない気がする。
設問4
(1)可能なパスワード数の計算。問題文に「14文字までのパスワード」と書いている点に留意する。
(2)ソルト（パスワードに塩を振りかけ味を微妙に変えるように、入力されたパスワードにランダムな文字列を加えてパスワードを内部で長くする）を付加すると、ソルトによって出力されるハッシュ値が異なる。
H.27春
問1
Webアプリケーションのセッション維持に関する問題。cookie周りの知識必要（パス）
問2
設問1
(1)(2)L社のネットワークにDMZは存在するが、DMZはローカルIPアドレスを配賦し、FWのNAPT（Linux用語ではIPマスカレード）でグローバルIPアドレスへ変換して通信している点に留意する。
設問2
(1)IPA特有の「DNSは最小限の名前解決しかさせない」ルールが適用されている。
一般的な企業であればPCのDNS参照先は内部DNS、内部DNSは社内の名前解決&DNSフォワーダ設定で外部DNSを指定、外部DNSがDMZ&インターネット上の名前解決、という構造を取る。
しかしながら、本設問では内部DNSはL社内の名前解決しかしない。明示していないが「フォワーダ設定はしていない」と考えられる。
この設定であれば、マルウエアからC&Cサーバ向けの通信は内部DNSはC&Cサーバの名前解決で失敗して終了する。
なおmail、webの名前解決はメールサーバ、プロキシサーバが外部DNSで名前解決できれば運用できるので、PCからインターネット上のドメインを名前解決出来なくても、問題は無い。
類似の考え方をする問題がSC PM2 H.26春 問2 設問5(3)(4)に出ているので参照されたし。
（確かに問題文からは上記の通り解釈できるのでしょうが、一般的な企業でも上述の設定をしているところ、多いのでしょうかね？）
(2)FWはUTM型ではないので、特定URLへの接続禁止はプロキシサーバで設定する。
設問3
(1)
(2)
(3)サーバ自身のログは改竄されている可能性がある。別途syslogで飛ばして保管されているログ管理サーバのものを照合する。
問3
設問1
ハッシュ値が漏洩した場合、選択平文攻撃でパスワード解読が可能となる。選択平文攻撃とは、大量の平文を暗号化モジュールに入れて、ハッシュ値が同値となったものを平文として選択する。しかし、ソルトを付加して暗号化モジュールに入れるパスワードを長くして変化させると、ハッシュ値も異なるものになるので、選択平文攻撃が通用しづらくなる。
設問2
(1)SHA-256の'256'bitが出力されるハッシュ値の長さ。bit表示なので回答はbyteに変換すること。
(2)リバースブルートフォース攻撃では同一IPアドレスからIDを変更してログイン試行を行なうので、同一IPアドレスからの大量のログイン失敗を検知する。
(3)接続元を分散してログイン試行された場合は、通常のログイン失敗と判定がしずらい。急激に利用者が増加（≒ログイン失敗数も比例して増加）する事は考えずらいので、（ウ）の様に対策する。
設問3
設定可能なパスワード数を求める問題。文字数が1-8文字の様な問題だとsigmaを使う必要があるが、本設問はパスワード長が固定なので、x^yで求められる。
設問4
同一のID,パスワードを使いまわすと流出時のリスクが大きい。
H.27秋
問1
Webアプリケーションの脆弱性とWAFによる対策問題。正規表現の知識必要（パス）
問2
H.24春 問3の類似問題
問3
設問1
ログイン時刻とアクセス元から推測する。
設問2
(1)(2)表5から推測されるクラック手順
1
testというディレクトリがあるかを確認したが404でディレクトリが無いと判った
2
demoというディレクトリがあるかを確認したが404でディレクトリが無いと判った
3-10
/manager/以下の管理画面へのログインを試行するが401で失敗する
11
/manager/以下の管理画面へのログインが200で成功する
12
/manager/以下の管理画面での操作
13
管理画面から攻撃ツールをアップロード
14
/demoの攻撃ツールへアクセス
15-23
攻撃ツールを用いて、/Temp/Printer以下にファイルを作成等
設問3
(1)DMZから内部LANへの通信を制御しているものを探す。
(2)表6 項番5は運用端末のアクセス制御であるが、図2の許可する操作よりアクセス制御が緩い。
設問4
(a)ローカルホストからのみ接続を許可するため、設定は当該端末から物理コンソールを用いる運用とする
(b)p.17 A氏の発言参照
H.28春
問1
WebアプリケーションのXSS脆弱性問題（パス）
問2
設問1
外部メールサーバに要求される対策。オープンリレーでspam踏み台にならない様に。spfでspamを受信拒否。
設問2
外部に公開しているDNSサーバはリゾルバ、キャッシュ機能は使わない。コンテンツ機能（自社のwebやsmtpに関する名前解決のみ）のみ動かす。
設問3
(1)(2)DNSポイズニングと対策。不正なDNS応答を受け取らないために問い合わせポートをランダムに変更する。DNSが汚染されると、異なるサーバへ名前解決してしまう。
(3)https通信では通信内容が暗号化されている。通信相手は判るが、パス名といった通信内容は暗号化されて判らなくなる。
設問4
複合機からの通知メールを偽装された場合の対処方法を考える。複合機は社内にあるので、社外からメールが届く筈はない。社外からのメールであれば、メールエンベロープが複合機のものになる事はない。しかし、メールヘッダは自由に設定できるので、複合機のものに設定できる。このメールを拒否すれば良い。
問3
設問1
DNSの初歩
設問2
(1)所謂「オレオレ証明書」を用いたときの挙動を理解する。
(2)無線LANはSSIDを初めとする認証要素が一緒であれば自動接続してしまう。
（でも、明示的に指示するまでAPへ接続しない設定って出来ないのかな？出来る気がするけど）
11月 21, 2024
