[レポート] Zocdocはどうやって脅威の検知・セキュリティの修復を自動化したか #reinvent

本記事はre:Invent 2018のセッション「How Zocdoc Achieves Automatic Threat Detection & Remediation with Security as Code」の参加レポートです。
2018.11.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

福岡のyoshihitohです。re:Invent 2018のセッション「How Zocdoc Achieves Automatic Threat Detection & Remediation with Security as Code」についてレポートします。

セッション情報

セッション名

How Zocdoc Achieves Automatic Threat Detection & Remediation with Security as Code

スピーカー

  • Danielle Ruderman - Manager, Security Information Experience
  • Brian Lozada - CISO, Zocdoc
  • Jay Ball - Head of Application Security, Zocdoc

概要

原文の引用です。

In less than 12 months, Zocdoc - an online healthcare scheduling service that receives more than 6 million patient visits a month - became a cloud-first organization to meet their business goals. This digital transformation allowed for rapid innovation and the ability to deliver products that align with demands of the 21st-century patient. In this session, Brian Lozada, CISO at Zocdoc, and Jay Ball, Head of Application Security, explain how Zocdoc uses AWS security services to seamlessly and automatically monitor, audit, and enforce their security policies within all their AWS environments. They use AWS security services, such as AWS Config, Amazon GuardDuty, Amazon Inspector, and AWS Shield, while using AWS Lambda functions to augment their security team, all without slowing down their developers.

以下、意訳です。

  • Zocdocはオンラインのヘルスケア予約サービスで、1ヶ月あたり600万人以上の患者が訪問している
  • Zocdocは12ヶ月以内にクラウドファーストな組織となることを彼らのビジネスのゴールとしている
  • このデジタル化によって21世紀に適した急速な革新・製品の配信を患者に提供する
  • このセッションではZocdocでどのようにAWSのサービスを自動化・監視・監査・セキュリティポリシーの適用しているか、CISOのBrian Lozada氏とアプリケーションセキュリティまとめ役のJay Ball氏が説明する

以降がセッション内容です。

Zocdocはどうやって脅威の検知・セキュリティの修復を自動化したか

交通の問題を解決する

地域によって待ち時間にムラがある

待ち時間を減らす

21世紀の患者に適したケアを提供する

Zocdocの目指すところ

  • 水平にスケールする
  • 技術スタックを多様化させる
  • オープンソース
  • データの開放
  • セキュリティの向上

クラウドインフラを保護する

達成したもの

  • AICPA
  • SOC
  • HITRUST

セキュリティの制御

  • 監視
  • アラート
  • 調査
  • 予防/ブロック

セキュリティを支えるAWSのサービス

  • AWS GuardDuty
  • AWS Trusted Advisor
  • AWS WAF/Shield
  • AWS Lambda
  • AWS CloudTrail
  • Amazon Inspector
  • Amazon CloudWatch

現在のAWSの自動化

ケース1: 暗号化されていないS3バケットの対処

  • 問題点: どうやってS3バケットが常に暗号化されることを保証する?
  • 解決策: 暗号化が無効なことを検知したら自動で暗号化する

シナリオ

  • 作成方法の種類
    • CLI経由でバケットを作成
    • マネジメントコンソールから作成
    • APIでバケットを作成
  • マネジメントコンソールから作成するときに、暗号化の指定を忘れてしまった

修復方法

  1. AWS CloudTrailでS3バケットの操作ログを記録
  2. Amazon CloudWatchでS3の操作を検知する
  3. S3の操作をトリガーにLambda Functionを起動する
  4. S3バケットが暗号化されていない場合は暗号化する

補足: 実際のスライドには 「Lambda Function」から「S3 Bucket」に向かって「Encrypts」の線が出ています。撮影タイミングの問題で欠如しました。

ケース2: EC2上の疑わしい動作

  • 問題点: マルウェアの感染を検知した
  • 解決策: EC2インスタンスを破棄する

修復方法

  1. EC2から疑わしいホスト名への通信が発生する
  2. AWS GuardDutyが疑わしいホストへの通信を検知する
  3. Amazon CloudWatchに通知する
  4. 疑わしいホスト名への通信をトリガーにLambda Functionを起動する
  5. EC2インスタンスを破棄する

