ならず者IoTエンジニアが由緒正しきシステム監査技術者になってしまった件(4)
午後Ⅱ
午後Ⅰが終わった後、午後2の答案が配られるまでの間、私は数か月前のことを思い出していました。
IPAへの質問
システム監査技術者試験の対象者像には、こんな記述があります。
https://www.jitec.ipa.go.jp/1_11seido/au.html
高度IT人材として確立した専門分野をもち、監査対象から独立した立場で、情報システムや組込みシステムを総合的に点検・評価・検証して、監査報告の利用者に情報システムのガバナンス、マネジメント、コントロールの適切性などに対する保証を与える、又は改善のための助言を行う者
ところが、午後2の論文試験の問題文記述を見ると、組込みシステムに関する配慮がされていないように見えたのです。
例えば2018年春季の問1。
設問ア あなたが関係する情報システムの概要、アジャイル開発型開発手法を採用する理由、及びアジャイル型開発の内容について、800字以内で述べよ。
同年度問2。
設問ア あなたが携わった組織の主な業務と保有する情報システムの概要について、800字以内で述べよ。
組込みシステムを含むシステム監査能力を問う試験のくせに、組込みシステムの知見を基に回答できる設問が同一年度中に全く用意されていないのではないか？ と思ったのです。
これは看板に偽りありで、組込みシステムの知見を積んできた受験者には著しく不利な措置では？ と思ったので、直接IPAにこう尋ねてみました。
- 問題文中に『情報システム』と記述のある問題について、『組込みシステム』における内容について論述し、回答した場合、問題の趣旨に添わない(B以下の判定となる)と解釈されるのでしょうか。
と。
するとこんな回答が返ってきました。
午後2（論述式）試験につきまして、組込みシステムに関して論述された場合でも、設問の趣旨に沿っていれば問題ございません。
なお、論述式試験では、設問で要求した項目の充足度、論述の具体性、内容の妥当性、論理の一貫性、見識に基づく主張、洞察力・行動力、独創性・先見性、表現力・文章作成能力などを評価の視点として、論述の内容を評価します。
回答表現としてはちょっと物足りないですが、質問とセットで見た場合、情報システムと記述された設問に対し、組込みシステムの事例をもとに回答しても問題ない、ということでした。
というわけで、午後Ⅱを受験する段階では、組込みエンジニアとして解答オプションが3つあったことになります。
- 文章上、組込みシステムを直接論述可能な問題に回答する。
- 『情報システム』と記述のある設問に対して、組込みシステムを題材として解答する。
- 『情報システム』と記述のある設問に対して、組込みシステム以外の仮想事例をベースに回答する。
このことを答案用紙が配布される前まで思い起こしていました。
実際の設問
試験開始の合図を聞き、問題用紙を開いた瞬間、私はあっと息をのみました。
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2019h31_1/2019h31h_au_pm2_qs.pdf
問1 IoTシステムの企画段階における監査について
この時ほど自身に対する天佑神助を確信したことはかつてありませんでした。
完全にホームグラウンド。この設問であれば、監査を行った事例こそ持ち合わせてはいないものの、自身の技術知見をダイレクトに使って回答可能です。
私が発した質問だけではないのかもしれませんが、情報システム一辺倒での出題形式に対して少し補正がかけられたのかもしれません。
と同時に、このテーマに対して内心予期していた部分があって、驚愕すると同時にさもありなん、という印象もありました。
実は予測されていた
実は、このテーマを最初に見たのは本試験の場ではなかったのです。
この本の462ページにはこんな想定問題リストがありました。
そしてこの想定問題に対する出題例と回答論文例まで書いてあったのです。
で、私はiTECの回し者ではないのでここで言っておくと、実は私、この回答論文の内容には大して目を通しておらず、私自身の論文作成においては全く参考にしていません。
ここで私が言いたいことはiTECの本を読めなどという対症療法的な話ではなく、
- 今まで出題されていない分野に対する予想リストを何らかの形で入手、確認しておく
ことが、準備として有効に機能することがある、という話です。
というのも、IoTに対する監査に対しては、iTECの本だけではなく、もう1冊言及している本があったのですよ。
- よくわかるシステム監査の実務解説(第3版)
- 作者:島田 裕次
- 出版社/メーカー: 同文舘出版
- 発売日: 2019/01/25
- メディア: 単行本（ソフトカバー）
『新しいITとシステム監査』という章に書いてあります。
システム監査というと、すでに完成したフォーマルな古いシステムに対して何らかの検証行為をするもの、と思われがちですが、むしろ新しい領域に構築されたシステムの方が、ガバナンスもコンプライアンスもコントロールも効いていないばかりか、社会的な影響力が大きく危険であり、現実として種々の事故、事件が発生しているわけです。
加えて、ともすれば年長者が座を占めがちなシステム監査技術者に対して、絶えず新しい技術領域に対するキャッチアップを怠ってはならない、というメッセージを体現した出題、ともいえるでしょう。
この傾向性はテーマ監査として、クラウド、サイバーセキュリティ、アジャイル等、新規技術領域に対する出題が例年相次いでいることからもうかがえます。
監査テーマで不意を突かれないようにするためには、監査というメソッドばかりを注視することなく、IT技術領域全般に対するアンテナとして、監査として新規に狙われやすい領域を意識しておくことが重要かと思います。
私の解答
これは得たり、と、私は勢い込んで論文設計をメモ用紙に書き始めました。
といっても、IoTで物は作っているものの、監査に立ち会ったり実施した経験があるわけではありません。
なので、演習同様、リスクとコントロールを抽出し、題意に沿いつつ実在してもおかしくない事例の構築を行いました。
…読めるわけがない。いやはやまったく、よく本試験で通ったな、この字…。
ではいつもの通り、略した部分を補って解読しましょう。
- 第一章 私が関係するIoTシステム
- 概要 A社の鍵管理PF(プラットフォーム)
- A社はセキュリティモジュールを売る、鍵管理PFを持つ
- 自社工場機械向けに暗号データを送って制御する機器を導入
- メリット
- 遠隔制御したいのでセキュリティが心配
- セキュリティを維持しつつ遠隔操作
- セキュリティモジュールなのでクラッキングしづらく、現場のいたずらも防げる
- 第二章 (想定されるリスク)
- 外部からの不正操作リスク
- 鍵が流出するリスク
- 不正なデータで操作されるリスク
- サプライチェーンリスク
- 不正機器の埋め込みがハード作成時に行われていないか
- 外部からの不正操作リスク
- 第三章 (監査手続)
- 鍵の伝達がセキュアか
- 不正データ受信時に停止するか
- 導入時の機器正当性の証明
- 入手管理、トレーサビリティ
- 受け入れ時の機器構成確認
…って書いてあるんですけど、この論文設計メモだけ見ても何をどう書いたのかが、あまり伝わらない気がします。実は本文執筆中に結構脚色しているんですよ。
私が記述した事例
概略を書くと、大体こんな感じです。記憶をもとに適当に字句を並べているので字数とかは適当。
第1章 私が関係する組織で導入を検討しているIoTシステム
私の所属するA社は国内各所に工場を有している大手製造業。昨今の働き方改革の流れや、工場の機械を人が直接操作することによる労働災害を防止するべく、自動化、省力化を推進している。
そんな折に、工場設備管理部署が、セキュリティベンダからIoTセキュアプラットフォームの提案を受けた。
セキュリティベンダ曰く、
- セキュリティベンダが売っているセキュリティモジュールを機器に組み込む。
- セキュリティモジュールには個別鍵が埋め込まれており、セキュリティベンダが持っているプラットフォームで鍵を管理できる。
- プラットフォームを介して工場機器に制御データを送ることで、プラットフォームとセキュリティモジュールが暗号化された通信路上で制御データを授受し、遠隔からセキュアに機器を制御できる。
提案を受けた部署は、当該PF導入によって上記メリットを享受できることを期待し、導入の企画検討に入った。
私は監査部門の人間ではなく、別の開発部隊の人間だが、過去の被監査経験や幅広いシステム開発の知見を基に、監査を念頭に置いたアドバイスをしてほしい旨を依頼され、本件に関わった。
第2章 想定したリスク
私は監査人の観点に立ち、以下のリスクを想定した。
外部からの不正操作リスク
- 鍵が漏洩することで、第三者が不正な制御データを正しく暗号化して送信するリスク
- 不正な暗号データをでたらめに生成し送信することで誤動作を引き起こすリスク
サプライチェーンリスク
- ベンダが納品したハードウェアにスパイウェアや不正なチップが搭載されているリスク
いずれも顕在化すれば、工場の機器を不正に操作されることで事故が発生したり、内部情報の漏洩によって経済的損失をこうむったり、会社の信頼を失墜するなど、大きなダメージの原因となるリスクであり、これを放置することはできない。
前者は鍵の管理状態(セキュリティ)と、誤動作に対する備え(セーフティ)に関連するリスクである。
一方後者はIoTデバイスのサプライチェーンの正当性確認に関するリスクであり、近年某企業が世界的な疑惑と問題を起こしたことから無視できないリスクと考えた。
第3章 適切性を確かめるための監査手続
私は監査人ではないが、監査人となった場合は以下の手続きを設定するだろう、と話した。
なお、監査手続の実施における、適切な監査証拠の収集に当たっては、セキュリティベンダからの全面的協力を得られる旨を確認している。
- 外部からの不正操作リスク
鍵の漏洩に関しては、セキュリティモジュールの設計書、およびセキュリティテスト結果を査閲し、デバイスからの直接鍵漏洩の可能性が低いことを確認する。
また、プラットフォームを稼働させているデータセンタの管理ポリシー、物理的設計等についてヒアリングするとともに、直接立ち入り調査を行って、不正なデータ持ち出し、鍵流出を防止可能なメカニズムが機能しているか、目視確認する。
誤動作に対する備えに対しては、セキュリティベンダに対してファジングテストの実施可否をヒアリングするとともに、結果報告書を査閲し、十分なテストが行われていることを自ら確認する。
- サプライチェーンリスク
セキュリティベンダに対して、使用しているハードウェアのリストを提出してもらうとともに、各ハードウェア製造メーカの与信を適切に行ったことを証明する書類を合わせて提出してもらう。これを査閲することで、サプライチェーンの与信管理をセキュリティベンダが行っていること、実際に各部品が信頼に値するかを確認する。
併せて、A社側の受け入れ試験において、納入された機器が実際に当該リストに基づいていることを確認する手順、項目を用意しているかを、A社側の企画書を査閲して確認する。
以上
題材、内容の妥当性も、文書記述も文字数の妥当性も一切保証されているわけではないので、パクったところでそのままでは合格できません1。こういうものか、と雰囲気だけ持って帰ってください。
リスク、コントロールの抽出とリアリティ
前述したように、リスクとコントロール自体を先に抽出したうえで、システムの側を当てはめているんですが、やはり背景となる技術知識を有している点はアドバンテージとして大きいものがあります。
同じリスク抽出する場合でも、当該業界、領域に対する事前知識があると、リアリティのあるリスクを抽出できるんですよ。
セキュリティ製品を使う場合に鍵に関するリスクがある、というのは普通のエンジニアなら想像できると思うんですが、ゴミデータを送った時に誤動作するリスクがある ってのは組込みや制御系の知見(いわゆるセーフティに関する考え方)がないとなかなか引っ張ってこれないと思うんですよね。
もう一つ、業界に関連するニュースとか、ホットトピックを知っていると、それを引き合いに出すことでリアリティが増します。
例えば働き方改革、という言葉はもう世の中に十分定着してますよね。午後ⅠのRPAもそうですが、IoT導入の旗印としても使えるわけです。
あと、IoTのリスクで思い出したのは、某国の通信機器メーカがスパイウェアやスパイチップを仕込んでいる疑惑の話でした。
現在進行形で炎上中のこの問題、大半の人には他人事なんですが、自分がIoTシステムの導入をしようとすると、あらゆる国の部品を使用することになるので、まったく他人事ではなくなるんですね。実際、SDカードのような汎用品はおろか、表面実装組み込み品でも偽チップ問題とかが横行しているわけですから。
こうした、自分がウォッチングしている業界の事例とかを組み込んでおくと、仮想事例でも大分現実臭くなってきます。ここから監査手続きを書くとなれば、問題に対する対策も同時に書くことになるわけですから、自分が世の中にキャッチアップし続ける、広い知見を持っているエンジニアであることも同時にアピールできるわけです。
監査手続の障害を排除する
現実問題として監査手続を企画すると、他社の成果物をどうやって監査するのか、とか、まだ存在していない成果物をどう監査するのか、とか、いろいろと地に足をつけすぎて考えてしまいがちです。
正直なところ、こうした現実志向は論文における監査手続記述においては、あまり価値がないだろうと。
どうしても確認しなければならないエビデンスがあるのなら、それが他社の成果物であろうが、まだ作成されてない物であろうが、断固として手続を設定すべきで、逆に支障となる事態が存在するなら、論文中で明確に排除しておく、というのも一つのリアリティの出し方かな、と思っています。
なので、A社におけるIoT企画案件でありながら、監査対象はA社の成果物ではなく、導入元のセキュリティベンダの成果物であり、そのための合意はすでにとっている、という立て付けを論文中に直接記述しているわけです。
実際私が監査人の立場ならそうするでしょうから、監査実施の障害排除についてあえて書いておく、というのも有効な一手になったかな、と思います。
試験終了後
こんな感じで論文を書いて試験会場を後にしたのですが。
疲労困憊で家に帰って、労いの酒を飲みながら5chを見ていたら、こんな文が目に入ってしまいましてね。
394名無し検定１級さん2019/04/21(日) 16:47:30.12id:kKzh5QTb>>395>>400
午後2のIOT選んだ人
問ウは、企画段階の話だからね
テスト仕様書を確認するとか意味不明なこと言ってた人いたけど
395名無し検定１級さん2019/04/21(日) 16:50:19.09ID:2Cfdkb8I
394
うわぁ
その人今日寝れないんじゃ
私には一緒に試験を受けた連れもおらず、内容も一切しゃべってないので、ここで言及されている人では全くないんですが、企画段階という言葉はその時の私から結構抜け落ちていて、おかげで眠れなくなりました。
ご覧いただければわかる通り、立て付けは一応企画段階として設定しているものの、開発済みの成果物を監査証拠にしている辺り、試験官に誤解されないだろうか…と、2昼夜ぐらい頭の隅に引っかかってました。
が、結果は御覧の通り。どうやら私の意図は試験官に伝わっていたようです。
ただ、振り返ってみると、自分のホームグラウンドの問題が出たことに舞い上がって、問題文を正確に咀嚼して頭の中に入れていなかったが故の不安であり、油断だったと感じています。
どのような問題が出題されても、落ち着いて問題文の中身と題意をしっかりと頭に叩き込まなければならない、と痛感しました。
さいごに
気づけば大分長くなっていましたが、こんな体験をした2か月後、合格の報に接することができました。
監査というテーマからは結構程遠い人間だったので、今回の試験を通して、
- 監査する側、される側の視点を得た
- 自部署、他部署、自社、他社の対監査能力を見直すことができた
- 監査の目的として、業務の正確性、正当性だけではなく、業務効率化を目的とした助言が存在することを知った
と、監査に対する視点をベースとして、知見がだいぶ広がったように思っています。
ESと並んで日本一マイナーな高度情報処理技術者タイトルですが、割と独立した立場で業務に関わることが多い自身の立場に相応したタイトルでもあり、この知見を活かして様々なステークホルダに改善の働きかけをしていければよいかな、と思っております。
こんな感じですかね。午後Ⅰをぎりぎりでパスした合格者の補習としては。
人によっては結構大変な試験区分ですが、この記事がエンベデッド領域を含め、再挑戦者も含め、この試験に挑む方の背中の一押しになれば、筆者としては何よりの幸いでございます。
-
そもそも完全な再現ではありません。実際に書いたことの何割かを忘れています。↩
