家studyをつづって

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

フィッシング対策ガイドラインの比較(2020年版と2019年版)

概要

フィッシング対策協議会では、フィッシング詐欺の被害を防ぐためにWebサービス事業者に向けた対策をまとめたガイドラインを公開しています。 

www.antiphishing.jp

2020年度版では、最近の脅威動向を踏まえ対策要件を見直し、また、優先度の設定が見直されています。

また、ガイドラインの対策要件の中でも、ユーザがフィッシング被害を減らすために事業者が特に重点的に取り組むべきものを5つにまとめ公開しています。

https://www.antiphishing.jp/report/phishing_report_2020.pdf

 

関連記事:2019年度版 

www.iestudy.work

 

 

 

2020年度版と2019年度版の比較

ガイドラインで公開されている要件一覧について、2020年度版と2019年度版を比較してみました。

※赤字は変更箇所です。 

2020年版 2019年版
Web サイト運営者が考慮すべき要件一覧
【要件1】◎:利用者に送信するメールには電子署名を付与すること 【要件1】◎:利用者に送信するメールには電子署名を付与すること
【要件2】◎:外部送信用メールサーバを送信ドメイン認証に対応させること 【要件2】◎:外部送信用メールサーバを送信ドメイン認証に対応させること
【要件3】◎:利用者へのメール送信では、制作・送信に関するガイドラインを策定し、これに則って行うこと 【要件3】◎:利用者に送信するメールでは定型的な様式を用いること
【要件4】:Web サイト運営者が利用者に送信するメールはテキスト形式とすること 【要件4】◎:Web サイト運営者が利用者に送信するメールはテキスト形式とすること
【要件5】◎:利用者に情報発信する手段および内容を周知すること 【要件5】◎:利用者に情報発信する手段および内容を周知すること
【要件6】◎:Web サイトの正当性に係る情報を十分に提供する画面とすること 【要件8】◎:Web サイトの正当性に係る情報を十分に提供する画面とすること
【要件7】◎:すべてのページにサーバ証明書を導入すること 【要件9】 ◎:サーバ証明書を導入すること
【要件8】◎:正規Web サイトのドメイン内設置サーバの安全性を確認すること 【要件10】◎:正規Web サイトのドメイン内設置サーバの安全性を確認すること
【要件9】○:認証システムが許容するポリシを利用者に示すこと 【要件11】○:認証システムが許容するポリシを利用者に示すこと
【要件10】○:色々なチャネルで利用者に対する脅威の状況を提供する 【要件12】○:色々なチャネルで利用者に対する脅威の状況を提供する
【要件11】◎:利用者に端末を安全に保つよう、注意を促すこと 【要件14】◎:利用者に端末を安全に保つよう、注意を促すこと
【要件12】◎:複数要素認証を要求すること 【要件15】◎:資産の移動を実行する前に、複数要素認証を要求すること
【要件13】◎:資産の移動に限度額を設定すること 【要件16】◎:資産の移動に限度額を設定すること
【要件14】◎:資産の移動時に利用者に通知を行うこと 【要件17】◎:資産の移動時に利用者に通知を行うこと
【要件15】○:利用者の通常とは異なるアクセスに対しては追加のセキュリティを要求すること  
【要件16】○:登録情報を変更するページへの移動には再度認証を要求すること 【要件19】○:登録情報を変更するページへの移動には再度認証を要求すること
【要件17】○:重要情報の表示については制限を行う 【要件20】○:重要情報の表示については制限を行う
【要件18】○:認証情報は厳格に管理すること(アカウントは不必要に発行しない) 【要件22】○:認証情報は厳格に管理すること(アカウントは不必要に発行しない)
【要件19】◎:アクセス履歴の表示 【要件23】◎:アクセス履歴の表示
【要件20】◎:利用者の認知している Web サイト運営者名称から連想されるドメイン名とすること 【要件26】◎:利用者の認知している Web サイト運営者名称から連想されるドメイン名とすること
【要件21】◎:使用するドメイン名と用途の情報を利用者に周知すること 【要件27】◎:使用するドメイン名と用途の情報を利用者に周知すること
【要件22】◎:ドメイン名の登録、利用、廃止にあたっては、自社のブランドとして認識して管理すること 【要件28】△:ドメイン名の登録、登録、利用、廃止にあたっては、ドメイン名を自己のブランドとして認識して管理すること
【要件23】◎:フィッシング詐欺対応に必要な機能を備えた組織編制とすること 【要件29】◎:フィッシング詐欺対応に必要な機能を備えた組織編制とすること
【要件24】◎:フィッシング詐欺に関する報告窓口を設けること 【要件30】◎:フィッシング詐欺に関する報告窓口を設けること
【要件25】◎:フィッシング詐欺発生時の行動計画を策定すること 【要件31】◎:フィッシング詐欺発生時の行動計画を策定すること
【要件26】◎:フィッシング詐欺および対策に関わる最新の情報を収集すること 【要件32】◎:フィッシング詐欺および対策に関わる最新の情報を収集すること
【要件27】◎:フィッシングサイト閉鎖体制の整備をしておくこと 【要件33】◎:フィッシングサイト閉鎖体制の整備をしておくこと
【要件28】○:フィッシングサイトアクセスブロック体制の整備をしておくこと 【要件34】○:フィッシングサイトアクセスブロック体制の整備をしておくこと
【要件29】◎:利用者が実施すべきフィッシング詐欺対策啓発活動を行うこと 【要件35】◎:利用者が実施すべきフィッシング詐欺対策啓発活動を行うこと
【要件30】◎:フィッシング詐欺発生時の利用者との通信手段を整備しておくこと 【要件36】◎:フィッシング詐欺発生時の利用者との通信手段を整備しておくこと
【要件31】○:Web サイトに対する不審なアクセスを監視すること 【要件37】○:Web サイトに対する不審なアクセスを監視すること
【要件32】△:フィッシング詐欺検出サービスを活用すること 【要件38】△:フィッシング詐欺検出サービスを活用すること
【要件33】△:端末の安全性を確認すること 【要件39】△:端末の安全性を確認すること
【要件34】△:バウンスメールを監視すること 【要件40】△:バウンスメールを監視すること
  【要件6】◎:Web サイトの安全性を確保すること
  【要件7】◎:ユーザに提供するアプリケーションの安全性を確保すること
  【要件13】△:認証画面には利用者個別のマークなどを表示できるようにする
  【要件18】○:正規Web サイトにアクセス可能な端末を制限すること
  【要件21】○:パスワードのブラウザへの保存については禁止する
  【要件24】△:特別な認証方法を採用する場合には、その方式に特有の脆弱性対策を行うこ と
  【要件25】○:正規サイトログイン時の認証には複数要素認証を利用すること
