家studyをつづって

IT技術やセキュリティで勉強したことをつづっています。

ゼロトラストについて調べてみた(NIST SP800-207)

ゼロトラストについてNISTのガイドライン(ドラフト)が公開されていました。

 

Draft NIST Special Publication 800-207(Zero Trust Architecture)

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207-draft.pdf

 

従来のセキュリティモデルである境界防御(Perimeter Defense)に替わる新たなセキュリティモデルとして最近よく聞く言葉なので、自分の勉強のためにガイドラインを読んでみました。

 

 

 

ガイドラインの構成

ガイドラインは以下の構成です。

  1. Introduction
  2. Zero Trust Network Architecture
  3. Zero Trust Architecture Logical Components
  4. Deployment Scenarios/Use Cases
  5. Threats Associated with Zero Trust Architecture
  6. Zero Trust Architecture and Existing Federal Guidance
  7. Migrating to a Zero Trust Architecture

 

ゼロトラストの定義

ガイドラインの2章では以下のように定義してあります。

An operative definition of ZTA is as follows:
Zero Trust Architecture (ZTA) provides a collection of concepts, ideas, and component relationships (architectures) designed to eliminate the uncertainty in enforcing accurate access decisions in information systems and services.

ゼロトラストアーキテクチャ(ZTA)は、情報システムおよびサービスで正確なアクセス決定を実施する際の不確実性を排除するために設計された概念、アイデア、およびコンポーネントの関係(アーキテクチャ)のコレクションを提供します。(Google翻訳)


個人的な解釈ですが、ゼロトラストでは、「リソース」(データだけでなく、サーバやプリンタ等のデバイスも含む)へのアクセスの不確実性を減らすため、認証による遅延は最小限に抑えながら、アクセスルールは最小に制限(信頼ゾーンの縮小)する考え方です。

f:id:iestudy:20200302222229p:plain

ゼロトラストのアクセス

ゼロトラストの論理構成

3章ではゼロトラストの論理構成を解説しています。

f:id:iestudy:20200302222340p:plain

ゼロトラストの論理構成
  • ポリシーエンジン(Policy Engine)
    リソースへのアクセス許可を最終決定する。
  • ポリシー管理者(Policy Administrator)
    クライアントとリソース間の接続を確立する。クライアントがリソースにアクセスするための認証トークンまたは資格情報を生成する。
  • ポリシー執行ポイント(Policy Enforcement Point)
    サブジェクト(ユーザやマシン)とリソース間の接続を有効にし、監視し、終了させる。

また、周辺にあるものは、例えば「Industry Compliance System(PCI DSS等の業界ルール)」等はゼロトラストのアクセスルールの決定などにかかわりのあるものです。

 

ゼロトラストの脅威

5章ではゼロトラストの脅威を解説しています。

  1. ZTA決定プロセスの転覆
    ZTAの主要なコンポーネントが侵害されてしまうこと
  2. DoS攻撃またはネットワークの中断
    ZTAの主要なコンポーネントが攻撃されて可用性を喪失すること
  3. 内部者の脅威
    悪意ある内部者により侵害されてしまうこと
  4. ネットワーク上の可視性
    企業が所有しないネットワークの状況がわからない
  5. ネットワーク情報の保存
    ネットワークトラフィック情報が狙われる
  6. 独自のデータ形式への依存
    独自のデータ形式を持つプロバイダに起因する相互運用の問題
  7. ZTA管理における非個人エンティティ(NPE)の使用
    攻撃者がエージェントになりすましてしまう

 

ゼロトラストの要件

Forrester Research社は、ゼロトラストに求める要件を定義しました。

 

ゼロトラストの要件

要件 ソリューションの例
ネットワークセキュリティ SWG(Secure Web Gateway)SDP(Software Defined Perimeter)
デバイスセキュリティ EDREPPMDM
アイデンティティセキュリティ IAM
ワークロードセキュリティ CWPP(Cloud Workload Protection Platform)
データセキュリティ DLP
可視化と分析 CASBSIEM
自動化 SOAR(Security Orchestrating and Automation Response)

 

また、同社の2019年Q4の「Zero Trust eXtended Ecosystem Platform Providers」の調査結果では以下の企業が対象となりました。