破棄した後の措置

  • CloudWatchとCloudTrailのログを分析
  • EC2インスタンスにアタッチしていたストレージを分析する
  • CloudFormationを使ってEC2インスタンスを自動で再構築する

ケース3: センシティブなポートの開放問題

  • 問題点: 誰かがセンシティブなポートをインターネット全体に向けて開放した
  • 解決策: センシティブなポートの開放を検知したら、その開放ルールを削除する

修復方法

  1. AWS CloudTrailでSecurityGroupへの変更を記録
  2. 許可されていないCIDRのルールを検知したらAmazon CloudWatchに通知
  3. Lambda Functionを起動する
  4. 許可されていないCIDRのルールをSecurityGroupから削除する

ケース4: WAF(Web Application Firewall)とDDoS

  • 問題点: WAFの費用がとても高くなる
  • 解決策: AWS WAFとAWS Shieldの保護を活用する

伝統的なWAFの非効率性

  1. サイト/ALBごとに個別の設定が必要
  2. サイトごとの設定管理が必要
  3. それぞれの設定を共有できない
  4. IPレピュテーションリストに対応していない

AWS WAFを活用したセキュリティの自動化

AWS WAFを活用したセキュリティの自動化 (変更点)

  • 追加: 国単位のブロック
  • 追加: URIとパラメタに応じたホワイトリスト
  • 追加: 古いエンドポイントのブラックリスト
  • 更新: IPレピュテーションリストの処理方式
  • 削除: Bad bot honey pot

2つのWAFを組み合わせる

ZocDocには2種類のシステムが存在する - それぞれ固有のAWS WAFルール(WebACL)がある - それぞれ複数のALBをさしている

WAFの設定

設定

比較

どのセキュリティを自動化したか

  • 悪意のあるIPブロックリストを1時間毎に更新
  • Flood対策でレートの高いIPから保護
  • 調査中のIPブロックリストを定期的に更新
  • 悪意のあるBOTのIPブロックリストはトリガー契機で即座に更新する

ケース5: 脆弱性の自動評価

  • 問題点: 脆弱性!
  • 解決策: Amazon Inspectorで脆弱性を可視化し、業界標準のコンプライアンス要求を満たす

基本的な要求

Zocdocのコンプライアンス測定

調査結果をレビューし、パッチリクエストをチームに提出する

症状・コンプライアンスの要求に応じて優先度を設定する - SOC 2 Type II: ほとんどのプロセス - PHI/HIPPA: ほとんどのポリシー - CIS (Center for Internet Security): 進化し続けるセキュリティ強化のためのチェックリスト

将来的にどうなる?

  1. EC2インスタンス上でエージェントを起動する
  2. Amazon Inspectorが検証する
  3. 自動で脆弱性を見つけて処理する
  4. AWS System ManagerでAMIにパッチをあてる
  5. コンプライアンスに準拠していないシステムを破棄する
  6. 手順5で破棄したシステムを再デプロイする

今後の展望

まだまだやるべきことはあるが、少しずつでも始めることができる

  • OSレベルのパッチは一般的にアプリケーションレベルのパッチよりも効果が高い

商用のソリューションもこの考えをもとにしている

  • 完全なものは存在しないが、いずれも価値ある機能を提供している
  • Amazonは我々に必要な部品を与えてくれる、どんどん使っていこう

まずはCIS準拠から始めよう

セキュリティの将来

  • 非効率な手作業を減らして、自動化によせていく
  • アラートを減らす、代わりに自動で修復する
  • ビジネスを継続できるようにする

コードに興味がある?

GitHubで公開してる!

おわりに

セキュリティの監視・アラートに加えて、自動で修復するところまで実運用でまわりしてる事例が聞けて非常に勉強になりました!また、ケースごとのBrian氏とJay氏の掛け合いがいちいちおもしろかったですw

アラートは非常に便利なんですが深夜対応はできるだけ避けたいですよね。安全に自動修復できるところはその場で対応して詳細は後日対応する、というのはビジネス継続的な面でも運用者の負担の面でもとても価値の高い仕組みだと思います。ぜひ試していきたいですね!