こんにちは、ひろかずです。
OWASP World Tour 2017に行ってきたので、一筆書きます。

会場は、東京工業大学大岡山キャンパス
サイバーセキュリティ特別専門学修プログラムが開講されるなど、セキュリティの熱量が高さが伺えます。
なんと、東京工業大学は、OWASPアカデミックパートナーに申請されるそうです。
認可が待ち遠しいですね！

会のスライドはこちらです。

例によって、リアルタイムで執筆しているので、表記ゆれ、誤字、脱字、記載漏れはご容赦ください。

お品書き

OWASP Top10を用いた脆弱性対応
最小権限の具体的な実現方法
開発者・運用社に向けたOWASP ZAPを用いた脆弱性診断手法
OWASP BWAを用いた学生及び職員向けトレーニング
開発ブロジェクトの現場を把握する ~OWASP SAMMを活用~

OWASP Top10を用いた脆弱性対応

オージス総研安藤さん
スライドはこちらです。

OWASP Top10とは

今回は2013年版(現在のSTABLE)を読み解く
PCIDSS, MITER, DISA, FTCが参照しているドキュメント

2013年版に記載されている以下については、削除・統合の予定

A2,A5 認証不備として統合
A10 あまり使われなかったので削除予定

なお、2017RC1は、リジェクトされてしまったそうです(11月下旬に正式リリース予定)

OWASP Top10 Proactive Controls

Top10をインプットにして、プロアクティブにやれば良いことをまとめている
マトリクス形式になっていて、Top10との関連性もわかりやすいです。

脆弱性とは

プログラムや設定上の問題に起因するセキュリティ上の弱点
脅威者が、攻撃手法を用いて、セキュリティ上の弱点を突き、セキュリティ制御を突破して、機能に対して技術的な影響を及ぼし、ビジネスへの影響が発生する
これがリスク
脅威者とビジネスへの影響は、自分で判断する必要がある。

セキュアコーディング

攻撃に耐えられる堅牢なプログラムを書く
アプリケーション自体の防御力を上げる直接的な手段
ソフトウェア脆弱性の多くは、コーディングエラーで作り込まれる

SQLインジェクション欠陥があるかどうか確認のポイント

動的クエリは怪しい
変数で組まれたクエリ
クエリを直接投げる（インタプリタ通さない）
制御とデータを区別しない。入力値がデータであることを検証する。

Proactive Controlでは

全ての入力値を検証する(信頼しない)
プレースホルダを利用する
安全なSQLの呼び出し方は、IPAのドキュメント参照
Prepared Statementを使用する

コードレビュー

安全にインタプリタを使っているか
ツールを使って検証(目検は限界)

コーディング規約違反の検出
ソースコードセキュリティ検査
ホワイトボックステスト

静的解析ではできないこと

Webアプリケーションにおけるアクセス制御、認可制御、機能仕様に関する脆弱性は検出できない
ここは目検になる。

脆弱性検査

動的解析

インタプリタを使った検査は、静的ではできない。
有償は信頼できるけど、費用がかかる。おわりでの一発勝負になってしまう(手戻り大変)
無償の検査ツールの利用(こまめにかけて、手戻りを少なくする)
ブラックボックステスト
OWASP ZAPは初心者でも簡単に使える。

セキュリティアーキテクチャの構築

実装・テストだけでは不十分
開発者のスキルでばらつく
セキュアな認証の仕組みを自作できる？有効なの？
開発者向けの次のステップ

開発初期段階化でセキュリティを設計に組み込む
標準的なセキュリティ制御セット(ライブラリ)の利用
再開発は時間の無駄。

Spring Secirity

JAVA系に強い。特に認証
A2,A4,A6,A7,A8

ESAPIの対応(スライド参照)

盲目的な信頼もまた、脆弱性になりうる。

セキュリティ要件定義

どんな対応が必要？
アジャイルは機能要求だけになりがち

何をすべき
どれくらいかかるか

ASVS(OWASPアプリケーションセキュリティ検証標準)

セキュリティ要件とセキュリティ項目
アーキテクチャ、設計、モデリングのチェックシート（レベル1~3）
セキュリティ要件定義のインプットに最適

Webシステム/Webアプリケーションセキュリティ要件書2.0

セキュリティは非機能要件(見えにくい)
IPAの非機能要求グレードが参考になる。
トレードオフを含めて検討することが大事

外注するなら、OWASP Secure Software Contract Annexを参照するといい。

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

神戸デジタルラボ　長山さん

資料はこちらです。

情報・データ起点の権限設計

画面や機能起点ではない

今日は、Webアプリケーションの権限設計の話

最小権限とは

