エフセキュアブログ

遅い を含む記事

新たな調査で、オンライントラッキングがWebブラウジングを遅延させることが判明

トラッキング保護を活用することで、ロード時間を89%も短縮することができます。これは オンラインセキュリティのプロバイダであるエフセキュアが実施した、新たな調査で明らかになった事実であり、リサーチャーはサードパーティのトラッキングクッキーがどの程度ウェブサイトで乱用されているのかが、調査結果から浮き彫りになったと述べています。適切な対策を整備しない限り、この「デジタル公害」はウェブの閲覧速度を低下させ、顧客は承諾なしにデータを使用せざるを得ない可能性があります。

エフセキュアのセキュリティ研究所は、アレクサの上位50位にランキングされているサイト*の閲覧において、Freedomeのトラッキング保護を使用する場合と、使用しない場合で比較を行う調査を実施しました。その結果、Freedomeを使用した場合は、人気のあるウェブサイトでもロード時間が高速であり、帯域幅の使用も少ないことが明らかになりました。ロード時間は3%〜89%、平均で30%の短縮となりました。ページサイズは3%〜55%、平均で13%の縮小となりました。ウェブサイトの中には95個ものトラッカーが使用されていましたが、これはFreedomeの新しい機能であるTracker Mapperを活用することで確認できます。

エフセキュアのセキュリティ・アドバイザーを務めるショーン・サリバンは、オンライントラッキングは深刻な問題になっており、時間とお金を無駄遣いする原因であることが、調査で明らかになったと指摘しています。「通常、ウェブサイトではよりよいサービスを提供するために、ある程度のオンライントラッキングの使用が正当化できます。ただし、今回の調査結果では、収拾がつかない状態であることがはっきりと示されています」とサリバンは述べています。「トラッキングによってブラウザの作業量が増加するため、ユーザーやその親世代が1990年代に利用していた、ダイヤルアップ接続での閲覧状態が再現されているのが現状です。実際のところ、これは帯域幅を消耗するデジタル公害であり、データに対する対価の拡大が正当化された上で、情報が消費者の手にわたっているのです」

Freedomeのトラッキング保護では、トラッキングサービスからのリクエストが完全にブロックされ、広告ネットワークに属するCookieが除外されます。Freedomeが閲覧のパフォーマンスを改善できたのは、こうしたデータの集積をブロックすることで、オンラインで移動するデータ量が削減されたからです。

「基本的にトラッキング保護では、サードパーティのCookieがインターネット上にもたらしているノイズが除外されます」とエフセキュアの次世代セキュリティ担当ディレクターを務めるジャンヌ・パティラーティは述べています。「消費者はこうしたノイズを求めていませんが、知らないうちにその代償を支払っているのです。そのため言葉は悪いですが、「不快」、かつイライラするほど遅いオンラインエクスペリエンスが、データ収集に頼る会社の事業運営のせいでお客様にもたらされることを、何らかのトラッキング保護を利用することで阻止します」

