ISMAP制度の現在地
政府情報システムのためのセキュリティ評価制度（Information system Security Management and Assessment Program: 通称、ISMAP（イスマップ））は2020年6月より運用が開始され、執筆時点（2024年11月）では4年半ほどが経過しました。府省庁等は原則ISMAP等クラウドサービスリストに登録されたサービスから調達を行うものとされていることから、これらの政府機関と取引がある、または取引を希望するサービスベンダーが既に登録あるいは登録に向けて対応を進めているところです。
しかし、ISMAPクラウドサービスリストに登録するには、1100項目以上の要求事項に対応し、適合性について指定の監査法人から監査を受けなければならず、費用・工数ともに多大な負担となります。このあたりの大変さについては、過去のコラムでも記載しましたので、併せてご参照ください。
執筆時点で、ISMAP登録サービスは75、ISMAP-LIUについては2024年9月に初めての登録サービスが誕生したばかりです。
それなりに増えては来ましたが、世の中に数多存在するクラウドサービス全体からするとごく一部です。またデジタルプラットフォーマーのサービスが複数登録されていること、登録サービスの機能に多少偏りがあることなどから、実際に調達する際の選択肢は、恐らく数字のイメージ以上に少ないでしょう。
このような状況の中、2024年8月に制度改訂があり、9月に制度側より「ISMAP制度改善の取組み」が公表されました。また7月には管理策基準が改訂され、一部要求事項が追加されました。
本稿ではこれらに基づき、制度全体の状況、また追加された要求事項について解説します。
制度改善の取組み
「ISMAP制度改善の取組み」は、ISMAPポータルのこちらのページ にて公開されていますので、詳細を確認されたい場合はリンク先をご参照ください。ここでは主に登録事業者側での対応に関わりが深い点を重点的に取り上げ、それ以外の点については概要のみとします。
制度側としては「制度が担保している安全性・信頼性を保持しつつ、変化の速いクラウド分野に対応すべく常に変⾰していく」というスローガンのもと、これまでの運用から明確化された課題およびその改善策として以下の3点を挙げています。
| ① 課題 | ：外部監査の負担が重い | → | 外部審査の負担軽減 |
| ② 課題 | ：登録審査の期間が⻑い | → | 審査の迅速化・明確化 |
| ③ 課題 | ：関係主体間のコミュニケーション不⾜ | → | 利⽤層の拡⼤、コミュニケーションの深化等 |
このうち①が、特に事業者側に影響する点となります（②・③はどちらかというと制度側の対応事項のため、今回は省略します）。
以前のコラムでも記載した通り、ISMAPの要求事項は極めて多いことから、対応工数が膨大となり、それに比例して監査費用も相当な高額となります。これを登録後も毎年対応せねばならないため、事業者側は継続的に多大な負担を強いられます。 これに対し、制度側は大きく3つの改善策を講じています。
複数年を軸とした外部監査サイクルの導⼊
これはISMAP登録後、更新のための監査時に適用される内容ですが、毎年全ての管理策について監査するのではなく、複数年で全ての管理策を網羅する形とし、1年あたりの監査工数を削減するというものです。
この手法は監査対象期間が2023年10月以降のサービスについて、管理策基準については既に導入されていましたが、今回マネジメント基準にも適用を広げることとなりました。ただしマネジメント基準への適用については、ISMS認証の取得（かつISMSの適用範囲にISMAP登録のサービスが含まれていること）が条件となっています。基本的にISMS認証を取得している場合は、マネジメント基準の大まかな要素については対応できていることが保証されるためでしょう。 なお、初回登録時は全管理策の監査が必要な点は変わらないため、初回の工数・費用負担は残念ながら削減されません。
（「ISMAP制度改善の取組み」より引用）
アップデートテストの見直し
こちらも主に更新時の監査に関する改善になります。
監査の中でも「運用状況評価」については、監査対象期間中の運用記録等の全量を「母集団」として監査法人に提示し、その中から監査法人側でサンプリングして統制状況を確認するといった手続きになります。また、監査法人側は監査対象期間の末日から3か月以内に実施結果報告書を事業者に提出しなければなりません。
監査対象期間が1年間の場合、1年間全ての運用記録等を整理して母集団として提示し、サンプリングを行うといった流れで監査を実施しようとすると、3か月の間に全ての運用状況評価項目を確認した上で実施結果報告書を作成しなければならないため、タイトなスケジュールとなります。
これを改善するため、母集団について、1年間の全量ではなく、監査対象期間の始期から9か月以上の期間を「サンプル抽出期間」として定め、その期間の全量を母集団として提示することが認められました。これにより事業者側は母集団の整理が少しだけ楽になり、監査法人側も評価を前倒しできるため、スケジュールの余裕ができるようになりました。なおその他にも細かい条件があるため、詳細をお知りになりたい場合はISMAPポータルより「標準監査手続」を確認してください。
ただしこの見直しも初回登録時の監査には基本的に影響が無く、また更新監査時にも事業者視点での工数削減効果は薄いと思われます。どちらかと言えば監査法人側の負荷削減効果を狙った改善と言えそうです。
監査対応における証跡等例⽰の公開にむけて
従来、ISMAPの膨大な管理策の一つ一つについて、どのような種別の証跡が必要となるのか、以下の分類で定められていました。
| ● 根拠となる⽂書・記録等①サンプルテストを実施しないもの（設計書、仕様書等） |
| ● 規程・⼿順書等 |
| ● 根拠となる⽂書・記録等②サンプルテストを実施するもの（申請書、承認記録、システムログ、台帳等） |
| ● 根拠となる設定（パラメータ、ステータス、コマンド等） |
| ● 設備・建物等 |
まずこの分類が再整理され、以下の通りとなっています。
| ● 規程・⼿順書・様式等（ルールの整備、運⽤⼿順の確⽴） |
| ● 根拠となる⽂書・記録等（申請書、承認記録、システムログ、台帳等） |
| ● 根拠となる設定（パラメータ、ステータス、コマンド等） |
| ● 設備・建物等 |
元々あった「根拠となる⽂書・記録等①サンプルテストを実施しないもの（設計書、仕様書等）」は廃止され、他の種別に統合されました。
そしてここからが問題なのですが、これまで事業者側には、どの管理策でどの種別の証跡が要求されているのか開示されていません。
そのため、規程等に定めていれば良い（あるいは定めなければならない）のか、記録類があれば良いのか、実際の設定情報を見せなければならないのか、判断が付かないまま監査法人とやり取りを行うこととなり、何度も手戻りを繰り返す羽目になっていました。
監査法人側は当然証跡種別を把握しているのですが、事業者側に伝えてはならないこととなっており、とはいえ必要な種別の証跡を得るためには何とか伝えなければならない、と、恐らくコミュニケーションに苦慮してきたのだろうと思います。これは極めて非効率的で、ただでさえ多大な工数をより押し上げることとなっていました。
この点については制度側としても課題感はあるようで、「今後ISMAP管理基準ガイドブック等を通じてCSPへの公開を順次進めていく」されています。ただし、現状では1100以上ある管理策の内のごく一部、約10程度について解説がなされているに過ぎません（証跡の例示もなし）。
これが全管理策、証跡の例示も含めて記載されるのは恐らく当分先になるでしょう（そもそも全管理策について対応予定なのかどうかもわかりませんが）。正直個人的には、「例示とか後回しでいいからさっさと証跡種別は公開してくれ」というのが本音です。
管理策基準の改訂
2024年7月に、以下の改訂がありました。
| 新設 | 8.1.5.4.P | 12.2.1.15 | 13.2.3.7.P | 16.1.5.10 | |
| 改定 | 7.2.2.18 | 9.1.1.16 | 9.2.3.11.PB | 13.1.3.1 | 13.1.3.5 |
このうち改定については例示等の追加や表現修正などがメインのため、ここでは新設箇所について解説します。 なお、管理策をそのまま記載することは控えさせていただきますので、確認されたい場合はISMAPポータルよりご請求ください。（JIS Q 27014、27017の購入が必要です）
8.1.5.4.P
クラウドサービス利用者のデータを事業者側で抹消する際、暗号化消去を実施することが求められています。
暗号化消去とは、最初のデータの書き込み時から暗号化が実行される場合に使用可能なデータ抹消方法で、暗号鍵を抹消することでデータの復号を不可能にします。処理に時間がかかる上書き消去や、データの完全な抹消に失敗する恐れのある物理的なメディア破壊の代替措置として推奨されています。
もちろん「最初のデータの書き込み時から暗号化が実行される」よう実装されていることが前提ですので、まずは実装状況を確認の上、利用者データの抹消方法について検討する必要があります。
12.2.1.15
マルウェア対策について、検出精度向上や感染リスク低減手段の実施が求められています。
具体的には、シグネチャーベースのマルウェア対策ソフトのみを利用するのではなく、機械学習・サンドボックス機能により未知のマルウェアへの対策を講じることとなります。
多くの場合、マルウェア対策には外部の専門企業のツールを利用されていると思いますので、ツールの機能を確認しましょう。
13.2.3.7.P
サービスにおいてメール送信機能がある場合、なりすましメール対策として、SPF・DKIMのいずれか又は両方による送信元認証、およびDMARCによる認証失敗時の対策について、機能又は設定のための情報を提供することが要求されています。
SPFとDKIMは送信元が適正であることを確実にするための認証機能で、SPFは送信元メールサーバのIPアドレスで、DKIMはメールに付与した電子署名で、それぞれ認証します。
DMARKは、これらの認証が失敗した際に、受信側に推奨するアクションをポリシーとしてあらかじめ設定し、実施させる機能です（例えば認証失敗時には受け取り拒否させるなど）。
なりすましメールは様々なサイバー攻撃の入り口として多用されているため、このような対策が一般的となってきており、例えばGmailでも利用者がSPFまたはDKIM対応することが必須となりました。自社サービスにメール送信機能がある場合は、これらの対策を確実にしましょう。
16.1.5.10
インシデント対応において、実際に検知したものと同様のインシデントが組織内の別の箇所でも発生していないか、必要に応じて確認することが要求されています。
例えばマルウェア感染などは、社内で同時多発的に感染するケースもあったりしますので、被害範囲を正確に把握するために重要なアクションとなります。
このように昨今の脅威動向、技術動向などに合わせ、基準自体も変化していっています。スローガンに「変化の速いクラウド分野に対応すべく常に変⾰」とあるように、今後もこのようなマイナーチェンジは発生するものと思われます。
一方、2024年10月末に開催された、第 29 回 ISMAP 運営委員会の議事要旨を確認すると、「JIS Q 27002の改定等を踏まえたISMAP管理基準の改定について、抜本的な見直しに向けた方針や改定に向けたスケジュールに係る検討状況を報告した。」という恐ろしい記載があります。
現状のISMAPの管理策は、多くの部分がJIS Q 27002：2014の内容に沿ってほとんどコピペされていますが、ISMAP制度が運用開始されて間もない2022年、JIS Q 27002の元となるISO/IEC 27002が大幅に改訂されました（JIS Q 27002も2024年に改訂済）。
一方でISMAPの管理策はここまで上記のようなマイナーチェンジのみとなっており、大きく差分が出ていました。元々の管理策基準のコンセプトからすれば、やはりJIS Q 27002：2024に合わせていきたいというところと思われますが、細かい内容のみでなく、全体構成から大きく差異が出てしまったため、「抜本的な見直し」という表現となっていると考えられます。 ISO/IEC 27002が改訂された時点で想定された事態ではありますが、移行時の監査・審査負担も相当なものになるのではないかと、実務担当者でもある筆者は正直なところ戦々恐々としています。
まとめ
これまで見てきた通り、ISMAP制度側も、登録に向けた過剰な工数負担を課題として認識し、徐々に改善を進めています。しかし、そうはいっても膨大な管理策自体が減るどころか、むしろ増えたり変わったりするため、結局相当な工数が必要となることは変わりません。 当社はISMAP制度の開始当初からのご支援実績を基にした豊富な知見を持ち、また、可能な限りお客様の社内リソースを削減できるフルサポートプランを含め、ご要望に応じたご支援をしております。ISMAP登録をご検討の方は、是非下記のお問い合わせフォームよりお気軽にご連絡ください。
なお、サービス概要についてはこちらを併せてご参照ください。
