top of page

RSA CONFERENCE 2022レポート

更新日:1月7日

RSA CONFERENCE 2020の最中にサンフランシスコで緊急事態宣言が発せられ、2021年はオンライン開催。でも2022年には早々とリアル開催に復活。毎年やっているイベントで現地開催を取りやめたのが1年だけ、って実はすごいのではないだろうか。

と、実はこれを書いているのは既に2024年の1月。なかなかまとまった時間が取れずに後回しにしていましたが、ようやく重い腰があがりました。メモは取っていたので、思い出しながら書いていきます。


会場はいつもと同じくMOSCONE CENTER。今年のテーマは「TRANSFORM」。変化ですね。新たな働き方。新たなIT基盤。新たな脅威。新たな防御手段。いろいろ変化していますね。

 

First 90 Days In the CISO Chair: A Practitioner's Perspective

Dr. Chenxi Wang, General Partner, Rain Capital

Allison Miller, CISO and VP of Trust, Reddit

Olivia Rose, CISO, VP of IT & Security, Amplitude

Caleb Sima, Chief Security Officer, Robinhood


タイトルの通り、CISOポジションになって最初の90日間ですべきことについて。いつも私はパネルディスカッションは聞かないようにしているのだけど、これはタイトルがあまりにも興味深かったので参加。

  • スピーカーはRobinfood、Tust Reddit、Amplitudeという会社のCISO。みんな1年ちょっと前に就任した人達。そういえば、RSA ConferenceのCFPに応募してから実際のイベントまで半年以上あるわけだけど、その間に会社を辞めちゃう可能性もあるわけで、そうなったらどうするんだろう、と思ったり。

  • Robinhoodは話題にもなった、簡単に投資ができるアプリの会社。この会社はよく攻撃されるので、CISOになるのは大きなチャレンジだったとのこと。CISOになって、まず「First 90 days」という本を読んだらしい。会社に入ったら、まず仲間を見つけることが大事。プライバシー担当や法務担当は同じ考えを持っているので協業しやすい。

  • 自分がCISOになって最初にどういう人を雇ったか、という質問に対し、Amplitudeの人が「自分が辞めたときに自分のポジションになる人」と答えていた。Robinhoodの人は、高度に専門的な人よりも、いろいろなことができる人を雇った。Redditの人は、ものを作ったり、大きくしていくリーダー的役割の人を雇ったとのこと。

  • Robinhoodの人は、最初に30日、60日、90日、1年で実行することを明らかにした。最初の30日で2枚のスライドを作った。1枚目はチャレンジするエリアのトップ3。2枚目は脅威のトップ3。その後Updateしていった。

  • Amplitudeの人が、CISOになってすぐにあまり多くの質問をしたり、攻撃をしてはいけない、と言ったのに対し、Robinhoodの人が「嫌われていないなら、仕事をしてないのかもしれない」と返したのが印象的だった。

  • 「どういいうフレームワークを使ったか?」という質問に対し、Amplitudeの人はCMMI。Trust Reddidの人はNIST CSFと回答した。Robinhoodの人は、Boardと話す時はFrameworkより、ストーリーを大事にする、と回答。メインのストーリーは単純化して、Appendixをたくさんつけて、そちらに詳細を記載する方法を取った。

  • 以下会場からの質問と回答。

 質問「どうすればエンジニアがリーダーになってくれるのか」

 →回答「いろいろな人と話すように促すと良い。」

 質問「最初のBoardミーティングでは何をすれば良いか」

 →回答「計画を示し、期待値をコントロールする。課題も提示する。」

 質問「古い体質の会社に入ってしまったらどうするか」

 →回答「"Talk their language"が大事。相手の言葉で喋ることが大事。」

 質問「自分の部下は、外から採用すべきか、中の人をアサインすべきか」

 →回答「古い体質の会社なら、外から取った方が良い。」


CISOになって最初に雇う人が自分の後任、という話は面白かった。また、一番最初の仕事として、30日、60日、90日、1年でやることを決めること、そして、最初の30日でトップ3のスライドを作る、というのは参考になると思った。


 

