top of page
検索

RSAC CONFERENCE 2025レポート

更新日：6月29日

　今年で参加20回目のRSA CONFERENCE。なんか、今年から名前がRSAC Conferenceになったのかな?

　今年のテーマは「Many Voices. - One Community.」。サイバーセキュリティの脅威と戦っていくためには、様々な視点を持った人達が一つのコミュニティで結束することが重要だ、ということのようです。

　開催地はいつものSan Francisco、Moscone Centerです。


RSAC CONFERENCE

　今年のRSAC CONFERENCEには、140カ国以上から44,000人(EXPOのみの参加者を含む)が参加しました。(うち、日本人は約1000人)

　今年で34年目。

　セッションへの応募は2800件を超え、そこから400のセッションが選ばれました。

　今年はAIの実装に関する多くの発表が行われました。

Ed Skoudis, President, SANS Technology Institute College

Heather Barnhart, DFIR Curriculum Lead and Sr. Director, SANS Institute and Cellebrite

Tim Conway, ICS Curriculum Lead, SANS Institute

Rob T Lee, Chief of Research & Head of Faculty, SANS Institute

Joshua Wright, Faculty Fellow and Senior Technical Director, SANS Institute and Counter Hack Innovations

SANSの人たちが、最近観測された5つの新しく、危険な攻撃手法について紹介するセッション。

  1. SSOで統合されたアカウントの乗っ取り。乗っ取るのはブラウザ。ブラウザを乗っ取ってもEDRは反応しない。

  2. インフラや製造業のICSやOTシステムに対する攻撃。攻撃者はシステムをより深く理解するようになり、システムを停止するレベルではなく、破壊することが可能となる。

  3. ログが取れていないこと。ちゃんとログを取っていないので、攻撃を受けたときにも、なぜ攻撃されたのかがわからず、同じ間違いを繰り返す。

  4. AIエージェントでサイバーキルチェーンの段階を進めていくと、人間より47倍速い、97%成功する。スピードは脅威である。メールやNWの情報を全部AIに喰わせて攻撃に使う。

  5. GDPRやCCPAのような法律がサイバーセキュリティに対する脅威である。法律に縛られて効果的な防御ができない。サイバーセキュリティにセーフハーバーが必要。

Nadir Izrael, CTO & Co-Founder, Armis

AIによって脅威が高まる理由は、攻撃が高度化するからではない。あまり技術を持っていなくて、以前は攻撃ができなかった人でも、AIの力を借りて攻撃できるようになってしまうからである。

DBIR Author, Verizon Business

  • Verizonが毎年発行しているDBIR (Data Breach Investigations Report) について。18年目。

  • 22,052件のインシデント、139カ国、12,195件のデータ漏洩が対象。

  • 攻撃のルートは、認証情報の悪用、フィッシング、脆弱性の悪用が代表的だが、年によってその割合は変化する。

  • SNSのパスワードと、リモートアクセスのパスワードを同じにしているケースは80%に達する。

  • 社有の端末以外で会社のパスワードが漏洩するケースが多く発見されている。

  • InfostealerマルウェアはCookieは盗み出す。Cokkieをリプライ攻撃することで、MFAをバイパスすることができる。

  • Initial Access Brokers(IAB)と呼ばれる人達は、盗んだIDとパスワードの組を売っている。どのような権限を持っているかという説明もつけて販売している。

侵入経路の変化

  • 認証情報の悪用、フィッシング、脆弱性の悪用が主な侵入経路だが、その割合は時間と共に変化する。







初期侵入経路

  • 初期侵入経路として販売されてるものとしては、リモートデスクトップが最多で20%程度、続いてVPNで10%程度。





Shaun McCullough, Instructor & Course Author, SANS Institute

  • MITRE ATT&CKのTechniquesについての説明(特にクラウド関係)。

  • それぞれのIDは https://attack.mitre.org/techniques/ で検索することで具体的な方法を知ることができる。

  • AWSに対する攻撃で使われる方法は T1078.004, T1526, T1485, T1578.002, T1535などである。管理者権限を乗っ取ったり、バックドアVMを作って攻撃される。

  • Kubernetesに対する攻撃は T1133, T1552, T1556, T1610, T1021.007など。不用意に開示された認証情報を使って攻撃される。

  • Azureに対する攻撃はT1110, T1078, T1136, T1484, T1199など。使っていないテナントが乗っ取られ、信頼関係がある本番環境を攻撃される。

  • AWSであれば、AWSのIAM Analyzerやサードパーティーのツールが役に立つ。

  • Azureであれば、"cross-tenant-access"を無効にすべき。

  • また、テナント間のアクセスやIAMを定期的に監査すべきである。

