コラム

ISO27001改訂！クラウドネイティブを抜き打ち内部監査してみた

セキュリティチームのぐっちーです。ISMSに関する国際規格「ISO/IEC 27001[注1]」が2013年以来の改訂がなされました。ISMS認証を取得している会社は全国に7000社以上もあるので、非常にインパクトがある出来事だと思います。当社もISMS認証を取得していますし、そもそもISMS認証は情シスが大きく関わることも多いので、無視することはできないものです。そんな折角の機会なので、改定後の規格を使って当社を内部監査してみました。（ちょっと話飛んだ！？）

ISMS認証・ISO27001って何だ？

「ISMS認証」とは、組織が構築した「情報セキュリティマネジメントシステム（ISMS）」が、国際規格である「ISO/IEC 27001」に基づいて、適切に管理・運用されていることを第三者認証機関が認証する制度です。よく用語が混同されがちですが、用語の定義としてはざっくりと以下の通りです。

用語ざっくり定義
ISMSリスクアセスメントにより必要なセキュリティレベルを決め、情報の機密性、完全性及び可用性をバランス良く維持・改善し、リスクを適切に管理している仕組み（概念）
ISO/IEC 27001組織が「ISMS」を確立し、実施し、維持し、継続的に改善するための要求事項を提供することを目的として作成された国際規格
ISMS認証ある組織のISMSが「ISO/IEC 27001」に基づいて、適切に管理・運用されていることを第三者認証機関が証明するもの

規格の構造

ISMS認証は国際規格「ISO/IEC 27001」に基づく認証なのですが、実は「ISO/IEC 27001」を読み解くためには他の文書も参照する必要があります。ここでは、それらにも触れながら規格の構造をご紹介します。まず「ISO/IEC 27001」は大きく「本文（要求事項ともいう）」と「付属書A（Annex A）」に分かれます。

「本文」はISMS認証を取得する上では問答無用で実施しなければならない「要求事項」が記載されています。具体的には「リスクアセスメント」や「内部監査」などの内容が該当しますが、セキュリティ施策というよりは、管理の仕組み（マネジメントシステム）に関わる内容です。

一方、「付属書A」には「アクセス制御」や「暗号化」といった情報セキュリティ管理策が記載されています。この「付属書A」と「本文」は密接な関係があり、「本文」で定められるリスクアセスメント等を実施した結果に基づいて、「付属書A」に記載されている管理策を選択し、実装する流れとなります。そのため、リスクアセスメントの結果に基づいて説明責任を果たせるのであれば、「付属書A」に記載されている内容を実施する義務はありません。

しかし、付属書Aの内容はざっくりとしています。以下を例にとると、定められた間隔についてはリスクアセスメントを元に間隔を決めるとしても、どのようにアクセス権をレビューすべきかは全く分かりません。

9.2.5 利用者アクセス権のレビュー
資産の管理責任者は，利用者のアクセス権を定められた間隔でレビューすることが望ましい。

出所：JIS Q 27001:2014[注2]

そこで活用できるのが「ISO/IEC 27002[注3]」です。これは「付属書A」に記載されている管理策の実践のための手引き書となっています。以下のようなことが記載されており、レビュー時に気を付けるべきポイントが明らかとなります。

9.2.5 利用者アクセス権のレビュー
アクセス権のレビューでは，次の事項を考慮することが望ましい。
a)  利用者のアクセス権を，定められた間隔で及び何らかの変更(例えば，昇進，降格，雇用の終了)があった後に見直す(箇条 7 参照)。
b)  利用者の役割が同一組織内で変更された場合，そのアクセス権についてレビューし，割当てをし直す。
c)  特権的アクセス権の認可は，利用者のアクセス権より頻繁な間隔でレビューする。
d)  特権の割当てを定められた間隔で点検して，認可されていない特権が取得されていないことを確実にする。
e)  特権アカウントの変更は，定期的なレビューのためにログをとる。

出所：JIS Q 27002:2014[注4]

ちなみに、「JIS版（JIS Q 27001など）」はISO規格の翻訳版だと思っていただけたら幸いです。

