家studyをつづって

IT技術に関することやセキュリティ、ガイドライン等学んだことをつづっていきます。

ITサービスマネジメントとITIL

ITサービスマネジメントとITIL

ITサービスマネジメント(ITSM:IT Service Management)とは、ITシステムによるサービス提供を管理(マネジメント)することです。従来のシステムでは、ITシステムを開発・運用することに重点が置かれ、ユーザの視点が不足してしまい、ユーザの満足度向上に課題がありました。上記課題に対して、ユーザ視点でITサービスの提供を考えるのがITサービス管理です。ITサービスでは、ユーザが必要とする機能を継続的に提供すると共に、ビジネス環境や情報技術の変化に合わせて、常に改善を続けていく必要があります。ITサービス管理を考える枠組みとして、幅広く利用されているのが、ITIL (Information Technology Infrastructure Library)です。

 

ITILの構成
ITILは以下の7つの書籍群から成り立っています。

 

ITILを構成する書籍群

No 書籍名 概要
1

サービスサポート

(service support)

通称「青本」と呼ばれ、IT利用者が適切に利用できるようサポートするためのマネジメントについて説明している。
2

サービスデリバリ

(service delivery)

通称「赤本」と呼ばれ、ITをビジネスで利用している利用者のサービス要求に関するマネジメントについて説明している。
3

サービスマネジメント導入計画立案

(planning to implement service management)

通称「緑本」と呼ばれ、目標設定から導入後の初期診断と継続的な改善を組み込むための方法論を解説している。
4

ビジネスの観点

(e-business perspective)

ビジネス環境における課題、事業継続性管理、パートナーシップ、アウトソーシング、変化への柔軟な対応などについて書かれている。
5

アプリケーション管理

(application management)

アプリケーションの実装から廃棄までのライフサイクルに関連する課題について書かれている。
6

ICTインフラストラクチャー管理

(I.C.T. infrastructure management)

情報通信インフラの管理について技術的側面から説明している。
7

セキュリティ管理

(security management)

セキュリティへのインパクトに関する評価やデータの安全性・機密性を確実にするための課題について説明している。

ja.wikipedia.org

 

ITILの体系図

f:id:iestudy:20191016225437p:plain

ITILのフレームワーク

ITILの中核をなすのがITサービスマネジメントを構成する「サービスサポート」と
「サービスデリバリ」です。
上記はそれぞれ以下のプロセスに分類されています。

 

サービスサポート

  • インシデント管理
    ITサービスにインシデントが発生した場合に可能な限り迅速にサービス復旧に努めます。インシデント管理は以下のステップで行われます。

f:id:iestudy:20191016225546p:plain

インシデント管理
  • 問題管理
    インシデントの原因を「問題」としてとらえ、原因を追究します。問題を解決するための対策を検討し、変更管理に引き継ぎます。
  • 構成管理
    インシデント管理、問題管理、変更管理、リリース管理を支える重要な活動を行います。ITサービスを構成するハードウェアやソフトウェア、ネットワーク、ドキュメントなどの「構成品目(CI)」の情報を正確に把握し、よりよいITサービスを提供するために維持していく活動のことを構成管理と呼びます。
  • 変更管理
    問題管理によって明らかになった解決策や、ライフサイクルに応じて必要になった構成の変更などについての「変更要求」を受け付け、それらを評価、実施していくための活動を行います。

f:id:iestudy:20191016225612p:plain

変更管理
  • リリース管理
    リリース管理の目的は、変更管理で承認されたRFCに対する変更を、ビジネス的な観点においても技術的な観点においても確実に実装することです。正式な手順とチェックで稼働環境とそのITサービスを保護し、変更によって発生する負のインパクトを最小限に抑えることも重要な目的です。
  • サービスデスク
    サービスデスクは利用者からの問い合わせに対応するための窓口で、ヘルプデスク、コールセンター等があります。

 

サービスデリバリ

  • サービスレベル管理
    ITサービスの提供者と利用者の合意に基づいたサービスレベルを維持・改善していくプロセスです。サービスレベル合意書(SLA)やサービスレベルマネジメント(SLM)を実施し、運用・管理を行います。
  • ITサービス財務管理
    ITサービスに必要なコストを管理するプロセスです。
  • キャパシティ管理
    予算なども考慮しつつ、必要な性能要件を満たすサービスを開発できるようにするためのプロセスです。
  • ITサービス継続性管理
    地震等の災害発生時にITサービスの停止を最小限にすることを目的にしたプロセスです。
  • 可用性管理
    サービスを継続して提供できるようにするプロセスです。ITサービス継続性管理は地震等の災害を想定したプロセスであるのに対し、可用性管理はインシデントを対象としたものです。