Code Spacesに対して行われた攻撃

  • MFAが適用されていない管理者アカウントが乗っ取られた

  • 本番環境のDBは守っていても、S3にあるバックアップデータが窃取された

  • 新たにバックドアVMを作られてしまうとログモニタリングしていても気づけない


TeslaのKubernetesに対する攻撃

  • K8Sの構成管理が不十分

  • コンテナのDeploy制御が不十分

  • 永続的な認証情報は危険






Azure環境に対する攻撃

  • 放置されたテストテナントが乗っ取られ、信頼関係を結んでいた本番環境が侵害されてしまう






Yonatan Khen, Security Research Team Lead, Hunters

  • クラウドシステムに対してどのような攻撃が行われているかの紹介。

  • 攻撃者は、APIキーを入手して、データを盗むと共に、仮想通貨マイニングをした。攻撃者は2週間も攻撃を続けた。セキュアコーディングが実現されていなかったので、次々とアクセスキーを奪われて広く攻撃された。

  • 攻撃は GetCallerIdentity から始まる。AKIAから始まるCredentialは永続的な物で、ASIAから始まるものは一時的なもの。

  • CredentialをスキャンするTrufflehogというツールがあり、攻撃者がよく使う。

  • 攻撃者はAWS Systems Manager Agent(SSM)を悪用してシェルコマンドを実行しようとする。CloudTrailに記録されるので、これを検出することはできるのだが、コマンドラインのような重要な情報が欠落してしまう。EDRで検出するようにすればよい。

  • 攻撃者はどのようなEC2インスタンスが動作しているかを調べようとするので、短い間に多数のEC2にアクセスがあったら怪しいと考えれば良い。

  • このように、攻撃者の手法を理解することで、それが実行されたときにアラートを発報するルールをしかけ、検出することができる。

  • 攻撃者の手法を理解し、攻撃パターンを検知するアラートをシステムに組み込むことで攻撃を早期に検知し、対応することができるようになる。

AWSに対する攻撃 - APIキーで侵入して仮想通貨マイニング

  • GitLabでAPIキーを入手、そのキーを使ってクラウド環境に侵入、インスタンス内にあるキーを発見して別のインスタンスを次々と侵害、気付かれるまでの2週間、仮想通貨マイニングを行って利益を得た。

AWSに対する攻撃 - GetCallerIdentityで認証情報を取得

  • Trufflehogなどを使って公開されているリポジトリからアクセスキーを抽出。その後GetCallerIdentity APIを叩いて認証情報を取得。その認証情報を使ってAWS環境全体を侵害する。




AWSに対する攻撃 - SSMでコマンド実行

  • AWSのSSMというサービスを使ってEC2でコマンドを実行させる。この実行ログはCloudTrailに記録されるが、「どのようなコマンドを実行したか」は「セキュリティ上の理由」で記録されないので、検出が困難。実際には、SSMが送ったコマンドはWindows環境ではPowershell、Unix環境ではbashで実行され、特定のコマンドラインが付与されるので、そこで検出する。

攻撃者は攻撃の主戦場をクラウドに移している

  • 他にも以下のような攻撃手法が観測されている

    • From IAM Creds to Console & Persistence Using Federation Identity

    • Enumeration of multiple EC2 Resources

    • Persistence Using Lambda Function

    • Suspicious Credential Gathering using IMDS

  • 攻撃者はクラウドに対する攻撃方法を日々開発している

  • 一方で防御側では、クラウドに対する攻撃にどのようなものがあるのかの情報が不足している

  • 攻撃方法を知った上で、検知・防御しなければならない

Christian Beckner, Vice President, Retail Technology & Cybersecurity, National Retail Federation

Evan Gaustad, Sr. Director Threat Detection, Fraud & Abuse, Target Corporation

小売業界における「Kill Chain」の体系化

  • どのような不正があり、どのような対策をとることができるかについて体系化している





