情報処理安全確保支援士試験の問題を解いて、セキュリティインシデントの事例を他山の石として学ぼう

はじめに

@e-ronny と申します。食べログでセキュリティとかテストとかやっています。

実は、私自身セキュリティ領域に携わるようになったのが割と最近で、どのようにセキュリティ領域に対するインプットを進めるのか試行錯誤していました。
その中で、「情報処理安全確保支援士試験¹ の過去問を解いてみる」というアプローチによって学びが多かったので、私と同じように情報セキュリティ領域のインプットに悩んでいる方に向けて「賢く」学ぶ方法をご紹介します。

情報セキュリティ領域のインプットの一つの切り口として、「セキュリティインシデントの事例を他山の石として学ぶ」という方法があると思いますが、情報処理安全確保支援士試験を解くことによってもこれと類似したインプットができます。

この記事では、具体的な過去問を引用しつつ、情報処理安全確保支援士試験を通じて情報セキュリティ領域について学ぶにあたり工夫した点を紹介していきます。

過去問事例集

その1: パスワード失念時の本人確認・メール送信先確認が不十分で容易になりすまされてしまう

出典: 令和2年度 10月 情報処理安全確保支援士試験 午後Ⅱ 問1(問題・解答)

問題文のポイント

この問題で提示されたシステムでは、パスワード失念時の操作画面を用意しています。

このシステムの不備を突かれて不正にログインされるというインシデントが発生し、その原因調査を経てシステムに対する問題点が指摘されています。

• インシデントの内容

• インシデントの発生原因とそれを可能にしたシステムの問題点の指摘

問題文中でL課長が指摘している通り、このシステムにはだいぶ問題があります。
設問としては、本文中の j および k に入れる適切な内容を記述させるものになります。

工夫したポイント

この設問に対する解答例は以下のようになっています。

L課長の指摘しているこのシステムの問題は以下の3つです。

• 一つ目の問題: 本人であることを確認するための情報が少なすぎる
• 二つ目の問題: パスワードそのものをメールで送る
• 三つ目の問題: パスワードリセットの URL を、登録済みメールアドレスだけに送る

現実にも、上記の問題を持ったシステムによる事例が発生しています。

• 一つ目の問題に相当

生年月日をパスワードにするよう指定　子育て支援サイトが話題　パスに認証以外の役割があった
https://www.itmedia.co.jp/news/articles/2111/25/news174.html

• 一つ目・三つ目の問題に相当(会員登録時の本人確認が不十分という別の問題も指摘されている)

それぞれの問題を元に、パスワード失念時の操作画面について設計・レビューをする際に考慮すべき内容を考えてみます。

一つ目の問題: 本人であることを確認するための情報が少なすぎる

この問題に対しては、「 (失念されている)パスワード以外の何の情報をもって本人であることを確認するか？」ということを考える必要があります。

少なくとも、生年月日では取りうる値のバリエーションが少なすぎて総当たり攻撃の難易度が下がってしまいます。
7pay のケースでは、会員登録時に生年月日を指定しなかった場合には自動的に指定の年月日で設定されていたとのことで、これでは更に攻撃の成功率が上がってしまいます。
この問題文には出てきていませんが、現実のシステムでよくあるような「秘密の質問(アカウント登録時に設定されたもの)」を回答させるという方法のも一つの手かと思います。

→ 学び方: 現実のシステムの仕様や発生したインシデントを問題文の事例と照らし合わせ、良いケース・悪いケースの知見を蓄積する

二つ目の問題: パスワードそのものをメールで送る

この問題に対しては、「パスワード失念時に本人確認後に送信するメールの内容はどうすべきか？」ということを考える必要があります。

現実のシステムにおいても、このような場合にはパスワードそのものではなくパスワードリセットの URL をメールで送信するケースが多いと思います。
この問題でも、対応案として「パスワードリセットの URL をメールで送る」という方法が提示されています。

