FFR Blog

目を逸らさず直視することは、次の一歩に重要なこと

FFRの奥天陽司でございます。

先日某新聞記事に宛てたコメントが様々な反響に繋がっているようで、インターネット上で繰り広げられている意見交換は、逐次チェックをし参考にさせていただいております。

今回の新聞記事により、Twitter含め多くの方の発言で、Windows 2000のサポートが終わっていたことを事後に知ったという方や、自分の会社のパソコンや、サーバーがWindows 2000で動いていることを気にしている方が目立っているように思います。

私も某社で仕事をしているとき、一つの重要な事柄を多くの方に知っていただくことの難しさを経験しました。大手のメディアに社告を打ってもリーチできたのは数％であったり、セキュリティアップデートの重要性を説明しても実際にアップデートの配信が進まなかったり、結果的に自動アップデートの導入で大きな反対を押し切り実施を行い、ようやく今の脆弱性対策の常識作りに成功した、そんな時代もありました。

製品のサポート切れの認知を高めることとは、同じような常識作りに対する挑戦に他ならず、今回の報道についても社会的な共通課題であることを、いかに皆さんと認識しあい次の一歩につなげるか、という部分が重要なのではないかと思います。

メーカーがサポートを打ち切ることは、製品のメンテナンスコストや時代にそぐわなくなった製品であることを明確にするために重要なことで、今回はWindows 2000が10年もの間メンテナンスを続けたことは、評価されるべきものではないかと思っています。メーカーがサポートを終了したことにより、ユーザーは全ての管理の責任を受け取ったということに等しいですし、責任を全うするために何をすべきかを理解することは、見たくは無いものに目を向けなければならない行為なのかもしれません。

で、今回、弊社の盟友でもあるサイバーディフェンス研究所さまと共同で、以下のセミナーを開催することになりました。
 
http://www.fourteenforty.jp/seminar/
タイトルは刺激的ですが、内容も刺激的です。

先日のメディア向け説明会でも指摘しましたが、Windows 2000とそれ以外のOSの脆弱性の共通性とか、Windows 2000の対脅威技術の弱さなど、赤裸々に語られるセミナーです。
懸念のある製品を使うということは、懸念をしっかりと理解することから次の一歩が始まると思いますし、ぜひ一歩を踏み出していただきたいと思っています。

福森さまが、F-Secure Blog に投稿されていますが、
http://blog.f-secure.jp/archives/50428042.html
YouTubeに投稿されたビデオも、激しく危機感をあおります。。。

こちらのセミナー8月10日に日経ホールで開催され、無料で参加いただけます。
お盆前でいろいろと忙しい時期ではございますが、参加をいただければと思います。

私を延命してください

お久しぶりです、FFRの奥天陽司でございます。

ここのところ、Windows 2000のサポート終了に関わるモロモロの活動で、自分のいろいろなものが擦り切れそうです。

7月5日に、少し早めに Windows 2000 のサポート終了に関する啓発を兼ねて、メディアの皆様向けに説明会を開きました。今回は、ソフォス様も同様に、Windows 2000 を使用されているお客様からの要望に合わせ、サポート期間を2012年まで伸ばしたという共通項もあり、一緒にキャンペーンを始めることになりました。

このキャンペーンは、9月30日までFFRの脆弱性攻撃防御機能を20%オフ、同様にソフォス様のEndpointSecurityも20%オフということで、出費を抑えて、移行までの期間をできる限り安全に使ってもらうような取り組みとしております。

このキャンペーンは、Windows 2000 の延命というお題目にはなっていますが、IT業界のはしくれとして、サポート切れ製品を積極的に使うことを奨励したものではありません。最新のポルシェが最良のポルシェ、ではなく最新のIT製品がやっぱりセキュリティ的にも運用管理的にも優れているのは間違いが無いので、ぜひ移行をお願いしたいということで、それらを考えるきっかけにしていただきたいと思っています。

ただ、いろいろな理由で移行できない企業様もありますので、僅かばかりですが金額を下げ、移行期間のセキュリティを可能な限り高めていただきたいという思いで始めたキャンペーンなのです。

5日の発表以降、非常に多くの記事が作成され、新聞でも様々取り上げられる中、日本時間の14日に向けてさらに啓発活動は続くでしょう。

私たちとしても、製品を導入いただくことはありがたいことですが、こういう移行計画はITILのチェンジマネジメントでも指摘されているように、移行計画はしっかりと考えていただきたいと思っています。いろいろお騒がせをしておりますが、皆様が幸福なIT活用を続けていただけることを願っております。

なお、8月からはWindows関連の深刻な脆弱性が公表されましたら、弊社で影響度を調べましてWindows 2000に影響があるものについて、可能な限り情報公開をしようと考えております。
本来は有償サービスで提供していますので、内容はそこそこになると思いますが。。。

