Security-JAWS 第14回レポート #secjaws #secjaws14 #jawsug

Security JAWS 第14回のレポートです。re:Inforceの話からConfigのつらみ、始まり機械学習を使った不正検知やLanding Zoneと組織の話まで様々ありました。興味がある方はぜひ次回ご参加ください！

#イベントレポート

#JAWS-UG

#レポート

#セキュリティ

#AWS

臼田佳祐

2019.08.28

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

こんにちは、臼田です。

Security JAWS 第14回が開催されましたのでレポート致します。

Security JAWS 【第14回】勉強会 2019年8月28日(水) - Security-JAWS | Doorkeeper

レポート

Session1: アマゾンウェブサービスジャパン株式会社松本照吾さん「re:Inforce Recap 2019 改め皆様にお願いがあってまいりました！！！」

[slideshare id=167082342&doc=sjawsrecapreinforcepublish-190828081731]

ざっくりRecap
- 資料が公開されているので見たいものを見てください
- 注目セッションはスライド参照
- AWS Security blogのカテゴリごとに人気が高かったセッションのリストがある
- ジェネラルなものはleadershipセッションがおすすめ
June 16-17, 2020に次回のre:Inforceがある！
- テキサスであります
- 是非参加しましょう！
皆さんにも Re:Inforce体験を！
- AWS Security Roadshow Tokyoを開催します！
- 2019 年 9 月 25 日（水）開催　大手町プレイスカンファレンスセンター
- 700名参加できます！
- 日本の事情に合わせたセッションもある
- Security JAM / Capture The Flagも併催します！
  - Security JAMはAWS上のセキュリティチャレンジをチームで解決し合うゲーム
  - Capture The FlagはJeopardyスタイルとCastle defenseスタイルによるAWSを利用したCTF
  - 残念ながら両イベントはSOLD OUT(つい先程！)
  - Roadshow自体には参加できるので応募してください！
- 基調講演ではPｗCあらた有限責任監査法人の方やJapan Digital Design 株式会社の方が登壇
- お昼に松本さんが登壇します
  - 僕と握手！
- 午後はブレイクアウトセッション
  - AWSユーザとAWSの方が交互で登壇
  - 時間とともに深い内容になっていく予定
- AWSは最近ビルダーという言葉を使う
  - ユーザ部門でも何かを作ろうとしている人をビルダーとしている(開発者だけではない)
- Security JAMは別部屋で行われている
- クロージングも松本さんがしゃべる
  - 是非参加してください！
おまけ: 私が見つけたおすすめ
- Security best practices the well-architected way - SDD318 - AWS re:Inforce 2019
- Well-Architectedは様々なベストプラクティス
- 登壇者はSecurityのWell-Architectedを作っている
- 資料の中にLabsもある
- 是非試してみてください！

感想

Security Roadshowは日本で開催される大きい規模のイベントなので是非参加したいですね！

Well-Architectedは重要な考え方なので絶対参考になりますので見てみてください！

Session2: パネラー : 株式会社リクルートテクノロジーズ安東美穂さん, ＮＲＩセキュアテクノロジーズ株式会社関戸亮介さん, 株式会社クラウドネイティブ吉田浩和さん, モデレーター : Security-JAWS 吉江瞬さん「re:Inforce 参加報告パネル」

パネルの発端
- AWSの公式カンファレンスはいくつかある
- セキュリティでもいくつかあった
- re:Inforceが新しく出てきたがよくわからなかった
- 実際に参加してきた方に話を聞きたかったのでパネルにしてみた
実はAWSでもRe:Cap Seminarを実施済み
- 詳細はこちら
パネラー紹介
- 吉田ひろかずさん(@fnifni)
  - 株式会社クラウドネイティブでセキュリティエンジニアをしている
  - 日本ではキャッチできない先進的な考え方をキャッチしに行った
- 安東美穂さん
  - 株式会社リクルートテクノロジーズでセキュリティアナリストをしている
  - SOCでIDSやWAFなどをやっている
  - 新しい攻撃の検知などを目的に参加した
- 関戸亮介さん
  - NRIセキュアテクノロジーズ株式会社でセキュリティアーキテクトをしている
  - セキュア開発、コンサルティングをやっている