利用者が考慮すべき要件一覧
【要件35】◎:ソフトウエアは信頼できるサイトからインストールする 【要件41】◎:ソフトウエアは信頼できるサイトからインストールする
【要件36】◎:最新のソフトウエアを利用する 【要件42】◎:最新のソフトウエアを利用する
【要件37】◎:セキュリティ対策ソフトウエアの機能を理解し適切に用いる 【要件43】◎:セキュリティ対策ソフトウエアの機能を理解し適切に用いる
【要件38】○:端末の利用には一般ユーザアカウントを利用する 【要件44】○:端末の利用には一般ユーザアカウントを利用する
【要件39】○:URLフィルタリングを活用すること 【要件45】 ○:URLフィルタリングを活用すること
【要件40】 ◎:個人情報の入力を求めるメールを信用しない 【要件46】◎:個人情報の入力を求めるメールを信用しない
【要件41】◎:メールに記載される差出人名称は信用しない 【要件47】◎:メールに記載される差出人名称は信用しない
【要件42】◎:怪しいメールの判断基準を知る 【要件48】◎:怪しいメールの判断基準を知る
【要件43】◎:安全なメールサーバを活用したり、類似性評価によるフィッシングメール判 別機能を活用すること 【要件49】◎:安全なメールサーバを活用したり、類似性評価によるフィッシングメール判 別機能を活用すること
【要件44】◎:リンクにアクセスする前に正規メールかどうか確認する 【要件50】◎:リンクにアクセスする前に正規メールかどうか確認する
【要件45】◎:正しいURLを確認する 【要件51】◎:正しいURLを確認する
【要件46】◎:電子メール本文中のリンクには原則としてアクセスしない 【要件52】◎:電子メール本文中のリンクには原則としてアクセスしない
【要件47】◎:正しいURLと錠前マークを確認する 【要件53】◎:錠前マークを確認する
【要件48】○:Web サイト運営者からの通知メール形式をテキスト形式に設定する 【要件54】○:Web サイト運営者からの通知メール形式をテキスト形式に設定する
【要件49】◎:アカウントID/パスワードは Web サイト別に設定する 【要件55】◎:アカウントID/パスワードはWebサイト運営者別に設定すること
【要件50】◎:全てのアカウントについて緊急連絡先を把握しておくこと 【要件57】◎:全てのアカウントについて緊急連絡先を把握しておくこと
  【要件56】◎:アカウント管理ソフトウエアを導入する

 

 

 

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

背景

色々なIT技術を使ったサービスが次々に登場し、個人情報を含む、様々な情報が活用されています。
個人情報保護法ではそういった社会情勢を踏まえ、平成27年(2015年)より「いわゆる3年ごとの見直し」(附則第12条3項)を設けました。

個人情報保護法は前回の改正(施行は2017年)より3年が経過しており今年2020年に改正されます。

 

 

 

改定概要

  1. 個人の権利の在り方
    〇利用停止・消去等の個人の請求権について、不正取得等の一部の法違反の場合に加えて、個人の権利又は正当な利益が害されるおそれがある場合にも要件を緩和する。
    〇保有個人データの開示方法について、電磁的記録の提供を含め、本人が指示できるようにする。
    ※現行は、原則として、書面の交付による方法とされている。
    〇個人データの授受に関する第三者提供記録について、本人が開示請求できるようにする。
    〇6ヶ月以内に消去する短期保存データについて、保有個人データに含めることとし、開示、利用停止等の対象とする。
    〇オプトアウト規定により第三者に提供できる個人データの範囲を限定し、①不正取得された個人データ、②オプトアウト規定により提供された個人データについても対象外とする。

  2. 事業者の守るべき責務の在り方
    〇漏えい等が発生し、個人の権利利益を害するおそれがある場合に、個人情報保護委員会への報告及び本人への通知を義務化する。(現行法は努力義務)
    〇違法又は不当な行為を助長する等の不適正な方法により個人情報を利用してはならない旨を明確化する。

  3. 事業者による自主的な取組を促す
    〇認定団体制度について、現行制度に加え、企業の特定分野(部門)を対象とする団体を認定できるようにする。

  4. データ利活用に関する施策の在り方
    〇イノベーションを促進する観点から、氏名等を削除した「仮名加工情報」を創設し、内部分析に限定する等を条件に、開示・利用停止請求への対応等の義務を緩和する。
    〇提供元では個人データに該当しないものの、提供先において個人データとなることが想定される情報の第三者提供について、本人同意が得られていること等の確認を義務付ける。

  5.  ペナルティの在り方
    個人情報保護委員会による命令違反・個人情報保護委員会に対する虚偽報告等の法定刑を引き上げる。

  6. 法の域外適用・越境移転の在り方
    〇日本国内にある者に係る個人情報等を取り扱う外国事業者を、罰則によって担保された報告徴収・命令の対象とする。
    〇外国にある第三者への個人データの提供時に、移転先事業者における個人情報の取扱いに関する本人への情報提供の充実等を求める。

「仮名加工情報」の新設

仮名加工情報とは

第2条
この法律において「仮名加工情報」とは、次の各号に掲げる個人情報の区分に応じて当該各号に定める措置を講じて他の情報と照合しない限り特定の個人を識別することができないように個人情報を加工して得られる個人に関する情報をいう。
一 第1項第1号に該当する個人情報
当該個人情報に含まれる記述等の一部を削除すること(当該一部の記述等を復元することのできる規則性を有しない方法により他の記述等に置き換えることを含む。)。
二 第1項第2号に該当する個人情報
当該個人情報に含まれる個人識別符号の全部を削除すること(当該個人識別符号を復元することのできる規則性を有しない方法により他の記述等に置き換えることを含む。)。

 

これは、2019年に話題となった、就活における内定辞退率のデータ活用の問題が背景にあります。 

情報提供元(A社)では個人情報に該当しないデータであっても、情報の提供先(B社)では、ほかの情報と突合することで、個人を特定できるような情報の提供にあたっては、個人に対して許可を求めることを規定しています。 

f:id:iestudy:20200602112015p:plain

仮名加工情報のイメージ

 

関連情報

 

www.iestudy.work

www.iestudy.work

 

 

「Guidelines for Securing Wireless Local Area Networks(WLANs)」の概要 NIST SP800-153

Guidelines for Securing Wireless Local Area Networks(WLANs)

NIST Special Publication 800-153

発行年月日:2012年2月

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-153.pdf

 

 

 

概要

このガイドラインは、NISTが企業の無線LAN環境をセキュアに利用するための推奨事項をまとめたものです。

章構成は以下の通りです。

Executive Summary
1. Introduction
1.1 Authority
1.2 Purpose and Scope
1.3 Audience
1.4 Document Structure
2. WLAN Security Configuration
2.1 Configuration Design
2.1.1 Needs Gathering
2.1.2 WLAN Architecture
2.2 Configuration Implementation, Evaluation, and Maintenance
3. WLAN Security Monitoring
3.1 WLAN Security Monitoring Basics
3.1.1 Attack Monitoring
3.1.2 Vulnerability Monitoring
3.2 Monitoring Tools
3.3 Continuous Monitoring Recommendations
3.4 Periodic Assessment Recommendations

