システム監査技術者論文メモ

平成29年度問1、情報システムに関する内部不正対策の監査について

システムの概要と内部不正が発生した場合の概要

・A社の業務管理システム

・A社の事業に関する膨大なデータが含まれており、特に、価格情報や利益率が他社に漏れれば競争が不利になる可能性がある。

・取引先の情報や、個人情報も含まれており、情報漏洩があれば信用が失墜し、事業の継続にも影響が出る可能性がある。

内部不正の技術的対策と実施状況確認の監査手続き

内部部製の技術的対策

・システムユーザーに対しては、アカウントごとに権限を付与し、自分の業務に関する機能、自分の部署の情報にしかアクセスできないように設定している。

・システム保守ベンダーは、業務上管理者権限を保有している。データ持ち出し対策として、外部のネットワークに接続できないように設定し、外部記憶装置の接続もポリシーで接続不可の設定を行なっている。

監査手続き

・監査社にシステム権限を付与してもらい、権限の設定状況を確認した。また、もう一つユーザー用のアカウントを作成してもらい、権限を設定して、正しくアクセス制御が行われていることも確認した。

・システム保守ベンダーに対しては、端末貸与の際にポリシーの設定内容を画面キャプチャで取得しておきそれを参照した。また、社内ネットワークからのアクセスログも確認し、外部への接続がないことも確認した。

内部不正の組織的対策と実施状況確認の監査手続き

内部不正の組織的対策

・オンライン教育システムを用いて、内部不正に関する教育を実施した。

・上司が部下のアクセス履歴を月次で確認し、不明なログがあれば聞き取り調査を行う。

監査手続き

・オンライン教育のプログラム内容、テスト内容が適切であることの確認。

・オンラインプログラムの受講率、テスト合格率が100パーセントであることの確認。

・複数社員にインタビューを行い、教育内容を十分に理解しているかを確認。

・上長のアクセスログから、毎月ログの閲覧を行なっていることを確認。

・上長に事前アンケートを取り、ログの内容について聞き取りを行なったことがないと回答した上長数人に一緒にログを見ながら、聞き取り不要と判断した理由を説明してもらった。

平成29年度問2、情報システムの運用段階における情報セキュリティに関する監査について

情報システムの概要とビジネス上の役割及びシステムに求められるセキュリティレベル

情報システムの概要とビジネス上の役割

・A社は小売業を営む企業。

・A社の商品管理システムは、ベンダー、A社商品担当者、A社ECサイト担当者がそれぞれ必要事項を入力する。

・各人の利用できる機能、閲覧できる範囲には制限がある。

システムに求められるセキュリティレベル

・外部からの侵入は絶対に阻止する必要がある。

・アカウント権限が適切に機能し、各個人がアカウントを適切に管理することが必要となる。

情報システムの運用段階においてセキュリティレベルを維持できなくなる要因とそれに対するコントロール

要因

・①サーバーやミドルウェア、プログラム言語のセキュリティパッチ適用、アップデートが適切に行われず、外部の攻撃者にセキュリティホールを突かれてしまう。

・②攻撃者の手法にシステムが対応できなくなっている可能性。システム改修時に追加開発したプログラムでセキュリティ対応に問題があるもしくはシステム開発後に新しく生まれた攻撃手法に対応できていない可能性がある。

・③個人のセキュリティ意識の低下から、パスワードが当人以外に漏れている可能性がある。

コントロール

・①システム開発時にパッチ等の適用対象リストを作成し、毎週、情シス担当者がパッチ情報を確認する。

・②システム改修時はセキュリティテストの必要有無が判定される。必要である場合はあらかじめ定められたセキュリティテストを実施する。また、年に１回外部のセキュリティテスト会社に依頼してセキュリティ対応状況を確認してもらう。

・③社員への教育を実施する。社内のセキュリティ委員会を月次で開催し、教育プログラムを作成しオンラインで全社員に受講してもらう。

コントロールが有効に機能しているかどうかの監査手続き

セキュリティパッチ適用

・パッチのチェックを行っている資料を確認し、情シス担当者に実際に作業状況を見せてもらい最新のパッチが資料上適用されていることを確認する。

・システム担当者に現在のシステムのバージョンのエビデンスを提出してもらい、資料と照合する。

セキュリティテストの実施

・過去のシステム改修履歴とセイキュリティテスト必要可否の資料を確認し、運用実績を確認。

