FFR Blog

新しいコンセプト、新しい試みが受け入れられるまでの苦悩

皆様こんにちは、FFRの 奥天陽司 でございます。

Blogを読んでくれている方が結構いらっしゃいまして、この業界でも有名な方が読まれている声をかけていただいた時には、身が引き締まる思いです
（身が引き締まるつながりで言うと、前職退職時から、現在マイナス15キロ減量中～。久しぶりに会った方には、何か病気でもしたと思われたようで、そこには触れてこない方が多数 減量方法は、ブログネタなのでナイショ）

このブログ、FFR社内で読んでくれている人もいて、この間社内の親睦会で早く次を書けと追い込まれる始末。。。少しの間更新が止まっておりましたが、それには理由がございます。いえ、何のことは無い単に忙しいのです。

これまで、大手日本企業、大手外資系企業を経て日本のベンチャー企業で活動をしていますが、大手はどちらかというと自分のミッションを深掘りしてゆく仕事で、良く言うとスペシャリスト、悪くいうと仕事の範囲が限定的な印象です。

ベンチャーはやることが無限大。私が担当するマーケティング職も、マーケティング戦略立案、製品戦略立案、製品資料作成、メディア・広報、広告、販売戦略立案とありますし、営業力が必要なので営業としても動かなきゃならないし、提案活動と称してプリセールスエンジニアとしても動きます。今期からは製品のPMもすることになるので、一人やるべき仕事量は大手の何倍にもなります。