なぜそのようになっているかを深掘りして考えてみると、この方式のほうが「パスワードリセットを強制できる」・「URL のリンク先を無効化すればメールの内容が漏洩しても攻撃者が何もできない」などのメリットがありそうだということに気付けます。
このように考えていくと、更に一段掘り下げて「パスワードリセットの URL はパスワードリセット完了後 or 一定時間後に無効化する」といった仕様を盛り込んだほうがよさそうだ、といった具合に設問以外のところからも学びが得られると思います。

→ 学び方: 設問に対してなぜそのような解答になっているのかを掘り下げて考えることで知見を深める

三つ目の問題: パスワードリセットの URL を、登録済みメールアドレスだけに送る

この問題に対しては、「パスワード失念時に登録されたメールアドレス以外にメールを送信してよいのか？」ということを考える必要があります。

問題となるメール送信先としては、「不正に本人確認した悪意あるユーザのメールアドレス」・「本人ではあるが間違えて指定してしまった別人のメールアドレス」などが考えられ、システムに対象のユーザのものとして登録されていない任意のメールアドレスに送信できてしまうという仕様は問題がありそうです。

この問題でも、対応案として「登録されたメールアドレス以外にはメールを送信しない」という方法が提示されていますが、その方法に対して「一部の利用者はパスワード失念時にログインできなくなる」という課題も合わせて提示されています。

ここで言われている「一部の利用者」とは、具体的には登録されているメールアドレスが使用できない状態の利用者などが考えられます。
そのような利用者に対しては、他の方法でのパスワード再設定の手段が必要になるため、「登録済みメールアドレスが使用できない場合はコールセンタで対応する」という方法が提示されています。
この例のように、システムの安全性を確保するためにシステムそのものでは実現できない要件がある場合に、運用も含めてその要件をどのように満たすかを考えることも大事になりそうです。

→ 学び方: すべてをシステムそのもので解決しようとしない設計も念頭に置いておく

不幸中の幸い

ここまでは問題点ばかりを列挙してきましたが、問題文をよく読むと「不幸中の幸い」もあったことが読み取れます。

このインシデントの原因調査にはサイトRのアクセスログが用いられましたが、そこに適切な情報が記録されていなかった場合には原因の特定が容易に行えなかったことが予想されます。
このことに関する設問は設定されていませんが、「インシデント対応も見据えて適切な内容のログを取得しましょう」という学びも得られると思います。

→ 学び方: 問題文中の「適切なシステムの設定が活かされていること」を良いケースの知見として蓄積する

---

その2: アカウントの共用により実際の作業者が特定できない

出典: 平成27年度 秋期 情報処理安全確保支援士試験 午後Ⅰ 問2(問題・解答)

問題文のポイント

こちらはその1の事例とは異なり、利用者視点ではなくシステムの「中の人」視点で問題になるケースです。
問題文ではシステムの仕様について淡々と記述されていますが、実はその中にひっそりと地雷が埋め込まれています。

• Yシステムの構成

• S社に委託している保守作業の内容

このシステムに対し、L主任が問題を指摘しています。

この指摘に関連して、以下のように設問が設定されています。

工夫したポイント

この設問に対する解答例は以下のようになっています。

L主任が問題を指摘するに至った背景も問題文中に記述があります。

「委託先の従業員が個人情報を不正に持ち出して名簿業者に売却する」という話は、だいぶ前に全く同じ話が現実に発生しており当時世間を賑わせていましたが、本問題はこのインシデントを参考に作成されたのかもしれません。

DBMS 操作 ID は委託先のS社で作業を実施する際に使用しますが、同じものを社内で業務アプリを提供するためにも使用してしまっています。
これではログに記録される DBMS 操作 ID は同じになり、実際に誰が操作したかの区別ができません。

これは、その1の事例において、「適切なログが記録されていたのでインシデント発生時の原因特定がスムーズに行えた」という状況とは対照的です。
アカウント設計の際には、単に対象者が必要な作業を実施できる権限があればいいという以上に、「委託会社に使用していただくアカウントは社内で使っているものと共用で問題ないか」・「共用した場合にどのようなリスクが考えられるか」など考える必要がありそうです。

