この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
Security JAWS 第20回が開催されましたのでレポート致します。
Security-JAWS 【第20回】 勉強会 2021年2月18日(木) - Security-JAWS | Doorkeeper
動画
当日のアーカイブが公開されました。合わせて見てください。
レポート
挨拶
NISCのサイバーセキュリティ月間に協力しています！
みんなで叶えるセキュリティ！
Session1: 「AWS re:Invent 2020 Security re:Cap」 アマゾン ウェブ サービス ジャパン株式会社 桐山 隼人さん
- いつも2月に喋っている
- ぜひ来年もご登壇ください(編集注)
- セキュリティのリーダーシップセッション
- re:Invent 2020でCISOのStephen Schmidt氏の登壇内容
- ゼロトラスト
- AWSでどうやって行くか
- アイデンティティの防御かネットワーク防御か？という選択を避けるためにAWSを利用する
- AWSでは両方を組み合わせる
- VPC/Security Groupでの制御や、S3などにはIAMでも制御できる
- AWSでは昔からゼロトラストに取り組んでいたし、これからもやっていく
- 10個のセキュリティの項目
- 例えばNo hard soft defense
- ココナッツに例えると、外は固くて中は柔らかい
- これは良くないセキュリティ
- すべてのレイヤーが大事
- 詳しくは動画をみて！
- 例えばNo hard soft defense
- セキュリティ関連サービスアップデート
- AWS Audit Manager
- 手動のリスク管理プロセスはクラウドの俊敏性を阻害する
- 事業部門や法務部門がマニュアルなプロセスを行うことによってビジネスが阻害される
- 例えば監査のエビデンスの収集
- Audit Managerではエビデンスの収集を自動化
- 組織のセキュリティを守るには3 lines防御という考え方がある
- 第一防衛戦はリスク管理機能
- AWSではTrail / Configなどの運用管理に役立つリソース
- 第二防衛戦はリスク監視機能
- AWSではSecurity Hubなどのセキュリティポスチャの管理など
- 第三防衛戦はリスク管理の独立したアシュアランスを提供する機能
- ここをAudit Managerでやる
- 監査やコンプライアンスの位置づけ
- 第一防衛戦はリスク管理機能
- 何ができるか
- AWSの利用状況を継続的に収集
- 自動で収集できる
- 評価ルール
- CIS / PCI DSS / GDPR / FedRAMPなどなど
- 動作
- CloudTrailからのアクティビティ収集
- Config / Security Hubからコンプライアンス状況収集
- 手動
- 処理プロセス
- Controlがエビデンスを収集
- Assesmentでレポートを作成
- Security Hubアップデート
- AWS Organizationsと統合
- 自動で・一括で有効化が可能に
- Kube-bench / Cloud Custodianと統合
- AWS Organizationsと統合
- AWS Configアップデート
- Delegated Administratorの設定が可能に
- AWS Organizationsを使って管理の委任ができるように
- 他にもいっぱいアップデートがあるけど割愛
- スライドをみてね！
- AWS Audit Manager
感想
10個のやつ、要チェックですよ！
Audit Managerもぜひ使ってみましょう！
Session2: 「今日から始めるAWS監視〜Cloud SIEMでAWSのセキュリティを強化する〜」 Sumo Logic Japan セールスエンジニア CCSP 神崎哲朗さん
- Sumo Logicとは？
- ログ・イベント・メトリクス・アプリケーションパフォーマンスを統合監視・分析
- マルチテナント型クラウドSaaS
- AWSや様々なクラウドソリューションなどから情報を取り込んで分析可視化
- SIEM以外にも稼働監視やビッグデータ分析なども
- SIEMとは？
- Security Information and Event Managementの略
- スレットハンティングや相関分析などもやったりする
- 様々なインシデントの検知が可能
- Sumo Logicのここが好きだ！
- SaaSで気軽に使える
- AWS東京リージョンでも使える
- デモ
- シナリオ
- ある日AWS/Linux等を統合監視しているエンジニアにあるSlackメッセージが届く
- Sumoがトロイの木馬に関連したIPを検知した
- 原因を特定していく
- ブラウザでアクセスしている
- オンプレはないよ
- AWSやapacheやpaloのログなど様々なものがすでに入っている
- ログの入れ方を参考に紹介
- AWSの場合はS3の権限をSumoに渡すと取ってこれる
- Sumoは東京リージョンにあるので、S3バケットが東京ならログ転送料が無料！！
- App Catalogというテンプレートを使えば、取り込んだログからリッチなインサイトを自動作成！
- 今回はトロイの木馬ということでCloudTrail以外にもいろいろ見ていく
- WAFの検知状況や各サービスのアクセス状況を一覧化したダッシュボード
- コンソールログインの状況も変化なし
- Linuxのログが大量に出ているので怪しい
- サーバーのCPUの状況は特定の時間で跳ねている
- SSH試行回数が近い時間で跳ね上がっている
- 同じ時間に特定のIPからリクエストが増えている
- このIPを止めれば良さそうだけど、もう少し見ていく
- paloのログではmysqlのデータが外部に大量に出ている
- これまでmysqlは全くデータが流れていなかったので怪しい
- CroudStrikeから脅威情報も共有されている
- 危ないIPやドメイン、URLなど
- これらをログと突合できる
- ダッシュボードから検索画面へ
- IPアドレスをキーワード検索してみる
- 2万件が1200件くらいに
- まだ多いのでLogReduce機能を利用
- ログをパターン別に分類して表示できる
- 今回はインシデントなどでパターンでまとめられたうち、少なめのログを見ていく
- sshdの接続が成功したログがあった
- 単純な検索では見つけづらいので、各種機能を使っていきましょう
- シナリオ
- デモまとめ
- SaaSはいいぞ
- CrowdStrike連携いいぞ
- LogReduceなどいいぞ
- おまけ
- 新しくAWS Observability Solutionを出しました
- SOCの自動化をやっている
- Cloud SIEM Enterprise
- アラートのルールをアップデートしたりできる
- 本当に見るものに絞っていく機能がある
- まとめ
- AWS東京リージョンで動いていて速く始められる！
感想
ログ転送料がかからないのは、実はめっちゃ大事なんですよね。うれぴい。
Cloud SIEMかっこいいですね！私は知らなかったので詳細が知りたい！
Session3: 「Serverless applicationとセキュリティ ~Cognito編~ 」 株式会社 Flatt Security / 情報科学専門学校 齋藤徳秀(Azara)さん
- 好きなサービスはCognitoとLambda
- 会社では脆弱性診断やWeb Securityのラーニングサービスなどを展開している
- 今回はAWS 診断を事例としたクラウドセキュリティ。サーバーレス環境の不備や見落としがちな Cognito の穴による危険性の内容から
- 発表内容の要約
- 見落としがちなところを確認していきましょう
- 触れることはレッドチーム的なところ
- ロギングなどは触れない
- サーバーレスとしてmBaaSなどが出てきている
- AWS AmplifyやFirebaseなど
- Amplifyは中身は複数のサービスの組み合わせ
- 責任共有モデルによってある程度セキュリティは確保できる
- AWS側が責任を持ってくれる
- サーバーレスのサービスはよりAWSが見てくれる部分が大きい
- 責任範囲は狭まったけどセキュリティの脅威はまだまだたくさんある
- アプリケーションの脆弱性対策
- 利用するサービスの設定不備
- 今回はこっち
- Cognitoについてみる
- 今回のアプリケーション例
- つぶやきをするSNS
- 会員制・招待制
- 攻撃例
- 本来のアカウント作成フローからの逸脱
- まずは本来のフロー
- UserAがUserBを招待
- UserBは新規登録のため/registerを経由して新規登録
- Cognitoから初期パスワードが通知されて登録完了
- クローズドなアプリケーションで攻撃者がどうやって攻撃してくるか
- 直接CognitoのAPIを実行して新規登録を行う
- Cognitoで自己サインアップの許可がされている場合にこのような攻撃が可能になる
- 自己サインアップがなぜ可能であることがわかるか？
- Cognitoからのエラーレスポンスが異なるため
- 正常なら権限が無いと言われる
- エラー文に沿って各種属性を追加していくと最終的にユーザー追加できる
- 対策
- 「管理者のみにユーザーの作成を許可する」の設定をする
- 発展型の攻撃: Cognito ID Poolからの認証情報の取得
- 他にもCognitoで必須となっていない属性を検証したり、独自の認証機構を検討する
- 必要ではない属性の検証では次の攻撃で対処される可能性がある
- まずは本来のフロー
- Cognito User Poolにおけるユーザー属性の意図しない書き換え
- 標準属性はOpenID Connectに準拠した実装
- カスタム属性は任意に追加
- アプリクライアントの属性書き込みと読み込みの権限で許可する
- API GatewayのAuthorizerの設定を利用する
- custome:roleという値を利用するRoleとして利用していた場合
- Adminというものに属性を書き換えて権限を昇格することができた
- 対策
- アプリクライアントの必要最小限の権限が必要
- また認可に関連するものはおいておかない
- 本来のアカウント作成フローからの逸脱
- まとめ
- mBaaSの攻撃例と脅威を紹介
- アプリケーションの設計に合わせて適切に設定
感想
自己サインアップは悪用されやすいものの一つなので気をつけたいですね。ユーザーの属性の変更も気をつけたいですが、まずは設計ェ…
Session4:「AWSではじめるDNSSEC」 アマゾン ウェブ サービス ジャパン株式会社 セキュリティソリューションアーキテクト 中島 智広さん
- 昔からDNSに関わっている
- 今回のre:InventでRoute53がDNSSECをサポートした
- どういうものなのか？
- 使い方
- 留意事項を紹介
- DNS(Domain Name System)
- おさらい
- ブラウザでアクセスできるのもDNSのおかげ
- 2つの役割
- ネームサーバー
- 名前解決する
- 全世界に散らばっている
- フルサービスリゾルバー
- パソコンからアクセスするのはこっち
- ネームサーバー
- DNSから情報を取得することを名前解決という
- ゾーンに情報が乗っている
- DNSSEC以前のDNSやRoute53についてはblackbelt参照
- DNSSEC
- DNS Security Extensions
- セキュリティ拡張
- 暗号技術によりDNS応答の発信元認証と整合性検証を実現する技術
- ネームサーバーは応答を署名をつける
- フルサービスリゾルバーはその署名を検証する
- なぜ必要なのか？
- キャッシュ汚染攻撃・DNSスプーティングなどというものがメカニズム上起きる
- UDPが使われている
- TCPなら想定している相手を自明のものとできる
- UDPはそのパケットだけを見て本当の相手なのか確認しないといけない
- TXIDを付けて送って、レスポンスでもそれを見る
- UDPポート番号も含めて16bit * 16bitで合計32bitの情報を一致させると攻撃が成功する
- 僅かな時間の間に先に攻撃者が送れたら成功する
- 単純な確率計算では攻撃成功確率は非常に低い
- しかしこの成功確率を高める研究が行われてきた
- 2008年のKaminsky Attackが有名になった
- 2020年にもSAD DNSが話題になった
- それぞれ対策や緩和策も出ている
- 現時点では対処はできている
- しかし、DNSの仕組みで正規のものから返ってきた情報を確認する手段が無いので、検証する仕組みを考えた
- それがDNSSEC
- DNSSECの普及状況
- インターネットで利用可能になったのは2012年
- .govではすべてのドメインがDNSSECに対応
- 詳しくは日本政府組織のドメイン名などへ
- AWSにおけるDNSSEC利用方法
- フルサービスリゾルバー、ネームサーバーともにDNSSECをサポート
- マネージドサービスとしてDNSSEC運用をシンプルに
- 例えば鍵のロールオーバーや署名の更新を省力化
- Resolver
- VPC及びオンプレミスからの名前解決の際に署名の検証
- リゾルバーの設定
- Route53 > リゾルバー > VPCで有効化
- これだけ
- Hosted Zoneの設定
- パブリックホストゾーンで設定
- 3つのステップ
- KSK(キー署名キー)の作成
- ゾーンのDNSSEC署名有効化
- 信頼チェーンを確立(親ゾーンへのDSレコード登録)
- 例えばexample.comを利用していたら.comを管理しているところへ登録する必要がある
- KSK
- KMSのCMKを使う
- バージニア
- ゾーンのDNSSEC署名有効化
- KSKを指定して有効化
- 親ゾーンへの登録
- マネジメントコンソールから登録する情報を参照できる
- レジストラ(ドメインの登録事業者)によっては対応していないので、その場合はRoute53に移管することも検討してください
- DNSSECの有効化ではお金はかからない！
- KMSの利用費はかかります
- 留意事項
- 押さえるべきポイント
- 暗号技術の導入に伴うオペレーションの手間やコストの増加
- 鍵の管理には注意
- 不適切なオペレーションにより名前解決ができなくなる可能性あり
- マネージドサービスの利用にあたってもDNS/DNSSECそのものの理解が望ましい
- 暗号技術の導入に伴うオペレーションの手間やコストの増加
- キャッシュ時間を必ず考慮
- DNSSECのオペレーションでは鍵屋署名のTTLの考慮が重要
- 影響の大きい操作はマネジメントコンソールのウィザードにて注意喚起
- 厳密にはRFCなど参照
- 押さえるべきポイント
- まとめ
- DNSSECの有効化により名前解決のセキュリティが高まる
- すぐになにか危なくなるわけではないですが気にしたほうがいい
- 煩雑と言われるDNSSECの運用がよりシンプルにより身近に
- まずは関心を持ってやってみませんか？
- DNSSECの有効化により名前解決のセキュリティが高まる
感想
めちゃくちゃよくわかった！
とりあえず始めてみる、ができそうですね。やっていきまっしょい！
Session5: 「AWS VPC Traffic Mirroringを使ってFraud監視をスタート! 」 Splunk Services Japan 合同会社 横田 聡さん
- SplunkはSIEMとかログ分析のイメージがあるかもしれない
- 今日はちょっと聞き慣れないユースケースのFraud監視
- ちょうど2年前ぐらいにも登壇していただいた
- 情報セキュリティ10大脅威2021でも不正アクセスが増えている
- Splunkはあらゆるサービスに対する不正行為(Fraud)の監視に活用できる
- サービスログイン試行でチェックする
- もう一つはログイン後のなりすまし利用を確認する
- この2段階でチェックしていく
- 今回は時間の関係上前半について話す
- 分析の要
- アプリケーションログの出力できてますか？
- ブラウザ
- OS(Device)
- ステータス
- ソースIP
- ユーザーID
- 失敗しか記録していないことは多いのでは？
- 裏技としてSplunk Streamでhttp通信をキャプチャして必要な情報を抜ける
- アプリの改修が不要
- AWSではVPC Traffic mirroringを利用して活用できる
- SSLをどうやってモニターするの？
- ALBで終端していれば後段のNICを使える
- アプリケーションログの出力できてますか？
- デモ
- Splunk Stream
- メジャーな52種類のプロトコルに対応
- httpで33のフィールドを選択しながら取り込める
- 見積もりモードがあって、どれくらいの容量入るかチェックできる
- ログ容量超過しないか確認できる
- フィールドがなくても正規表現で抽出もできる
- 複数のアカウントを利用した認証試行や異なるソースIPで同じユーザー名の認証試行を確認する
- WAFログ
- AWS WAFのログを分析
- SQLインジェクションを成功させる
- formに入力したデータもログにある
- Splunk StreamとAWS WAFのログを結合する
- 実際のリクエストとログを一緒に確認
- Splunkのスマートフォンアプリ
- スマートフォンでも結構見やすい画面が提供されている
- Splunk Stream
- これから始めるFraud対策ハンズオンやります！
感想
不正アクセスの検知・分析・可視化も非常に大事ですね！
まずログを取って、(画面を作っていくことを)がんばりましょう！
さいごに
re:Invent 2020のアップデートもいろいろありました。Audit Managerはまだまだポテンシャルがあるので、事例とか出てきたら詳しく聞きたいですね！
ログはまず取ろう。そして見よう。
設定不備は気をつけよう。集合知を活用するのです…
DNSSEC使おうね！
やることいっぱいだぁ！
25