参考にさせていただいたサイト

https://www.fom.fujitsu.com/goods/preview/pdf/fpt1111-1.pdf

www.k-fix.jp

「事業継続ガイドライン」の概要

事‌業‌継‌続‌ガ‌イ‌ド‌ラ‌イ‌ン‌ ‌
発‌行‌年‌月‌日‌:‌2013‌年‌8‌月‌(第‌3‌版)‌ ‌
発‌行‌機‌関‌:‌内‌閣‌府‌ ‌

http://www.bousai.go.jp/kyoiku/kigyou/keizoku/pdf/guideline03.pdf‌

 

概要
事業継続ガ‌イ‌ド‌ラ‌イ‌ン‌は、‌事‌業‌継‌続‌計‌画‌(‌BCP‌)‌を‌含‌め‌た‌事‌業‌継‌続‌マ‌ネ‌ジ‌メ‌ン‌ト‌(‌BCM‌)‌の‌概‌要、‌必‌要‌性、‌有‌効‌性、‌実‌施‌方‌法、‌策‌定‌方‌法、‌留‌意‌事‌項‌等‌を‌示‌す‌こ‌と‌で、‌日本の‌企‌業の‌自‌主‌的‌な‌事‌業‌継‌続‌の‌取‌組‌を‌促‌し、‌日本全体の事業継続能‌力‌の‌向‌上‌を‌実‌現‌す‌る‌こ‌と‌を目的に策定されました。
‌当‌該‌ガ‌イ‌ド‌ラ‌イ‌ン‌で‌は、‌BCM‌の‌概‌念‌に‌始‌ま‌り、‌計‌画‌の‌策‌定、‌訓‌練‌の‌実‌施‌に‌つ‌い‌て‌も‌触‌れ‌て‌い‌ま‌す。‌ ‌

BCMとBCP

事業継続マネジメント(BCM)と事業継続計画(BCP) BCP・BCM は、事故や災害などが発生した際に、「どのように重要な事業・業務を継続さ せるか」もしくは「どのように重要な事業・業務を目標として設定した時間内に再開させ るか」について様々な観点から対策を講じることである。BCP は、そのための計画自体を 指し、BCM は、BCP の策定から運用、見直しまでのマネジメントシステム全体を指す。

 ‌https://www.meti.go.jp/policy/netsecurity/docs/secgov/2011_IoformationSecurityServiceManagementGuidelineKaiteiban.pdf

 

事‌業‌継‌続‌計‌画‌(‌BCP‌)‌の‌概‌念‌ ‌

f:id:iestudy:20191015223817p:plain

BCPの概念

 

用語の説明

  • MTPD
    『最大許容停止時間』とは、MTPD(Maximum Tolerable Period of Disruption)とも呼ばれ、経営陣が最大限譲歩できる業務中断の最長時間のことを指します。
  • MTDL
    最大許容データ損失とは、MTDL(Maximum Tolerable Data Loss)とも呼ばれ、組織が耐えられる、情報(電子的もしくはその他のデータ)の最大損失量のことです。
  • RTO
    目標復旧時間(RTO)とは、事業が中断した際に、「いつまでに事業を復旧するか」という目標時間を表す指標で、BCP策定時に用います。
  • RPO
    RPO(Recovery Point Objective:目標復旧地点)とは、損壊・紛失したデータを復旧させる際の「復旧目標に関わる指標」の1つであり、「データの古さ(世代)」を指します。より具体的には、何らかの理由によりデータが損壊・紛失してしまった際の、決められた時間内(RTO:目標復旧時間)に、少なくともどの時点(どれくらいの古さ;世代)のデータを復旧しなければならないのか、といったときの「どの時点(どれくらいの古さ)のデータ」のことを意味します。
  • RLO
    RLO(目標復旧レベル)とは、何らかの理由で業務が中断することにより落ち込んでしまった操業水準を、決められた時間内(目標復旧時間:RTO)に、どの程度(操業水準)まで復旧させるかといったときの「どの程度(操業水準)」のことを指します。

