情報処理安全確保支援士の受験をした記録 2021

だいぶ久しぶりにIPAの情報処理技術者試験を受験してきたので記録しておく記事。区分はSC、いわゆる情報処理安全確保支援士である。初回受験。合否はもちろんまだわからない。

• IPA 独立行政法人 情報処理推進機構：制度の概要：情報処理安全確保支援士試験

2021/12/17追記
無事に合格していました！　午前Ⅱ：80点、午後Ⅰ：73点、午後Ⅱ：67点（危なかった）

受験の動機

所属組織の制度や自分の立ち位置的に、資格取得が必要というわけではない（別に手当て等もない。受験費用は経費）。とはいえ昨今のIT業界におけるセキュリティの重要性の増大と、後進指導のためにも知識を泥縄式で獲得する必要を感じたのだった。

時系列でやったことのまとめ

• 4月頃：受験の意思を固める
• 5月頃：とりあえず翔泳社のセールを待って参考書を電子書籍(PDF)で購入

  • 情報処理教科書 情報処理安全確保支援士 2021年版

• 5月頃：IPAのサイトから過去3回分くらいの過去問と回答をダウンロード
  • とりあえず午前Ⅰ試験の過去問をいきなりやってみる。年の功で平均6割くらいの正解は取れることがわかったので、午前Ⅰの対策は過去問のみで行くことにする
  • 午前Ⅱの過去問もやってみたところ、こちらは苦戦することがわかった。知識量が足りない。まずはテキストを読みきってから対策することに
• 6月〜8月：ノートに手書きでメモを取りながら「情報処理教科書 情報処理安全確保支援士 2021年版」を読み進める（アナログに手書きなのは、午後の試験の筆記対策でもある）
• 9月上旬：午前Ⅱ、および午後試験の過去問を解き始める
  • 午前Ⅱは6割以上の正解は出せるようになっていたので、解けなかった問題の復習のみに絞り込む
  • 午後試験はかなり難しい事をこのタイミングで認識する。あせりはじめる
• 9月下旬：以下の記事を参考に追加のテキストを購入（おせーよ）

  • うかる！ 情報処理安全確保支援士 午後問題集 (日本経済新聞出版)

  • このタイミングで午前問題の対策サイトの存在を知る（おせーよ２）
    • 応用情報技術者過去問道場｜応用情報技術者試験.com
    • 情報処理安全確保支援士過去問道場｜情報処理安全確保支援士.com
  • 過去問を上記サイトで解きまくりつつ、試験10日前に届いた「うかる！ 情報処理安全確保支援士 午後問題集 (日本経済新聞出版)」を読み始める（試験前に読み切ったが、ダウンロードできる追加コンテンツには手が届かなかった）
• 10月10日：受験

受験の感想

• 初回受験だからかもしれないが、試験範囲の知識が新鮮だったので、勉強自体は楽しめた（特にテキストを読んでいる時は）
• 午後の試験問題はだいたい「セキュリティ問題が発生して、調査して、対策する」事例問題になっていて、背徳感というか「他人の失敗は蜜の味」感がある。興味深い。
  • ちなみに午後の試験問題に出てくる「上司」が有能。うらやま
• 試験そのものが「オンサイト会場で」「長時間着席して」「マークシートと筆記」という点はだいぶ不安だったが、やってみたら別になんともなかった。懐かしかった。
  • ただし漢字記述能力には大いに不安だったので、前日に漢字の練習をだいぶやった。
• 高度情報処理技術者試験、といえば当日出席率の低さというイメージがあったが、やっぱり会場は空席（不戦敗）だらけ。試験費用が値上がりしているので、もったいない。

まあ、合格するかはわからないけれど（とりあえず午前は自己採点的には問題ない）なかなか興味深い勉強体験だったので記録しておく

ゼネラリスト育成としてのGoogle APM

今、「ブリッツスケーリング」を読んでいるのだけれども、ゼネラリスト育成についての説明でGoogle APM（Associate Product Manager Program）が紹介されていたので、オッと思っていろいろと調べてみた。APMをゼネラリスト育成プログラムとしては見ていなかったなぁ。ちなみにブリッツスケーリングは第二次世界大戦における独の電撃戦（ブリッツクリーク）をヒントにした電撃的スケールアップのことのようです。

ブリッツスケーリング

