Security-JAWS 第12回レポート #secjaws #secjaws12 #jawsug

はじめに

こんばんは。岩城です。 Security JAWS 【第12回】 勉強会 2019年1月21日(月)に参加中なのでレポートいたします。 リアルタイム更新に挑戦しており、セッション資料等は公開された後に随時当エントリに反映していきます。

概要

• 2019/01/21（月）19:00 - 21:30
• アマゾン ウェブ サービス ジャパン株式会社
• 東京都品川区上大崎3-1-1 目黒セントラルスクエア 21F

時間	内容
18:30	受け付け開始
18:50	運営からのお知らせ
19:00～19:10	自己紹介タイム
19:10〜19:30	Session1:Amazon Web Services Japan株式会社 中島 智広さん「セキュリティのおともにAmazon CloudWatch Logs Insights」
19:30〜19:35	Q&A
19:35～19:55	Session2:ソニーネットワークコミュニケーションズ株式会社 小野寺 剛さん「アカウント認証基盤の外部攻撃 WAF防御事例紹介」
19:55〜20:00	Q&A
20:00～20:10	休憩
20:10～20:30	Session3:PwCあらた有限責任監査法人 饒村 吉晴さん・有村 拓朗さん「当局と求められる対応のトレンド -AWS評価パッケージのご紹介-」
20:30〜20:35	Q&A
20:35～20:55	Session4:クラスメソッド株式会社 臼田 佳祐さん「簡単に始めるAWS基盤のセキュリティ分析~Sumo Logic~」
20:55〜21:00	Q&A
21:00～21:20	Session5:Mark Ryland, Director, Office of the CISO, AWS「AWS SecurityとOffice Of the CISOの概要」
21:20〜21:25	Q&A
21:30〜	撤収

セッション内容

Amazon Web Services Japan株式会社 中島 智広さん「セキュリティのおともにAmazon CloudWatch Logs Insights」

• はじめに
• CloudWatch Logs Insightsをセキュリティ運用の観点から説明
• セキュリティ運用に欠かせないログ調査
• ユーザが誤って不審なファイルを開く
• 脆弱性に対する通信が発生していないか
• 社外よりブラックリストが提供され、社内からアクセスしていないか
• ログ調査に何を利用しているか
• 分析ツール
• ワンライナー、スクリプト言語（grep,perlなど）
• 両方
• 効率化しにくい理由
• 一定でない調査目的
• 種類、状態、環境で異なるログの所在
• ハイブリット環境
• コスト、手間
• OSSを導入するにはコストが高い
• Amazon CloudWatch Logs Insightsの概要
• CloudWatchに保存されているログをインタラクティブに検索して分析できる機能
• 重要なポイント：AWSとオンプレミスの両方のログをサポートしている
• 利点
• 簡単で強力
• 柔軟なクエリ言語
• 従量課金
• 固定費用なし
• 高速・スケーラブル
• 大量のログを数秒で走査
• フルマネージド
• 操作イメージのデモ
• 期間選択が便利
• クイック・リファレンス
• クエリコマンドと基本構文
• コマンドは6つ（FIELDS,PARSE,FILTER,STATS,SORT,LIMIT）
• UNIXのシェルライクなパイプ文字でコマンドを連結できる
• FILEDS
• 指定したフィールドをログイベントから取得
• ログフィールドが予め定義されており、簡単に利用できる
• PARSE
• 自動識別されていないログフィールドからデータを抽出
• FILTER
• クエリの結果の条件に基づいてフィルタリング
• STATS
• STATS~BY
• 統計の計算事にデータをグループ化
• SORT
• LIMIT
• 対象期間の指定
• GUIから指定可能
• デモ
• FILTER
• amazon-ssm-agentのログに限定できる
• PARSE、FILTER
• proxyのログからurlと認証失敗したログの統計
• STATS~BYを用いたグラフ化
• クエリをダッシュボードへ登録でき、毎回クエリを実行せず再度コンソールから簡単に確認できる
• まとめ
• アドホックなログ調査の多いセキュリティ運用には便利な機能
• 見える化することにより自社、自組織での活用を検討できおるようになった
• Q&A
• オンプレにはエージェントを導入する必要があるか
• 統合CloudWatchAgentを導入する必要がある
• 結果を定期的に取り込んだ際に、キーワードに基づいてアラートを上げるられるのか
• SDKを提供しているので、コーディング次第で可能、ワンクリックでできるようなものではない
• SNS連携はできないのか
• 今の所簡単にできるようにはなっていない