f:id:iestudy:20200302224220p:plain

Zero Trust eXtended Ecosystem Platform Providers

 

  • Akamai Technologies: Zero Trust Security
  • Check Point: Check Point Infinity Security Access
  • Cisco: Duo Beyond; Tetration; SD-Access
  • Cyxtera Technologies: AppGate SDP
  • Forcepoint: Forcepoint Zero Trust Suite
  • Forescout: The Forescout Platform
  • Google: Context-Aware Access for Enterprise
  • Illumio: Illumio Adaptive Security Platform
  • MobileIron: MobileIron Zero Trust Platform
  • Okta: Okta Identity Cloud
  • Palo Alto Networks: Palo Alto Networks
  • Proofpoint: Proofpoint
  • Symantec: Symantec Integrated Cyber Defense
  • Unisys: Unisys Stealth; Unisys Solutions Services

 

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

news.yahoo.co.jp

www.secure-sketch.com

 

 

NIST SP800-40の概要

概要

NIST SP800-40は、脆弱性とパッチの管理についてのガイドラインです。
日本語版について、IPAでは「NIST SP 800-40 Version 2.0(パッチおよび脆弱性管理プログラムの策定)」を公開しており、ゾーホージャパン株式会社では「Revision 3(エンタープライズ向けパッチ管理技術ガイド)」を公開しています。

パッチおよび脆弱性管理プログラムの策定(Ver.2)

http://ipa.go.jp/files/000025330.pdf

エンタープライズ向けパッチ管理技術ガイド(Ver.3)

https://www.manageengine.jp/solutions/nist_publications/nist_SP800-40/lp/

 

 

 このガイドラインでは、組織内部でパッチを特定し、配布を円滑に行うことを専門とした対策グループ(PVG:Patch and Vulnerability Group)を定義し、11の責務を示しています。

 

PVGの責務

  1. システムインベントリを作成する。
    PVGは、組織のITリソースに関する既存のインベントリを使って、組織内部で使用しているハードウェア機器、オペレーティングシステム、およびソフトウェアアプリケーションを確認する。PVGは、既存のインベントリでは把握されていないITリソースについても、手作業によってインベントリを管理する。

  2. 脆弱性、修正措置、および脅威を監視する。
    PVGは、セキュリティソースを監視して、PVGのシステムインベントリに含まれるソフトウェアに対応する脆弱性の公表、パッチやパッチ以外による修正措置、および新たに発生した脅威がないかどうかを確認する。

  3. 脆弱性修正措置の優先順位付けを行う。
    PVGは、組織における脆弱性修正措置の導入の優先順位を決定する。

  4. 組織固有の修正措置データベースを作成する。
    PVGは、組織に適用する必要がある修正措置のデータベースを作成する。

  5. 修正措置の一般的なテストを実施する。
    PVGは、標準化された構成を使用するIT機器を対象としたパッチおよびパッチ以外による修正措置のテストを実施する必要がある。これにより、現場の管理者が余分なテストを実行せずに済む。PVGは、現場の管理者と緊密に連携して、重要なシステムに対するパッチや構成変更のテストも行う。

  6. 脆弱性に対する修正措置を導入する。
    PVGは、脆弱性の修正措置を監督する。

  7. 現場の管理者に対して脆弱性および修正措置の情報を配布する。
    PVGは、組織のソフトウェアインベントリに存在し、かつ、PVGの守備範囲に含まれるソフトウェアパッケージの脆弱性と修正措置の情報を、現場の管理者に通知する責任を負う。

  8. パッチの自動導入を実施する。
    PVGは、エンタープライズ向けパッチ管理ツールを使ってIT機器に自動的にパッチを導入する。または、実際にパッチ管理ツールを実行するグループと緊密に連携することもできる。自動化されたパッチ適用ツールにより、管理者は 1 つのコンソールから数百あるいは数千のシステムを更新できる。デスクトップシステムが標準化されており、各サーバが同様の構成になっている均一なコンピュータプラットフォームの場合、導入はきわめて容易である。マルチプラットフォーム環境、標準でないデスクトップシステム、レガシーコンピュータ、および例外的な構成のコンピュータが組み込まれている場合であっても、自動化されたパッチ適用ツールを使用することができる。

  9. アプリケーションの自動更新を設定する(可能かつ該当する場合は常に)。
    最近のアプリケーションの多くは、ベンダーのWebサイトにアクセスして、適用可能なアップデートが存在するかどうかをチェックする機能を備えている。この機能は、パッチの特定、配布、インストールに必要な労力を最小限に抑える上で非常に有効である。ただし、組織の構成管理プロセスの妨げとなる可能性があるため、この機能の使用を望まない組織もあるだろう。推奨される方法としては、組織のネットワークから、自動更新プロセスを使ってパッチをローカルに入手する方法である。この場合、インターネット経由ではなく、ローカルネットワークからアプリケーションの更新が可能である。

  10. ネットワークおよびホストの脆弱性スキャンにより脆弱性修正措置を検証する。
    PVGは、脆弱性に対する修正措置が正常に行われたことを確認する。

  11. 脆弱性の修正措置についてトレーニングを行う。
    PVG は、管理者に対して、脆弱性の修正措置の実施に関する教育を施す。コンピュータへのパッチの適用をエンドユーザに委ねる場合、PVG は、エンドユーザに対して、適切な教育を施さなければならない。

