.jpg)
RSA CONFERENCE 2018のテーマは「NOW MATTERS」。今年の参加者は、EXPO参加も含めると5万人だそうです。確か去年が4万人だから、更に増えたって感じですね…。キーノートはラップでした。
GDPR Essentials
初日はGDPR Essentialsという丸一日のセッションに参加。
ヨーロッパの人はGDPR擁護、アメリカの人はGDPR反対と、非常に白黒はっきりした主張が行われた。
最初はGDPRの概要をイタリアが。GDPRは2年前からアナウンスしていた。IT技術の変化のスピードを考えれば、十分な時間があったはずである、と。 「GDPRを守れない会社は市場から排除されてしまうべきなのか?」という会場からの質問に対して「GDPRを守れない会社が排除されるのではない。プライバシーを守れない会社が排除されるのである。」とかっこつけて回答。イタリア人はかっこいいなぁ。
Get Up Speed On the GDPR, Fast
2020年には40%の会社がGDPR違反の状態と考えられるが、2023にはほぼゼロになるだろう、とGartnerは予測している。GDPR準拠に関する課題には以下のようなものがある。 ・業務プロセスの変更 ・漏洩の検知と対応 ・導入のコスト ・インフラの変更 ・顧客からの信頼損失、業務効率の低下 ・ルールの複雑化 ・機密データの漏洩・データの保護 ・罰金 GPDRはプロセスである。入れるだけでGDPR対応になるソリューションは存在しない。 漏洩が起き、GDPRに対応していることを説明できなかったら罰金となる。漏洩しても、GDPR対応していれば罰金にならない。そのためにも、GDPRに対応するプロセスは記録を取っておくことが重要である(耐監査性があること)。 「企業の場所は関係ないか?」という質問に対し、「関係する。EU内にいる企業がGDPR違反をした時のリスクの方が大きい。」と回答。 「漏洩して、Forensicツールが無くて何が漏れかわからない場合はどうするべきか?」という質問には、「とりあえず報告すべき。」と回答。つまり、漏洩したものが何かわかるような仕組みが無いと、全部報告しないといけなくなっちゃうということか…。 Will the GDPR and related rules prove a competitive differentiator for Europe?
アメリカ人の教授によるGDPR批判。 ヨーロッパで聞いたところ、68%が会社の自分の情報を消したいと思う、と答えた。一方、アメリカで聞いたところ、11%の人が他の組織と共有することは嫌だと答えた。Jane Winnさんは「アメリカ人とヨーロッパの人は違う。アメリカ人は、自分の行動に関する情報を提供して、自分にあったサービスを受けることを好む。ヨーロッパは違う。米国では、失敗が許容される。それによってイノベーションが生まれるのであれば、規制を厳しくしてイノベーションをおさえてしまうのは国としていいことではない。テクノロジーがどうなるかわからないのだから、政府が規制するのではなく、市場の自主規制を期待すべきである。ヨーロッパにいるアメリカの企業がターゲットになるのではないかと危惧している。」と。
これに対し、ヨーロッパの教授は「テスラ、Facebookを見てみろ。自己規制なんて無理なんだ。多くのデータをつなげると想像できないようなリスクが生まれる。」と反論。 3年後どうなっていると思いますか、という質問に対して、Janeは「そもそも労働法が厳しいEUで、更にGDPRなんてものをかぶせたら、起業しづらく、失業率は高いままだろう。」と。アメリカの会社が自主的に規制しているように見えない、という質問に対して、アメリカでは、個人情報を守る自主規制を作るための組織を作るべきだ、と。 Deep Dive On Customer Profiling Under GDPR: What's Allowed, What's Forbidden, and What's Unclear
GDPRでもまだ不明確な点について。
プロファイリングはGDPRの規制の対象となっている。プロファイリングは様々な業界で広く使われている。マーケティングでセグメンテーションするのもプロファイリング。明示的に禁止されている事柄は無いが、例えば、GDPRでは、マーケティングの目的で子供のプロファイリングをすることがグレー領域。 ADM: Automated Decision Makingとは、プロファイリングした後、その結果に基づいて自動的に重大なアクション(雇用に影響する、診療の機会を失うなど)が行われることを言う。 統計データに基づいてカテゴライズすることはプロファイリングではない。 「メディカルな情報に基づくターゲティング広告の例を教えてほしい」との質問に対し、「ギャンブル狂の人に高い利率のローン広告を出すことはまずいようなきもするが、まだ議論しているところである。」と回答。 Top 10 GDPR Pitfalls To Avoid
Speakerが顔に傷。昨晩、バーテンダーに殴られたらしい。なんで?? 罰金は、情報漏洩が起きたか、もしくは、データ所有者からの苦情がトリガーとなる。漏洩だけではないところに注意。 DPAへの72時間以内の報告は、リスクがある場合のみ。但し、漏洩が発生した時に、「個人情報が含まれていない」ことを確認するのは難しい。 Controllerは、データの処理について定めたときと、実際に処理を行うときの両方で関与しなければならない。 何をしてもいい、だれに渡してもいい、という同意はダメ。 処理を委託する場合でも、コントローラーが責任を持つ必要がある。 ネットワークセキュリティや情報セキュリティのためにログを収集するようなことは、正当な目的があると解釈される。この場合は同意を得る必要がない。但し、文書化しておくことが必要。(Recital 49) 「忘れられる権利」はセキュリティログには適用されない。 GDPRではプロセスであるとともに、文化である。 Practical Guide To GDPR Breach Notification And Security Requirements
データ漏洩には、機密性・可用性・完全性の喪失の種類がある。 WP29にて、個人情報が漏洩したと思われる場合は、コントローラーが対応すると書いてある。米国の調査では、発生から発見に13.21日、発見から通知まで29.1日かかっている。これから、72時間がいかに厳しいかわかる。72時間を超えた場合は、その理由を説明する必要がある。通知はフェーズ毎(事実が判明するごと)に行う。 EUのControllerはUSのCovered Entityに相当する。ProcessorはBusiness Associatesに相当する。 タイムリーにインシデントを発見してエスカレーションする仕組みを構築するべき。また、一貫性のあるアセスメントを行うことも重要。 「ほかのユーザの名前と決済情報を見ることができるバグをWebサイトに発見した。それだけで報告を行うべきか? (実際に漏洩したログが無いときに?)」という質問については、「インシデントを事前にリスクアセスメントしておき、報告するかどうかを予め決めておく。」ことが大事と回答。 GDPR: The Future of International Regulation? panel
あまりまとまりのないパネルだった。 オーストラリアの人が、APJにおけるGDPRの影響について話しているとき、ITがMatureな国としてオーストラリア、中国、韓国を紹介し、Developingしている国として香港、日本を。遅れている国としてマレーシア。オーストラリアからするとそういう認識なんだということがわかった…。 アメリカの人が、プライバシーに関する法案を挙げても、議会が何も通さない、とジョーク。
「サイバーセキュリティに関する法律と、プライバシーに関する法律はどのような関係か?」という質問に対し、「サイバーセキュリティの法律は、プライバシーの法律をサポートするものである。しかし、ログの保存期間を考えると、サイバーセキュリティではできるだけ長く保存しておくように、としているのに対し、プライバシーでは、不要になったら消すことを求めるなど、相反する要件が定められているところもある。」と。 よくできた会社でも、72時間以内に報告するのは難しい。 Enforcement: When Will the Big Scary Fines Happen, and How Do You Avoid Them?
スピーカーはフランス人。 罰金に繋がるトリガーは以下のようなもの。すべてDPAに報告される。 ・個人からの苦情 ・Webに脆弱性がある、というような通報 ・Activism ・サイバー攻撃(Ashley Madisonのようなケース) DPAは罰金で運営される。 以下のようなときに罰金が科せられる。 ・嘘をついている ・ガバナンスを適切に利かせていない →シャドークラウドが問題になるかもしれない。アセスメントをしてもらう前に、2～3個あるかと思っていたら、4000個見つかった。 ・情報が守られていない フランスの200人の警官のリストがテロリストのPCにあった。そのうち二人が殺された。セキュリティとセーフティは繋がっている。 「自由の女神がフランスからニューヨークにプレゼントされたように、GDPRはヨーロッパからアメリカへのGiftである。」って…。すごいこと言うなぁ。会場から苦笑が。 DPAの判断に不服の場合は、International Courtに訴えることになる。 キーノートスピーチをまとめて。
Cybersecurity Silver Linings (RSA)
サイバー犯罪で怖がらせるのはやめよう。 攻撃を予測して、新しいテクノロジーをつかって組織を守ろう。 守ることを楽しもう。CyberJoyという言葉を使ったらいいんじゃないか? Silver Liningは、希望の光という意味なんですね。「Every cloud has a silver lining」ということわざがあるそうです。つまり、クラウドに希望があるということ? The Price of Cyber-Warfare (RSA) wannacryが大きな被害を与えたことについて。病院のシステムがダウンして、手術が行えなかったことなど。 Azure sphereの発表。まさかマイクロソフトがRSAカンファレンスでcustom Linuxのソリューションを発表するとは思わなかったでしょう、と。 一緒に守ろう、と30社ぐらいのアライアンスを発表。 一緒に守ろう、とはRSAの人も言ってましたね。 Cryptographer’s Panel RSAのRとS、DHのDが出るPanel。 Shamirが青いシャツじゃなかった。 量子暗号に耐えられる暗号方式(格子暗号)を選定中だそうです。
The Incident Response Class of 2018: Tactics and Tales from the Frontline
サイバー攻撃を受けている最前線からのレポート。
ジャマイカからOffice365の乗っ取りが行われたりしている。会場から「Attributionは必要か?」という質問に対し、「必要。Fortune500の企業はやっている。どのように行動することを知ることが費用対効果を高める。どういう人が攻撃しているかを知らないと、ビジネス的な判断ができない。」と。 「ここ1，2年で何か変わったか?」という質問には、「去年の11月からOffice365のメールが標的になっている。フィッシングであったり、もっと高度なCredentialに対する攻撃もある。Apache Strutsの脆弱性を悪用したCryptoMinerも増えた。顧客側と、エンジニア側と両方から攻撃される例を保険業界で確認しており、これは守るのが非常に困難。クラウドのメールを使っていて、2要素認証を使っていないと非常に危ない。PowerShellを悪用した攻撃が多い。」と。
「IRを作ろうとしているが、Recommendationは?」に対しては、「無いならまず作った方がいい。大事なのはエスカレーション」と。 Threat huntingチームがある会社の人、と聞かれて、結構な数の人が手を挙げていた。 「有効性をどう計測しているか?」といつ質問には、「時間、エスカレーションまでの時間など。IBMのCISOは、検出したThreatの数に対して、組織に影響を与えた数で評価していた。」と。 「Minimumセットは何か?」には「CISのTop 20 Controlsをやるべき。」と。
Disclosure committeeを作った。大規模な問題が起こった時に、公表するかどうか判断する委員会。CIO、CEOもすべて含まれている。
Is Car Hacking Over? AUTOSAR Secure Onboard Communication
CANは”Insecure by default"。CANでは、すべてBroadcast。不要なメッセージは捨てて、必要な場合は処理を行う。
自動車Hackの例の紹介。
AUTOSAR(オートザー、と発音するらしい)は、LEGOのように部品をモジュール化する。国際的に受け入れられようとしている。2020年までには、どの自動車もAUTOSARベースのECUになると考えられる。AUTOSARにはSecOCというモジュールがあり、PDU(メッセージ)を認証し、完全性を検証する。Replay attackも検出する。PDUにはSecOCDataIDがつけられる。
Replay attack防止のために"freshness"を検証する。タイムスタンプを使う場合とカウンターを使う場合がある。
共有鍵ベースで128bitのMACを作成する。カウンターを全て送るとばれてしまうので、一部しか送らない。
MACのサイズは27ビット。それほど長くないので、ブルートフォースできるかもしれない。
「ノードを交換したらどうなるか?」という質問に、「カウンターを同期させる手段が必要。これは実装依存になる可能性がある。ペンテストするのであれば、この再同期のプロセスがポイントになる。再同期の前に複数の正しいMACを送りあって検証すると良いかもしれない。」と。
鍵管理も問題。どのように鍵を格納するか。鍵は1個しかないので、一つばれたら終わり。メッセージごとに鍵を変えればいいかもしれない。公開鍵は遅すぎて無理。ECUをグループ化して、別の鍵を使うといいかもしれない。
リモートでECUをコントロールされるとすべてやられてしまう。音楽を再生するモジュールにCANフレームを送らせてはいけない。
「オーバーヘッドはどれぐらいか?」という質問に「AESの演算を1回するだけ。H/WのAESモジュールを使えばいい。」と。
「自動車業界はECUの開発においてDue Dilligenceをしようとしているか?」という質問には「FirmwareのPentestは大事。すべきである。」と。
Make Your Car Self-Driving Using Open-Source Software
PANDAというインタフェースでCANバスにつなげ、cabanaというツールでリバースエンジニアリングする。
アクセルもブレーキも、すべてCANバスのメッセージでコントロールされている。
opendbcというデータベースがあり、CANのメッセージの仕様が載っている。ホンダなら、ブレーキは0x30C、ブレーキは0x1FA、ステアリングは0xE4。
EONというデバイス(スマートフォンをケースに入れただけ)
NEOSというAndroidからのフォーク。SSH、tmux、bash。
openpilotというオープンソースのDriving Agentがある。HONDA、TOYOTAはOK。GMは今年対応する予定。openpilotはECUをエミュレートする。openpilotを使って運転している人はすでにいる。このソフトウェアは映像から3Dマップを作っている。このデータが集約されていっている。
DSPを使いたいが、DSPはSignedコードしか実行してくれない。Quallcomにお願いしないといけない。しかし、DSPでSignatureをチェックするコードは最初にロードされるので、それを変えてしまえばいい。Jailbreak。I/Oコントロールをフックして、Signatureチェックをパスさせる。 http://freethedsp.com/
自動車会社は、自動車を作ることにフォーカスすればいい。ソフトウェアは得意じゃないのだから、やめればいい。
The Price of Shame
Monica Lewinskyによるセッション。 「後悔しているミスをしたことをある人は手をあげてください。」「そのミスを会場の全員が知っている人はいますか?」「私だけですね。」興味本位の参加者を、冒頭のこの問いかけで引き込む。 「あの事案があったのは20年前。20時間の自分の電話の会話を聞かされ、本人であることを確認するように強制された。」 「18歳の女の子が盗撮されて自殺した事件があり、それから考え方が変わった。」 「humiliationがIndustryになっている。クリックされれば広告費が入るようになっていて、それが加速している。SnapchatがHackされ、プライベートの写真や会話がネットに永久に存在している。」
「実世界では言えないことをネットでは簡単に言ってしまう。」 #bestrong 「クリックするときに思いやり(compassion)の気持ちを持ってほしい。」
Red Team vs. Blue Team on AWS
AWSの攻撃方法と防御方法について。AWSのセキュリティを包括的に知ることができた。 RedTeamは、AWSのアカウントをとったら勝ち。DBのデータを抜くのがRedTeamの目的。Credentialをフィッシングでとる。ネットワークアクセスコントロールリスト、セキュリティグループの設定を確認する。DBにアクセスできるVPCを探す。そのためには3306のポートが出られるようになっているものを探す。Lambdaの設定を調べる。rds_configを見つける。その中にはDBの認証情報が入っている。Webサイトを立ち上げて、抜いたデータをそこに送る。 対するBlueTeamは、ユーザ教育、PWポリシーとローテーション、MFAの普及。再認証、認証情報のハードコーディングをやめること。GitHubに認証情報がよく載っている。IAMの設定をきちんとする。マスター、ユーザーロールなど。Roleを活用する。個人のアカウントには権限を与えず、時限的な許可をMFAベースで付与する。CloudTrailでAPI利用をモニタリングする。KMSを使って認証情報を管理する。鍵を扱う人と、鍵でDBのデータにアクセスする人を分けてSoDを実現する。モニタリングする。GuardDuty、VPC Flow Log、CloudTrail、Config、Log shipping、Secure log backups、Automate Remediationなど。WAFも使う。AWS Shield、CloudFrontも併せて使う。ネットワークをプレゼンテーションレイヤ、アプリケーションレイヤ、データレイヤに分け、プレゼンテーションレイヤとデータレイヤの間の通信を禁止する。 「Public S3で情報が漏洩するのを防ぐにはどうすればいいか?」という質問に対し、「自分達のデータがどこにあるかを知ることが一番大事。CI/CD(Continuous Integration / Continuous Delivery)の中に組み込む。設定変更を検出する。最初は権限がないものをつけるから問題になる。そのアラートを捕まえれば、PublicS3のようなものを抑えることができる。」と回答。
STIX Patterning: Viva la Revolución!
STIX1とSTIX2は全然違う。STIX1の問題は、Indicatorの定義方法。定義方法が多すぎた。それによって、人によって定義がバラバラになり、マッチできなくなった。Snortはネットワークのアクティビティにしか使えないし、YARAはファイル操作に関することだけ。OpenIOCは表現に制限がある。Sigmaは非常にSTIXとゴール設定が近かったが、ログに重点を置きすぎ。 新しい言語を開発することとした。XMLやJSONではなく、読みやすく、なおかつコンピュータがパースしやすい形式とし、SQLに近い形となった。 ([ipv4-addr:value = 'x' OR ipv4-addr:value = 'y'] FOLLOWEDBY [domain-name:value = 'z']) WITHIN 600 SECONDS のような形式 IPアドレス、URL、Windowsレジストリキーなどをキーとして使うことができる。 YARAでできることは、STIXでもできる。 Indicatorは人間が書くとは思っていない。自動化されることを想定している。 Necurs Botnetのパターンも記述できる。これは、ファイルとネットワークの両方について記載しているので、YARAやSnortでは記述することができない。 ツールもトレーニングもGitHUBにある。 IndicatorをSTIXの言語で記述して、共有すべきである。分析もできるようにしたい。SCOオブジェクトモデルがベースになると考えている。 「ベンダーが「STIX対応」と言っているのに、ハッシュしか対応していなかったりする。」という質問に対し、「それは問題として認識している。相互接続を考え、認定プログラムを作らないといけないと考えている。」と回答。 面白いセッションだった。
Scaling an Application Security Program at the IMF: A Case Study
IMFでアプリケーションセキュリティを改善した話。
アプリケーションセキュリティは、建設などに比べて非常に歴史が短く、環境の変化が激しく、短納期などが厳しく、ライセンスもない。
ツールは、スキルのある人の効率を高めるが、スキルのない人が仕事をできるようになるものではない。
アプリケーションセキュリティリスクプロファイリングを行い、各アプリケーションのリスクを測定し、優先順位付けをした。
SLDCに沿ってセキュリティの助言をする際は、序盤より終盤の対応コストが大きいことを認識すべきである。
「Managerにちゃんと関与してもらうためにはどうするのか?」という質問には、「Visibilityが有効である。」と回答。
開発チームときめ細かく打合せを行うことがうまくいく鍵。
開発ガイドラインを開発者に渡しても読んでくれない。なので、2ページでわかるようなシートを作った。
システムコンポーネントの中で、セキュリティ機能を持っている部分と、開発者が気にしなければならないところを色分けした。これは非常に有益だった。
JAPAN NIGHT
3回目のJAPAN NIGHT、もちろん開催しました。この年から、私の前に(ISC)²の日本代表をしていたValue Creation Frontierの衣川さんと共同開催になりました。場所は変わらずMURPHY'S PUBで9時から。
毎回来る人、会社の都合で来られない人、サンフランシスコにいるのに時差ボケでホテルで寝ていた人、みんなそれぞれですが、良い時間を過ごして貰えたと思います。来年もまたやります。
小熊