操作の実行に要求される最低の権限を最低限の期間だけ割り当てる必要がある

難しさ

ビジネスとの結びつきが強い(この画面隠したら使い物にならないとか)
ツールで見つけにくく、直しにくい(ツールでは、レスポンスが違うことの異常性がわからない（無料ユーザー画面なのに、管理者画面に遷移できる）)
発生には、考慮不足を伴うので、発覚するタイミングがリリース前だと大変

公開情報
IPAの場合

安全なWebサイトの作り方
外部パラメータを使って、権限切り替えはしない

OWASPの場合

全てのリクエストが、アクセス制御機能を通ること
デフォルト拒否
アクセス制御をハードコートしない

実装上の情報は多いけど、設計上の情報は少ない。

そもそも何を守るか

どんな攻撃があるの？
未承認状態で、要認証コンテンツでダウンロード（URLさえわかれば良いやつ）
認証後に、別認証者に公開されているコンテンツにアクセス
権限パラメータを改ざん（cookie）

画面を守るのではなく、データを守るのが本質。
データを中心にアクセス制御を考える必要がある。

リスクアセスメント

資産の特定、誰がアクセス可能化、脅威や脆弱性を洗い出す

権限設計をするには

扱うデータの特定
データのライフサイクルの検討
データの操作権の特定
例

対象　　　　　：へそくり
ライフサイクル：¥50,000貯まるまで。溜まったら消える(買い物)
アクセス範囲　：自分だけ

扱うデータの特定

DBデータは、ER図とかをインプット
扱うファイルの洗い出し

ライフサイクル

作成契機、削除契機
申請都度とか任意のサービスの提供期間とか

操作権の特定

ER図で、未認証者がアクセスできる範囲と認証者がアクセスできる範囲を特定する
レコードの操作単位を把握することで、

操作方法の検討

Howの検討とシーケンス図で検証
How:例）自分だけが安全に出し入れできる本棚を使う。金庫だとバレる。
シーケンス図を使うことで、必要なユーザーや削除契機が見えてくる。

プロトタイプとUIモックは並行してできる。
権限設計はデータ主体で行える。

実装するには

FrameworkのACL(アクセス制限機能)を利用して、以下をお手軽に実装

ログイン有無による制限
ページ単位のアクセス許可

検証するには

テストコードに含める

設計者や開発者は、結果が正しいか判断できる。これが確実。

維持するには

コードから権限表を生成するスクリプトを作る

画面単位で権限コントロールのコードを拾っていく

開発者・運用者に向けた、OWASP Zapを用いた脆弱性診断手法

SCSK 亀田さん

スライドはこちらです。

Zapを使ってOWASP Top10を見つけることができようにすることが目的
これを使えば、一定のレベルだと認知される
自動だけど、手動でもできる。
対象者は、開発者や受け入れ担当者

注意

データへの影響や、診断文字列の残存、負荷があるので、本番環境では極力避ける。
アンチウィルスソフトが検知してしまうことがある

情報ソースが豊富

スライドを参照

利用想定事例

要件定義

設計開発

デバッグに使える
デバッグ中に脆弱性を見つける

テスト検証

納品物の一定の品質担保
確認すべき項目を元に診断を実施

運用保守

自動診断による網羅的な診断
手動でのフォロー

ZAPping Top10

自動向き(A1,A3,A5,A6,A8,A9,A10)

手動向き(A2, A4, A7)

HTTPセッション

特定の条件にマッチした文字列をセッション情報として格納しておく(フィールド名の自動判別/指定も可能)
必要に応じてセッションを切り替えて利用できる
セッションを切り替えて、見える見えないを判別できる。

パラメータタブ

サイトごとにパラメータの一覧が表示
スパイダーの後で見れば、存在する値をもれなく一気に確認できる
意図しないパラメータの検出とか。

スパイダー・Ajaxスパイダー、Access Control

指定ページを起点に遷移可能なページを探索
ユーザーの状態で遷移できるページが変わる場合に使える
ログインした状態で発現する脆弱性とか

アクセスコントロール

設定ユーザー毎のアクセス制御を確認
アクセス出来過ぎとかできなさすぎとかを検出できる。

Web Application Security Testing チートシート

診断時に必要な項目のチェックリスト

Web Application 脆弱性診断ガイドライン

簡易的に診断を行うためのマニュアル
どの脆弱性を見つけるためには、何をすれば良いのかが書いてある
受け入れ担当向け
受け入れ時にこれを手動でやるだけで一定の水準に達する

"Web Application 脆弱性診断ガイドライン利用のためのドキュメント"に詳細な手順が掲載されている

スライドを見てください！

Active Scan Rule