・一番新しいセキュリティテストが必要と判定された案件について、実施したセキュリティテスト結果とエビデンスを確認する。

・外部のセキュリティテスト会社への依頼では、過去数年分のレポートを確認し実施状況を確認。最新のレポートでは詳細に確認し、指摘された内容と指摘への対応が完了していることを確認する。

教育活動の実施

・セキュリティ委員会の議事録を確認し、開催実績を確認する。

・オンラインの教育プログラム実施状況を確認し、社員の受講率と確認テストの合格率を確認する。

・教育を終えた社員数人に過去のテストを抜粋したものをもう一度受けてもらいその点数から理解度を確認する。

平成30年度問1、アジャイル開発に関するシステム監査について

アジャイル開発するシステムの概要とアジャイルを採用する理由及びアジャイル開発の内容

システムの概要

・レストラン紹介サイトを運営するA社の新規コンテンツとして立ち上げる飲み会日程の調整を行えるサイト

アジャイル開発を採用する理由

・A社のコンテンツ開発では仕様変更がた度々発生し、開発チームが無理なスケジュールで対応するなどの問題があった。

・あらかじめ完成形を決めるのではなく、開発しながら仕様変更を取り込んでいくこととなった。

アジャイル開発の内容

・開発する機能ごとの粒度に分解して、見積もり工数ごとに点数をつけ、その消化点数を2週間ごとに集計しチームの開発能力とする。

・残っている機能の点数を、開発完了日までの日数で割って、チームの開発能力を超えない範囲で機能を追加する。

・開発機能が開発能力を上回った場合は、企画担当者が人員を追加してチームの開発能力を高めるか、仕様を取り下げるかを判断する。

・単体テストはプログラムとしてあらかじめコーディングする。

アジャイル型開発を採用することに伴うリスクとコントロール

アジャイル型開発に対する認識の違い

・今回の開発メンバーにアジャイル経験者がおらず、知見がないというリスクがあり、コントロールとしてアジャイル開発経験のあるB氏にアドバイザーとして参画してもらう。

・企画担当者が、仕様変更をなんでも聞いてくれると誤解してしまうリスクがあり、コントロールとして開発方法の説明資料を作成し、キックオフで合意する。

単体テスト完了時の品質低下

・ウォーターフォール型の単体テストとは異なり、単体テストの件数やレビュー結果で品質を担保することが難しく、品質低下リスクがある。

・コントロールとして、開発メンバーの参画基準を定め、プログラミング経験3年以上、うち1年はPHPの開発経験があることとした。また、単体テストのコーディング結果をメンバー間で相互レビューするとした。

アジャイル型開発を進めるための体制、スキル、開発環境などの整備状況を確認する監査手続き

体制及びスキル

・開発メンバーの職務経歴書とインタビューを監査手続きとして実施し、職務経歴書とインタビュー結果を監査証拠とした。

・アドバイザーのB氏の過去のアジャイル経験についても、過去のプロジェクト資料の確認とインタビューを監査手続きとして実施して、B氏のアジャイル経験についてまとめた資料を作成し監査証拠とした。

・プロジェクトの進め方に対する監査手続きとして、キックオフ時の説明資料、議事録の査閲を実施した。企画担当者には追加でヒアリングを行い、説明資料、議事録、企画担当者ヒアリング結果を監査証拠とした。

開発環境の整備状況の確認

・進捗状況と機能ごとの開発担当者、レビュー者を管理するエクセルに対し、実際にサンプルデータを入力して管理が正しく行えるかという監査手続きを行なった。サンプルを入力したエクセルファイルを監査証拠とした。

・単体テストコーディングツールが正しく機能するかという監査手続きを行なった。PLにテスト対象とテストコードを作成してもらい、バグを正しく検知できるかも含め確認した。プログラム及びテストツールの出力結果を監査証拠とした。

平成30年問2、リスク評価の結果を利用したシステム監査の策定について

組織の主な業務と保有するシステムの概要について

組織の業務

・工事を行う企業

保有するシステムの概要について

・期間システムはいくつかの領域に分かれ、領域ごとにサブシステムとして構築されている。

・情報システム部門が中心となって開発し、運用を行なっている。

・現在も頻繁にシステム改修が行われている。

・システムでは多くの秘密情報を取り扱っている。

監査部門がリスクの評価を実施して監査対象の選定や監査対象の設定を行う場合の手順

監査対象の選定と監査目的の設定の手順の概要

・必ず実施するもの、毎年ポイントを変えて行うもの、全社方針に基づくものの3つに分類して実施する。