Adobe Flash Player and Reader 0-day 脆弱性 vs FFR yarai

村上です。

既に修正プログラムが公開されているため現時点では0-day脆弱性という呼び方は適切ではありませんが、ご存じの通り6月上旬からAdobe Flash PlayerおよびAdobe Readerの脆弱性を悪用した攻撃が確認されています。本脆弱性は、所謂Gumblar型の攻撃（Webを閲覧しただけでウイルスに感染）に悪用可能な類のものです。冒頭でもお話ししましたが既にAdobeから脆弱性を修正済みのプログラムが公開されていますのでまだアップデートを行っていない方は、早急に対応することをお勧めします。

Security update available for Adobe Flash Player

余談ですが、FFR yarai（ZDPエンジン）、また先日製品発表させて頂いたFFR yarai脆弱性攻撃防御機能ともにこの脆弱性を突く攻撃を防御することができています。

ようやく発売開始です！

FFRのセールスマーケティング担当の奥天陽司でございます。

苦節数カ月ようやく『FFR yarai 脆弱性攻撃防御機能』の発売と相成りました！

製品の立案から開発、マーケティング、チャネル整備などいろいろとありましたが、これまでの3階層の多層防御では攻撃を防ぐことが難しくなっている現状に対して、4層目のエンドポイントセキュリティ対策を提案する製品となります。

多層防御（重深防御：Defense in Depth：a.k.a DiD）ですが、もともとネットワーク防御としてファイアウォール、マルウェア防御としてウイルス対策ソフト、脆弱性対策としてセキュリティ更新プログラム、という位置づけでしたが、それぞれが攻撃の進化（というか攻撃者のモチベーションの上昇：職業化といわれてます）に対応が難しくなってきているとFFRでは分析してます。

今回の製品は、脆弱性を悪用しバッファオーバーフローなどの攻撃が成功する間際に、コードの実行を停止するというものです。CPUが持つNX技術(DEP)の基本思想を元に、近年の攻撃に対抗するための強力なコード実行停止ロジックをソフトウェア的に実装したもので、データエリアからコードの実行が行われるタイプの攻撃はほぼ100%検知し、ウイルスに行動を乗っ取られるプロセスを停止、被害の拡散をストップします。

本来、このエンドストッパーが動かない、安定、安全な運用が理想なのですが、前述したように攻撃者は職業化してきていますので、お金が流れさえすれば悪事は絶えない、という悩ましい状況です。

さて、本製品の発売に際して、弊社製品の販売店様から暖かいエールをいただいており、それらはニュースリリースで紹介いただいております。

今回新たにサイバーソリューション様が販売代理店に参加いただく予定となっております。

また、今回は、OEMエディションの話を進めており、NEC Biglobe 様に本製品のコアテクノロジーを組み込んだ会員様向けセキュリティーサービスの提供をご検討頂いております。

そして、Security Operation Center向け製品。こちらは業界の雄である Infosec様、LAC様にご検討頂いております。

まだまだありますよ～。

NEC様より、FFR yaraiをエンドポイント検知エンジンとして使用する『セキュリティ可視化ソリューション』が発表されました。

FFRの技術がいろいろなところで使用いただけるようになるのは、本当にうれしいことです。

お客様に使用いただくことで、弊社として次の技術開発を進めることができます。そして、日本発で世界を唸らせる技術の実現ができたら、やっぱり安全大国の面目躍如ができるんじゃないか、なんて思ってますよ。

ということで、今日9日はINTEROPのNEC様ブースで『セキュリティ可視化ソリューション』の説明してます。もし会場にいらっしゃったかた、小太りなちょっと派手目な中年がいたら私ですので、話しかけてくださいね～

セキュリティを身近にする唯一の方法、なのか？

こんにちは、FFRマーケティング担当の奥天陽司でございます。

いよいよ6月9日にFFR yarai 脆弱性攻撃防御機能の発売日に向けて、準備をしているところでございます。準備といっても、販売網のメンテナンスとか、ソリューションセリングのためのシナリオ作りとか、そういうのがメインです。

発売日の6月9日は、INTEROPに参加しますよ～。例によってFFRはブースを出していないですが、パートナー様のブースに間借りです。詳細は後日～

それにしても、Windows 2000のサポート切れに対して、多くの企業様が様々な課題と懸念をもってシステム運用されていることが垣間見える昨今です。弊社への問い合わせも増えていて、サポート終了後にどのような状況になるのかが見えないので、皆様困っているようです。

お客様のほとんどは、今後1年～2年は運用しなければならないようで、その間のつなぎに投資するか否かで悩まれています。セキュリティ製品は問題が発生しないと効果を体感できないものが多く、ビルの免振機構のような位置づけです。過度に頼ったり期待すると、あとで拍子抜けをする可能性があるので、導入の選定にはしっかりとした目的設定が必要なように思います。

