toto_1212

技術のログをツラツラ書きます。自分用ですが参考にしていただけたら嬉しいです。間違ってたらドンドン突っ込んでください。

【勉強会】第18回オワスプナイト

勉強会 セキュリティ

OWASP Japan主催のオワスプナイトに初参加したのでメモを残しておきます。

owasp.doorkeeper.jp


* Outreach Activities - S Nakata

元 Webの脆弱生診断員
現 コンサルタント　OWASPプロモーションリーダー

今日のお話
・OWASP Japan対外的活動の共有
・OWASPのドキュメント類の紹介

【対外的活動の共有】
OWASP Japanブログを始めた
　イベントの参加やオワスプナイト開催の通知等を長文で解説する

http://blog.owaspjapan.org/post/125493381154/owasp-night-18th-at-scsk-開催報告
blog.owaspjapan.org

【ここ最近の活動】
本日のデブサミにブースを出展しその足でここに来た

JFT2015（ブースとショートプレゼンで参加）
石切山さんがプレゼンテーション

某社とコラボレーション企画を考えている。

【OWASPのドキュメント類の紹介】
OWASPドキュメントの使いどころ
　・要件定義フェーズ
　　　WebシステムWebアプリケーションセキュリティ要件書

　・設計・開発フェーズ
　　　OWASP Proactive Controls
　　　　OWASP TOP10で定義したリスクを事前に防ぐ方法をまとめたもの

　　　OWASP ASVS
　　　　後のセッションで説明
　　　
　　　OWASP Cheat Sheet Series（33種類、14準備中）
　　　　テクニカル要素（あるべき論）を纏めたもの

　・テストフェーズ
　　　OWASP Zed Attack Proxy （ver2.4.0）
　　　　日本語UIが多くなった
　　　　アタックモード（web遷移するとアクティブスキャンをかってにかける）

　・運用保守フェーズ
　　　OWASP Testing Project
　　　　テスト手法を纏めたもの

　　OWASP OWTF
　　　ペネトレーションテスト

　　OWASP ModSecurity Core Rule Set Project
　　　modsecurityに関するもの
　　　
　　OWASP AppSensor Project
　　　侵入検知とそれに対するレスポンス応答を同時におこなう

　　OWASP Dependency Check
　　　使っているライブラリに脆弱性がないかをチェック

　その他
　　OWASP TOP10
　　Mobile Top Ten
　　Internet of Things Top Ten
　　　リスクと対策を纏めたもの

　OWASP Snakes and Ladders（twitterbotが存在）
　　OWASP TOP10のリスクと対策をスゴロクで遊べる

OWASP Proactive Controlsを日本語訳した。（公開準備中）

speakerdeck.com


* Hardening Project 2015 - Hardening 10 Market Place Inside Story - N Takanori

OA機器メーカ勤務

【Hardening Projectとは】
ITシステムの総合運用能力を競うイベント
ビジネス継続をふまえた守りに特化したもの

6/20,21に沖縄宜野湾市（コンベンションセンター）で開催
20日は競技主体のHardeningday
21日は振り返り＆表彰のsoftningdaywasforum.jp

ロゴの意味は灼熱のHardeningdayと祝福のsoftningdayで
色がそれぞれ分かれている。


Hardening競技とは
テーマはマーケットプレイスの活用
　・インシデントレスポンス
　・可用性
　・パフォーマンスチューニング
　・在庫管理
これらをうまく8時間で回していく。

実行委員の川口さんが@ITに競技の模様をコラムとして書いている。www.atmarkit.co.jp

【コラムに書いてないこと】
マーケットプレイスの商品は？
　プラットフォームサービス、プロダクト、アウトソーシング、コンサルティング、分析解析、構築サービス
　これらを使ってECサイトをうまく回していく（可用性を保ってDoS回避とか）
　マルウェアの回避はプロダクト内のWAFだったりセキュリティ対策ソフトを使って対処
　　※うまく使っていたチームは少なかった印象
　
応募選考があり、MAX40名を想定していた。
スーパーアリーバードで十数名を想定。
金曜夜にスーパーアリーバードを募集して日曜の昼に締め切りで40名のうち過半数を超える応募
急遽、アーリーバードを廃止して選考しようとしたが、その後も応募が多数。
VM数が350超え、VLANIDも100を超えるシステムでの競技になった。