www.newton-consulting.co.jp


ガイドラインの章構成

f:id:iestudy:20191015224425p:plain

ガイドラインの章構成

ACID特性と独立性

ACID特性とは
データベースの処理では、ある目的をもつ業務処理のひとまとまりのことをトランザクションといいます。ACID特性とは、トランザクション処理において必要とされる4つの要素、Atomicity(原子性)、Consistency(一貫性)、Isolation(独立性)、Durability(永続性)の頭文字で表したものです。

 

ACID特性の概要

ACID特性 特性の説明 実現機能

原子性

(atomicity)

トランザクションは完全に実行されるか、

全く実行されないのどちらかでなければならない。

コミットメント制御

一貫性

(consistency)

トランザクションの終了状態にかかわらず、

データベースの整合性が保たれなければならない。

整合性はDB内のデータに矛盾のない事を常に保証します。

排他制御

独立性

(isolation)

トランザクションを複数同時実行しても、

単独実行の場合と同じ処理結果にならなければならない。

排他制御

耐久性

(durability)

トランザクションの結果は、

障害が発生しても失われてはいけない。

障害回復機能

 

上記の独立性に関して、トランザクションが複数実行中の場合は多少なりとも他のトランザクションに影響が出ます。
そのトランザクションに影響を与える度合のことをISOLATION LEVELと言い、以下の4つに分類されます。
※直列処理の場合は、独立性は完全に保証されます。

 

ISOLATION LEVEL

  • READ UNCOMMITTED
    READ UNCOMMITTEDはコミットされていない変更を他のトランザクションから参照できる設定です。最もトランザクションの分離レベルが低いため、速度は速いです。
  • READ COMMITTED
    READ COMMITTEDは他のトランザクションがコミットしたデータだけを読み込みます。しかし、トランザクションの中で一度参照したデータが、同一トランザクション内でもう一度読み込んだときに違う結果を返す可能性があります。
  • REPEATABLE READ
    REPEATABLE READは同一トランザクション内で同じデータを複数読み込んでも同じ結果を返します。そのため、あるトランザクションで読み込んでいるデータを他のトランザクションが更新することを防ぐことができます。しかし、更新ではなく行の追加や削除は行うことができます。
  • SERIALIZABLE
    SERIALIZABLE(直列化)はトランザクションが互いに完全に干渉しません。よって独立性阻害要因は発生しませんが、各トランザクションの”待ち”が増えるため、速度は遅くなります。

 

独立性阻害要因

ダーティリード
ダーティリードは、他のトランザクションがコミット前のデータを読み込ムことで発生します。コミット前のデータを読んでしまうと、そのデータがロールバックされた場合に存在しない更新データで処理を行うことになります。

f:id:iestudy:20191014231552p:plain

ダーティリードのイメージ

ノンリピータブルリード(ファジーリード)
ノンリピータブルリードは、同一トランザクション内で同じデータを複数読み込んだ場合に違う結果を返す可能性があります。

f:id:iestudy:20191014231629p:plain

ファジーリードのイメージ

ファントムリード
ノンリピータブルリードでは行の更新でしたが、ファントムリードは行の追加や削除をされてしまう可能性があります。
行の追加や削除が行われることで、例えば読み込んだ行数を使って処理をしていた場合等に不整合が起きてしまいます。

f:id:iestudy:20191014231657p:plain

ファントムリードのイメージ

ロストアップデート
同じリソースに対して、ロックをかけずに複数のトランザクションが処理を行った場合に、処理結果に不整合が発生する場合があります。

f:id:iestudy:20191014231722p:plain

ロストアップデートのイメージ


ISOLATION LEVELと独立性阻害要因の関係

縦:ISOLATION LEVEL

横:独立性阻害要因

ダーティーリード ファジーリード ファントムリード ロストアップデート
read uncommitted 発生 発生 発生 発生
read committed 発生しない 発生 発生 発生
repeatable read 発生しない 発生しない 発生 発生
serializable 発生しない 発生しない 発生しない 発生しない

 

参考にさせていただいたサイト

qiita.com

high-programmer.com

 

CMMとIDEAL

