.jpg)
忙しさにかまけてずっと書いていなかったRSA CONFERENCEレポート。ようやくまとまった時間がとれたのと、ホームページを更新したということもあって、手をつけてみることにします。2015年までは書いていたので、2016年から。
RSA CONFERENCEはこの年で25周年。ということは、1991年から始まったということですね。テーマは「Connect to protect」。攻撃者から防御するために、サイバーセキュリティの専門家は協力しなければならない、ということですね。
参加者は年々高齢化してきていて、興味の中心が技術では無くなってきているとは思っていましたが、それがだいぶ顕著になってきた感じがします。一緒に来ている日本の人と話をしたところ、「若い人たちはBlackhatとかに行っちゃうからねぇ」と言っていました。確かにそんな感じです。キーノートはまるで政治家のスピーチのようにも思えます。
How to Explain Cyber Security to the Board Using a Simple Metaphor: FIRE
経営陣にサイバーセキュリティについて説明するときに、防火対策を比喩に使うといいのではないか、という話。確かに、防火対策とサイバーセキュリティは似ているところが結構あるのに、比喩として使われることはあまり無い気がしますね。これは参考になります。YouTubeにも載っていたので、よろしければどうぞ。
From Cave Man to Business Man, the Evolution of the CISO to CIRO
SpeakerのJames Christiansen氏はGEで初めてCISOになった人だとのこと。
CISOが増えてきたのはここ3年ぐらいの話らしい。セキュリティは成熟するに従って、AD HOC、INFRASTRUCTURE BASED、COMPLIANCE BASED、THREAT BASED、INTELLIGENCE DRIVEN、RISK BASED、BUSINESS ALIGNEDと変わっていく。 効果の計測はOperationではなくPerformanceで行うべきである。 CISOはCEOと責任を共有する人。予算を取るためにCEOと戦う人ではない。それを勘違いしてはいけない。確かに。 3 lines of defenseは金融で使われている言葉。1st line of defenseは現場の人。2nd line of defenseは情報セキュリティ推進組織、3rd line of defenseは監査部門。 FAIR (Factor Analysis of Information Risk)というフレームワークは便利とのこと。GEの初代CISOが言うからいいんだろう。 プレゼンテーションスキルの向上にToastmastersが良いそうだ。こないだKevin Henryが来た時にも同じこと言っていた。 CISOはBoardとコミュニケーションできないといけない。そのためのガイダンスがNACD (National Association of Corporate Directors)から出ている。 法則1.サイバーセキュリティは会社の問題である。 法則2.サイバーリスクの法的意味を理解する 法則3.サイバーセキュリティ専門家から定期的に情報を得る 法則4.サイバーセキュリティリスク管理態勢を確立する 法則5.サイバーリスクに対する受容・回避・低減・移転のどの対応なのかを話す。
Demystifying Security Analytics: Data, Methods, Use Cases
Gartnerの人の話。データ分析をするにあたっては、何のデータを、どのような手法で、何の問題を解決するのかを明確にすることが重要。セキュリティ分析のサクセスファクターは、(1)データを分析するマインドセット、(2)データをExploreしたいという気持ち、(3)データを集積する仕組み、(4)データサイエンスの知識、(5)それを実行可能な人的資源。分析のインフラを構築するには、ツールを入れる、自分で構築する、コンサルタントを頼んで作ってもらうという選択肢がある。それぞれメリット、デメリットがある。 プロジェクトを成果に結びつけるために必要なことは、データから始めること。データをExploreして問題を解決する。他にも問題を見つけて解決することでスキルを磨く。知識を蓄積して分析能力を高める。手近な問題から手を付ける。問題を解決するために最適のデータを探す。異なるアルゴリズムを試し、データをチューニングする。学習し、次の問題をよりうまく解決する。他のデータと問題に目を向ける。 行動分析ツールで発見できることは以下のようなこと。 ・アカウント乗っ取り ・退職予定の社員が知的財産を盗むこと ・地理的な異常値検出 ・VPNの異常行動 ・カスタマーサービス担当者の個人情報漏洩 ・ソースコードの漏洩 ・情報漏洩しているシステムのふるまい ・利用終了したはずのデバイスの稼働 ・患者記録への不正アクセス ・特権アカウントの共用 ログ分析ツールを買ったとしてもある程度の構築とチューニングは必要になる。ベストプラクティスと呼べるようなものはまだ存在しない。 Gartnerなので、資料は結構良くまとまってます。小熊的にログ分析ツールの問題点は、分析した結果が正しいかどうかの検証が非常に難しいことだと思っています。アルゴリズムが間違っているから何も検出されないのか、本当にそういうログが無いのかを見極めるのが難しい。
My Life as Chief Security Officer at Google
GoogleでCSOをしている人の話。セキュリティの経験は20年。2年前にGoogleに入社。セキュリティのチームは600人。交替で24時間働いている。半分エンジニアリングで、半分はセキュリティレビュー。Googleのコードは20億行あるので、それを守らないといけない。
脆弱性を発見してもらうために昨年$2M外部に支払った。
GoogleはFIDOのセキュリティキーを使った二要素認証をサポートしていく。エストニアは全国民に二要素認証を導入した。
オフィスには朝7時にいく。まだほとんど人は来ていない。まずはヨーロッパのチームと連絡する。ヨーロッパはプライバシーを気にするので、それに関する話が多い。他にも、要員、新規プロジェクトの話、クラウドセキュリティなどの話をする。その後チームのミーティング、ビジネスリーダーとのミーティングなどをする。毎週チームとランチミーティング(Brown bag meeting)をしている。これはとても有益。ソーシャルイベントにも積極的に参加する。
もちろん、いろいろなことが起こる。みんなで対応して、うまくいけばそれを祝う。問題は週末に良く起こる。Signalsチームがシステムからのシグナルを監視している。
マザーボード、BIOS、データセンター自体も含めシステムは全部自分たちで作っているが、それでもSupply Chainは脆弱点である。
セキュリティの問題はクラウドが解決すると考えている。特に小さい会社はそう。大きな会社は自分でできるかもしれないが。中小の会社がGoogleレベルでセキュリティの体制を組めるとは思えない。
Innovation Sandboxではマシンラーニングを活用したものが多くてうれしかった。2020年にはIoTの世界でのセキュリティが解決されると信じているが、それにはAuthentication、Encryption、Updatingが鍵となる。
Google社員には20%のInnovation Timeがある。目の前の仕事だけで毎日を終えてほしくない。
セキュリティコミュニティをサポートしている。そうすると、フィードバックがあり、とても有益。
人が雇えないのが課題。インターンを受け入れ、育てることもしている。今年は100人雇用する予定。
クラウドコンピューティングモデルがやってくる。
データセンター間も暗号化している。プログラムはハッシュでチェックしている。
大きいプロジェクトも小さなプロジェクトも区別しない。小さなプロジェクトでも悪用されたら問題になるので、セキュリティレビューはしっかり行う。
They're People Not Data! The Human Side of Insider Cyberthreats
Rockwellの人事の人と、技術の人の話。内部脅威として、IP窃取だけでなく、破壊も含めた話。
会社を去る人の50%がIPを盗んだというSymantecの調査がある。別の調査では、IPを盗んだ内部者の50%は会社を辞める前1か月に実行している。辞める2か月前で70%、3か月にすると80%以上。よって、CERTが言う「90day window」には意味がある(出自がわからず)。
地球の反対側にある国のオフィスで、辞める日にポータブルドライブを持ってきてコピーしようとした話が紹介された。コピーしようとしたことが知られたと知ったその人は、外に出て石でハードディスクを破壊し、証拠を隠滅しようとした。その人が使っていたPCを調査して、持ち出そうとしていたことがわかった。同時に、前職からも数千の顧客データを持ってきていたことが判明した。
期限ぎりぎりのプロジェクトがテストフェーズまで来ていたが、突然VMが削除されたことがあった。復旧させるために3日を要した。プロジェクトにとって3日はとても大きかった。VMの削除はテスターがやったものだった。聞いてみると、スクリプトを間違えて実行したと言い張る。このような時にどう対応すべきか。間違えたならしょうがないと許すべきか。本人に聞いてみたところ、スクリプトの名前を言わない。削除されたタイミングをみると、手動でやったようにしか見えず、スクリプトらしきものは存在しない。マニュアルで消したことは間違いなかった。なので、そのテスターはチームから外した。
このようなプロジェクトをするにあたっては、まずパイロットを実行すると良い。誰でもいいので辞める人のログを見る。そうすれば、50:50の確率でIPを持って行っているログを発見できる。
Sabotage(破壊)の150以上のケースを調べたが、周りから「いい人」と言われている人は一人もいなかった。一方、IP窃取の場合は、そのような特徴は無い。良い人でも持っていく。
800のケースの調査に携わった、産業スパイはいなかった。これには驚いた。IP窃取は次の職場で使おうとしていただけで、情報を売ろうとしていた人はいなかった。
CyberSabotageは大きな問題である。一方で、USBにプレゼンテーションをダウンロードする必要がある営業もいる。そのようなFalse Positiveをどのようにして排除するかが問題。事前に兆候を検出することが重要である。
Using Large Scale Data to Provide Attacker Attribution for UnknownIoCs
DNSへのアクセスを分析してアタックを分析する話。BlackhatでIP Range Fingerprintingというコンセプトを発表した。IPアドレスのレンジに対して、どのようなポートが開いているか、ドメイン登録されているか、登録されている場合はその所有者は誰か、どこのプロバイダか、どのようなDNS問い合わせがあるか、といった情報をもとに種類が近いIPアドレスを見極め、悪用されている可能性を判断していく。それに基づいて、Malwareがホスティングされているサイト、フィッシングに使われているサイト、などに分類していく。
Data Breach Litigation: How to Avoid It and Be Better Prepared for Defense
弁護士によるセッション。
業界によって攻撃されるポイントが違う。旅行関係はPOSが攻撃され、金融はWebへの攻撃、DoS、カードのスキミング、ヘルスケアは物理的な窃盗、電力系はWebへの攻撃やクライムウェア、小売りは31%がPOSで33%がDoS、製造はサイバースパイとDoS、など。
1367件の漏洩が報告されているが、訴訟までいたったのは110件。一方、小売は報告の数としては12.5%だが、訴訟の中では60%を占める。
データ漏洩後の通知について、63%のユーザが、どのようにして個人情報を守るために何をすべきかのステップが書かれていないと言い、それを理由として、31%のユーザがその組織との関係を終わらせている。57%のユーザが信頼を無くしたと言っている。
公共系は物理的な盗難が多い。次にヘルスケア・金融系。
Security as a Service in a Financial Institution: Reality or Chimera?
BBVAはスペインで2つ目に大きな銀行。開発プロセスの中でどのようにセキュリティチェックをするかという話。セキュリティを担保する仕組みを「SECaaS」として説明。
コーディングを終えてJIRAチケットをあげてうちに帰ると、コードがチェックされ、翌朝来るとセキュリティに関するフィードバックが到着しているというような流れになっている。チェックは高度に自動化されているが、マニュアルプロセスも残っている。
100以上の開発プロジェクトが同時に動いている。それを個別にサポートするのは困難なので、APIを定義してプラットフォーム化した。将来的には、どのようにチェックをするか(「セキュリティパターン」と呼ぶ)を銀行間で共有したいと考えてLegalと話をしている。
Public/Privateクラウドをモニタリングしているので、このプロセスをバイパスしてDeployされたような場合は検出することができる。
以前は、セキュリティ部門はプロジェクトを遅延させる部隊と思われて嫌われていたが、今は開発プロセスに完全に組み込まれているのでそういうことが無い。
Cloud Security Essentials 2.0
一つのクラウドサービスですべてのサービスを使えればいいが、そうはいかず、複数のクラウドを使わなければならないのが現実。そうすると、攻撃者にとってAttack surfaceが増えて攻撃しやすい。
Cloud Hack Labを使って、システムの脆弱性を確認する。nmapでサービスをチェックし、MetasploitでJenkinsを乗っ取り、システム特権を取る様子がデモされた。
クラウド上のアプリケーションは脆弱性があると容易に管理権限をとられる可能性がある。クラウドオーケストレーションは操作をブラックボックス化するので危険。クラウドサービスを管理する権限はMFA必須。
クラウドのシステムが侵入された可能性があると気づいたら、すぐにインスタンスのスナップショットをとってForensicを始めることができる。
Security as code、「DevSecOps」の考え方が大事。
DevSecOps in Baby Steps
ここでも「Security as code」。セキュリティサービスをAPIとして提供する。また、それらのサービスを自動化する。
事前に学ぶこと、仕事をしながら学ぶこともあるが、実際にはリリースしてから学ぶことが一番多い。なので、Agileで頻繁にリリースをすることでスキルがあがっていく。また、脆弱性が残った状態を最小限にするためにも、頻繁なリリースが効果的である。そのためには、総合テストを自動化させる必要がある。
セキュリティの問題を発見してもリリースを止めてはいけない。最小権限の原則に従っていなかったのであれば、次のリリースまでに対応することにしてリリースを許すべき。
JAPAN NIGHT
この年から、日本からRSA CONFERENCEに参加している人に声をかけてパーティーをすることにしました。場所はUNION SQUARE近くのMURPHY'S PUB。前から時折行っていた店だったのですが、パーティーに使えそうな小部屋があり、聞いてみたところOKとのことで、その部屋を借りることに。みんな都合もあると思うので、開始は午後9時から、参加無料、予約不要、キャンセル自由、ベンダーディナーとかが終わってから一杯だけ飲みに来てもOK、というスタイルにしました。
それほど宣伝したわけでもないんですが、思ったよりも多くの人が来てくれ、会場はごった返しました。
この会を通じて、日本人同士で情報交換したり、新たなコネクションができたらいいと思っています。これからもお金が続く限り開催していきたいと思います。
小熊