Benefit from Cybersecurity Insurance: Taking Advantage of Insurer Panels

Alan Brill, Senior Managing Director & Institute Fellow, Kroll

"Insurer Panel"について。

  • 数年前、サイバー保険はまだ未開の状態だった。そこにランサムウェアがやってきて、多額の保険金支払いが発生した。そこで、保険会社はITセキュリティ専門家を雇って正しくリスク測定をするようにした。

  • 保険は契約である。契約には支払い条件がある。通常、インシデントを即座に保険会社に通知しないと保険金が支払われない。また、インシデントレスポンスを依頼する会社についても、契約業者が決まっていることが多く、他の業者に依頼すると払って貰えないことがある。「Panel」とは、この契約業者のこと。以下のような職種がある。

    • Attorneys (breach coach) (漏洩事案専門の弁護士)

    • Forensic Investigators

    • Crisis Communications (公表するかどうか、など)

    • E-Discovery Firms

    • Notification Specialists (被害者への通知、コールセンターの設置)

    • Ransom Negotiators (身代金の支払い、連邦法に違反しないような対応)

    • Recovery Specialists

    • PCI PFIs (PCI DSS関連インシデントの調査を行う)

    • Pre-Breach Assessors (インシデントが起きていない状態で企業のリスクを評価する)

    • Table-Top Exercise Vendors (机上訓練やリスク評価を有償だが比較的安価に提供したりしている)

  • インシデントが起きていなくても、パネルの業者と準備について話をすることもできる。

  • 経営陣は、侵害があったという確かな証拠が無い限り報告したがらないので気をつける必要がある。

 

アメリカの健康保険は、保険が適用される医者が決められている印象があるが、サイバー保険でも同様の仕組みがあるということらしい。日本でも同様なのだろうか。漏洩があったときに公表するかどうかを考える専門家や、漏洩の被害者への通知についての専門家がいるということは知らなかった。漏洩の発生を保険会社に即座に通知する必要がある、ということは、インシデントレスポンスマニュアルにサイバー保険の保険会社への通知を手順として入れておく必要があるということになる。


 

How to Win with Cyber Insurance & Sidestep the 7 Biggest Pitfalls

Cynthia James, Enterprise Security Executive , Microsoft

サイバー保険に入っていたのに払って貰えないケースについて。

  • 5000社の中規模企業を対象にした統計では、95%の保険金が支払われた。70%はビジネス回復コストもカバーされた。一方で、サポート切れのソフトウェアが原因の漏洩には保険金は払わない、と言われたこともある。

  • サイバー保険に入るときに確認する17のポイントというものがある。

  • 以下DeepLによる邦訳。

1. 定期的にバックアップを行い、安全なオフサイトに保管していますか?

2. 二要素認証を使用して、すべてのコンピュータ・システムへのリモート・アクセスを制限していますか?

3. ネットワーク上にどれだけの個人情報がありますか?

4. 従業員に対して定期的な不正防止トレーニングを実施していますか?

5. 口座番号、電話番号、連絡先情報など、銀行口座に関する情報を変更する際の確認プロセスを整備していますか?

6. Office 365を使用していますか?

7. 社外デバイスのウェブアプリケーションからメールにアクセスできますか?

8. 受信メールのSPFチェックを厳格に実施していますか?

9. バックアップは暗号化され、オフラインまたは専門のクラウドサービスを使用してネットワークから分離されていますか?

10. ネットワークでエンドポイントプロテクションを使用していますか?ブランドは?

11. 重要で深刻度の高いパッチのインストールにはどれくらいの時間がかかりますか?

12. SOCは導入されていますか?

13. ランサムウェア攻撃を検知・防止するために、どのような対策を講じていますか?

14. サーバー、ラップトップ、デスクトップ、管理下のモバイル・デバイスに渡って、厳格なベースライン構成を導入していますか?

15. ローカル管理者権限をどのように実装していますか?

16. ユーザにパスワード・マネージャ・ソフトウェアを提供していますか?

17. サポートが終了したハードウェアやシステムは、他のネットワークから分離されていますか?

  • サイバー保険に入っていても、保険金を払って貰えない理由のトップ5は以下の通り。

