技術者ブログ

はじめに

H2OはH2O.ai社がOSSとして公開している機械学習の実装です。

筆者が使ってみた感じ、以下のような特徴があるようです

• Javaでフルスクラッチで開発されている
• しかし、PythonやRのユーザも取り込めるように、PythonとRのインターフェースもきちんと用意されている
• 使用できるアルゴリズムの数は非常に少ないが、どれもKaggle等でよく使われる厳選されたものになっている(上画像を参照)
• そのため、「サービスやプロダクトに機械学習を実用する」という視点だと、迷いがなく非常に使いやすい
• 研究や学習向けではなく、完全に実用向き
• 学習時に並列処理が行われるので、マルチコアCPUの良さを十分に活かすことができる。(H2Oでクラスタを作成することもできるようだが、筆者はそちらは調べていない)
• OSSであるが、非常にお金がかかっている印象。UIが洗練されており、ヘルプやドキュメントも含めてとても使いやすい
• 学習の結果生成されたモデルはPOJOとして自動生成されたJavaソースコードの形でダウンロードでき、Javaプロダクトに組み込みやすい
• （H2Oと同じJava製の）WekaやRapidMiner、あるいはPythonやRなどの機械学習環境やライブラリよりも、コンセプトも設計も新しく、ビッグデータ(文字通り、非常に大量のデータ)を扱うことを当たり前のように前提にしている。
• 多くの(主に英語圏の)大企業で実績がある。PayPalの事例などがインターネット上で公開されている
• AutoML機能で、複数のアルゴリズムでのモデル生成やそれらのアンサンブルなどまで一気にやってくれる。有料となるH2O Driverless AIだとさらに凄い(特徴エンジニアリングまでやる)らしい

まだまだ日本語の情報は少なく感じますが、特にJavaのプロダクトに機械学習を導入する際には、非常に有力なソフトウェアだと思います。

HRSとは

2018年の7月に、「XSS due to the header Transfer-Encoding: chunked」というタイトルでPHPの脆弱性報告がありました。

https://bugs.php.net/bug.php?id=76582

日本語の情報源としては徳丸さんによるこちらの記事が参考になります。

この脆弱性は下記のように、HTTPリクエストヘッダ内に一見矛盾していたり、明確でない内容が含まれている場合の挙動についてのものでした。

Transfer-Encoding: chunked
Content-Length: 25

この問題はHTTPリクエストスマグリング(HTTP Request Smuggling、以下HRS)と呼ばれていて、今から13年前、2005年に知られたものです。筆者は今から11年前に「ウェブアプリケーションセキュリティ」という本(通称:金床本)を上梓しましたが、その中で第12章がHTTPリクエストスマグリングの解説に当てられています。

Transfer-Encoding: chunkedとContent-Lengthの両方がリクエスト中に存在するケースというのはHRSの基本中の基本で、2018年になってPHPほどメジャーなソフトウェアにこの脆弱性が出てきたというのは個人的にガックリきました。

しかし、上記でリンクした脆弱性情報のページおよび徳丸さんの記事どちらにおいてもHRSという脆弱性の分類、名前が登場していないことから、意外とHRSは知名度が低いのかもしれません。

はじめに

IPレピュテーションはIPアドレスそのものの信頼性をスコアリングし共有する手法で、主にスパムメール対策において使われてきました。しかし近年では(他社さんの)WAFがウェブアプリケーションへの攻撃を防ぐためにIPレピュテーションを利用する、というケースが増えてきたように感じます。

筆者は、あくまで個人的な感覚としてですが、「IPレピュテーションはウェブの攻撃検知・防御では役に立たないだろう」と思っていたのですが、今回これを客観的に評価してみることにしました。

はじめに

2017年にJoomlaに見つかったLDAPインジェクションの脆弱性、CVE-2017-14596について調査をしたので、簡単にブログにまとめたいと思います。

はじめに

「異常検知したい」と考えている人は多いと思います。もはや囲碁ですら機械が人間を上回る時代となったので、システムの故障を発見したりクレジットカード詐欺を見つけたりという異常検知システムも、データサイエンスを使えば人間以上に優秀なものを作れるのではないか？と考えるのも自然でしょう。