ブリッツスケーリングの初期段階では、スピードと適応力が必要なので、頭の回転が速く、不確実で変化の速い環境でさまざまな仕事を片づけられるゼネラリストが大いに重視される。
（中略）
グーグルではマリッサ・メイヤーが、アソシエイト・プロダクトマネジャー（ＡＰＭ）というプログラムを立ち上げた。このプログラムでは、ゼネラリストの価値を体系化している。新卒の技術者を製品ゼネラリストとして採用し、このプログラムを通して柔軟で適応力のある社員に育成しようとメイヤーは考えた。
ブリッツスケーリング、第4章 マネジメントのイノベーション

How Google WorksやWork Rulesではあまり取り上げられていないAPM

とりあえず手元にあった

• How Google Works (日本経済新聞出版)
• ワーク・ルールズ！―君の生き方とリーダーシップを変える

を読み返してみたけれども、APMの説明はほとんどない。後者に至っては取り上げられてもいないような気がする。

Webで調べてみた

日本語で読める記事はこの2つが一番参考になった
tumada.medium.com
www.axion.zone

あと英語だけれども、かなり詳しく掘り下げた記事はこちら
candor.co

結局はローテーションとOJT

いろいろ読んでみたけれども、結局のところはローテーションを中心としたハードル高めのOJTといった感じ。

データソース全体の整合性／クレンジングの重要性をNASAの事故に学ぶ

有名なソフトウェアのバグ事例の一つにNASAのマーズ・クライメート・オービターの事故というものがあるのだけれども、これをデータソース全体の整合性やクレンジングの重要性を説明する際に使うというのは良いアイデアだと思ったのでメモ。

マーズ・クライメート・オービターの事故

• マーズ・クライメイト・オービター - Wikipedia
• メートル法とヤードポンド法は間違えやすい！ うっかりミスが引き起こした5大悲劇 | ギズモード・ジャパン
• 失敗百選-単位系の取り間違いで火星探査機が行方不明

わりと有名な話。モジュール間インターフェースの単位整合性が取れていなかったというバグ。連携ソフトウェアの一部はデータをヤードとして扱い、一部はメートルとして扱っていたため、結果として火星探査機が火星に墜落したという話。失敗百選の分析はかなり興味深い。

データソース全体の整合性

上記のトラブルは歴史的には知っていたのだけれども、改めてデータソース全体の整合性を取ることの重要性を説明する際に使うのは賢いと思った。

1999 年、米航空宇宙局（NASA）のジェット推進研究所はデータソース全体の整合性をとることの重要性を嫌と言うほど理解しました。NASAと契約したロッキード・マーティン社は、火星探査機マーズ・クライメイト・オービターのスラスタを制御するアプリケーションを開発しました。その際に、そのアプリケーションはスラスタの推力の計算にヤード・ポンド法の単位である重量ポンドを採用したのですが、NASA 側が航行システムにデータを入力するときには、推力はメートル法の単位であるニュートンで指定されることを想定していたため、実際に必要な計算と処理されたデータに食い違いが発生し、オービターの航行システムは火星の軌道に乗るための正しい姿勢を取ることに失敗しました。こうして探査機は宇宙に消え、NASAは1億ドル以上の損害を被ったのです。高く付いたアクシデントは、データを処理する前に、測定単位の変換による適切な正規化をしていなかったことが原因です。
実践 CSIRTプレイブック ―セキュリティ監視とインシデント対応の基本計画

この説明はいつか使うためにストックしておこう。
ちなみにタイムスタンプのズレと、ロケール違いもよくあるミスである。これを忘れないようにする良い事例はないかなぁ。

• 貴社のシステム時刻は正確ですか？ - Interconnections - The Equinix Blog

「実践 CSIRTプレイブック」を読んだ #デッドライン読書会

読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第31回。今回取り上げるのは「実践 CSIRTプレイブック ―セキュリティ監視とインシデント対応の基本計画」である。実は細々と情報処理安全確保支援士試験の勉強をしていたので、その関係で大変興味深く読んだ。

実践 CSIRTプレイブック ―セキュリティ監視とインシデント対応の基本計画

• O'Reilly Japan - 実践 CSIRTプレイブック

なおリンクの多くはAmazonとしているが、本書は訳書が米オライリーのサブスク対象となっている。というわけで有難く定額読み放題の枠内で読ませていただいた。

• 実践 CSIRTプレイブック ―セキュリティ監視とインシデント対応の基本計画 [Book]

「実践 CSIRTプレイブック」の全体的な感想