サリバンは、ウェブサイトが「軌道の修正」を行い、トラッキング技術の導入について見直す機会だとも話しています。こうしたメッセージを企業に伝えたい方は、Freedomeのトラッキング保護機能を、優れたオンラインエクスペリエンスの実現に役立てることができます。MacとWindows PCをお使いの場合は、ウェブの閲覧中に消費者を追跡するサードパーティのCookieを確認できるTracker Mapperのβテスト版にお申込みいただくことで、インターネットトラッキングの状態を改善できます。テストしていただく方には、こちら( https://freedome.f-secure.com/trackermapper/ )でご登録いただくことにより、Freedomeを2か月間無料で利用できるコードをお送りいたします。

*出典: http://www.alexa.com/topsites/global;0

詳細情報:  
Freedome https://www.f-secure.com/ja_JP/web/home_jp/freedome
Who Is Tracking ME? http://freedome.f-secure.com/whoistrackingme/index.html

準備中

 このブログ(https://www.f-secure.com/weblog/)の常連の読者の方なら、最近、更新が遅いことにお気づきだろう。

Under Construction
工事中

 とうとうGreymatter 1.7.3から更新することにした。ここは世界でもっとも古いGreymatterのブログかもしれないが、もうすぐ変わる。

 詳細は追って連絡する。

 それと同時に、引き続きTwitterで情報を得られる。

DODAからの挑戦状に隠された画像

先月まで「DODAからの挑戦状」という企画でハッキング問題を掲載しておりました。(現在、企画は終了しており、こちらに解答を掲載しています。)

DODAChallengeFromWired

初級、中級、上級と全部で3部構成の問題となっており、最後の上級問題の正答率を1%にしてほしいという要望をいただいておりました。過去のCTF参戦の経験から考えても難易度の調整は難しいものでして、「DODAからの挑戦状」の裏で、個人的に「1%への挑戦」がありました。

最終的には、初級問題の正答者数(アクセス数)が8232でした。これはユニークを取っていない数字なのですが、ユニークを取ると半分くらいの4000名くらいになるでしょうか。
4000名の1%だと40名になりますが、実際に上級問題を正解した方は32名でしたので、難易度の設定はうまくいったと思います。

さて、この挑戦状は普段からデコンパイルに慣れ親しんでいる方には退屈に思われるかもしれないので、上級問題の後に超上級問題として追加で一問隠しておきました。

ここではその解法を紹介します。
続きを読む

もっとも手が届きやすい果実:Java

 コンピュータ・セキュリティ上、あらゆる評価基準において、現時点でもっとも手が届きやすい果実という称号の保持者はJavaだ(Javaという言葉で、ここではJREや各種ブラウザのプラグインも意味する)。ずっとそうだった訳ではない。どうして、こうなったのだろうか?手の届きやすい果実の歴史について、ハイライトをおさらいしよう。

2004〜2008年:WindowsからOfficeへ攻撃がシフト

2004年8月 — Windows XP Service Pack 2がリリース

2005年2月 — RSA Conferenceにてマイクロソフトが最初のベータ版Microsoft Updateをアナウンス

2005年6月 — Microsoft Updateの初回リリース

結果:Windows UpdateからMicrosoft Updateに置き換わって以降、時間と共に世の中のMicrosoft Officeの脆弱性が減った

2008〜2010年:攻撃の焦点が徐々にAdobeへ

2009年2月 — Adobe Reader has become the new IE(Adobe Readerが新たなIEになる)

From my point of view, Adobe Reader has become the new IE. For security reasons, avoid it if you can.

2009年3月 — Adobeが四半期ごとのアップデート・スケジュールを開始。「Patch Tuesday(訳注:Microsoftの定例アップデート)」と同日に入手できるようになる

  •  ASSET Blog:Adobe Reader and Acrobat Security Initiative

2009年4月 — OracleがSunを買収、Javaのオーナーに

2010年3月 — PDFベースの標的型攻撃が増加

Targeted Attacks

  •  Computerworld:Hackers love to exploit PDF bugs, says researcher

 Adobeはこのデータに驚いてはいなかった。「数多くの当社製品が相対的にユビキタスでプラットフォ―ム共通であることから、Adobeは攻撃者から注目を集めており、今後もさらに集め続けていくことになりそうだ。」

Given the relative ubiquity and cross-platform reach of many of our products…

2010年7月 — AdobeがMicrosoftのMAPPプログラムに参加

  •  ASSET Blog:Working Together: Adobe Vulnerability Info Sharing via Microsoft Active Protections Program (MAPP)

結果:Adobeがチーム・プレイヤーとなり、その成果を得た。

2010〜2013年:Javaが(複数のOSにおいて)もっとも手が届きやすい果実という称号に名乗りを上げる

2012年4月 — Adobeが「四半期ごとのアップデート」を終了し、必要に応じて毎月行うことに。マイクロソフトのアップデート・スケジュールに依然沿っている

  •  ASSET Blog:Background on Security Bulletin APSB12-08

2012年8月 — Javaランタイム環境 = 常に脆弱なマシン

2013年1月 — ZDNetのレポーターEd Bott氏が、Javaをフォイストウェアの新たな王だと断言

  •  ZDNet:A close look at how Oracle installs deceptive software with Java updates

2013年2月 — 多数の企業がJavaを原因とするセキュリティ上の欠陥を認める

  •  The Verge:After so many hacks, why won't Java just go away?

結果:ブラウザのJavaプラグインは公衆の敵ナンバーワンだと見なされる

 しかし待てよ。ブラウザのJavaプラグインを無効にするだけで十分だろうか?

2011年3月 — Spotify Freeのユーザが、悪意のある広告経由で攻撃される。少なくとも1つの攻撃で、Javaエクスプロイトが用いられる

  •  SC Magazine:Spotify in malvertising scare

 Javaを起動できるのは「ブラウザ」だけではないようだ。

2013〜201X年:Oracleが進化するか、JREが次第に重要でなくなる

 Oracleは1、4、7、10月の17日にもっとも近い火曜日にクリティカル・パッチ・アップデートをリリースしている。「Patch Tuesday」とは別の(遅い)日にこうしたアップデートをリリースすることで、今のところOracleは、IT部門に対し、パッチ・メンテナンスの評価や試験ミーティングの予定をさらに別に設定することを強いている。

 本当に何かを変えなければならない。

Flameは不十分

  Flameマルウェアが2週間前に発見された時、「非常に先進的」「スーパーマルウェア」「史上最大のマルウェア」と呼ばれた。

  これらのコメントはすぐに、Flameには特に新しい点も興味深い点も無いと指摘した専門家たちによる嘲笑を受けた。

  実際、Flameで唯一ユニークなのは、そのサイズでしかないようだ。それとても、それほど刺激的ではなかった。アナリストはもっと大きなマルウェアの事例を探してきたし、実際、発見してもいる(マルウェアの中にはビデオファイルのように見せかけようとするため、本体にノーカット版の映画を含むものもある)。

  FlameがStuxnetやDuquのように、政府によって作成されたもので、国民国家が作成したものだという示唆も、嘲笑を受けている。

  しかし、この2週間で我々がFlameについて知ったことを見てみよう。

1. Flameはキーロガーとスクリーングラバーを持つ

  否定派は感銘を受けていない。「以前、見たことがある。Flameは不十分だ。」

2. FlameはビルトインのSSH、SSLおよびLUAライブラリを持つ

  「肥大化している。遅い。Flameはやはり不十分だ。」

3. Flameはローカルドライブおよびネットワークドライブで、すべてのOffice書類、PDFファイル、Autodeskファイル、テキストファイルを探す。盗み出せる情報が多すぎるため、IFilterを使用して書類からテキストの引用を抜粋する。これらはローカルのSQLLiteデータベースに保存され、マルウェアのオペレータに送信される。このようにして、彼らはマルウェアに指示し、本当に興味深い資料に焦点を合わせる。

  「Flameは不十分だ。」

4. Flameは感染したコンピュータのマイクをオンにし、マシンの近くで話される会話を録音できる。これらの会話はオーディオファイルとして保存され、マルウェアのオペレータに送信される。

  「Flameは不十分だ。lol」

5. Flameは感染したコンピュータとネットワークで、デジタルカメラで撮影された画像ファイルを検索する。これらの画像からGPS情報を抽出し、それをマルウェアのオペレータに送信する。

  「Flameはやはり不十分だ。」

6. FlameはBluetoothを介して、感染したコンピュータに接続している携帯電話があるかどうかをチェックする。もしあれば、その端末(iPhone、Android、Nokiaなど)に接続し、アドレス帳の情報を収集して、マルウェアのオペレータに送信する。

  「Flameはやはり、ちょっと不十分だ。」

7. 盗まれた情報は、感染したマシンで使用されているUSBスティックを感染させ、このスティックに暗号化されたSQLLiteデータベースをコピーすることにより、それが閉環境の外側で使用された時に送信される。このようにしてデータは、ネットワーク接続の無い安全性の高い環境からも盗み出されることになる。

  「Agent.BTZが2008年、既に似たようなことをしている。Flameは不十分だ。」

8. Flameは現在、とうとう捉えられたが、攻撃者はすべての証拠を破壊し、影響を受けたマシンから感染を取り除こうと活動している。

  「何も証明されていない。不十分。」

9. 最新の調査で、Flameが実際、Stuxnetと関係していることが分かっている。そしてFlameが発見されたちょうど1週間後、イスラエルの軍隊とともにStuxnetを開発したことを米国政府が認めた

  「大げさにしようとしているに過ぎない。やはり不十分。」

10. FlameはMicrosoft Updateへのトラフィックを傍受するのに使用する、ローカルプロキシを作成する。これはFlameをLANで他のマシンに広めるのに使用される。

  「不十分。他のコンピュータがそうした偽のアップデートを受けとったにしても、Microsoftによって署名されていないのだから、受け入れるはずがない。」

  攻撃者がMicrosoft Terminal Serverライセンス証明書を再利用する方法を見つけたため、偽のアップデートはMicrosoftのルートと結びつく証明書で署名されている。これだけではWindowsのより新しいバージョンになりすますことはできないとしても、最先端の暗号の調査が行われ、証明書のスプーフィングを可能にするハッシュ衝突を生み出す、完全に新しい方法が考え出されている。しかし、彼らはさらにスーパーコンピュータを必要とした。

  「…」

  そして突然、何の前触れもなく、Flameが不十分か否かに関する議論は…消えてしまった。


まだ問題無くパスワードにデフォルト設定を使っている? やめましょう。

先週、我々は「パスワードは本当にSHA-1+saltで十分だと思いますか?」という記事を再掲載した。

  パスワードに関するこの話題を続けると:コードでパスワードハッシュを実装する際、適切なIteration Countを使用するだけでなく、同じことがKeePass.のようなパスワード管理ソフトにも当てはまる。

  強力なパスワードは記憶するのが難しいため、多くの人がKeePassや他のパスワードマネージャを使用することを選択し、そのパスワードマネージャを、一つあるいは他の動機サービスにコピーする。パスワードはデスクトップやラップトップ、携帯電話、タブレットなど、あらゆるデバイスで利用可能になる。しかしこれは潜在的な問題をもたらす。デバイスの一つに障害が起きるか、盗まれるか、あるいは動機サービスがハッキングされれば、パスワードファイルが悪の手に渡る結果になる可能性が高いのだ。

  そのための明白な防御は、パスワードデータベースファイルで強力なパスワードを使用することだ。しかし強力なパスワードの入力は、携帯電話では面倒だ。そのため多くの人がより短いパスワードを使用することになる。14文字以上のパスワードもしくはパスフレーズが適切だが、我々は皆、多くの人がそうはしないことを知っている。

  パスワードマネージャの設定で、Key Iteration Countを調整することにより、モバイル使用における短いパスワードの問題を軽減することができるかもしれない。一般的にはIteration Countを設定すれば、使用中の最も遅いデバイスで、パスワード認証が約1秒になる。

  たとえば、KeePassを使用しているなら、デフォルトの鍵導出Iteration Countは6,000だ。典型的な携帯電話では、1秒間におよそ200,000の反復が行われる。よって、適切なKey Iteration Countを設定することで、攻撃者にとってパスワードクラッキングを33倍、高くつくものにすることができる。もちろん、パスワードに1文字プラスすれば、同等の保護を与えることになり、2文字追加すれば、1024倍良い保護になる。しかしそれは、Key Iteration Countを途方もなく低い、デフォルトの値にしておく理由ではない。

  以下はWindowsラップトップのKeePassで、値は4,279,296に設定されている:

Number of key encryption rounds

  そしてモバイルパスワードマネージャを開発している人への助言は:モバイル端末のCPUパワーが低いことで、Key Iteration Countを妥当な数値(何十万というレベルではなく、400万から600万であるべき)に設定することは非常に難しい。では携帯電話のGPUをパスワード導出に使用したらどうだろう? それを使用して、鍵導出のための適切なIteration Countが獲得でき、GPUアクセラレーションを使用するパスワードクラッカーに対して、より有利になる。

Post by — @jarnomn

遅いCPUはマルウェア防御に等しい?

  ラボでは毎日、何万もの疑わしいバイナリを扱っている。人間の研究者の比較的小さなグループが、このような量を取り扱える唯一の方法は、もちろんオートメーション化だ。我々のマルウェアサンプル管理システムにインポートされたサンプルはスキャンされ、分類され、仮想環境で実行される。記録が作成され、我々人間が分析する。

  マルウェア作者は、アンチウイルスのベンダが最新の亜種のライフスパンを攻撃するため、オートメーション化と仮想化を使用する事を知っている。(それが、彼らが毎日多数の亜種を作成する理由だ。)量が多いことに加えて、多くのマルウェアの亜種は、我々のリサーチを妨げ、可能な限り長く検出されないようにするため、バーチャルマシン検出とアンチデバッギングコードも含んでいる。

  時には、彼らのアンチデバッギングはあまりに攻撃的で、逆効果寸前ということもある。

  先週、私はデバッガの存在を検出するため、複数のメソッドを使用しているZbot(別名ZeuS)の亜種を分析していた。デバッガが検出されると、ExitProcessが即座に呼びだし、悪意あるコードは実行されない。このアンチデバッグトリックは長らく知られているものだが、その一つには面白い副作用がある。

  以下がアセンブリコードだ:

IDA

  最初に、RDTSC(Read Time-Stamp Counter)インストラクションが実行される。タイムスタンプカウンタは、各クロックサイクル上で値が増加する。カウンタの高位の32ビットはEDXにロードされ、スタック上にプッシュされる。次に、2秒間実行を停止するSleep(0x7D0)が呼び出される。最後にRDTSCが再び実行され、好意の32ビットはスタックに保存された値と比較される。値が等しければ、すなわちRDTSCが実行される実行されるたびに、EDXが同じ値を受けとるなら、サンプルはデバッガが存在しているに違いないと判断する。これは、少なくとも2秒間に2^32クロックサイクルが起き、EDXの値が増加しなければならないという仮定に基づいている。

  これは、サンプルはCPUが2GHz以上で動作すると想定していることを意味している。言い換えれば、2GHz以下のCPUでは、サンプルはデバッグされているかのように振る舞い、実行を中止し、システムに感染しないということだ。私はこのサンプルをIBM T42(1.86GHz)ノート上でテストしたが、同システムはスピードが遅かったため、感染を避けることができた。

  Zbotのアンチデバッギング防御のもう一つ別の面白い副作用は、同サンプルが感染させることの出来るどんなコンピュータも、ボットの高価なコレクションに終わるということだ。もしかしたら、Zbotをばらまいている連中には、特異な趣味があるのだろうか?

  この記事はレスポンスチームのTimoによる。

YouTubeのCPAleadスパム

  エフセキュアの「Safe and Savvy」ブロガーの一人、Melody-Janeが先日、YouTubeで見つけた「エフセキュア インターネット セキュリティ 2010」の「無料」オファーについて、私に聞いてきた。彼女はこのビデオ、そしてそこに付随したリンクは、疑わしいどころではないと考えていた。そこで私はチェックしてみた。

  その結果、「Cost per Action(CPA)」スパムを発見した。私が最近、Facebookで調査しているのと同種のものだ。(私は本当に、「本当に」このCPAが嫌いになりはじめている。)

  これは以下のような典型的ビデオだ:

YouTube Spam

  「削除される前に…リンクをクリックしてダウンロードを始めよう!」

  もう遅い。私はすでに、YouTubeとBit.lyに対して、私のリクエストの30分以内に、このビデオがリンクを悪用していることを報告した。(ナイス!)

  以下は、別のスパムビデオ例だ。

YouTube Spam

  ご覧の通り、スパマーが詐欺に利用しようとしているのは、エフセキュアのソフトウェアだけでなく、他の多くのAV製品も提供されている。

  ビデオ内で紹介されているリンクをクリックすれば、「WordPress.org」ブログに導かれる。

  そして、「無料コンテンツをアンロックする」ためのCPA調査が提示される。

YouTube Spam

  調査に記入すると、得られるコンテンツは何か?

  動画共有サイトへのリンクだ…(何てことだ)。

  不正なソフトウェアのダウンロードは、一般的にマルウェアへの近道だ。我々は(何のソフトウェアであれ)推奨しない。

それでは
ショーン

Q&A:Windows 7におけるファイル拡張子を隠す問題について

  Windows 7についてこのブログに掲載した記事に対し、好意的なコメントを多数頂いた。中にはMicrosoftのExplorer開発チームで働いている人たちからのフィードバックもあった。

  多くのコメントに、このトピックに関する質問が含まれていたので、以下にQ&Aをまとめた:

Q:一体これはどういうことなのか?
A:Windowsでは、デフォルトでEXEのようなファイル拡張子を隠す設定となっていることが問題になっている。ウィルスライターたちは二重拡張子(PICTURE.JPG.EXE)を持つ悪意あるファイルを作成することで、この問題を悪用する。このようなファイルでは、誤解を招くようなアイコンが使用されるているケースも非常に多い。

Q:Windows Explorerはいつから「既知のファイルタイプ」のファイル拡張子を表示していないのか?
A:Windows NTからだ。

Q:どうしてこのような仕様にしているのか?
A:我々には分からない。

Q:これは本当にリスクなのか? ユーザーがハードドライブにこのようなファイルを既に持っている場合、もう遅いのでは?
A:そうでもない。このファイルはインターネットやファイル共有、あるいはリムーバブル・ドライブにより侵入する可能性があり、ユーザーがそのファイルを実行しているとは限らないからだ。

Q:でも、もしそのファイルがインターネット経由で侵入したのなら、Explorerが「信頼できないゾーン」からのものだと警告するはずだ!
A:それはウェブをブラウズするのにInternet Explorerを、電子メールの添付書類をダウンロードするのにOutlookを使用している場合のみだ。しかしネットからファイルをダウンロードする方法は山のようにある:サードパーティのウェブおよび電子メールクライアント、BitTorrent、その他のP2Pクライアント、チャットプログラム等など。また、そのファイルがネットワークシェアもしくはUSBドライブ上にある場合は、そのような警告ダイアログをあてにすることはできない。

Sucks

Q:問題ない。あなた方のスクリーンショットでも、Explorerがファイルに「アプリケーション」と表示されている! だから誰もクリックしたりしないだろう。たとえファイルが、何とか.txtという名称でも。テキストファイルのアイコンだったとしても。
A:確かに…

Q:本物のワームは本当にそんなファイル名を使用しているのか?
A:もちろん。こうしたファイルは、リムーバブル・ドライブまたはネットワークシェア上のランダムなフォルダに、以下のようなファイル名で自身をコピーすることで広まるのが一般的だ:

    E:\PRESENTATION.PPT.exe
    E:\DOCUMENT.DOC.exe
    E:\PORNVIDEO.AVI.exe
    Etc.

  多くの人がこれらをクリックする可能性がある。特にファイルのアイコンがドキュメントアイコンの場合は──またWindowsがファイル名の「.exe」部分を隠している場合には。

Q:それでは、Explorerの設定で「既知のファイルタイプの拡張子を隠す」をオフにするのがソリューションなのか?
A:そうだ。

Windows 7 Folder Options

Q:そうすると、すべてのファイル拡張子が表示されるのか?
A:いや、そうではない。このオプションをオフにしても、まだ隠されたままの実行可能な拡張子もある。

Q:それは何?
A:たとえばPIFがそうだ。このファイルタイプは古いMS-DOSプログラムへのショートカットとなるよう意図されている。問題は、新しいWindows実行ファイルすべてを.PIFに名称変更することは誰でもでき、ダブルクリックすれば間違いなく実行されるということだ。

  たとえば、Scamoワームはまさにこのフローを利用して、以下のようなファイルを仕込む:

    HARRY POTTER 1-6 BOOK.TXT.pif
    ANTHRAX.DOC.pif
    RINGTONES.MP3.pif
    BRITNEY SPEARS FULL ALBUM.MP3.pif
    EMINEM BLOWJOB.JPG.pif
    VISTA REVIEW.DOC.pif
    OSAMA BIN LADEN.MPG.pif
    NOSTRADAMUS.DOC.pif

Q:それでは、PIFファイルを見えるようにするにはどうしたら良いのか?
A:「NeverShowExt」という名のレジストリキーを介してだ。Microsoft Knowledgebaseの記事にリンクしたかったのだが… 見つけることができなかった。だが、GeoCitiesのこのページに、2、3年前に愛好家によって作成された、このトピックに関する記載がある。おそらくこの件に関しては、これが最良の情報源だろう。

Q:あなた方はまだ、MicrosoftがWindows 7でExplorerのふるまいを変更することを期待しているのか?
A:いや、そうでもない。

結論:我々は今も、どうしてWindowsがファイル名の最後の拡張子を何が何でも隠そうとするのか、理解できずにいる。間違いの元なのに。

バックナンバー
セキュリティ関連リンク
セキュリティ機関

政府関連

セキュリティ関連団体

研究機関・大学
詳細カテゴリ
メディア関係者の皆様へ
エフセキュアブログメンバー
エフセキュアブログメンバー
ミッコ・ヒッポネン
エフセキュア CRO(セキュリティ研究所主席研究員)(ヘルシンキ)
(Twitterアカウント)
(研究所Twitter)
ショーン・サリバン
エフセキュア セキュリティ・アドバイザー(ヘルシンキ)
(Twitterアカウント)
高間 剛典
メタ・アソシエイツ代表
(公式ブログ)
(Twitterアカウント)
星澤 裕二
株式会社セキュアブレイン 最高技術責任者
(公式ブログ)
(人物紹介)
岩井 博樹
デロイト トーマツ リスクサービス株式会社 (〜2013年3月 株式会社ラック) 情報セキュリティ大学院大学 客員研究員
(Twitterアカウント)

(人物紹介)
福森 大喜
株式会社サイバーディフェンス研究所 上級分析官
CDI-CIRTメンバー
(人物紹介)
鵜飼 裕司
株式会社FFRI 代表取締役社長
(人物紹介)
福本 佳成
楽天株式会社
執行役員
OWASP Japan
アドバイザリーボード
Rakuten-CERT representative
(人物紹介)
神田 貴雅
エフセキュア株式会社 プロダクトグループ 部長
富安 洋介
エフセキュア株式会社 プロダクトグループ
コーポレートセールスチーム
エフセキュア株式会社
(エフセキュアブログ公式Twitterアカウント)

海外記事翻訳
株式会社イメージズ・アンド・ワーズ
エフセキュアメールマガジン

ブログに載らないメルマガ限定情報や、技術者インタビュー、製品情報、技術解説を掲載して毎月一回配信します。アドレスのみの登録で購読無料。

エフセキュアブログQRコード
QRコード