競技環境内はLBに繋がれた3台のECサイトやDB、サポート端末といったものが用意され、
これらをうまく管理しさまざまな攻撃に対処する。
これらのサイトはTomcat、wordpress、stratsといったもで構成されている。
Tomcat、wordpressのプラグインは脆弱性対策されているが、インジェクション対処をしない
チームがほとんどであった。
簡単に対策できるところだと思うのできっちりやってほしい。

手軽に確認できる方法としてSecurity Ninjas AppSec Training Programがある。
dockerコンテナで脆弱性のあるWebページが用意されている。
OWASP TOP10の項目に紐付いたWebページとなっておりクイズ形式で進められる。
OWASP TOP10の脆弱性項目を簡易的に体験できる。

Mini Hardening Project 1.2が8月に開催される（1.0や1.1に参加されていない方が対象）
3時間程度のライトなHardening競技でこちらで腕を試して12月の本戦にお越し頂きたい。minihardening.connpass.com

ざっくり分かるインシデントレスポンス M Tamaki

以下2点のお話し。
・最近のWebサイトに対する脅威
・Webアプリケーションエンジニアからみたインシデントレスポンス

最近のWebサイトに対する脅威
2015年7月だけでも脅威が9つもある。
　攻撃者の目的は攻撃用インフラとして使うものや情報を搾取するケースとして分類できる

被害者は企業ではない、Webサイトの利用者である
　企業としては利用者に対し情報を提供することが大事

対策責任の所在
　利用者の問題というものはあまりない
　パスワードリスト攻撃にしても運営者が強固なパスワードや認証手段を用意すればよい
　運営者が責任もって対処すべきである
　とはいっても脆弱性ってそんな簡単に対処できない

ゼロデイ脆弱性トップ5のパッチ適応される期間がどんどん伸びている
　→対処が難しい
攻撃までの期間が早い
　→シマンテックレポートでは脆弱性が明らかになって4時間で攻撃開始されるものもある
　 対処が難しい
パッチ適用のためのサイト停止が難しい

インシデントレスポンスの必要性
　適応できないから何か起こった場合、チェックして見つけて対処する必要がある
　脆弱性を防いで、攻撃されないようにするのは難しい
　攻撃される事を前提で、それをいかに検知し対処できるか
　Webアプリケーションエンジニアの方はそれらを理解して行動しなくてはいけない

Webアプリケーションエンジニアは何をすべきか
　インシデント発生時、CSART体制（想定）で活動すると思われるが、Webアプリケーション開発者及び
　Webサイト管理者はインシデントに対する調査や対応、復旧の実働者

インシデントレスポンスの一般的なライフサイクル
　準備 → 検知・分析 → 封じ込め・根絶・復旧 → 事後活動

これらのカテゴリ内でWebアプリケーションエンジニアがやるべき事
　準備：サイト情報の整理、検知策導入、監視、予防対策　＜平時＞
　検知・分析：インシデント初期調査、調査結果の報告、セキュリティ専門業者とのやり取り　＜有事＞
　封じ込め・根絶・復旧：初動対応、対策の実施、サイトの復旧　＜有事＞
　事後活動：改善の協力　＜平時＞

検知・分析
　・エラーログアクセスログを見る
　・改ざんされることを想定し差分を取っておく
　・MD5やSHA1といったハッシュ値でチェックする
　・日付を見ておく
　・NW設定を見る（変更されてないか）
　・アカウントの確認
　・ジョブスケジューラの確認
　・DNSとかARPの設定確認
やらないといけない事がたくさんある
焦ってはいけないけど急ぐ

Webサーバのログチェック観点
　存在以内ファイルや埋め込みコード、LB内すべてを対象とするとか

報告
　調査の結果は必ずCSIRT（責任者）へ報告
　　Webアプリケーションエンジニアはあくまで手を動かすこと
　
　電話での報告
　　VoIPとかだと攻撃者が盗聴しているかも
　メールでの報告
　　スニッフされているかも
報告も気をつける必要がある

ログ確認時も注意が必要
　エビデンスが汚染される（アクセスによって履歴が変わる）
　調査履歴を取ることが必要