改訂の全体像

ここで本題に戻ります。今回の規格改訂では「ISO/IEC 27001 本文」の一部が微修正された他、「ISO/IEC 27001 付属書A」と「ISO/IEC 27002」が全面改訂されています。

ただし、全面改訂といってもそれは付属書Aの「章立て（文書構造）」に関する部分となります。個々の管理策の記載内容は、改訂前の内容をベースに作られており、それを時代の変化に合わせて加筆修正されています。また、11件ほど全く新しい管理策も取り入れられています。

これは個人の感想ですが、すっごいシンプルで見やすくなったなって思いました。組織的な管理策→IS委員会、人的な管理策→人事、物理的な管理策→総務、技術的な管理策→情シスみたいに担当をざっくり分けると良さそう。

本文も改定がなされていますが、付属書と比べて大幅な改定ではなく微修正にとどまっています。完全に無視できるものでもないですが、表現の修正などがメインとなります。

移行スケジュール

「ISO/IEC 27001」が改訂されたことにより、ISMS認証にも多大なる影響がでます。詳細については認証機関ごとに指針が発表されていますが、日本の認証期間である一般社団法人情報マネジメントシステム認定センター(ISMS-AC)[注5]の指針を例に紹介します。（当社はISMS-ACではありませんが）

まず、現在ISMS認証を取得中の企業に関しては2025年10月31日（2022年10 月31日から3年間）までに、新規格に移行して審査を受ける必要があります[注6]。2025年10月31日以降は旧規格は廃版されるので、移行できなかった場合はISMS認証は無効になります。

また、新規でISMS認証を取得する企業が旧規格で認証審査を受ける期限は2023年10月31日までとなります。移行に際して、ISMS認証を取得中の企業は、ざっくりと以下のようなことをやらなければなりません。

  1. 「ISO/IEC 27001 本文」の改訂に対応する規定の修正（準拠規格の修正 等）
  2. 修正された規定に定められた内容の実施
    1. 改訂された「ISO/IEC 27001 付属書A」に関連したリスクアセスメントの実施
    2. 適用宣言書の修正
    3. リスクアセスメントの結果、必要と判断されたリスクへの対応（管理策の実装・規定の修正）
    4. 内部監査・マネジメントレビュー 等々

内部監査してみた

改訂されたISO27001と当社の既存のルールとのFIT＆GAPを確認したいと思ったので、内部監査をしてみました。実施概要は以下の通りで、Annex A（付属書A）の新規追加項目のみを対象としています。

監査の目的・改訂されたISO27001と既存のルールとのFIT＆GAPを確認すること
・ブログのネタにすること
規格ISO/IEC 27001:2022 Annex A
※ Annex Aのうち新規追加項目のみを対象とする
監査担当ぐっちー
被監査部門（担当者）・情報セキュリティ委員会 ksuke
・セキュリティデータガバナンスセクション murota
・ビジネステクノロジーセクション mori
監査手法・Zoomを使った会議での被監査者への質問
・提示された規定を閲覧
・提示された証跡やクラウドサービスの設定値を確認（サンプル調査）

結果を見る前の注意点

新規格に準拠することの意味合い

監査結果を記載する前に、新規格に準拠することの意味について少しだけ補足させてください。新規格は2022年10月25日に出たばかりの新しい文書ですが、この規格に準拠していると「最先端の対策を取り入れている」というわけでは決してありません。

ISOの規格は作成開始から公開まで5年以上かかり、且つ一度定められたら中々変わらないので、最先端というよりは、実績が積み上がった対策が中心です。また、これは私見ですが、具体的に改定された管理策を見ると「今更感」がある内容がほとんどです。後ほど紹介する新規追加された管理策（トピック）も、ここ5年〜10年で様々な議論がされ尽くした内容であり、重要なトピックスであることには間違いないですが、新しい概念では全くありません。

「JIS Q 27001:2014」Annex Bなどには、国際規格が作られるまでの経緯などが記載されています。それを見るとこのこの規格が最先端のものではないことが読み取れると思います。「日本はXXXを提案したが採用されなかった」みたいなことが書いてあって、個人的には結構面白い読み物です。

