FFR Blog

Windows XPのデータ実行防止

はじめまして、リサーチチームの本郷です。
日々のリサーチの中で気がついたちょっとしたことを紹介していきたいと思います。
どうぞよろしくお願いします。

今回はWindows のデータ実行防止(Data Execution Prevention 以下DEP)について話したいと思います。

DEPはWindows XP SP2 および Windows Server 2003 SP1から導入されたWindows のセキュリティ機構の一つです。

DEPにはソフトウェアDEPとハードウェアDEPがありますが、今回はハードウェアDEPについて取り上げます。

メモリ内部のセクションには大きく分けて、コードセクションとデータセクションがあります。コードセクションでは読み・実行が許可されており、データセクションでは読み・書きが許可されています(ここではそういう解釈で話を進めます)。

DEPはメモリ内の実行不可領域でのコード実行を防ぐもので、許可されてない領域でコードを実行しようとすると例外が発生します。

みなさんもこのような画面を見たことがあるのではないでしょうか

DEPの設定

DEPは4つの設定が用意されており、OptIn、OptOut、AlwaysOn、AlwaysOffがあります。

・OptIn
特定のプログラム(システムプログラムなど)のみDEPが適用されます。
・OptOut
すべてのプログラムにDEPが適用され、指定されたプログラムのDEPを解除することが可能です。
・AlwaysOn
すべてのプログラムにDEPが適用されます。
・AlwaysOff
すべてのプログラムにDEPが適用されません。

現在の状態はbootcfg /Queryで確認することができます。

Windows XP ではデフォルトでOptInに設定されており、特定のプログラムにだけDEPが適用されています。

システムのプロパティの詳細設定->パフォーマンス オプションのデータ実行防止タブから「次に選択するものを除くすべてのプログラムおよびサービスについてDEPを有効にする」を選択することでOptInからOptOutに変更することが可能です。

画面の状態はOptInに設定されている状態です。

AlwaysOnやAlwaysOffにする場合はboot.iniファイルを変更する必要があります。

各プロセスに対するDEPの設定

DEPはプロセスごとに設定されます。DEPが設定されている場合の設定として、通常のDEPとDEP(permanent)があります。

通常のDEPに設定されている場合は、アプリケーション実行後にDEPの設定を変更することができ、DEP(permanent)に設定されている場合、DEPの設定を変更することはできません。

通常のDEPが適用されている場合、NtSetProcessInformation APIを使用することでDEPのON/OFFを操作することが可能です。
そのため、以前このブログでも紹介したReturn-Into-Libcを利用して、NtSetProcessInformation APIでDEPを無効化することで、実行不可領域に置いた攻撃コードを実行することが可能となります。

この手法は、NtSetProcessInformation API 呼び出しの際、引数にNULLバイトが必要となるため、
文字列処理のAPIによるバッファオーバーフローなどの脆弱性を利用する場合には使えません。

また、Uninformed - vol 2 article 4 でntdll内部のマシン語命令を利用してDEPを回避する方法が紹介されています。

Uninformed - vol 2 article 4

一方、DEP(permanent)はこのNtSetProcessInformationを使用してもON/OFFを切り替えることはできません。よって上述した攻撃を防ぐことが可能です。

Windows XP でデフォルトではDEP(permanent)は有効になっておらず、DEP(permanent)を有効にしたい場合は、AlwaysOnに設定するか、OptIn/OptOutに設定し、アプリケーション内部でDEP(permanent)を有効にする必要があります。
そのため、ユーザー側でDEP(permanent)にするにはAlwaysOnを選択する必要があります。

また、プロセスごとのDEPの適用状態はSysinternal SuiteのProcessExplorerで確認することができます(Vista以降であれば、タスクマネージャーから確認できます)。
Google ChromeやFirefoxではOptIn/OptOutの場合もDEP(permanent)となっていることが確認できます。

アプリケーション開発時の設定

アプリケーション開発時に/NXCOMPAT オプションを有効にしてリンクした場合、Vista以降ではDEP(permanent)が有効になるのですがXPでは適用されません。

前述の通り、システムがOptInおよびOptOutに設定されている場合にDEP(permanent)を有効にするには
アプリケーション内で明示的に有効にしてあげる必要があります。
Windows XP SP3 からはSetProcessDEPPolicy APIを使用することで、DEP(permanent)に設定することが可能です。
実際、SetProcessDEPPolicy API内部でNtSetProcessInformation APIを呼び出し、設定を行っています。

Windows XP SP3上でOptIn、OptOutが適用されている場合に/NXCOMPAT オプションをつけてリンクしたDep.exeとDEP(permanent)をアプリケーション内部で有効にしたDepPermanent.exeの違いを比較してみます。

ProcessExplorer上で通常のDEPが適用されている場合はDEPと表示され、DEP(permanent)が適用されている場合にはDEP(permanent)が表示されます。

システムにOptInが適用されている場合
Dep.exeはDEPが適用されていないが、DepPermanent.exeにはDEP(permanent)が適用されています。

システムにOptOutが適用されている場合
Dep.exeはDEPが適用されており、DepPermanent.exeにはDEP(permanent)が適用されています。

このようにWindows XPのデフォルト設定では、特定のアプリケーションにのみDEPが適用されています。デフォルトの設定で使用しているユーザーが多いことを考えると、アプリケーションを開発する側でDEPの設定を行ってあげることで、攻撃の可能性を減らすことが可能です。

---
このブログ中における株式会社フォティーンフォティ技術研究所（以下FFR）の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

ヒヤリハット、といっても別のこと

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

昨日は前職の人、OBなんかと吞み会でした。FFR Blogのこと、みなさん注目してくれているみたいです、ありがとうございますっ！
Connect24さんなんて、Twitterで私の異動の話までネタにして。。。ありがとうございます、なんて言うかー！
小島センセも、まっちゃさんも、いろいろコメントありがとうございます～
道場、マジで新装開店してしまおうと、マーケティングプラン作成が山積みのなかブログに書いてみた。。。おや誰か来たようだ。。。

さてさて。

前に、某セキュリティ業界人（結構知られてる業界のブルドーザー）が話をしてたこと、いつも思い出します。