今回はセキュリティと啓発の話です。

セキュリティの仕事をしてて偶に思うのは、あの人はセキュリティを理解していない、とか、言っても分かってもらえないとか、そういう意見。

理解してない、わからない、の善悪は判断できませんし、それぞれの価値観、経験もあるので一概に言えませんが、事前の対策をするためにはセキュリティ確保の重要性を理解をすることは必要条件ということは間違いがないですよね。ここで疑問が。なぜセキュリティの重要性を理解できているひとと、できていない人がいるのでしょうか？

以前の会社で、みんながセキュリティを意識すると全てが変わる、なんて言ってましたが、意識をするなんて曖昧な表現だとモヤモヤします

たとえば物理的なセキュリティは、みなさん真剣に考えるわけです。家の鍵や会社の入り口のガードマン、その他リアルセキュリティに関しては対策しています。ものが盗まれたり壊されたりが目に見える物質世界では、対策の重要性は説明が要らない訳ですね。

物持ちが良い人と、悪い人の違いはどこから生まれるのでしょう？物質に対する認識の違いではないでしょうか。

人間って、子供が育つ過程で本とかぬいぐるみとか、そういうものに触れ、壊し、無くすといった経験を経て感覚として物のありがたさが分かってくるのでしょう。

では、数字、アイディアのようが情報概念として存在しているものは？重要性が分かっている人は、ノートに取ったりコピーをしたり、何らかの方法で保護をしようとします。しかし、生まれてこのかた物ではないモノが失われてしまうことを、誰が教えてくれたかというと、そういう機会はだれも与えてくれていません。

こんな状況で、情報を守ることは重要です！セキュリティは重要です！なんていっても理解されないのは当然です。

セキュリティの啓発をするには、まずは情報（概念）とは何なのか、そこから理解をしなければ。守る守らないは、情報を大切なものとして捉えて初めて議論できるお話ではないかと思ってます。情報そのものは、あることでは意味がない（美術品や工芸品のように、あるだけで意味がある情報なんて無い）わけで、活用してナンボ。利活用してこその情報ですから、セキュリティの話の前に保護する情報がどのようなメリットを与えてくれるものなのか、そこから理解しなければならないんですよね。

弊社製品の説明をするとき、その会社が知識や情報資産をどのように捉え扱っているのか、まずはそこを探るようにしている理由は、意識が無い方にセキュリティ確保が前提の話を押しつけても、きっとドン引きされると思っているから。

そういう人間の面白さに触れられるのも、ITの楽しさかなあ、なんて思ってます～

情報セキュリティEXPO御礼

みなさま大変ご無沙汰しております。
やわらカテゴリー担当の藤田明菜です。

前回の記事からどのくらい経って・・・という話は皆様の優しい心で無かったことにしてください(+_+)ｵﾖﾖｰ

とはいえ、お会いする業界の先輩方、パートナーさんだけではなく、お客様にもご覧頂いている事は喜ばしくもあり、辛くもあり。

「やたらBLOG更新しない、やわらカテゴリーの人」と呼ばれないように気合い入れます！

さて、先日（5/12～14）の情報セキュリティEXPOにてブースにお立ち寄り頂きました皆様、本当にありがとうございましたこの場を借りて御礼申し上げます。

出展いただきましたAITの皆様にも重ねて感謝いたしますm(_ _)m

想定を超えたご来場でブースにお入り頂けなかったり、お待ちいただいたにも関わらずご説明差し上げられなかった方、大変申し訳ありませんでした・・・

もし製品やサービスにご興味をお持ち頂いていらっしゃいましたら、弊社および各販売店様の窓口迄ご連絡いただけましたらご説明にあがりますので、是非ご検討ください。

http://www.fourteenforty.jp/contact/index.htm

EXPOは盛況のうちに終了しましたが、「FFR yarai　脆弱性攻撃防御機能」の発売日まで現在ラストスパートで、スーパーサ●ヤ人状態です（歳がばれる～）

FFRは完全国産の技術研究をしているベンチャー企業ですので、皆様のご意見が製品・サービス向上にとても貴重な情報となります。

RC（Release Candidate）版をご試用頂きました際には、是非ご意見・ご要望をご教示下さいますようお願いいたします

奥天もBLOGでご紹介していますが、「FFR yarai　脆弱性攻撃防御機能」は３つのEditionをご提供する予定です。

http://blog.fourteenforty.jp/blog/2010/05/3editionexpo-9c.html

企業で導入頂くCorp.Edition、SOC（セキュリティオペレーションセンター）にてEndpointのセンサーとして活用頂くためのSOCEdition、そしてOEMEditionです。

それぞれお客様・パートナー様とお話させて頂いておりますが、機能の洗い出しや運用検討含め、最善の形でご提供できるよう一同努めますので、何卒よろしくお願いいたします！