パッチ管理技術

Revision 3ではパッチ管理技術について書かれています。4章ではパッチ管理機能3種類について説明されています。

特徴 エージェント型 エージェントレススキャン ネットワークのパッシブ監視
ホストに管理権限が必要か? はい はい いいえ
管理されていないホストをサポートするか? いいえ いいえ はい
リモートホストをサポートするか? はい いいえ いいえ
アプライアンス機器をサポートするか? いいえ いいえ はい
スキャンに帯域幅が必要か? 最小限 中程度から過度 なし
検出されるアプリケーションの範囲は? 包括的 包括的 暗号化されていないネットワークトラ フィックを生成するものに限定

 

 

 

BYODにおけるセキュリティ対策の考え方

私物端末の業務利用におけるセキュリティ要件の考え方

https://www.kantei.go.jp/jp/singi/it2/cio/hosakan/wg_report/byod.pdf

 

 

 

概要

この資料では、BYOD(Bring Your Own Device=私物端末を業務に利用すること)におけるセキュリティの考え方を解説しています。この資料におけるBYODでは、端末にはスマートフォンやタブレットに加えてデスクトップPCも含んでおり、また、業務システムへのアクセス経路は特定していません。

f:id:iestudy:20200223211311p:plain

BYODのイメージ

 

BYODの検討にあたって

この資料では、BYODの検討にあたって、以下のポイントを解説しています。

  1. BYODが本当に必要か? (何のためにBYODを認めるのか)
    • 目的を明確に。ニーズがあるのなら「どこまでやるか」を考えてみる。「隙間時間の有効活用」 「コスト削減」 「ワークライフスタイル対応」 「災害時への備え」
    実際に、BYODにするよりも、実施したい内容によっては会社支給の端末のほうが管理が容易になる場合もあります。想定しているBYODのメリットは、目的を明確にしていくことで、そこまで大きくないと判明する場合もあります。

  2. BYOD端末の機能や指定業務はできるだけ絞り込む (必要の無いことはやらない)

  3. BYODの管理ルールはシンプルに (現実的に運用できる内容とすること)

BYODの脅威と対策

 

脅威/リスク 対策一覧
①不正プログラム感染
- ソフトウェアの脆弱性
- OSの改造

【運】 利用者による不正プログラム感染防止対策の徹底

・ソフトウェアのバージョンを最新に保つ

・ウイルス対策ツールを使用しパタンファイルを最新に保つ

・OSの改造(Jailbreakやroot化)を禁止

【技】 端末接続時の認証やセキュリティ設定の確認機能を導入

・端末ソフトウェアのバージョンをチェック

・ウイルス対策ツールの導入有無と利用状況をチェック

・改造された端末を検知

②不正アプリ、有害サイト

【運】 利用者による不正アプリや有害サイトに対する対策の徹底

・信頼できないマーケットからのアプリ入手禁止

・アプリインストール時に不用意なデータやデバイスへのアクセス許可を禁止

・webアクセスフィルタの利用推奨

【技】 業務利用時のwebアクセスを業務システムのプロキシ経由とする