Jeff Pollard, VP & Principal Analyst, Forrester

  • SECは、上場企業で重大な情報セキュリティ事故があった場合に公表するように要求している。

  • 一般的なフレームワークを適用している企業は32%。使っているフレームワークとしては、NIST-CSF (Cyber Security Framework)が88%、ISO/IEC27001が19%、CISが17%。(重複あり)

  • ベストプラクティスはまだ存在しない。みんなまだ探っているところ。

  • 2020年にSolarWindsは大規模なセキュリティ侵害を起こした。これに対してSECは、SolarWindsがセキュリティ対策をちゃんとしていたと公表していたのは虚偽であると訴訟を起こした。この訴訟は、どのような形でセキュリティ対策を公表すべきかの参考になる。

  • 侵害があったことを公表する際に、署名すべき人はCISOではなく、CEOであるべき。

  • 実際にインシデントが発生した際に、それが「重大」であるかどうかを判断する演習をしておくべき。演習は、経営陣がすべき。エンジニアがするものではない。

  • 会社の中にInformation Security Steering Committeeを作るべきである。テンプレがあるので、それを使えば良い。

  • NIST CSFに基づく成熟度モデルを採用すべき。その後、他のコンプライアンスフレームワークを検討する。

  • 米国企業ではNISTのCSF広く使われていることに驚いた。

Sandra Joyce, VP, Google Threat Intelligence, Google

  • AIは、Cyber Kill-Chainのすべてのフェーズで攻撃者に使われている。

  • Googleでは、攻撃者がどのようにGeminiを使っているか把握している。

  • 防御においても、Geminiを有効に活用することができる。例えば、マルウェア解析は27秒ですることができる。

David Kosorok, Director of Information Security Programs, Toast, Inc.

  • 新たにアプリケーションを開発する際に、どうやってセキュリティを組み込んでいくかの話。

  • Step1: Stakeholder Interviews→何が重要かを確認する

  • Step2: Brainstorm Initiatives→セキュリティ対策をマトリクスで提示して議論する

  • Step3: Assess Current State→セキュリティ対策を時間軸で示して、実装の状態を色分けして示す(最初から完璧を目指さない。時間の経過と共に対策を強化していく計画を提示する)。

  • Step4: Prioritize Initiatives→まずは簡単で効果が大きいものに着手し、次に、大変だが効果が大きいもの、最後に効果は大きくないが大変なものに着手する。

  • Step5: Measure, Own, Optimize→開発チームと協働する。調達プロセスに関与する。

  • セキュリティチームがいたが、開発部隊から信頼されていなかったケース。AppSecの人を開発チームの一員にして、リアルタイムでサポートできるようにした。また、セキュリティレビューをプロセスに組み込み、テストを自動化することで、リアルタイムのフィードバックができるようにした。特別にしつらえたセキュリティトレーニングを実施した。

  • 時代遅れのセキュリティプロセスが導入されていたケース。ビジネスオブジェクティブにアラインしたセキュリティストラテジーを作った。ポリシーを新しくしてSLDCに統合した。セキュリティ対策に対するPDCAプロセスを導入した。セキュリティ意識を高める教育を実施した。

  • セキュリティ対策のマトリクスで、すべて導入済、となっていたとしたら、既にそのマトリクスは陳腐化している。新しいセキュリティ対策は常に必要なはずで、何らかの対策は導入中のステータスであるはずである。

新サービスのセキュリティ実装

  • セキュリティ機能実装の中期計画を立てて実装を進めていく







Mike Nichols, Product Lead, Elastic Security

James Spiteri, Director of Product Management, Elastic

  • RAG(Retrieval augmented generation)はSIEMをAI拡張する。

  • OODA(Observe, Orient, Decide, Action)ループのすべてのステップにAIは適用できる。

  • アラートの情報をコンテキストと共にAIに入力することで、何が起こっているかをサマリとして提示してくれる。また、何故その結論に至ったかについて、順を追って説明してくれる。

  • 封じ込めのために何をすれば良いかも順を追って説明してくれる。

  • コンテキストを入力しておけば、抽象的な質問でも的確に答えてくれる。

  • FWのルールを入力し、どのようなegressトラフィックを許可しているかを質問すれば、その場所を表示させたりすることもできる。

  • JIRAとも連動していて、「この件に関するチケットはあるか」と聞くと、関連するChange Requestチケットを表示してくれる。

  • RAGの仕組みは、AIエンジンと独立しているので、AIのエンジンが新しくなったときに乗り換えることができる。

Retrieval Augmented Generation (検索拡張生成)

  • AIにコンテキスト情報を入力することで、より正確な回答を導き出す






SIEMの進化

  • SIEM 3.0では、AIを適用することでセキュリティ対応が自動化されていく






