ISO27001:2022 何がどう変わったのか？

2022年10月26日にISO/IEC 27001:2022が発行されました。

旧規格で初回認証審査、再認証審査を受けられるのは2024年4月30日まで（審査開始日で起算）であり、新規格への移行期限は2025年10月31日です。

最大3年間の猶予がある中、どのタイミングで規格移行に取り組むのか、予め計画しておく必要があります。

規格移行に関するコンサルティングサービスはISO27001:2022移行支援から確認ください。

ISO27001は規格本文（主にPDCAの枠組みを規定）と附属書A（主に具体的なセキュリティ対策）から構成されており、それぞれの変更の概要は下図のようになります。

規格本文の変更点

規格本文はほとんど変更がないのですが、変更点は下記になります。

附属書Aの変更点

附属書Aは先行して改訂された、ISO27002の内容に沿って改訂されました。

まず、管理作が下記の4つの分類され、体系が大きく変わったことが目をひきます。

・Organization controls（組織的管理措置）

・People controls（人的管理措置）

・Physical controls（物理的管理措置）

・Technological controls（技術的管理措置）

これは個人情報保護法のガイドラインで採用された分類と同じなので、日本企業のセキュリティ担当者には馴染みやすいかもしれません。

主な、変更箇所は下記14点で、クラウドサービスを前提としたセキュリティ対策の実行、サプライチェーンのセキュリティ、監視、脅威インテリジェンスの活用などが注目すべきポイントでしょうか。

それぞれの管理策の解説、対応例を以下に記載します。

なお、ISMS審査においては、具体的にどこまで対応するかについて、組織ごとにある程度幅をもって検討可能ですので、以下に記載した対応を100％実施しなければISMS認証を維持できないというわけではありません。

当社では、それぞれどこまで対応するべきかについても、それぞれのお客様と検討した上で、ISO27001規格改定への対応支援サービスを提供しています。

1.情報セキュリティの脅威に関する情報を収集および分析して、脅威インテリジェンスを作成する（5.7）

脅威インテリジェンスは、端的に言うと、情報セキュリティの脅威による組織への影響評価や対策の検討に活用できる（ようにした）情報です。一部の大企業は、SOC（セキュリティオペレーションセンター）を組織内に設置する又は外部のSOCサービスを利用することで既に脅威インテリジェンスを活用している状況であるため、本管理策が追加されたことの影響は軽微です。一方、SOCの設置やSOCサービスの利用が難しい大企業や中小企業にとっては本管理策への対応は悩ましい状況と思われます。このような組織の当面の着地点は、本文パートの外部課題（状況）の決定（4.1）としても実施する情報セキュリティの脅威情報の収集および対応や、脅威インテリジェンスを活用しているクラウドサービス等の利用になり、継続的な改善として脅威インテリジェンスの活用を図ることになるでしょう。

2.所有者を含む情報およびその他の関連資産の目録を作成し、維持する（5.9）

3.機密性、完全性、可用性、および関連する利害関係者の要件に基づいて、情報を分類する（5.12）

組織は、これらの管理策に対して情報資産の台帳を見直す必要があります。情報資産の所有者（管理責任者）を明記し、また、先の規格改定の際に要求事項としての記載がなくなった、情報資産の機密性、完全性、可用性に関する評価が求められます。

4.認証情報の適切な取り扱いについて利用者に助言する（5.17）

これまでは利用者にルールに従った認証情報の管理を要求することが求められましたが、認証情報の適切な取り扱いに関する助言も含まれることとなりました。これにより、ルールで縛ることができない外部利用者（例えば組織が提供するクラウドサービスの顧客である利用者）への対応も求められてきます。

5.事業継続目標を決定し、ICT継続および情報セキュリティ継続に取り組む（5.29，5.30）

災害などにより事業継続に影響が生じた場合の情報セキュリティの維持復旧に加え、ICT環境の維持復旧が求められます。事業における事業継続目標や求められる事業継続性に応じて、これらの事業継続に関する管理策を実施する必要があります。具体的には、データやシステム環境のバックアップ、システムの冗長化などの実施や、事業影響度分析（BIA）、システムのRTO（目標復旧時間）、RPO（目標復旧時点）の設定、事業継続計画（BCP）の策定などが挙げられます。

