ここから始めるAWSセキュリティ〜リスク可視化と分析による継続的セキュリティの実現〜

リスク可視化と分析による継続的セキュリティの実践
登壇者：桐山隼人さん

セッションの目的

AWS環境におけるセキュリティ対策を
「まず、何から始めたらいいの？どこまでやったらいいの？」から脱出する。

継続的セキュリティ Continuous security(CS)

Continuous security (CS) is itself a distinct pillar with standalone best practices that cross all of the other pillars.

All information security platforms that are in use expose full functionality via APIs.

Immutable infrastructure mindsets are adopted to ensure production systems are locked down.
Security controls are automated so as not to impede DevOps agility.
Security tools are integrated into the CI/CD pipeline.
Source code for key intellectual property on build or test machines are only accessible by trusted users with credentials. Build and test scripts do not contain credentials to any system that has intellectual property.
External penetration tests (done out of band) are scheduled either periodically or on a regular cadence are used to perform deep-dive analysis.
Telemetry from production security controls such as WAF and RASP are delivered back to development teams to inform application updates.
Accurate inventory of all software packages and version information is documented via infrastructure as code. Automated detection is used to identify whether any of the packages have known CVEs associated and define specific remediation actions.

https://devops.com/9-pillars-of-continuous-security-best-practices/ より

継続的セキュリティをやる意義

環境変化適応
- セキュリティ対策は実施した瞬間から危殆化する
- 実施した瞬間から、少しずつ時代遅れになってくる
スピード
- セキュリティ侵害は攻撃側の方が早い
- 攻撃側は金銭などにモチベーションが高いので手法を取り込んでくる
コスト最適化
- リスクベースのアプローチで考える
- セキュリティ障害は経営の脅威になる
- 予算をどの程度つけるかは決裁者次第。予算を検討すると青天井になる。一方で何も起きなければ、「無駄」に思われてしまう。
- リスクが高いものほど、お金をかけていく。

セキュリティリスクの方程式

リスク = 脅威 x 脆弱性 x 情報資産

脅威
- 手法
  - 標的型攻撃
  - マルウェ
  - サイバー攻撃
- 対策
  - 異常検知
  - 脅威インテリジェンス
- AWSのソリューション
  - Amazon GuardDuty
脆弱性
- 要因
  - セキュリティホール
  - 設定ミス
  - 心理的要素
- 対策
  - 脆弱性診断
  - ベンチマーク評価
- AWSのソリューション
  - Amazon Inspector
情報資産
- 対象
  - 機密情報
  - 個人情報
  - 知的財産
- 対策
  - ユーザ振る舞い分析
  - 情報漏洩防止
- AWSのソリューション
  - Amazon Macie
- 保護対象の特徴
  - 変更が可能なもと不可能なもがある。
    - 指紋や虹彩などの生体情報は変更不可能
    - クレジットカード番号は変更可能
  - 変更不可能な情報資産はupdateできない前提で考えなければならない。

AWSのソリューション

Amazon GuradDuty 継続的監視と脅威検知

機械学習を利用したクラウドネイティブな脅威検知
脅威の種類
- 悪意のあるポートスキャン
- 総当たり攻撃
インスタンスへの脅威
- Command&Controlサーバとの通信
- EC2インスタンスに侵入されてしまい、第3者の攻撃に利用されている
入力ソース
- VPC Flow Logs(VPC内の通信元/先)
- DNS Logs(DNSサーバへの問い合わせ)
- CloudTrail

Amazon Inspector - プラットフォーム脆弱性分析

EC2にエージェントをインストールして、インスタンスの脆弱性を診断する。
CVEやCISベンチマークに基づいたリスク評価
エクゼクティブサマリー含めた評価レポート
Amazon Inspectorのルールパッケージ
- ホスト評価のルール
  - CVEに基づく一般的な脆弱性
  - CIS Operating System Security
- ネットワーク到達性
  - 自分で意図したネットワーク設計になっているのか。
- PCI DSS
  - インターネットに接してるかでセキュリティ対策の評価が変わってくる。
- 自動推論にる評価
  - 「設定内容」と「ネットワークの設定内容のスナップショット」で評価する
  - 実際にパケットを飛ばしている訳ではない。設定から推定する