③端末の紛失・盗難

【運】 端末内の業務データを都度削除し、端末内に残さない

【運】 ID/パスワード等のログイン認証情報を端末に残さない

【運】 リモートロック/ワイプ等のセキュリティアプリ利用

【運】 タッチパネルの入力値推測等パスワード搾取行為への注意徹底

【運】 ストラップ等により端末を身体に固定する

【技】 セキュアブラウザや仮想デスクトップ等のツールを使用する

【技】 端末内のデータ暗号化やリモートロック/ワイプ機能を持つツールの利用

【技】 端末認証とユーザ認証を併用する

【技】 リモートアクセスゲートウェイのログ解析により不正アクセスを検知

④業務外アプリの利用
- データ同期アプリ 等

【運】 データ同期アプリ等特定アプリを利用しない

【技】 データ同期アプリ等特定アプリの利用を制限

⑤外部への情報出力
- メモリカードや他PC
- 紙媒体
- スクリーンショット

【運】 外部出力の禁止を徹底

【技】 業務利用時の外部出力機能やスクリーンショットを管理ツールで禁止

⑥ショルダーハッキング

【運】 覗き見防止機能やフィルタの着用の推奨

【運】 端末やサーバのログインパスワードの管理ルール徹底

⑦誤操作・知識不足

【運】 職員への教育研修

【運】 利用マニュアルの整備

⑧信頼性の低い通信サービス
- 通信区間の盗聴
- 無線LAN不正AP

【運】 信頼性の低い通信サービスの利用禁止

【技】 SSL・VPN等で通信内容を暗号化する

【技】 公衆無線LANの利用制限(信頼できる回線のみ利用)

⑨家族や知人の端末利用
- セキュリティ設定の変更
- ファイル共有サイト接続
- 業務情報や業務システムへの不正アクセス

【運】 組織が認めた利用者以外への貸与禁止

【運】 家族への注意喚起

 

 

プライバシーマーク制度(Pマーク)について

Pマークとは

プライバシーマーク制度は、日本産業規格「JIS Q 15001個人情報保護マネジメントシステム-要求事項」に適合して、個人情報の保護措置(PMS)を整備している事業者を認定する制度です。

一般的な傾向として、消費者の個人情報を適切に管理していることをアピールするため、BtoC企業で取得するケースが多いように感じます。

privacymark.jp

 

 

 

個人情報保護マネジメントシステム(PMS)とは

個人情報保護マネジメントシステム(Personal information protection Management Systems)は、JIS Q 15001では、個人情報を保護する体制があり、適切な手順で情報を取り扱い、継続的に改善する仕組みと定義しています。

 

PMSには以下のようなものが含まれます。

  • 個人情報保護方針の策定
  • 個人情報の管理責任者の任命
  • 個人情報特定、手順の文書化
  • 技術的対策、継続的な改善(監査)の実施

 

JIS Q 15001について

JISQ15001は、個人情報保護法の改正を受けて2017年に改正しています。

www.iestudy.work

 

主な変更点は以下の通りです。

 

個人情報の定義の追加

  1. 個人識別符号
    旅券番号や運転免許証番号、個人番号といった個人に割り当てられる符号や、指紋データや顔認識データなどの個人の身体の一部の特徴をデータ化したもの
  2. 要配慮個人情報
    以前の規格で機微な個人情報として扱っていたもの。人種や信条、病歴、犯罪の経歴など、第三者に知られることで本人が差別などの不利益を被る可能性がある個人情報を指します。
  3. 匿名加工情報
    個人情報を誰の情報かわからないように加工して、元の状態に復元できないようにした情報のこと。この匿名加工情報は個人情報に該当しないと定義されたため、本人の同意なしに第三者提供が可能となることから、企業では匿名加工情報を、ビッグデータに活用することができます。

 

トレーサビリティの確保

個人情報のトレーサビリティの確保が義務付けられました。

 

オプトアウト手続の厳格化

  • オプトイン
    個人情報を持つ本人が事前許諾した個人情報だけを第三者提供すること
  • オプトアウト
    個人情報を持つ本人が反対をしない限り、個人情報の第三者提供に同意したものとみなすこと

