Security JAWS 【第9回】 勉強会 2018年5月16日(水) 参加メモ（をただ貼るだけ
Security JAWS 【第9回】 勉強会 2018年5月16日(水) - Security-JAWS | Doorkeeper
に参加した時のメモ書き。を単に貼るだけだけど上げておく。
＝＝＝＝＝＝＝＝＝＝
■フューチャーアーキテクト株式会社 日比野 恒さん、中井 祐季さん
「Kibana Canvasで魅せる！AWS環境における脅威分析ユースケース」
https://www.slideshare.net/hibinohisashi/securityjawskibana-canvasaws
オープンSIEM構想
シンプルな分析画面
個人情報を保持するシステム＜不正監査をする仕組みでAWS導入
無償でElasticStackの性能管理ができるX-Pack Basicのモニタリング
Beats
audit beats
○脅威分析のユースケース
・外部からの攻撃
マネジメントコンソール等々のログイン行為
APIの監査
・内部犯行
踏み台への不正ログイン
S3のアクセスログ（GETのログ
SQLアクセス
※内部犯行の特定はログと作業記録との突き合わせ
○CloudTrail分析
コンソールログイン, API操作
→いつ誰がどこから
LOgstashのgeoip filterを用いて送信元IPアドレスに国情報を孵化しておく
存在しないIAMユーザーでログいんすると
HIDDEN_DUE_TO_SECURITY_REASONS
IAMUserの実行したAWS APIコールについてCloudTrail操作ログを分析する
・IPアドレスで絞ってみる
・ユーザー名で絞ってみる
AWS管理コンソールへのろログインに関するCloudTrail操作ログ分析
・ConsoleLoginで絞ってみる
・MFA利用有無をNoで絞ってみる
○番外編
CLBのアクセスログからアプリの脆弱性をついた攻撃を検知
MLで異常検知
→CLBの遅延時間の大きい時間帯のアクセスで異常検知し、おかしなUserAgentを発見
○Canvasの話は？
間に合わなかった
＝＝＝＝＝＝＝＝＝＝
■Imperva Japan K.K. 岩下 洋司さん
「WAFシグネチャとログとAI」
Imperva
https://www.imperva.jp/
Attack Analyticsの機能紹介
○AWS WAFでImperva SecureSphereのシグネチャを提供してる件
マネージドルールとしてRuleセットを提供している
・IP Reputation Lists
https://aws.amazon.com/marketplace/pp/B07784QN39
・WordPress Protection
https://aws.amazon.com/marketplace/pp/B077GJ99B1
競合となるAWS WAFになぜManaged Rule Setを提供するのか？
・ユーザからの要求
・自社顧客とのユーザ層の違い
・AWSからの打診
IP Reputation Lists
→脅威を振りまく最新のアドレス情報を世界中の自社顧客のWAFから収集
→それ使えるの？
→75%以上のIPアドレスで攻撃があれば他の攻撃も行う
○セキュリティ装置のアラートが何かと多すぎる件
本当に必要なアラートだけに絞るには
重要なアラートを見逃さないためには
・Imperva Attack Analytics
AI, MLを活用したアラート分析
○ログ分析の分野に今後AIが盛んに利用されて行く件
USではDBファイヤーウォール製品が人気
日本ではファイル関連の製品が人気
→ポリシーを明確に書きづらい（統制を利かせにくい
＝＝＝＝＝＝＝＝＝＝
■株式会社NTTドコモ 守屋 裕樹さん
「JAWS DAYSで話せなかった「Security x Serverless」の話」
（JAWS DAYSでの公募から外れた内容
ドコモでのAWS利用
・2012年から本格利用
・400アカウントを運用中
・CCoE（Cloud Center of Excellence）チーム
→社内のガイドライン、テンプレート（共通基盤）作成
→対策方法やベストプラクティスを社内公開
○クラウドの表と裏
間違った使い方も簡単にできる
→ガイドラインだけでは防げない
・設定ミス／知識不足、
内部でScanMonsterと言う自動アセスメントツールを作成
→ガイドラインに照らし合わせて間違った使い方を検知
→57のチェック項目を実装
→同一画面で複数のAWSアカウントをアセスメント可能にしてる
→できるだけお金をかけない
・Trasted Advisor
→NG（クロスアカウントでフル機能だと高すぎる
・Config Rules
→OK（だけどお金がかかる
・AWS API
→OK（Lambdaでリソース効率化
Zappa（Pythonベースのサーバーレスフレームワーク）でバックエンド実装
○権限管理どうやるの？
・全てIAMロールで
・クロスアカウントのアクセスはIAMロールとSTSのみ利用
○ユーザ認証はどうやっている？
○サーバレスの接続元制限
API Gateway
→リソースポリシーにてIPアドレス制限
Lambda
→Event情報として接続元情報を取得可能。関数内のロジックでIPアドレス制限可能
CloudFront + WAF
→WAFでIPアドレス制限
○ログ収集
CloudWatchで
→機密情報の送信に注意
→1024バイトを超えるログが切り捨て
Cognito User Poolsではログイン履歴、認証の履歴といったログは取得不可
DynamoDBでもGetItemのログが取得不可
CloudWatch logs
→JSONで吐かれるのでコンソール上では解析が難しい
○QA
Trusted Advisorはエンタープライズサポートに入れば安くなるのでは？
→社内事情です
＝＝＝＝＝＝＝＝＝＝
■SecureWorks Japan 株式会社 山崎 景太さん
「攻撃者視点から考えるAWS EC2セキュリティインシデントとその対応」
Red Team Testingサービス
→物理的な侵入も含めた攻撃サービス
・外部からの攻撃によって発生するインシデント
・攻撃者の視点から考える
・○○からの攻撃
・case study
○EC2環境で発生する基本的なインシデント
・Webアプリの脆弱性
・OSコマンド実行系の脆弱性
・アクセス制御の不備
・AWS管理コンソールへの不正アクセス
とはいえ発生するインシデント
・Zero-day
・予算不足
・現場の理解不足
・検証環境/開発環境のShadow化
○攻撃者の視点から考える
・攻撃ポイント
・社内端末、委託先端末や自宅端末（リモート端末
・VPC内のシステムに侵入するためには
・アクセス経路が確保されている
・アクセスに必要な認証情報を取得する
Red Team Testing Approach
内部活動
○正規運用端末を乗っ取ると（何ができるか
・アクセス制御のバイパス
・認証情報の窃取
・侵入の拡大
いわゆるCVEに乗るような脆弱性やアクセス制御のミスがなくても侵入可能になる
○アクセス制御のバイパス
基本マルウェアに感染させて端末を乗っ取ってアクセス
AWSコンソールのセッションタイムアウトの時間知ってますか？
→12時間
→この時間内なら端末を乗っ取っているならカレントセッションを乗っ取れる
→使い終わったらログアウトしましょう
○Wrap Up
・インターネットからの直接的な攻撃に対して必要な対策を講じておくのは当然
・社内ネットワークを経由知れば、ターゲットシステム（EC2）に侵入する経路は増える
→内部からの攻撃を考慮して内部からの攻撃対策をしておくのが重要
・インシデントは起こる
→のでインシデントレスポンス対応体制の整備が必要
→攻撃を遅らせている間に対応
○EC2のフォレンジック用データの取得
・ボリュームスナップショットを取得してセキュリティベンダーへ提供
・暗号化ボリュームの場合は鍵情報も併せて
○AWS
○OS内のデータのログギング
who, where, when, what
○QA
AWS管理コンソールは使い終わったらログアウトしましょう
＝＝＝＝＝＝＝＝＝＝
■電気通信大学 手柴 瑞基さん
「自動車監視のためのクラウドソリューション（仮）」
https://speakerdeck.com/himitu23/jaws-security-09-tokyo-cloud-solution-for-management-and-observation-vehicle
OBD2ポート（CAN）
→診断用端子
キーフォブ
コンピュータ（ECU）
PiCAN、ODB-IIケーブルを用いてCAN通信を取得
→ハンドルの右下か左下にODBってポートがあるのでそこから取得できる
＝＝＝＝＝＝＝＝＝＝
■LT#1:株式会社NTTドコモ 神崎 由紀さん
「ドコモでのインシデント事例と対策（仮）」
（先のドコモの方と内容が被ってた気がするのであんまり聞いてない。ごめんなさい
＝＝＝＝＝＝＝＝＝＝
■LT#2:クックパッド株式会社 水谷 正慶さん
「セキュリティログ分析のためのサーバーレスアプリケーションの構築（仮）」
https://speakerdeck.com/mizutani/sekiyuriteirogufen-xi-ji-pan-falsegou-zhu-on-aws
https://speakerdeck.com/mizutani/korega-cloud-native-na-sekiyuriteirogufen-xi-da-jia
のブラッシュアップ版
SIEMだとクラウドでは…
・ログの送信元を動的に制御できない
・全体構成を気軽にいじれない
・ルールのテストが難しい
＝＝＝＝＝＝＝＝＝＝
■LT#3 T3 Realize合同会社 横堀 達也さん
「アセスメント指摘事項への対応をサーバレスでチャチャッとやる話」
Systems Manager
Logs Agent
SSM Agent
AWS Systems Manager
SSMエージェントでWindows 10 Proも管理できる（らしい
無料でクライアント端末管理できちゃう？