→ 学び方: 他の問題で得た良いケースの知見を参考に、そうなっていない悪いケースの知見を見つけ出す

また、この問題の趣旨からは外れますが、「委託会社に使用していただくアカウントはどれくらいの権限が必要か」・「不要に強い権限を設定した場合にどういう問題が発生しうるか」ということもしっかり考慮する必要があります。
過去問では「最小権限の原則」に関する設問(必要以上に強い権限を持ったアカウントが乗っ取られて被害がより拡大する等)もよく取り上げられるので、広く問題を解いていくことでこれらの知識を関連付けて記憶できるようになると思います。

→ 学び方: 問題を解いて得られた個々の知識をリンクしてより強固にする

その3: 決済アプリの認証が不十分でやりたい放題

出典: 令和2年度 10月 情報処理安全確保支援士試験 午後Ⅰ 問1(問題・解答)

問題文のポイント

この問題では利用者がスマートフォンでバーコードを見せて決済を行うシステムを取り挙げていますが、バーコードの作り方に問題があります。

この仕様に対して、Yさんが問題点を指摘しています。

この指摘に関連して、以下のように設問が設定されています。

工夫したポイント

この設問に対する解答例は以下のようになっています。

バーコードの内容が会員番号のみから構成されており、他者の会員番号を推測もしくは窃取することでその会員番号に相当するバーコードを作成できれば、その会員情報を使用しての決済がやりたい放題です。
利用者側としてはこのような決済システムは怖くてとても使えませんね。

→ 学び方: 問題文で提示されているシステム設計について、利用者の立場からすると使いたくないものになっていないかを考えながら読む

現実のこのようなシステムではバーコードの有効期間が設定されていることを考えると、「パスワードそのものだけでなく時刻などを元にして特定の会員のバーコードが漏洩した際に使い回せないようにする必要がありそうだ」ということに思い至ることができそうです。
(この問題の後続の記述でも、この仕様への対策として会員番号の他に時刻などを組み込んだメッセージ認証を取り入れています)

→ 学び方: 問題のあるシステム設計への対策について、問題文での対策案の記載を読む前に自分なりに考えてみることで知見を定着させる

この問題はバーコードを「見せる」システムでのバーコード作成の不備について問われていましたが、現実にはバーコードを「読み取る」システムでもユーザによる不正利用が発生していました。

PayPayの音だけ鳴らして商品をだまし取った男が逮捕される
https://iphone-mania.jp/news-385630/

店舗が用意したバーコードを利用者がスマホで読み取って決済を実施するべきところを、店舗側で(偽の)決済音だけを確認して決済完了を確認しなかったということのようです。
これは単純にシステムの不備であるとは言いづらいですが、決済フローの運用も含めてこのような不正が実施されないようにしたいものです。

→ 学び方: 問題文に提示されたシステムに類似する現実のシステムについても、「まずいシステム」になっていないか考えてみる

まとめ

この記事では、情報処理安全確保支援士試験を通じて情報セキュリティ領域について学ぶにあたり工夫した点を紹介しました。

今回取り上げたのは、以下のようなパターンの問題でした。

• 問題文中に(さりげなく)記載されている「まずいシステム設計」を指摘する
• 問題文中に記載されているべき「適切なシステム設計」の記載が欠落していることを指摘する

このようなパターンの問題を解くときに、今回紹介した学び方を活かしていただけるかなと思います。

過去問では、上記のパターンの問題以外にも、脆弱性に対する攻撃手法に関する知識問題・セキュリティプログラミングになど関する問題など幅広い問題が用意されています。
実際に色々なパターンの問題を解くことで情報セキュリティ領域についての知見を深められますので、ぜひ皆さんも過去問を解いてみてはいかがでしょうか。

明日は食べログアドベントカレンダー2021の18日目の記事が公開されるのでご期待ください！

---

1. URL は こちら です。IPA(独立行政法人情報処理推進機構) が実施している情報セキュリティに関する知識・技能に対する試験で、 過去問 が公開されています。午後問題は架空のシステムの設計・運用事例に関する記述式問題になっています。 ↩