Discover Performance

 

 


今すぐ登録する

「HP Software Discover Performance」日本語版



OWASP AppSec APAC 2014
情報セキュリティの再考- OWASP AppSec APAC2014 誌上レビュー

OWASP AppSec APAC

3/18-19ソラシティ・カンファレンスセンターで2日間にわたって開催された「OWASP APPSEC APAC 2014」。日本初開催のOWASP AppSecは、「ソフトウェアの安全性に取組むすべての人のための国際カンファレンス」で、二日間で400名を超える来場者であった。「すべての人のための」ということで技術者向けの話だけではなく、企画をする人、マネジメント向けのセッションも用意されていた。

中でもWomen IN AppSecというセッションもあり、女性のセキュリティアナリスト、エンジニアの育成に力を入れ始めている。(Women in AppSecの資料 

HPも先日女性のセキュリティアナリスト育成の奨学金を発表している

2013年版OWASP Top 10 /OWASP Top 10 2013(Dave Wichers)

2013年版OWASP Top 10 /OWASP Top 10 2013(Dave Wichers)

新しく追加された「2013---A9-Using Known Vulnerable Components(NEW)」に重点を置いたセッション。

オープンソースやサードパーティ製のライブラリなどを使用しているアプリケーションが多くなっているが、脆弱性を含むライブラリを使用し続けているアプリケーションが多い。80%はライブラリー、20%はカスタムコードである。

開発時は、それらのコンポーネントに脆弱性が存在する場合、アプリケーション側で対処する必要があり、運用時は、使用しているライブラリを把握し、それらのバージョンアップ、ならびにセキュリティパッチを適用するなどの対策を行う必要がある。

資料は、こちら 

Top Ten Proactive Web Application Controls (Jim Manico)

定期的(1年に1回、半年に1回など)にペンテストだけを実施し、アプリケーションの脆弱性をチェックしているが、 ハッカーは1年365日1日24時間、それらのアプリケーションに対して攻撃を仕掛けている。 ペンテストはアプリケーションの脆弱性をチェックし、見つかったら対策を行うなど能動的なアプローチであるため、開発の初期段階から、脆弱性を作り込まない対策を行うべきである。

資料は、こちら 

「世界初のSaaS型WAFサービスの裏側 / Inside Story of the first SaaS type WAF Service」 金床氏

既に450以上のウェブサイトで使われており、ほとんどのユーザでほとんど問題なくブロックモードで利用している。
SaaS型ということでウェブシステム側に変更を加えることなく、DNS, Firewall, SSLの設定変更だけで導入できるという手軽さが受け入れられている。最短で24時間で導入したケースもある。また、あまり大きくない組織では、WAFの運用をする人員を揃えられないため、このようなサービスで防御をすることも一つの選択肢であろう。「監視ではなく防御」と金床氏は、強調している。

一方、大企業においては、監視も必要になってくる。攻撃を止めて終わりではなく、止めた攻撃も他の攻撃の予兆と考えられたり、事後的に調査を行う必要も出てくる。どのような攻撃をどれくらいどこから受けたのかを把握しておくことも必要である。本サービスの仕組みは、DNSの変更により全てのウェブトラフィックをこのSaaS型WAFに飛ばし、ウェブサイト側ではこのWAFのIPアドレスからしかリクエストを受け付けないようにするというものです。したがって、ウェブサーバ側には全てのアクセスのソースIPアドレスがWAFのものとなる。

シグネチャベースでの検知では誤検知が多いという欠点があり、このSaaS型WAFは閾値モデルやベイジアンネットワーク等を使って進化している。条件毎に加点・減点し、最終的に閾値を超えていたら攻撃と見なすようになっているというのは非常に興味深い。

資料は、こちら 

1 User, 10 Places, 100 Seconds / Matias Madou

今日では、世界中のWEBアプリケーションに対し、1ユーザーが10個所から100秒間に同時ログインを実施するような行為が日常茶飯事に発生している。このようなケースでは、SOCはどのように対処しているのだろうか?殆どのケースでは、SOCに大量のアラートが鳴り響くが、実際に何が起きているかわからない。
理由は簡単だ。SOCではOSやDB、ミドルウェア、ネットワークのログは容易に収集できるが、アプリケーションログに関する情報が足りないからだ。ほとんどがアプリケーションのバグFIXのためのログであり、セキュリティログはほとんど出さない。そのため、冒頭のような事象に対し、ログを相関して分析することができない。


なぜアプリケーションをケアしなければいけないのか。 それは、セキュリティ侵害の84%がアプリケーションに関連づけられたものだからだ。

※2013年ガートナー調べ

なぜこれほどまで圧倒的な数字が多いのだろうか?やはりWEBアプリケーションは攻撃する機会・チャンスが多いこと、さらに利益を得やすい、という現状が関係している。今やスマートフォンの普及に伴い、ソーシャルネットワーキングが爆発的に活用されるようになり、WEBアプリケーションが普及し、あらゆるサービスがDBと直結して、身近に存在する環境となってきている。そのため、DBに存在する機密情報、個人情報を金儲けの材料とすることで、無限に近いほどの機会・チャンスを提供している。攻撃者の立ち位置で考えると、攻撃に対するROIが明確に存在することになるからだ。では、どのようにこれらに対処するのだろうか?何種類か方法があるが、エージェントを利用する技術が確実でBESTな選択となる。エージェントがアプリケーション内のWEBサーバー/ファイル操作/DB関連/ページ呼び出し関連/ミドルウェアに関連するアクティビティを収集する。その中で、セキュリティに関する行為・例外を検知してログに出すことが可能だ。具体的には、アプリケーションのログにソース/デストIPやユーザー名、Login Successfulなどのセキュリティ関連のログを付ける、といったことを行う。
これで第一段階はクリアできる。後は、これらの情報をSOCで可視化し、『容易』かつ『リアルタイム』に確認する必要がある。ここで、ArcSightに代表される「SIEMソリューション」が絶対不可欠となる。SIEMソリューションの能力が高ければ高いほど、複数のログソースにまたがる情報を横断的かつ段階的に検知することが可能となる。もちろん、リアルタイム性は今日のサイバー攻撃に欠かせない要素だ。これにより、冒頭の事象、「同一ユーザが同時刻に異なる国からログインしている行為」を容易に確認できる。また、同じユーザー名で複数回のログイン試行といったBrute Force Attackも容易に検出できる。同様に、最近ホットなReverse Brute Force Attackも検知することが可能となる。以上により、今日のサイバー攻撃に対処するためには、アプリケーションにセキュリティ関連のログを出す仕組みを導入すること、それらのログを高性能なSIEMソリューションで確実に相関分析できること、が重要となる。

資料は、こちら