CMMとは
CMM(Capability Maturity Model,能力成熟度モデル)は組織の能力成熟度モデルの一つで、システム開発を行う組織がプロセス改善を行うためのガイドラインとなるものです。ソフトウェア工学研究所(SEI)で考案され、主にソフトウェアの開発プロセスを5段階のレベル評価で使用されます。

 

CMMの能力成熟度レベル

  • CMMレベル1「初期(initial)」
    決まった開発手順がなく、組織のメンバー個々の能力次第で品質や生産性が変わる属人的なソフト開発を行っている段階。
  • CMMレベル2「反復できる(repeatable)」
    コスト管理、スケジュール管理等の基本的な管理を実施している段階。
  • CMMレベル3「定義された(defined)」
    組織全体で開発プロセスが標準化・統合化され、成果物が明確に定義されている、高度な段階。
  • CMMレベル4「管理された(managed)」
    組織の進捗状況を常に定量的に監視し、問題が予見されれば直ちに解決する能力を持つ、かなり高度な段階。
  • CMMレベル5「最適化する(optimizing)」
    自発的かつ恒常的に開発プロセスを改善・高度化する能力を持つ、最高の段階。

プロセスの改善を進める上での考え方の一つとして、SEIではIDEALというプロセス改善の方法を提唱しています。

 

IDEALとは
IDEALモデルはプロセス改善を推進する際に具体的な活動内容を計画・定義できるよう、改善活動の典型的なライフサイクルを示したリファレンスモデルです。
「開始」「診断」「確立」「行動」「学習」の5つのフェーズで構成されており、各フェーズの頭文字をとってIDEALモデルと呼ばれています。

f:id:iestudy:20191014003922p:plain

IDEALモデル

各フェーズの概要

  • 開始フェーズ( Initiating )
    開始フェーズとは、プロセス改善の実施に先立ち、改善の動機付けを行い、改善内容の定義や支援体制(組織の上級管理層のスポンサーシップ)・活動体制を確立したうえで、目標設定や計画立案をするフェーズです。
    IDEALモデルでは、各フェイズを繰り返し行うことが前提ですが、開始フェーズは原則として最初に1回だけ実施します。
  • 診断フェーズ( Diagnosing )
    診断フェーズとは、アセスメント(診断)などを実施することにより現状を認識し、プロセスの視点からプロジェクトおよび組織の強い点、弱い点を明確にし、改善対象のプロセスを明確にしたうえで、改善ポイントの提案を実施するフェーズです。
  • 確立フェーズ( Establishing )
    確立フェーズとは、診断フェーズで得られた結果を基に、戦略、優先順位、アプローチを確定し、具体的な改善計画を作成するフェーズです。
  • 実践フェーズ( Acting )
    実践フェーズとは、作成された改善計画に従ってプロセス改善の試行、および適用を実施する。パイロットプロジェクトで改善策を実施、洗練し、成功事例などのプロセス改善活動を組織全体に拡大、定着させるフェーズです。
  • 学習フェーズ( Learning )
    学習フェーズとは、プロセス改善の実施結果について、教訓や意図した改善効果が得られているかなどを分析し、プロセス改善活動をより効果的かつ効率的に実施する方法を提案し、継続的改善を定着させるフェーズです。

参考にさせていただいたサイト

tech.nikkeibp.co.jp

www.nttcom.co.jp

 

tech.nikkeibp.co.jp

 

https://www.juse.or.jp/sqip/workshop/report/attachs/2005/1_b_report.pdf

ア‌ジャ‌イ‌ル‌開‌発‌宣‌言‌と‌は‌ ‌

ア‌ジャ‌イ‌ル‌ソ‌フ‌ト‌ウェ‌ア‌開‌発‌宣‌言‌の‌読‌み‌と‌き‌方‌ ‌
発‌行‌機‌関‌:‌情‌報‌処‌理‌推‌進‌機‌構‌(‌IPA‌)‌ ‌
発‌行‌年‌月‌日‌:‌2018‌年‌4‌月‌ ‌

https://www.ipa.go.jp/files/000065601.pdf‌

 

アジャイル開発とは
アジャイル(agile)は「素早い」や「機敏」という意味があります。
アジャイル開発で使われるアジャイルとは、ソフトウェアの軽量な開発、ソフトウェアを早く、かつ継続的に提供するという意味があります。
ソフトウェア開発に「アジャイル」という概念が取り入れられた背景には、顧客の要望に答えるシステムをできるだけ短い時間でリリースすることによって、顧客のビジネスのスタートを早めようという考え方があります。


