[レポート]SnowflakeからSnowstormへ:侵害と検知の対処 - CODE BLUE 2024 #codeblue_jp
こんにちは、臼田です。
みなさん、セキュリティ対策してますか?(挨拶
今回はCODE BLUE 2024で行われた以下のセッションのレポートです。
SnowflakeからSnowstormへ:侵害と検知の対処
最近、「Snowflakeキャンペーン」として知られる重大なセキュリティ・インシデントが発生し、165以上の顧客の機密データが漏えいした。
この侵害はクラウド・データ・プラットフォームにおける深刻な問題を浮き彫りにし、強固なセキュリティ対策の必要性を強調している。本講演では、Snowflakeキャンペーンを知った経緯、攻撃者がどのようにアクセスしたのか、どのように情報を流出させたのか、そしてこのような脅威を軽減するために組織が講じるべき対策について解説する。この講演では、この侵害の構造、クラウドやSaaSの可視性がインシデントの特定と対応においていかに重要であるか、そしてクラウド・セキュリティを強化するための実践的な検知戦略についての洞察を得ることができる。
特に、われわれはこの侵害について最初に公表した組織であり、サイバーセキュリティ・コミュニティにおける迅速で透明性のあるコミュニケーションの重要性を強調している。この講演では、新たに進化するSaaSセキュリティ脅威の現状を理解し、それに対抗する方法を模索しているセキュリティ専門家に向けて、実践可能な検知手法を提供する予定である。
Speakers: Roei Sherman
レポート
- 冒頭数分聞けなかったので途中から
- ユーザーのコンフィグの問題によって侵害が発生する
- ネイティブのクエリを実行すれば侵害されているか確認できる
- アクセスのログが確認できる
- 脅威アクターはログインしなくてもいい
- クラウドの時代は
- ゼロデイをする必要がない
- 単に認証情報が使えればいい
- 様々な認証情報がある
- ほとんどの組織がフィッシングに耐性を持つMFAもない
- トークンではMFAが無い場合もある
- コードリポジトリに保存されていたりする
- 必要以上の権限もある
- SaaSはクラウド
- 企業から購入して使うがサーバーをもっていない
- 起きていることはブラックボックス
- プロバイダーが提供するものに依存している
- 自分のせいかプロバイダーのせいかわからない
- Snowflakeでは認証強化を強制していなかった
- 企業はSaaSに移行していっている
- 支出額が増えている
- 元からSaaSのソリューションもたくさんある
- これはいいことではある
- クラウドだから悪いわけではない
- クラウドに移行する理由はまずコスト
- メンテナンスや人件費も減らせる
- リモートデータセンターへ派遣する必要がない
- 電源ユニットの管理なども必要ない
- スケールアップできる
- 可用性も理由の1つ
- 顧客が最善のエクスペリエンスを受けられる
- 素早くアクセスできる
- 拡張性も高い
- このスライドに書いていないこと
- Top5の理由にはセキュリティが書かれていない
- 侵害はクラウドに移行してきている
- 指数関数的にクラウドへの攻撃が増加している
- 企業がクラウドを利用していて侵害されたら、それはクラウド侵害?
- それとも具体的なターゲットがされていなければクラウド侵害ではない?
- 組織にとってそれは関係ない
- 自分たちの資産を守らないといけない
- 攻撃者は社内ネットワークに侵入してからクラウドへの経路を見つける場合も
- 攻撃者は小さい労力で経路を見つけたい
- Midnight Blizzard
- 国家的な攻撃
- MSがターゲット
- 最大規模の企業
- クラウドとしてもトップクラス
- それでも侵害が合った
- 攻撃者はパスワードスプレーした
- レガシーなアプリケーションを使った
- MFAが有効になっていない環境
- そこから本社へ入ることができた
- エグゼクティブのメールボックスも見れた
- これは最悪のシナリオ
- 政府が背景にいる攻撃者も特別な攻撃をしているわけではない
- MSが気づくまで何ヶ月もかかった
- それが問題
- C2通信もない
- クラウドのアクションだけ
- MSを批判するわけではない
- 検知が難しい
- クラウドとSaaSは特に
- オンプレならいろいろあるIDRとか
- いろんなものを使える
- クラウドよりはマシ
- クラウドではもっといいものが求められる
- コンテキストが求められる
- アクションはAdminができることと同じ
- 脅威アクターと区別するならコンテキストが必要
- ふるまいや異常か
- 場所は、回数は、繰り返されているか、会社で承認するか
- クラウドはベースラインがあるか?
- フォールス・ポジティブのアラームがでていた
- 燃え尽きにつながる
- しかしそのロジックを他でも使えるようにしなければいけない
- AWSで準備しても他のクラウドには展開できない
- 可視性の問題
- デフォルトではログがオフになっている
- Trailがあるという人もいる
- 他のログはどうか
- みんな有効化しない
- なぜならお金がかかるから
- お客様が自分自身を守る必要がある
- AIを使ってもセキュリティに活用していかない
- オブジェクトレベルのログは有効化していますか?
- 存在を知らない人も多い
- 問題は大きい
- セキュリティログが無いところが多い
- どれだけ維持するかも大事
- ログがなければ遡れない
- ライセンスの問題もある
- Slackはエンタープライズじゃないとログがない
- セキュリティログの扱いについてSaaSではライセンスを確認する必要がある
- デフォルトではログがオフになっている
- これを解決する場合にはDevOpsメンバーと相談
- セキュリティはDevOpsでやってくれない
- どの設定を入れないといけないと指示しないといけない
- 適切にやってくれているか確認もしないといけない
- ベンダーがものを売るときには何でももっていますという
- 実際にレッドチームは見てみる必要がある
- いろんな機密情報がある場合にOpsチームが覗けるか
- 契約に含まれているか
- 自分たちを守れるか
- 2つ目の問題
- マルウェア上のアイデンティティ
- アイデンティティがペリミタになる
- ハッシュは使えない
- アプリケーションのパーミッションを変えるなら
- 基本的なことからやっていく必要がある
- MFAを設定する
- これを展開できない組織はどうすればいいのか
- 振る舞いを捉える
- 日々何をしているのかベースラインを持つ
- プロアクティブな脅威インテリジェンスを利用する
- 見つけられればクレデンシャルのローテーションをしたり
- 自動化
- 侵害されているなら自動で対応する
- 誰かが入ってしまったら
- HRに入ってしまったら
- 疑わし事がわかる
- スキルセット
- 必要なものは常に変わる
- 全てにUIがある、ドキュメントがある
- PythonやCLIなどを使って自動化
- オンプレミスならサーバーの調査ができる
- S3バケットは入って調査はできない
- EDRなどは使えない
- トレーニング
- ハンズオン
- ギャップを確認する
- 脅威ハンティング
- モニタリング
- ニアリアルタイムで
- 誰がSaaSのセキュリティに責任を持つのか
- 開発者?情シス?クラウドセキュリティ?
- 何を設定する?
- 権限はある?
- CSPMはリスクを明らかにする
- 問題ではない
- 修正はDevOps
- 明確な決めが必要
- SecOpsに対して権限を与えるか
- 机上訓練が必要
- チームを編成して取り組む
- インシデントは週末や休暇に起きる
- 実際にMidnight Blezzerdのようなものが起きたらどうやって検知して対応するのかを考える
- 検知
- フォールス・ポジティブの割合を気にする人もいる
- SaaSがたくさんある
- 把握されていない
- ダウンロードする時アクセスは同じでも意図は違う
- これはどれだけ一般的なのか
- 1件1件ではなくフローで見る
- これまでアクセスが無かったのに新しいアクセスが発生する
- これからの攻撃
- 求めるのは簡単で価値が高い
- SaaSとクラウドは攻撃者にとって狙いやすい
- スレットインテリジェンス
- 実際この脅威はどれくらい深刻になるのか
- パスワードの間違いが2分で50回ならパスワード忘れじゃないだろう
- やっていくこと
- 来週: 視認性が必要
- 来月: 検知の戦略を考える
- あとはベースラインを作っていく
感想
クラウドに対しては攻撃者の攻撃コストが下がったり攻撃後のリターンが増えたりしている部分もあります。
構成要素が多いため複雑になっているところもありますが、正しく使えばオンプレミスと違い境界防御だけに頼らないより適切で強力なセキュリティ対策もできますし、発見的統制も組み合わせて対処していけますのでうまくシフトして組織のセキュリティを強化したいですね。
MFAは必ず使いましょう!