お題1: re:Inforceにいった目的
- 関戸さん
  - これまでre:Inventには行ったことがなかった
  - 情報のキャッチアップはしていたので募集を見て直ぐに反応した
- 安東さん
  - EBCが目的
  - AWSのサービスの責任者と話すため
  - 関心の高いサービスについていくつか設定してもらった
  - 新しくリリースされるサービスの情報も収集した
お題2: re:Inforceのみどころ
- ひろかずさん
  - re:Inventだと会場が広くて回りきれないことが多いが、re:Inforceはいい意味でコンパクト
  - Security JAMを会場に行かなくても参加できたので、ちょっとした休憩で参加したりした
  - 時間の使い方がだいぶ楽だった
  - そこかしこにホワイトボードがあったので英語があんまり喋れなくても色んな人とやり取りしやすかった
- 関戸さん
  - 街がめっちゃ綺麗だった！
  - 自動的にどうやって安全にするかみたいな話もあって開発者視点で学びがあった
お題3: 特におすすめしたいセッション
- 安東さん
  - Security JAM
- 関戸さん
  - bootcamp (building serverless compliance-as-code)
- ひろかずさん
  - AWS re:Inforce 2019: Amazon SageMaker Model Development in a Highly Regulated Environment (SDD315)
    - すごくクリティカルな情報を扱うときにどうやるのか
  - AWS re:Inforce 2019: Scale Permissions Management in AWS w/ Attribute-Based Access Control (SDD350)
    - 属性ベースのアクセスコントロールをどうするか
  - Using ML with Amazon SageMaker & GuardDuty to identify anomalous traffic
    - ラボのGitも公開されているのでぜひやってみてほしい
- 全体のYouTube
お題4: 参加して何を学んだか？所属企業や日本にどうひきこんでいくか？
- 安東さん
  - ライブ感がすごかった
  - 問題を直接現地の人に話したら次の日に改修された
- ひろかずさん
  - セキュリティ部門の人が引きこもる時代は終わったと感じた
  - 色んなものが進んでいて手が足りなくなってきている
  - コードにしたりCI/CDしたり監査の人もコード化するのでセキュリティの人だけだと限界
  - コードを書くのが得意な開発者と連携していくことが大切だと感じるイベントだった
お題5: 最後に一言
- 関戸さん
  - 英語があまりできなくても行けばコミュニケーションはなんとかなるのでぜひ行ってほしい
  - セッションはいつでも見れるけど、現地に行くなら隣りにいるエンジニアと会話したりすると大きな収穫になる
- ひろかずさん
  - 行くしかないイベント。行かないとわからない
  - いろんなエキスポを回っておきたかったという後悔
  - 日本では拾えないトレンドを拾えたはず
- 安東さん
  - re:Inevntは圧倒的なエンジニアリングのパワーなどを感じるが、re:Inforceはいい意味で規模も小さいのでセキュリティに絞ったりはじめて行くならいいかも
  - 自分たちをグローバルと比較してどうかと考えられる

感想

セッションはスライドや動画が公開されていますのでそのキャッチアップはできますが、現地の温度感はパネルを聞いていて楽しそうだなーと感じましたので行かなかったことを後悔しました！

来年はぜひ皆さん参加しましょう！

Session3: 株式会社クラウドネイティブ吉田浩和さん「UnConfig」

AWS Config有効にしていますか？
AWS Config活用していますか？
AWS Configとは
- AWSリソースのインベントリ/構成管理のためのフルマネージドサービス
- AWSリソースの構成変更をロギング
- 構成情報のスナップショットをS3に保管
- 構成変更の追跡やセキュリティ分析、トラブルシューティング、コンプライアンスチェック
- コンフィグルールという機能でS3を公開させないなどのチェックを行う
Configの機能
- Snapshot
  - ある時点のコンフィグの集合をS3に保管
  - Config るぇsの判定タイミングの一つ
- History
  - リソースタイプの集合。設定履歴をS3バケットに保存
- Stream
  - リソース作成/変更/削除に伴い作成され、SNSへ通知可能