2章では無線LANの設計にかかわる内容が、3章には無線LANのモニタリングにかかわる内容が示されています。

f:id:iestudy:20200529135842p:plain

無線LANの基本構成

※無線LANの基本構成のうち、DS(Distribution System)は無線LANコントローラに相当するもの

 

2章のうち、2.1.1では無線LANの設計にあたって、無線LANを利用する組織が外部から要求される事項(法律等)の収集を示しています。
また、2.1.2以降では無線LANの原則をまとめています。

 

無線LANの原則 

一つ目の原則は、プロファイルの異なるWLAN(ゲストや社内LAN)を分けることです。

An important principle of WLAN security is to separate WLANs with different security profiles.

 


二つ目の原則は、デュアル接続クライアントデバイスへの対策です。
このガイドラインでは、「デュアル接続」を有線ネットワークと無線LANの両方に同時に接続されているデバイスとしており、デュアル接続端末を介して、無線側から有線側に攻撃できるリスクを示しています。上記については以下のような対策が示されています。

  • 使用が許可されていないすべてのネットワークインターフェイスを無効にする
  • ブリッジング(ネットワーク間のトラフィックの受け渡し)を無効にする

 

3章では、無線LANのモニタリングについて解説しています。

このガイドラインでは主に無線LAN特有の監視ポイントを解説しており、接続先のシステム(通常の有線LAN部分)については、NIST SP800-53及び94を参照としています。

 

無線LANの脅威として、以下のように整理がされています。

 

無線LANの脅威

パッシブな攻撃:攻撃者が無線LANを監視するタイプ

  • 盗聴
  • トラフィック分析

アクティブな攻撃:攻撃者が無線LANを攻撃するタイプ

  • マスカレード(なりすまし)
  • リプレイ(パッシブ攻撃により通信を監視し、メッセージを再送信)
  • メッセージの改ざん
  • サービス拒否(DoS)
  • 横領(無線LANの不正利用)

 

上記の脅威に対して、継続的なモニタリング定期的なモニタリングを解説しています。

継続的なモニタリング

  • 不正なAPおよび不正なクライアントデバイスの監視
  • 脆弱なプロトコルの利用
  • 異常な無線LAN利用
  • 無線LAN攻撃ツールの使用の有無
  • DoS攻撃
  • IPS等によるなりすましおよび中間者攻撃

 

定期的なモニタリング

以下の評価項目は少なくとも年1回の実施が示されています。

  • 無線LANで送信されるデータのセキュリティレベル
  • 無線LANクライアントが環境に接続/切断する頻度
  • 無線LANクライアントの一般的なトラフィック状況
  • 無線の電波強度 

 

 

 

「政府情報システムにおけるクラウドサービスの利用に係る基本方針」の概要

政府情報システムにおけるクラウドサービスの利用に係る基本方針

発行年月日:2018年6月7日

https://cio.go.jp/sites/default/files/uploads/documents/cloud_%20policy.pdf

 

 

 

概要 

内閣官房IT総合戦略室は、標準ガイドライン付属文書「政府情報システムにおけるクラウドサービスの利用に係る基本方針」を追加しました。
当該ガイドラインは、政府情報システムのシステムについて、クラウドサービスの採用をデフォルト(クラウド・バイ・デザイン)とし、クラウドサービス利用にあたってのガイドラインです。

 

クラウド・バイ・デフォルト原則に基づく利用検討プロセス

Step0:検討準備

クラウドサービスを利用するにあたって、対象となる業務を明確化して検討を行います。検討するポイントには以下のようなものがあります。

1) 業務の基本属性
(1) 主なサービス利用者(国民向けサービスか、職員向けサービスか)及
びその利用者の詳細
(2) インターネット利用を前提とした業務か否か
(3) サービスの種別(特定の業務か、コミュニケーション系か)等
(4) 他のサービスやシステムとの連携

2) 必要なサービスレベル
(1) サービス提供時間
(2) 障害発生時の復旧許容時間
(3) 災害対策の要否等

3) サービス・業務の定常性
(1) 定常的なサービス・業務か、試行的又は一時的なサービス・業務か

4) 業務量
(1) 業務処理量の総量、単位時間当たりの処理量の予測
(2) 業務処理量の変動(増加・減少、ピーク特性等)予測

5) 取り扱う情報
(1) 府省の情報セキュリティポリシー等に基づいた情報の格付け(機密性、
完全性、可用性)、取扱制限

 

Step1: SaaS(パブリック・クラウド)

検討結果を踏まえ、対象業務にかかわるシステムがパブリック・クラウドで提供されている場合は、パブリッククラウドの利用を検討します。

クラウドサービスの選定については、以下の事項を満たすものを利用することが示されています。

1) クラウドサービスの選定
(1) SaaS(パブリック・クラウド)においては、コミュニケーション系のクラウドサービスでは、十分な稼働実績を有し、運用の自動化、サービスの高度化、情報セキュリティの強化、新機能の追加等に積極的かつ継続的な投資が行われ、サービス終了のリスクが低い、クラウドサービスを選定するものとする。IaaS/PaaS をインフラ部分として構築された業務系の SaaS については、少なくとも、そのインフラ部分において、コミュニケーション系のクラウドサービスと同等の投資が行われていることが望ましい。
(2) 統一基準に定める「クラウドサービスの利用に関する遵守事項」を満たすクラウドサービスを選定するものとする。
(3) コミュニケーション系のクラウドサービスについては、クラウドセキュリティ認証等(「セキュリティクラウド認証等」参照)を必須とするものとする。業務系のクラウドサービスについては、そのインフラ部分において、クラウドセキュリティ認証等と同等のサービスであることが望ましい。
(4) クラウドサービスに保存される利用者データの可用性の観点から、我が国の法律及び締結された条約が適用される国内データセンタと我が国に裁判管轄権があるクラウドサービスを採用候補とするものとする。ただし、データの保存性、災害対策等からバックアップ用のデータセンタが海外にあることが望ましい場合、又は争訟リスク等を踏まえ海外にあることが特に問題ないと認められる場合はこの限りではない。