過去にあった個人情報の漏洩事件を鑑み、改正個人情報保護法ではオプトアウトを行っていることを個人情報保護委員会に届け出ることになりました。

www.miyake.gr.jp

 

外国の第三者への提供ルールの新設

個人データを外国の第三者への提供に関するルールが新たに策定されました。

 

 

 

 

 

機能要件と非機能要件

システムに対する要件

情報システムは現代社会において必要不可欠な様々な機能を提供しています。また、情報システムは社会的に重要なインフラとなっており、上記の機能以外に安定してサービスを提供することが求められます。

f:id:iestudy:20200115225914p:plain

機能要件と非機能要件

機能要件
業務実現に関する要求事項

 

非機能要件
機能要求以外の事項

 

非機能要求に含まれる項目

f:id:iestudy:20200115230106p:plain

非機能要件の分類

 


上記の要求項目に対して、IPAではユーザとベンダ間でシステムの要求事項に対する認識を共通化することで、適切な情報システムを構築するために「非機能要求グレード」を公開しています。

www.ipa.go.jp

 

「非機能要求グレード」とは

「非機能要求グレード」は、「非機能要求」についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的とし、非機能要求項目を網羅的にリストアップして分類するとともに、それぞれの要求レベルを段階的に示したものです。重要な項目から順に要求レベルを設定しながら、両者で非機能要求の確認を行うことができるツール群です。

 

 

 

改正個人情報保護法について

個人情報保護法とは

個人情報保護法は、2005年4月に施行された法律で個人情報を保護するための法律です。
施行を受け、各省庁ごとに法案で使われている用語や、各業界向けの安全管理の具体的な例が公開されています。

また、ビッグデータやIoTの流れを受け、2017年5月30日には改正個人情報保護法が施行されました。

 

 

 

個人情報保護法における個人情報の定義

第二条
この法律において「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの(他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。)をいう。

 

改正個人情報保護法における個人情報の定義

第二条
この法律において「個人情報」とは、生存する個人に関する情報であって、次の各号のいずれかに該当するものをいう。

一 当該情報に含まれる氏名、生年月日その他の記述等(文書、図画若しくは電磁的記録(電磁的方式(電子的方式、磁気的方式その他人の知覚によっては認識することができない方式をいう。次項第二号において同じ。)で作られる記録をいう。第十八条第二項において同じ。)に記載され、若しくは記録され、又は音声、動作その他の方法を用いて表された一切の事項(個人識別符号を除く。)をいう。以下同じ。)により特定の個人を識別することができるもの(他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。)

二 個人識別符号が含まれるもの

 

個人識別符号とは

  1. 身体の一部の特徴を電子計算機のために変換した符号
    DNA、顔、虹彩、声紋、歩行の態様、手指の静脈、指紋・掌紋
  2. サービス利用や書類において対象者ごとに割り振られる符号
    公的な番号(旅券番号、基礎年金番号、免許証番号、住民票コード、マイナンバー、各種保険証等)

 

個人情報保護法の適用範囲

5000件以上の情報を持つ個人情報取扱事業者が対象です。
事業として行っていることで個人情報を使用する場合は対象となります。
また、所持している個人情報が「過去6カ月以内に5000人」を超える日がある場合は対象となります。


改正個人情報保護法の適用範囲

改正により全ての事業者に対し、情報の取得・保管・提供・開示等において、法的規制がかかるようになりました。
これまで適用除外であった「取り扱う個人情報の数が5,000人以下」の企業も対象になり、監督官庁が個人情報保護委員会に一元化されます。

 

改正個人情報保護法の変更点

項番 概要 詳細
1 小規模事業者への対応 個人情報が5,000件以下の場合でも法律が適用される
2 努力義務の追加 「利用する必要がなくなったときは、
当該個人データを遅滞なく消去するよう努めなければならない」
(第十九条)
3 開示等請求権の明確化(新設) 第三十四条訴えを提起するときは、あらかじめ請求
4 個人情報データベース提供罪の新設 第八十三条自己若しくは第三者の不正な利益を図る目的で提供し、
又は登用したとき
5 外国への個人情報の第三者提供 原則、本人の同意取得が必要国内において第三者提供の
例外となる委託、事業承継、共同利用も対象
6 利用目的の制限 第十五条利用目的を変更する場合には、
変更前の利用目的と 関連を有すると合理的に見取られる範囲
7 情報の利用方法から見た規約対象の縮小 第二条第4項利用方法からみて個人の権利利益を害するおそれが少ないものとして政令で定めるものを除く
8 匿名加工情報の新設 一定の基準と加工方法に基づき加工された情報であって、
再識別の禁止を義務付けることで、
本人の同意不要で第三者提供が可能

 