• 前提として一定のセキュリティに関する知識を要する上級者向けの本。冒頭にも書いたが自分はちょうど情報処理安全確保支援士試験の勉強をしていたので大変興味深く読んだ。
  • 本書はCISCOのコンピュータセキュリティインシデント対応チーム（Computer Security Incident Response Team：CSIRT）のプラクティスの紹介となっており、実例を多く紹介しているのが特徴である。
    • セキュリティとトラストに対する取り組み
  • 例えば情報処理安全確保支援士の勉強をしていると、なんというか机上論ばかりで退屈だったりする。本書を読んで実際のインシデント対応の実際がわかったのは大変に良かった。
• プレイブックとは抽象的に言えば「セキュリティインシデントの検知及び対応方法に関する高度な手順書」とのことだが、実際にはCISCOの事例ではBugzillaに登録されたチケットのようだ。この話が出てくるのがけっこう後なので、前半は「プレイブックって何なのよ」という気持ちでいっぱいだった。
• 個人的な印象だが、翻訳は問題ないけれど、よろしくはない。読み進めるのには問題ないが、章題などがちょっと直訳すぎるような……
  • 目次はこちらから確認できるので興味があればどうぞ。O'Reilly Japan - 実践 CSIRTプレイブック
• 本書の中核は具体的なプレイブックの話なのだけれども、その前提としてCSIRTを中心とした体制づくりと戦略策定が含まれているのは、大変に参考になった。

特に興味を惹いた箇所に関するメモ

上記に記載の通り、CSIRTの体制づくりや戦略策定に言及されている章は興味深い。

1章 インシデント対応の基本

インシデント対応チームはよく、ネットワークセキュリティの消防士のような存在として比較されることがあります。実際の消防士は消火活動や人命救助を実施し、消防法に則って活動し、防災意識の向上に努めています。燃えさかるビルから人を救い出し、消火を行っていないときは訓練を実施し、機材を整備し、規則に従った防災対策がされているかビルや構造を点検しています。これらすべては火事の規模を最小限に抑え、速やかに消火して事態を沈静化させることにつながります。
実践 CSIRTプレイブック ―セキュリティ監視とインシデント対応の基本計画 1.2 チームの存在を正当化する

情報処理安全確保支援士の教科書でも消防士の例えが出てきたと記憶しているのだが、このメタファーは有名なのだろうか。わかりやすい。

あと、1.6 自分たちのポリシーを策定する、でCSIRTの設立趣意書の例が出てくる点も興味深かった。このあたり、難しいんですよねぇ……

2章 守りたいものは何か

私たちはインシデント管理プロセスを刷新するとき、うまく運用できているものとできていないものとを、ざっと見ることから始めました。面白い技術的な課題に即取り組む代わりに、基本に立ち戻り、解決したい問題が正しく定義されているかを確認し、自社の安全を守る上で最も基礎的な要件に応えられるかどうかを考えることにしたのです。そして、これら問題や目標を次の 4 つの質問形式にまとめました。

• 守りたいものは何か？
• 脅威は何か？
• どうやって検知するのか？
• どう対応するのか？

上記の質問の答えは、セキュリティ監視とインシデント対応の基礎となります。
実践 CSIRTプレイブック ―セキュリティ監視とインシデント対応の基本計画 2.1 中核となる4つの質問

基本だといわれるとその通りだが、問われると困るタフな質問である。

またこの後ろに 2.9 プレイブックのコピーをいただけますか、という項がある。本章ではここまでで「何かを守るための必要事項がすべて定義された、網羅的かつ形式的なアプローチなど存在しない」ということを説明しているわけで、結果としてプレイブックのコピーなんて意味がないという話は、その通りだと思う。

*

この後、具体的なプレイブックや対応システムの構築についての説明がされたのち、最後に「10章 インシデント発生！どう対応する」で具体的なケーススタディ、「11章 適切な状態を維持するには」では今後のセキュリティ対策の展望について語られている。
5章～9章は詳細すぎて難しい、専門外ということもあるかもしれないので場合によってはすっ飛ばしても良さそうだ（そういう意味ではサブスクで読めるのが本当にありがたい）

ただし、サブスクで読む場合は若干課題があるので注意が必要だ。おそらく日本側の出版社のデータ共有方法が「固定ページ」形式なので、サブスク側でも固定ページで表示されてしまうのだ。日本でも本書の訳書はPDFのみ提供されているのがおそらく関係しているのだろう（KindleやEPUBに対応している訳書については他の書籍と同様に快適にWebページとして参照できるものもあるため）。

おまけ

というわけで「情報処理教科書 情報処理安全確保支援士 2021年版」を頑張っている。間に合うのかな