2) 情報セキュリティ
(1) 特定秘密(特定秘密の保護に関する法律(平成 25 年法律第 108 号)第3 条第 1 項に規定する特定秘密をいう。)及び行政文書の管理に関するガイドライン(内閣総理大臣決定。初版平成 23 年 4 月 1 日。)に掲げる秘密文書中極秘文書に該当する情報をパブリック・クラウド上で扱わないものとする。
(2) クラウドセキュリティ認証等の認証基準、監査フレームワークの監査報告書の活用や個別の調査等により、クラウドサービス提供者から提供されているサービスが統一基準を満たしていることを確認するものとする。
(3) クラウドサービス利用時の伝送路は暗号化するものとする。格納されるデータやデータベースについても、機微な情報については暗号化を行うものとする。データの暗号化に使用する鍵については、クラウドサービス提供者側よりも利用者側で管理することが望ましく、選択可能な場合は利用者側で鍵管理が可能な暗号機能を選ぶものとする

3) クラウドサービスの利用
(1) データバックアップは、クラウドサービスの全体的な災害や障害に備え、クラウドサービスの外部でも保管することが望ましい。
(2) 将来、他のクラウドサービスに移行可能となるように、データ移行の手段を情報システムの要件定義当初から考慮しておくものとする。
(3) 情報システムの運用において管理に必要なログの種類とクラウドサービス上取得できるか否か、その際の利用料金等をあらかじめ確認しておくものとする。

 

Step2: SaaS(プライベート・クラウド)

Step1までの検討結果を踏まえ、対象業務の性質によって、パブリッククラウドではなく、プライベートクラウドが望ましい場合があります。

Step3:IaaS/PaaS の利用検討

Step2までの検討結果を踏まえ、SaaS の利用が難しい場合は、IaaS/PaaSの利用が検討されます。クラウドサービスの選定については、以下の事項を満たすものを利用することが示されています。

1) クラウドサービスの選定
2) 情報セキュリティ
※上記はSaaSのものと同様
3) クラウドサービスの利用
(1) IaaS/PaaS(パブリック・クラウド)の利用においては、「3.33)クラ
ウドサービスの利用」の(2)に掲げる事項と同様の取扱いとするものとす
る。
(2) データバックアップは、データの完全性やデータリカバリのコストのバランスを踏まえ、同一クラウドサービスの内部で複数作成するものとする。また、クラウドサービスの全体的な災害や障害に備え、クラウドサービスとは別に外部でも保管することが望ましい。
(3) 24 時間 365 日のサービス提供が必要不可欠である情報システムについてはサービスの冗長化を行う。フェイルオーバー時の運用についてもあらかじめ準備を行っておくものとする。
4) システム移行
既存システムをクラウドサービスに移行させる際には、クラウドに最適化されたアプリケーションとして改修した上で移行することが望ましい。
5) オンプレミス等と連携するシステム形態について
パブリック・クラウドを利用する際に、オンプレミスやプライベート・クラウド上で運用する情報システムとパブリック・クラウド上で運用する情報システムとを連携させるシステム形態については、情報システムの複雑性が増し、結果として高コストとなること及び複雑性に起因する情報セキュリティ対策の困難さが増すことに留意するものとする。例えば、システム移行や既存システムとの連携等で当該形態とならざるを得ない場合や、連携させるオンプレミスやプライベート・クラウドが利用を検討しているパブリック・クラウドよりも明確に高い水準の情報セキュリティ対策を実装している場合は、メリットとリスクを明確にした上で利用するものとする。

 

Step4: IaaS/PaaS(プライベート・クラウド)

Step3 までの検討結果を踏まえ、IaaS/PaaS(パブリック・クラウド)の利用が難しい場合は、IaaS/PaaS(プライベート・クラウド)の利用を検討します。

ここで利用が想定されるのは独自の業務にかかわる小規模のシステムが例に挙げられています。


上記の検討を踏まえてもクラウドの利用が向かないものについてはオンプレミスの利用が検討されます。

 

補足:クラウドネイティブについて

クラウド・バイ・デフォルト(クラウドファースト)はシステムを導入する際に、クラウドを使うことを、まず検討するというような意味となります。

さらに踏み込んだ(進んだ、突っ込んだ)言葉として、クラウドネイティブという言葉があります。

クラウドネイティブはシステムをクラウド上に構築するだけではなく、そのうえで実行されるアプリケーションについてもクラウド環境に最適化(これがつまり、コンテナを利用すること、と理解しています。)することも意味します。
クラウドネイティブは「Cloud Native Computing Foundation」(CNCF)が推進しており、そのような考え方をまとめています。

github.com

 

 

 

 

ネットワークセキュリティ製品のテスト基準を策定する「NetSecOpen」

先日、Sonicwallの製品評価に関する記事を読みました。

blog.sonicwall.com

上記の記事に出てきた「NetSecOpen」について調べてみました。

 

 

 

NetSecOpenとは

NetSecOPENは、ネットワークセキュリティベンダー等が参加している、会員制の非営利団体で、ネットワークセキュリティ製品の評価または認証に使用できるテスト基準を策定することを目的に活動しています。

 

f:id:iestudy:20200518231420p:plain

NetSecOpenのメンバー

評価指標

評価指標には以下のようなものがあります。

  • ブロック率
  • TCP同時接続率
  • アプリケーショントランザクション
  • URL反応時間
  • 最初のバイトを受信するのにかかる時間(TTLB)
  • 最後のバイトを受信するまでにかかる時間(TTFB)
  • TLSハンドシェイクレート
  • トランザクションの待ち時間
  • HTTP/HTTPSスループット
  • トラフィックミックススループット

冒頭のニュース記事は、NetSecOpenによる脆弱性に対する攻撃テストにおいて、Sonicwallが好成績を収めたことを紹介する記事でした。
このような情報は製品選定における一つの指標として活用することができます。

「働き方改革のためのテレワーク導入モデル」の概要

働き方改革のためのテレワーク導入モデル

発行年月日:2019年6月
発行者:総務省

https://www.soumu.go.jp/main_content/000616262.pdf

 

 

 

概要と目的

「働き方改革のためのテレワーク導入モデル」は、テレワーク導入のためのノウハウやプラクティスをまとめて公開したものです。当該資料は、テレワーク導入にあたって、自社の「業種」と「企業規模」の軸で企業を分類し、さらにそこから、自社のテレワーク導入の状況と照らし合わせて、テレワーク導入にかかわる課題やその対処法を参考にするものです。

f:id:iestudy:20200514140513p:plain

ガイドラインの読み進め方

 

f:id:iestudy:20200514140647p:plain

テレワーク導入にかかわる課題

 

テレワーク導入にかかわる課題について

 

 

この課題への対策は各社にあったものを考える必要がありますが、 ここでは、IT(タブレット等の導入)による現場業務の効率化や、 テレワークのルール(チーム内での分担等)を紹介しています。