ヒヤリハットの法則。。。ただしくはハインリッヒの法則です。マーケティングでもよくつかわれる話です。300回ヒヤッとしたりハッとしたりするなかには29回の小さな事故があって、１回は大きな事故につながるという統計から導き出されたお話。

最初入った会社は大きな工場を持ってまして、始業前に危険予知(KY)訓練をしました。
チームが輪になって5分くらいかけて、工具箱があると躓いて転びます！ケーブルが乱雑だと足が引っ掛かり転びます！走ると物陰から出てきた台車とぶつかり・・・みたいな。

つまり、事前に仮想体験をさせてヒヤリハットを減らしてゆくという考え方なのかな～？
やってる最中は全然理解できなかったけど、今の仕事をしていてよくわかる訓練でした。

私、車が好きで自分の車でレーストラック（サーキット）に行くことが多かった（お金かかるのでやめちゃいました）のですが、自動車競技は車を壊す人もいるし、けがしてしまう人もいるわけですが、実はサーキット内で亡くなる方はとても少ないわけ（年間1名くらい？）です。安全な環境下で危険（スリルいっぱい）な行為をするって矛盾しますが、スリルを低リスクで体験できると考えると、ちょっとオモロいですよね。

サーキットで走ってて、慣れてくるとそれなりになってきて、欲を出したときにコースアウト！っていうのが流れですが、２９回のコースアウトには３００回のヒヤリハットが。。。これ、自分的には言い得て妙です。１回の事故。。。もっと多い気がしますケド
たぶん同じような趣味を持っている方もそう思っているのでは。だからこそ、メット被って、夏なのに長袖で、手袋臭いし、でも危険予知できているので我慢できると。

さて、我らが情報セキュリティ、この法則当てはまりますかね？

イライラしてもマウスをクリック連打しないこと！膀胱が張り裂けそうでもスクリーンロックすること！個人情報にアクセスするときには情報がデータファイルに保存できないよう以下同文！みたいなことを危険予知しても意味ないのかな～。

社内でセキュリティ意識が高まっていれば、当然当事者感覚も高まっているはず、なのでしょうか？

それは難しいと誰でも言いますよね。当然です。

それには理由があるはず、ということで次は陳腐な私なりの意見を書いてみます。
といっても6年前位に頻繁に講演で話をしていた考え方なので、聞いた方もいらっしゃると思いますケド

セキュリティを形にする日本のエンジニア - こぼれ話 -

こんにちは。石山です。

今回は、@ITさんに掲載されているFFR yaraiの連載「セキュリティを形にする日本のエンジニア」の第3回で掲載したZDPエンジンのこぼれ話についてお話したいと思います。@ITさんで掲載されている連載については以下で読めますので、まだ読んでいない方はこちらも参照してみてください。

この脆弱性対策エンジンは"永遠に完成しない

○ 名前の由来
まずZDPの名前の由来ですが、FFRの配布しているyaraiのパンフレットには"Zero-day vulnerability Detection and Prevention Engine"と書いてあります。つまり、0-Day脆弱性を検知、遮断するエンジンということです。しかし、石山が当初ZDPと名前を付けた時は、"Zero Day Prevention"という意味でつけていました。開発者的には正式には違いますと言ったところなのですが、新しい名称のほうがそれらしいということで特に気にしていません。この話は、今初めて公表しているので、おそらくFFR社員も知らないことだと思います。

○ コンセプトコードでWindowsにログオンできなくなる
ZDPエンジンでは、スタックのバックトレースを検査してShellcodeの実行を検出しているのですが、このコンセプトコード自体は開発前から存在していました。ZDPエンジンの開発時にまずはこのコンセプトコードの動作を見てみようということで、石山の作業マシンにインストールして実行してみたのですが、再起動を行った際にWindowsのログオン画面で誤検出が発生してしまいました。コンセプトコードでは、攻撃を検出した場合にメッセージボックスを表示しているのですが、メッセージボックスを消しても再度メッセージボックスが表示されるという事態になってしまいました。そのため、ログオン画面でユーザ名とパスワードを入力することができず、Windowsにログオンできなくなりました。

とりあえず、セーフモードで起動させてコンセプトコードのモジュールを削除しようと思ったのですが、ここでもログオン画面でメッセージボックスが表示されセーフモードでもログオンできない状態になってしまいました。

結局、CDからLinuxを起動させてコンセプトコードのモジュールを削除することでログオンできるようになったのですが、Windowsを構成しているモジュールでも誤検出することがあるということがわかり、今後の開発で誤検出について敏感になって開発することになりました。

○ 特殊環境で動作しているが故の不具合
ZDPエンジンは、API呼び出し時にスタックトレースを調査し、Exploitの実行を検出するという動作になっています。このため、ZDPエンジンの動作する環境は普通のアプリケーションに比べると特殊な環境で動作するアプリケーションとなっています。そのため、通常のアプリケーションでは発生しないような不具合がいくつかありました。

たとえば、CreateFileでファイル書き込みを監視する場合、ZDPエンジンではAPI HOOKを使用して監視を行っているため、監視ロジック内でログ出力のためCreateFileを実行してしまうと、監視ロジック内のCreateFile呼び出しでさらに監視ロジックが動作していしまい結果的に再帰呼び出しになってしまいます。そのため、ZDPエンジンの監視ロジック内では呼び出すAPIについての注意も必要でした。

こういった普段のプログラミングでは起こらないような不具合を乗り越えてZDPエンジンが開発されました。そのため、やはり開発者としてはZDPエンジンに対する思い入れは強いものがあります。ZDPエンジンが今後も長く使用されていくようなソフトウェアになっていくことを願っています。

---

このブログ中における株式会社フォティーンフォティ技術研究所（以下FFR）の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

[FFRUA-20100329] オペレーティングシステムのコンポーネント脆弱性

■ 報告日:
2010年3月24日

■ 概要:
フォティーンフォティ技術研究所リサーチチームは、一般に広く利用されているオペレーティングシステムにおいて、ネットワーク経由でDoS攻撃が可能な脆弱性を発見しました。特別に細工されたIPv6パケットを送信することで対象をクラッシュ、あるいは再起動することができます。

■ 深刻度:
中

■ 対象OS：
非公開

■ 脆弱性情報の取り扱い:
本脆弱性は、情報処理推進機構(IPA)の「情報セキュリティ早期警戒パートナーシップガイド」に従って処理されます。
http://www.ipa.go.jp/security/vuln/

