2017 OWASP World Tour Tokyo

久しぶりの Web。周回遅れになっているので、情報収集のために参加した。思っていたのとは、ちょっと違った*1が、参加してよかった。充実した 1 日になった。

後日、参照できるよう、最低限のメモを残しておく。

Opening "OWASP Project Overview for Developers"

紹介していただいたプロジェクトは、いずれも FLAGSHIP であったが、ほとんどが知らないプロジェクトだった。
https://speakerdeck.com/owaspjapan/owt2017jp-owasp-project-overview-for-developers

Training 1 "OWASP TOP 10 を用いた脆弱性対応"

恥ずかしいことに、「Proactive Controls」すら知らなかった。話の流れからして、「TOP 10」とのマッピングは、誰もやっていなかったのだろう。
印象に残ったのは、「ソースコード静的解析では、アクセス制御、認可制御など、機能仕様に関係する脆弱性は検出できない」旨。これは、以前から言われていることであるし、静的解析ツールの原理を考えても、できなさそうだ。だが、今回は説得力があった。資料 35 ページ目の右下にしれっと書かれているのだが、静的解析ツールが「コベリティ」だったからだ(最近では、オージス総研さんのソリューションにも加わっている)。一流の開発者であっても、似たような悩みをかかえているのかも。
https://speakerdeck.com/owaspjapan/owt2017jp-owasp-top10

Training 2 "最小権限の具体的な実現方法"

「具体的な実現方法」についてのプレゼンを初めて聞いた。「最小権限は、セキュリティの原理原則である」という一方で、「最小権限の設計や実装は、業務要件次第」と言って、具体的なやり方を一切語らない。そんなコンサルタントなら、自分にだってできる。このセッションは、そこを一歩踏み出し、「Web アプリケーションにおける最小権限の設計のガイドライン」となっている。

前のセッションでも話があったように、権限設計や、アクセス制御の問題は、業務要件次第であるため、コレといった決定的な解決策を提示しにくい。
悪いことに、アクセス制御の設計を、画面中心で行っている案件は少なくないだろう。それは、画面設計書(あるいは、UI 部分のみを実装したモック)が、プロダクトオーナーとの最良のコミュニケーションツールだからではないか(特に、業務要件を整理するときは、確かに便利)。最も頻繁に更新され、最も信頼できるドキュメントなどになるため、どうしても画面が中心になってしまうのではないかと。こういう人たちに、「ローカルプロキシ」を使ってもらいたい。一発で目が覚めるから。
本セッションでも、画面はただの UI で、リスクアセスメントと同様、情報やデータを起点に設計してほしい旨が述べられていた。その通りだと思う。

こんな状態で、ペネトレーションテストを実施すると、やはり、アクセス制御の問題が挙がってくるようだ。一般には、危険度が高いと評価されるため、脆弱なアプリケーションだとお墨付きをいただける。これは恥ずかしい。
残念ながら、アクセス制御の問題は、後付けが困難である。全ての処理をインターセプトし、権限表に従って、権限の有無をチェックするようにしなければならないからだ。そんな仕組みが全くないところに?
となると、プログラム中にハードコーディングする対策がとられたりして、収拾がつかなくなる。
こうであっても、「たまたま権限設計がシンプルだった」という奇跡に救われることもある。そうすると、同じ設計の仕方を横展開されてしまうのではないかと、夜も眠れなくなる。ウソ。ぐっすり。
と、いくらでも書けてしまうので、そろそろやめよう。
正直、自分の中では、インジェクション系は、どうでもいい。はっきり言って、インジェクション系の脆弱性は、作り込みにくい。SQLi とか、見たことない。たとえあったとしても、比較的簡単につぶせる(対、アクセス制御)。
https://speakerdeck.com/owaspjapan/owt2017jp-least-privilege

Training 3 "開発者・運用担当者に向けた、OWASP ZAP を用いた脆弱性診断手法"

開発者、受け入れ担当者、運用担当者などに向けた発表というところが、本当に素晴らしいと思う。何年も、モノをつくっている人たちにアプローチする姿勢には、頭が下がる。

自分も、開発をしている人に(保守・運用の要員までは考えていなかった)、どんな形でもよいから、広く 「ローカルプロキシ」 を使ってもらおうとしている。なぜか。HTTP のリクエストは、「いつでも何でも送れる」 ということをわかってほしいから。好きなタイミングで送信できるし、好きな内容で送信できるということを、体で理解してほしいから。そうなれば、変な設計しないでしょ。上記の最小権限とかアクセス制御とか、まじめに考えるでしょ。こと設計においては、ガイドや規約が、なかなか役に立たない。体に叩き込むのが早そうでしょ。

で、ローカルプロキシは、シンプルなツールだし、うったえる内容も 「いつでも何でも」 だけだし。簡単に浸透していくと思っていた。のだが、これが意外に進まない。

ローカルプロキシを、本当に使ってほしい人、例えば、設計のレビューする人だったり、テストの計画を作る人だったりするのだが、こういうエライ人たちは、構築した Web アプリケーションを実際に動かすことが、ほとんどなかったりする。なぜか。自分の経験的には、そういうエライ人は、だいたいまわっていない。てんてこ舞いしている。調整。

ドキュメント作っても、読んでもらえない。トレーニング立ち上げても、受講してもらえない。完全に、読みが甘かった。