その上で、新規格に準拠することの意味合いについては以下のようなものがあると思います。

組織の例新規格に準拠することの意味合いの例
ISMS認証を取得している組織組織としてISO27001に準拠してセキュリティ体制を構築するという方針を掲げていることになるので、その責務を果たす
ISMS認証を取得していない組織権威的な団体が出す指針に基づいて網羅的な対策を行っている
意味合いの例の表

その他、免責事項

  • 繰り返しとなりますが、管理策の実施レベルはリスクアセスメントの結果に基づいて決定するものです。また、下記の施策を実施すれば、ISMS認証の審査において指摘が入らないことを保証するものでもありません。組織ごとに必要な対策は異なりますので、あくまで参考程度にご覧ください。
  • 下記で紹介する各管理策は1つ1つが一冊の本が書けるほどの大きなトピックであることが多いです。例えば、最初に紹介している「脅威インテリジェンス」などは、それだけを取り上げた400ページぐらいの専門書がでてるぐらいです。解説も載せていますが、あくまでISOの規格の範囲での解説であり、専門的に各管理策を知りたい場合は別文書を参照ください。
  • この情報開示が当社にとっての脆弱性とならないように、多少表現はぼかしています。ご了承ください。

監査報告書

概要

監査結果の区分件数該当する管理策番号
適合8件・A.5.7
・A.5.30
・A.7.4
・A.8.9
・A.8.10
・A.8.12
・A.8.16
・A.8.23
改善の機会3件・A.5.23
・A.8.11
・A.8.28
軽微な不適合0件ー
重大な不適合0件ー

A.5.7 Threat intelligence（脅威インテリジェンス）

Information relating to information security threats shall be collected and analysed to produce threat intelligence.（筆者意訳：情報セキュリティの脅威に関する情報を収集・分析し、脅威情報を作成すること。）

出所：ISO/IEC 27001:2022

簡単な解説

この管理策では、定められたソースから作成された脅威の情報を受け取り、それを分析した上で、脅威の影響を軽減するために利用するプロセスを整備することが望まれています。具体的な情報源に関してはISOの規格では定められておらず、組織が決定していくものですが、IPAやJPCERTから出される情報を確認する例を良く見ます。

また、収集して対応が必要であると判断された脅威情報の利用方法としては、ファイアウォールやIPS/IDS、マルウェア対策製品の検出のインプットとして利用することや、セキュリティ機構としての対応が難しい場合はユーザーに周知（教育）することが考えられます。

評価結果

以下の点を評価して【適合】とします。

  • 攻撃は「脅威」と「脆弱性」が重なった時に成功することから、Microsoft Defender for EndpointのTVM（Threat & Vulnerability Management）[注7]で脅威と脆弱性を統合して管理する取り組みが行われていました。具体的には、組織が抱えている脆弱性をTVMで検出した上で、その脆弱性に紐づく脅威の情報（例えば、Exploit kitが作成されているかなど）と照らし合わせて優先順位を決定し、対応を行なっていました。
  • また、同じくMicrosoft Defender for Endpointを利用して、影響度の高い脅威や露出の高い脅威を特定し、露出の高い脅威に対しては、MDMによるポリシーの配信やAttack Surface Reduction（攻撃面の縮小ルール）[注8]などでリスク軽減策が講じられる体制が整えられていました。
  • さらに、Microsoft Sentinelでは、指定されたIoC[注9]の情報に合致するものを発見した場合、通知を上げるような分析テンプレートが有効化されていました。
  • 加えて、脅威の情報を含む情報セキュリティに関するニュースがSlackに配信されるように設定されており、情報を受けた従業員が、必要に応じて対応する仕組みや文化が醸成されていました。

A.5.23 Information security for use of cloud services（クラウドサービスの利用に関するセキュリティ）

Processes for acquisition, use, management and exit from cloud services shall be established in accordance with the organization’s information security requirements.（筆者意訳：クラウドサービスの取得、利用、管理及び終了のプロセスは、組織の情報セキュリティ要求事項に従って確立されなければならない。）