関連:JIS Q 15001とプライバシーマーク

JIS Q 15001(個人情報保護マネジメントシステム ― 要求事項)は、事業者が業務上取り扱う個人情報を安全で適切に管理するための要求事項です。個人情報保護に関する規格にはJIS Q 15001を基にしたプライバシーマーク認証もあります。

 

JIS Q 15001とプライバシーマーク認証の比較

  JIS Q 15001 認証サービス プライバシーマーク認証
対象・単位 基本的に任意 法人単位
適用/認定基準 JIS Q 15001 JIS Q 15001
有効期間
(更新期間)
3年更新
(その間1年ごとに定期審査)
2年更新
審査機関 JQA 指定審査機関
証書 JQA発行のJIS Q 15001登録証 JIPDEC発行のプライバシーマーク登録証
他規格との組合せ ISO/IEC 27001との組合せ審査が可能 プライバシーマークの単独審査

 

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

https://www.ppc.go.jp/files/pdf/kojinjouhou_handbook.pdf

https://www.ppc.go.jp/files/pdf/28_setsumeikai_siryou.pdf

 

ISO27000ファミリーについて

ISO27000シリーズについて

ISO27000ファミリーは、国際標準化機構(ISO)と国際電気標準会議(IEC)によって策定された情報セキュリティマネジメントシステムに関する規格群のことで、中核を成すISO27001を始めとしたISMSに関する第三者認証規格のことです。

activation-service.jp

 

 

 

ISO27001

ISO27001は組織のISMSを認証するための要求事項が示されています。
組織はこの要求事項に準じたマネジメントシステムを構築することで規格の認証を受けることが可能です。
ISMSの認証を得ることを「ISO27001を取得する」と表現するのは、ISO27001が規格の要求事項であるためです。

 

ISMSについて

情報セキュリティマネジメントシステム(ISMS:Information Security Management System)は、組織における情報資産のセキュリティを管理するための枠組み。
情報セキュリティマネジメントとは、ISMSを策定し、実施すること。

ISMSの目標は、リスクマネジメントプロセスを適用することによって、情報の機密性、完全性及び可用性を維持し、かつ、リスクを適切に管理しているという信頼を利害関係者に与えることにある。

 情報セキュリティマネジメントシステム - Wikipedia

 

ISO27002

ISO27002は、ISO27001にて示されている要求事項をもとにより具体的な情報セキュリティマネジメントの管理策を示した規格です。

 

ISO27017

ISO27017は、クラウドサービスの利用者や提供者を対象として具体的なISMSの管理策を示した規格です。

 

ISO/IEC27001、27002、27017の関係

f:id:iestudy:20191220194337p:plain

ISO27000ファミリーの関係

 

上記の関係図にもありますが、ISO27017はISO27001をベースに、クラウドサービス特有の要素を加えた管理策となります。
そのため、ISO27017はそれ単体で取得することはできず、ISO27001の取得が前提条件となります。

 

ISO27002とISO27017の管理策の体系

ISO27017:2016 ISO27002:2014

序文

1 適用範囲

2 引用規格

3 定義及び略語

4 クラウド分野固有の概念

5 情報セキュリティのための方針群

6 情報セキュリティのための組織

7 人的資源のセキュリティ

8 資産の管理

9 アクセス制御

10 暗号

11 物理的及び環境的セキュリティ

12 運用のセキュリティ

13 通信のセキュリティ

14 システムの取得,開発及び保守

15 供給者関係

16 情報セキュリティインシデント管理

17 事業継続マネジメントにおける情報セキュリティの側面

18 順守

序文

1 適用範囲

2 引用規格

3 定義及び定義

4 規格の構成

5 情報セキュリティのための方針群

6 情報セキュリティのための組織

7 人的資源のセキュリティ

8 資産の管理

9 アクセス制御