情報処理教科書 情報処理安全確保支援士 2021年版

「ゼロトラストネットワーク」後半も読んだ #デッドライン読書会

読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第30回。今回は前回前半までを読んだ「ゼロトラストネットワーク ―境界防御の限界を超えるためのセキュアなシステム設計」の続きである（ちょっと分厚いので前半後半に分けて読んでいる）。7章 アプリケーションの信頼と信用から最後までを読んでいる。

ゼロトラストネットワーク ―境界防御の限界を超えるためのセキュアなシステム設計

書籍「ゼロトラストネットワーク」の全体的な感想

• 前半の感想にも書いたのだけれども、抽象度が高いので割と難しい本だったなぁ、という印象
• 近年のパンデミックなどで、急速にリモートシフト、クラウドシフトが起こっておりゼロトラスト（ZT）の重要性は急速に高まっている。よって、このタイミングで基本的な考え方をおさえておくのは良かったかも
  • いま並行して「情報処理教科書 情報処理安全確保支援士 2021年版」を勉強しているのだけれども、ZTについては一応触れられてはいる（5ページ程度）が、だいぶ浅い

後半で興味深かった内容の紹介

7章 アプリケーションの信頼と信用

本章に期待していた内容は、例えばエンタープライズシステムのゼロトラストの対応（アプリケーションにどう認証を組み込むか等）だった。しかし実際には7章はプログラマーとコードをそもそも信頼しないゼロトラストの話なので、ちょっとびっくりした。

ソースコードはソフトウェアを実行するための最初のステップである。かなり平たく言えば、信用されない人が書いたソースコードを信用するのは難しい。コードが入念に監査されるとしても、悪意を持つ開発者が脆弱性を意図的に実装する（そして隠ぺいする）可能性はやはりゼロではない。実際には、このような悪質な行為を競う有名なコンテストまで存在する†2。悪気はなくても、アプリケーションにうっかり脆弱性を作り込んでしまうこともある。しかし、ゼロトラストネットワークの焦点は、そうした開発者から信用を取り上げることではなく、悪用されたコードを特定することにある。

• ゼロトラストネットワーク ―境界防御の限界を超えるためのセキュアなシステム設計 7章、より

お前は何をいってるんだ……
ちなみに紹介されているコンテストはこちら。だいぶ面白いが2015年で終わっているようである。

• The Underhanded C Contest

（と、茶化してしまったが、本章で語られているコードを信頼し、セキュアにデプロイする考え方は非常に参考になった）

9章 ゼロトラストネットワークの実現

具体的なマイグレーションに関する説明である。GoogleのBeyondCorpおよび、PagerDutyのZTAのケーススタディを含んでいる点が興味深い。
ただ、実はこの後に読んだNISTのZTA文書（2020年発効）のほうがわかりやすかった。これは時代的なものも大きいかもしれない。

• NISTの800-207 Zero Trust Architecture（日本語PDF）

10章 攻撃者の視点

最後の章では、ZTAに対して攻撃者の視点でどのようなアプローチが考えられるのかの論考がついている。ZTAにも当然のことながら脆弱性はあり、運用等でカバーする必要があるという話。

NIST 800-207 で示される現代のネットワーク的な前提事項

本書を読んでから補足的にNISTのZTA文書（日本語PDF）を読んだのだけれども、現代のネットワークに関する前提が興味深かったのであわせて紹介しておく。

1. 企業のプライベートネットワークは、暗黙のトラストゾーンとみなさない
2. ネットワーク上のデバイスは、企業が所有していないか、構成可能なものではない場合がある
3. どんなリソースも本質的に信頼されるものではない
4. すべての企業リソースが企業のインフラストラクチャ上にあるわけではない
5. リモートの企業主体と資産は、ローカルネットワークの接続を完全に信頼できない
6. 企業のインフラストラクチャと非企業のインフラストラクチャとの間で移動する資産とワークフローには、一貫したセキュリティポリシーが必要

ZTAはこれから必要性が高まっていくんだろうなぁ。

RFCスタイルの優先順位リスト

主に自分向けのメモ。「ゼロトラストネットワーク ―境界防御の限界を超えるためのセキュアなシステム設計」で紹介されていたRFC2119の話が有益そうだったので少し調べてみたという話。