課題 概要 内容
課題A 経営層に対するテレワークのメリットの訴求 経営層に対しては主に、数字(テレワークによる業務効率化の成果)を用いてテレワークによるメリットを提示します。
課題B 「食わず嫌い」な層への対応 まずは部長等管理職からのトライアルで試行していく事例が記載されています。
課題C テレワーク関連ツールの導入コストの捻出 主に無料/低額のサービスを活用した事例を紹介しています。
課題D 時間制約がない従業員に対するテレワークの普及啓発 家庭の事情などで時間の制約がない社員に、まずは会社がテレワークデイを設け、 実際に試してもらう施策について紹介しています。
課題E 現場・接客部門がいだきがちな「不公平感」の払拭 業務の内容によってはテレワークができないものがあります。この課題への対策は各社にあったものを考える必要がありますが、ここでは、IT(タブレット等の導入)による現場業務の効率化や、テレワークのルール(チーム内での分担等)を紹介しています。
課題F 従業員の自律性・主体性・マネジメントスキルの育成 テレワークではオフィスに不在でメンバーの業務が見えないことによる懸念や、 新人等、業務経験が少なく自身の業務を管理しきれないメンバーへの対策が紹介されています。 業務報告やチームでの進捗会議を設けるなどの運用ルールについて紹介されています。
課題G 人工ビジネスにおける「クライアントの壁」の打破 業務委託等で人員を派遣している場合はテレワークの実施に難色を示されるケースがあります。 この課題は現場任せにはせずに、会社として取り組んでいく必要があります。
課題H テレワーク浸透度50%の突破 時間的な制約のない社員にはテレワークが浸透しにくいといった課題があります。 この課題については、社長等のリーダーが率先してテレワークを推進していく事例が紹介されています。

 

 

セキュリティ業務を担う人材のスキル可視化施策について調べてみた

セキュリティ業務を担う人材のスキル可視化ガイドライン

  • 発行者:JNSA
  • 発行年月日:2019年1月18日

https://www.jnsa.org/isepa/images/outputs/JTAG_guideline-%CE%B2_190118.pdf

https://www.jnsa.org/isepa/images/outputs/JTAGreport2019.pdf

 

 

 

 

目的

JNSAでは、経済産業省も公開しているセキュリティ人材の不足という課題に対して、組織が求める人材と、組織に属する人材のスキルのマッチングを行い、適材適所の人員配置や、適切な教育プランを作成等に資する取り組みを行っています。

f:id:iestudy:20200428222525p:plain

JTAGの目指すもの

このガイドラインの特徴としては、以下のものがあります。

  1. セキュリティ人材の広範囲な定義
    セキュリティを専門に扱う人材だけでなく、プラスセキュリティ人材通常業務に加えてセキュリティを考えられる人材にも焦点を当てている
  2. 多視点からのセキュリティ人材スキル判定基準
    業務経験やコンピテンシーなども判断基準として取り入れることでその人材の制度の高い総合実力を把握する

※プラスセキュリティ人材とは
事業部門でITを利活用しながらセキュリティ確保も担当するセキュリティ人材のこと

 

JTAGの評価基準

スキル評価基準は以下の項目があります。

A:テクニカルスキル
B:各種資格
C:研修・講義等受講履歴(v2.0 にて組入れ予定)
D:タスク/業務実力(業務経験)
E:コンピテンシー・ヒューマンスキル/コンセプチュアルスキル
F:人(セキュリティに携わる上での、基本的な「人」としての信頼度)

 

JTAGが参照しているフレームワーク

JTAGではIT人材(上述のプラスセキュリティ人材を含む)のスキルを適切に把握するために様々なフレームワークを参照しています。

参照対象 指標/知識体系 概要
ITスキル項目 iCD

iCD(i コンピテンシディクショナリ)は、
IPAが企業において求められる業務と、必要なIT人材の能力をディクショナリ(辞書)として網羅したものです。

i コンピテンシ ディクショナリ概要:IPA 独立行政法人 情報処理推進機構

情報セキュリティ知識項目 SecBok

SecBoK(情報セキュリティ知識項目)は、JNSAがセキュリティ人材育成の参考資料とし公開しているものです。

セキュリティ知識分野(SecBoK2019)

IT/コーポレートガバナンス COBIT

COBITとは - 家studyをつづって

スキルレベル ITSS

ITスキル標準は、ITサービスの提供に必要とされる能力を明確化・体系化した指標です。 

資格レベル ISV Map ISV MapはITSSのキャリアフレームワークと認定資格のマップです。
能力成熟度モデル CMMI

CMMとIDEAL - 家studyをつづって

 

 

 

セキュリティに関連する法律一覧

セキュリティで関連してくる法律についてまとめてみました。

 

 

 

不正アクセス禁止法

「不正アクセス禁止法」は、正式名称「不正アクセス行為の禁止等に関する法律」であり、2000年に施行されたインターネット上での不正なアクセスに関する法律のことです。

不正アクセスの定義は以下のようになっており、主になりすまし脆弱性をついた攻撃が含まれます。

4 この法律において「不正アクセス行為」とは、次の各号のいずれかに該当する行為をいう。
一 アクセス制御機能を有する特定電子計算機に電気通信回線を通じて当該アクセス制御機能に係る他人の識別符号を入力して当該特定電子計算機を作動させ、
当該アクセス制御機能により制限されている特定利用をし得る状態にさせる行為
(当該アクセス制御機能を付加したアクセス管理者がするもの及び当該アクセス管理者又は当該識別符号に係る利用権者の承諾を得てするものを除く。)
二 アクセス制御機能を有する特定電子計算機に電気通信回線を通じて当該アクセス制御機能による特定利用の制限を免れることができる情報(識別符号であるものを除く。)
又は指令を入力して当該特定電子計算機を作動させ、その制限されている特定利用をし得る状態にさせる行為
(当該アクセス制御機能を付加したアクセス管理者がするもの及び当該アクセス管理者の承諾を得てするものを除く。次号において同じ。)
三 電気通信回線を介して接続された他の特定電子計算機が有するアクセス制御機能によりその特定利用を制限されている特定電子計算機に電気通信回線を通じて
その制限を免れることができる情報又は指令を入力して当該特定電子計算機を作動させ、その制限されている特定利用をし得る状態にさせる行為
(不正アクセス行為の禁止)

elaws.e-gov.go.jp

 

また、各都道府県ではサイバー犯罪相談窓口が設けられています。個人で利用しているWebサービスにおいても何らかの不正アクセスによる違法行為が疑われる場合には、管轄の警察本部に設置されているサイバー犯罪相談窓口に相談することができます。

www.npa.go.jp

 

個人情報保護法

個人情報の保護に関する基本法です。

www.iestudy.work

 

マイナンバー法

「マイナンバー法」は「行政手続における特定の個人を識別するための番号の利用等に関する法律」で、個人番号の取り扱い(入手・利用・管理)に関して定められた法律です。
マイナンバー法は個人情報保護法の特別法であり、マイナンバー法で定義していない部分については個人情報保護法の規制が適用されます。

elaws.e-gov.go.jp

https://www.dekyo.or.jp/kenkyukai/data/2nd/20150628_doc4.pdf

 