1. 前回と同じ侵害が発生した

2. 支払額が上限に達した

3. 侵害を保険会社に通知するのが遅れた (通知後に発生した被害額だけ支払われる事がある)

4. 契約業者(パネル)を紹介したのに使わなかった

5. 申告したセキュリティ実施状況が不正確だった

  • また、サイバー保険を契約する際の7つの落とし穴は以下の通り。

1. 補償範囲が不適切(不足)

2. 明確に補償範囲に含まれていないものは対象外となる

3. やりとりは文書化すること(口頭はNG)

4. セキュリティの状況をきちんと把握せずに報告すること

5. 保険会社への報告が多すぎる、また、逆に少なすぎる

6. 保険契約をちゃんと見ないで契約してしまう

7. 必要な被害シナリオが網羅されていない


昔聞いたサイバー保険に関するセッションでも、サポート切れのソフトウェアは支払い対象外になる、という話を聞いた。サポート切れダメ、絶対。


 

Linked-Out: Security Principles to Break Software Supply Chain Attacks

Siddhesh Yawalkar, Engineering Manager, Intuit

ソフトウェアのサプライチェーンを狙った攻撃について。日本で言えば東映アニメ事案。

  • 企業のセキュリティ対策が向上し、Weakest Linkがソフトウェアのサプライチェーンになってきた。GitHubに不正アクセスし、不正コードを混ぜるなどの攻撃。

  • Fortune1000の企業では、1企業あたり約110のソフトウェアベンダを利用している。

  • British Airwaysのケース。WebサイトのJavaScriptが狙われた。Webページが外部からロードするJavaScriptのうち一つでも攻撃が成功すれば、不正コードを紛れ込ませることができる。対策には、CSPを使うこと、読み込むコードのハッシュをチェックすること、iFrame sandboxingがある。

  • Exchange Serverのケース。SSRF脆弱性を使った。全部ゼロデイ脆弱性。ゼロデイだが、WAFはSSRFとして検出できるはず。

  • Azure DevOpsサーバのケース。BuildAgentがBuildServerにソースコードを送るプロトコルがデフォルトのHTTPで、Man in the middle攻撃が行われた。

  • Log4jもサプライチェーン攻撃である。


会場からも質問がでていたけど、SSRFのケースはサプライチェーン攻撃とは言えないのではないか。他にも、Log4jの脆弱性は攻撃によって作られたものではないので、これもサプライチェーン攻撃と言ってしまうと範囲が広くなりすぎてしまうのではないか。

ただ、British Airwaysのケースは確かにサプライチェーン攻撃のわかりやすい事例で、CSPが対策になるということも理解できた。Webサイトのチェックをするサービスで、CSPが定義されていないときに大きくスコアが落ちることに違和感を感じていたんだけど、これが理由ならしょうがないかな。

企業のセキュリティ対策が向上したことでソフトウェアのサプライチェーンが狙われるようになったという流れは興味深い。


 

What Matters Most

Bruce Schneier, Security Technologist, Researcher, and Lecturer, Harvard Kennedy School

有名なBruce Schneierのセッション。

  • 1年前にタイトルを決めないといけなかったので、タイトルは適当につけたとのこと。

  • AIがHackするようになったときの本を書いて4日前に出版社に送った。1月に発売される。

  • 数年前、コンピュータ同士のハッキング大会が行われた。その後もう開催していないが、中国は軍が継続してやっている。その後、どのように進化したかはわからない。

  • AIによる攻撃には、攻撃者がAIを使って攻撃するケースと、意図せずにAIが攻撃してしまうケースがある。後者の方が怖い。今のAIは判断に至った過程を説明できない。判断をした理由を説明できるAIは開発途中である。AI囲碁では、人間が想像できないような手を打つ。これと同じように、人間が想像できないようなハッキングの方法を見つけるかもしれない。

  • AIはコンテキストを読まない。触った物をすべて金に変えてしまう王様の話があるが、まさにそのような対応をするのがAI。AIにコンテキストを教えたりすることでこれを解決するようなことが検討されている。

  • 新しいシステムはAIの攻撃にも耐えられるようになっているだろうが、古いシステムは危険。

  • カジノの水槽のモニタリングシステムからデータを抜き出した例が紹介された