久々の更新が日記のようになってしまいましたが・・・

次回はやわらカテゴリーの本領？発揮？出来るように頑張りますっ

KHOBEに見るTOCTOU問題

セキュリティ技術カテゴリ担当の村上です。今回は、少し前に話題になったKHOBE（Kernel HOoking Bypassing Engine）と呼ばれるセキュリティ機能回避の問題について説明します。

今月5日、matousec.comによってKHOBEと呼ばれる技術を利用することで多くのセキュリティソフトが備えるセキュリティ機能が回避可能であることが報告されました。こうしたセキュリティソフトの多くは、APIフックを行うことでOSが提供している正規の処理をインターセプトし、独自のセキュリティ機能を実装した代替処理を実行します。例えば、統合セキュリティソフトやデスクトップIPSの場合、マルウェアによって自身のプロセスが強制終了させられないようにプロセスを停止させるAPI、サービスを停止させるAPI、ドライバをアンロードするAPI等をフックしているケースがあります。他にもファイル、レジストリ、プロセス等へのアクセス制御を実現するためにこうしたリソースにアクセスするAPIをフックし、定義されたポリシーとの比較検証ロジックを実装しているケースも存在します。KHOBEは、セキュリティ機能をバイパスする技術です。

この問題は、APIフックの代替関数における引数の取扱いに起因します。例えば、OSが提供しているファイルを開くAPIをフックするケースを考えてみましょう。ここでは当該APIを便宜上、OpenFileと呼びます。APIフックを行うプログラムは、このOpenFile APIを、独自のセキュリティ機能を実装したCustomOpenFile関数でフックします。以下にAPIフックを行うプログラムの疑似コードを示します。


---

some_func(...)
{
　　// OpenFile APIをCustomOpenFile関数でフックし、
　　// OpenFile APIのアドレスをOrigOpenFileに保存する

　　OrigOpenFile = ApiHook(OpenFile, CustomOpenFile);
　　...
}

CustomOpenFile(char *filename, ...)
{
　　// ファイルオープンの妥当性を引数に含まれる
　　// filenameに基づいて比較検証する

　　if (filename && check_policy(filename)) {
　　　　return ACCESS_DENIED;
　　}

　　// ※1

　　// 保存しておいたアドレスを利用して、元のOpenFile APIを呼び出す
　　return OrigOpenFile(filename, ...);
}

---

一見するとなんの問題もないように見えますが、CustomOpenFile関数にはレースコンディションの脆弱性が存在します。これは、より具体的には、TOCTOU(time-of-check, time-of-use)問題と呼ばれており、攻撃者は、※1のfilenameチェック後のタイミングでfilenameを変更することで、チェックを回避してOrigOpenFile APIを呼び出すことができます。
攻撃を行うプログラムは、例えばマルチスレッドで動作し、スレッドAがOpenFileを繰り返し呼び出し、スレッドBがスレッドA中で呼び出されたOpenFile APIの引数であるfilenameを絶えず変更します。スレッドBのfilenameの変更がちょうど※1のタイミングで行われれば、チェックを回避することが可能です。

ご想像の通り一回でこの攻撃を成功させることは確率的に考えて非常に難しく、数千回、数万回試行してやっと一回成功する、という性質の問題です。攻撃の成功確率はプロセッサ環境（シングル・マルチプロセッサ）、値のチェックと利用の間に行われる処理の有無・量、タスクスケジューラーの実装等によって変動します。とは言っても、一回でも成功すればそれで十分というケースもあるため軽視することはできません。対策としては、チェック時の値が実際に利用されることを保証する必要があります。そのため、下記のような修正が有効です。


---
CustomOpenFile(char *filename, ...)
{
　　char *copy_filename = NULL;
　　int ret;

　　if (!filename)
　　　　return OrigOpenFile(NULL, ...);

　　// filenameのコピーを作成する
　　// ※このstrdupは必ず成功する

　　copy_filename = strdup(filename);

　　// 作成したコピーを利用してチェックを行う

　　if (check_policy(copy_filename)) {
　　　　// 関数を抜ける前にコピーを解放する
　　　　free(copy_filename);
　　　　return ACCESS_DENIED;
　　}

　　// 作成したコピーを利用する

　　ret = OrigOpenFile(copy_filename, ...);

　　// 関数を抜ける前にコピーを解放する

　　free(filename);

　　reutrn ret;
}
---

matousec.comの報告では、実際に多くのセキュリティ製品がこうした問題を含んでおりセキュリティ機能を回避することが可能とのことです。興味のある方は、一次情報もチェックするお勧めします。余談ですが、一次情報では、SSDTフックを例に問題の説明がされていますが、この問題自体はSSDTフックに限らずフック全般に関連した実装の脆弱性だと言えます。

KHOBE – 8.0 earthquake for Windows desktop security software