ソニーネットワークコミュニケーションズ株式会社 小野寺 剛さん「アカウント認証基盤の外部攻撃 WAF防御事例紹介」

• アカウント基盤とは
• SonyAccount
• ソニーグループのサービスを利用できる
• 主にBtoCのビジネスを行うお客様に対する安全なユーザアカウントサービスの提供がミッション
• DevOpsが担当
• アーキテクチャ
• CloudFront→AWS WAF→ALB
• DevSecOpsチーム
• DevOpsが定着しており、Security関連タスクの自動化にも取り組んでいる
• アカウント認証基盤を構築するにあたって、セキュリティへの対応が求められた、セキュリティへのアクションを開発の段階で対応してきた
• DevOpsの文化が根付いた組織やプロダクトであったので対応できた
• DevSecOpsはチーム内の連携が大切
• アプリ、セキュリティインフラ担当が同じチーム内で連携があったDevSecOpsができている
• デイリーで夕方にアラートの報告をやり、対処が必要なものはアプリチームへ連携
• ウィークリーで先週行った対応を振り返っている
• 不正アクセスのリクエストが増えたので、不正アクセスの状況を確認する項目を設けている
• 外部攻撃の歴史
• サービスイン前から社内の別チームから一般的に想定される攻撃に予め対応しておきサービスインに備えた
• AWSからLambdaのコードが公開されおり、AutoBlockを実装してリリースした
• 現在発生中の攻撃に対して適用枠10個内でWebACLを柔軟に入れ替えている
• サービスインから1ヶ月後外部からの攻撃が来た
• アカウントサービスを狙った攻撃
• アクセスログ・アプリケーションログをSQLで解析できる仕組みが活躍
• S3にあがったログをFirehoseなどを用いて、DevSecOpsチームがすぐに対応できるようになっている
• 海外からのアクセス、TLSのバージョンが古い、自分たちが想定していたレスポンスとは違うステータスを見える化
• すぐに複数の対策を立案
• サービス提供外の国を即ブロックし、別の対策を実装する時間を捻出
• CloudFrontのTLSのバージョンアップ
• IPアドレス単位のエラー回数によるAutoBlock（Lambdaで実装）
• WAF防御事例1 Geo match
• 実践的なセキュリティモデルを簡単に導入
• 別の対策を実装する時間を捻出
• WAF防御事例2 IPアドレス AutoBlock
• 公開されているベストプラクティスをサービスイン前に実装済みだった
• ブロックされるとしきい値を探ってくるリクエストが増えるので、チューニングを行って判定ロジックのミスマッチを改善し、有効に働くようになった
• AWS WAFのマネージドルールを採用
• IMPERVAを採用
• すごく安くて、すぐに試せる
• 開発者からボトムアップで利用許可を得られる価格
• ０ではなかったがあまりマッチしなかった
• FORTINET OWASP10のルールを購入
• 一般ユーザへの影響を出さずに、攻撃者をブロックできる
• 攻撃からサービスを守り安定した運用を
• DevOpsが根付いていて、実装したブロックロジックを理解
• AWS WAFはコストが低く、即導入できる
• 運用中、すぐ試行でき、最適な対応がすばやく実現できる
• おまけ：おもしろ攻撃集
• Githubで公開されているセキュリティツールと思わしきコードが悪用されている
• 画像など静的ファイルしかホストしていないようなドメインに対する執拗な攻撃
• WordPress管理画面を狙ったリクエスト
• 著名な有名アプリケーションを狙った攻撃
• まとめ
• 実際やってみて推奨構成
• 攻撃は継続される
• 攻撃は一度止んでも再来訪することも
• 複数パターンの攻撃が同時に発生する
• ベストプラクティスをカバーしつつ受けている攻撃の固有ルールを適用できるWebACL運用が良い
• 新ルールを試すカウント枠もほしい
• AWS WAFの運用ポイント
• シンプルなルール
• （メモれず・・・）
• （メモれず・・・）
• DevSecOpsでより良い世界へ
• Q&A
• WebACL１０個を切り替えている運用はどうやっているのか
• 一部Cfn化されているが、後から確認したりして翌日確認する
• 2つのマネージドルールは利用し続けているのか
• 片方は解約した、一方は柔軟にルールを入れ替えて利用している
• どのルールを当てるか、わからない場合は分析しているのか、判定の方法は
• 一般的な攻撃は来ていない、自サービスに特化した攻撃であるため、分析してブロックを続けている