もちろん、色々なチャネルでアプローチをしていて、一部の若手には、使ってもらい出している。草の根的な活動も大事だと思っているので、これはこれで続けていこうと思う。
とはいっても、やはり、前述した人たちにアプローチするのが手っ取り早いし、そうできないのがもどかしい。もう少し、頭を使いマス。

で、OWASP ZAP の話。OWASP ZAP のスキャナも、ゴリゴリ開発している人に使ってもらいたい。ということで、組織内に展開するために、OWASP ZAP を色々動かしていたときのこと。あるプラグイン(Alpha)を追加したら、ウイルス対策ソフトが吠えた。これが、変な跳ね方をして、しばらく、おとなしくすることになってしまった。これも、完全に想定外。

改めて、何年も、モノをつくっている人たちにアプローチする姿勢には、頭が下がる。
https://speakerdeck.com/owaspjapan/owt2017jp-owaspzap

Training 4 "OWASP BWA を用いた学生および職員向けトレーニング"

自分も、組織内で、Web アプリケーションのセキュリティに関するトレーニングを立ち上げ、実施している。立ち上がったのは、10 年くらい前だが。
そういえば、トレーニングを立ち上げた話って、初めて聞いた。確かに、民間の人では、語りにくい。

他の仕事をかかえていて、2 週間程度で演習を作り上げたという話があったが、えっと、5 時間/日 × 14 日 = 70 時間。うん。とうていムリ。
自分の場合、企画した当初は、定時後にしか作業できなかったし、やられサイトも自作したということもあったが、たった 2 日間のコンテンツをつくるのに、半年近くかかった。満足いくクォリティになったが、やりすぎなのかもしれない。

XSS を 「分解して」 教えるところは、「なるほど」 と思った。自分のアプローチとは違ったが、前提知識を小出しにして積み上げていくという点は、一致していた。確かに、トレーニングを作成すると、こういうノウハウは蓄積する。ここらあたりの話は、心の中で、ウンウンと頷きながら聞いていた。

最後に、職員向けに、1.5 時間/週 でゆっくりやったという話だったが、コンテンツをどうやって分割したのか、受講者が前回の学習内容を覚えているものなのか、あたりも知りたかった。
https://speakerdeck.com/owaspjapan/owt2017jp-owasp-bwa

"開発プロジェクトの現状を把握する OWASP SAMM の活用"

TODO: 後で書く → 2017/10/10 ようやく書いた。途中までだが。
最後にキタ。
悲しいかな、「OWASP SAMM」を知らなかった。そんな自分には、最も有益な情報となった。

セッションの前半では、OWASP SAMM の骨子を、丁寧に解説いただいた。4 つのビジネス機能、ビジネス機能ごとに 3 つのセキュリティ対策、初めて聞く整理に驚いた。と同時に、コレは使えると思った(たとえ、教科書通りに使えないとしても)。また、各対策で活用できる OWASP の成果物が取り上げられていた。ほとんど知らない成果物であったため、たくさんの情報がいただけた。

セッションの後半では、具体的な活用事例が語られた。さすがに時間が短く(+ 大部分が社外秘の情報だろうから)、あまり細かいことはわからなかった。しかし、「アドバイス集の作成」や「タイムリーな情報提供」からスモールスタートするとよいなど、ノウハウも語られた。

すごく感じたのは、自分が所属している組織と比べて、「現場との連携が強い」ということ。一定のガバナンスが機能しているということ。
プロジェクトの開始から終了まで、一定の粒度で状況を把握することは、簡単にできることではない。プロジェクトの開始を確実にフックすることも大変だし、プロジェクトの途中経過を適宜知ることも、また大変*2

もとい。JPCERT/CC が、1.0 版を翻訳してくれているとのことで、さっそくダウンロードしてみた。
https://www.jpcert.or.jp/research/2010/SAMM_20100407.pdf

TODO: もう、ぐだぐだだ。もう少しだけ書きたい。

https://speakerdeck.com/owaspjapan/owt2017jp-owasp-samm

Closing "The shift left path"

SHIFT LEFT。言葉は違えど、昔から、そう言われていたような気がする。まだまだ実現できていない、ということなのだろう。
TODO: 後で書く
https://speakerdeck.com/owaspjapan/owt2017jp-the-shift-left-path


「被害者を産むようなアプリケーションを、システムを、世にリリースしてはならない」と思っている(だろう)人がたくさんいて、勝手に励まされた。


最後に。
今回、これだけのイベントを開催していただいたのだが、なんと参加費用は 0 円。無償だった。> 主催者のみなさま、講師のみなさま、ありがとうございました。
また、非常によい環境で、気持ちよく受講できた。> サテライト TOKYO-C 会場のスタッフのみなさま、ありがとうございました。

*1:「BOOTCAMP」 でも、「トレーニング」 でもないような気がした。

*2:こういう取り組みは開発現場の理解が不可欠だと思う。しかし、それを取りつけるのは、なかなかハードルが高い。トップダウンで降ろしてもらうには、まだ、体力が足りない。ボトムアップで、できるだけ現場の負担にならないように、「打ち合わせ時間を短くする」や「現場で対応しなければならない箇所を減らす」など、工夫をしてはいる。が、まだうまく機能はしていない(ボスのおかげで、少しずつは成果が出ている)。