RFCスタイルの優先順位リスト
RFCドキュメントは、インターネットインフラストラクチャに対して提案される変更の共通語である。これらのドキュメントは、そのドキュメントで提案されている変更をすばやく理解できるようにするために、言語と構造が明確に定義されている。この言語の要素のうち優先順位の説明において非常に有益なのは、RFC2119で定義されている標準用語であり、MUST/MUST NOT、SHOULD/SHOULD NOT、MAY/MAY NOTなどの用語が定義されている。

• ゼロトラストネットワーク ―境界防御の限界を超えるためのセキュアなシステム設計、9章より

これまで自分は無自覚にMUSTとかSHOULDとかを文書に書き散らしてきたような気がする。反省。

RFC2119

まあ詳しくはここを参照

• Key words for use in RFCs to Indicate Requirement Levels
• RFC において要請の程度を示すために用いるキーワード

MoSCow分析とのギャップ

アジャイル開発プロジェクトなどではMosCoW分析を使うことも多いと思うけれど、MosCowではRFC2119には登場しない「Could」「Won't」が登場する。

• 日常生活でも使える要件整理術 〜MoSCoW分析〜 | DevelopersIO

RFC2119のMAY=MosCoWのCould、と理解しても良いのだろうか

SHOULDの扱い

自然言語なので明確なものではないのだろうけれど、SHOULDの定義には若干注意が必要な気がする

3. 「する必要がある（ SHOULD ）」 English
この語句もしくは「推奨される（ RECOMMENDED ）」という形容表現は、 特定の状況下では、特定の項目を無視する正当な理由が存在するかもしれませんが、 異なる選択をする前に、当該項目の示唆するところを十分に理解し、 慎重に重要性を判断しなければならない、ということを意味します。

• RFC において要請の程度を示すために用いるキーワード

Shouldは「したほうがいい」という解釈をこれまでしてきたのだけれども、RFC2119の表記はもう少し強い印象がある。ニュアンス的な問題だろうか。

ゼロトラストネットワーク ―境界防御の限界を超えるためのセキュアなシステム設計

「ゼロトラストネットワーク」前半を読んだ #デッドライン読書会

読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第29回。さて、今回選んだタイトルは「ゼロトラストネットワーク ―境界防御の限界を超えるためのセキュアなシステム設計」、ちょっと分厚いので前半後半に分けて読んでいる。今回は前半（第6章）までの感想である。個人的にセキュリティ周りの勉強に最近力を入れているので、その一環でもある。

ゼロトラストネットワーク ―境界防御の限界を超えるためのセキュアなシステム設計

急激に注目度が上がるゼロトラスト

本書の原著が発売されたのが2017年、訳書が出たのは2019年である。しかし2020年のグローバルパンデミックにより、状況は一変してしまった。

• ガートナーが「日本におけるセキュリティ（デジタル・ワークプレース）のハイプ・サイクル：2020年」を発表：「ゼロ・トラスト・ネットワーク・アクセス」が「過度な期待」のピーク - ＠IT

セキュリティの担保されたオフィスやデータセンターの内部で執務をすること自体のリスクが高まってしまった。本書で紹介されるゼロトラストの考え方のみがソリューションではないとは思うが、その考え方の重要性は現在は非常に高まっていると言えるだろう。

書籍：ゼロトラストネットワークについて

というわけで本書はいわゆる「ゼロトラストネットワーク」の概念や理念から書かれた本である。ゼロトラストネットワークとは、という点については既に様々な情報が世にあふれているので本記事では割愛するが、本書は抽象度が高いので、つまり

• けっこう難しい

というのが前半を読んだ感想である。
特に訳書として難しいのは「トラスト」「信用」「信頼」などといった用語の使い分けである。この問題については末尾の監訳者あとがきが詳しい、というか、これはまえがきにしてほしかったくらい。先に読むことをお勧めする。

トラストエンジン

いちおう一般論としてのゼロトラストネットワークについては理解していたつもりだったのだけれども、本書を読んで、トラストエンジンを中心にした認証回りは自分が理解したつもりになったものと大きく異なっていて勉強になった。もちろん前半では抽象的な形でしか触れられていないのだが、後半にはGoogleのBeyondCorp等の事例紹介があるはずなのでそこで理解を深めたい。

後半も読み終わってからやりたいこと

今回は前半までの感想（というほど感想書いていないけど）だったが、後半まで通読してからあわせて以下にチャレンジしてみたい。

• NISTの800-207 Zero Trust Architecture（日本語PDF）をちゃんと読む
• Microsoft 365など身近な製品におけるゼロトラストアーキテクチャの実装について確認する

うーん、やりたいことが減らないなぁ