調査結果の報告で忘れがちな事
　専門家に規定頂いた時の入室管理やアクセス権の扱い
　　調査場所がDCである場合とかは事前に入館申請を出すとか忘れがち

封じ込め・根絶・復旧
　気をつけるべき事としては、対処した時に変わる情報を押さえておく（報告と同様）

　自分が管理しているサイトにどのくらいの売り上げや重要度があるのか
　　これにより対処したいが出来ないこともある
　　ECサイトのセール等で止める事ができないようなこともあるのでスケジューリング大事
　　CSIRT責任者が把握していればいいということも考えられるが、Webアクリケーション
　　エンジニアは実際のアクセス量や対策の問題点を把握しているので説得力がある

対策の実施
　バックアップから復旧すると完全に直らない場合がある。
　　古くから発生しているインシデントもある。（履歴管理をすること）

　復旧後に脆弱性が完治している事を確認、それをもって公開する

まとめ
インシデントレスポンスは重要だけど実際に実施すると大変なことが多い
チートシートはログのチェック項目や観点が書いてあり参考になる
インシデントレスポンスのフォーマットもある

speakerdeck.com

Application Security Verification Standard (ASVS) Project 3.0 preview - R OKADA

アプリケーションセキュリティ検査/検証の標準化というプロジェクト（2009年頃から）がOWASPにある。

アプリケーション検査における象徴的な絵
「思った通りに動いてる」とは何か？
　思った通りに動いているという事をテストするときに　
　　・ソフトウェアの脆弱性、ビジネスロジックの話をいかに網羅しているかを定義
　　・リスクに対して十分なテストをしているという定義
　これら以外に難しい。

このような背景からOWASPでは標準化するという活動をしている

検査：第三者的なイメージ
検証：Verificationを翻訳すると「自分でverifyする」という主体的な意味合いもあるし、
　　　既に起きているものを検査するという意味もある
文脈に応じて使い分ける（誤解を招く可能性あり）

OWASP TOP10
　重要リスクの普及啓発するツール
　しかし、検査しなくてはならない項目としては明らかに不十分
　検査しなくてはならない項目を網羅的にしたドキュメントではない
　注意事項にはASVSをガイドすることの明記がある。
　開発者向けのメッセージにもASVSをセキュリティ標準とする事が明記されている。

ASVS 1.0のあまりよくなかったとこ
　検査レベルを1〜4まで設けていた
　ツールで出来るテストの範囲とツールで出来ない範囲のテストを厳密に定義した
　どのようにテストするか？何をテストするか？の両方が書かれてしまっている
　そのため身動きが取れにくくなってしまっていた

ASVS 2.0
　シンプルなセキュリティレベルが定義された。

Level 0：テストしてない
Level 1：すぐに見つかるレベル
Level 2：標準レベル
Level 3：より進んだテストを実施
それ以上：外部とのモジュール接続等標準化しにくいもの

どのようにテストするかではなく、どのような項目をテストするかが書かれている

13項目からなる検査要件
　Vxxで表現（xxは数字）

V2. Authentication
V3. Session Management
・
・
・
V17. Mobile

Version 3.0が7月にPreview版がでた
大項目が3つ増えた
　V18. Web services (NEW for 3.0)
　V19. Configuration　(NEW for 3.0)
　V20. Client side Security (NEW for 3.0)

議論の場はGitHubで行われる
issueベースで議論github.com


レベルはどのように決めるのか？
　このシステムはレベル1でOKのような使い方、このシステムはレベル2は必要みたいな。

　付録ページにあらゆる業種で使われるシステムで定義に応じたレベル分けをしており、
　リスクの仕分けに使える

標準の使い方
　宣伝文句に惑わされない（XX社製品よりできますとか）
　開発会社の選定（レベル２以上の技術が必要とか）

使いどころ
　経営層にアプローチ
　開発中のシステムに照らし合わせてみる

セキュリティに関係ない方、学生さん
　セキュリティを学ぶツールとして利用できる
　セキュリティ上の原則に基づくテクニックが学べる

www.slideshare.net

参考Web

第18回 オワスプナイトまとめ #owaspjapan
togetter.com

@okdtさんのツイート