電子署名法

「電子署名法」は「電子署名及び認証業務に関する法律」で、電子文書に施される「電子署名」の定義および効果ならびにその認証を行う事業を規律する法律です。

www.cloudsign.jp

 

プロバイダ責任制限法

プロバイダが行う情報の流通によって他人のプライバシーや著作権が侵害された時のプロバイダなどへの責任の制限について規定している

「プロバイダ責任制限法」は「特定電気通信役務提供者の損害賠償責任の制限及び発信者情報の開示に関する法律」といいます。この法律は、ウェブページや電子掲示板などで行われる情報の流通によって権利侵害があった場合において、プロバイダ、サーバの管理者などの損害賠償責任の制限と、発信者情報の開示を請求する権利を定めたものです。
<損害賠償責任の制限>
プロバイダが他人のプライバシーを侵害しているものに対して送信防止措置を技術的に施しており、かつ、プライバシー侵害の発生事実を認識していないとき、プライバシーを侵害されたものからの損害賠償に対する責任を負わない

また、プロバイダが、プライバシー侵害をしているものに送信防止措置を講じたとき際に、プライバシーを侵害しているものからの損害賠償責任を負わない

<発信者情報の開示請求>
プライバシーを侵害されたと考えられるものは、プロバイダに対して情報開示を請求することができる

また、プロバイダがその請求に応じたとしても、プライバシーを侵害しているものからの賠償責任を負わない

※プロバイダの責任制限に関する考え方は、アメリカのDMCAが根本にあります。

www.iestudy.work

https://www.mext.go.jp/b_menu/shingi/bunka/gijiroku/012/020802f.pdf 

 

 

電気通信事業法

通信事業の自由競争化に向けて、1985年、新たに施行された事業法です。2019年10月1日から「電気通信事業法の一部を改正する法律」が施行されました。

  • 通信料金と端末代金の完全分離
  • 行き過ぎた顧客の囲い込みの是正
  • 販売代理店の届出制度の導入
  • 事業者や販売代理店による勧誘の適正化

 

電波法

電波を利用する利用者に対する法律です。

無線LANの5GHz帯は、これまで屋外利用できるのはW56のみでしたが、W52が条件付きで利用可能になりました。

elaws.e-gov.go.jp

www.tele.soumu.go.jp

 

通信傍受法

通信傍受法は、「警察は、犯罪捜査を目的として電話を盗聴できる」ことを定めた法律です。犯罪者が電話で連絡を取り合っているような場合、警察が電話を盗み聞きして逮捕のための情報にすることができます。対象になる犯罪は、

  • 組織的犯罪
  • 集団密航
  • 薬物犯罪
  • 銃器犯罪

の4つとなります。 

 

elaws.e-gov.go.jp

 

電子帳簿保存法

電子帳簿保存法とは、会計帳簿やその根拠となる証憑類を、紙ではなく電子データとして保法することを認めた法律です。個人事業主等は、事業に関する書類や帳簿を備え付け、取引を記録し、保存する義務がありますが、帳簿書類の記入や保存は手間や、書類を保管するスペースの確保が必要になります。
上記の課題に対して法人や個人事業の帳簿書類を電子的な媒体に保存することを可能にしたのが、電子帳簿保存法です。

 

特定電子メール法

「特定電子メール法」は迷惑メールの送信を規制する法律です。
Eメールによる一方的な広告宣伝(迷惑メール)に対する規制です。原則としてあらかじめ同意した者に対してのみ送信が認められる「オプトイン規制」が導入されています。

www.dekyo.or.jp

 

サイバーセキュリティ基本法

セキュリティに関して日本の基本方針を示したものが、「サイバーセキュリティ基本法」です。

この法律が定められた背景として、セキュリティのインシデントが増加しており、セキュリティに係る国家戦略を策定・推進や体制整備が急務となっていました。
「サイバーセキュリティ基本法」は、それらの機能強化や体制整備に法的根拠を持たせるもので、サイバーセキュリティは国の責務と定義し、国、自治体、重要社会基盤事業者、サイバー関連事業者等が連携して対応する方針が示されています。

 

 

 

 

コンピュータセキュリティインシデント対応ガイド(NIST SP800 61)の概要

コンピュータセキュリティインシデント対応ガイド(NIST SP800 61)を読んでみました。ガイドラインの概要をまとめます。

コンピュータセキュリティインシデント対応ガイド(NIST SP800 61)
https://www.ipa.go.jp/files/000025341.pdf

 

 

 

概要

このガイドラインは、組織がセキュリティインシデント対応機能を確立し、インシデントへの対応をを効率的に進められることを目的としたものです。
セキュリティインシデント対応として、大きく以下の項目について解説されています。

  • コンピュータセキュリティインシデント対応能力の組織化
  • 事件処理(初期の準備フェーズから、事件後に教訓を生かすフェーズまで)

 

f:id:iestudy:20200316225615p:plain

インシデント対応ライフサイクル

 

インシデント対応フローのステップごとの内容

項目 概要
準備
事件処理に備える

インシデントに対応する際に必要なツールやリソースが解説されています。
インシデント発生時に連絡するための連絡先のリストであったり、インシデント発生時に現地で対応するためのツール(ノートPC等)がまとめられています。

事件の予防 セキュリティコントロールとして、パッチ管理、ホストのセキュリティ(堅牢性)、ネットワークセキュリティ、悪意のコードの予防、ユーザの意識向上とトレーニングについて解説しています。
検知と分析
事件の分類 インシデントの分類として主だったものを挙げています。
(インシデントを網羅したものではない)
  • サービス不能
  • 悪意のコード
  • 不正アクセス
  • 不適切な使用
  • 複合要素
事件の兆候 インシデントの兆候の例が示されています。
  • FTPサーバに対しバッファーオーバーフロー攻撃が仕掛けられたことを検知したネットワーク侵入検知センサーが、警報を発する。
  • ホストがワームに感染したことを検知したウイルス対策ソフトウェアが、警報を発する。
  • ウェブサーバがクラッシュする。
  • インターネット上のホストへのアクセスが遅いという、ユーザからの苦情を受ける。
  • システム管理者が、異常な文字が使われたファイル名を発見する。
  • ユーザがヘルプデスクを呼び出し、脅迫的な電子メールメッセージがあったことを報告する。
  • ホストのログに、監査設定の変更が記録される。
  • アプリケーションが、見慣れないリモートシステムからの、複数回のログインの試みの失敗をログに記録する。
  • 電子メール管理者が、怪しい内容の大量のバウンスメールを見つける。
  • ネットワーク管理者が、典型的なトラフィックフローからの異常な逸脱に気づく。
  • ウェブサーバが、ウェブ脆弱性スキャナの使用を示すエントリーをログに記録する。
  • 組織のメールサーバの脆弱性をターゲットにした、新しいエクスプロイトの告知。
  • 政治的ハッカーグループが、組織を攻撃するという声明を出して脅迫する。
