- 勉強の為のメモです。内容は保証できません。正確な情報はCISSP CBKや公的なガイドライン等の参照お願いします。
- 記載者の独自の解釈を含みます。
- CISSPの試験内容は秘密であり、ここに書かれた内容が試験に直接でることはありません。
- 記載の範囲はCISSPドメインガイドブックの範囲と揃えられるよう努力しています。また、章立て、項番を(可能な限り)一致させています。
初めに
- インフラ関連を得意とするSE です。最近はDXな感じの部署で働いてます。
- 2023年4月にCISSPの試験を受けて無事合格しました。→ CISSP合格したので勉強法など
- discordでCISSPとその他の資格の勉強会をしています。→ CISSPその他の資格の勉強会
- 宜しければ一緒に勉強しましょう!!
2.資産のセキュリティ
情報と資産についてのセキュリティを確立しよう!!という分野です。
実際にISMSなどを確立したりする際もまずはここから手を付けるケースが多いと思います。
何を守ればいいのかわかなければ、セキュリティを担保しようがない、という極めて当然のところですが、大体の企業ではないがしろに、、、されているような気がしたりしなかったりします。
2.1 情報と資産を特定し、分類する
CISSPの難しいところですが、複数の概念が、日本語に訳されると同じ言葉になってしまい、理解できないことが多々あります。これも日本語でClassifiedとCategorizeのどちらも「分類」と訳されるので注意が必要です。
この分類はデータオーナーが実施します。 データの分類だけでなく、 必ずどの個人が責任を負うのか ということを明確にしておくことが重要です。
ClassifiedとCategorizeの違い
- Classified
データを標準化したレベル(最高機密・機密・部外秘など)にしたがって ラベリング していくことです。データAは「最高機密」、データBは「部外秘」などというように整理します。
- Categorize
データを使いやすいように グループ分け することです。データAとBは経理の情報だよね。データCは社員の個人データだよね、というように整理します。
単純に考えるとCategorizeしたものをClassifiedするのがやりやすそうに思いますが、両者の関係はCISSP CBKでは明確に定義されていないように思います。
データの分類(Classified)
米国政府の基準と民間企業の(一般的な)標準があります。
class | 政府 | 民間 | セキュリティが影響 |
---|---|---|---|
Class1 | 最重要機密(Top Secret) | 専有(proprietary) | 非常に重大な影響がある情報 |
Class2 | 機密(Secret) | プライベート(private) | 重大な影響がある情報 |
Class3 | 部外秘(Confidencial) | 重要(sensitive) | 影響がある情報 |
Class4 | 未分類(Unclassified) | 公開(public) | 影響がない情報 |
米国政府の分類は以下の大統領令(行政命令)にあります。民間のものは統一の基準はありません。
上記は一例です。(とはいえ大体このような分類が用いられているようです)
Executive Order 13526 - Wikisource, the free online library
(1) 国家の安全保障に格別の重大な損害(exceptionally grave damage)を及ぼすことが合理的に予想され、かつ、本来の分類機関がこれを識別または記述することができる情報には、「最重要機密(Top Secret)」を適用する。
(2) 国家の安全保障に重大な損害(serious damage)をもたらすことが合理的に予想される情報で、元の分類機関が特定または説明できるものについては、「機密(secret)」を適用する。
(3) 国家の安全保障に損害(damage)を与えることが合理的に予想される情報で、元の分類機関が識別または記述することができるものには、「部外秘(confidential)」を適用する。
データのカテゴライズ(Categoraize)
データのカテゴライズは、比較可能な「秘密度ラベル」を持つデータの種類をグループ化するプロセスです。「プライバシー情報、医療情報、専有情報、財務情報」などを「機密性、完全性、可用性」への影響を考慮しながら分類します。
NIST SP800-60 「情報および情報システムのタイプとセキュリティ分類のマッピングガイド」
にガイドラインがあります。
以下の例のように各情報に対して、機密性、完全性、可用性の観点でラベリングすることが推奨されています。(簡略化しているので、詳細は上のSP800-60のリンク参照)
例:会計情報 ={(機密性,高位),(完全性,中位),(可用性,高位)}
セキュリティ目標 | 低位 | 中位 | 高位 |
---|---|---|---|
機密性 | 限定的な悪影響 | 重大な悪影響 | 致命的または壊滅的な悪影響 |
完全性 | 限定的な悪影響 | 重大な悪影響 | 致命的または壊滅的な悪影響 |
可用性 | 限定的な悪影響 | 重大な悪影響 | 致命的または壊滅的な悪影響 |
資産の分類(Classified)
ここでいう資産は、主に機器等の物理的な資産を示しています。資産の分類は、資産のインベントリを作成し、資産(asset)オーナー を決定するところから始まります。セキュリティチームと 資産(asset)オーナーは、データと同様にそれぞれの機密レベルによって資産を分類します。
資産の分類は、データの分類(classification)と一致させる必要があります 基本的には、その危機が取り扱うデータと同じレベルが想定されることになります。特にこれに標準的な規格はなく、下記は一例です。
カテゴリ | 概要 | 例 |
---|---|---|
重要システム | コンプライアンス上の影響や、侵害が非常に重要な問題を引き起こす機器 | 個人情報を扱うシステムなど |
Tier0 | 非常に機密性の高いデータを保持し、侵害がビジネスに影響を及ぼすもの | DomainControlloers, ファイルサーバ、メールサーバなど |
Tier1 | 重要だが必ずしも必須ではない。特定の部門に不可欠だが、ビジネス全体ではない。侵害はビジネスに影響を及ぼす | 重要なデータを含む開発環境、部門のファイルサーバ |
Tier2 | 日常業務に不可欠もなく、重要でもない | 個人用PC、プリンタ |
2.2/2.3 情報と資産の取り扱い要件を確立する/リソースを安全にプロビジョニングする
情報と資産の所有権
「適切な個人」によって実行、監督される必要があることが明言されています。
ここでは「データオーナー(Data Owner)」と「資産オーナー(Asset Owner)」を明確にします。
※資産に「情報資産」としてデータを含むことが多いので、区別は資料によって必ずしも明確でない。(CBKも「データ」と「資産」の明確な線引きは定義していない認識)
※ Data ownerはInformaition owner、Data stewardと資料によって表記される場合がある。(CBKのNoteに記載あり)ただしstewardはより運用に近い役割として定義されているケースが多いように思われる。
データオーナー(Data Owner)
- データについての最終的な責任を負う
- 情報を分類し、セキュリティラベルを適切にマークする
- データの機密性、完全性、可用性を確保するための保護手段を定義及び実装する
- データのインベントリを最新の状態に保つ
- 日常的な運用責任はデータカストディアン(Custodian)に委任することが多い
- Responsability(説明責任)は委任できない
- コンプライアンスを確保するためのセーフガードおよびコンプライアンス違反の報告状況の評価と監視
- ビジネス上必要な情報に対するアクセスの承認
- 情報に対するアクセスの必要性がなくなったユーザのアクセス権の削除
- 環境と法令・コンプライアンスの状況を継続的に評価し、上記の変更が必要かどうかを判断すること
資産オーナー(Asset Owner)
- 資産について最終的な責任を負う
- 資産を分類し、セキュリティラベルを適切にマークする
- 資産の機密性、完全性、可用性を確保するための保護手段を定義及び実装する
- 資産のインベントリを最新の状態に保つ
- コンプライアンスを確保するためのセーフガードおよびコンプライアンス違反の報告状況の評価と監視
- ビジネス上必要な情報に対するアクセスの承認
- 情報に対するアクセスの必要性がなくなったユーザのアクセス権の削除
- 環境と法令・コンプライアンスの状況を継続的に評価し、上記の変更が必要かどうかを判断すること
資産インベントリ
資産インベントリには、ハードウェア、ソフトウェア、データなどの資産が含まれます。
セキュリティ確保のために資産インベントリの作成は必須です。
CIS Controlsでも初めに確率すべきものの2つは両方とも資産インベントリに関連するものです。
(1.組織の資産のインベントリと管理/2.ソフトウェア資産のインベントリと管理)
資産インベントリと記録のためのツールの導入が推奨されています。
CBKではハードウェア・ソフトウェアのような所謂「資産」だけでなく「データ」も含んだ形で語られています。
一般的にはSkySeaなど、資産(ハードウェア、ソフトウェア)のインベントリと、データのインベントリは別に管理することが多いような、、ベストプラクティスがあったら教えてほしいです。。
例えばAzureなら以下のようなものがあったりします。
資産運用管理
IT資産管理(ITAM)
組織はライフサイクル全体を通じて情報資産を追跡、管理、およびレポート作成する必要があります。
いくつかのガイドラインがありますので、覚えておく必要があります。
ポイントはどのガイドラインもライフサイクルを定義していることです。
- NIST SP1800-5 IT Asset Management
Asset Lifecycle NIST SP1800-5より
- ISO/IEC 19770-1:2017 Information technology — IT asset management
SkySeaはこれに準拠しているようです(でも規格がISO/IEC 19770-1:2006とちょっと古い??)
2.4 データライフサイクルを管理する
データに関連する役割(すなわち、所有者、管理者、保管者、処理者、ユーザ/対象者)
ここらへんは、かなり資料によって定義が違うので要注意です。(また、日本語に訳されるときに訳語が統一されていない点も)。。
さらにGDPRがまた別の定義を持ち出しており、ややこしいです。
よくある定義(わたしの解釈込みです!ご注意!)
役割 | 内容 |
---|---|
データオーナー | 一般的にシニアマネジメントがなることが多い。カストディアンに対して日常業務を委任することができる。ただし、 最終的な責任(responsibility)は委譲できない 。データの分類に責任を負う。 |
データカストディアン(custodian) | 一般的にITシステム部の誰かがなることが多い。どのようなコントロールが必要かなどを決定することはない。データオーナーのために、委譲された 日常的な コントロールを実施する。 |
データ管理者(Data Administratror) | 利用者へのアクセス許可を与える(RBACが利用されることも) |
利用者 | システムを通じてデータにアクセスする |
ビジネスオーナー/ミッションオーナー | 名前のままであるが、ビジネスやミッションに責任を持つ |
資産オーナー | 機密データを処理する資産またはシステムを所有し、機密データ及び関連するセキュリティ計画について責任をもつ |
GPDR(及びHIPAA)に関連する追加の登場人物(個人情報)
役割 | 内容 |
---|---|
データ主体(Data Subject) | データの源泉である個人。システムを通じてデータにアクセスする |
データ管理者(Data Controller) | データの処理を管理する個人または団体。(※日本語だとData Administrator も Data Controllerもデータ管理者と訳されることがあるのでややこしい。。) |
データプロセッサー(Data Processor) | データ管理者(Data Controller)に代わって個人データを処理する自然人または法人、公的機関、代理店、その他の組織 |
データのライフサイクル
データについて、収集されてから破棄されるまでのライフサイクルを理解しておく必要があります。
- 収集(Create) - データが生成、集計される
- ストア(Store) - データはストレージ、リポジトリに保存される
- 使用(Use) - データはユーザ、システムによって処理・分析される
- 共有(Share) - データは承認された外部ユーザ、システムと共有される
- 保持(Archive) - データは事前定義された期間保持される
- 破棄(Destroy) - データが削除され、ストレージから完全に削除されて使用できなくなる
データの収集 : Create
このタイミングで、データの分類を実施することが推奨されます。また、重要な属性でデータにタグをつけ、データに適切なアクセス権を割りふります。
データのロケーション : Store
データをその保管場所で保存します。クラウドストレージなどの発達やGDPRのようにデータのロケーションの考慮が必要な法令によって、データのロケーションは強く意識される必要があります。
データの保持(Retention) : Store & Archive
データを利用しその後、安全に破棄されるまでの保持期間を考慮する必要がある。
さまざまな規制要件は互いに矛盾しているため、データ保持ポリシーは確立と遵守は非常に困難になる可能性があるといわれています。
インシデントやその他の調査の為に最小の保持期間が法令やガイドラインよって定義されています。
また、最大保持期間が定義されている例もあります。
- 最小保持期間
- NIST 800-53では、データ作成から最低3年間のデータ保持が必要
- HIPAA関連データは6年間保持
- 最大保持期間
- GDPR第5条では、「データが最初に収集された目的を達成する為に必要な期間のみ保持する」と定義されている
データの維持(Maintenance) : Use & Share
データの使用フェーズでは、データのアクセスを適切に制御し、データへのセキュリティコントロールを適用することで、データのセキュリティを積極的に管理及び維持する必要があります。
データの破棄・データの残留(Data Remenence): Destroy
下に行くほど強力な消去方法です。
ここは日本語訳が非常に混乱(ほとんどどれも「消去」と訳されちゃう)ので必ず英語の方を覚えることが重要です。
- 消去(Erasing) - ファイル、ファイル、またはメディアに対して削除操作を実行すること。(通常この方法で消去したものは復元可能)※ガイドライン等に定義された概念というより、一般的な用法
- クリア,上書き(Clearing(overwriting) - メディアを再利用できるように準備し、従来の復元ツールを使用してデータを復元できないようにすること。
※同じレベルで再利用する場合はこれを使うこと - パージ(purging) -安全性の低い環境で再利用するためにメディアを準備する、より強力なクリアの形式。強力な磁場を発生させ、一部のメディアのデータを消去するなど。(暗号化消去もここに含まれる)
- 破壊(Destruction) - メディアのライフサイクルの最終段階であり、メディアをサニタイズする最も安全な方法。再利用はできません。
以下にNISTのガイドラインがあります。
「NIST SP800-88 媒体のデータ抹消処理(サニタイズ)に関するガイドライン」
以下の図がわかりやすいです。(というかこの図覚えておくべき)
以下NISTの資料からの引用です。
その他データ消去関連の留意事項
- Slack space:ファイルに割り当てられディスクスペースを消費しているが、実際には使用しない領域。ファイルサイズがクラスターサイズの整数倍でない限り生じる
- ウェアレベリング機能により、クリアできないデータが残存する場合がある。
ウェアウェアレベリング機能
Trimとは | SSDのTRIM機能の役割は何ですか| Crucial Japan
対策としては、暗号化によるデータの削除が有効。 - SSDのオーバープロビジョニング領域のデータは、クリアできない
オーバープロビジョニング(Over-Provisioning) ― トランセンドの産業用製品に使われる技術|テックウインド株式会社 (tekwind.co.jp) - SSDについては米国国家安全保障局は、物理的破壊を要求している
- ワークステーションやサーバ全体の破壊はかなりのコストがかかる。一般にはサニタイズすべき。
- データの消去ツールとして(clear)DBANが有名
DBAN の使い方 - ハードディスクのデータを完全消去 - PC設定のカルマ (pc-karuma.net)
2.5 適切な資産保持を確実にする(エンド・オブ・ライフ(EOL)、エンド・オブ・サポート(EOS)等)
EOLとEOS
- EOL(End Of Life) - 製品のライフサイクルの終了・部品の生産、メンテナンスもしなくなる。後述のEOSが打ち切られていなければ、サポートのみは受けられる。
- EOS(End Of Support) - サポート打ち切り期限。EOLより後になるのが普通
2.6 データセキュリティ管理とコンプライアンス要件を決定する
データの状態(使用中、転送中、保管中等)
保存データ(At Rest)
保存データとは、システムに格納され、書き込み、読み取り、送信、またはその他の方法で処理されていないデータを表します。
※RAMに保存されているデータはどうか?というような問いが公式問題集にあります。答えは「使用中」。
転送中データ(In Motion)
ネットワーク経由、複数のネットワーク間、またはある場所から別の場所にアクティブに送信されているデータを指します。
※ テープに保存されて移動しているデータはどの状態か?答えはテープ内のストレージに保存されているので、保存中。
使用中(In Use)
ユーザ(人間、またはシステム)によって使用されているアプリケーションにより、アクティブに処理されているデータを表す。主にRAM,CPUキャッシュ、CPUレジスタ内にある。
範囲とテーラリング
組織の要件にしたがって、組織に適用できるガイドラインやフレームワークをカスタマイズすることです。テーラリングは「カスタマイズすること全体」を指すこともあれば、以下の用語のように限定的に用いられる場合もあります。
以下の3つの用語があります。
- テーラリング - 組織の要件にしたがってガイドラインやフレームワークの内容を変えること
- スコーピング - 組織の要件にしたがってガイドラインやフレームワークで不要な内容を削ること
- サプリメンテーション - 組織の要件にしたがってガイドラインやフレームワークに無い項目を追加すること
一般的なスタンダードなどをテーラリングする(上記3つを含む)によって、組織のベースラインを確立します。
※ベースライン - 組織が適用できるセキュリティ構成、コントロールのリスト
スタンダードの選定
フレームワーク
セキュリティコントロールのベースラインを確立する一つの方法は、既存のフレームワークを選択することです。代表的なフレームワークに以下があります。
- NIST SP800-37 “Risk Management Framework”
※IPAのサイトの方はRev1で古いので注意
- NIST Cybersecurity Framework(CSF)
NISTのRMFとCSFの関係性については以下のサイトがわかりやすい
セキュリティスタンダード
セキュリティフレームワークより一歩進んで、特定のセキュリティコントロールを具体的に推奨するものがあります。(PCIDSS,HIPAA,GDPR)
一般的なスタンダードの例:
- NIST SP800-53 Rev5 “Security and Privacy Controls for Federal Information Systems and Organizations”
NIST-SP800-53には末尾にAとBがつく2つの付属文書があります。
-
NIST SP800-53A Rev4 “Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans”
(セキュリティコントロールを評価するアセスメントのガイドライン)この文書の中で各セキュリティコントロールのカテゴリが示されています。これについて理解が必要です。
カテゴリ | 内容 |
---|---|
仕様 | 文書ベースの成果物(例えば、方針、手順、計画、システムセキュリティ及びプライバシー要件、機能仕様、アーキテクチャ設計) |
メカニズム | ハードウェア、ソフトウェア、またはファームウェアのセーフガードと対策 |
アクティビティ | バックアップ、監視など運用的作業 |
個人 | これらを実行する運用者及びセキュリティを適用する対象となる人々 |
- NIST-SP800-53B Control Baselines for Information Systems and Organizations
(セキュリティコントロールをテーラリングするためのガイドライン)
- ISO27001, ISO27002 所謂ISMS
テーラリングを実施するにあたって以下に注意する必要があります。
- 保護する資産の重要度(センシティビティ)
- 業界の要件(例えばクレジットカード業界)
- 規制要因(管轄区域など)
- コストと利益
※ CISSP CBK reference 6thより
データ保護の方法
データ保護の方法について、代表的なコントロールを知っておく必要があります。
いくつか用語とわかりやすいページを記載します。
デジタル著作権管理(DRM)
作品の著作者または出版者が、作品の購入者が行う権利をコントロールするために、その権利を行使するプロセス。暗号化して、DRMプロバイダを利用して正規利用者にのみ暗号化解除キーを提供するのが一般的。↓たとえばAWSの実装
データ損失防止(DLP)
主に特定のキーワードが外部に送信されてないか監視するソリューション。データの外部への不正な転送、機密情報や個人を特定できるデータ(PII)の流出を防止する。
ホスト対して監視するクライアント型と、ゲートウェイ型(=proxy型)がある。
ゲートウェイ型はNGFWやCASBに組み込まれていることが多い。
クラウドアクセスセキュリティブローカー(CASB) ※キャスビー
ユーザーとクラウドサービスプロバイダーの間を仲介するクラウドホスト型またはオンプレミス型のソフトウェアやハードウェアのこと。
この層を挟むことでセキュリティを確保したり、従業員の管理されないクラウドサービスのアクセスを監視したりできる。上記のDLP機能が中核に含まれる。
クラウドセキュリティポスチャマネジメント(CSPM)
クラウドの構成がセキュリティ的に問題ないかどうかをチェックするソリューション
AWSなど各クラウドサービス自身でも存在するし、サードパーティ製のものもある。
以上