手順の詳細と留意点

・必ず実施する監査は、システムごとに内容が決まっており、最重要事項が対象となる。留意点としては発生したインシデントをもとに見直しが行われている点である。

・年度ごとにポイントを変えて行う監査は、監査のリスクリストの中から毎年違う観点でより詳しくシステムの監査を行う。

・全社方針による監査は、会社の経営方針にシステムが適用しているかの監査を行う。

監査部門以外が実施したリスクの評価結果を利用する場合の利点、問題点及び必要な措置

他部門が作成したリスク評価を利用する利点

・情シス部門が作成したリスクリストを利用する。発生確率と、発生した場合の影響度から重要度が決められている。

・利点は、開発者目線で作成しているため、網羅性が高いことである。また、システム改修時にアップデートが行われ最新の状態になっている。

・開発者目線で見た重要度も重要な参考情報となる。

問題点及び監査部門として必要な措置

・リストが平常時のシステムを想定して作成されており、緊急時の対応についてはすべてのケースを想定できないため記載されていない。

・過去に発生した緊急時の例外処理について情報システム部門から情報提供を受けて監査対象として検討することが必要となる。

・必ずしもリスクの評価が正しくない可能性がある。システム稼働時に設定されたリスクの重要度は、現在は変わっている可能性がある。

・リスクの重要度は監査部門でも再評価する。例えば、近年メールの誤送信が多ければ関連するリスクの発生確率を上げるといった具合である。

平成31年問1、IoTシステムの企画段階における監査について

IoTシステムの概要と、IoTシステムの活用によるビジネス上のメリット

システムの概要

・A社はレジャー施設を紹介するWeb企業。

・レジャー施設の利用チケットをWebで購入し、施設で自動発券機にQRコードをかざし自動発券するシステムの開発を行なった。

ビジネス上のメリット

・A者はサイト利用者を増やし、レジャー施設側からシステムの利用料を受け取れるメリットがある。

・利用者はレジャー当日に発券の列に並ぶ必要がなくなるというメリットがある。

・レジャー施設は発券の販売スタッフを削減しコスト削減ができるメリットと、Webで価格をフレキシブルに変更したりタイムセールをするなどのマーケティング戦略が可能になるメリットがある。

IoTシステムにおいて想定すべきリスク

①機器の故障リスク

・発券機が物理的に故障するリスクがある。故障すると利用できる機器が少なくなり、利用者の待ち時間が増大する他、最悪の場合チケットの発券ができなくなってしまう。

・A者は東京に本社があるため、施設が地方にある場合、代替の機器を持って駆けつけるということは難しい。

②不正利用のリスク

・QRコードが簡単に推測され利用されてしまうリスク

③通信障害、サーバーダウンのリスク

・施設のWifiルータの故障で発券機がシステムと通信できなくなるリスク

・サーバーがダウンしシステムを利用できなくなるリスク

IoTシステムの開発、運用、保守、及びセキュリティに関わる方針、基準に対する監査

設計、開発

・①、③のリスクに対するコントロールとして、発券機が利用できない場合の代替手段が必要となる。具体的には、管理画面にQRコードから取得した文字列を入力して認証できるようにする。

・監査手続きとしては、企画書を確認して管理画面に対象の機能が盛り込まれていることを確認する。

運用、保守

・①のリスクに対するコントロールとして、予備の機器を準備しておくことが考えられる。施設側で機器の交換を行うことができる必要がある。

・監査方法としては機器の仕様書を確認して、施設側で機器のセットアップ、交換が行えること、施設に渡す運用マニュアルに故障時の交換方法について記載する計画であるかを企画担当者にヒアリングする。

・サーバーダウンの場合は、施設側がマニュアルで購入者を認証する必要があり、購入時のメールを確認する等が考えられる。

・監査方法としては、施設側のマニュアルにシステム利用不能時の対応について記載する計画であること、また、購入完了メールに当日確認できるように準備してもらう旨を記載する計画であるかということを企画担当者にヒアリングする。

セキュリティ

・②のリスクに対するコントロールとして、QRコードを推測して作成できないこと、複数回利用できないようにする必要がある。

・監査手続きとしては、これらの対策がシステム企画書に記載されていることを確認する。

平成31年問2、セキュリティ関連規定の見直しに関するシステム監査について

情報セキュリティ関連規定の見直しの概要と背景及び影響を与えるIT資産の管理と利用について

背景