前兆と兆候のソース インシデントの兆候を表す情報のソースとして、以下のものがあげられます。
  • コンピュータセキュリティソフトウェアの警報
  • ログ
  • 公に入手できる情報
事件の分析 インシデントの兆候から、実際に問題があるか分析します。 ここでは分析の推奨事項がまとめられています。
  • ネットワークとシステムのプロファイル
  • 正常動作の理解
  • 一元化されたログ取得とログ保管ポリシーの作成
  • イベント相関処理の実施
  • すべてのホストの時刻を同期させておく
  • 情報の知識ベースの維持と利用
  • インターネットのサーチエンジンを使った調査
  • パケットスニッファを使った補足データの収集
  • データのフィルタリングの検討
  • 経験を最優先する
  • 経験が少ないスタッフのための診断マトリックスの作成
  • 他からの支援を求める
事件の文書化 インシデントの記録に関しての指針が示されています。
記録には、以下のものを記載する。
  • 事件の現在の状態
  • 事件の概要
  • この事件に対して、事件処理担当者がとった行動の内容
  • ほかの関連者(システム所有者、システム管理者など)の連絡先情報
  • 事件調査の際収集した証拠の一覧
  • 事件処理担当者からのコメント
  • 次にとるべきステップ(たとえば、システム管理者によるアプリケーションへのパッチの適用を待つなど)
事件の優先順位付け インシデント対応の優先順位付けは、「事件による、現在および将来起こりうる技術的な影響」及び「影響を受けたリソースの重要度」により判断することを示している。
事件の通知 インシデントを分析して優先順位した後、インシデント対応チームは組織内の適切な人間や、場合によっては他の組織に通知する必要がある。 一般に以下の関係者への通知が必要である。
  • CIO
  • 情報セキュリティ部門長
  • 各地区の情報セキュリティ担当
  • 組織内のほかのインシデント対応チーム
  • システムオーナー
  • 人事部門(電子メールによる嫌がらせなど、職員が関係する場合)
  • 広報部(公共性がある事件の場合)
  • 法務部(法的問題が想定される事件の場合)
  • US-CERT (連邦政府機関または連邦政府機関の業務を代行するシステムは、報告が義務付けられている)
封じ込め、根絶、復旧
封じ込め戦略の選択 封じ込めの戦略の基準を明確に文書化しておくことが示されています。 適切な戦略を決定するための基準として、以下のものが挙げられています。
  • リソースに対する潜在的な損害およびリソースの盗難の可能性
  • 証拠保全の必要性
  • サービスの可用性(ネットワーク接続、外部関係者へのサービス提供)
  • 戦略を実施するのに必要な時間とリソース
  • 戦略の有効性(事件の部分的な封じ込めや、完全な封じ込めなど)
  • 対策の期間(たとえば、4時間以内に中止する緊急回避策、2週間以内に中止する一時回避策、恒久策など)
証拠の収集と処理 証拠保全に関する指針がまとめられている。
  • 識別情報(たとえば場所、シリアル番号、型番号、ホスト名、MAC (Media Access Control)アドレス、コンピュータのIPアドレスなど)
  • 調査中に証拠を収集・処理した者の名前、役職、電話番号
  • 証拠処理の日付と時刻(タイムゾーンを含む)
  • 証拠の保管場所
アタッカーの特定 インシデント対応チームは、あくまで封じ込め、根絶、復旧に重点を置くべきである、アタッカーの特定は時間がかかる割には効果がないプロセスであるとしながらも、 アタッカーを特定するために最も一般的に行われる活動について説明されています。
  • アタッカーのIPアドレスの確認
  • アタッカーのシステムをスキャン←個人的には疑問視
  • サーチエンジンを使ったアタッカーの調査
  • 事件データベースの利用
  • 可能性のあるアタッカーの通信チャネルの監視
根絶と復旧 インシデントの事後対応が行われることを示している。 詳細な内容は対象外としている。
事件後の対応
教訓 インシデントの振り返りについて記載されている。
収集された事件データの利用 インシデント対応の履歴を蓄積し分析することで改善を促すことを示している
証拠の保管 証拠保管のポリシー確立について記載されている。

 

 

 

CISベンチマークについて

自分の勉強のために、CISが公開している資料を読んでみました。

www.cisecurity.org

 

 

 

CISとは

CIS(Center for Internet Security)は、セキュリティ推進のためのアメリカの非営利団体で、セキュリティの基準等を公開しています。

www.jiten.com

 

CISにはCIS WorkBenchというコミュニティがあり、そこでCISベンチマークを含むツールが作成されています。
CISの作成しているツールには以下のものがあります。

  • CIS Contorols:セキュリティ全体のガイドライン
    CIS Controlsは、米国国家安全保障局(NSA)等の米国の公的機関や情報セキュリティ専門企業等が共同で研究し、米国のセキュリティ専門団体であるSANS Instituteが取りまとめたCSC(Critical Security Controls)をルーツとしており、NIST Cyber Security FrameworkやISMS(ISO/IEC27001、27002)とならんでグローバルで普及しているフレームワークです。
  • CIS Benchmark:各機器におけるベストプラクティスです。(本記事の対象)

CISベンチマークとは

CISでは、AWSのセキュリティ設定のガイドとして、ベンチマークを公開しています。
このベンチマークでは、チェック項目を確認することで、定量的な評価が可能となります。

各項目には以下の分類があります。Level1でかつSocredなものは設定が推奨と考えることができます。

Level

  • Level1: 設定必須
  • Level2: 環境によっては設定が必要なもの

Score

  • Scored: 減点対象項目
  • Unscored: 減点対象項目ではないが設定が推奨

 

ベンチマークの概要