■ ステータス:
IPA脆弱性情報届出窓口に届出済
製品開発ベンダーに連絡済

Zeus Botnet

金居です。

2 週間ほど前、SecureWorks から ZeuS ボットネットに関する興味深いレポートが公開されたので、まずはその一部を紹介したいと思います。

■ ZeuS Banking Trojan Report (SecureWorks)
http://www.secureworks.com/research/threats/zeus/

そもそも、ZeuS とはどういったものでしょうか？

レポートの中では、銀行向けのトロイの木馬型プログラムで、「crimeware」つまり犯罪プログラムとしても知られているとのことです。また、アンダーグラウンドで販売されているソフトウェアキットで $3000 ～ $4000 という価格がついているとも説明されています。「アンダーグランド」と書きましたが原文では「the criminal underground」となっており愉快犯や興味本位の技術者集団などではなく犯罪を目的とした社会組織としてのアンダーグランドの存在を示唆しています。

Wikipedia の説明でもやはり銀行をターゲットにしているとあり、キーロガーにより銀行の情報を盗むと説明されています。

■ Wikipedia: Zeus (Trojan horse)
http://en.wikipedia.org/wiki/Zeus_%28trojan_horse%29

SecureWorks のペーパーによると様々な機能があるようなのですが、驚くべきことにハードウェアベースのライセンス機能が搭載されているというのです。1ライセンスを購入すると、特定の1つのマシンでしか ZeuS Builder キットを実行できないようになっていると書かれています。皮肉なことですが、ZeuS が不正コピーの被害者になったことがあるのでしょう。

シェアウェアや商用ソフトウェアであればライセンスシステムを持っているのが通常ですが、今までこのようなプログラムがハードウェアベースのライセンス機能を持っているとは聞いたことがありません。ライセンス機能、特にハードウェアベースのある程度しっかりしているものを開発したのだとすると、今後も継続的にソフトウェア販売でビジネスを行うつもりがあってそれが可能だと開発側は思っているという事でしょう。

他にも、現在開発中の機能についても書かれています。どうやってインタビューしたのでしょうか。以下の機能を持つ次期バージョンが開発中で今ベータテスト中だということです。

1. Web Injects for Firefox
2. Polymorphic Encryption

2 の「Polymorphic Encryption」というのはセキュリティ製品対策の機能です。マルウェアの中には自分で自分を暗号化しているものがあります。これによりセキュリティ研究者による解析を困難にしたり、セキュリティ製品からの検出を困難にしたりしています。これが「Encryption」の部分の機能です。

ただし、セキュリティベンダーが検体を入手しさえすれば、いずれはパターンベースのエンジンで検出されるようになってしまいます。これは、自分自身を暗号化しても変わりません。一方でパターンベースの技術は基本的には一人目の被害者を救うことができないという原理上の難点があります。これは、乱暴な言い方をしてしまえば、誰かが感染して検体を入手するまでパターンが作れないことを意味しています。

そこで、最近のマルウェアのトレンドとしては、多くの種類のマルウェアが頻繁にリリースされるようになりました。これにより、パターンの配信がおいつかずパターンベースのエンジンがあまり有効に機能しなくなってきています。

「Polymorphic Encryption」という機能は、この攻撃側の考え方をさらに進化させたものと言えます。つまり、感染するパソコン毎に異なるマルウェアを作ってしまおうという機能のようです。どの程度の完成度なのか分かりませんが、PC 毎に完全に異なるマルウェアが生成できるのだとしたら、パターンベースのエンジンはまったく意味のないものになってしまうでしょう。

セキュリティベンダー各社が、こういった次世代マルウェアに対してどのようなソリューションで対応するのか注意して見守る必要がありそうです。ちなみに、弊社では「Polymorphic Encryption」に似た機能を持ったマルウェアを確認していました。別の機会に、どのように未知のマルウェアを検出しているのか説明できたらと思います。

---

このブログ中における株式会社フォティーンフォティ技術研究所（以下FFR）の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

そもそもセキュリティを高めるって？

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

ちょっと哲学的になりそうな投稿なので、ゲンナリしないこと～

私がセキュリティの仕事を始めるまえ、セキュリティ＝管理、認証、制御、暗号、的なファンクションとしての話が多かったように思います。それでも、IISとかIEの技術チームを見ていたので、人一倍セキュリティに関する知識はあったと思います。

でも、2001年からのウイルス騒ぎで、セキュリティ（というかthreat:脅威）が一気に可視化（みえる化）したように思います。

あー、だからこれって必要だったのか～とか、これってこのままじゃこの脅威に対応できないじゃね？とか、この穴（脆弱性）ってセキュリティ機能を全部バイパスすんじゃね？みたいな。

そこから坂道を転げ落ちるように（表現間違えてます）セキュリティの仕事に埋もれて行きましたが、常に何かを何かから守る、ということが眼前に迫っていて、とてもわかりやすい業態でした。

昨今クラウドなどがバズワードであり続けていますが、たぶん単純な一言で表せられるところまで意味がブレイクダウンされて認知されれば、一気に広がるんだろうな～と思ってます。

で、問題は今のセキュリティ業界。私は2006年にセキュリティ業界をいったん離れたのですが、そこから今までの４年間、ITコンプライアンスとかガバナンスとかいうポリシー関係の活動に傾倒しすぎたのではないかと思っています。もちろんポリシーって重要ですし、フレームワークって必要。でも問題は、何から何を守るために何をするのか、があいまいになってしまい、ポリシーを整備するためにポリシーを作っているみたいな錯覚に陥ってないかな、ということなのです。

セキュリティの基本は、セキュリティバイオレーションになる脅威を排除すること、日常の安定性を維持してゆくこと、なわけで、そのためのルール、評価をするためのポリシーなので、ポリシー組んだらオッケー！みたいな話にはならないです。

という話を会社が変わる前に、この業界に前からいるオジ様（名前伏せ、絶対）と語らったわけです。

今セキュリティ業界も必要としていることは、クラウドをメインストリームに引っ張り上げるのと同じように、一言で言い表せる業界としての価値と、その相互認識、なんじゃないかな～って思ってます。

---

このブログ中における株式会社フォティーンフォティ技術研究所（以下FFR）の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

