技術的脆弱性の管理 ISO/IEC27002:2022とNIST SP800-53を比べてみた
前回、「ISO/IEC27002に追加された多要素認証」についての記事を書きました。今回は、同じような形でISO/IEC27002の2022年版で技術的脆弱性の管理に追加されたものについて調べ、NISTの同様の管理策との比較をしてみました。
ISOの2022年版は2013年版からどう変わったか
ISO/IEC27002の2022年版がJIS化されたJIS Q27002:2024を読んでみると管理策「8.8 技術的脆弱性の管理」は2013年版に比べて、なんと2倍以上3倍くらいのボリュームになっていました（2022年版の付属書Bによると2013年版の「12.6.1 技術的脆弱性の管理」と「18.2.3 技術的遵守のレビュー」が2022年版の「8.8 技術的脆弱性の管理」に対応します）。手引きのボリュームが増したので、2022年版では、「技術的脆弱性の特定」、「技術的脆弱性の評価」、「技術的脆弱性に対処するための適切な対策の実施」、「その他の考慮事項」の小見出しがつけられて、４つの節に分けられていました。
情報セキュリティマネジメントシステム（ISMS）では、情報セキュリティ管理策（「マルウェア対策」や「データのバックアップの取得や管理」「アクセス制限」などの対策）を決定し、実施することが求められます。情報セキュリティ管理策を規定する国際規格であるISO/IEC 27002が2022年に改訂されたことを受けて、対応するJISであるJIS Q 27002を改正しました。
情報セキュリティ管理策に係る最新の国際規格とJISの整合が図られることにより、多様化する脅威に対するサイバーセキュリティ対策、クラウドサービスの利用、リモートワークの普及など、情報セキュリティを取り巻く技術や環境の変化への対応が可能となり、我が国の情報セキュリティの向上に一層寄与することが期待されます。
※日本産業標準調査会（JISC）のHP（https://www.jisc.go.jp/）から、「Q27002」でJIS 検索する と本文を閲覧できます。
手引きの主な変更点
2022年版の手引きは、対象が拡大して全般的に詳細化されています。2013年版になかったところで目立つのは、ソフトウェアサプライチェーンが意識された供給者への要求や、ソフトウェアの自動更新、脆弱性スキャン、クラウドサービスなどで、主に脆弱性の特定に関しての手引きが拡充されています。
技術的脆弱性の特定
・供給者への要求
・脆弱性スキャンツールの利用
・認可された者による侵入テスト
・第三者のライブラリ・コードの使用
・調査者が問題を報告できる公開連絡先
・情報共有の場の用意
・バグ報奨金プログラム採用の検討
・力量ある業界団体又は他の利害関係者との情報共有
技術的脆弱性の評価
・報告書の分析と検証
技術的脆弱性に対処するための適切な対策の実施
・ソフトウェアの自動更新
その他の考慮事項
・クラウドサービスを利用する場合のクラウドサービスプロバイダとの合意
NIST SP800-53
「技術的脆弱性の特定」の部分についてNISTではどのような扱いになっているか見てみます。NISTのサイトに、SP800-53とISO 27001:2022の対応表があります。これによると、管理策番号RA-5の「脆弱性の監視及びスキャン」に対応するのがISO27001:2022の付属書A8.8とされていますので、RA-5を読んでみました。NIST SP800-53の最新版のrev5（SP800-53とSP800-53B）の日本語翻訳版はIPAのサイトにあります。SP800-53では、管理策のベースラインを「低」、「中」、「高」と定めていて、それぞれ管理策を実装するシステムの重要度を表します。低、中、高のセキュリティベースラインごとの管理策（５つ）は次のとおりでした。
ちなみに、同内容は、 NIST CPRT を使うと、WEBベースで確認することができます。NIST CPRTについては、以前こちらに記事を書きましたので読んでみてください。
ベースライン低
RA-05脆弱性の監視とスキャン
RA-05（2）脆弱性の監視とスキャン｜スキャンする脆弱性の更新
RA-05（11）脆弱性の監視とスキャン｜公開開示プログラム
ベースライン中
RA-05（5）脆弱性の監視とスキャン｜特権アクセス
ベースライン高
RA-05（6）脆弱性の監視とスキャン｜検出可能な情報
NIST管理策は、ISO27002でどう書かれている？
NISTの５つの管理策がISO27002の箇条8.8にどのように書かれているかを確認したところ以下のとおりで、ISO27002は、スキャンに関する記載が少ないことがわかりました。
ベースライン低
RA-05脆弱性の監視とスキャン
箇条8.8にはかなりの部分で同内容が書かれているものの全部が書かれているわけではない。例えばバグ報奨金プログラムは箇条8.8でも採用の検討をすると書かれています。、
RA-05（2）脆弱性の監視とスキャン｜スキャンする脆弱性の更新
箇条8.8には書かれていない。
RA-05（11）脆弱性の監視とスキャン｜公開開示プログラム
箇条8.8に書かれている。
ベースライン中
RA-05（5）脆弱性の監視とスキャン｜特権アクセス
スキャンするときの特権アクセス許可についてで、箇条8.8には書かれていません。
ベースライン高
RA-05（6）脆弱性の監視とスキャン｜検出可能な情報
外部からの調査で検出可能な情報のことで、箇条8.8に書かれていません。
NIST SP800-53rev4、SP800-171
ついでに、RA-5(11)が2013年版のSP800-53rev4ではどうだったかも見てみました。IPAのサイトに翻訳版は残っていませんが、NISTのサイトにSP800-53rev4がありました。当時は、RA-5(11)が存在していなかったことがわかりました。2021年のSP800-53rev5では、重要度が低のシステムも含めて実装対象とするようになったということになります。
SP800-171はどうでしょうか。rev3を調べてみたところ、直接CUIの機密性に関係しない管理策（NCO）として、SP800-171の要件にはなっていませんでした。ちなみに、SP800-171rev2はSP800-53rev4を元にしていたので、SP800-53rev4には存在していなかったRA-5(11)は要件の候補になっていませんでした。
NCO：The control is not directly related to protecting the confidentiality of CUI.
まとめ
ISO/IEC27001では、ISMSに必要な管理策を組織として決定することが求められていて、決定する際に参照するガイドラインとしてISO/IEC27002があります。2022年版では同じ管理策であっても、改定までの10年間の変化を反映してボリュームが倍増していることがよくわかりました。
ISMS認証の審査では、新規管理策や対象が拡大した管理策についてケアすることは当然として、それ以外の変更がない管理策も手引きが変更されているところは、参考にするのがよさそうです。
NISTとの比較では、SP800-53のベースライン低の管理策であっても、RA-5(2)「スキャンする脆弱性の更新」は、ISO/IEC27002に書かれておらず、RA-05（11）「公開開示プログラム」は書かれていることがわかりました。書かれていなくてもベースライン低の管理策は、必要な管理策かどうかの検討対象にするのがよさそうかと思いました。
最後に、管理策の決定についてNICTの山下氏の2021年の情報セキュリティマネジメントセミナーの講演資料が大変参考になりましたのでご紹介しておきます。スライド26、27のあたりです。
「ISO/IEC 27000ファミリー規格の展開とその活用」
ISO/IEC JTC1/SC27 WG1小委員会、WG4小委員会 山下 真 氏
（国立研究開発法人 情報通信研究機構）
＜概要＞
ISO/IEC 27000ファミリー規格は、ISO/IEC 27001及びISO/IEC 27002と関連する規格群で構成されています。ISO/IEC 27001について解説するISO/IEC 27003、情報セキュリティリスクマネジメントの手引であるISO/IEC 27005、適用分野ごとのISO/IEC 27011（通信事業者向け）とISO/IEC 27017（クラウドサービス利用者・事業者向け）など、約20の文書からなる規格群です。隣接する分野では、サイバーセキュリティ関連のISO/IEC 27100ファミリー、IoTにおけるセキュリティ及びプライバシーを扱うISO/IEC 27400ファミリーがあります。ISO/IEC27002改定版の出版に続くこれらの規格の今後の展開について概観します。
また、今回のISO/IEC 27002改定における膨大な検討の中では、管理策について、その最新化と共に粒度や表現についても特に注意をはらって審議を行いました。新しい管理策群への移行は、情報セキュリティリスクマネジメントにおける管理策の決定とその説明の重要性を再認識する機会にもなります。このプロセスに関係する要求事項を再確認し、その活用の要点をご紹介します。
この記事が気に入ったらサポートをしてみませんか？