・2020年のコロナウィルス感染の広まりを受けてテレワークを実施することとなった。

・今まで想定していなかった役員やシステム担当者のテレワークも発生するため情報流出の懸念が発生し、対応が必要となった。

セキュリティ関連規定の見直しの概要と影響を与えるIT資産の管理と利用について

・電車での鞄の盗難に備えて、持ち歩く資料の種類を規定し、情報デバイス紛失時の対応の見直しが行われた。

・PC画面をカメラで撮影することを禁止するとした。

関連規定の見直しに関する手続の適切性を確かめるための監査手続及び留意すべき事項について

・①目的、今回の目的は全社員がテレワークを行うにあたり、情報流出を防止するためのものである。

・②適用範囲、全社員の情報資産が対象となる。

・③適用時期、即時適用。

・④対応技術、インターネットVPN

・情報資産を横軸に、事故による流出、故意の流出を縦軸に取り、マトリクスを作成しリスクとコントロールをそれぞれ整理した。

・想定していない情報資産やリスクが例外として発生する可能性があったため、情シスメンバーや、各部のセキュリティ担当者とタスクフォースを結成し対応した。

・メンバーと週次で打ち合わせを行い、マトリクス表を完成させた。

・マトリクス表、部長へのヒアリング結果、MTG議事録を監査証拠とした。

関連規定を周知徹底するための計画及び状況の適切性を確かめるための監査手続及び留意事項

周知徹底するための計画

・①社内サイトでの掲示及びメールでの周知

・②社内広報誌への掲載、図やイラストを用いて、流出が発生した際の危険性を知ってもらう。

・③トップメッセージの発信

周知状況を確かめるための監査手続

・①、計画の①〜③が確実に行われたかを確認する。
社内掲示では掲示を開いた人の人数を確認する。前者メールでは送信者の送信と例のメールの送信先を確認する。

・②確認テストの実施
確認テストを実施した、留意事項として規定の変更点だけではなく、情報流出がもたらす影響や罰則についても内容に追加した。全社員が正答率100%となることを確認する。

・③アンケート及びヒアリング
社内広報誌、トップメッセージについてアンケートを実施して有効性を確認する。各部のセキュリティ担当者は部内にヒアリングを行い状況を確認する。留意事項として規定が守られなくなる可能性や新たなリスクの発生を考慮して、タスクフォース解散後も定期的に打ち合わせを行う計画とした。

平成29年問1、情報システムに関する内部不正対策の監査について

内部不正が発生した場合に重大な影響を及ぼす情報システムの概要と、そのシステムで内部不正が発生した場合の影響

情報システムの概要

・A社はさまざまなWebサイトを運営する大手企業であり、A社会員が存在する。

・会員登録には、氏名、生年月日、住所、電話番号などの個人情報が含まれている。

・ユーザー情報はユーザ情報システムで一括管理されており、各コンテンツシステムのAPIを利用してユーザー情報を取得、利用している。

・APIの利用にはコンテンツごとに発行されたID、パスワードが必要であり、また、ユーザー情報を取得する際も会員番号の他に、ユーザ認証後に発行されるトークンが必要となる。

内部不正が発生した場合の影響

・A社会員の会員数はA社のビジネスの根幹に関わっており、会員数の減少は売上の減少に直結する。

・また、流出した内容によっては、損賠賠償に発展する可能性があり、会社のブランドイメージや社会的信用の失墜を招く恐れもある。

内部不正の技術的対策の実施状況を確認するための監査手続きについて

コントロールと留意点

・留意点としてシステムのAPIの利用だけではなく、システムを裏で管理する社員に対するルールも必要である。

・①APIでユーザ情報の不正取得ができないこと。
　コンテンツごとの、ID、パスワードが必要であること、ユーザー情報取得には会員IDと認証後のトークンが必要であること。

・②検証環境にテストデータが含まれないこと。

・③本番DB利用時のルール
　利用前に上長の承認が行われること、作業は確認者を含めた2人で行い、確認社は完了している承認に供覧をつけること。

監査手続

・①に関してはAPIの基本設計書を確認、また、API開発者にインタビューを行い仕様を確認した。

・②に関しては実際にデータを閲覧して、件数や内容から検証データであることを確認した。

・③に関しては承認と供覧の実績について確認した。また、本番DBのアクセスログを入手して申請が行われていない日にアクセスがないかを数日分確認した。

内部不正の組織対策の実施状況を確認するための監査手続きについて