構成管理/監査系の星
- 有効にしない手はない
- 新しいアカウントを払い出したらまずConfigを有効にすべき
今日のテーマ
- 素晴らしい機能が集まっているので期待が高まる
- AWS Configに抱く甘い幻想をぶっこわす☆
- (あくまで個人の見解です)
とあるお題
- 安定したAWS環境があるので変更を検知したいのですよ
  - 抱く幻想1
    - Streamを通知してフィルタすればいい
  - 幻想2
    - SnapshotのDiffを取ればいい
- やってみる
  - 来るのは変更通知だけではない
    - Snapshot/Historyの取得通知
    - Rulesの評価結果/Not_Applicable通知
  - すべての変更通知が来る
    - AWSが行う操作も変更はすべて通知される
    - マネージドサービスでよしなにやっているやつも
  - サンプル
    - ELBのスケールイン・アウトに係る初変更
      - NIC削除/作成、SecurityGroupのAttach
    - 新機能追加に伴うEC2の属性追加
      - Capacity Reservationの追加
      - すべてのEC2から通知が来る
    - EC2起動時のManagedInstanceInventory作成
      - SSMを有効にしているときに動く
- ふぁー、しゃーない、フィルタするか
  - SNSに渡される段階で件名が切れる
  - 変更情報はリソース毎にスキーマがバラバラでリソース名を取るのも一苦労
  - そもそもConfigで収集される情報には変更者の情報は記載されていない
知りたかったことは人為的な変更
- もしかして詰んだ？
- いやまてConfig TimeLineがある
- コンソールだとCloudWatch Eventで拾えている
- エキスパートに聞いてみた
  - CloudTrailを参照している
- cloudtrail lookup-eventsでとる
よろしい、ならば実装だ
- manual-changes-detector-pocを作った
- ConfigからSNS -> SQSでLambda起動
- 1つ目のLambdaでは差分がある内容を次に繋ぐ
- 次のLambdaでCloudTrailを参照
  - タイムスタンプそのまま使ってもだめなので肌感180secくらいのラグを吸収する
  - 除外処理も入れる
  - AWSが自動的にやったものはuser identifyがないので判断できる
- 最後のLambdaでSlackに通知
- Slack通知できた
- イベントIDをクリックするとTrailの画面を開く
ユースケース
- 安定した環境へのユーザに紐づく変更操作を検出
- コードでのデプロイを運用ルールとしている環境でそれ以外のユーザによる変更を検出したい
Githubで公開しています
注意事項
- あくまで概念実証コード
- 本番ワークロードでは状況に応じて改修や調整を必要とします
- 現時点の完成度は60%
- プルリク大歓迎
まとめ
- Config Streamを使えば都合よくいい感じに変更を追うことができるのは幻想
- 何かあったら追えますから一歩前へ
- 困ったときはExpertに聞くのも手

感想

Configでいい感じに検知したいっていうのはめちゃくちゃ共感できました。

頑張るのは大変ですが、運用を楽にするために自動化するのはいい選択肢だと思います！

ちなみにCloudTrail側で検知する手法も一緒に検討するといいと思います！

Session4: 株式会社ChillStack 伊東道明さん「AWS上で動くWebサービスの不正ユーザ検知手法の紹介」

AWS上で動くサービス例
- 動画配信、ブログ/SNS、ECサイト、などなど
- それぞれで不正対策を行うと思う
- ソーシャルゲームの例
  - 開発時はDASTやSAST
  - 運営時は通信の暗号化、共通暗号鍵の秘匿、リバースエンジニアリング対策
  - 不正行為された後は通報ボタンの設置やSNS監視、セキュリティポリシー作成、ログ解析に寄る不正ユーザのルール定義
- 大量に溜まっているユーザの利用ログから不正なユーザを自動的に見つけられると低コストである程度の品質担保ができる
- ログデータは離散的なテーブルデータが多い
  - 簡単に機械学習とかができない
  - サービスごとにフォーマットが異なることも特徴
  - モデルを他のところに使いますのも難しい