RAGのデモ

  • 複数のログに対して相関分析を行い、どのような攻撃がどのホストに対して行われたかを説明してくれる




  • Cloud Security Alliance (CSA)のSummitがカンファレス初日に開催された。

  • 会社がAIに適応しようとしたときに、阻害要因となる組織は人事部・法務部・購買部である。

  • AI人材を雇おうとするときに、会社の人事システムでは市場価格に見合った給与をオファーすることができないケースがある。そのような場合は、子会社を作り、その子会社で親会社の人事システムに縛られることなく十分な報酬を提示するようにすればよい。

  • 組織のデータを守るためには、まず、どのようなデータがあるかを把握しないといけない。いままではそれが障壁であった。AIを使えば、組織が持っているデータを自動的に分類することができる。現在のDLP(情報漏えい防止)ソリューションは誤検知が多い。ここにAIを適用すれば、劇的に誤検知を減少させることができる。

  • そもそも、使わないデータを持っていることがリスクである。AIを使って不要なデータを発見し、データをオフロード(オンラインからオフライン)すれば、情報漏洩リスクを低減させることができる。

  • ソフトウェア開発にAIを適用することについての議論が行われた。最近、マイクロソフトでは既に30%近くのコードをAIで生成しており、多くのソフトウェアエンジニアを解雇するという報道があった。

  • OpenAIの発表では、情報に対するアクセス権の付与をAIで行う事例が紹介された。社員が、会社のどのような情報にアクセスしたいかを自然言語で質問すると、その情報を社内から探し出し、会社のポリシーに基づいてその人がアクセスして良いかどうかを判断し、アクセスを許可して良いのであればアクセス権を付与する、という一連の流れをAIで実行する。

  • Metaの発表では、DLP、フィッシングの検出、Shellコマンドの実行が適切であるかどうかの確認等にAIが適用できるという説明があった。DLPはCSA Summitでも触れられており、早晩AIが適用される領域だと考えられる。

Ravi Kadiri, Senior Security Architect, Amazon Web Services

Satya Vajrapu, Senior Migrations Solutions Architect, Amazon Web Services

  • AWSの人のセッション。どのようにDevSecOpsにAIを組み込んでいくかという話。

  • Amazon Q Developerを使うと、コンテキストやインフラを理解した上で、自社のコーディングルールに沿った形でIaC(Infrastructure as a Code)コードを生成してくれる。

  • Amazon Security Hub、AWS Config、会社のコンプライアンス関連文書(ルール)、会社の監査記録をS3に保存し、コンテキストとしてAmazon Bedrock(AIエンジン)の入力とする。その上でユーザからプロンプトを与えると、会社のコンテキストを理解した出力を得ることができる。アウトプットのIaCは、Guardrailの仕組みでチェックする。いずれもBedrockで動作する。

Bedrockに会社のコンテキストを与えてIaCを作り出せば、AWSの環境を安全に保てるということになる。出力は人間がチェックする必要があるが、会社のルールや監査記録等も入力として、人間がチェックしなければならない部分を限りなく小さくしていく方向。

このセッションでは触れられていなかったが、構築する対象のシステムが、どのようなサービスを提供しているのか、また、どのような情報(個人情報、決済情報など)を扱っているかといった情報も入力すれば、より期待に近い出力が得られるようになると思われる。

また、この発表では、Bedrockをベースにフローを構築していたが、いずれこの一連の流れはAWSの標準機能としてビルトインされていくだろうと予想できる。

AIでIaCコードを生成

  • 関係性、クラウドの全体構造、既存のコード、ログ、アクセスパターン、Configを入力し、IaCを吐かせる。















コードのDeployにおけるリスク低減

  • それぞれの分野(コード分析、障害履歴突合、環境との整合性確認、依存関係確認)を担当するBedrockを複数連動させ、コードのDeployの際に必要なチェックをコンテキストベースで実行する




AWSの環境が適切かどうかを判断

  • AWS Security Hub、AWS Config、組織のコンプライアンス関連文書、組織の監査記録をBedrockの入力とし、不適切な設定を検出する






AIの入力・出力に対する「ガードレール」

  • Bedrockへの入力及び出力を、ポリシーを入力とした別のBedrockでチェックすることで、不適切な入力や出力が行われないようにする(ガードレール)。