花粉症デビュー

みなさんこんにちはやわらカテゴリー担当の藤田明菜です。
FFRのやわらカテゴリー、だいぶ間があいてしまいましたが・・・記念すべきブログ第一回です
投稿するまで、とにかく何度も修正していて、最初に書こうと思った内容とずいぶん違ってますが、初心者ということでお許しを～

桜の開花宣言がされ、とうとう本格的な春になりましたね
春といえば、お花見、新年度、なにかとウキウキする季節・・・でした。

去年までは。

そう、とうとうデビューしてしまったのです。

花粉症

去年までは他人事だったのに、いまや、マスクや薬、ヨーグルトに至るまで、なにか少しでも症状が緩和できないか、花粉を防ぐ策がないか、と模索する日々です。
ぜひ私の目と鼻を救ってくださーい。対策方法をトラックバックで教えてくださーい！

で、何でしょう、この何とも言い表せない目のかゆみと鼻のムズムズ。。。
ボーっとする頭でモヤモヤ考えているうちに、何かひらめきました。ん？この感じ、どこかで・・・？

「まさか私（ウチ）が」

「経験しないと正直わからない」

これって、私がお客様に訪問してセキュリティ対策について話を伺っている時に、お客様が毎回コメントされる定型句なんですね（笑）
前者は、何かしらのインシデントが発生してしまったケース。
後者は、幸運にも問題に直面していないケース。
みたいな気がします。

何事も当事者意識って重要で、本当は事が起こる前に予防しておかなければいけないわけですよね

気が付いていれば、マスクをするとか、手を洗うとか、その季節には出歩かないとか、対処できたはずじゃないですか

どうして何もしてこなかったの！？私のバカバカ～～

これが現実なのです。皆様も、システムの安全管理についてはくれぐれも当事者意識を忘れずに、しっかり事前対応してくださいね。

じゃないと、私のようになってしまうかも・・・

人のフリ見て我がフリ直せ、ならぬ

藤田のフリ見て皆様のフリを直して頂けましたら本望でございます。

---

このブログ中における株式会社フォティーンフォティ技術研究所（以下FFR）の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

やっぱ持つべきものは友よね♪

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

ブログも３発目の投稿になると、あっという間に "ネタが" なんてことになりがちですが、そこは長年のキャリアで乗り越えてまいります。
ネタといえば、以前の会社で "師匠キャラ" で川柳とか書いてました。
これがもう大変で、技術的仕事（講演含む）、マーケ的仕事、マネージャ的仕事に加えて、コミュニティ的仕事ということで、才能もないのに脳汁絞り出して書いてました。
だいたい夜仕事が終わってから、ぼーっと句を考えて、閃いて書く！閃いて書く！！閃いて忘れて泣く　の繰り返し。
句ができても、そこからコメント書いてー、次にキャラに合わせて表現変えてー、なんてことやってるから時間掛かるんですけどね。

興味があったら、私の名前と川柳で検索してみてくださいませ。
もしかすると、FFRで師匠キャラ復活させようかな～なんてね。

さて、今日のトピックは、先日３月２日に発表会をした "Web感染型マルウェア対策コミュニティ"　のお話です。
上の会の名前でググってみてくださいな。いっぱい記事がでてきます。

そもそもなんでこんな任意団体を作るようになったのか、そこ重要。
FFRはセキュリティ製品を作る会社なんだから、それを売るためなんじゃないの？って思ってる方残念でした。どっちかというと逆です。

FFRの製品を使っていても、最近のガンブラー型の Web Malware っていろいろ対策が難しいんですよね。なにせ、対策すべきフェーズが多すぎるし、敵もさる者で解析すらままならない。で、今でこそコミュニティのメンバーさんですけど、各社と話をしていて不安感いっぱいだったわけです。対策しても次、また次、って感じで後追いになってしまうのです。
で思ったことは、他力に頼らず、みんなで具体的な対策を見据えて意見交換しちゃおうぜ！って話になり、サービスしている会社からは直近の情報を、FFRはウイルスの解析とか、システム的に防御するべきものはインテグレーターさんと、みたいな感じで、各強みを持つ仲間を引っ張り込んで、みんなで協力してゆきましょう♪って言う感じなんです。

つまり、我々業界としても、攻撃側に蹂躙されてしまっているので、"スクラム組んでガチンコ勝負"。。。すみません、オジサン的表現です。
まだどういう風に会の成果を見せてゆけるのか、手探りの状況ではありますが、みなさんこれからの活動にワクワクしてくれていたようです。

いずれにしても、今の現状を考えると（Webの改ざんだけじゃなくて、既に配布されてしまっているウイルスの個体数も半端じゃないはず）何かしら事を起こさないとならないと思ってますし、セキュリティ業界だけではなく、ITで飯を食ってる人、仕事している人、楽しんでる人皆さん等しく重要なステークホルダー（関係者）ですので、真剣に取り組んでゆきたいですね♪

ちうことで、事務局としてこのコミュニティに貢献してまいりますので、ぜひ皆様の企業もご参加を～
参加条件は、”Web感染型マルウェアって怖いからなんとかした～い”という思いのある企業の担当の方、webmalwarecom あっと fourteenforty.jpまでご連絡くださいませ。

---
このブログ中における株式会社フォティーンフォティ技術研究所（以下FFR）の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

Windows Vistaからの保護機能：保護モードと整合性レベル

こんにちは、リサーチエンジニアの丹田です。Windowsのさまざまな仕組み（やその他もろもろ）を、わかりやすくお伝えしていきたいと思っています。どうぞよろしくお願いします。

今回はWindows Vistaから導入されたInternet Explorerの「保護モード」と、その背景にある「整合性レベル」についてお話しします。

保護モードとは、Internet Explorerの動作権限を自動的に小さくすることで、Internet Explorerが攻撃を受けてしまった場合でもその影響を抑えることができる仕組みです。この仕組みには、Windows Vistaからの新しい権限管理機能「整合性レベル（Integrity Level）」が利用されています。今回は、これらの仕組みがなぜ必要で、どのように機能するかについて見ていきます。

●保護モードの必要性

