TL;DR
ISO 27001は、情報セキュリティリスクを管理するための世界標準規格である。スコーピング、リスクアセスメント、附属書Aの管理、監査など、安全なISMSを構築し維持する方法を定義している。
SOC 2よりもプロセスが多いが、対象範囲は広い。国際的に事業を展開する場合や、拡張性のあるリスクベースのセキュリティフレームワークを求める場合には不可欠。
ISO 27001スコアカードの概要:
- 開発者の労力:中程度から高程度(安全な SDLC ポリシーの遵守、リスクアセスメントへの参加、A.12/A.14 のようなコントロールの証拠の提出が必要)。
- ツール費用:中程度から高い(監査費用が大きい、潜在的なISMSソフトウェア、セキュリティツール)。
- 市場への影響非常に高い(世界的に認知された基準、国際ビジネス、規制産業、大企業にとって重要)。
- 柔軟性:高い(フレームワークアプローチ、SoAを通じたリスクに基づく統制の選択)。
- 監査の強度:高(初回認証の第1段階および第2段階、年次サーベイランス審査、プロセスと文書化に重点)。
ISO 27001とは何か?
ISO/IEC 27001は、情報セキュリティに焦点を当てた主要な国際規格です。国際標準化機構(ISO)と国際電気標準会議(IEC)が共同で策定したもので、情報セキュリティマネジメントシステム(ISMS)を組織の中で確立、実施、維持し、継続的に改善するための要求事項を規定している。
ISMSは単なる技術的なツールの集合ではなく、企業の機密情報を安全に管理するための体系的なアプローチです。ISMSには、人、プロセス、技術が含まれる。中核となる考え方はリスク管理であり、脅威と脆弱性を特定し、リスクを評価し、許容可能なレベルまで軽減するための管理策を実施する。
ISO 27001の主な構成要素:
- 条項4~10:これらは、組織の状況の理解、指導者のコミットメント、計画(リスクアセスメントと処置)、支援(資源、認識、文書化)、運用、パフォーマンス評価(モニタリング、内部監査、マネジメントレビュー)、改善というISMS自体の必須要件を定義している。
- 付属文書A:これは、14の領域(ただし、2022年版では4つのテーマで93の統制に改訂された)にグループ化された114の情報セキュリティ統制の参考セットを提供するものである。組織は、適用可能性宣言書(Statement of Applicability:SoA)を通じて、リスクアセスメントの結果に基づいて、附属書Aから関連する管理策を選択する。すべての管理が必須というわけではなく、特定されたリスクに対処するために必要な管理のみが対象となる。
SOC 2が認証報告書となるのとは異なり、ISO 27001は外部監査(ステージ1およびステージ2)に合格すると正式な認証となります。この認証は通常3年間有効で、維持するためには毎年サーベイランス監査が必要です。
なぜ重要なのか?
ISO 27001認証は、特にグローバルに事業を展開するハイテク企業や機密データを扱う企業にとって、大きな重みを持つ:
- 国際的な認知度情報セキュリティ管理の世界標準として最も広く認知されており、世界的な信頼性を高めている。
- 包括的なセキュリティ管理:構造化されたリスクベースのアプローチを強制し、技術的な管理だけでなく、全体的なセキュリティ態勢を向上させる。
- 顧客とパートナーの信頼:SOC 2と同様、セキュリティを真剣に考えていることを顧客やパートナーに示す強力なシグナルとなり、契約書やRFPで求められることも多い。
- 法規制の遵守: ISO 27001ISMSの導入は、体系的なリスク管理を実証することで、さまざまな法律や規制(GDPRなど)の要件を満たすのに役立ちます。
- 侵害リスクの低減:ISMSが適切に実施されることで、セキュリティ・インシデントの可能性と影響が明らかに減少する。例えば、トヨタはサイバー攻撃を受けて生産停止に直面したが、強固なISMSはそのような混乱を防ぐのに役立つ。
- 組織とプロセスの改善:セキュリティの取り組みに構造をもたらし、責任を明確にし、セキュリティを意識する文化を醸成する。
SOC 2は、米国のSaaS顧客の要求によって推進されることが多いですが、ISO 27001は、セキュリティ管理システム全体について、より広範で国際的に認められた保証を提供します。
何をどのように実施するか(技術・政策)
ISO27001の導入は、ISMSとリスクマネジメントを中心とした構造化されたプロセスである:
- 範囲の定義:組織のどの部分、場所、資産、技術をISMSの対象とするかを明確に決定する。
- リーダーシップのコミットメント:トップマネジメントの賛同とリソースを得る。
- ポリシーを定義する:高レベルのセキュリティポリシー(情報セキュリティポリシー、利用ポリシーなど)を策定する。
- リスク評価:情報資産、脅威、脆弱性、既存のコントロールを特定する。リスクの可能性と影響を分析する。
- リスク処置:許容できないリスクを軽減するための管理策(主に付属書Aから)を選択する。これを適用可能性報告書(SoA)に文書化し、含まれる/除外される管理策を正当化する。
- コントロールを導入する: 選択した技術的および手続き的な管理を展開する。多くはSOC 2と重複するが ISO 27001 附属書Aには具体的なカタログが掲載されている:
- A.5 情報セキュリティ方針:マネジメントの方向性。
- A.6 情報セキュリティ組織:社内組織、モバイル機器、テレワーク。
- A.7 人材セキュリティ:雇用前、雇用中、雇用後のセキュリティ責任。
- A.8 資産管理:在庫、所有権、許容される使用、分類、メディアの取り扱い。
- A.9 アクセス管理:ビジネス要件、ユーザーアクセス管理、ユーザーの責任、システム/アプリケーションアクセス。(RBAC、MFAなどを含む)。
- A.10 暗号:暗号管理、鍵管理に関する方針。
- A.11 物理的および環境的セキュリティ:安全なエリア、設備のセキュリティ
- A.12 運用セキュリティ:手順、変更管理、マルウェア対策、バックアップ、ログ記録、監視、脆弱性管理。(SAST、SCA、パッチなどを含む)。
- A.13 通信セキュリティ:ネットワークセキュリティ管理、情報転送。(ファイアウォール、転送中の暗号化を含む。)
- A.14 システムの取得、開発、保守:開発におけるセキュリティ要件、安全な開発方針、テストデータのセキュリティ。(セキュアな SDLC の実践)
- A.15 サプライヤーとの関係:サプライヤー契約におけるセキュリティ、サプライヤーサービスの監視。(ベンダー管理)
- A.16 情報セキュリティインシデント管理:責任、対応、インシデントからの学習
- A.17 事業継続マネジメントにおける情報セキュリティの側面:計画、実施、検証(災害復旧)
- A.18 コンプライアンス:法的/契約上の要件の特定、知的財産権、プライバシー(個人情報保護)、情報セキュリティの見直し。
- トレーニングと意識向上:従業員に対して、ポリシーとセキュリティに関する責任を教育する。
- モニタリングとレビュー統制の有効性を継続的に監視し、内部監査を実施し、マネジメントレビューを行う。
- 継続的改善:モニタリング、監査、リスクの変化に基づいてISMSを更新する。
リスクを特定し、コントロールを確実に実施し、監視し、改善するためのプロセスであるマネジメント・システムに重点を置いている。
避けるべき一般的な間違い
ISO 27001を効果的に導入するということは、このような頻発するエラーを回避するということである:
- 不適切な範囲設定:ISMSの範囲が広すぎる(管理できない)、または狭すぎる(重要な資産/プロセスをカバーしていない)。現実的でリスクに焦点を当てたものであること。
- 経営陣のコミットメントの欠如:目に見えるリーダーシップの支援、リソース、事業目標への統合がないまま、ISO 27001を純粋にITプロジェクトとして扱うこと。
- 不十分なリスクアセスメント:表面的なリスクアセスメントを実施し、主要な資産、脅威、脆弱性を正確に特定しないため、効果的なコントロールの選択ができない。
- 附属書Aの "チェックボックス "アプローチ:附属書Aのコントロールを、アセスメントで特定された特定のリスクと関連付けることなく実施すること。コントロールはリスクを扱うべきである。
- 不十分な文書化:方針、手順、リスクアセスメント、SoA、統制運用の証拠を適切に文書化していない。監査人は証拠を必要とする。
- 継続的改善を忘れる:認証取得を最終目標とすること。ISO 27001では、継続的なモニタリング、内部監査、マネジメント・レビュー、ISMSの更新が義務付けられています。
- 人材不足:十分な時間、予算、専門知識を持たずに、すべての取り組みを一人の人間やチームに任せること。組織全体の取り組みである。
監査役が質問すること(開発者フォーカス)
ISO 27001の監査員は、管理システムと実施された管理の両方を見ます。開発チームは、次のような附属書Aの管理に関する質問に直面する可能性があります:
- "安全な開発方針を示せ"(A.14.2.1)
- 「要求事項の段階でセキュリティ要件を確実に特定する方法を教えてください。(A.14.1.1)
- 「オープンソースライブラリの脆弱性管理のプロセスについて教えてください。(A.12.6.1「技術的な脆弱性管理」関連)
- 「開発環境、テスト環境、本番環境はどのように分けられていますか?(a.12.1.4 / a.14.2.6)
- 「最後のメジャーリリース前に実施したセキュリティテストの証拠を提示する。(a.14.2.8 / a.14.2.9)
- "開発者のさまざまな環境へのアクセスコントロールはどのように管理していますか?"(A.9)
- "試験データの取り扱いと保護の手順を示してください。"(A.14.3.1)
- "配備前のコード変更はどのようにレビューされ、承認されますか?" (a.12.1.2 / a.14.2.3)(a.12.1.2 / a.14.2.3)
彼らはプロセスと 証拠を重視する。方針があるか、それに従っているか、それを証明できるか。
開発チームのクイックウィン
ISO 27001は広範囲に及ぶが、開発チームはこれらのステップで大きく貢献できる:
- SDLC を文書化する:テストと配備のステップを含めて、現在の開発プロセスを書き出してください。これは、A.14 の管理の基礎を形成します。
- SAST/SCAの実装:CI/CDパイプラインの早い段階で、自動化されたコードと依存性のスキャンを統合する。これはA.12とA.14の一部に対応する。
- コードレビューの公式化:PR にはレビューと承認が必要なようにしましょう。Gitプラットフォームでこれを追跡しましょう。(Addresses A.14.2 controls)
- 環境の分離:開発環境、テスト環境、プロダク ト環境を、異なる認証情報とネットワーク制御を使用して明確に分離する。(アドレス A.12.1.4)
- 秘密の管理:秘密保管庫を実装し、ハードコードされた秘密をスキャンする。(アドレス A.9 / A.12 / A.14 コントロール)
- 依存関係のパッチ適用:脆弱な依存関係を特定し、更新するプロセスを確立する。(アドレス A.12.6.1)
これを無視すれば...(失敗の結果)
ISO 27001の審査に落ちたり、規格を無視したりすると、次のような事態を招く可能性がある:
- 認証の喪失:既存の認証は停止または撤回される可能性がある。
- 契約上の罰則/損失:認証の取得や維持に失敗すると、契約に違反したり、入札、特に国際的な入札で失格となる可能性がある。
- 風評被害:セキュリティ態勢が脆弱であることを示唆し、グローバルな顧客やパートナーとの信頼関係を損なう。
- 審査精査の増加:認証機関は、今後のサーベイランス審査の頻度や強度を増やし、コストと労力を増やす可能性がある。
- 規制上の問題:コンプライアンス違反は、法的または規制上のセキュリティ要件(GDPRなど)を満たしていないことを示す可能性がある。
- 市場機会の喪失: ISO 27001が事実上の要件となっている市場やセクターに参入できない。
よくあるご質問
ISO 27001とSOC 2の違いは何ですか?
ISO 27001は、国際規格とリスク評価に基づいて、情報セキュリティマネジメントシステム(ISMS)全体を認証します。SOC 2 は、主に米国市場のニーズに基づき、特定のサービスコミットメント(Trust Services Criteria)に関連するコントロールに関する認証レポートを提供します。両者は、多くの場合、コントロールが重複していますが、アプローチ、範囲、結果(認証と報告書)は異なります。
ISO 27001は必須か?
いいえ、一般的には自主的な基準ですが、特定の規制産業や国際市場で事業を展開するためには、契約上の要求事項であったり、必要であったりすることがよくあります。
ISO 27001認証にはどれくらいの期間がかかりますか?
実施には、成熟度によって6~12カ月、あるいはそれ以上かかることもある。認証プロセス(ステージ1およびステージ2審査)は次のとおりである。既存のISMSは、認証審査までに約6ヶ月の運用が必要です。
ISO 27001のコストは?
多額の投資が必要である。3年サイクルの監査費用は数万ユーロ/ドルになることもあり、それに加えて社内リソース、潜在的なコンサルティング、ツールのコストがかかる。中小企業の場合、監査費用だけで3年間で15,000ユーロ以上というのが大まかな見積もりかもしれない。
附属書Aの114項目(または93項目)すべてを実施する必要があるか?
いいえ。リスクアセスメントと治療計画に基づいて、各コントロールを適用声明書(SoA)に含めるか除外するかを正当化する必要があります。
認証の有効期間は?
通常は3年間だが、その間の有効性を維持するためには、毎年のサーベイランス審査に合格しなければならない。3年経過後は再認証審査が必要となる。
誰が監査を行うのか?
認定された独立した外部認証機関。内部監査も必要だが、認証にはつながらない。