6.安全な認証技術を採用する（8.5）

これまでの安全なログオン手順の採用に加え、安全な認証技術の採用が求められます。「認証技術」について言及された背景には、パスワードのみの認証方法では脆弱になってきていることが挙げられます。ISO/IEC27001上では「安全な認証技術」の指定はありませんが、ベストプラクティスを説明するISO/IEC27002では重要な情報システムにおいては多要素認証の採用が推奨されています。

7.構成管理を実施する（8.9）

これまで変更管理の一部として実施されてきた構成管理が独立した管理策となりました。ネットワーク構成やシステム構成などを記録しつつ、最新の状態を維持することが求められます。構成を変更する際は変更管理（8.32）に則ることが求められます。

8.データ漏えい防止策を講じる（8.12）

情報セキュリティの代表的な対策の一つであるデータ漏えい防止策が管理策として追加されました。本管理策は、これまでも要求されていた事項であるため、影響は軽微と思われます。追加された背景としてはDLP（Data Loss Prevention）などデータ漏えい対策のためのツールが普及してきたことがあると思われます。

9.ログを分析し、潜在的な情報セキュリティインシデントを検知し対応する（8.15、8.16）

監視活動（8.16）が追加されました。また、これまでログの「レビュー」が求められてきましたが「分析」が求められることになります。ログの取得、監視という活動の大きな単位ではこれまでも求められてきましたが、これらの要求事項の変更により、より積極的にインシデントの兆候を検知しようという監視姿勢が求められてくることになると思われます。

10.ウェブフィルタリングを実施する（8.23）

マルウェア感染リスクを減らすための管理策として追加されました。対策としては、ウェブフィルタリングツールなどの導入により、業務に必要のないサイトや危険性の高いサイトへのアクセスを制限する、または、危険なサイトへのアクセスを警告するブラウザを利用するなどが挙げられます。また、データ漏えいの防止（8.12）の観点でオンラインストレージなどへのアクセス制限も合わせて検討することは有効です。

11.セキュアコーディングを確立する（8.28）

コーディングを大規模で実施している場合はセキュアコーディング標準の策定を目指しましょう。ウェブサイトであれば、IPAの「安全なウェブサイトの作り方」を参照することとするのも良いと思われます。また、コードレビューやコード解析を実施することとするのも良いでしょう。コーディングを実施しない場合は、適用除外にするか、ノーコード開発（またはローコード開発）を原則とすることを定める選択肢もあり得ます。

12.製品およびサービスの情報セキュリティリスクを管理する（5.19、5.21）

13.組織の情報セキュリティ要件に従って、クラウドサービスの取得、使用、管理、および終了のプロセスを確立する（5.23）

14.アプリケーションの情報セキュリティ要件を決定する（8.26）

これまでは供給者（サプライヤー）とリスクについて合意することが求められましたが、これからは合意することに加え、リスクとして管理することが求められます。具体的には製品、サービスを評価・選定し、利用ケースにおけるリスクを特定し、管理していく必要があります。昨今のサプライチェーンリスクを踏まえたリスク管理が重要になってきます。

また、クラウドサービス管理について独立した管理策が追加されました。クラウドサービス管理においても従来から実施してきていると思われる、評価・選定、利用規約への合意、自社の責任範囲のシステム運用、リスクの特定・管理が求められます。

さらに、アプリケーションの導入に際しても同様の観点による運用が求められます。アプリケーションを自社開発する場合は非機能要件として情報セキュリティ要件を決定し、実装することが求められます。

以上は主な変更箇所について求められる事項をまとめましたが、その他についても、管理策の体系変更に伴い、要求事項の表現も変更されています。ISO27001規格改定に対応する際には、ISO27002規格を参考に、全体の管理策への対応状況について再確認することが求められます。

当社では、ISO27001規格改定への対応支援サービスとして、新規運用構築の検討支援、文書改訂支援等を行っています。移行期限も迫ってきておりますので、未対応の場合、是非【お問い合わせフォーム】よりお気軽にご相談ください。