出所：ISO/IEC 27001:2022

簡単な解説

この管理策では、クラウドサービスの導入・利用・終了などのライフサイクルにわたって管理するためのプロセスを整備することが要求されています。具体的な内容としては、クラウドサービス利用と管理に関する役割・責任や利用範囲、セキュリティの要求事項（XXの機能を有する）、監視方法などが挙げられます。

評価結果

以下の点を評価して【改善の機会】とします。

  • クラウドサービスの導入時・利用のプロセスや順守事項（SSOなどの最低限のセキュリティ要件等を含む）について、社内規定として整備されていることを確認しました。
  • しかし、その手順にはクラウドサービス利用終了時のプロセスや注意事項が記載されておらず、現場任せである旨回答がありました。
  • ただし、クラウドサービス利用終了時のリスクに対しても、変更管理のルールや、当社が大事にする「従業員間のコミュニケーション」等によりリスク軽減されている状況は確認できました。
  • 常に新しいサービスを検証するという事業性質上、「クラウドサービスの利用終了」というイベントは発生しやすいものと考えます。それによりクラウドサービスの利用終了時には、必要に応じてデータの削除や、格納しているデータの移行などを行うことが望ましいため、それらのプロセスも同様の規定に追記することが望まれます。

A.5.30 ICT readiness for business continuity（事業継続のためのICTの備え）

ICT readiness shall be planned, implemented, maintained and tested based on business continuity objectives and ICT continuity requirements.（筆者意訳：事業継続目標及びICT継続要件に基づき、ICTレディネスを計画、実施、維持及びテストしなければならない。）

出所：ISO/IEC 27001:2022

簡単な解説

この管理策では、ICT（Information and Communication Technology）サービスの中断によって発生するビジネスインパクトの分析結果に基づいて、サービス障害時の復旧計画を定めたり、定めた計画が機能するものなのかをテストすることなどが求められています。

評価結果

以下の点を評価して【適合】とします。

  • ICTの中断を含む事業継続リスクに関してのリスクアセスメントがなされていました。
  • リスクアセスメントの結果に基づき、事業継続計画が作成されていました。
  • 計画のうち従業員が実際に実施する必要がある部分に関しては、定期的に教育や訓練を行なっていました。
  • 結果をトップマネジメントに報告して、フィードバックをもらっていました。

A.7.4 Physical security monitoring（物理的セキュリティの監視）

Premises shall be continuously monitored for unauthorized physical access.（筆者意訳：敷地内は、不正な物理的アクセスがないよう継続的に監視すること。）

出所：ISO/IEC 27001:2022

簡単な解説

この管理策では、施設（オフィスやデータセンターなど）に関して、不正なアクセスが発生しないように継続的に監視することが求められています。旧規格にも似たような管理策として「入退室管理」に関連するような管理策がありましたが、よりリアルタイム性が高まったというイメージです。

監視のレベルは当然、施設にある情報の重要度やリスクアセスメントの結果によって変わってきますが、重要情報が格納されたサーバーなどがある場合は、警備員や侵入者センサーなどを設置したり、セコム等の法人向け監視ソリューションを導入することなどが考えられます。

評価結果

以下の点を評価して【適合】とします。

  • 前提として当社は WeWorkに本社を構えています。
  • ビルの入り口から、WeWorkの当社エリアまでに関しては、ビルの管理会社やWeWork社によって監視カメラが設置され不正にアクセスされないように継続的に監視がなされていました。
  • 当社エリアに関しては、監視用のWEBカメラによって記録・録画されており、当社エリアで行われる作業について記録されていました。
  • 当社において24時間の人力での監視や侵入者センサーやアラーム等を使ったような監視は行われていませんでした。しかし、WeWork社やビル管理会社で行っている監視・警備、当社が行っている入退室管理・記録、保管されている情報資産の重要度、保管方法などを考慮して十分な対策が行われていると考えている旨の回答がありました。

A.8.9 Configuration management（構成管理）