内部不正の留意点とコントロール

・APIの機能やDB取扱の基準に漏れや例外があり、社員の意識が低い場合はそのまま見過ごされ、情報流出に発生する危険性がある。

・①個人情報取扱に関する教育
　年一回教育プログラムを実施する。オンラインの受講であり、確認テストで満点をとって完了となる。全社員が対象。

・②セキュリティ委員会の活動
　社内のインシデント状況や、他社で発生したセキュリティに関する事案などをメールで共有。

監査手続

・①に関しては過去の教育プログラムの実施状況を確認した。管理者に画面を操作してもらい全ての教育プログラムの受講及び完了率が100%となっていることを確認した。

・また、前回の受講者リストを当時の社員名簿と突合して漏れがないことを確認した。

・②に関しては、メールの送信者に送信トレイ内のメールのハードコピーを送付してもらった。
　送信者が全社員となっていること、内容が十分に意識を高める内容であることを確認した。

平成29年度問2、情報システムの運用段階における情報セキュリティに関する監査について

情報システムの概要とビジネスの役割及び当該情報システムに求められるセキュリティレベル

システムの概要とビジネスの役割

・A社は建設業を営む企業であり、今回対象とするのはA社の機関業務システムである。

・システムは、工事の受注管理、購買、請求を行うもの、ワークフローを行うもの、経理業務を行うものと各領域ごとに別々のパッケージシステムをカスタマイズして使用している。

・システムの保守運用は主に、開発ベンダーが担当している。

情報システムに求められるセキュリティレベル

・工事の価格情報や取引先との取引情報が流出すれば会社の信用失墜につながり、今後の業績に大きな影響をもたらす。

・システムには過去の経理情報が全て含まれており、情報流出による悪用や、万が一改ざんがあった場合は事業継続に大きな影響を及ぼすため、システムからの情報流出、改ざんは絶対に阻止する必要がある。

情報システムの運用段階においてセキュリティレベルを維持できなくなる要因とそれに対するコントロール

要因

・2020年に発生したコロナウィルスにより、A社もテレワークへの意向を余儀なくされ、情報流出の危険性が高まることとなった。

・①一般利用者
　自宅でシステムを利用するにあたり、データを不正に転送したり、端末の盗難や紛失、家庭で仕事資料を廃棄した場合、そこからの情報流出も懸念される。

・②システム管理者
　システムベンダーメンバーは管理者権限を保有し、A社に常駐してシステムの保守運用を行なっていたが、テレワークに移行することとなった。管理者はデータの参照可能範囲が広く一括のデータ出力ができるため特に注意が必要。

コントロール

・①一般利用者
　各自のセキュリティ意識を高めるためオンライン教育システムを用いて教育を実施する。また、セキュリティ規約のを一部改訂して、社外秘文書の取扱、PC画面のカメラ撮影禁止などを盛り込む。

・②システム管理者
　本番へのアクセス権限をOFFにしておき、必要な時は申請を元に、A社の運用責任者がONにして利用する方法に変更した。ベンダーユーザーは2人1組で作業にあたり、一人はオンライン監視ツールで作業者の作業内容を確認する。

コントロールが有効に機能しているかを確認する監査手続

・①一般管理者向け対策に関する監査

・受講者と受講状況の確認と教育内容の確認の3点を実施した。

・受講者と社員名簿を付き合わせて漏れがないことを確認、受講者全員の受講状況が100％となっていることを確認、教育に盛り込むべき内容をチェックリスト化して教育プログラムの内容を確認した。

・規約改定について社内イントラの規約が改定されていること、新旧規約を比較して変更内容が盛り込まれていること、全社に向けた周知が行われているかを確認した。

・②システム管理者への対策に対する監査

・アカウント有効化メール、アクセス履歴管理ファイルから運用実績を確認。現在のユーザーアカウントがOFFとなっていることを確認した。

・ベンダーのリーダー及びメンバーにいたビューを行い監視作業の実施状況を確認。

・直近の本番アクセスログを取得し、アクセス履歴管理ファイルと突き合わせを行い、申請された時間外でのアクセスがないことを確認した。

※後から気が付いたが、『コントロールが有効に機能しているか』の監査なので本来書くべき内容と違う。

平成30年度問1、アジャイル開発に関するシステム監査について

システムの概要とアジャイル型開発

システムの概要

・TO社

・商品情報を基幹システムに登録しているが、最近構築したECシステムと2重登録が発生している。