Steve Wilson, Chief Product Officer, Exabeam

  • British Libraryの事案では、セキュリティソリューションは導入されていたが、アラートを見逃したことによってシステムのデータがすべて暗号化されてしまった。

  • コントラクターがIDとPWを$50ぐらいで売ってしまったケースでは、UEBAが導入されていたので怪しい行動を発見してシャットダウンさせることができた。しかし、現在では攻撃者がAIを使いはじめている。

  • 「2023 Exabeam State of Threat Detection, Investigation, and Response Report」というレポートがあり、これらの侵害についての情報が網羅されている。

  • AIですべてのログを分析すると遅すぎるので、それはML等で行い、MLが怪しいとしたログをAIにコンテキストと一緒に喰わせて、どの程度怪しいかを分析させる使い方が良い。

Machine LearningとAIは得意な領域が異なるので、うまく組み合わせることで効率的にセキュリティ対策を行う事ができるようになる。

British Libraryでの事案

  • セキュリティシステムが侵入を検出していたが、対応されなかった







MLとAIの連携

  • ログはMLでタイムラインに変換し、その上でセキュリティに関するコンテキスト共にAIに入力し、どのように対応すべきかを教えて貰う













Douglas McKee, Instructor, SANS, Executive Director Threat Research, SonicWall

Ismael Valenzuela, Senior Instructor & Author, VP Threat Research & Intelligence, SANS and Arctic Wolf

  • CCDC(Collegiate Cyber Defense Competitions)という、大学生がITインフラを攻撃から防御する大会がある(日本のHardeningに似ている)。

  • 「Hacking Defensively」とは、Thinking Red, Acting Blueのこと。つまり、攻撃方法を知った上で防御することが重要。

  • IoTデバイスのファームウェアは、共通のものが使われていることが多い。TrID(トライディー)という仕組みを使って調べることで、何のファームウェアかわかり、それをもとに脆弱性を調査することができるようになる。

  • 脆弱性の調査を自動化するために、n8nというAIワークフローのツールを使っている。

AIによる処理を自動化するためのサービスも出てきている。こういったツールをどんどん使って自動化していくことが重要だろう。

n8nを使ってAIをワークフロー化

  • 結論が得られるまで様々なツールを使って調査を繰り返す


George Kurtz, CEO & Founder, CrowdStrike

  • CISOはBoardメンバーになっていく。

  • 既に、CFOの50%はBoardのポジションを持っている。これは、エンロンやワールドコムの事案が発生してから変化した。CISOも同様になるべき。

  • CISOがボードメンバーになるためには、ボードメンバーとしてのスキルを身につける必要がある。

Microsoft Security - Corporate Vice President - Vasu Jakkal氏

「エージェントAIが日常的に多くのセキュリティオペレーションをサポートしていくようになる。人間に残るのはガバナンスである。」

→この写真、「AI」が「愛」を意味しているようで面白かった(笑)。

キーノートなどは既にYouTubeにアップロードされ、誰でも見ることができるようになっています。去年は、もっと多くのセッションがYouTubeにアップロードされたので、これから順次そうなっていくかもしれません。

Expo

エンディング

Japan Night

　今年もJapan Nightを開催しました。2016年に衣川さんと二人で「せっかく日本からたくさんの人がサンフランシスコに来ているんだから、知り合いになれたらいいよね」ということで開始し、今年で8回目。今年は他にもProofpointの増田さん、サイバーセキュリティクラウドの桐山さんにも出資してもらって4人で主催することになりました。

　事前に来ると連絡してくれた人は10人ぐらいだったのに、始まってみたらなんと250人もの人が参加。去年より大きな店に変更したので、どうにかなりましたが…みんな楽しんで貰えたでしょうか。

まとめ

  • 様々なセキュリティ対策にAIを活用することができる。

  • AIにコンテキスト(会社のルール、監査記録、システムの情報など)を入力することで、人間のチェックを最小限で済ませるような方向でAI化を加速していく。

  • マイクロソフトが言うとおり、最終的に人間に残されるのはガバナンスだけかもしれない。

Waymo

去年は惜しくも乗れなかったWaymo(自動運転タクシー)に今年は乗ることができました。

人間くささのある運転で気持ち悪く感じます。特に、交差点で信号が赤で止まっているとき、横の信号が赤になると、前の信号はまだ赤でもブレーキを解放して走り始める準備をするところにびっくりしました。

値段はLyftやUberよりちょっと高めです。

来年のRSAC CONFERENCEは3月23日～26日です。日本のほとんどの会社では今年度になってしまうので、同一年度で2回は厳しいかもしれませんが…　私はもう飛行機も宿も予約しちゃいました。また来年、サンフランシスコでお会いしましょう!!

 
 
 

Comments

Commenting on this post isn't available anymore. Contact the site owner for more info.
bottom of page