先日の記事でもありましたが、Internet Explorerに未修正の脆弱性が見つかりました。Internet Explorerなどのウェブブラウザーの脆弱性は、そのウェブブラウザーの利用者が攻撃用のウェブページにアクセスしただけで脆弱性が突かれ、悪意あるコードが実行されてしまうケースがあります。Microsoftのセキュリティアドバイザリによれば、今回の脆弱性もこのような攻撃シナリオが想定されています。

仮に脆弱性に対する攻撃が成立してしまった場合、多くの場合その脆弱性を持つプロセスが攻撃コードを実行するため、攻撃コードの動作権限は、その脆弱性を持つプロセスの動作権限と同じになります。Windowsは管理者権限のアカウントで利用されていることが多く、攻撃コードも管理者権限で動作することになってしまいます。

そこで Microsoft は、Internet Explorer 7 から「保護モード」と呼ばれる仕組みを導入しました。

●保護モードと整合性レベルの働き

保護モードは、冒頭でも触れたとおり「整合性レベル」という機能を利用して実現されています。整合性レベルとは、プロセスそれぞれに対して「整合性レベル：高/中/低」という3つの権限レベルを割り当て、これを基に、従来のアカウントベースの権限チェックに先立ってアクセス権の検証を行うものです。

整合性レベルが低いほど動作は制限され、保護モードで動作する Internet Explorerは整合性レベル「低」で動作するようになります。これにより、万が一Internet Explorerの脆弱性が突かれ、攻撃コードが実行されてしまった場合でも、システムに対する影響を最小化できます。

以下に、それぞれの整合性レベルによるアクセス権の違いの一部を示します。

• 整合性レベル「高」のプロセスはいわゆる昇格したプロセスです。システム全体に関する場所への書き込みが可能です。たとえば、Program FilesやWindowsフォルダ以下、HKEY_LOCAL_MACHINE以下など、ほぼ無制限に環境を変更できます。
• 整合性レベル「中」のプロセスは通常のプロセスです。そのプロセスを動作させたユーザー環境だけに関する場所への書き込みが可能です。たとえば%USERPROFILE%以下や、HKEY_CURRENT_USER以下を変更できます。
• 整合性レベル「低」のプロセスは制限されたプロセスです。特別に許可された場所だけへの書き込みが可能です。たとえば%USERPROFILE%\AppData\Local\Microsoft\Windows\Temporary Internet Files\Low以下や、HKEY_CURRENT_USER\Software\LowRegistry以下を変更できます。

保護モードによって整合性レベル「低」で動作するInternet Explorerは、上記のような制限が設けられ、攻撃コードの影響範囲が抑えられます。

なお、あるフォルダが整合性レベル「低」でも書き込み否かを確認するには、icaclsコマンドを利用できます。次の画像は、icaclsコマンドを使い整合性レベル「低」でも書き込み可能なフォルダであることを確認しています。

icaclsコマンドによる設定の確認

●整合性レベルの決定

では、この保護モードを実装する、プロセスの整合性レベルがどのように決まるかを簡単にまとめます。これは通常、UAC（User Account Control）の設定状態とアカウントの権限によって次のように決まります。

• UAC が無効の状態で、制限ユーザーが起動したプロセスの整合性レベルは「中」になります。
• UAC が無効の状態で、管理者が起動したプロセスの整合性レベルは「高」になります
• UAC が有効の状態で、保護モードを有効にしたInternet Exploreの整合性レベルは「低」になります。
• UAC が有効の状態で、制限ユーザーが起動したプロセスの整合性レベルは「中」になります。
• UAC が有効の状態で、管理者が起動したプロセスの整合性レベルは「中」になります。
• UAC が有効の状態で、「管理者として実行」により起動したプロセスの整合性レベルは「高」になります。

プロセスの整合性レベルはProcess Explorerを使って簡単に確認できます。Process Explorerでは整合性レベルの高中低が、それぞれ「Integrity」列に High、Medium、Lowと表示されます。

次の画像は、UAC が有効の環境において、それぞれ次の方法でInternet Explorerを起動した様子です。整合性レベルの違いが確認できるかと思います。

• 「管理者として実行」により起動したもの（Integrity: High）
• 保護モードを無効で起動したもの（Integrity: Medium）
• 保護モードを有効で起動したもの（Integrity: Low）

Internet Explorerの各動作状態における整合性レベルの表示

なお、UAC が無効の場合、２つの点で注意が必要です。

1. 保護モードは自動的に無効になります。つまり整合性レベルは「低」にならず、上記のルールに基づいて「中」や「高」が設定されます。
2. 管理者が起動したプロセスの整合性レベルは「高」になります。これはWindows XP 以前と同様の使い勝手を実現しますが、プロセスが攻撃を受けた場合のリスクが高まります。

UAC を無効にする場合、これらの点を考慮するようにしてください。

以上です。いかがでしたでしょうか。最後に、保護モードや整合性レベルについてのより詳細な資料をいくつかご紹介します。これらの情報が、Windowsの安全な利用の助けとなれば幸いです。

●参考資料

• Windows Vista のアクセス制御メカニズムと保護モードの Internet Explorer（PPT）
• Understanding and Working in Protected Mode Internet Explorer
• アプリケーション開発者向け Microsoft Windows 7 対応アプリケーションの互換性

---

このブログ中における株式会社フォティーンフォティ技術研究所（以下FFR）の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

消えゆく市場へのマーケティング

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

ようやくブログの開始と相成り、おかげさまで沢山のアクセスをしていただき、本当にありがとうございます。
FFR は、非常に個性的な人間が集う面白い会社で、ベンチャーらしくやることも山積みななか、パッションだけで生きております

さて、おかげさまで弊社の製品ラインナップも徐々にそろってきて、ニッチな市場に対して投下された製品でありながらも、非常に引き合いの多い製品があります。
本年1月に発表した　"FFR yarai 脆弱性攻撃防御機能 for Windows 2000" です。
http://www.fourteenforty.jp/products/yarai2000/

最初この製品の企画を出したとき、いまさら Windows 2000 向けの製品かよ～！という罵倒の声が社内にこだまし、なかなか話が進まなかった記憶があります。そりゃそうです。既に時代はWindows Server 2008ですし。Windows 7 ですし。マイクロソフトがサポートを終了直前の製品に対して、新製品をリリースするなんて、暴挙に見えたでしょう。