攻撃者は当然のようにAIを使ってくるので、防御側もAIを使うこなすのが大事、ということなんだろう。AIで脆弱性を発見したり、AIを使ったペネトレーションテストを実施したり。


 

Inclusivity: The Future of Security is Now

Vasu Jakkal, Corporate Vice President, Microsoft Security Business

マイクロソフトのセッション。

  • フィッシング攻撃にやられて情報がとられるまで1時間42分、ラテラルムーブメントまで1時間12分しかかからない。つまり、守るには2時間以内に封じ込めをしないといけないということ。普通にやっていたら無理。Cloud+AI+MLで対応する必要がある。

  • AIを攻撃の検出に使うことは既に行われている。これから、キルチェーンも理解するようになる。そして将来的には、AIが説明できるようにならないといけない。

  • SOCも、AIを使うことで多くの組織を同時に守れるようになる。

  • セキュリティのポジションの1/3は埋められていない。セキュリティをやっている人のうち女性は24%、有色人種は20%にすぎない。もっと増える必要がある。


Bruce Shneierの内容と結構かぶっているところがあった。DEI(Diversity Equity Inclusive)の話になるとは思わなかった…。


 

Security Automation for DevOps at the Scale of Dell: A Real-Life Case Study

Sam Sehgal, Technical Staff, Product Security Engineering, Dell Technologies

DELLでDevSecOpsを導入したケーススタディ。

  • DELLには様々なハードウェアがある。ECサイトもある。内部システムもたくさんある。リリースのタイミング、アーキテクチャの新旧、リスクの高低など、さまざま。

  • セキュリティの推進に関しても様々な課題があった。セキュリティチームのフィードバックが遅い、セキュリティスキャンのレポートがPDFで使いづらい、誤検知が多い、など。

  • 新たなDevSecOpsの仕組みは、現状のSDL基盤の上に構築することとした。そのために3つのオプションを用意した。(1)SDLエンジニアが実行する、(2)SDLセキュリティ専門家がリードする、(3)APIで接続する。アプリの種類によって適・不適がある。

  • 導入に際しては、開発チームとセキュリティチームが対決するような形にならないようにした。Joint Scrum Teamとし、同じBacklogを使った。但し、そうすると、セキュリティの人が足りないという問題が出てきた。

  • PowerBIで状況をダッシュボード化した。

  • 最終的には、セキュリティのフィードバックは5分以内に行われるようになった。90%以上のBUが利用している。1000以上のアプリをみている。

  • 導入の最初の30日間にすべきことは、フィードバック時間の目標値を定める、など。3ヶ月から6ヶ月では、パイロットを実施する。1年以内に状況を評価する。

  • リスク受容もワークフローで対応する。リスク受容した記録は一カ所にまとめられている。

  • 自分のチームは数人。各プラットフォームに担当者がいる。そこと一緒に動いている。


DELLの規模でDevSecOpsを集中管理できているのはびっくりした。日本だと大きな会社のシステムは全部バラバラなんじゃないかな…。


 

Dissecting The Ransomware Kill Chain: Why Companies Need It

Kurtis Minder, CEO, GroupSense

Bryce Webster-Jacobsen, Director of Intelligence Operations, GroupSense

ランサムウェア想定インシデントレスポンスのPlaybookを作っておこうね、という話。

  • いろんな内外の組織と連携する必要がある。Playbookは以下のような項目を含むべき。

– List of Key Stakeholders and Responsibilities

– Detection, Assessment, and Containment Plans and Checklists

– Communications Plan and Checklist – Which Should Include Incident

Communications Statements

– Response Plans

– Incident Priority and Impact Classification

– Payment Decision Making Process and Extortion Payment Approvals

– Ransomware Event Cost Sheet

  • 会場からの「サイバー保険会社は、身代金を払いたがらないのではないか」という質問に対し、「保険会社は、身代金と復旧費用すべてを想定し、一番安い方法を選ぼうとする。多くの場合、復旧費用より身代金の方が安い」と回答。