PwCあらた有限責任監査法人 饒村 吉晴さん・有村 拓朗さん「当局と求められる対応のトレンド -AWS評価パッケージのご紹介-」

• クラウドアドバイザリー&アシュアランスサービス
• クラウド利用をけんとうする企業やクラウド事業者に対して、当局や関連団体との連携も含めて統合的なサービスを提供している
• 政府のクラウド利用の安全、認証プログラムの検討に参加
• セキュリティにおけるトレンド（覚えて帰ってもらいたい）
• 経営のリーダシップとリスクベースアプローチ
• サプライチェーンセキュリティ
• 事後対応の強化
• 自動化とモニタリング
• サイバーセキュリティ経営ガイドライン Ver2.0
• システム監査基準およびシステム管理基準の改定
• 14年ぶりに改定
• 金融庁「変革的における金融サービスの向上に向けて」
• ７つの重点施策
• デジタライゼーションの加速的な進展への対応　〜金融デジタライゼーション戦略〜
• FISC
• 第８版から第９版に改定
• 有識者検討会において、重要なシステムでクラウド利用も提言されている
• 政府期間等の情報セキュリティ対策のための統一基準
• AWSのパートナー企業の一緒に出した
• クラウドの適用領域に応じた対応
• CIAで覚えている人が多いと思われる、つながる社会において可用性が重要のため、AICの順番で表記されはじめている
• 経営リーダシップに必要な報告
• KPIを設定して定量的に報告する
• AWS評価パッケージの紹介
• PwC Cloud Evolution Framework
• ENSAにPwCの知見を加えてアップデートしている
• コントロールを軸に経済産業省のガイドライン、FISC、NISCなどの遵守事項をマッピング
• AWS Well Archtectedの観点も加えている
• 主要なサービスに対してセキュリティのチェックをしている
• FISCやNISCに応じた点数付けを行っている
• SOC1の対応も紐づけている
• 色々な角度から網羅的にヌケモレがないことをチェックする
• PwCがクラウド・セキュリティ評価にて提供する価値
• Frameworkを用いた評価
• クラウド各種設定に関する技術対策の評価
• 経営層に対する報告書
• 定額パッケージ
• クラウド管理体制の評価
• クラウド利用技術対策の評価
• クラウド評価（オプション）
• 評価のアプローチ
• 設定の取得（自動/手動）
• NGだとしても守るべき項目かどうかを考慮してレポートする
• 技術対策評価におけるツールを利用した情報取得
• RedLockを利用している
• RedLockデフォルトとPwCカスタムでクエリを発行して情報取得
• 自動で取得しきれないものは手動、自動化に向けて計画中
• レポートからの調査
• NGだとしても守るべき項目がどうかを考慮する
• 経営層に向けたレポート
• 形成層向けにヒートマップ、技術担当向けに課題一覧
• リスクの定量化（Appendix）
• リスクベースアプローチでシステムを守ることが重要
• Q&A
• クラウド利用技術対策の評価において、脆弱性診断、プラットフォーム診断はOS/MWレイヤーで、構成管理はIAMロールなどのAWS設定周りを診断するものか
• そのとおり
• 脆弱性診断の取扱件数は
• すごく増えている
• フレームワークにて、AWSの新しいサービスを取り組む際にどのようにアプローチしているのか
• 対象にているサービスを決めており、全てのサービスを対象にしているわけではない
• 認証のアップデートタイミングで新サービスの利用を検討している

クラスメソッド株式会社 臼田 佳祐さん「簡単に始めるAWS基盤のセキュリティ分析~Sumo Logic~」

既にブログが公開されていますので御覧ください。 「簡単に始めるAWS基盤のセキュリティ分析~Sumo Logic~」というタイトルでSecurity-JAWS第12回に登壇しました #secjaws #secjaws12