アジャイル開発宣言とは

「アジャイル」という概念が誕生するきっかけとなったとなったのは、2001年にアジャイルソフトウェア開発の分野において専門性の高いメンバーが集い行った「アジャイルソフトウェア開発宣言」です。

 

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

 

agilemanifesto.org


「アジャイルソフトウェア開発宣言」はその背後に、「アジャイル宣言の背後にある原則」というものがあります。これは、「アジャイルソフトウェア開発宣言」で表明されているマインドセットを実現するために従うことが望ましい原則、取り組み姿勢が書かれています。

「アジャイルソフトウェア開発宣言の読みとき方」は、「アジャイルソフトウェア開発宣言」および「アジャイル宣言の背後にある原則」の解釈についてまとめた資料です。

補足:マインドセット
マインドセット
mind set
マインドセットとは、経験、教育、先入観などから形成される思考様式、心理状態。暗黙の了解事項、思い込み(パラダイム)、価値観、信念などがこれに含まれる。 

mba.globis.ac.jp

 

「アジャイル宣言の背後にある原則」

IPAの解釈 原文
顧客の満足を求め続ける

「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。」

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

要求の本質を見抜き、変更を前向きに

「要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。」

“Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.”

成果物を2-3週間で、リリースし続ける

「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。」

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

全員で共通の目標に向かおう

「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。」

“Business people and developers must work together daily throughout the project.”

人の意欲は信頼から

「意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。」

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

顧客も開発チームも直接対話で

「情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。」

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

進捗も品質も現物で

「動くソフトウェアこそが進捗の最も重要な尺度です。」

“Working software is the primary measure of progress.”

一定のペースでプロジェクトにリズムを

「アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。」

“Agile process promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

よい技術、よい設計、よい品質の追求

「技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。」

“Continuous attention to technical excellence and good design enhances agility.”

ムダ=価値を生まない、を探してヤメる

「シンプルさ(ムダなく作れる量を最大限にすること)が本質です。」

“Simplicity--the art of maximizing the amount of work not done--is essential.”

よいモノはよいチームから

「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。」

“The best architectures, requirements, and designs emerge from self-organizing teams.”

自分たちのやり方を毎週、調整する

「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。」

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

共連れとアンチパスバック

入室する際に社員証などのICカードをかざしてはいるような施設でたまに、「アンチパスバックエラーです」といわれて部屋から出られない、ということがあります。
これまで聞き流していたアンチパスバックについて調べてみました。

 

アンチパスバックとは
アンチパスバックとは、入室時と退室時にIDカードを用いて認証を行い、入退室を管理する区画において、入室時の認証に用いられなかったIDカードでの退室を許可しない、
又は退室時の認証に用いられなかったIDカードでの再入室を許可しないコントロールを行う仕組みのことをいいます。

f:id:iestudy:20191010221905p:plain

アンチパスバックのイメージ

 

上記のような状態になる理由として、共連れ(ピギーバック)があります。

 

f:id:iestudy:20191010221947p:plain

共連れのイメージ

参考にさせていただいたサイト

secureinc.co.jp

 

ISMSの入退室管理の記載
ISMSでは、物理的セキュリティとして「A.11.物理的及び環境的セキュリティ」があり、 その中で「A.11.1.2 物理的入退管理策」が定められています。
審査では、「A.11.1.2 物理的入退管理策」として「物理的入退室管理のルールが周知され、守られているか」をチェックが行われます。

 

情報処理試験の問題

アンチパスバックに関してはIPAの情報処理試験にも取り上げらています。

learning.zealseeds.com

 

アンチパスバック以外の共連れ防止策
アンチパスバックで完全に共連れを防止できるわけではありません。
共連れで入室したのと同じように、共連れで退出する、という方法が可能性としてあるためです。

セキュリティゲート
駅の改札口のように、物理的に1人ずつしか通ることのできないセキュリティゲートを設ける手段です。

監視カメラ
エントランスに監視カメラを設置して監視します。この手法は共連れを発見できますが入室を止める手段にはなりません。