動的スキャンのRule集
Release版は、シンプルなもの。デフォルトで入ってる
Beta、Alpha版、複雑なペイロード。
ポリシーでテストの種類に応じてレベル分けできる。
テストの種類ごとにやる・やらないが選べる

Passive Scan Rule

静的スキャンのRule集
Release版は、シンプルなもの。デフォルトで入ってる(まずはこれから)
Beta、Alpha版、複雑な文字列(過剰検知が増える傾向がある

OWASP BWAを用いた学生及び職員向けトレーニング

東京工業大学松浦さん
東工大CERT統括責任者

スライドはこちらです。

セキュリティのトレーニングは結構簡単にできるからやろうよ！という内容。
演習の内容の内製している人ー！

会場は1%

QWASP BWAとは？

BWAとはBroken Web Applicationの略
VM形式で提供されている(閉鎖環境での利用必須！ダメ！グローバル！)

BWAの対象者

Web Applicationセキュリティを学びたい人
リスク評価技術、アセスメント、脆弱性診断をじっくり学びたい人
自動化のテストや攻撃の監視、WAF技術のテストをしたい人

BWAには何がはいってるの？

トレーニングApplication(脆弱性毎の問題コース)
脆弱性が作り込まれたWebアプリ(10種類くらい)
実在アプリの脆弱性のある古いバージョン

環境構築のリソースを省略できるのが魅力

演習実施者、受講者の教育効果

東工大生

基礎力を応用する実践的な場を提供(机上の学習がメインだが、手を動かす場も大事)

CERTメンバー(事務員、技術職員)

セキュリティのニュースにはよく触れているが、実際に手を動かすことで、日頃の業務の役に建てる

座学と演習

座学(インプット)と演習(アウトプット)の繰り返し
だが、どうしても知識の習得に偏ってしまう
演習環境が足りない
構築コストを抑えながら演習できるのがWBA

演習環境の構築方法

作成ポリシー

無理なく準備参加できる
現実環境に置き換えて想像可能である(ヤバさが直ぐ分かる。相手の想像力に過大な期待はしない)
自力で解ける問題の粒度/難度
進めると攻撃シナリオが達成できるような流れ

複雑なXSSを受講者にどう理解してもらうかの工夫

シーケンスをならべてもなかなか伝わらない

シナリオをパーツ別に分解

クッキー情報の確認と変更(アドレスバーでクッキーを確認、追加して編集を体験)
脆弱性を確認して、わざと漏洩してみる(脆弱なサイトにアクセスして、クッキー情報の送信)
攻撃コードを作成/設置

BWAを使っての攻撃シナリオの作成手順

実施環境

学生：ブラウザはFirefoxがいい。(演習に優しいブラウザ。chromeやsafaliでは止められてしまう)
環境：BWAにおまかせ

他の業務をやりながら、2週間程度で準備ができた(一日1〜2時間の頑張りの積み重ね)
演習担当者は、直接のセキュリティ知識が高まる他、付随するシナリオの作成能力や、HTTP、仮想環境の構築能力等幅広い知識が付く。

演習実施手順（問題の出し方：理解しやすい粒度と順番の考慮）

まず、わかりやすくできることを示す

入力フォームにキーワードを入れて、通常表示、HTMLタグ(取り消し線)、Javaスクリプト(アラートポップアップ)を見せる。

次にググれば出てくるお題に置き換える。

cookieの中身の表示
cookieの中身を送信(srcタグを使って、別サーバのアクセスログに情報を貼る)
リクエストパラメータに情報入力を促す画面を表示させる

演習を通して、掲示板に置いてあるようなリンクを踏むことの危険性に気付く等、想像力が働くようになった。

具体的な演習実施例とTips

学生向けセキュリティ合宿

箱根の温泉に2泊3日:10名程度
参加者：基礎力が高い一方で、HTMLやJAVAなどの知識は乏しい。CTF未経験者
演習環境：入れてこーいの一声で用意してくれた(!)
Tips：ネットワークの環境に頼らない、端末内で完結する環境とした
チーム編成：2~3人
お題：OWASP Top10のうち2~3種類づつに按分してレポート
東工大生は真面目にデモを作ってきた

雑感

時間をかければ、事務の方でも段階を追って回答できる
問題が解けた時は嬉しそう(学びに年齢は関係ない)
手を動かす(能動的に動く)ということは学びが多い
職員向けに幅広くやることで、意識が向上できる

余談

大学の環境は、マリシャスに汚れていると思われるている（実際汚れているけど）
大学は人の流動性が激しいので、ガバナンスが効きにくい。
ブラジル五輪と同じような感じ。
大学と仕事する時は、温かい目で見て欲しい

開発ブロジェクトの現場を把握する ~OWASP SAMMを活用~

サイボウズ株式会社伊藤さん
CSIRT PoC

スライドは、こちらです。

OWASP SAMMって?

成熟したセキュア開発を行うことを支援するドキュメント

OWASPフラッグシッププロジェクトの成果物は、要件定義から運用まで当てはめることができる。
OWASP SAMMは、セキュアな開発ライフサイクルを作ること（全フェーズに適用）

特徴

開発プロジェクトのセキュリティ成熟度を、指標を用いて可視化、定量化して現状を把握できること(NISTIR-8151)
継続改善に役立つツールが整っている。
セキュリティのアセスメントに役立つ

今回は、Coreドキュメントを読み解く上での助けになる話をしたい。

プロジェクトメンバーとしては、以下が定められている

Developer
Architect
Manager
QA Tester
Security Auditor
Business Owner
Operator

ビジネス機能

ガバナンス
構築(設計/開発)
検証
運用

それぞれに3つのセキュリティ対策を実施

内容はスライドを参照してください！

セキュリティ対策の例

プロジェクトメンバーのうち、誰が関わっているか
対応することで期待できる結果は何か
対応するためのコストはどれくらいか
定量的な指標の例

使った感覚では、定量的な指標の例が役に立った

現状把握

アセスメント(ツールボックスの活用)
ヒアリング計画を建てることが重要
プロジェクト体制を把握して、ヒアリング項目と対象を決める
時間がかかる。焦らないこと。

アセスメント項目

可視化

成熟度がグラフで0~3で可視化される。
レーダーチャートも出せる。

目標設定

可視化できる水準を決めて
ビジネスオーナーに説明するのに、可視化したものを提示することで、少しずつ進めようと説明するということがやりやすくなる

12のセキュリティ対策とOWASP成果物

SAMMではアクティビティが示されるが、具体的な成果物への導線がない。
OWASP Project Inventoryに登録されている公開プロジェクトとローカルチャプターの成果物を参照する

戦略/指標 (SM)

各ドキュメントを当たるより、SAMMのドキュメントを参照する

ポリシー・コンプライアンス（PC）

日本ではISMSが主流
OWASP Policy Framework
社内の規定を基に、参照するのが良い

教育・指導（EG）

OWASP Education Project

脅威の査定（TA）

Application Threat Modeling
Cheat Sheet

セキュリティ要件（SR）

ASVS
Webシステムセキュリティ要件書

セキュアなアーキテクチャ(SA)

Proactive Control

デザインレビュー(DR)

Application
レビュ対象に応じて拾ってくるのが良い

実装レビュー（IR）

Code Review Project
Secure Coding Cheat Sheet

セキュリティテスト（ST）

脆弱性診断士スキルマッププロジェクト

課題管理（IM）

Incident Response Project
NCAやJPCERT/CCのドキュメントも参考になる

環境の堅牢化（EH）

OWASP Dependency CHECK
OWASP SOC Framework Project

運用体制のセキュリティ体制（OE）

SAMMのアセスメント項目をCheat Sheetとして活用するのが良い
何か良いことがあれば教えて欲しい

適用事例

アドバイス集の作成（工数少ない）
情報提供
Projectの可視化（工数が大きい）

工数が少ないところから、だんだん広げていくのがいい

アドバイス集の作成

アセスメント項目ごとに参考になるドキュメントを収集
どんな人に情報を提供するときのカンペ集を作る

タイムリーにアドバイスを提供しながら、落とし所を探っていく。

開発時の負荷低減、利便性へのアドバイザリ
顧客からの問い合わせへのアドバイザリ

情報提供

新規プロジェクトへの情報提供
運用や開発に必要な情報を

Projectの可視化

ツールボックスの内容を埋めていく。
全部まともに埋めると大変なので、ヒアリング項目を決めて効率よくやっていく

可視化の結果、悪いところだけではなく、良いことも評価する。

ロードマップテンプレート

業種別に用意されている

ソフトウェアベンダー
金融サービス
サービス・プロバイダ
政府組織

3を求めるのではない。
いいところに落とし込む。
頑張り過ぎのことろを調整することもできる

QA

SAMMを適用できるプロジェクトの大きさは？ミニマム(2-3人)なものには適用可能？

ロールが重複している
求める水準の高さはプロジェクトよる
作っている人は2-3人でも、ビジネスオーナーもいる。
共通認識を持つディスカッションの材料にしてほしい。
誰がどの役割なのか識別するのが大事

おわりに

どれも濃密なセッションでした。
どんなプロジェクトにも役立てるリソースがよくわかったと思います。
明日から、ぜひ役立てたいですね！

今日はここまでです。
お疲れ様でした。