FFRは、セキュリティの専業企業として調査研究、製品開発、コンサルティングサービスを生業にしています。今も、Origma+ の機能拡張 (昨年10月の発売以来、2度目のバージョンアップが先日行われました） や FFR  yarai のようなセキュリティ関連製品の開発が急ピッチに進んでいて、まだ未発表のプロジェクトがいくつも控えています

FFR の製品は、セキュリティ技術者が本当に必要と考えている機能を備えた独自コンセプトの製品ばかりです。マーケットやデマンドドリブンではないため、理解され、受け入れてもらえるまでが大変な製品ばかりです。が、セキュリティの現状を考えると、どれも効果的に働く製品ばかりです。

以前某社で働いていたとき、新しいコンセプトや早すぎる技術の投入は、マーケットに受け入れられるまでに 2 年から 4 年ほど時間がかかることを学びました。セキュリティ更新プログラムの適用が本格的に受け入れられたのは、2001年に啓発活動をスタートして、自動更新などが実装されるまでの2年が必要でしたし、メディアプレイヤーなども同じ。もともとマーケットとして存在していたエリアへ後発参入する以外では、我慢の時期が続くことは必然です

弊社の FFR yarai も、昨年5月の発売以来、ようやく1年になろうとしています。パターンファイルを使用せず、ヒューリスティックやビヘイビアブロックだけでウイルスからの猛攻を防ぐというコンセプトは、当初は懐疑的だったとおもいますが、昨今の事情を考えると今後ウイルス対策製品は間違いなくこの方向に行くだろうことは理解できます。現状のソリューションの限界を理解（体感）出来るまでには、時間が必要なのかもしれません

楽しみでもあり、辛くもあり。

Windows XPでも保護機能：Google Chromeのサンドボックス

こんにちは。リサーチエンジニアの丹田です。前回はInternet Explorerのセキュリティ機能「保護モード」のお話をしました。

Windows Vistaからの保護機能：保護モードと整合性レベル
http://blog.fourteenforty.jp/blog/2010/03/windows-vista-e.html

今回もウェブブラウザのセキュリティつながりということで、Google Chromeのお話をしたいと思います。ポイントは、Google ChromeはXPでもセキュアに動く、です。

■ プログラムの脆弱性はなくならない

前回にも触れたとおり、ウェブブラウザのセキュリティの確保はほとんどのPC利用者にとってとても大切です。しかし、ウェブブラウザは攻撃者から見たとき非常に脆弱性を悪用しやすいソフトウェアであるため、攻撃者が最初に脆弱性を見つけて悪用してしまう「ゼロデイ」が頻繁に発生しています。意識して見ると、Microsoftの定例外更新の対象がInternet Explorerであったり、Firefoxが毎月のように更新していたりすることに気付きます。

このことは、ウェブブラウザの脆弱性を開発段階で洗い出すのは難しいということを示しています。この事実に対して、Internet Explorerは保護モードを導入し、「攻撃されても被害を抑える」戦略をとったと言えそうです。

そしてこの戦略をさらに強力に実現したのがGoogle Chromeです。Google Chromeは2008年末に公開された後発のウェブブラウザです。複数のプロセスで構成するマルチプロセスアーキテクチャを持ち、サンドボックスと呼ばれる仕組みを使ってセキュリティを提供しています。そこで今回は、このサンドボックスと、サンドボックスに関連するGoogle Chromeの特徴を紹介してみたいと思います。

■ 危険性の高いコードを分離する

Google Chromeは、バッファオーバーフローなど致命的な脆弱性を生み出す可能性が高いと見込まれるコードを、別のプロセスとして分離しています。この結果、高い安定性と、サンドボックスによる強いセキュリティが実現できています。

プロセスを分離するマルチプロセスアーキテクチャは、Internet Explorer 8でも採用されました。Firefoxでも同様に、プラグインを別プロセスに分離する計画があることが告知されています。

・IE8 と Loosely-Coupled IE (LCIE)
http://msdn.microsoft.com/ja-jp/ie/cc787974.aspx

・Firefox の安定性が大幅に改善しているという調査結果が発表されました
http://mozilla.jp/blog/entry/5425/

　Google Chromeは、タブ、エクステンション、プラグインひとつひとつまで単一のプロセスとして動作する点でやや異なります。これはとりわけ安定性に貢献します。

■ 分離したプロセスの権限を落とす

分離された危険性の高いコードは、極めて権限の抑えられたプロセスとして動作します。権限が抑えられ、できることが限られているため、攻撃者に制御を奪われても被害を最小限に抑えることができます。この権限を抑え、被害を最小化する仕組みが「サンドボックス」です。

もしWindows Vista以降をお使いでしたら、Google Chromeを起動して、Process Explorerから「Integrity」列を確認してみてください。Chrome.exeのうちいくつかが、整合性レベル「Low」で動作していることが確認できます。 

これは、分離されたプロセスの権限が抑えられていることを示しています。前回お話したInternet Explorerの保護モードと同じ仕組みです。

■ 保護モード以上に厳しい制約を課す

Google Chromeのサンドボックスの面白いところは、整合性レベル以外にもさまざまな制約を課す点です。たとえば、子プロセスを生成することができません。クリップボードの読み書きが禁止されています。サンドボックスの外とウインドウメッセージをやり取りすることも許されていません。また、ファイルを読み取ることもできません。保護モードのInternet Explorerは、ファイルの読み取りは可能（書き込みは禁止）であるため、攻撃者の手に落ちた場合、情報漏えいを防ぐことができませんでした。

■ UAC無効でも、XPでも機能する

私はXPも頻繁に使っています　そんな私ですから、この点は特に感心しています。前回も少し触れましたが、UACが無効の場合、Internet Explorerの保護モードは無効になります。またXPでは保護モードは使えません。

それに対して、Google Chromeのサンドボックスは、これらの状況にあっても変わりなく動作します。もちろんXPに整合性レベルはありませんが、XPだからといってサンドボックスの機能が損なわれることはありません。

■ なぜ？

端的にいえば、サンドボックスの実装は、保護モードで使われていた整合性レベルの機能に依存していません。ドキュメントを読むと分かるのですが、整合性レベルの調整はオマケのような扱いです。実装は古くからあるWindows APIを巧みに組み合わせたもので、サンドボックスのドキュメントには、この仕組み自体はWindows 2000から動作すると書かれています。

サンドボックスの実装は、具体的には以下のような仕組みが使われています。

•制限トークンの利用で各種カーネルオブジェクト（ファイルもここに含む）へのアクセスを制限
•デスクトップの変更でウインドウアクセスやウインドウメッセージの送受信を制限
•ジョブオブジェクトの制限機能でクリップボードへのアクセスなどを制限

疑わしい！と思った方や、実装に興味がある方は、ぜひドキュメントやソースコードをあたってみてください。なかなか面白い仕組みを学ぶことができると思います。

・The Chromium Projects > Design Documents > Sandbox
http://dev.chromium.org/developers/design-documents/sandbox

・The Security Architecture of the Chromium Browser
http://seclab.stanford.edu/websec/chromium/

・ソースツリー
http://src.chromium.org/viewvc/chrome/releases/

・Google Chrome の内部構造
http://code.google.com/intl/ja/events/developerday/2009/sessions.html

■ 余談

実は、Google Chrome 4.1では、フラッシュプレイヤーのようなプラグインは上記のサンドボックス機能の管理下にありません。つまりプラグインに脆弱性があり、プラグインプロセスの制御が攻撃者の手に渡った場合には保護されないことを意味します。

先ほどの画像を見てみましょう。整合性レベル「Medium」になっているChrome.exeうちの１つが「--type=plugin」になっています。これがプラグインプロセスです。

プラグインにサンドボックスが適用されないのは、プラグインの仕様上やむをえない措置だったようです。この問題に対してブラウザ利用者ができることは、プラグインを利用しないか、プラグインを確実にアップデートすることだけです。

この問題を解決するために、GoogleやMozilla、Adobeは共同でプラグインの新しいAPIを策定しています。

・Bringing improved support for Adobe Flash Player to Google Chrome
http://blog.chromium.org/2010/03/bringing-improved-support-for-adobe.html

次のバージョンとなるGoogle Chrome 5では、この新しいAPIを利用したプラグインがサンドボックスの管理下に入り、プラグイン経由の攻撃からも保護できるようになるかもしれませんね。

ではまた。

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

• Comment / TagCloud / Auto start (Open) /
• SBMAsc / SBMDesc / DateAsc / DateDesc / UserAsc / UserDesc
• Multi poster / Tag / No commenter

0 user
0 user
0 user

:0 :0 :0

• Comment / TagCloud / Auto start (Open) /
• SBMAsc / SBMDesc / DateAsc / DateDesc / UserAsc / UserDesc
• Multi poster / Tag / No commenter

0 user
0 user
0 user

:0 :0 :0

• Comment / TagCloud / Auto start (Open) /
• SBMAsc / SBMDesc / DateAsc / DateDesc / UserAsc / UserDesc
• Multi poster / Tag / No commenter

0 user
0 user
0 user

:0 :0 :0

ポリシーとガイドラインの違いは海賊に真鍋

最後の"真鍋"、知ってる人にはウケがいい
いえ、以前某組織が使ったスローガンの一語で、IMEが選んでくれた変換候補ですので、気にせず～

今回は、日本人が間違いやすい（自分も間違えてた）言葉の定義の話。

言葉の定義といえば、過去様々用語論争がありまして、たとえば、コンピューターの最後の "ー" ですが、最近はこの伸ばすの付けるんだそうな。20年前からこの業界にいると、コンピュータ、が当たり前ですけど、これってメモリーの使用量を少しでも減らすための苦肉の策ということです。いやー大らかだとは思いませんかみなさん！

某社のスタイルガイドにも、3字以上のカタカナかつ語尾が”ー”の場合省略、みたいのがあって、パワーユーザーなら、パワーユーザ　だし、ユーザーだけなら省略しない、みたいな。最近コンピューターのパワーが上がったことに気がついて、改定の動きになったようです。

あと、脆弱性という言葉、今でも変わった言葉として認知されていますが、この言葉をセキュリティ情報のなかで使い始めた時点で、欠陥という言葉の印象を和らげるためのもの、みたいな認識を持たれていたみたい。使用者側からすると、セキュリティ上の脆さも、バグとか欠陥とか不具合って同じ位置づけの障害ではありますが、メーカー側からすると少しことなる位置づけだったりするわけで、この辺はなかなか判断が難しいですよね。

メディアの視点からは、読者に理解されない言葉は使えないわけで、一時期新聞に躍った欠陥という言葉も、最近では脆弱性（＝セキュリティ上の瑕疵不具合）として使われていますが、それも言葉に市民権が与えられた表れでしょうか。まあ、ニュアンスの違い程度ですけど、モノ作りの国としては欠陥といわれると過剰に構えてしまうわけで、そうなると欠陥と言われないよう隠ぺいしたくなるわけで、という状況が改善されつつあると思います。

前段が長いですね、ハイすみません。

言葉の定義って、目的と実態を結び付ける関連性を表す端的で重要な要素なわけで、これが誤っていると違う方向に行ってしまうわけですよね。私の日々の仕事の中でも、特にマーケティングの落とし穴として戦略と戦術の違いが混同するとおかしな方向に向かうなど、到達点が大きくずれてしまう一つの理由になっています。

で、これは前職で私の戦友（愛すべき○○氏お世話になりました）が教えてくれた事例です。

世の中、ポリシーとガイドラインの違いをはき違えているケースが目立ちます。ポリシーと言いながら例外が多い、ガイドラインと言いながら従属条項が多いなど。わかりやすく示した例が最近連続してテレビで流されているパイレーツオブカリビアンの一節に出てきます。
ヒロインが海賊につかまりひと悶着があるシーンで、ヒロインが海賊に Parlay(パーレイ)という合言葉をいうんですね。これを言うと、親玉と交渉する権利が生じるという掟。
で、海賊はその掟についてこんなようなやり取りがあります。

（男A）パーレイって知ってるか？
（男B）しってるぞ
（男A）パーレイってポリシーだったか、ガイドラインだったか？
（男B）たしかガイドラインだったはず
（男A）じゃあヤっちゃおう

つまり、ポリシーであれば守らねばならず、ガイドラインであれば必ずしも守らなくても大丈夫、そういうニュアンスで伝わってきます。

この二つの言葉をきちんと使い分けているかなあ～( ﾟдﾟ)ﾎﾟｶｰﾝ > 自分
と考えたものでした。

セキュリティポリシー、セキュリティガイドライン、この二つきっちり理解し使い分けてゆかないと、厳しすぎたりゆるすぎたり、指示を受けた側もそれぞれ認識がまちまちだったりすることになりそうですね。

という、みなさん「あたりまえじゃーん」ってネタで今週を乗り切る私です。

。。。そういえば、こういう常識をエンターテインメントから得ることがありますね～。小学生の時にドラえもんを読んでて彼岸のことを知ったり、周りにいろいろなヒントがあると思って注意すると、人生死ぬまで之学習、というのが腑に落ちますです。

奥天@人生折り返し点なう

やわらかCanSecWest2010参加報告

名ばかりリサーチエンジニアの鈴木です。

CanSecWest2010に参加してきたので、驚いたこと、知ったことなどをランキングで。

第5位 行き帰りの飛行機がビジネスクラス
単なるラッキーです。混んでいたので、ビジネスにしてくれました。快適な旅でした。個人的には一番うれしかったできことでした。

第4位 ヨーロッパの人たちが多い
アジア系はほとんどいない中、ドイツ語やらフランス語でしゃべっているグループが結構たくさんいました。みんな英語も当然できるので、お互いの意思疎通には問題ないのですが。フランスから来た人と話を少ししたのですが、フランスでは結構たくさんセキュリティ関係のカンファレンスがあるそうで、CanSecWestに出る前のいい準備になる。そこで評価を受けたものがCanSecWestに来るから、というようなことを言っていました。
はい、特に準備とか、国内発表とかそういうのなく来ましたが、なにか・・・。

第3位 Dragosはいい人
主催者であるDoragosとは初めて会って、少し話をしたのですが、なんとなく日本人的というか、すごく丁寧な感じの人でした。なんというかそうとうまじめそうというか。ただ、変に硬い人というわけじゃないので極度の人みしりの僕にも親しみやすい人でした。

第2位 会場が想像以上に広い
合計500人ぐらいは入る会場だったと思います。もっと狭いホテルの一室を借りてやるのかとイメージしていたら、違いました。でっかいスクリーンが4つも並んでる・・・。発表する前はそれで逆にプレッシャーでした。そのせいで、発表の前日は緊張のためほとんど何も食べられませんでした。

第1位 下手するとTwitterでその場で酷評される
今回のダントツの驚きはこのTwitterシステム。会場の側面にスクリーンがあって、#CanSecWestのTwitterの検索結果がリアルタイムで表示されます。会場は無線LANで誰でもネットアクセス可能なので、その時点での会場の様子や発表の内容について、コメントがそこにどんどん表示されます。発表を聞く側としては、発表の内容がどのようにみんなに受け止められているのかをその場で見ながら聞くことができて、アイディアとしてはとても面白いです。（っていうか、これっていまどき当たり前のシステム？僕は3週間前にTwitter始めました。）

さて、このシステム、確実にあったほうがいいのは間違いないのですが、中にはその場で酷評される人も・・・。会場のみんながその発表者を目の前にして、横のスクリーン見ながら失笑というか・・・。まあ、発表者からは見えにくい位置にあるので、その場でそれを知ることはないのですが、あんなこと言われたらもう立ち直れないかも、ってぐらい酷評されていた人もいました。場違いだったんでしょうね、内容が。
「誰があいつをスピーカーに選んだんだ？」
「次の発表の時間まで寝てればよかったよ。」
そして、途中でプロジェクターのトラブルで画面が出なくなった時には
「good news everyone」
などなど・・・その場で言われるんだから怖すぎます。

で、私の発表時のタイムラインはというと・・・詳細は検索してもらうこととして、なかなかおもしろかったコメントを一つご紹介。
「マリナーズは一日休暇を与えたのか？」
名前が鈴木秀一郎なので、まあ、海外の人から見ると「Shuichiro Suzuki」も「Ichiro Suzuki」もほとんど同じ名前に見えるんでしょうね。

こんな感じでいろいろ面白い経験ができたわけですが、全体としてこのイベントの規模や、構成のされ方が想像よりずっと大きくて驚きました。大きな企業から小さな企業まで、現在のセキュリティに本気で興味を持って取り組んでいるという印象を受けました。

個人的にもセキュリティに対する意識が少し変わった意義のあるCanSecWest2010参加でした。

CanSecWest2010発表報告

リサーチエンジニアの鈴木です。

CanSecWest2010にて、SEH Overwriteに関する発表をしてきました。今回は、その時の報告、発表内容の要旨、そしてそこから出てく防御機能に対する考え方をご紹介したいと思います。

まずは、簡単に参加報告を。CanSecWestに参加するのは初めてで、緊張しながらいったのですが、会場を見てさらに緊張しました。せいぜい100人ぐらいの入る小さな部屋でやるんだろうと思っていたら、ざっと数えて500人は入る会場でした。

緊張しましたが、いざ発表が始まると意外に落ち着いて、約１時間の発表も特に問題なく終えることができました。

発表後には、興味を持ってくれた人たちが何人か来てくれて、いろいろ話をしたり、名刺交換したり。

より詳しく知りたい方は「SEHオーバーライトの防御機能とそのExploit可能性」と「発表スライド」をご覧ください。

今回のリサーチペーパーは、いろいろある攻撃防御機能がどれくらい有効なのかをSEH Overwriteという手法を題材にしてまとめようという目的のもと始まったものでした。進めるうちに、SEHOPという防御機能の回避というものは一般に紹介されておらず（2009年8月時点）、その他の防御機能も一緒にバイパスできてしまいそうだと感じ始め、それらの可能性について調べました。

もともとSEHOPはSafeSEHやSoftware DEPという防御機能がバイパスされることがあるということで、これを難しくしようという経緯で提案され実装されました。しかし、実際にはバッファオーバーフローを起こすアドレスが分かっていれば比較的簡単にSEHOPも一緒にバイパスして攻撃できてしまうというものです。さらにReturn-into-libcを用いてHardware DEPもバイパスして任意のコードが実行できる可能性があるということを示しました。

最終的な結論として、ASLRを組み合わせるとSEH Overwriteによるエクスプロイトはかなり難しいということがわかりました。

ただし、ここで重要なことはASLRがすべてではないということです。ASLRさえ有効になっていれば、他はどうでもよいということではありません。SEH Overwriteに関して言えば、ASLRとSEHOPという組み合わせがお互いの有効性を高めあい相乗効果があるということです。たまに、Hardware DEPだけで安心だという声も聞かれますが、これもそれだけでは心もとないです。ASLRとHardware DEPと組み合わせると有効性が一気に増します。
しかし、ASLRとHardware DEPだけの防御機能も回避される例は存在します[Bypassing Browser Memory Protections(Alexander Sotirov, Mark Dowd)]。しかしここでもSEHOPを組み合わせると防御機能回避は難しくなります。

いろいろなエクスプロイト手法を考察すると、やはり各防御機能は確実に組み合わせて用いるのが有効です。一方で単独の防御機能だけでは現在の攻撃者のレベルから考えるとちょっと心もとないです。セキュリティを考えるならば１つより２つ、２つより３つと、防御機能をできるだけ有効にしておいた方がよいのは間違いありません。

しかし、ただやみくもに増やせばよいということではないということも今回のリサーチの中で分かりました。先ほども書いたように、SEHOPはSafeSEHやSoftware DEPのバイパスを防ぐということを１つの目的として実装されましたが、実際にはASLRが一緒に有効になっていないと、その効果がほとんどでなくなってしまいます。このように、どのような組み合わせで効果が出るかは、新しい防御技術が出るたびに考える必要がありそうです。
（Windows 7ではASLRはデフォルトで有効で、SEHOPはデフォルトで無効です。ASLRを無効にしてSEHOPを有効にするという使い方はあまり想定していないのかもしれません。）

そして現実に目を向けると、残念ながらWindows XPにはASLRやSEHOPという機能がありません。Windows XPは防御機構の充実度という点では少し弱いと言わざるを得ません。Hardware DEP単独ではなかなか高度な攻撃手法から防御することは難しいかもしれません。

セキュリティを考えるのであれば、やはりWindows 7という選択肢はよいのではないかと思います。ただし、きちんとASLRやSEHOPなどの設定をしておかなくてはいけません。（互換性の問題もありますので、注意して有効にするようにしてください。）こうすることで、Windows XPに中途半端なウィルスソフトを入れるよりはずっと安全になることと思います。

ただし、残念ながらこれで完璧に守れるということはありません。
CanSecWest2010でのPwn2OwnコンテストではASLRとDEPが有効なWindows 7でIE8がハックされました。

セキュリティを第一に考えるのであれば、まだまだ足りないということなのかもしれません。
そこで、おすすめするのがZDP・・・とここから先はマーケティングにお任せすることとして、今回はこの辺で。

セキュリティ＝保険、そろそろ考え方変えたほうがいいかも

FFRでマーケティングをしている奥天陽司でございます。

私がセキュリティの世界に入った10年前、セキュリティの重要性が叫ばれる中、口々に業界のみなさんが言っていたのは、セキュリティ更新を消費者に実施してもらう難しさ、ウイルス対策ソフトを購入してもらうハードルの高さ、セキュリティ特有の用語を理解させる困難さ、みたいな様々な課題が山積していて、正直僕たちどうなっちゃうのぉ～な感じだったわけです。

と言っても、まだマーケットの要請は厳しくは無く、ウイルス感染の被害が激増してゆくさなかでしたので、みなさんいつかはセキュアになるはず、日本ってポテンシャル高いし！と楽観していたのも事実です。時代はバブル後のしばらくたった後の成長期でしたし、正しいことを正しく行うことって当たり前に心に響いた時期だったんですよね。

さて、ウイルス対策や、セキュアなOSの選択、セキュリティアップデートも的確に実施ができるようになってきている中で、今業界の方は何を言っているのか。よりセキュアな製品に移行してもらえない、ウイルス対策ソフトを有償のものを使ってもらえない、最近のWeb感染型マルウェアに関して、技術的な問題点を理解してもらえない！みたいな、いつの時代も同じ課題が残っているのが世の常なんですよね。

で、以前のカオスと違う点はこれ、経済状況。
いえ、業界が儲かるとかそういうことを言いたいのではなく、生活全体に忍び寄るえも知れぬ不安が、セキュリティ業界にも影を落としているような気がします。
最近ある講演を聞いていて、以下のようなフレーズが出てきました。

「情報セキュリティ対策は、保険的な意味合いを持っています。みなさん事故に備えましょう！」

まさしくネットワーク型のウイルスが増加してきて、被害も増えてきてしまったあたりから、事故前提の体制とかインターネット保険、みたいな話は急激に増えました。
要するに、危険な状況なので自ら危険な状況を直視して第三者に担保してもらいましょう、ということで、その当時はみんなが保険！保険！の大合唱でした。
はい、その当時は、そうだったのです。

私、ある記事を見ていて、驚きました。
http://japan.cnet.com/marketing/story/0,3800080523,20393822,00.htm
20代の生命保険加入率、驚きの40％。保険に入らない理由は、特にないのだそう。
実際には経済的なものもありますし体も元気ということもあるでしょうが、それにしても特に理由が無いとは。
ちょっと面白いとおもい、そのほかのメディアで出ているマーケティングデータをみても、一律50%以下なのです。
30代以降は一気に加入割合は上がるので、要するに保険に対する認識がこの年代の違いで大きく変わっているということですよね。

さて、ここで先程の文章を読みなおしてみてください。

「情報セキュリティ対策は、保険的な意味合いを持っています。みなさん事故に備えましょう！」

正しい、まさにただしい、と思うのは私が40代だから？
つまり、ターゲットになっているセグメントに対して的確なメッセージではない可能性があるということ。
マーケティングやってると、どうしてもボリュームゾーンへのメッセージが強くなりますが、PCをアクティブに使いこなしているのはだれ？という部分も考えなければなりませんよね。
（とはいえ、20代より若年はPCではなく携帯がメインのデバイスですけどネ）

アメリカでは、あまりセキュリティ＝保険という感覚はなく、（映画シッコを見るとわかるように、そもそも保険に入っていないアメリカ人が多いわけです）彼ら曰く、セキュリティ＝ベースライン　つまり、基礎、と考えているように思います。
セキュリティ予算は、IT予算の15％程度が定常的に確保されているというのは、彼国らしいという気もしますが、まさしくメンテナンスも含めて彼らのベースラインなわけですよね。

この考え方を日本に持ち込むのは、困難ですし、そもそも必要もありません。
私たちに合う考え方を作りだし取り入れてゆく必要があって、それを下すのは我々自身、というものすごいドライブ感を感じるのが、今は面白い時代だな～と感じている私42歳のおっさんの意見です。