Configurations, including security configurations, of hardware, software, services and networks shall be established, documented, implemented, monitored and reviewed.（筆者意訳：ハードウェア、ソフトウェア、サービス、ネットワークのセキュリティ設定を含む設定を確立し、文書化し、実施し、監視し、見直すものとする。）

出所：ISO/IEC 27001:2022

簡単な解説

この管理策では、まず、ハードウェア、ソフトウェア、サービス、ネットワークの構成に関して、「期待された状態」を定義することが望ましいとされています。期待された状態というのはセキュリティベンダーが権威的な団体が出すドキュメントをベースに、リスクアセスメントの結果や、実現可能性などを総合的に見て定義することがガイダンスされています。そして、それが守られていることを監視するためのプロセスやツールを定義するとともに、それを実施する役割や責任を割り当てたり、手順化することが望ましいとされています。

これは特に言うは易く行うは難しな項目ですが、突き詰めてやるとしたらInfrastructure as code[注10]やCSPM[注11]ツールの活用などで自動化するとよいとガイダンスされていました。

評価結果

以下の点を評価して【適合】とします。

  • 社内規定に、ハードウェア、ソフトウェア、サービス、ネットワークのセキュリティ設定の遵守事項が定められていました。
  • これらのうち、監視する必要があり、且つ監視可能なものについては、Microsoft SentinelやMicrosoft Defender for Cloud Appsで監視がなされており、アラートをトリガーにセキュリティ・データガバナンスセクションの担当者が調査する体制が整っていました。
  • 監視がなされていた構成のサンプルとしては以下のようなものがあった。
    • Microsoft Defenderのアンチウイルス機能がアクティブに動いていない状態となった。
    • AWSのセキュリティグループが変更された。
    • Workatoのコネクションに関して社内で定めた命名規則に反しているものが作成された。

A.8.1 Information deletion（情報の削除）

Information stored in information systems, devices or in any other storage media shall be deleted when no longer required.（筆者意訳：情報システム、機器、その他の記憶媒体に保存された情報は、不要になった時点で削除する。）

出所：ISO/IEC 27001:2022

簡単な解説

この管理策では、センシティブな情報の不必要な露出を防ぎ、法律、法令、規制、契約上の要求を遵守するために、情報は不要となった時に削除することが求められています。実践のためには、法令等を気にしながら情報の保持期間や削除方法などのポリシーを定義し、定義に基づいて削除を行い、その結果を証跡として記録することなどが必要となってきます。

評価結果

以下の理由により【適合】とします。

  • 機器（主にWindowsおよびmacOS）に関して、不要になった際のデータ削除の手順が定められており、手順に則って削除されている証跡も確認できました。
  • 社内規定に基づいて削除を要する情報資産（例えばeKYCの記録など）に関しては、Boxのリテンションポリシー[注12]等を利用して、一定期間が経過した後、自動的に削除される仕組みが構築されていました。

A.8.11 Data masking（データマスキング）

Data masking shall be used in accordance with the organization’s topic-specific policy on access control and other related topic-specific policies, and business requirements, taking applicable legislation into consideration.（筆者意訳：データマスキングは、アクセス制御に関する組織のトピック別ポリシー及びその他の関連するトピック別ポリシー、並びに適用される法令を考慮したビジネス要件に従って使用されなければならない。）

出所：ISO/IEC 27001:2022

簡単な解説

この管理策では、データマスキングについて触れられています。目的としてはPIIなどのセンシティブなデータを保護するためですが、ただ「マスキングしなさい」ということではありません。あるデータのうち、一部の記録についてはユーザーに見せてはいけない場合などに該当する場合は、アクセス制御方針や、法令・規制等を考慮してにマスキングを行うことが求められていると解釈できます。

評価結果