インターロックゲート(二重扉)
ドアを二重に設置して、同時の解錠を防ぎ、確実に1人ずつしか通さない仕組みです。

f:id:iestudy:20191010222332p:plain

インターロックゲートのイメージ

locksystem.co.jp

その他 2名照合機能(ツーパーソン機能/ダブル認証機能)
共連れとは逆に、常に2名の認証を求めるシステムもあります。データセンターや開発実験室のような、極めて厳重なセキュリティが要求される施設で設置されます。
正規の入室であっても、1人だと不正な行為を行う危険性が高まります。
それを避けるのがこの機能で、必ず2人で入って2人で出ます。1人を残して1人が退室することはできません。 

 

連邦政府情報システムに対するリスクマネジメントフレームワーク適用ガイド(NIST SP800 37)

連邦政府情報システムに対するリスクマネジメントフレームワーク適用ガイド

発行機関:NIST(IPA訳)
発行年月日:2010年2月

https://www.ipa.go.jp/files/000025329.pdf

 

概要
情報システムに対する脅威には、環境破壊や人的ミス、システムのエラ-、外部からの攻撃があります。情報システムを取り巻く脅威は増大しているため、組織においては自組織で運用するシステムのリスク管理が重要になります。
本ガイドラインでは適切なリスク管理の実施により、情報システムのセキュリティを向上させることを目的として公開されています。リスクマネジメントの実施は組織全体で取り組む必要があり、以下の図のように段階的に取り組むことを示しています。

 

f:id:iestudy:20191009090730p:plain

段階的なリスクマネジメントアプローチのイメージ

第1層
第1層では、組織的観点からリスクに対処します。

  • リスク評価の手法の周知
  • リスクマネジメントを実施する対象の決定
  • 許容するリスクレベルの決定 等


第2層

  • 組織の主要な任務および業務プロセスを定義する
  • 組織の目標と目的に照らし合わせて、各任務および業務プロセスに優先順位をつける 等

第3層
表題にもあるリスクマネジメントフレームワーク(RMF)は第3層で活用します。

 

RMFのステップ

分類
情報システム、およびそのシステムによって処理、格納、および伝送される情報を、影響分析結果に基づいて分類する。

選択
セキュリティ分類結果に基づいて、情報システムに対するベースラインセキュリティ管理策の初期セットを選択する。また、リスク、およびローカルな状況のアセスメント結果に基づいて、必要に応じてセキュリティ管理策ベースラインを調整し、補足する。

実施
セキュリティ管理策を実施する。また、情報システム、およびその運用環境において、セキュリティ管理策をどのように採用するかについて、記述する。

アセスメント
セキュリティ管理策がどの程度正しく導入されているか、どの程度意図した通りに運用されているか、システムのセキュリティ要求事項に対する適合性の観点から所望の結果をどの程度産出しているかを判断するために、適切なアセスメント手順を用いて、セキュリティ管理策をアセスメントする。

運用認可
情報システムの運用から生じる組織の業務や資産、個人、他の組織、および国家に対するリスクを評価し、そのリスクを受容できると判断した場合に、情報システムの運用を認可する。

監視
情報システムに導入されているセキュリティ管理策を継続的に監視する。これには、管理策の有効性の評価、システムまたはその運用環境に対する変更の文書化、関連する変更によるセキュリティ影響の分析、システムのセキュリティ状態の指定された職員への報告が含まれる。

 

f:id:iestudy:20191009091039p:plain

リスクマネジメントのステップ

リスクマネジメントを成功させるには、一貫性を持って実施することが重要になります。リスクマネジメントを実施するのに必要なリソースを割り当てるには、経営層の支援も必要になります。
ガイドラインでは、リスクマネジメントの各ステップにおけるタスクと責任を負うべき役割についてもまとめています。

 

RMF ステップ 1-情報システムの分類

タスク 概要 主な責任を持つ者 補助的な役割
セキュリティ分類 情報システムを分類し、セキュリティ分類の結果をセキュリティ計画に記載する。 情報システムのオーナー、情報のオーナー/スチュワード

リスクエグゼクティブ(機能)

運用認可責任者または指名された代理人

最高情報責任者

上級情報セキュリティ責任者

情報システムセキュリティ責任者

情報システムに関する記述 情報システム(システム境界を含む)について説明し、その内容をセキュリティ計画に記載する。 情報システムのオーナー