ただ、Windows 2000は私にも思い出深い製品で、いまだ一線で活躍していることは知っていました。
3階層アプリが全盛で、NASも無いころ多くのお客様がファイルサーバー、アプリケーションサーバーとして活用されていました。
以前某外資系で働いていたときに、ライフサイクルの責任者もしていましたので、まだまだ使える製品がメンテされなくなってしまう悲哀を肌身で感じていました。お客様もこのご時世に簡単にアップグレードは難しかろう、と思っての企画だったわけです。

あるとき、あるお客様に訪問した時 FFR yarai の説明をし終わったときに、衝撃的な一言が。
「FFRさんさ～、業務のクライアントは新しいウイルス対策ソフトに変えたばっかりなんだよね。

ただ、社内で問題になっているのは Windows　2000 なんだよ。

新しい OS ではドライバが無いので周辺機器が動かず、ソフトも動かない。だからといって全て移行する予算は削減されてしまった。もちろん、セキュリティポリシーで脆弱性対策していないものを使い続けることは自分が禁止した手前・・・そういうの保護する製品無いの？」

脳内では何かが弾けました。（○○さん、あの時に作ることが決まったんです）
FFRが脆弱性を攻撃されたことをセンサーのように把握できる機能を提供し、ウイルスの実行も停止できたなら。
これができれば、企業の業績が上向くまで、少しの間でも時間稼ぎができるかもしれない、と考えたのが昨年 11 月。

この製品が一般的な商業製品と異なるのは、以下の点です。

- 死に行く製品（狭まるマーケット）に向けた製品
- 予算が苦しい顧客ほど熱心
- 必要な機能だけ凝縮し、決して肥大化しない

一般に、ユーザーに購入の背中を押すのは、前向きな姿勢、新しい試み、より効率的に改善、など前向きなデマンドです。
が、私たちが目を向けたのは、絶望の回避、コストへの挑戦という後ろ向きなデマンドです。
確かに、大手の企業では見向きもしない15万サーバーというマーケットですが、私たちはそのうちの10%を救うためにチャレンジするという、とても面白い経験をしているところなのです。

こういうビジネスを考えられるソフトウェア企業、うらやましいでしょ。

Internet Explorer iepeers 0-day 脆弱性 vs FFR yarai

金居です。

Internet Explorer 6/7に、未パッチのセキュリティ脆弱性が発見されており、攻撃コードが出回っています。近年猛威を振っているGumblar型の攻撃に悪用される懸念がありますので、Internet Explorer 6/7をお使いの方は注意して下さい。

セキュリティホールmemoに、詳しい情報が時系列に整理されて掲載されています。

http://www.st.ryukoku.ac.jp/~kjm/security/memo/2010/03.html#20100311_IE

■参考情報
・マイクロソフトセキュリティアドバイザリ
http://www.microsoft.com/japan/technet/security/advisory/981374.mspx
・JVNVU#744549
http://jvn.jp/cert/JVNVU744549/
・NTT データセキュリティ
http://www.nttdata-sec.co.jp/article/vulner/pdf/report20100312.pdf
・so-netセキュリティ通信
http://www.so-net.ne.jp/security/news/view.cgi?type=2&no=2182

Internet Explorer 8は本脆弱性の影響を受けませんので、Internet Explorer 8にアップグレードしてください。また、「iepeers.dll のピア ファクトリ クラスを無効にする」ことで本問題を回避する事ができます。

http://support.microsoft.com/kb/981374/en

なお、FFR yaraiは、本攻撃に対してZDPエンジンで検出出来ています。

環境および攻撃コード：
yarai ZDP v1.1.528
Windows XP SP3 / IE 7.0
exploit/windows/browser/ie_iepeers_pointer (metasploit 3.3.4-dev.8793)

Hardware DEPとReturn-into-libc

こんにちは、村上です。予定を変更して今回は、今月の始めに公開されたHardware DEP（Data Execution Prevention）回避版のInternet ExplorerのPoCについてお話したいと思います。

ご存知の方もいらっしゃると思いますが今月1日、SkyLinedことBerend-Jan Wever氏によってWindows XPSP2以降に搭載されているセキュリティ機能であるHardware DEPの回避に対応したPoCが公開されました。

Internet Exploiter 2 - bypassing DEP

はじめに断っておくと、攻撃対象となるIEの脆弱性は、既にマイクロソフトからセキュリティ更新プログラムが提供されているためWindows Updateを実施しているユーザーは影響を受けません。この脆弱性が発見された当初に公開された攻撃コードは、Hardware DEPの回避に対応しておらずHardware DEPが有効に設定された環境下では、攻撃は成功しませんでした。余談ですが、Windows XPSP2の既定状態では、Hardware DEPは有効化されていないため可能であれば有効化することをお薦めします。

[HOWTO] Windows XP SP2 におけるメモリ保護の構成方法

Wever氏が公開したPoCは、Return-into-libcと呼ばれるテクニックを利用してHardware DEPを回避しての攻撃が可能であることを実証するものです。Return-into-libc自体は、特段目新しいものではなく私が知る限り初めてそのアイディアが公開されたのは、1997年のことです。その後、いくつかリサーチによりブラッシュアップされ近年、実際の攻撃でも利用されるようになってきています。興味のある方は、下記をご参照ください。

Getting around non-executable stack (and fix)

The advanced return-into-lib(c) exploits

Hardware DEPの基本的な考え方は、プロセッサがサポートしているNX/XDビットを利用してコード実行可能なメモリ領域とコード実行不可能なメモリ領域を明確に分離し、意図しないコード実行を防止するというものです。メモリ破壊に起因する脆弱性では、一般的に「(1)脆弱性を利用した制御フローの奪取」、「(2)スタック領域・ヒープ領域に読み込まれた攻撃コードの実行」の2つのステップから成り立ちます。Hardware DEPが有効化された環境下では、プログラムが明示的に実行可能とマークしない限りスタック領域・ヒープ領域はコード実行不可能となり、前述の(2)を防止することができます。これは、攻撃者から見ると「脆弱性を攻撃して制御は奪えたものの、意味のある悪事がなにもできない」（プロセスのクラッシュによるDoS攻撃は例外）という状況です。