以下の理由により【改善の機会】とします。社内向けデータのマスキング技術の採用要否について、現状のアクセスコントロールの設計や、当社が大事にする文化（情報の透明性）、プライバシー、業務上の必要性などの観点を総合的に考慮した上で検討し、その検討結果を文書化することが望まれます。

  • ブログ等で画像データを社外にアップロードする際には、必要に応じてマスキング処理が行われていました。
  • しかし、社内向けの情報に関するデータマスキング技術の利用について、社内規定では何も言及されておらず、データマスキングの実施についてのリスクアセスメントの結果も残っていませんでした。
  • ただし、特別に社内で配慮を要する情報に関しては、アクセス権限のコントロールなどでその要件を達成しているが、マスキングに関しては厳密に定義されていない（現場任せの部分がある）と説明がありました。
  • 一方で、一部のセキュリティ製品（Microsoft 365やNetskope等）には、従業員のプライバシーを保護するためのデータマスキング機能があるため、リスクアセスメント等の結果に基づき、これらの技術の活用も考えられます。

A.8.12 Data leakage prevention（情報漏洩防止対策）

Data leakage prevention measures shall be applied to systems, networks and any other devices that process, store or transmit sensitive information.（筆者意訳：機密情報を処理、保管、伝送するシステム、ネットワーク、その他の装置には、情報漏洩防止対策を施さなければならない。）

出所：ISO/IEC 27001:2022

簡単な解説

この管理策では、情報漏洩を防止するために、まずは情報の重要度を識別・分類した上で、データ漏洩の経路を監視・制御することが求められています。ISO 27002では機密情報を識別し、その認可されない漏洩を検知し、ブロックするためのツールを利用することなどがガイダンスされていました。

個人的な特筆すべき点としてはISO/IEC 27002:2022において、「スクリーンショットや画面の写真を撮ることは、利用規約やトレーニング、監査を通じて対処すべきです。」と言い切られていた点です。日本国内では良く聞く要件ですが、海外と日本の文化の違いをまじまじと感じることができました。

評価結果

以下の理由により【適合】とします。

  • Netskope[注13]のCASB機能を利用して、SSL通信を複合した上で検疫し、不正な情報の持ち出しを検知可能とする体制が構築されていました。
  • また、NetskopeのAPI Introspection[注14]を利用してNetskopeとSaaSを連携し、個人向けのGmailアカウントへの情報の持ち出し等を検出するようなポリシーなどが設定されていました。
  • さらに、重要なコンテンツが多く格納されているBoxに関しては、フォルダ設計などによって情報漏洩が起きにくいような配慮を行っていると同時に、大量ダウンロード等の不審な挙動を検知した際にはアラートを上げる設定としていました。
  • 万が一、情報漏洩が発生した場合の証拠保全・否認防止の目的で、従業員の端末のバックアップデータがDruva[注15]によって保持されていました。

A.8.16 Monitoring activities（監視）

Networks, systems and applications shall be monitored for anomalous behaviour and appropriate actions taken to evaluate potential information security incidents.（筆者意訳：ネットワーク、システム、アプリケーションの異常な挙動を監視し、情報セキュリティ事故の可能性を評価するために適切な措置を講じるものとする。）

出所：ISO/IEC 27001:2022

簡単な解説

この管理策では、ネットワーク、システム、アプリケーションの異常な挙動を監視し、情報セキュリティ事故の可能性を評価するために適切な措置を講じることが求められています。具体的には、正常な動作の「ベースライン」を確立し、このベースラインに照らし合わせて異常を監視することがガイダンスされていました。製品を入れて終わりではなく、自社の環境と向き合うことの重要性が読み解けます。

評価結果

以下の理由により【適合】とします。

  • 様々な情報システムから発生したログをSIEM製品（Microsoft Sentinel）に収集し、収集したログデータを複数の分析ルールを使って分析を行った上で、セキュリティ事故が疑われる事象を発見した場合は、アラートを上げるように設定されていました。
  • セキュリティ・データガバナンスセクションの担当者はアラートを毎営業日に開催される会議（Sentinelのお世話会）で確認し、アラートの重要度や調査の必要性に応じて、調査を行っていました。
  • また、緊急度が高いものに関しては、Slackに通知され会議を待たずして調査が行われる体制を構築していました。

A.8.23 Web filtering（Webフィルタリング）