10 暗号

11 物理的及び環境的セキュリティ

12 運用のセキュリティ

13 通信のセキュリティ

14 システムの取得,開発及び保守

15 供給者関係

16 情報セキュリティインシデント管理

17 事業継続マネジメントにおける情報セキュリティの側面

18 順守

参考 参考

上記の内容とも関連しますが、ISO27001がベースにあるため、ISO27002とISO27017の管理策を比較すると、基本的には同様の管理策であることがわかります。

 

余談:認証と保証

クラウドサービスに関する第3者認証は上記のISO27017のほかにSOCがあります。

www.iestudy.work

 

認証と保証の違いについて調べてみました。

 

認証

認証は、ISMSであれば、セキュリティマネジメントシステム要求事項(ISO27001)に合致しているかどうかを第三者が審査し登録する仕組みをさします。

www.jab.or.jp


保証

「保証」の前提として「監査」とは

「監査」とは、ある目的のために組織体の行為を、独立の立場にある第三者が検証・評価することで、その真実性や妥当性などを確認し、その結果を関係者に報告すること。これにより、なんらかの説明責任を果たし、一定の信頼を付与する機能や行為。

http://lab.iisec.ac.jp/~harada_lab/lab/2013/20130930.pdf

 

「監査」における「保証」とは

合理的保証(reasonable assurance)

「保証型監査の監査人が情報セキュリティ監査基準に従って監査を実施した結果、言明と、監査人が把握した事実との間に相違がないことについて、相当程度の心証を得たとの専門家としての判断を結論として述べること」

保証型監査における保証業務の定義

「監査対象の経営者が発した言明に対し、監査人が合理的な方法と証拠に基づき、
監査の対象となる組織体の情報セキュリティに関するマネジメントとコントロールが監査手続きを実施した限りにおいて、適切である旨(または不適切である旨)の意見を述べること」 

保証型監査における保証程度の度合い

保証型監査においては、「合理的保証」のみが存在しうると考える。ここでいう合理的とは、経済的合理性、技術的合理性、社会的合理性などを意味する。

なので、保証という言葉の意味するところは、監査対象のサービスやシステムにおいてインシデントが絶対に発生しない、という保証ではなくて、一定の基準に従って監査を行った結果、問題ないということの保証になります。

www.jasa.jp

「保証」は、「認証」と比較として、より高い水準の検査に適合していると考えることができます。

 

ISO27017とSOCの比較

  ISO27017 SOC
基準の位置づけ 国際的な標準規格 AICPAが定めたTrustサービスの原則基準
難易度 比較的容易 高度
成果物と公開範囲 認証の登録 認証登録はWebサイト等で不特定多数に公開可能 報告書 SOC2の場合はサービスの利用者に公開が限定される
訴求効果 情報セキュリティに対し、一定レベルでのマネジメントが確立していることを証明する。 セキュリティに関して、より高い水準での評価があることを訴求できる。

www.eyjapan.jp

 

ファジングについて

ファジング実践資料(テストデータ編)

発行機関:IPA

発行年月日:2013年11月

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

 

 

 

概要

ファジング実践資料(テストデータ編)は、ファジングで問題を検出するための「テストデータ」に焦点を当てた実践資料です。
IPAでは、ファジングにおけるテストデータの考え方「データ構造の『どの部分』を『どのように』細工するか」を解説しています。


ファジングとは
ファジング(fuzzing)とは、問題を起こしそうなデータ(例:極端に長い文字列)を対象製品に送り、対象製品の動作状態から脆弱性などを発見するテスト手法です。
 

ファジングにおける「テストデータ」

ファジングの「テストデータ」は、製品に何か問題を起こしそうなデータで、仕様に則っていないデータがテストデータになりえます。

テストデータは、製品が受け取るデータのデータ構造を解釈するかどうかで、大きく2種類に分かれます。

データ構造の解釈 テストデータの作り方
解釈する

データ構造の要素をそれぞれ細工してテストデータを作る。

Generation based fuzzing、Smart fuzzing、Intelligent fuzzingなどと呼ばれる。

解釈しない

元となるデータを読み込み、そのデータをランダムに変更する。

(Mutation based fuzzing)

まったくランダムな値からデータを作る

