この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
Security JAWS 第22回が開催されましたのでレポート致します。
Security-JAWS 【第22回】 勉強会 2021年8月27日(金) - Security-JAWS | Doorkeeper
動画
レポート
Session1: インシデントハンドリングを効率化する AWS Systems Manager Incident Managerのご紹介 アマゾン ウェブ サービス ジャパン株式会社 柳 嘉起さん
- AWS Systems Managerの話から
- Incident Managerは単体のサービス名ではなく、Systems Managerの中の1つの機能
- Systems Managerは運用管理のツール群
- AWSもオンプレも管理する
- 他にもインベントリ管理とかコンプライアンス管理とかパッチ管理とか
- あとは運用ジョブ実行(Automation)とか
- AutomationはIncident Managerとも関連する
- Incident Manager
- Incidentとは？
- サービスにおける計画外の中断やサービス品質の低下をもたらすもの
- Incidentのハンドリング
- インシデントを検知
- 運用担当者が検知
- トリアージ/対応
- インパクトはどれくらい？
- 誰が対応するのが良い？
- インシデント指揮官(上長)
- 他の人に指示を出したり全体を俯瞰したり
- 原因分析/アクション
- インシデントを検知
- インシデント対応は多くの関係者がいる
- 目的
- インシデントの解決のための時間を短縮する
- 何を提供するか
- 関連情報の表示
- サービス復旧のためのツールを提供
- かっこよく言うと
- インシデントハンドリングを総合的に管理・支援するフルマネージドサービス
- Incidentとは？
- 全体感
- 対応プランに基づいて行われる
- 設定する = 対応プランを作る
- インシデントが発生したら
- 3種類の検知
- CloudWatchのメトリクスアラーム
- EventBridge
- 運用担当者のマニュアル対応
- 3種類の検知
- 対応プランが開始される
- インシデント自動生成
- 連絡先へ通知
- Chatbotと連携してSlackやChimeに連携もできる
- 指定したランブックの実行
- 対応プランに基づいて行われる
- 例
- EC2のCPU使用率が高まったときの対応プラン
- ダッシュボードに必要な情報がまとめられる
- 概要欄は予め作っておく
- インシデント発生時に必要な情報を書いておける
- インシデント発生時に受け取ったデータも表示できる
- ダッシュボードの概要を適宜編集できる
- 他にもいろんなタブがある
- メトリクス
- CloudWatchから引っ張ってこれる
- タイムライン
- 発生状況や対応状況を時系列に並べられる
- 追加ボタンからマニュアルでカスタムイベントを挿入できる
- 連絡先
- 通知方法にメール/SMS/音声など選べる
- 一定時間が経過したら次の連絡手段というフローを組める
- エスカレーションプラントして、さらに複数連絡先のステージを活用できる
- 担当者がACKをしたらエスカレーションが止まる
- パスコードを使ったりマネジメントコンソールでアクションしないといけない
- メールでの承認は8月に追加されたばかり
- 電話は国際電話、英語でいきなりインシデント番号が読み上げられるので面食らうかも
- 電話は重要な内容はない、承認するときは1を押すだけ
- 分析
- インシデントが解決してから整備する機能
- どのようなアクションをしたかとか
- インシデントの質問というテンプレートがあり設問がある
- どうしたら検知時間を改善できますか？
- どういうアクションをしたら良いか？
- などなど
- 設問集をカスタムできる
- メトリクス
- クロスリージョン構成
- レプリケーションセットで複数のリージョンを指定できる
- 他のリージョンに同期される
- 料金
- プラン: $7/月
- SMS/音声メッセージもかかる
- 詳細はこちら
- 直近のアップデート
- メールでのエンゲージメント承認
- CloudFormation対応
- 余談: SSMって？
- 最初はAmazon Simple Systems Manager(SSM)だった
- その名残でAWS Systems ManagerをSSMと言う
感想
インシデント対応フローは事前にしっかり組んでおきたいですね。あと改善も！
Session2: AWSのコンテナはここが要注意！セキュアなコンテナ開発環境を実現するには パロアルトネットワークス株式会社 西田 和弘さん
- コンテナのセキュリティどうします？
- 残念な人
- クラウドサービスが守ってくれるんでしょ？
- 従来のセキュリティの延長でいいんじゃね？
- 残念な理由
- コンテナの保護はユーザー責任
- EKSそのものにも若干注意が必要
- 従来の延長
- 個々のコンテナにEDR/ウイルスチェッカーいれますか？
- コンテナ間通信はSecurity Groupでは保護できません
- ベースイメージのセキュリティも考慮する必要があります
- コンテナの保護はユーザー責任
- 健全な人
- EKSそのものは安全？
- 更新が頻繁なコンテナにエージェントを入れるの？
- 安全なイメージを使いたい
- シフトレフトどうやる？
- FargateとEKSで違いはでるの？
- 残念な人
- クラウドネイティブセキュリティの課題
- 迅速なサービス展開に追いつかない
- あとからセキュリティ対策していくと遅い
- コンテナイメージのセキュリティ課題
- 攻撃者によるマルウェアを仕込んだコンテナイメージ
- うっかりさんによる秘密鍵を埋め込んだコンテナイメージ
- コンテナ環境のセキュリティ課題
- ガイドラインとしてNIST SP800-190がある
- コンテナイメージだけではなくオーケストレータやホストOSなども気にする必要がある
- Prisma Cloud
- コンテナ環境を保護する製品
- コンピュートやサーバレス関数にも対応
- エージェントを入れる
- コンテナ環境の保護
- ホストOSと保護専用コンテナで用意する
- 利用コンテナにエージェントは不要
- DaemonSet: システムコールをフックして不正な処理を防止
- イメージスキャン機能
- レジストリ上のイメージをスキャン
- 脆弱性・マルウェア・秘密鍵等を検出
- スコアリングしてくれるので判断しやすい
- 不正なイメージ利用をブロックすることもできる
- Prisma CloudでEKS環境を調べてみた
- 脆弱性は
- ホストOS: AL2_x86_64(5.4.129-63.229)
- KubeletとDockerに若干脆弱性あり
- 常に最新版にアップグレードを
- コンプライアンス(CIS)の結果
- Kubelet通信をHTTPSで暗号化すべし
- 特権コンテナを制限すべし
- EKSで特権モード利用をkubectl editして変更もできる
- 脆弱性は
- Prisma Cloudでコンテナイメージを調べてみた
- 各ディストリビューションのlatestをスキャン
- 結構色々出てくる
- ちゃんと更新しよう
- コンテナランタイム保護
- ルールと機械学習で保護
- ダウンロードされたファイル実行を禁止
- プロセスを学習して不正な動きをブロック
- WAFもある
- CI/CD連携できる
- デプロイ時にスキャン
- ビルドもとめる
- イメージ登録も止める
- マニフェスト検査も
- ランタイム保護
- Fargateについて
- DaemonSetが利用できない
- サイドカーコンテナを使う必要がある
感想
コンテナセキュリティはまた専用の知識が必要になるのでちゃんとチェックしていきたいですね。
Session3: 経産省DXレポートで主張したAmazon KMS 株式会社クラウドネイティブ 齊藤 愼仁さん
- SNS禁止だからダメだよ
Session4: AWSのインシデントレスポンスはここまで進化した！Radware Cloud Native Protectorによるインシデント調査 Radware Japan, SE Director, 和田一寿さん / クラスメソッド株式会社 シニアソリューションアーキテクト 臼田 佳祐さん
以下ブログを見てね☆ミ
Session5: AES SIEMを運用して分かった できること、できないこと freee株式会社 杉浦 英史さん]
- Freee
- SaaS提供の会社
- クラウドERPを目指している
- スモールビジネスを世界の主役に。
- リアルタイムデータ収集 + 可視化 + 自動化
- AES SIEMとは
- 昔はAmazonESの仕組みが3つ動いていた
- それぞれを人で頑張ってつなげた
- Amazon ESのSIEM
- 1年くらい使っている
- 重要なコンポーネントはes-loaderというLambda
- S3にさえ入れたらよしなにやってくれる
- できること
- ETLを簡単に構築できる
- S3にログを集めるはまあ難しくない
- Elastic Common Schemaにes-loaderで揃える
- DLQもある
- loadする前にfield nameを揃えてくれる
- CloudTrail / GuardDuty /AWS WAFなど名前が違うのを揃える
- Threat Huntingできる
- デモ
- Alertが飛んできた
- ダッシュボードで確認
- ルートログインの確認
- 1つだけupdateがあるけどほかはdescribeばかりなので問題なさそうと判断できる
- デモ
- ETLを簡単に構築できる
- できないこと
- サポート外のログ
- 例えばWAFv1
- 設定をすればいい
- sf_***というファイルで拡張してあげる
- DeepSecurityログ対応もした / PRした
- 多量のログ
- 小さなイベントをたくさん送ると拾えないことが
- 処理を分けてラッパーを書いて、pollingするようにした
- アラート
- ESの設定でできる
- Lambda別で書いてアラートもできる
- DLQの自動処理
- 全部入れるのは諦めた
- ピークに溢れた
- サポート外のログ
- わかったこと
- Elasticsearch設定あるある
- VPCに閉じ込めたい
- CDKを書き換えた
- S3とSQSのVPC Endpoint忘れずに
- Node設定変更はblue/greenデプロイ
- ALBが参照するIPの入れ替えが必要
- index fullにならないように
- Daily index
- Storage使い分け
- Index State Management
- Planning + Feedback
- log容量は予測できないもの
- 実測してから考える
- 25% Free Storage Alert
- ベストプラクティスにも書いてある
- VPCに閉じ込めたい
- Elasticsearch設定あるある
- 日々の運用
- もくもく会して分析し合う
- CSIRT/PSIRTで情報共有
- 対処方法を決める
- 改善する
- 気になるものを試してみる
- AES SIEMのありがたみ
- すべてを串刺しで観測できる
- 外部からの攻撃以外にも社内からの攻撃、侵入後の水平展開なども
- 前後関係の把握や影響範囲の特定
- ある日DDoSを受けました
- 大量のWAFブロック
- あるパスだけ
- Unique IPが1,000個くらい
- 1IPあたり10発くらい
- 時系列を確認
- DeepSecurityでSQL Injectionを検知している
- WAFは素通りしていた
- いろんなセンサーでみれるメリットが感じられた
- 検知漏れの把握ができた
- 自作自演
- 自社アプリで同じリクエストが大量にきている
- バグっぽいことがわかった
- 考えていくこと
- PublicAPIで気軽に探索してくる人とか
- サインアップしたあとアカウント大量追加する人とか
- コストはどうか
- あるログ分析のツールよりはだいぶ安いかも
- まとめ
- AES SIEMを入れれば対応しているものは簡単に分析
- 新しいものの対応もそんなに難しくない
- index管理は大変だけど肝は押さえている
- Threat Huntingに欠かせなくなっている
感想
１年ぐらい使っていて含蓄のある話でした。１箇所に情報が集まるだけでいろんなことが見えるようになっていいですね！
ぜひみなさんもSIEM on Amazon ES使ってみましょう！
[クラウドZoom相談] 当日のslido & ドアキで受付けた質問に回答する枠 Security-JAWS運営メンバー
一般的なシステムアラートとセキュリティインシデントは、データとしても検知方法としても別物であることが多いと認識していますが、AWSの監視サービスではセキュリティインシデントをどのように検知してアラート監視するプラクティスがあるでしょうか？ WAF, Shield, GuardDutyなど、AWSサービス自体がセキュリティに特化している機能はわかりやすいので、もしそれ以外のユースケースがあれば知りたいです
- アプリレイヤーの話であれば、オブザーバビリティの文脈でX-Rayなどを利用して見ていくなどがある
- CloudWatchとかでセンサー入れていったり
- 他のログ分析ソリューションに突っ込んだり
- アラート・検知ルールはそれぞれ作っていく必要がある
- 何を検知するか、を詰めていくは大事
- 何が脅威なのか、どう可視化したいのか
突発！re:Inforce日本最速(?)Re:Cap ひろかずさん
- re:Inforceとは？
- AWSが主催するセキュリティ、アイデンティティ、コンプライアンス似たおッカしたラーニングカンファレンス
- 2019年初回
- 2020年は中止
- 今年は中止の危機を乗り越えてバーチャル短縮開催になった
- re:Inventのセキュリティ版なんでしょ？
- セキュリティ新機能の発表ラッシュ楽しみやなぁ！
- ちがうんだなそれが
- 新機能は少ない
- でも発表された
- AWS Backup Audit Manager
- AWS Backupが動作している「日報」を見ることができる
- 監査の証跡を見やすくする役割
- AWS IoT CoreのVPC Endpoint対応
- IoT Coreの通信をインターネットに出さないで通信できる
- Level 1 MSSPプログラムの開始
- 品質を満たしたパートナーが登録される
- 長期的に信頼できるセキュリティ製品を手に入れることができる
- IAM Access Analyzer
- ポリシー履修
- ポリシー検証
- 使われないアクション
- Wickrの買収
- E2E暗号化
- 各セッションから垣間見えるメッセージ
- Keynote
- Threat Detection & Incident Response
- GuardDutyとかSecurity Hubとか
- 自動化やチューニングをしてアラート慣れを防ごう
- Ransomware
- オペレーション用とバックアップ用アカウントを分ける
- S3バージョニングとオブジェクトロック使おう
- DRを含めた包括的なバックアップ計画とゲームデイ
- ほんとに戻せるの？って確認
- SP1800-25で掘り下げる
- Identity and Access Management
- パスワードの使い回しは危険
- SSOや多要素認証
- IAM Access Analyzerはゲームチェンジャー
- パーミッションは定期的に監査
- ユーザーグループを使って権限管理の煩雑さを軽減しよう
- Network Infrastructure Security
- HBOmaxの事例
- 検出と対応
- ガードレール構築
- セキュリティエンジニアはSlackを介してyamlを作成
- Cloud CustodianでLambdaに変換して自動化を促進
- Confidential Computing
- AWS Nitro Enclaves
- HBOmaxの事例
- Data Protection & Privacy
- 普遍的な事柄の集合体
- AWSの考え方
- ID管理とネットワーク管理の両方を補っていく
- GDPRへの対応
- サービスの機能はGDPR適用対象であるか否かを問わずすべての顧客に適用される
- 転送評価の支援リソース共有
- 計画なしに機微情報を保存しないこと
- この分野は手探りですすめることはできない
- ビジネスを終了するレベルのリスクを持つ
- ビジネスで起こっていることを掘り下げて正確に
- GRC
- 高いレベルの認証を受けるためには150を超えるコントロールを満たす必要がある
- AWSサービスはセキュリティ監査で検証さえrている
- AWS Artifactで楽しよう
- 今日できること
- Cloud Audit アカデミー
- 監査の勉強をしよう
- Threat Detection & Incident Response
- Leadershipセッション
- Data Protection & Privacy
-
- 文化を形成する
- 各チームにセキュリティ担当者が組み込まれている
- 暗号化すれば良いわけではない
- 鍵の管理と透明性(Alexaの事例)
- ベッドで話したことは記録されないんだよ
- プライバシーは何をするかということ
-
- GRC
- 早く失敗する
- 監査のためのエンジニアを雇った
- コンプライアンスに見せられたエンジニア
- 専門監査人の台頭
- 冗長性をもたせる
- 製品のどこに焦点を当てるか
- たくさんあるコンプライアンスのどれに対応するか
- 学習したい人に
- aws.trainingのEラーニングはいいぞ
- Culture of Security
- セキュリティはバナナでした(ハイコンテキスト)
- Tenetsという言葉はよくわからんかった
- IAM
- AWS Organizationsを使ってマルチアカウント管理
- AWS SSO使ってアカウント中央管理
- データペリミタ
- SCP / VPCE Policy / Resouce-based policy
- 最小権限への旅
- IAM Access Analyzer
- IAM座談会
- Threat Detection & Incident Response
- セキュリティ機能使って対応短縮
- GuardDutyのベストプラクティス
- 対顧客のセキュリティオペレーションチームの話
- 管理者メールだけは受信しろ
- 行うべきアクションTop10
- Data Protection & Privacy
- 俯瞰して考察
- 開発プロセスにセキュリティを組み込む文化とコンプライアンスを組み込む文化は似ている
- プライバシーの考え方の頭出し
- Compliance as Codeはまだまだ普及していない
- 派手な目新しいものではなく、普遍的な事柄の積み上げ
感想
新しいものが少なかったのは残念！だけど大事な話が多かったのでちゃんとみんなやろうね！
さいごに
インシデント対応の周りが多かったですね。準備をしっかりして対応していきましょう。
質問募集してますのでどしどし送ってください！
25