確かに、保険会社の立場からすると、支出を抑えるという観点からは身代金を払いたくなるモチベーションがあるということか。Playbookについては、まぁ、一般的な感じか。


 

Staying Secure in Today’s High-stakes World

Fernando Madureira, Global CISO, Cosan

Chris McCurdy, General Manager and Vice President of Worldwide IBM Security Services, IBM Security

Charles Tango, Chief Information Security Officer, Sysco

IBMのキーノート。

  • ランサムウェアは大きな問題。以前は金融業がやられていたが、今は製造業がやられている。

  • 「Safety Moment」という言葉がある。工場で、事故が起きていない日数を表示したりする。これに対応する「Security Moment」という考え方を導入したらどうか。

  • ここでインフラ系の会社であるCosanとCyscoのCISOが登場。

  • Cosanでは、InfoSecチーム、Defenseチームを作り、グループ企業を見ている。M&Aやベンダーマネジメントの話。ベンダのセキュリティ改善を支援する人がいる。セキュリティのプロセスを提供したりしている。

  • Syscoの人は、CISOに一番必要なのは人脈だ、と。OTデバイス管理のアウトソースを始めている。


Cosanに、ベンダのセキュリティ向上を支援する人がいる、というのにはびっくりした。

Syscoが、CISOに一番必要なのは人脈だ、と言い切っていたことに共感した。特にOT系の人はそうだと思う。


 

The Five Most Dangerous New Attack Techniques

Rob T. Lee, Chief Curriculum Director and Faculty Lead, SANS Institute

Heather Mahalik, DFIR Curriculum Lead, SANS Institute, Senior Director of Digital Intelligence, Cellebrite

Katie Nickels, Certified Instructor, SANS Institute, Director of Intelligence, Red Canary

Ed Skoudis, President, SANS Technology Institute College

Johannes Ullrich, Dean of Research, SANS Technology Institute College

新しい脅威について教えてくれる。

  • Katie Nickels氏 (SANS講師)

    • Living off the Cloud - ngrokを悪用する。

    • MFA bypass - MFAサーバでなく、その根っこにあるADサーバにアクセスする MFAサーバが落ちていると、2要素目の認証なしでログインを許可する挙動のシステムもある。そのような場合、MFAサーバを攻撃すればMFAバイパスできる。

  • Johannes Ullrich氏 (インシデントハンドラー)

    • MFAでTokenを無くしたときの問題がある。バックアップを作れば、バックアップが脆弱性になる。このバックアップを攻撃する。

    • Agentに対する攻撃。

  • Heather Mahalik氏

    • 昔からある技術でも使える物は使う。

    • PegasusというMalware。ユーザのクリックがなくてもiOSやAndroidに侵入できる。

    • Wormはまだ活動している。攻撃者はこういう古いテクノロジーを使う。

  • Rob T. Lee氏

    • ウクライナはGIS ARTAを導入した。


ちょっと今年のはぱっとしなかったな…。ngrokやPegasusぐらいか。


 

Can the Workforce Shortage Be Fixed?

Clar Rosso, Chief Executive Officer , (ISC)2

(ISC)2 CEOのClarによるセッション。

  • Cybersecurity workforce studyの話。

  • サイバーセキュリティ人材が足りないときに、IT業界からしか人を採ろうとしなかったら採れない。経歴のDiversityも重要。仕事をする中でITスキルをつけてもらうのでもいい。

  • この業界に入ってくる人のための新しい資格。Certified in Cybersecurity。

  • 外から完成されたサイバーセキュリティ専門家を連れてくるのでは無く、社内に適性がある人を探してトレーニングしたほうがいいのではないか。

  • エントリーレベルの人にさせると良い仕事: 1年以下ならアラートやイベントのモニタリング、プロセスや手順の文書化、スクリプトの作成、インシデント対応、レポート作成。3年以下ならInformation Assurance(情報保証…認証やプライバシー)、バックアップ・リカバリ・事業継続、侵入検知、暗号、ペネトレーションテスト。エントリーレベルの人にはメンター制度が重要。


