Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20181219 Introduction of Incident Response in AWS for Beginers

380 views

Published on

2018/12/19 に INSIDE MeetUp!! #1 、
2018/12/22 に SECCON 2018 の#ssmjp 枠で飛び入りLTした内容です。

Published in: Technology
  • Be the first to comment

20181219 Introduction of Incident Response in AWS for Beginers

  1. 1. Introduction of Incident Response in AWS for Beginers INSIDE MeetUp!! #1 2018/12/19 SECCON 2018 #ssmjp 2018/12/22 @Typhon666_death
  2. 2. Self-Introduction • @Typhon666_death (テポ) • 仕事:某セキュリティ専門会社にて、 セキュリティエンジニア/コンサルタント/アナリスト/営業してました • 業務:以前は多種企業向けMSSや金融機関向けASP、今は自社AIサービスの運用保守 • 活動コミュニティ: • OWASP Japan Promotion Teamメンバー • Security-JAWS 運営メンバー • X-Tech JAWS 運営メンバー • FinJAWS 運営メンバー • AISECjp 運営メンバー • レトロゲーム勉強会 運営メンバー • 全脳アーキテクチャ若手の会 運営メンバー https://www.slideshare.net/Typhon666_death
  3. 3. AWS Security https://www.slideshare.net/HayatoKiriyama/aws-reinvent-2017-security-recap-key-messages
  4. 4. AWS Security https://www.slideshare.net/HayatoKiriyama/aws-reinvent-2017-security-recap-key-messages
  5. 5. AWS Marketplace [Categories:Security]
  6. 6. 各種AWSのセキュリティサービス は以下のURLから確認 現在17のサービス AWSのマネージドサービスを用い てよりセキュアに 事前対策できるものが多い 事後対策は? Security Services after re:Invent 2018 https://aws.amazon.com/jp/products/security/
  7. 7. Incident Response (IR) インシデントハンドリングフロー インシデントとなるものを発見 トリアージ(優先度を決める) 事象の分析 IRの計画 IRの実施 報告 準備 検知・分析 封じ込め 根絶・復旧 教訓 IR
  8. 8. Importance of Incident Response 万が一、侵害を受けた際の対策フローが出来てない場合にあなたは何します ? https://www.jpcert.or.jp/present/2005/IncidentResponseOverview2005.pdf
  9. 9. 各NW機器、サーバ、アプリ等のログをログ 収集サーバに送る それらのログを相関的に分析し、インシデン トの発生を速やかに検知する必要がある インシデントの早期発見のために利用するの がSIEM(Security Infomation and Event Management) SOC(Security Operation Center)からSIEMを 使って監視を行う FW ログ収集Web WAF DB IPS 認証 DNS メール SIEM SOC端末 Incident Response for on-premises Web Net
  10. 10. マルウェアがWebサイトに混入した場合 WebサーバやDNSサーバやAVソフト等のログから混 入を検知 不正侵入元のIPアドレスやプロトコルの通信の遮断 AVソフトによるマルウェアの検疫や、隔離からのマル ウェア解析、バックアップからのリカバリ 此度の対応に関するレポート作成、顧客への注意喚起 、警察への届け出、対応手順に関するフィードバック 等 FW ログ収集Web WAF DB IPS 認証 DNS メール SIEM SOC端末 Incident Response for on-premises Web Net
  11. 11. But… SIEM機器が高い → ウン千万円する機器を検討するか? SIEMのルール作成大変 → ログのフォーマットごとに相関分析できるルールをつくる必要が ある マンオペ大変 → トリアージの判断誤って被害拡大、解析する時間の猶予 人的リソースがない → 小さい会社でそこまで人さけるのか? クラウドではオンプレとは違った高度なIR、Security Automationの実現が可能 ▷ AWSを例に
  12. 12. Incident Response for Cloud Web Net snapshot CloudWatch Logs AWS CloudTrail IAM AWS WAF SES security group RDS DB instance Route 53 VPC Flow Logs /DNS Logs CloudWatch Event Lambda Amazon GuardDuty 隔離 log bucket instance EBS instance instance EBSEBS Auto Scaling Malicious Instance & EBS log bucket Lambda 保全 該当Security Groupから該当インスタ ンスを削除し、新規インスタンス追加 Outbound Denyの Security Groupにより感 染インスタンスを隔離 GuardDutyのFindings により感染インスタンス が特定 VPC内は普遍的な Web+DBの構成 AWS WAFを利用 ログはS3 Bucketへ GuardDutyの Findingsで感染特定 接続元IPの自動遮断 Lambda 接続元IPの遮断 WAFシグネチャの更新等 フォレンジック
  13. 13. snapshot CloudWatch Logs AWS CloudTrail IAM AWS WAF SES security group RDS DB instance Route 53 VPC Flow Logs /DNS Logs CloudWatch Event Lambda Amazon GuardDuty 隔離 log bucket instance EBS instance instance EBSEBS Auto Scaling Malicious Instance & EBS log bucket Lambda 保全 該当Security Groupから該当インスタ ンスを削除し、新規インスタンス追加 Outbound Denyの Security Groupにより感 染インスタンスを隔離 GuardDutyのFindings により感染インスタンス が特定 CloudWatchEvent を元にLambdaで 感染インスタンス の隔離と新規イン スタンス追加 隔離インスタンス の保全 マルウェアフォレ ンジック 接続元IPの遮断 WAFシグネチャの更新等 Lambda フォレンジック Incident Response for Cloud Web Net
  14. 14. snapshot CloudWatch Logs AWS CloudTrail IAM AWS WAF SES security group RDS DB instance Route 53 VPC Flow Logs /DNS Logs CloudWatch Event Lambda Amazon GuardDuty 隔離 log bucket instance EBS instance instance EBSEBS Auto Scaling Malicious Instance & EBS log bucket Lambda 保全 該当Security Groupから該当インスタ ンスを削除し、新規インスタンス追加 Outbound Denyの Security Groupにより感 染インスタンスを隔離 GuardDutyのFindings により感染インスタンス が特定 CloudWatchEvent を元にLambdaで 感染インスタンス の隔離と新規イン スタンス追加 隔離インスタンス の保全 マルウェアフォレ ンジック 接続元IPの遮断 WAFシグネチャの更新等 Lambda フォレンジック この部分に 適用できそう http://ascii.jp/elem/000/001/549/1549718/ About Unauthorized Access and Forensics for AWS
  15. 15. Log Aggregator Logstash/Beats fluentd Logging Sumologic Graylog Monitoring Datadog NewRelic Splunk Security Tool for Cloud
  16. 16. Forensic as a Service Intezer Security Orchestration Demisto Phantom Security Tool for Cloud
  17. 17. CloudFalcon & FalconNest by LAC https://www.lac.co.jp/news/2018/10/01_press_01.html https://www.lac.co.jp/news/2018/11/08_press_01.html
  18. 18. ZEITA & RAFFLESIA by Recrute Technologies http://www.atmarkit.co.jp/ait/articles/1810/15/news010.html
  19. 19. snapshot CloudWatch Logs AWS CloudTrail IAM AWS WAF SES security group RDS DB instance Route 53 VPC Flow Logs /DNS Logs CloudWatch Event Lambda Amazon GuardDuty 隔離 log bucket instance EBS instance instance EBSEBS Auto Scaling Malicious Instance & EBS log bucket Lambda 保全 該当Security Groupから該当インスタ ンスを削除し、新規インスタンス追加 Outbound Denyの Security Groupにより感 染インスタンスを隔離 GuardDutyのFindings により感染インスタンス が特定 CloudWatchEvent を元にLambdaで 感染インスタンス の隔離と新規イン スタンス追加 隔離インスタンス の保全 マルウェアフォレ ンジック 接続元IPの遮断 WAFシグネチャの更新等 Lambda フォレンジック 内製化してみる? Incident Response for Cloud Web Net
  20. 20. インシデントレスポンスを行うためのコアエンジン コマンドの実行でインシデントレスポンスに必要となるいくつかの操作を行 える アクセスキーの失効 ホストの分離やシャットダウン、スナップショットの取得 フォレンジックキャプチャをs3にホストする等 https://aws-ir.readthedocs.io/en/latest/index.html# AWS-IR
  21. 21. 実行中のLinuxインスタンスからメモリダンプを作成するツール リモートシステムのカーネルバージョン等が確認されている前提で、 適切なLiMEメモリモジュールがロードされ、システムメモリがsshト ンネルを介してインシデントレスポンダのワークステーションにスト リーミングされる。 メモリダンプはディスクにも、s3バケットに直接ストリーミングも可 https://margaritashotgun.readthedocs.io/en/latest/index.html Margarita Shotgun
  22. 22. IIJさんの秀逸な資料 https://www.slideshare.net/IIJ_PR/ss-121246301 Importance of Forensics
  23. 23. オペレーター端末側に以下の環境 Python3.4以上の環境 AWS CLIをインストール AMI用のLiMEメモリモジュールの作成(メモリダンプに必要) $ sudo yum install -y kernel-devel-$(uname -r) $ git clone https://github.com/504ensicsLabs/LiME.git $ cd LiME/src $ make $ cp *.ko ~ ・2018/11/04時点で最新のAmazonLinux2のAMI amzn2-ami-hvm-2.0.20181024-x86_64-gp2 (ami- 013be31976ca2c322) ・Kernel: 4.14.72-73.55.amzn2.x86_64 Preparation
  24. 24. --case-number ケース 番号をつけれる(ログ を保持するのに便利) --bucket-name インシ デントの結果を格納す るために使用される S3バケット名を指定 特に指定しないとこんな感じ のバケットが生成される。 AWS-IR
  25. 25. AWS IRで行う作業内容をPluginで指定。 スナップショットを取る、ホストを停止させる等 AWS-IR
  26. 26. $ aws_ir --case-number 001 --bucket-name secjaws11-ir --examiner-cidr-range 54.205.83.117/32 instance-compromise --target 18.204.197.239 --user ec2- user --ssh-key ~/.ssh/secjaws11.pem --plugins gather_host,isolate_host,snapshotdisks_host,examineracl_host 総じて投げてみたコマンドはこんな感じ。 AWS-IR
  27. 27. 〜中略〜 フォレンジック端末からのみアクセ ス可能なSGに変わる (このログでは54.205.81.117のみ) 自動でSnapshot取得 AWS-IR
  28. 28. key-compromiseでは利用中のアクセ スキーを失効させることが可能。 AWS-IR
  29. 29. $ margaritashotgun --server 18.204.197.239 --module lime-4.14.72- 73.55.amzn2.x86_64.ko --username ec2-user --key ~/.ssh/secjaws11.pem -- filename mymemcap.lime Margarita Shotgun 総じて投げてみたコマンドはこんな感じ。
  30. 30. Margarita Shotgun 準備の段階で作っ たLiMEメモリモジ ュールを指定しな いと、メモリダン プが行えない。 作成されたメモリ ダンプを必要に応 じてフォレンジッ カーに連携
  31. 31. Ask Forensic Experts? Or is it self? https://digital-forensics.sans.org/community/downloads https://tsurugi-linux.org/
  32. 32. ssm_acquire - Released re:Invent 2018 ps://www.slideshare.net/AmazonWebServices/how-to-perform-forensics-on-aws-using-serverless-infrastructure-sec416r1-aws-reinvent-20
  33. 33. Secure DevOps Toolchain https://www.sans.org/security-resources/posters/secure-devops-toolchain-swat-checklist/60/download
  34. 34. Incident Response for Containers/k8s コンテナにしても、Kubernetesにしても、ホストが侵害される可能性は残る コンテナイメージが侵害されている状況も考えられる。 もし、AWS-IRやMargarita Shotgunのようなツールでダンプするならホストに 対して行うのが良いと考える。
  35. 35. Conclusion ログ取得の設定を見直す。 モニタリングする。 インシデントハンドリングフローを確認する。 すべて内製するところ、しないところを企業内で話し合うこと。 自動化できるところは自動化(自動化が働かなかったとき手動で出来ること) 運用設計大事
  36. 36. Q&A
  37. 37. Q&A 0x01 Q:AWS初心者からしてまずセキュリティをやっていくには何を気をつけたらいい か? Trusted Advisorを見ましょう。 S3でオープンにしすぎないようにしましょう。 S3やGithubにpemとか置かないでください。 あと、Classmethodのブログを見ましょう。
  38. 38. Q&A 0x01 musudakeisuke/awssekiyuriteishi-shi-me-ji-chu-karahasimetekurautosekiyuri
  39. 39. Q&A 0x02 Q.あまりコストをかけることが出来ない上で利用できるセキュリティサービ スありますか? NRISTのSketCh、ClassmethodのInsights Watchでセキュリティ可視化 https://www.secure-sketch.com/ https://insightwatch.io/
  40. 40. Q&A 0x03 Q.インシデントレスポンスのための準備をやっているところって少ないと思って いて、なかなか上司の説得が大変です。 一度やられたらわかります。 私はやられたことありませんが、 やられた多くのお客様が前社時代に駆け込んできました。 絶対安全なんてものはないので、合間合間で準備をしておくにこしたことはない とおもいます。
  41. 41. Q&A 0x03 インシデント起きてからかける工数、コストを考えてみましょう。 https://tech.nikkeibp.co.jp/atcl/nxt/news/18/03708/ https://ferret-plus.com/11382
  42. 42. Q&A 0x04 Q.トップダウン、ボトムアップどっちからセキュリティをやっていくといいか? 個人的意見多分に含みますが、トップダウンで降ってくる=経営層がセキュリティを意識しているとも捉 えれて羨ましい環境ですね。トップダウン、ボトムアップどっちの観点からも進めるのが良いとおもい ます。 ただ、社内で会話が出来てなくて、向かう目標が違っていると大変なので、きちんと経営層とも話をし ながら、お互いにコンセンサスをとりながらセキュリティ対策を歩み寄っていける形にもっていくべき と思います。

×