1.Identity and Access Management
Level 1 1.1 Avoid the use of the "root" account (Scored) rootアカウントは使用しない
Level 1 1.2 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password (Scored) IAMユーザすべてにMFAを有効化している
Level 1 1.3 Ensure credentials unused for 90 days or greater are disabled (Scored) 90日以上利用の無いアカウントは無効化されるように設定している
Level 1 1.4 Ensure access keys are rotated every 90 days or less (Scored) 90日以内にアクセスキーがローテーションされるように設定している
Level 1 1.5 Ensure IAM password policy requires at least one uppercase letter (Scored) IAMパスワードは英大文字を含む
Level 1 1.6 Ensure IAM password policy require at least one lowercase letter (Scored) IAMパスワードは英小文字を含む
Level 1 1.7 Ensure IAM password policy require at least one symbol (Scored) IAMパスワードは記号を含む
Level 1 1.8 Ensure IAM password policy require at least one number (Scored) IAMパスワードは数字を含む
Level 1 1.9 Ensure IAM password policy requires minimum length of 14 or greater (Scored) IAMパスワードは14文字長以上
Level 1 1.10 Ensure IAM password policy prevents password reuse (Scored) IAMパスワードは過去のパスワードの再利用を禁止
Level 1 1.11 Ensure IAM password policy expires passwords within 90 days or less (Scored) IAMパスワードはパスワードの有効期限が90日以内
Level 1 1.12 Ensure no root account access key exists (Scored) rootアカウントのアクセスキーを削除している
Level 1 1.13 Ensure MFA is enabled for the "root" account (Scored) rootアカウントはMFA認証によって保護している
Level 2 1.14 Ensure hardware MFA is enabled for the "root" account (Scored) rootアカウントのMFA保護は、ハードウェアのセキュリティキーを使用する
Level 1 1.15 Ensure security questions are registered in the AWS account (Not Scored) セキュリティ質問がAWSアカウントに設定されている
Level 1 1.16 Ensure IAM policies are attached only to groups or roles (Scored) IAMポリシーは、グループやロールにのみ紐づいている
Level 1 1.17 Maintain current contact details (Not Scored) コンタクト詳細が常に更新されている
Level 1 1.18 Ensure security contact information is registered (Not Scored) セキュリティコンタクト情報が登録されている
Level 2 1.19 Ensure IAM instance roles are used for AWS resource access from instances (Not Scored) インスタンスからのAWSリソースアクセスには、IAMインスタンスロールが利用されている
Level 1 1.20 Ensure a support role has been created to manage incidents with AWS Support (Scored) AWSサポートでインシデントを管理するためのサポートロールが作成されている
Level 1 1.21 Do not setup access keys during initial user setup for all IAM users that have a console password (Not Scored) コンソールパスワードを持つIAM ユーザについては、セットアップ時にアクセスキーを作成しない
Level 1 1.22 Ensure IAM policies that allow full "*:*" administrative privileges are not created (Scored) フル特権(*.*) を持つIAMポリシーを作成しない
2.Logging
Level 1 2.1 Ensure CloudTrail is enabled in all regions (Scored) 全リージョンで、CloudTrailが有効
Level 2 2.2 Ensure CloudTrail log file validation is enabled (Scored) CloudTrail ログバリデーションが有効である
Level 1 2.3 Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible (Scored) CloudTrail ログを保管する S3 Bucket のパブリックアクセスは無効化されている
Level 1 2.4 Ensure CloudTrail trails are integrated with CloudWatch Logs (Scored) CloudTrail 記録は、CloudWatch Logsに連携されている
Level 1 2.5 Ensure AWS Config is enabled in all regions (Scored) 全リージョンで、AWS Configが有効である
Level 1 2.6 Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket (Scored) CloudTrailログを保管するS3 Bucketにおいては、アクセスログが有効化されている
Level 2 2.7 Ensure CloudTrail logs are encrypted at rest using KMS CMKs (Scored) CloudTrailログは、KMS CMKを用いて暗号化されている
Level 2 2.8 Ensure rotation for customer created CMKs is enabled (Scored) ユーザ作成CMKのローテーションが設定されている
Level 2 2.9 Ensure VPC flow logging is enabled in all VPCs (Scored) 全VPCで、フローログが取得できる
3.Monitoring
Level 1 3.1 Ensure a log metric filter and alarm exist for unauthorized API calls (Scored) 不正なAPIコールに関するログメトリックフィルタおよびアラームが定義されている
Level 1 3.2 Ensure a log metric filter and alarm exist for Management Console sign-in without MFA (Scored) MFA認証を用いないコンソールログインに関する ログメトリックフィルタおよびアラームが定義されている
Level 1 3.3 Ensure a log metric filter and alarm exist for usage of "root" account (Scored) root利用に対するログメトリックフィルタおよびアラームが定義されている
Level 1 3.4 Ensure a log metric filter and alarm exist for IAM policy changes (Scored) IAMポリシーの変更処理に関するログメトリックフィルタおよびアラームが定義されている
Level 1 3.5 Ensure a log metric filter and alarm exist for CloudTrail configuration changes (Scored) CloudTrail の構成変更に関するログメトリックフィルタおよびアラームが定義されている
Level 2 3.6 Ensure a log metric filter and alarm exist for AWS Management Console authentication failures (Scored) AWSマネジメントコンソール認証の失敗に関するログメトリックフィルタおよびアラームが定義されている
Level 2 3.7 Ensure a log metric filter and alarm exist for disabling or scheduled deletion of customer created CMKs (Scored) ユーザ作成CMKについて、スケジュールされた削除処理および無効化に関するログメトリックフィルタおよびアラームが定義されている
Level 1 3.8 Ensure a log metric filter and alarm exist for S3 bucket policy changes (Scored) S3 bucketポリシー変更に関するログメトリックフィルタおよびアラームが定義されている
Level 2 3.9 Ensure a log metric filter and alarm exist for AWS Config configuration changes (Scored) AWS Configサービスの構成変更に関するログメトリックフィルタおよびアラームが定義されている
Level 2 3.10 Ensure a log metric filter and alarm exist for security group changes (Scored) セキュリティグループの設定変更に関するログメトリックフィルタおよびアラームが定義されている
Level 2 3.11 Ensure a log metric filter and alarm exist for changes to Network Access Control Lists (NACL) (Scored) NACLの設定変更に関するログメトリックフィルタおよびアラームが定義されている
Level 1 3.12 Ensure a log metric filter and alarm exist for changes to network gateways (Scored) ネットワークゲートウェイについての変更に関するログメトリックフィルタおよびアラームが定義されている
Level 1 3.13 Ensure a log metric filter and alarm exist for route table changes (Scored) ルートテーブルの変更に関するログメトリックフィルタおよびアラームが定義されている
Level 1 3.14 Ensure a log metric filter and alarm exist for VPC changes (Scored) VPCの設定変更に関するログメトリックフィルタおよびアラームが定義されている
4.Networking
Level 1 4.1 Ensure no security groups allow ingress from 0.0.0.0/0 to port 22 (Scored) 全セキュリティグループにおいて、port 22(ssh)を不特定多数(0.0.0.0/0)に公開していない
Level 1 4.2 Ensure no security groups allow ingress from 0.0.0.0/0 to port 3389 (Scored) 全セキュリティグループにおいて、port 3389(ssh)を不特定多数(0.0.0.0/0)に公開していない
Level 2 4.3 Ensure the default security group of every VPC restricts all traffic (Scored) 全てのVPCの、defaultセキュリティグループは、全ての通信を拒否する設定となっている
Level 2 4.4 Ensure routing tables for VPC peering are "least access" (Not Scored) VPCピアリングのルーティングテーブルは、必要最小限のものにしている

 

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

貴重な情報をありがとうございます。

jpn.nec.com

docs.microsoft.com