・新しく商品登録画面を作成し、既存の基幹システム、ECシステムに情報連携させる。

アジャイル型開発手法を採用する理由と内容

・ECサイトに掲載する商品を増やすことが経営上急務であるが、ECサイトに掲載する手間のためそれがうまくいっていない。本システムをなるべく早く稼働させることが必要。

・商品部門、EC部門とシステムに関連する部署が複数あり、要件定義に時間がかかりそうなことに加え、ユーザー自身どのようなものが最終的に良いかがイメージできていない。

・2週間に一度のスプリントで設計、開発、テストを行い、開発が完了した機能を順次追加していく。

・利用部門には実際にシステムを使ってもらいながら月次で要件定義を行い、欲しい機能と優先順位を決定してもらう。

想定するリスクとコントロール

リスク

・①不具合の発生頻度が多くなる可能性
リリース回数が多くなるため、すでに稼働中の機能に影響を及ぼしてしまう可能性、本番反映時の手順ミスによる不具合発生が考えられる。

・②コスト増となる可能性
あらかじめ全体工数を見積もるウォーターフォールと異なり、開発した機能と実際の工数に大きな乖離がある場合でもそのまま進んでしまい、結果としてコストがウォーターフォールに比べ多くかかってしまう可能性がある。

・③利用部門との認識差異
利用部門が今回の計画を理解していない場合、リリースのたびに使い勝手が変わり不便に感じる、要望を出せばすぐにやってもらえるといった誤解をしている可能性がある。

コントロール

・①不具合の発生を抑える対応

・回帰テスト、単体テストをプログラムで作成し、専用のツールで流す。リリース前に確認することで過去に開発したものに影響がないことを確認する。

・デプロイについては、git＋Jenkinsを用いてデプロイを自動化することで手作業により発生するミスを減らす。

・②コスト増への対応

・開発メンバー全員がプログラミングを行う必要があるため、開発メンバーの参画要件として、「プログラミング経験2年以上かつPHP経験半年以上」を定めた。

・開発した機能にかかったコストを算出し、ウォーターフォールで開発する場合の見積もりを適宜比較して大きな差がないことを確認する。

・③利用部門との認識差異に関する対応

・各部署から代表者を選出してもらい要件定義を行う。また、各部の部長にも責任者という形で参画してもらい打ち合わせの議事録を確認し、要件について部として承認してもらう。

・利用者にはリリース前に、リリース日と変更内容をメール及び掲示板で周知することとした。

アジャイル開発を進めるための監査手続

体制に関する監査手続

・要件定義に商品部門、EC部門の担当者が参加していることを、議事録の参加者一覧で確認した。

・部の担当者にインタビューを行い、要件定義の内容について部長に報告し承諾を得ていることを確認した。

・リリース後の全体周知はまだ、未実施であったのでPMに確認し、その役割をPLが行うことになっていることを確認した。

スキルに関する監査手続

・開発メンバーの経験が、プロジェクト参画要件を満たしているかを各自の職務経歴書で確認した。職務経歴書から読み取れないメンバーは本人にインタビューを行い確認した。

開発環境などの整備状況を確認する監査手続

・アジャイル開発で利用するツールについてPLに確認した。

・テスト実行ツールは、実際にサンプルプログラムを動かしてもらい動作を確認した。テスト対象コード、テストプログラム、実行結果を監査証拠とした。

・デプロイツールについてはテスト用の環境に向けて実行してもらいデプロイが行われたことを確認した。監査証拠としてデプロイツールの設定画面、実行結果ログ、デプロイ前後のプログラムの差分を画面キャプチャで取得した。

・コストに関する見積もりの比較について、具体的な実施方法について、PM、PLにインタビューを行った。また、PLが過去の案件で工数見積もりの経験があることも職務経歴書から確認した。

平成30年問2、リスク評価の結果を利用したシステム監査の策定について

主な事業と保有する情報システムについて

主な業務

・飲食店紹介サイトを運営する企業。

・さまざまなコンテンツを展開。

保有する情報システムについて

・飲食店関連のコンテンツを中心に40〜60のコンテンツがある。

・規模や特色がさまざまで、保有するリスクもそれに従って異なっている。

監査部門がリスク評価を実施して監査対象の選定や目的の設定を行う場合の手順及び留意点

監査対象の選定、目的の設定を行う場合の手順

・コンテンツの数が多く全てを監査することはできないため、リスク一覧の作成、監査部門内の検討会によって決定される。