運用認可責任者または指名された代理人

上級情報セキュリティ責任者

情報のオーナー/スチュワード

情報システムセキュリティ責任者

情報システムの登録 組織内の適切な計画局/管理局に情報システムを登録する。 情報システムのオーナー 情報システムセキュリティ責任者

 

RMF ステップ 2-セキュリティ管理策の選択

タスク 概要 主な責任を持つ者 補助的な役割
共通管理策の明確化 組織の情報システムに対する共通管理策として組織が提供しているセキュリティ管理策を明確にし、セキュリティ計画(またはそれと同等の文書)に記載する。 最高情報責任者または上級情報セキュリティ責任者、情報セキュリティアーキテクト、共通管理策の提供者

リスクエグゼクティブ(機能)

運用認可責任者または指名された代理人

情報システムのオーナー

情報システムセキュリティエンジニア

セキュリティ管理策の選択 情報システムに導入するセキュリティ管理策を選択し、それらの管理策について、セキュリティ計画に記載する。 情報セキュリティアーキテクト、情報システムのオーナー

運用認可責任者または指名された代理人

情報のオーナー/スチュワード

情報システムセキュリティ責任者

情報システムセキュリティエンジニア

監視戦略 セキュリティ管理策の有効性、ならびに、情報システムおよびシステムの運用環境に対して提案されている、あるいは、実際に実施された変更を継続的に監視するための、戦略を策定する。 情報システムのオーナーまたは共通管理策の提供者

リスクエグゼクティブ(機能)

運用認可責任者または指名された代理人

最高情報責任者

上級情報セキュリティ責任者

情報のオーナー/スチュワード

情報システムセキュリティ責任者

セキュリティ計画の承認 セキュリティ計画をレビューし、承認する。 運用認可責任者または指名された代理人

リスクエグゼクティブ(機能)

最高情報責任者

上級情報セキュリティ責任者

 

RMF ステップ 3-セキュリティ管理策の実施

タスク 概要 主な責任を持つ者 補助的な役割
セキュリティ管理策の実施 セキュリティ計画に記載されているセキュリティ管理策を実施する。 情報システムのオーナーまたは共通管理策の提供者

情報のオーナー/スチュワード

情報システムセキュリティ責任者

情報システムセキュリティエンジニア

セキュリティ管理策の文書化 必要に応じて、セキュリティ管理策の実施について、機能面での記述(予定しているインプット、予想される挙動、および予想されるアウトプットを含む)と併せて、セキュリティ計画に記載する。 情報システムのオーナーまたは共通管理策の提供者

情報のオーナー/スチュワード

情報システムセキュリティ責任者

情報システムセキュリティエンジニア

 

RMF ステップ 4-セキュリティ管理策のアセスメント

タスク 概要 主な責任を持つ者 補助的な役割
アセスメントの準備 セキュリティ管理策のアセスメント計画を策定、レビューし、承認する。 セキュリティ管理策アセサー

運用認可責任者または指名された代理人

最高情報責任者

上級情報セキュリティ責任者

情報システムのオーナーまたは共通管理策の提供者

情報のオーナー/スチュワード

情報システムセキュリティ責任者

セキュリティ管理策のアセスメント セキュリティアセスメント計画に記載されているアセスメント手順に従ってセキュリティ管理策をアセスメントする。 セキュリティ管理策アセサー

情報システムのオーナーまたは共通管理策の提供者

情報のオーナー/スチュワード

情報システムセキュリティ責任者

セキュリティアセスメントレポート セキュリティ管理策のアセスメントを通じて発見された問題、導かれた結論および推奨事項を文書化した、セキュリティアセスメントレポートを用意する。 セキュリティ管理策アセサー

情報システムのオーナーまたは共通管理策の提供者

情報システムセキュリティ責任者

是正活動 セキュリティアセスメントレポートに記載されている結論と推奨事項に基づいて、セキュリティ管理策に対する初期の是正活動を実施し、是正された管理策(複数)を適宜、再アセスメントする。 情報システムのオーナーまたは共通管理策の提供者、セキュリティ管理策アセサー

運用認可責任者または指名された代理人

最高情報責任者

上級情報セキュリティ責任者

情報のオーナー/スチュワード

情報システムセキュリティ責任者