• 今回はログにフォーカス
• AWSのログ
• CloudTrailログ
• ほぼ全部取れる
• CloudTrailログ分析の必要性
• AWSへのAPIコールのログを一元的に取得している
• AWSの基盤という意味では有益な情報が取得できる
• CloudTrailは昔はなかった
• 誰がEC2立てたか分からない
• セキュリティグループが空いている
• CloudTrailの有効性とログ分析の必要性
• CloudTrailのログ分析は辛い、とにかく情報量が多い
• 辛いログの分析を人がやっていはいけない
• デフォルトのViewは情報が少ない、情報量は多い
• AWSとしてのアプローチ
• 分析に利用するサービスを使う
• Amazon Athena
• CloudWatch Logs
• CloudWatch Logs Insights出てきてめっちゃ嬉しい！！！
• Security-JAWSでのログ分析
• 第7、８、9回で発表されている（資料はスライドのリンクから）
• Sumo Logicとは
• SaaSベースのログ分析基盤
• デフォルトで用意されている多数のダッシュボードですぐにログの可視化が可能
• マルチクラウド、Apache、セキュリティ製品などのログを取り込める
• 従量課金
• 他社に比べて優しい料金体系
• 見やすくグラフィカルなダッシュボードがデフォルトで作成されている
• 対応しているAWSサービスは一杯
• 認証系にも対応している
• デモ
• ダッシュボード
• APIコールがどの国からリクエストされているかマッピングされる
• クリエイトリソースから直近作られるたリソースを確認できる
• デリートリソースから直近削除されたリソースを確認できる
• FailedLoginから24時間以内でコンソールの認証に失敗しているリクエストを家訓できる
• ログインは単位時間あたりどれくらいあったのか
• しきい値を動的に調整する
• S3のパブリック公開されているオブジェクトがないか確認できる
• 個々のアラートを上げることが可能
• 各ダッシュボードにクエリが設定されており、クエリをローカライズできる
• tailライクな表示も可能
• 細かいところはブログで！！
• Sumo Logicのいいところ
• 特許を持っている機械学習機能
• LogReduce/LogCompareは動画見て！
• Sumo Logicが東京リージョンに対応した
• まとめ
• CloudTrailの可視化が必須
• Sumo Logicはすごい速さでログを取り組んで可視化できる
• 安いのでまずはトライアルから

Mark Ryland, Director, Office of the CISO, AWS「AWS SecurityとOffice Of the CISOの概要」

• AWSセキュリティとは何か
• プラットフォームのセキュリティの運用をしている
• AWSサービスのセキュリティやコンプライアンスをやっていくチームがある、脆弱性診断など一般的なセキュリティ関することにも取り組んでいる
• AWSセキュリティアシュアランスにてコンプライアンスを
• externalサービス（お客様のプラットフォームからAWSサービスを利用するセキュリティサービス）を担当するチームがある
• お客様の意見を取り込みサービスを作るために、Office Of Seesawがある
• 企業のトップからセキュリティにエンゲージメントすることが重要
• CXOレベルでセキュリティインシデントを深掘りすることが重要
• AWSではAndy Jassyも関わっている
• Q&A
• Amazon Macieの東京リージョン対応を早く
• 日本語の問題が大変、鋭意対応中
• CloudTrailでまだログ取得できないサービスへの対応
• 各サービスは各サービスのチームで対応しているため、セキュリティチームから強く対応を働きかけられないが鋭意対応中
• Control Towerを使いやすくしてほしい
• PreViewFunctionがあるので使えるのではないか
• ランディングゾーンを使ってみてほしい
• IAMポリシーのyaml対応は検討されているか
• サービスレベルでハイレベルで変える方向で考えており、yaml化は難しい
• 大企業向けにSecurityHubやControl Towerがリリースされたが中小企業向けなサービス提供はあるか
• 必ずしも大企業向けに提供しているわけではない、まずは使ってみてほしい
• AWS WAFの最大数を増やせないか
• セキュリティグループもかつては制限があったがお客様の声から上限を増やしてきた、WAFも今後増えていくと思われる

おわりに

CISOに直接Q&Aできるのはとても有意義だったのではないでしょうか。今後のセキュリティ関するAWSの方向性が少しだけ垣間見えた気がします。 リアルタイム更新はすごく疲れました。もっと早く正確に分かりやすくまとめられるようになりたいと思います。