・コンテンツごとにリスク一覧シートを作成する。縦軸にリスクの一覧、横軸には発生する可能性、発生した場合の重大度が5段階評価され、2つの数値を掛け合わせたものがリスク評価値となる。

・発生する可能性、発生した場合の重大度は、5段階の数値を設定する上でそれぞれ設定基準が設けられている。

・作成したリスク一覧をもとに監査部内で検討会を行い、リスク評価値の高いコンテンツをピックアップし意見を出し合って最終決定する。

・どのリスクを重きを置くかは部内での共通認識があるが、経営方針や他社で発生したインシデントなどは別途加味される。

留意点

・新規コンテンツは計画段階でもリスク一覧に盛り込むため、大型の案件については企画部から情報を得ておく必要がある。

・コンテンツは頻繁な更新が行われるため、過去に作成したコンテンツのリスク一覧も必要に応じて更新が必要となる。

監査部門以外が実施したリスク評価の結果を利用する場合の利点、問題点、及び監査部門として必要な措置

利点

・各コンテンツの開発担当者が作成するセキュリティリスク一覧を利用する。

・開発者が作成している為、仕様書からは読み取れないリスクについても記載がある。

・開発部内でレビューが行われており品質も高い。

・コンテンツの更新に合わせてアップデートも行われており、監査部門の工数削減に有用である。

問題点

・監査部門で作成するリスクの全てを網羅できていない。

・各コンテンツ間で記載ルールや基準が統一されていない。

監査部門として必要な措置

・監査部門で作成するリスク一覧のうち、開発担当者が作成したリスク一覧を参考にできるものを理解して、対象でないものは別途情報を集める必要がある。

・仕様書と合わせて確認を行い、リスク一覧に落とし込む。必要であれば開発担当者にヒアリングを行う。

平成31年度問1、IoTシステムの企画段階における監査について

導入を検討したIoTシステムの概要とビジネス上のメリット

システムの概要

・A者は大規模なスキー場を運営する企業。スキー場には20以上のコースがある。

・休日などは混雑により十分に楽しめなかったと意見をいただくこともあるが、一部のコースに混雑が集中することが多い。

・導入を検討したシステムは、webカメラと人感センサーを設置し、その情報をAIで解析して混雑状況をwebやアプリでリアルタイムに確認できるシステムである。

ビジネス上のメリット

・スキー客をスキー場全体に分散することで、顧客満足度の向上につながる。

・スキー場に来る前からユーザーがコースの混雑状況を知ることで空いていれば顧客の呼び込みにつながり、混雑している場合は流入を抑えることができる。

・試みが成功すれば、システムをwebサービスとして公開し他のスキー場にも利用してもらい、利用料を得ることも期待できる。

IoTシステムにおいてそう適すべきリスク

・①機器の故障

・機器そのものの故障により情報が取得できなくなったり、誤った情報が送信される可能性がある。屋外に設置することから故障の発生確率も高いことが予想される。

・間違ったデータをもとに混雑状況を表示してしまうと、混雑しているコースに人が集中してしまうなどの問題が発生する。

・最終的には苦情や、システムで表示する情報の信頼性を損なうことになる。

・②機器の設置ずれ

・風や地震などで機器の位置がずれて正しく情報が取得できない可能性がある。

・正しい情報が表示できなくなり、蓄積される情報としても問題がある。

・特にWebカメラは撮影エリアが変わってしまうため影響が大きい。

・③不正アクセスの可能性

・機器は人の手の届かないところに設置するが、屋外であるため完全に安全とは言えない。

・LANケーブルや、ルータに直接接続された場合、サーバーに侵入されたり、ダウンさせられるといった危険性がある。

・他のスキー場も利用している場合、訴訟問題にもつながりかねない。

IoTシステムの企画段階における監査

開発に係る方針

・機器の故障、設置ずれの対応として、正しく情報が取得できなくなっているときに検知する仕組みが必要である。

・機器の動作状況を運用担当者が確認できる管理画面が必要となる。

・監査としては企画書を確認し検知について記載されていることを確認する。

・Webカメラのずれに関する対応策を企画、開発担当者にヒアリングした。

運用、保守に関わる方針

・正しく情報が取得できているか確認し、データが取得できない場合は対応が必要となる。

・システムのアラートを検知し、故障や問題が確認されれば、機器の交換や位置の修正を行う必要がある。

・実際の混雑状況とシステムで表示している情報に乖離がないか定期的な確認も必要となる。