Amazon Macie - 事業価値のあるデータを保護

継続的監視によるデータ漏洩のリスクを評価する
現在(2019年5月23日)は北バージニアとオレゴンのみ

Amazon Security Hub

現在(2019年5月23日)はプレビュー版
上の3つを一元的ににアクセスできるダッシュボードを提供する。

まずはここから

全リージョンで GuardDutyを有効化
InspecorでEC2インスタンスを評価
Macie で S3にある重要データの棚卸し
Security Hub で可視化
AWS Configで全リソースの設定変更記録を開始
Securty Hub で Compliance Standardsを有効化する
セキュリティ管理アカウントで組織全体を監視する
Securitie HubのカスタムアクションでFindingsの追加

リスクベースアプローチで優先順付け

現時点のリスクの偏在を監視
ベースラインアプローチ
- 企業のルール / 業界のルールからの逸脱を評価する
- AWS Config で管理する。 Security Hubからアクセスできる
AWS Config
- 元々はAWSリソースの構成管理/変更記録のサービス
- ルールから逸脱した時に、過去の履歴がないと、「いつから」の問いに答えられない
- 逸脱した時に検知したことを通知してほしい

ガバナンス

監視と評価に基づく意思決定と指示
- AWS organizations を使う
最初のAWSアカウントは１つだけど、事業ごとに、サービスごとにアカウントが増えていく。それらを管理しなければならない。
- Landing Zone で管理する
マルチアカウント戦略
- 目的が違うアカウントは分ける。目的を分ける方が新技術を投入しやすい
- アカウントの種類
  - マスターアカウント
    - 支払い
  - 共有サービスアカウント
    - 事業に必要なサービスが稼働する
  - ログ管理用アカウント
    - 他のアカウントで出力されたログを集める
    - 何もなければアクセスすることが少ない
  - セキュリティアカウント
  - セキュリティ管理者への通知

ワークショップ

資料
- https://scaling-threat-detection.awssecworkshops.jp
- 大事なこと
  - セキュリティ障害の最大要因
    - 人間こそが間違いを起こすのです。善意の人であっても人間です。騙されてしまうこともあります。同じクレデンシャルを複数の箇所で使用してしまったり、多要素認証のハードウェアトークを利用しないもの人間です。人為的な要因をできる限りデータから隔離する必要がります。
  - データ侵入の検知
    - 情報漏洩が発生する数分前から攻撃を受けている。一方で68%が情報漏洩後に1ヶ月以上経過してから気づく。
補足
- モジュール 1で入力するeメールアドレス
  - Amazon SNSのサブスクリプションに登録され、脅威を検知した時の通知先になる
  - 検証メールが送信されるので、confirm しておく必要がある。
  - 忘れるとモジュール2後に動き出す攻撃を検知した結果を受け取れない。そうすると、モジュール3の前提を満たせない。
- モジュール2のCloudFormationが失敗する
  - リージョン us-west-2d はt2.microをサポートしないので失敗する。
  - 作成するサブネットはランダムに選ばれるので、失敗したらやり直して、別のAZが対象になることを祈る。

東京リージョンと料金

GuradDuty 、Inspector 、Macie、Security Hubのうち、Macie だけ東京リージョンなし

料金 (2019年5月23日時点)

GuradDuty
- VPC フローログと DNS ログ分析
  - 最初の 500 GB/月 -> 1.18 USD/GB
  - 次の 2000 GB/月 -> 0.59 USD/GB
  - 2500 GB/月を超えた場合 -> 0.29 USD/GB
- AWS CloudTrail イベント分析
  - 1,000,000 イベントあたり/月 -> 4.72 USD/1,000,000 イベント
Inspector
- 最初の 250 回のインスタンス評価 -> 0.15 USD/回
- 次の 750 回のインスタンス評価 -> 0.13 USD/回
- 次の 4,000 回のインスタンス評価 -> 0.10 USD/回
- 次の 45,000 回のインスタンス評価 -> 0.07 USD/回
- これ以上のインスタンス評価 -> 0.04 USD/回
Macie
- https://aws.amazon.com/jp/macie/pricing/ を参照
Security Hub
- プレビュー期間中なので追加料金なし

導入したとに気になること

検知した通知が届く頻度