離散データに有効な手法
- 標準化
- 正規化
手法(教師あり)
- RandomForest
- SVM
- Boosting
- DNN
手法(教師なし)
- Spectral Clustering
- 等々
Boostingとは
- 省略
ALOCCとは
- 正常データだけで異常を検知できるようにする
- 正常なものを圧縮して複合
- 異常データを入れると復元データとの差分が大きくなる
AWS上で検知モデルの運用方法
- AthenaやRedshiftでログを溜め込んで読み出す
- 不正検知モデルをEC2やSageMakerで作成
- 検知システムをEKSやEC2で立てる
- 都度検知モデルのアップデートを養成する
管理コストが非常に高い
- しかし実運用するとこんな感じ
- Stenaというサービスを作っていてそれで簡易化できる
デモ
- リアルタイムに競技しているゲーム
- チータが明らかにおかしいスコアを出す
- Stenaの管理画面で確認できる
Stenaのログデータへのアクセス方法
- 直接Read権限を付けてアクセス
- Fluentdでログを収集する
Stenaの精度はとってもいい
- 去年の卒論で世界一の精度をだしてて、国際学会で最優秀賞を受賞した
- 公開された不正HTTPリクエスト検知などのデータセットを利用
詳細は技術ブログがあるのでこちらで！
- ChillStack技術ブログ

感想

機械学習のアルゴリズムとかはよくわかりませんがとにかくすごい製品ですね！ｗ

ゲームだとチート・Botを自動検出などで使えるので今後もチェックしていきたい製品ですね！

Session5: みずほフィナンシャルグループ山泉亘さん「＜みずほ＞が考えるクラウド活用の仕組み〜Landing Zoneとその先〜」

＜みずほ＞とクラウド
- 金融機関、金融業、お金…お客様の世の中の価値観の変化
- 変化の先はどうあるべき？
- 失敗できる体力と体質 = 成長し続けるための必須条件の獲得
- 変化していくためにクラウドが必須だと考えている
リスク評価とデザインパターン
- オンプレと異なるリスク
  - 過失・過誤
  - 委託先不正
  - 統制逸脱
  - 一緒にみえるけど大きさが違う
- パブリッククラウド用の考え方をイチから作るのか？
  - 既存から自社ポリシーを抽出して「ではクラウドならどうする？」を考える
- ペリメタモデルからゼロトラストへ
  - これまでセグメントを切ってNWゾーニングしていた
  - PaaS/SaaS利用が発展していくと適用しにくくなる
  - これからは認証認可、ゼロトラスト
  - それぞれの間を認証認可
  - 理解促進は大変
みずほでは内部ドキュメントを作成している
コスト評価とLanding Zone
- AWSの責任共有モデルのお客様範囲は広い
  - サービスレベルを適切に理解
- MUST / MUST NOTは予防的統制。注意制限事項は発見的統制
  - 認証認可の分離
    - 権限管理のアカウントを1つ作成
    - スイッチロールでテナントアカウントへ
  - AWS操作ログは共通アカウントに保管、集中監査へ
- 統制を効かせるためのベストプラクティス = Landing Zone
  - 組織で複数のAWSアカウントを管理する際のベストプラクティス
  - ログの集約やセキュリティ管理をBaaS化
苦労話
- サービス利用は認定性
  - 検証、評価、検証、評価、…
  - 各サービスをセキュアに利用可能か検証
  - AWSアップデートへの追従
- 自由度 vs ガバナンス
  - 予防的統制強め
  - だんだんバランスを変えていきたい
- 社内合意形成、間を埋める役割(=CCoE)
  - 様々な人がいるのでCCoEで橋渡し
  - グループ、エンティティの横断組織
今後について
- マネージドなLanding Zone
  - Control Tower
  - 乗り換えるかどうかも含めて期待している
- 予防的統制と発見的統制のバランシング
  - 要因教育・スキル向上、せってい自動化、発見的統制機能の充実
- セキュリティ対策としての人材育成
  - クラウドメリットの全員理解
  - 習うだけではなく慣れろ、まずは触ってみる
  - IT部門だけじゃなくて全員理解しよう
- コネクティビティ(ERG)というものを打ち出している
  - テック人材開発ERGもやっている
  - テック怖いをへらす