・監査としては、システムの運用体制図を確認し、日々の管理画面チェックと、実地の混雑状態をチェックする担当者が明確になっているかを確認した。

・運用手順書、マニュアルに記載する予定の内容を企画担当者にヒアリングして漏れがないことを確認した。

・運用手順書にアラート検知後の対応手順、日々のチェックに関する記載をするか、マニュアルに機器の交換方法について記載するかといった内容。

セキュリティに係る方針、基準

・③不正アクセスへの対応として、機器の設置場所を人が触れない場所となっていること、万が一侵入された場合に備えIPSを導入することとした。

・監査は、機器の設置基準が定められているかということを確認した、例えば、人の手の届かない場所、鍵のかかる場所、施設担当者の目の届くところとなているか等。

・IPSについては企画書に詳しい記載がなかったため、開発担当者に直接、導入を検討しているものの確認を行なった。

平成31年度問2、情報セキュリティ関連規定の見直しに関するシステム監査について

セキュリティ関連規定の見直しの概要、その背景及び影響を与えるIT資産の管理と利用について

セキュリティ関連規定の見直しの概要と背景

・A社はレストラン紹介サイトを運営する大手企業。メインのサイト以外にもホテル予約など、複数のコンテンツを運営している。

・A社会員は１０万人を超えて増え続けいており、各コンテンツで管理している個人情報を基盤チームが統括して1箇所のDBで管理し、コンテンツはAPIでその情報を利用することとなった。

影響を与えるIT資産の管理と利用について

・影響するIT資産として、会員DBで管理していた個人情報、各コンテンツで保持していた会員に関連する情報、個人やチームで管理している個人情報がある。

・会員DBと各コンテンツで保持していた情報は基盤DBに移される。

・個人やチームで管理している個人情報は台帳管理され、チームごとにアクセス制限がかけられた共有フォルダで管理される。

規定の見直しに関する手続きの適切性を確かめるための監査手続および留意すべき事項

・①目的

・目的が明文化されていることをPMに確認した。留意事項としては目的が経営層に承認されていることも重要である。

・経営層の説明会議で明文化された目的が承認されたことを議事録を査閲して確認した。

・②適用時期、適用範囲

・適用範囲がA社の保持する個人情報全てであることを個人情報一覧と計画のターゲット突き合わせて確認した。

・適用時期についてはプロジェクト計画書のスケジュールを確認して明確になっていることを確認した。

・留意事項として目的を見据えた計画が立てられているか、具体的にはターゲットに優先度が付けられ計画に盛り込まれているかを、一覧の優先度と計画書のスケジュールを比較して確認した。

・③対応技術

・個人情報を扱うAPIの対策について、社外からのアクセスの防止や、内部の不正利用防止について技術的対策が十分に行われているか、リスクと対応一覧の資料を査閲して確認した。

・留意事項としては、万が一にも不備があってはならないものであるため、対策が複数の開発担当者によってレビューされる計画であること、APIを外部のセキュリティテスト会社に依頼する計画であることをプロジェクト計画書およびPMへのヒアリングで確認した。

関連規定を周知徹底するための計画及び周知徹底状況の適切性を確かめるための監査手続

周知徹底するための監査手続

・コンテンツ担当者には、今後のコンテンツ開発での注意点を周知する。部内のリーダー会議でリーダーに伝えメンバーにも共有してもらう。

・監査手続きとしてはリーダー会で発表する為の資料作成、発表日のスケジュールをPMにヒアリングする。

・全社については社内周知を出し、チームごとに個人情報の整理を行ってもらう。

・監査手続としてはPMに周知の内容と周知予定日をヒアリングした。各部の部長から各チームに管理台帳のテンプレートと指示が行われていることをメールを査閲し確認した。

・留意事項としては、個人情報流出のリスクについて別途教育が行われている必要があり、そちらの確認も必要である。

周知徹底状況の適切性を確かめる為の監査手続

・開発担当者に対してはメンバーをランダムに選んで今回の対応について説明があったか、理解しているかをヒアリングした。

・直近で個人情報を扱うコンテンツを開発するプロジェクトのPLにAPI利用についてヒアリングするとともに基本設計書を査閲して規定に沿った開発が計画されていることを確認した。

・全社に対してはユーザーにアンケートを行い規定が正しく理解、運用されていることを確認した。

・留意事項としてその時1回だけの確認では規定が形骸化する恐れがある為、継続的な監査が必要となる。