Access to external websites shall be managed to reduce exposure to malicious content.（筆者意訳：外部ウェブサイトへのアクセスは、悪意のあるコンテンツにさらされないように管理されるものとする。）

出所：ISO/IEC 27001:2022

簡単な解説

この管理策では、マルウェアによるシステムの侵害を防ぎ、不正なウェブへのアクセスを防止するため、Webフィルタリングを実施することが求められています。該当するIPアドレスやドメインをブロックしていく方法が紹介されている一方で、これを自動的に行うことができるツールを導入して、防御することなどについても言及がなされていました。

また、この統制を導入する前に、組織は、不適切なWebサイトやWebベースのアプリケーションへの制限を含め、オンラインリソースを安全かつ適切に使用するためのルールを確立する必要があるとも言及されており、さらには、安全かつ適切な使用方法について、従業員にトレーニングを行うべきであるともガイダンスされていました。

評価結果

以下の理由により【適合】とします。

  • Netskopeでは、Web経由での不正なスクリプトやプログラムを実行させるような攻撃を防御をするCTEP（Client Traffic Exploit Prevention）[注16]が有効化されていました。
  • また、同じくNetskope SWGのカテゴリーフィルター機能を利用して、Netskope社が定義するフィッシングサイトなどに該当しそうなサイトをブロックする設定がなされていました。

A.8.28 Secure coding（セキュアコーディング）

Secure coding principles shall be applied to software development.（筆者意訳：ソフトウェア開発には、セキュアコーディングの原則を適用すること。）

出所：ISO/IEC 27001:2022

簡単な解説

この管理策では、ソフトウェアに潜在する脆弱性の数を減らすために、最低限のセキュアなベースライン「セキュアコーディングの原則」を社内のルールとして定めた上で、それをプログラマが遵守できるように仕組み化していくことが求められています。

「セキュアコーディングの原則」には、企画・コーディング前段階、コーディング中、レビュー、メンテナンスというそれぞれの段階においての考慮事項が含まれており、具体的にはペアプログラミング、リファクタリング、ペアレビュー、テストなどに言及されています。

評価結果

以下の理由により【改善の機会】とします。

  • 社内規定では「セキュアコーディングの原則」が定められていませんでした。
  • しかし、当社はクラウドサービスの利用を前提とし、開発を行う場合でもWorkato等のiPaaS製品が中心となっており、そもそも「コーディング業務」自体が限定的である旨回答がありました。また、「コーディング業務」に関連するリスクに関しては他の管理策（変更管理 等）で対応している旨、回答がありました。
  • さらに、関連するリスクアセスメントの結果も文書化されていました。
  • ISO27001の規格の改定に伴い再度リスクアセスメントを実施し、「セキュアコーディングの原則」の必要性について検討することが望まれます。
  • 必要に応じて、本管理策を非採用とし、適用宣言書に記載することも考えられます。

終わりに

当社においてもISMSの移行作業はこれからというステータスですが、ISMS認証の規格改訂は7,000社が直面している課題なので、これからも移行の時の課題やナレッジをオープンにしていけたら嬉しいなと考えています。質問などございましたら、お気軽にお問い合わせください。

Q＆A

SNS等で質問をいただけたらここに追記いたします。

このブログでは「今回の改訂で新規追加された管理策」を取り上げていますが、「今回の改訂で新規追加された管理策」か否かは、どうやって判定しましたか？

「ISO/IEC 27002:2022」のAnnex B（付属書B）に新規格と旧規格の管理策のマッピング表があります。ここでは、新規格で新しく追加された管理策が「New」と表示されています。また、旧規格の管理策番号も記載されているので、新旧規格のFIT&GAP分析を行う際にはそちらを使うと便利です。ISOの規格は引用できる分量に制限があるため、このブログには記載しませんが「ISO/IEC 27002:2022」をご購入してご確認ください。

なぜ、できていない管理策（改善の機会）までブログで取り上げるのか？大丈夫なの？