(Dumb fuzzing)

 

 

 

クラウドに対するセキュリティの考え方

CSAとは

クラウドセキュリティアライアンス(CSA)は、クラウド利用にあたってのセキュリティの考え方について発信している非営利法人団体です。

www.cloudsecurityalliance.jp

 

 

 

CCMについて
Cloud Controls Matrix(CCM)は、クラウドサービスのセキュリティリスクを総合的に評価するための指針です。
CCMではクラウドのセキュリティ管理策のフレームワークを16のドメインに分けて記述しています。


CCMの16ドメイン

  1. Application & Interface Security (アプリケーションとインターフェース
    セキュリティ)
  2. Audit Assurance & Compliance(監査・保証とコンプライアンス)
  3. Business Continuity Management & Operational Resilience(事業継続管理と運用レジリエンス)
  4. Change Control & Configuration Management(変更管理と構成管理)
  5. Data Security & Information Lifecycle Management(データセキュリティと情報ライフサイクル管理)
  6. Datacenter Security(データセンタセキュリティ)
  7. Encryption & Key Management(暗号化と鍵管理)
  8. Governance and Risk Management(ガバナンスとリスク管理)
  9. Human Resources(人事)
  10. Identity & Access Management(アイデンティティとアクセス管理)
  11. Infrastructure & Virtualization Security(インフラと仮想化のセキュリティ)
  12. Interoperability & Portability(相互運用性と移植容易性)
  13. Mobile Security(モバイルセキュリティ)
  14. Security Incident Management, E-Discovery & Cloud Forensics(セキュリティインシデント管理、Eディスカバリ、クラウドフォレンジックス)
  15. Supply Chain Management, Transparency and Accountability(サプライチェーンの管理、透明性、説明責任)
  16. Threat and Vulnerability Management(脅威と脆弱性の管理)

 

CCMでは、クラウドサービスの利用にあたって、各ドメインで解説されているセキュリティのコントロールを参照することで、概略でのチェックリストとして利用することができます。

 

また、CCMは他のセキュリティフレームワーク(ISO27001/27002、ISACAのCOBIT、PCI DSS、NIST、AICPAのTSP、FedRAMP、ENISAのIAFなど)へのマッピングがされており、ISMSユーザの場合であれば、CCMとISMSの対応を確認することで、ISMSベースでのセキュリティチェックができます。

CCMVer3からは、AICPA/SOC2にも対応しており、情報セキュリティに加えて、ITガバナンスとの関係も含めてチェックできるようになりました。

 

参考:SOCについて

www.iestudy.work

 


CCMのイメージ

f:id:iestudy:20191205110450p:plain

CCMのイメージ

 

余談:Excelの翻訳機能

Excelに翻訳機能があることを知りました。

「校閲」ー「翻訳」を選択すると上図の右側にある「トランスレーター」という枠に英文と和訳の文章が表示されます。

 

 

 

ウェブサイトにおける脆弱性検査手法の紹介の概要

ウェブサイトにおける脆弱性検査手法の紹介
発行機関:IPA
発行年月日:2013年12月

www.ipa.go.jp

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

 

 

 

2013年は脆弱性が原因で、情報漏洩などのインシデントが多数発生しました。このレポートでは、管理者がコストをかけずに脆弱性の診断ができるように、オープンソースの脆弱性検査ツールについて、特徴や使い勝手をまとめています。

 

脆弱性診断ツール一覧 

タイプ ツール名 検査対象 特徴
手動検査 Paros Webアプリ 脆弱性検査に脆弱性を検出するコードの知識が必要となる
手動検査 WebScrab Webアプリ

セッションIDの詳細な調査ができる。

セッション系の脆弱性検査に強みがある。

自動検査 OWASP ZAP Webアプリ 日本語に対応しており、検査が容易にできる
自動検査 skipfish Webアプリ CUIによる操作のため、上級者向け
自動検査 OpenVAS

Webアプリ

ミドルウェア

OS

Nessusから派生したオープンソースツール
自動検査 Nikto

Webアプリ

ミドルウェア

Webアプリの脆弱性やポートの稼働状況等を

容易に検査できる

通信監視型 Ratproxy Webアプリ

検査コードを送信しない。

環境に影響を与えずに検査ができる