Return-into-libcは、発想を転換し、プロセスが利用しているDLL上のAPIを実行する手法です。これらのAPIはそもそも実行すべきものであるため、そのメモリ領域は元からコード実行可能とマークされています。ただし、当然、そこにはDLLが提供しているAPIしか存在しないため、必ずしも「攻撃者が行いたいこと」を行えるわけではありません。

さて、任意のWin32 APIを呼び出せるとしたらなにを呼び出すでしょうか? Windowsには都合の良いことにメモリ属性を変更するAPIが存在します。そこで、より実践的な攻撃手法としては、「(1)脆弱性を利用して制御フローを奪取する」、「(2)Return-into-libcによりメモリ属性を変更するAPIを呼び出しスタック領域・ヒープ領域をコード実行可能にマークする」、「(3)スタック・ヒープ領域に置かれた攻撃コードを実行する」という流れになります。

このようにReturn-into-libcを用いることでHardware DEPを回避することは可能です。ただし、前述のようにこの技術は目新しいものではありません。また、Wever氏が氏のブログでもコメントしている通りHardware DEP及びASLR(Address Space Layout Randomization)が有効化された環境では攻撃は成立しません。こうしたOSや開発環境が提供しているセキュリティ機能の組み合わせと攻撃可能性については、社内でもリサーチしており弊社のWebページでリサーチペーパーを公開しています。

SEHオーバーライトの防御機能とそのExploit可能性

実は、上記のリサーチペーパーが先日お話した鈴木のCanSecWest 2010での発表内容になっています。手前味噌ではありますが技術的に良く纏まった内容になっていますので興味のある方は是非一読ください。最後に、FFR yaraiはReturn-into-libc攻撃に対応済という点をお知らせして終わりたいと思います。

---

このブログ中における株式会社フォティーンフォティ技術研究所（以下FFR）の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

古今セキュリティ事情

初めまして「古今セキュリティ事情」のカテゴリ リーダーの金居です。

このカテゴリでは、技術よりの話もしたいと思っていますが、それ以外の様々な話題を取り上げられればと思っています。特に私は US のセキュリティベンチャーで働いた経験もありますので、そういった個人的な体験も少しづつ話していきたいと思います。

簡単に自己紹介をしますと、前職ではセキュリティ スキャナを開発していまして、エンタープライズ機能を中心に様々な部分を担当してました。当時は、P2Pの研究や NIC のファームウェアで動くバックドアの研究などもしていました。

「tigon nic kanai」あたりでググって頂ければ何か出てくるかと思います。前の会社では製品開発をしている人も積極的に研究を行っており、研究開発型のベンチャーは面白いなぁと思った記憶があります。

セキュリティ業界には敵がいるという点において、非常に特徴があると思っています。この特徴的なサイバー戦線の最前線で何が起こっているのか、どういう経緯でこのような状況になってしまったのか、お伝えできればと思っています。

---

このブログ中における株式会社フォティーンフォティ技術研究所（以下FFR）の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。

このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

FFRのやわらカテゴリー

はじめまして、FFRのやわらカテゴリー担当の藤田明菜です。

このカテゴリーでは、IT職以外のかたにも解りやすいセキュリティ情報・知識の共有を行っていきたいと思います。

私はFFRに入社するまで、セキュリティはもちろん、ITの知識もほぼ持ち合わせていない完全な素人でした。

そんな状態で、セキュリティのプロ集団に囲まれたら・・・

入社当初は、飛び交う言葉のひとつひとつがまるで暗号のように聞こえました。
しかも、その暗号をWebで調べてみると、説明している文章自体も専門用語の集合体で、素人が理解するには難しいんですね。この時点で、「わからない用語が出てきたから調べてみた」「ちょっと興味があって見てみた」一般のPCユーザのかたは、急速に引いてしまうのではないでしょうか。

また、企業では情報システム部門がITまわりを一手に管理しているため、それ以外のメンバーはPC自体の仕組みやセキュリティリスクについて知る必要ない状況なのではないかと思います。私もそうでした。

ただ、FFRで活動してきたなかで一つ言えるのは、意外とITが身近で、取っ掛りがわかると面白いという事です。

このブログをご覧になっている皆さんにもそう感じてもらえるよう、次回から「やわらかめ」なテーマに沿ってお話させて頂きたいと思っています。

ではこれから宜しくお願い致します！

--
このブログ中における株式会社フォティーンフォティ技術研究所（以下FFR）の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

FFRのリサーチ

セキュリティ技術のカテゴリーリーダを担当する村上純一です。

このカテゴリーでは、最新セキュリティトピックの技術解説やFFR社内でのリサーチについて取り上げていく予定です。

初回ですので自己紹介を兼ねて簡単に私自身の興味やリサーチについてお話します。私は、2000年頃からルートキットを中心としたマルウェアの検出・分析手法の研究に取り組んできました。当時、ルートキットと言うとSolaris等のサーバでハッカーが利用するツールキットと言う意味合いが強く、今のようにクライアント端末でマルウェアが隠れ蓑に利用する、と言った用途は想像することができませんでした。これは、ITが十分に普及した事、それに伴ない悪意の矛先がサーバからクライアント、一般ユーザに広がった事が大きく関係しています。それだけ「IT」や「セキュリティ」という言葉も変わった・多様になったという事だと思います。
話が脱線しましたが、この2、3年は仮想化技術を応用してこうしたマルウェアを検出・分析するための研究に取り組んできました。仮想化技術が登場した当初は、それ自体のセキュリティがリサーチャーの間で熱く議論されました。現状そうしたフェーズは一段落しており、「仮想化技術を応用したセキュリティシステム」や「仮想化技術を利用したシステムにおけるセキュリティ」の2種類の話題が多いように感じます。私の研究も前者に該当し、研究成果の一部を国内外のカンファレンスで発表して参りました。

Hypervisor IPS based on Hardware Assisted Virtualization Technology
http://www.fourteenforty.jp/research/research_papers/bh-usa-08-Murakami.pdf

FFR GreenKiller - Automatic kernel-mode malware analysis system
http://www.fourteenforty.jp/research/research_papers/avar-2009-murakami.pdf

FFR社内では、この他にもExploitation技術、IPv6、組み込みセキュリティ等について各リサーチャーがそれぞれの課題に取り組んでいます。そうした研究の成果についても段階的に公開していければと考えています。直近では、今月末にカナダで開催されるCanSecWest Vancouver 2010で弊社の鈴木が「SEH overwrite and its exploitability」と言うタイトルで発表する予定です。