ISO 27001の付属書Aの部分（ISO 27002）は必ず実施するものではありません。リスク評価を元に、やらないと判断することも1つの選択肢ですので、その辺の考え方も含めて参考になるものがあればと思ってあえて書きました。また、今はできてないことを堂々と「できてない」と言える稀有なタイミングだからという側面もあります。

一方で、ISMS認証を取るならば、ISO 27001の本書の部分に関しては問答無用でやってくださいね♪

ISO/IEC 27001やISO/IEC 27002は日本語訳（JIS化）されているのか？

2022年11月1日時点では、ISO/IEC 27001やISO/IEC 27002はまだ公式の日本語訳（JIS版）は出ていません。

改訂されたISO/IEC 27001で審査ができるのはいつから？

2022年11月1日時点では、改訂されたISO/IEC 27001で審査ができる会社について、私の観測範囲ではまだ出てきていません。審査会社としても審査員のトレーニング等を行わないといけないと思うので、それなりに時間はかかるものと思います。詳細はISMS審査会社にお問い合わせください。

注釈

  1. ISO/IEC 27001 https://www.iso.org/isoiec-27001-information-security.html
  2. JIS Q 27001 https://www.jisc.go.jp/app/jis/general/GnrJISNumberNameSearchList?toGnrJISStandardDetailList
  3. ISO/IEC 27002 https://www.iso.org/standard/75652.html
  4. JIS Q 27002 https://www.jisc.go.jp/app/jis/general/GnrJISNumberNameSearchList?toGnrJISStandardDetailList
  5. ISMS-AC https://isms.jp/isms/index.html
  6. ISMS適合性評価制度　ISO/IEC 27001:2022 への対応について https://isms.jp/topics/news/20221025.html
  7. Microsoft Defender for EndpointのTVM（Threat & Vulnerability Management）https://learn.microsoft.com/en-us/microsoft-365/security/defender-vulnerability-management/?view=o365-worldwide
  8. Microsoft Defender for Endpoint (MDE) 攻撃サーフェイス削減 (ASR) ルールの展開の概要 | Microsoft Learn https://learn.microsoft.com/ja-jp/microsoft-365/security/defender-endpoint/attack-surface-reduction-rules-deployment?view=o365-worldwide
  9. IoC：「Indicator of Compromise」の略でサイバー攻撃の痕跡をデータベース化して技術仕様として活用すること
  10. Infrastructure as Code：コードやスクリプトを使用してインフラのプロビジョニングと設定を自動的に行う方法（具体例→https://blog.cloudnative.co.jp/12634/）
  11. CSPM：「Cloud Security Posture Management」 の略でクラウドサービスが「期待された状態」となっているかを自動でチェックしたり、レギュレーションと設定の対応状況を見ることができるソリューション
  12. Box リテンションおよびリテンションポリシー：リテンションポリシーを使用すると、指定した期間、特定のコンテンツをBoxに保持し、その期間の終了時にコンテンツを削除することができます。 https://support.box.com/hc/ja/articles/360043694374-%E3%83%AA%E3%83%86%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%8A%E3%82%88%E3%81%B3%E3%83%AA%E3%83%86%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BC%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
  13. Netskope https://cloudnative.co.jp/product/Netskope
  14. NetskopeのAPI Introspection：NetskopeとSaaSがAPI連携することで、管理下のSaaS内のコンテンツやユーザーアカウントのアクティビティの可視化と制御が可能となる機能
  15. Druva https://www.druva.com/ja/
  16. CTEP（Client Traffic Exploit Prevention）https://docs.netskope.com/en/client-traffic-exploit-prevention.html

ぐっちー

コンサル会社にてISO27017やISMAP等のセキュリティ規格案件を経験した後、クラティブに転職。趣味はダンス（Soul, Lock, Waack）です。

記事一覧

株式会社クラウドネイティブは、情報システム部門のコンサルティング専門家集団です。 ゼロトラストの概念を国内でいち早く取り入れ、現実的に実装できる国内唯一のコンサルティング会社です。 「どの製品選べばいいの？」 「社内インフラ改革はどこから？」 「セキュリティって結局どうすれば？」 その疑問や不安にお応えします。

詳しくはこちら →