一方で、実際に異常検知システムの開発に乗り出してみたものの、意外と上手く完成まで辿りつけなかったり、せっかく作ったけれども結局誤検知だらけでお蔵入りしたり、というケースもあるのではないかと思います。この記事では実際に異常検知システムをゼロから開発してみた経験からいくつかの点について書いてみたいと思います。

この記事にはアルゴリズム的な、技術的な知見は含まれていません。「もし居酒屋で異常検知をネタに呑むとしたら、このへんで盛り上がるかな」的な記事として書いてみましたので、お時間あるときに気軽に読んでいただけたら幸いです。

HBOSの概要

HBOSはヒストグラムベース、統計ベースの教師なし異常検知アルゴリズムです。非常にシンプルでわかりやすく、論文も読みやすいです。ラベルがついていないデータセットに対して適用し、各データについて異常度(Anomaly Score)を算出してくれます。利用者は結果と相談しながらこの異常度に対して閾値を決め、それ以上を異常として扱うような形で使うことができます。こちらの研究レポートでHBOSが速度・検出精度ともに優秀であることが紹介されています。

XBOSの概要

XBOS(Cross interaction based outlier score)はクラスタリングを使う教師なし異常検知アルゴリズムです。異常と正常両方を含んだラベルなしのデータセットに対して適用し、それぞれのデータに対して異常度のスコア付けを行う形で使用します。発想も実装も非常にシンプルで、Pythonではわずか55行のコードの実装になっています。Scutumにおけるアノマリ検知のために開発されたもので、こちらの記事で書いたようにかなり良い性能を発揮します。

XBOSの処理は大きく2つのステップに分かれており、まずクラスタリングを行い、次にクラスタ間の調整を行います。

はじめに

Scutumでは2017年の初旬からアノマリ検知(異常検知)による防御機能の開発を本格的にスタートし、1年ほどかけて徐々に実用性を高めてきました。ここで行っているのはいわゆる「教師なし学習による異常検知」で、中核としているアルゴリズムはXBOSというものです。

しばらくの間は完全に手探りでシステム開発を進めていて、異常検出のアルゴリズムの定量的な性能については科学的な裏付けに乏しい状態でした。「なんとなく動いている(異常を見つけることができている)ようだから、これでいいか」という感じの状態でデプロイし、結果を見て改善を重ねるというサイクルを繰り返してきた形です。

2018年になり、これまで殆ど目を通すことができていなかった異常検知に関する学術的な情報(論文等)を見ていたところ、いくつか面白い発見がありました。そこで今回、少し自分でも手を動かして調査したポイントのうちの1つ、3つの異常検知アルゴリズムの性能比較をこの記事にまとめてみました。

TL;DR

アプリケーション側の問題をライブラリの責任にするのはどうかと思います(;´Д`)

はじめに

2017年、ついにOWASP Top 10が更新されました。筆者が一番印象的だったのは「Top 10にCSRFが入っていない」ということです。

なぜCSRFが圏外になってしまったのかは4ページのリリースノートで軽く説明されています。「retired, but not forgotten」つまり「引退したね...でも君の事は忘れてないよ」という感じでしょうか。全米がCSRFのために泣きそうです。

それはさておき、具体的には「as many frameworks include CSRF defenses, it was found in only 5% of applications.」という部分が引退理由だと思われます。「多くのフレームワークがCSRF対策を備えた結果、5%のアプリケーションにしかCSRFは見つからなかった」というのが引退の理由です。

この理由を読むと、「ということは、XXEは5%よりも多いのか？」「5%に対して”only”という表現になっているが、5%というのは少ない数値なのか？」「そもそも5%の母集団は何なのか？」など色々な疑問が湧き上がりますが、まぁOWASP Top 10というからには10個にまとめないといけないという性質上、皆が飽き気味のCSRFがスケープゴートにされたというところでしょうか。

さて、OWASP Top 10から引退してしまったとはいえ、CSRFは対策が必要な攻撃手法であり続けます。今回の記事では「2017年時点のCSRF対策」について簡単にまとめてみたいと思います。