セキュリティ人材不足を解消するために、セキュリティ専門家だけを雇うのではなく、適性がある人を雇って育成する、というのはアリだと思う。時間がかかるかもしれないけど、今は良い人を雇うにも時間がかかるし。


 

Hacking Exposed: Next-Generation Tactics, Techniques and Procedures

George Kurtz, Chief Executive Officer & Co-Founder, CrowdStrike

Michael Sentonas, President, CrowdStrike

Crowdstrikeのセッション。参加者多い。

  • Kubernetesが普及している。コンテナに関するHackingがある。

  • Container Escape。コンテナの範囲を超えて、OSの領域にアクセスする。CRI-Oというランタイムがあるが、ここに脆弱性があった。CRI-Oがsysctlをサポートしているが、引数のチェックが甘かった。

  • kernel.core_patternは、コンテナがクラッシュしたときにホストOSにシグナルを送ってコアダンプを作るが、このコアダンプを作るスクリプトを改ざんして、ホストOSに実行させる。

  • Container Escapeのデモ。

  • 対策: コンテナやホストのモニタリング、sysctlのモニタリング、コンテナの定期スキャン、コンテナイメージのスキャン、"Rogue Container"の検出

  • 根本策はCRI-Oを新しいバージョンに置き換えること。


コンテナなら隔離されているから3rd partyのものを使っても安心というわけではないということ。そのコンテナを作成した3rd partyに悪意がなくても、攻撃されてContainer Escapeする攻撃コードが組み込まれている可能性がある。更に言えば、すべて内製のContainerだったとしても、GitHubが乗っ取られるという可能性もある…。


 

The Marie Kondo Approach to Security

Bob Lord, Former Chief Security Officer, CISA

Dr. Hugh Thompson, Executive Chairman, RSAC, Program Committee Chair, RSA Conference

「人生がときめく片づけの魔法」で有名なこんまりメソッドでセキュリティを考える。相戸さんが数年前にやったネタと同じ。

  • セキュリティコントロールは捨てることができない。SPAMフィルタはずいぶん前からあるが、未だにSPAMメールは届く。

  • 映画のMoneyBallに、予算が無いチームがどうやって勝つかを考えるシーンがある。この考え方はセキュリティにも適用できる。お金が無い組織は、高いソリューションを使わなくても、安いソリューションでも十分機能させることができるはず。

  • SSO Taxという言葉がある。SSOはコーポーレートレベルで管理されていて、単価が高い。また、各事業部からはIDも25単位でしか貰えなかったりして使いづらい。


Hugh Thompsonは面白くしようとしてるんだけど、Bob Lordが真面目すぎて面白くならない。


 

まとめ

  • 中国からの参加者はいなかったこともあり、人数は少なめだった。

  • サイバー保険が普及している印象を受けた。サイバー保険でちゃんと補償してもらえるようなセキュリティの仕組みを構築する、という好循環が確立しつつあるような印象を受けた。

  • サプライチェーンセキュリティを実現するために、ベンダのセキュリティを改善するための人員を配置しているのには驚いた。ベンダに費用負担は求めないのだろうか…。


 

番外編1 (会場でのワクチンチェック)

今年のRSA CONFERENCEは、コロナ明け直後ということもあり、アプリでワクチン接種済であることを確認してから入場、というシステムが導入されていました。書類をアプリで送れば事前に確認ができるので特に混乱はありませんでした。

 

番外編2 (メジャーリーグ)

今年もOakland Athleticsの球場までMLBを観戦に。対するはRed Sox。澤村が出てきました。


 

番外編3 (PCRテスト)

帰国前にPCRテストを受ける必要があり、ネットで予約して検査会場へ。$129。

急ごしらえのテストセンター。

ゲートは閉まっていて、窓に「ノックしたら開けるよ」ってポストイットで貼ってある。

まるで何かの密売所のよう。


 

番外編4 (ピーナッツバターウイスキー)

ピーナッツバターから作ったウイスキー。

とても甘かったです。

bottom of page