CanSecWest Vancouver 2010 - Speakers
http://cansecwest.com/speakers.html

参加される方がいらっしゃいましたら是非お声掛けください。次回は、鈴木からのCanSecWest参加報告になる予定です。

それではこれからよろしくお願いします。

---
このブログ中における株式会社フォティーンフォティ技術研究所（以下FFR）の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

FFRのソフトウェア開発

はじめまして、FFRのソフトウェア開発を担当する石山智祥です。

このカテゴリーでは、セキュリティ業界でのソフトウェア技術、開発手法からFFRのソフトウェアエンジニアが普段思っていることなどを取り上げていきたいと思います。

さて、はじめに石山のプロフィールを簡単に紹介したいと思います。石山は、独立系のソフトウェア開発会社にておもに組み込み関係の開発業務を行っていました。組み込みの世界では、コンピュータウィルスや脆弱性といったキーワードを耳にする機会はほとんどありませんでした。当然、業務内でもセキュアコーディングといった視点からはあまり考えていなかったと思います。

そんななか、石山がセキュリティに対して興味を持ったのは、Windows Update のアドバイザリや、ニュース等で目にする「悪意のあるコードが実行される」という記述からです。アプリケーションに実装されていないコードがどうやって実行されるのかという技術的なところに興味を持ち始め、個人的に調べていきました。そして、セキュリティ技術について、個人的に学習をしていく中で、セキュリティ業界で働いてみたいと思い、FFRに入社しました。

FFRに入社して感じたことは、セキュリティ技術といって何か特別なことをしているわけではないということでした。というのも、脆弱性を攻撃して「悪意のあるコードを実行」することについても、特別なことをしているのではなく、コンピュータの動作原理を理解し、応用しているだけだったからです。この辺りについては、コンピュータサイエンスの基礎をしっかり理解している人であれば、理解するのはそれほど難しいことではないと感じました。

最近のソフトウェア業界では、クラウドや仮想化等により、CPUに近い部分については隠ぺいされていく傾向にあると思います。逆にセキュリティ業界のソフトウェア技術は、CPUに近い低レイヤの部分に踏み込んで行く傾向にあると思っています。石山がそうだったのですが、低レイヤの技術に興味のある方にはセキュリティ業界は魅力的な業界ではないかと思います。

---
このブログ中における株式会社フォティーンフォティ技術研究所（以下FFR）の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

セキュリティ業界とマーケット

はじめまして、FFR でセールスマーケティングを担当する奥天陽司でございます。

このカテゴリーでは、セキュリティ業界およびマーケットに関して、私が知り感じている内容を取り上げたいとおもいます。

私は某大手外資系企業でセキュリティ担当として、古くはSadmin/IISのインシデントレスポンス（事故対応）からP2Pネットワーク上で広がったAntinnyの駆除対応までの業務の指揮をしてまいりました。セキュリティの仕事を始めた時は、コンピューターウイルスそのものの知識も乏しく、当時の会社でWebサーバー製品の不具合修正をしていた私は、突然サーバーがダウンしたというレポートや、突然コンテンツが切り替わってしまったというクレームが多発し、訳がわからずデバッグしていた気がします。

その後、ありとあらゆる攻撃手法が現れてコンピューター利用者を蝕んできた歴史があり、当初25%程度だったウイルス対策ソフトの普及度も、一気に85%まで上昇した時期でした。

技術的な対策だけではなく、消費者に訴えかける啓発活動も、メーカーだけではなく政府、一般の企業、メディア、自治体、みなさんが対策を推進したからこそ、日本は世界で最も安全な（対策が進んだ）国となったのでしょう。

ただ、ここ数年は、そのような大きな騒ぎも減り、ウイルス対策ソフトを利用するモチベーションも段階的に低下してきているのでは？それは、対策ソフトで守らないと危険！という常識が徐々に失われてきているのではないかと思っています。事実は。。。次の機会で述べますが、対策を進める一つのエンジンは、きちんと認知していただくことにあります。

弊社は小さな会社ではありますが、セキュリティの専業企業として日本のセキュリティ対策を進歩させる、そんな取り組みを展開してゆきたいと思っています。

--

このブログ中における株式会社フォティーンフォティ技術研究所（以下FFR）の社員による発言やコメントは、FFRの正式な見解またはコメントではありません。このブログは、FFRおよびココログの倫理規定に即して運営されており、倫理規定に反する内容のトラックバックは、事前のお知らせなしに削除させていただく場合があります。予めご了承ください。

FFR Blog 開設

みなさん、こんにちは。
代表取締役社長の鵜飼裕司です。

このたび、当社の公式Blogを開設する事になりました。

当社は、コンピュータセキュリティ技術に関するR&Dをベースとしたセキュリティベンダーです。

今や、ITは重要インフラの一つとして国民生活に根付く存在となっていますが、ハッキングやコンピュータ・ウイルス等に代表されるセキュリティ脅威への対策は、ITインフラの維持・発展に欠かせない重要なテーマとなっています。しかし、日本国内では研究開発をフルスクラッチから実施するセキュリティベンダーは極めて少なく、基本技術をほぼ海外に依存してしまっているという状況です。こういった国民生活の安全・安心や社会機能維持を確保するための技術は、分野を問わず極力国内で蓄積しておくべきでしょう。新型インフルエンザ対策や新エネルギー技術と同じです。

私自身は、当社を設立する前は海外のセキュリティベンダーで長年研究開発を行っていたのですが、そこで感じたことは、「このままでは、海外への技術依存が更に加速してしまう」という懸念と、「実は技術という点においては日本人でもこの分野で十分戦えるのではないか」という期待です。そこで、2007年に帰国。日本でR&Dをベースとしたセキュリティ事業をスタートするべく当社を設立しました。現在は、基本技術の研究で常にノウハウを蓄積し、パッケージ製品やサービスに繋げています。

このBlogでは、当社の研究開発で分かった色々な事実や近年のセキュリティ脅威、最新のセキュリティ技術・動向に関するトピック、当社の研究開発成果の紹介など、セキュリティに関する様々な話題をご提供致します。