情報システムセキュリティエンジニア

セキュリティ管理策アセサー

 

RMF ステップ 5-情報システムの運用認可

タスク 概要 主な責任を持つ者 補助的な役割
行動計画とマイルストーン セキュリティアセスメントレポートに記載されている結論と推奨事項に基づいて、行動計画とマイルストーンを作成する(ただし、既に実施されたすべての是正活動を除く)。 情報システムのオーナーまたは共通管理策の提供者

情報のオーナー/スチュワード

情報システムセキュリティ責任者

セキュリティ運用認可パッケージ セキュリティ運用認可パッケージをまとめて、運用認可責任者に提出し、裁定を仰ぐ。 情報システムのオーナーまたは共通管理策の提供者

情報システムセキュリティ責任者

セキュリティ管理策アセサー

リスクの判断 組織の業務(任務、機能、イメージ、または評判を含む)、組織の資産、個人、他の組織、または国家に対するリスクを判断する。 運用認可責任者または指名された代理人

リスクエグゼクティブ(機能)

上級情報セキュリティ責任者

リスクの受容 組織の業務、組織の資産、個人、他の組織、または国家に対するリスクが受容できるかどうかを判断する。 運用認可責任者

リスクエグゼクティブ(機能)

運用認可責任者が指名する代理人

上級情報セキュリティ責任者

 

RMF ステップ 6-セキュリティ管理策の監視

タスク 概要 主な責任を持つ者 補助的な役割
情報システムやその運用環境に対する変更 タスク 6-1: 情報システムおよびシステムの運用環境に対して提案されている、あるいは、実際に実施された変更がもたらすセキュリティへの影響を判断する。 情報システムのオーナーまたは共通管理策の提供者

リスクエグゼクティブ(機能)

運用認可責任者または指名された代理人

上級情報セキュリティ責任者

情報のオーナー/スチュワード

情報システムセキュリティ責任者

継続的なセキュリティ管理策アセスメント 組織が定めた監視戦略に従って、情報システムに導入される、または情報システムによって継承される技術面、管理面、および運用面でのセキュリティ管理策の中から選択された、管理策のサブセットをアセスメントする。 セキュリティ管理策アセサー

運用認可責任者または指名された代理人

情報システムのオーナーまたは共通管理策の提供者

情報のオーナー/スチュワード

情報システムセキュリティ責任者

継続的な是正活動 継続的監視活動の結果、リスクアセスメント結果、および行動計画とマイルストーンにリストアップされている重要な項目に基づいて、是正活動を実施する。 情報システムのオーナーまたは共通管理策の提供者

運用認可責任者または指名された代理人

情報のオーナー/スチュワード

情報システムセキュリティ責任者

情報システムセキュリティエンジニア

セキュリティ管理策アセサー

重要な更新 継続的監視プロセスの結果に基づいて、セキュリティ計画、セキュリティアセスメントレポート、および行動計画とマイルストーンを更新する。 情報システムのオーナーまたは共通管理策の提供者

情報のオーナー/スチュワード

情報システムセキュリティ責任者

セキュリティ状況の報告 監視戦略に従って、継続的に、情報システムのセキュリティ状況(情報システムに導入されるセキュリティ管理策、および情報システムによって継承されるセキュリティ管理策の有効性を含む)を運用認可責任者および組織内の他の適切な職員に報告する。 情報システムのオーナーまたは共通管理策の提供者 情報システムセキュリティ責任者
継続的なリスク判断および受容 監視戦略に従って、情報システムのセキュリティ状況に関する報告内容(情報システムに導入される、または情報システムによって継承されるセキュリティ管理策の有効性を含む)を継続的に見直すことによって、組織の業務、組織の資産、個人、他の組織、または国家に対するリスクが、ひきつづき受容可能か否かを判断する。 運用認可責任者

リスクエグゼクティブ(機能)

運用認可責任者が指名する代理人

上級情報セキュリティ責任者

情報システムの切り離しおよび廃止 必要に応じて、情報システムの廃止戦略を実施する。この戦略は、システムがサービスから切り離された時に必要となる活動を実施するためのものである。 情報システムのオーナー

リスクエグゼクティブ(機能)

運用認可責任者が指名する代理人

上級情報セキュリティ責任者、情報のオーナー/スチュワード

情報システムセキュリティ責任者