ドローン撃退銃DroneShieldがピョンチャンに次ぎ全米ストックカーレースNASCARで採用

NASCARレースの実況で、ドローンから撮ったすてきな画面を見たくても、そのクァッドコプターは不思議な力によって地上に釘付けになっているだろう。DroneShieldのそのドローン退治技術は、Texas Motor Speedwayで行われるNASCARのイベントで起用される。

同社が作っている数種類の製品はどれも、飛ぶべきではないところを飛んでいるドローンを見つけて安全に停止させる。もちろんこの問題は激化しており、しかも場所は空港や空軍基地だけではない。大きなスポーツイベントに現れた迷子のドローンが、落ちてゲームの邪魔をするかもしれない。人に当たるかもしれない。カーレースなどでは、重大事故の原因になるかもしれない。

同社の手持ち型ドローン捕獲銃“DroneGun”の最新バージョンはUAV(無人飛行体)のシグナルをスクランブルするから、ドローンはおとなしく駐機してるしかない。最初からそのようにプログラムしておけばよい。それは、個人が買うと違法だが、警察は買える。

最近DroneShieldの技術は、ブリスベーンで行われたイギリス連邦競技大会やピョンチャンのオリンピックで起用された。そして同社の発表によると、今度はテキサス州の当局により、ストックカーレースNASCARの警護に採用された。

ピョンチャン冬季オリンピックで起用されたDroneShield

“有名なイベントをアシストできて光栄だ”、とDroneShieldのCEO Oleg Vornikが発表のメールで言っている。“しかもこれは、弊社の三機種(DroneSentinel, DroneSentry, DroneGun)すべてを警察がひとつのイベントで実際に使う最初の機会になる”。

もちろんそれは、同社にとっても市場拡大のチャンスになるだろう。ドローン市場は今後もまだまだ右肩上がりだから、その機会をうまく捉えたスタートアップだと言えるね。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

FIDOアライアンスおよびW3C、「パスワード」無用の仕組みを提案

「パスワード」という仕組みは、非常に脆弱だ。極端にいってしまえば、セキュリティ対策としては「意味のない」仕組みであるということに、多くの人が同意してくれることだろう。しかし、われわれは依然としてパスワードに頼りきって生活している。パスワードは、覚えておく利用者自身にも負担になるだけでなく、盗むのも難しくなく、重要な場面で役に立たないものなのだ。そのような中、FIDOとW3Cが、WebAuthnというウェブ閲覧時のパスワードを不要とするプロトコルを開発している。

Google、Mozilla、およびMicrosoftも、仕様が定まった段階で本プロトコルの採用を表明している。セキュリティキーやスマートフォンなどの外部デバイスを利用して認証処理を行うようになっている。このプロトコルでは、認証を必要とするウェブサイトと、BluetoothやUSB、あるいはNFCなどを通じて直接通信を行うことにより、利用者の介入をなくす仕組みになっている。これによりフィッシングなどの可能性を0にできるとうたっている。

そう、新しい仕組みに移行することで、数週間毎に新しくする、20文字程度のセキュリティ神への捧げもの(パスワード)から開放されるだけでなく、流行のセキュリティリスクをなくすこともできるわけだ。パスワードを入力しない以上、フィッシングや介入者攻撃(man-in-the-middle attack)などにより、セキュリティ情報を奪われる可能性もなくなる。認証のためのトークンは必要なときにのみ生成されることとなり、それ以外のときには必要なくなるのだ。

WebAuthnの仕様は、ユースケースについても詳しく説明している。たとえば、ノートパソコンを利用して認証を要するウェブサイトにアクセスする場合についても記述されている。この場合、IDとパスワードを入力する従来の方法に変わり、スマートフォンを利用して認証を行うようになっている。利用者は、スマートフォンに表示されるメッセージに応答するだけで、パスワードなどの入力は無用となるのだ。

FIDO Allianceのエグゼクティブ・ディレクターであるBrett McDowellも、新たな仕組みのメリットを語っている。すなわち、情報漏えいや信用情報の盗用が行われる中、パスワードないしワンタイムパスワードなどという脆弱なシステムに頼るのをやめることを目的としているとのこと。ウェブやアプリケーションで、新たな認証システムを採用することにより、これまでに比べてはるかに安全な認証システムを実現できるのだとのことだ。

ただし、今のところはWebAuthnもファイナル段階に至っていない。しかし勧告候補(Candidate Recommendation:CR)段階となっている。すなわち、最終段階の直前にまで達しているというわけだ。

もちろん、どんなセキュリティ対策にも「完ぺき」はないだろう。新しいプロトコルに対しても、欠陥を突く仕組みが登場してくるのは時間の問題なのだろう。しかし、パスワードを排除しようとする流れ自体は正しいものだと思われる。多くの人が、パスワードという仕組みからの脱出を狙ってきたわけだが、WebAuthnはその流れの中から出てきたシステムなのだ。

原文へ

(翻訳:Maeda, H

世界中のネットワーク機器約20万台に大規模な攻撃が発生。「米国の選挙を妨害するな」と表示も意図は不明確

eng-logo-2015イランの情報通信技術省が、過去数日間のうちに約20万台の設定機能付きネットワークスイッチに国際的なサイバー攻撃があったと発表しました。このスイッチはCisco製で、最新の修正パッチが当てられていない状態でした。

報告によると、攻撃者はネットワークスイッチのターミナル画面に星条旗のアスキーアートおよび「我々の選挙を邪魔するな」とメッセージを表示させました。ただ、攻撃を受けたネットワークスイッチはイラン国内だけでなく、約5万5000台は米国、1万4000台は中国でそれぞれ使用されているもので、また欧州やインドでも同様の攻撃が確認されているとモハマド・ジャバド・アザリ・ジャロミIT大臣は語っています。

攻撃はCisco製品が搭載する自動設定展開機能”Smart Install”を介して行われたとみられ、前駆的現象として2017年11月以降、Smart Install機能と探すとみられるネットワークスキャンが発生し、特にこの3~4月にはそれが増加していました。

ただ、少なくともイランはこの攻撃でのデータが流出したり損なわれたりしたわけではなく、被害は最小限に抑えることができたとしています。とはいえ攻撃された機器と選挙云々のメッセージについては、攻撃者の意図が少々つかみにくいのが実際のところ。

本当に選挙妨害への警告が目的だったのなら、なぜ疑惑深まるロシアでなくイランを標的としたのかは疑問です。もしかすると攻撃者はこの警告を出すことで調査を撹乱し、本来の目的を隠そうとした可能性も考えられます。

いずれにせよ、ネットワークスイッチにメーカーが出していた最新の修正パッチを適用していないなど、運用側にも落ち度があったことは否めません。2017年11月から予兆を認識していたのなら、速やかにセキュリティを高める対策をする時間はあったはずです。単なるネットワーク機器とは言っても高機能なものはサーバーやPCなどと同様に1台のコンピューターと同じととらえ、セキュリティパッチを当てる習慣をネットワーク管理者は身につけておく必要があるかもしれません。

なお、この件の攻撃者はIT情報サイトMotherboardに対してイランとロシアを標的として攻撃を行い「単にメッセージを表示しようとしただけだ」と主張しました。ただ、主張を信じるならば実際には米国内や英国などにも被害を出しているあたり、少々的はずれな攻撃だったかもしれません。

Engadget 日本版からの転載。

Symantec の PKI の無効化について: 要対応確認

この記事は Chrome セキュリティ チーム、Devon O'Brien、Ryan Sleevi、Emily Stark による Google Security Blog の記事 "Distrust of the Symantec PKI: Immediate action needed by site operators" を元に翻訳・加筆したものです。また、Google Developers Japan ブログに投稿された記事のクロスポストです。詳しくは元記事をご覧ください。

以前にお知らせしたように、Chrome での Symantec の認証局(Symantec が所有する Thawte、VeriSign、Equifax、GeoTrust、RapidSSL などのブランドも含む)への信頼が無効化される予定です。本投稿では、サイト運営者が今回の無効化によって影響を受けるかどうかを判断する方法と、影響を受ける場合、いつまでに何をする必要があるのかについて説明します。対象となる証明書の置き換えを行わないと、Chrome などの主要なブラウザの今後のバージョンで、サイトを正しく閲覧できなくなります。

Chrome 66

2016 年 6 月 1 日より前に発行された Symantec の SSL/TLS 証明書を使っているサイトは、Chrome 66 で動作を停止します。これにより、すでにユーザーに影響が出ている可能性があります。

サイトで対象となる証明書を使っているかどうかわからない場合は、Chrome Canary 版で変更をプレビューして、サイトが影響を受けるかどうかを確認できます。サイトに接続した際に、下のような証明書エラーや DevTools での警告が表示される場合、証明書を置き換える必要があります。新しい証明書は、どの信頼されている CA からでも取得できます。最近 Symantec の CA ビジネスを買収した Digicert も利用できます。

2016 年 6 月 1 日より前に発行された Legacy Symantec SSL/TLS 証明書を使っている場合に Chrome 66 ユーザーに表示される可能性がある証明書エラーの例。 


Chrome 66 のリリース前に、証明書を置き換える必要がある場合に表示される DevTools のメッセージ。

Chrome 66 は、Canary チャンネルと Dev チャンネルですでにリリースされています。そのため、これらの Chrome チャンネルを使っているユーザーは、すでに影響を受けている可能性があります。影響を受けるサイトが 2018 年 3 月 15 日までに証明書を置き換えなかった場合、Chrome ベータ版のユーザーにもエラーが発生し始めます。Chrome Canary 版から現在のサイトを開いてエラーが発生する場合、できる限り早く証明書を置き換えることを強くおすすめします。

Chrome 70

Chrome 70 以降、他のすべての Symantec SSL/TLS 証明書が動作しなくなり、前述のような証明書エラーが発生します。お使いの証明書が影響を受けるかどうかを確認するには、現在の Chrome を使ってサイトにアクセスし、DevTools を開きます。証明書を置き換える必要がある場合、そのことを通知するメッセージがコンソールに表示されます。

Chrome 70 のリリース前に、証明書を置き換える必要がある場合に表示される DevTools のメッセージ。

DevTools にこのメッセージが表示される場合は、できる限り早く証明書を置き換えてください。証明書を置き換えないと、早ければ 2018 年 7 月 20 日より、サイトで証明書エラーが発生し始めます。最初の Chrome 70 のベータ版リリースは、2018 年 9 月 13 日頃を予定しています。

Chrome のリリース予定スケジュール

下の表は、Chrome 66 および 70 の最初の Canary 版、ベータ版、安定版リリースの日程を示しています。リリースによって受ける影響は、最初の Canary 版リリースのタイミングから発生しはじめます。それ以降、ベータ版、そして最終的に安定版がリリースされるにつれて、対象端末が徐々に広がります。サイト運営者の方には、Chrome 66 および 70 の最初の Canary リリースが行われる前、遅くともベータ版のリリース日までに必要な変更を行うことを強くおすすめします。

リリース
最初の Canary 版
最初のベータ版
安定版リリース
Chrome 66
2018 年 1 月 20 日
~ 2018 年 3 月 15 日
~ 2018 年 4 月 17 日
Chrome 70
~ 2018 年 7 月 20 日
~ 2018 年 9 月 13 日
~ 2018 年 10 月 16 日

特定のバージョンの Chrome のリリース スケジュールに関する情報は、Chromium 開発カレンダーにも掲載されています。リリースのスケジュールが変更になった場合は、このカレンダーが更新されます。

特定の企業ユーザーのニーズに対応するため、Chrome 66 以降では、Legacy Symantec PKI の無効化を停止する Enterprise Policy も実装されます。2019 年 1 月 1 日には、このポリシーは利用できなくなり、すべてのユーザーに対して Legacy Symantec PKI が無効化されます。

特記事項: Chrome 65

以前のお知らせにありましたように、2017 年 12 月 1 日以降に Legacy Symantec PKI から発行された SSL/TLS 証明書は信頼されなくなります。対象となる証明書は、DigiCert と特別な契約を結んでいなければ取得できないので、これによって影響を受けるサイト運営者はほとんどありません。Chrome 65 時点で、対象となる証明書を使っているサイトにアクセスすると、エラーが発生してリクエストはブロックされます。このエラーを回避するには、対象となる証明書が Chrome などのブラウザではなく、以前の端末のみに対してサービスを提供するようにします。


Reviewed by Eiji Kitamura and Yoshifumi Yamaguchi - Developer Relations Team

見捨てられるPenryn世代: Intelは古いチップのSpectre対策を中止

チップの欠陥MeltdownとSpectreに対して、引き続き行われているパッチ努力の一環としてIntelは先月、2005年までさかのぼって開発コードYorkfield以降のプロセッサーにも修復を適用する、と示唆した。しかし最近のガイダンス文書によると、これらの古いプラットホームの多くは結局、修復を受けないことになった。

具体的には、Spectre Variant 2(変種2)のための対策は、チップの世代で言ってBloomfield, Clarksfield, Gulftown, Harpertown, Jasper Forest, Penryn, SoFIA 3GR, Wolfdale, Yorkfieldに対しては行われない。(IntelのコードネームのリストはWikipediaにある。)

変種2はブロックや回避がいちばん困難な欠陥なので、対策も難しい。マイクロコードのアップデートで何かをコピペして終わり、という仕事ではない。

そのガイダンス文書(PDF)には、修復対応をやめる理由が書かれている:

  • マイクロアーキテクチャの性格により、変種2を緩和する機能の実効的な実装ができない
  • システムソフトウェアの商用サポートが不十分
  • 顧客からの入力によると、これらの製品の多くが“クローズド・システム”として実装されているので、これらの脆弱性への露出の可能性が低い。

言い換えると: それは超難しい、サポートが薄い、そしてバグが悪用されるような使い方をしている人がとても少ない。

そもそもそれら古い機種は、リストが膨大であるだけに、Intelとしてもリーズナブルな後退をした、と言えるだろう。しかしそれでも、システムの管理者は、これらの世代のチップが自分たちのシステムの中で外部者に対してむき出しになっていないか(悪用の可能性がないか)、チェックしたいだろう。

そしてユーザーに関しては、Core 2 Duoに代表されるPenryns世代は、まだ古いラップトップを使っている人が少なくないだろう。2008年には、それがIntelのすべてだった。ぼくみたいに、古い機種に愛着があって捨てられない人は、重要な仕事をその上でやらないようにしよう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

アメリカで売る前に袋叩きのHuaweiは、それでもまだこの大市場を諦めない

ぼくがHuaweiの旗艦製品の説明を受けた最後の二度は、おかしなことが起きた。同社のアメリカでの流通計画に対する大きな障害物がある、というニュースが発生したのだ。最初のはCESの真っ最中だったが、AT&Tが手を引いた。次は大画面のスマートフォンP20のローンチ直前に、Best BuyがHuaweiを切る決定をした。ただしHuaweiによると、P20はアメリカで売りたい機種には含まれていない。

この中国のハードウェアメーカーがまさにアメリカでかなりのプレゼンスを確立しようと努力しているそのときに、相次いでそんなことが起きた。しかし米国政府による拒否の余波が広がる中で同社は、逃げも隠れもしないと意地を張っている。

CNETに宛てたメールで同社の消費者部門のCEO Richard Yuは、その強気を再確認した。“われわれはワールドクラスの製品とイノベーションをお届けすることにフォーカスし続けることによって、アメリカ市場とアメリカの消費者の信頼を勝ち取りたい。われわれがその信頼を裏切ることは、決してない”、とYuは主張する。

YuはAT&Tとの契約が破談になったときも、CESのステージで同じ気持ちを述べたが、今回はそのときほど激しい口調ではない。Yuの再説はもっぱら、アメリカのさまざまな安全保障部門からの度重なる警告はあったけれども、この騒動全体が度外れである、という主張の繰り返しだ。

“安全保障のリスク云々は根拠のない疑いに基づいており、率直に言って不公平である”、とYuは付け加える。“それらが事実に基づいている主張なら、オープンで透明な議論を歓迎したい”。

これらの主張が同社の意図を表しているとしても、この世界で三番目に大きいモバイル市場にHuaweiが食い込むのは、相当に厳しいだろう。アメリカではスマートフォンを通信企業(電話会社)から買うことが多いが、同社が頼みにできるキャリアは存在しない。しかもアメリカ最大の量販店にフラレたことは、傷口に塩である。

そして今後同社が起死回生に成功したとしても、国防総省の警告があるかぎり、アメリカの消費者に売るのは難しい。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

ニューヨーク市は住民にサイバーセキュリティアプリを無料で配布する

ひとつの都市(アトランタ)がサイバー攻撃されたこの怖ろしい週に、ニューヨークはその予防策を講じようとしている。

そのタイミングはあくまでも偶然だが、ニューヨーク市の市長Bill de Blasioは今日(米国時間3/29)、市民をとくにモバイルデバイス上のオンラインの悪行から護るための、一連のセキュリティツールを用意し、まずその第一弾を導入する、と発表した。

それがこの夏ローンチすると、ニューヨーク市の住民はNYC Secureと呼ばれる無料のアプリをダウンロードできる。このアプリはスマートフォンのユーザーに、ありうる危険を警報し、“悪質なWi-Fiネットワークからの遮断や、危険なWebサイトに行かないこと、悪質なアプリをアンインストールすることなど”の対策を教える。

アプリ自身が何かをやってくれることはないので、もっぱらユーザーが言われたアドバイスを守らなければならない。NYC Secureが個人を特定できる情報やプライベートなデータを集めることもない。

市はまた、その公開Wi-Fiネットワークのセキュリティも強化する。それは、悪いやつが暗号化されてない個人情報を盗むことで悪名高いターゲットだ。市は、Quad9というサービスを利用してDNSの保護を実装する。それは、Global Cyber Alliance(GCA)とIBMとPacket Clearing Houseが共作した無料のサイバーセキュリティ製品だ。

市のセキュリティ担当官Geoff Brownはこう述べる: “たえずユーザーのすきをねらっているサイバー犯罪者から前もって市民を護るためには、市民のデジタル生活の安全に投資する必要がある。サイバーセキュリティの脅威に対して免疫のある個人は存在しないから、今回の計画は、多くの場合大量の機密データが所在する個人のデバイスに、セキュリティの新しい層を加える”。

2017年の7月に市長命令で創設されたサイバー防衛団体NYC Cyber Command(NYC3)がこの新しいセキュリティツールの導入を担当し、それらの実装を監督する。

セキュリティ企業McAfeeのCEO Christopher Youngは、こう言う: “ニューヨーク市のこのような活動は、サイバー犯罪が増加していることへの市民の認識を強化し、自衛のための行動ができるようにする”。

国際的なビジネスハブで、文化の中心都市でもあるニューヨークは、さまざまな、ときには当市独特のサイバーセキュリティの脅威にさらされている。しかしそんな都市だからこそ、他の大都市のお手本になるような、市としての主体的なサイバーセキュリティ対策を展開できる、とも言えるだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

IETFがTLS 1.3を承認、悪質なハッカーや盗聴者が仕事をしづらくなる仕掛けを盛り込む

聞こえるかな? 世界中のハッカーや諜報員たちが大声で一斉に叫んでいるよ。Internet Engineers Task Force(IETF)が今日、全会一致で、Web上の暗号化されている接続を高速化し、盗聴しづらくするセキュリティフレームワークを承認した。

それはTransport Layer Security version 1.3と呼ばれ、派手な話題ではないけど、至るところに悪いやつがいるようになったWebの、安全強化策のひとつだ。IETFは、世界中のエンジニアたちの集まりで、このようなスタンダードの策定で協力し合っている。そして今回のTLS 1.3の承認までは、4年あまりという長い年月と、提出されたドラフト(草稿)数28という、たいへんな作業を経ている。

それは、インターネットがとてもデリケートなマシンで、その基本的な部分の変更、たとえばクライアントとサーバー間の安全な暗号化接続の確立は、きわめて慎重な協議を必要とするからだ。

ここで技術的な詳細は述べられないが(ぼくが挑戦しても途方に暮れるだけだろう)、TSL 1.3は、ユーザーの安全を守るためにいくつかの重要な変更を加えている。

  • クライアントとサーバー間の“ハンドシェイク”が簡素化され、平文で送信されるデータの量を最小化するので、暗号化がより早期に開始される。
  • 前方秘匿性”によりハッカーは一回の鍵交換から鍵を解読できないようになり、その後それを使ってそのほかの鍵を解読することもできない。
  • “レガシーの”暗号化アルゴリズムをオプションから除く。それがうっかり、やむを得ず使われると、その欠点を利用してメッセージの暗号を破られることがある。
  • 新たに“0-RTT”、ゼロ・ラウンドトリップ・タイムを導入。このモードでは、サーバーとクライアントが一部の要件を事前に確立していて、お互いを紹介し合わなくても直ちにデータの送信を開始できる。

このスタンダードのの全文は155ページあり、専門のエンジニアでないと理解は難しいだろう。でもとにかく容易に入手できるから、勉強意欲のある方はぜひ挑戦を。

もちろん、現場の実装努力がなければ新しいスタンダードも効果を発揮できないが、IETFの承認が下りたことによって、大企業やWebサービス、より高いレベルのスタンダードなどが実装に着手するだろう。そのことに、われわれ一般ユーザーは気づかないかもしれないけど、インターネットという舞台の縁の下で頑張っているエンジニアたちや暗号技術者などに、この場を借りて謝辞を述べておきたい。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

IBMがセキュリティやDDoS防御でCloudflareとパートナー、サービスの内製を選ばず

最近の数年間でCloudflareは、データセンターの立地とパートナーシップでグローバルなネットワークを築き、同社のDDoS防御やセキュリティツール、Webサイトの加速、などのサービスを拡大してきた。これだけの専門的能力は簡単に得られるものではないので、IBMのような巨大グローバル企業でさえ今日(米国時間3/13)、内製よりもむしろCloudflareとのパートナーシップにより、これらのサービスを顧客に提供していく、と発表したのも、不思議ではないかもしれない。

IBMが新たに始めたCloud Internet Servicesは今日発表され、サイトの保護と高速化のためのCloudflareのサービスをすべて提供する。IBMはこの発表を、来週行われるTHINKカンファレンスの前、というタイミングで行っているのだ。

IBMのWatsonとクラウドを担当するCTO Bryson Koehlerによると、IBM Cloudのユーザーは、一回のクリックでこれらの機能をonにできる。“Cloudflareは、ワールドクラスのツールセットを作るすごい仕事をしている。それらは使いやすいだけでなく、うちのチームが使っているのと同じスタンダードに従っている”、と彼は語る。“今日のように、変化が早くてサービスがつねに進化しているときには、いつも内製かパートナーかという決定を迫られる。そしてキャッシングやロードバランシングでは、彼らがうちとのパートナーシップにふさわしい仕事を成し遂げている”。

このパートナーシップに加えてIBMは今日、二つの新しいセキュリティ機能を発表した: それはIBM Cloud Security Advisorと、IBM Cloud App IDの新しい機能だ。Cloud Security Advisorは、デベロッパーとオペレーションの両チームに、彼らのセキュリティ態勢への、これまでよりも多くて深いインサイトを提供する。その中には、Webサーバーのセキュリティ証明がそろそろ期限切れだというベーシックなアラートがあったり、あるいはアプリケーションとデータに影響を与えるIBMのグローバルネットワーク上に兆候のある脅威に関する警報だったりする。このツールは十分高度に作りこまれているので、たとえば特定の規制に従ってデータを管理しなければならないデベロッパーが、うかつにPCIやHIPAA準拠のサービスからデータをロードし、それを非準拠のサービスに書き出す、といった事故を未然に防ぐことができる。

Cloud Security Advisorはまだ実験段階のプロダクトだが、必要なすべてのデータを単一のダッシュボード上に表示する。

App IDの方は、正しい認証を経たユーザーだけが、アプリケーションやデータにアクセスできるようにする。とくに新しい機能ではないが、IBMはこのサービスを今後、コンテナやIBM Cloud Container Serviceにも適用する。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

オープンソースのライブラリのセキュリティチェックと脆弱性フィックスを代行するSnykが$7Mを調達

オープンソースのライブラリはデベロッパーにとってとても重要なリソースだが、今日の慌ただしいアプリケーション開発環境では、それらが安全なコードであるという確信を持つことが容易ではない。そこでSnykは、デベロッパーがオープンソースのコードに脆弱性を見つけて直す作業を支援し、確実に安全なコードがプロダクションのその後の工程で使われるようにする。同社は今日(米国時間3/6)、Boldstart VenturesとCanaan PartnersがリードするシリーズAのラウンドで、700万ドルを調達したことを発表した。

このラウンドには、Heavybit, FundFire, VeeamのPeter McKay、およびそのほか数名の投資家が参加した。同社は2016年に、同じくBoldstartがリードするラウンドにより、300万ドルのシード資金を獲得している。

この種のバグフィックスは、アプリケーションが完成して世に出てからではなく、開発チーム自身がやった方がよい、とSnykのCEOで協同ファウンダーのGuy Podjarnyは信じている。今は開発工程にセキュリティチームがいないやり方が一般的になりつつあるが、そうでない方がよい、と彼は言う。ソフトウェアが何か月も何年もかかって構築されるときはそれでも良いが、しかし今日のような開発スピードでは、デベロッパーチームとは別のセキュリティチームがソフトウェアをチェックするやり方は、合理的でも効率的でもない、とPodjarnyは主張する。

“われわれは開発工程の中へエレガントに統合し、オープンソースの部分に既知の脆弱性を見つけ、それらをフィックスする”、とPodjarnyは説明する。同社はユーザーのGitHubリポジトリの中のコードをモニタするが、サードパーティの企業とソースコードを共有している場合も、どのファイルを使っているのかという“マニフェストファイルにアクセスできれば、われわれの仕事にとってとくに問題はない”、と彼は言う。

同社はインターネットのあちこちから情報を集めて、彼らがモニタしているオープンソースプロジェクトの既知の脆弱性とその特徴を知る。ユーザーが使っているライブラリと、使用している言語(JavaScript, Java, .netなど)が分かれば、今使っているコードが古いバージョンである(かもしれない)ことも分かる。

そしてそれらの脆弱性が見つかったら、そのコードに依存しているものを壊さずに早く効率的にフィックスする方法のアドバイスと共に、プルリクエストを送る。

  1. deep-integrations-into-a-large-and-growing-list-of-platforms.png

  2. detailed-advisories-for-vulnerabilities-in-the-snyk-vulnerability-db.png

  3. detailed-test-reports-with-a-single-click-fix-button.png

PodjarnyはBlaze.ioの協同ファウンダーだったが、同社は2012年にAkamaiに買収された。彼は買収後に、その企業のWeb体験ビジネスのCTOになり、2015年のSnykの立ち上げまでそこに在籍した。

そのときのスタートアップ体験が、ニューヨークのアーリーステージVC Boldstart VenturesのファウンダーでマネージングパートナーEd Simの目にとまった。“彼がAkamaiに売ったスタートアップにもうちは投資したが、彼と彼の協同ファウンダーたちには深いセキュリティ経験があった。また同社(Snyk)は、企業の大きな満たされざるニーズ、すなわちコードを継続的にデプロイしていくときの、オープンソースコードのセキュリティの確保というニーズを、満たすことができた”、とSimは語る。

SnykはまだシリーズAの企業だが、しかし今では月間ダウンロード数が35万もあり、大手の有料ユーザー企業が130社いる。同社は今後、対象とするオープンソースプロジェクトをもっと多くしていきたい、と考えている。また、現在30名の社員を、その倍にしたい。今同社は、テルアビブとロンドンにオフィスがあり、ボストンに小さな営業とサポートのオフィスがある。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

ハッキングに強いサイトを作るヒント:サイバーセキュリティ月間によせて

2 月 1 日 ~ 3 月 18 日は「サイバーセキュリティ月間」です。
サイバーセキュリティ月間に合わせて、本日は、日本においても引き続き被害が多く見られる不正なハッキングから、サイトを守るための Tips を改めてご紹介したいと思います。

そもそも不正なハッキングはなぜ起きるのでしょうか。不正に金銭を取得することだったり、政治的または社会的なメッセージを伝えることだったりと、不正なハッキングの目的はさまざまです。悪質なハッカーはサイトの脆弱性を狙ってサイトに不正にアクセスし、あなたの管理権限を乗っ取ります。そして、サイトを改ざんし、別のサイトへの誘導などの踏み台に利用します。それによってあなたのサイトにアクセスしていると思っているユーザーは、知らない間にフィッシング サイトや偽のショッピングサイトに誘導され、その結果として個人情報や金銭を奪われるといった被害にあうかもしれません。みなさんのサイトがこうした犯罪に加担してしまわないよう、ぜひサイトのセキュリティを高め、ハッキングを防ぎましょう。

Google ではさまざまな形でウェブスパムなどへの対策を行っていますが、Advanced Hosting Meetup のようにインターネット サービスを提供する他の会社のみなさんと企業の枠を越えた対策も行っています。そこで、今回 Advanced Hosting Meetup のメンバーや、ホスティング会社としてさくらインターネット株式会社様と GMOペパボ株式会社様、そして WordPress コミュニティのみなさんにもサイトのハッキングを防ぐためのアイディアをお伺いしました。その中でみなさんからのアイディアに共通してみられたハッキングを防ぐためのコツを 3 つご紹介します。
  • パスワードを複雑なものにする


  • パスワードをデフォルトのままにしていたり、同じパスワードを複数のサービスで使いまわしていたり、一般的な推測されやすい単語にしていたりと、パスワードを適切に設定・管理されていない方が多く見られます。パスワードは覚えられないくらい複雑なものにして、パスワードマネージャなどを使うことをお勧めします。また、パスワードだけでなく、2 段階認証などが利用できる場合は 2 段階認証を必ず使うようにしましょう。
  • CMS やシステムを最新に保つ

  • CMS やプラグインは必ず最新に保つよう心がけましょう。CMS 側から提供されているアップデートは、多くの場合自動的に適用されるように設定できます。残念なことにデフォルトで自動アップデートになっているものを手動で停止してハッキングの被害にあうケースが数多く見られます。自動アップデートはオフにせず、必ず最新の CMS を使うようにしてください。
    ※ WordPress については、WordPress コミュニティで「あなたのWordPressを安全に保つ方法」という記事も公開されましたのであわせてご覧ください。
  • ファイアウォールをきちんと管理する


  • 多くのホスティング サービスではファイアウォール サービスを提供しています。しかし、デフォルトでオンになっているファイアウォールを停止したり、いくつかのポートを公開し、結果としてセキュリティを落としているサービスが数多く見られます。ファイアウォールはきちんと管理・設定しましょう。例えば、管理者権限があるサーバサービスではファイアウォールを適切に設定しないと脆弱なポートが開放されたままになってしまいます。きちんと設定して使用するポートだけを開放しましょう。また、多くのレンタルサーバ サービスではウェブ アプリケーション ファイアウォール(WAF)機能が提供されておりますので、これを ON にすることにより脆弱性を利用した攻撃などを防ぐことができるようになります。
最後に、昨年末にグローバルで行った #NoHacked キャンペーンの記事を改めてご紹介します。

ソーシャル
ブログ

インターネットの安全性を高めるためには、ウェブマスター(サイト運営者)のみなさんのご協力は不可欠です。
ぜひこの機会にみなさんのサイトが安全に管理されているか、確認してみてください。

インターネットがより安全に安心して使える場所となるように、Google は今後もさまざまな活動を実施していきます。

Takeaki Kanaya and Kiyotaka Tanaka, Online Safety Samurai, Google Japan

世界最大のDDoS攻撃はGitHubをわずか10分足らずオフラインにしただけだった

サイバー攻撃はこのところ攻守ともに巧妙になっている。そのことを示すようにGitHubは、今週襲ってきた知られているかぎり史上最大のDDoS攻撃を切り抜けたことを、公表した。

DDoS(distributed denial of service, 分散型サービス妨害)は、Webサイトやその提供サービスを、それらのサービスやインフラストラクチャが対応できないほど大量のトラフィックで爆撃して、ダウンさせてしまう攻撃だ。ターゲットを強制的にオフラインにするために、よく使われる攻撃手段だ。

GitHubはよくやられるターゲットだ。インターネットの検閲システムをバイパスするソフトをホストした2015年の5日間に及ぶ攻撃は、その背後に中国政府がいたと各方面から疑われている。そして今回の最新の攻撃はその規模が過去最大で、ピーク時には1.35Tbpsに達した。

その事件をあらためて語るブログ記事でGitHubは、犯人は ‘memcaching’と呼ばれるものをハイジャックした、と言っている。高性能や大きな需要への対応を要求されるWebサイトはデータを高速メモリにキャッシュして高速対応を図るが、そのような用途のメモリキャッシュのことを一般的にmemcacheと呼ぶ。犯人たちはそこに膨大な量のトラフィックをぶつけて、GitHubを攻撃した。それをするために彼らは最初GitHubのIPアドレスを装い、メモリキャッシュシステムmemcachedのインスタンスを乗っ取って、GitHubによると、“うかつにも一般のインターネット上でアクセスできる”ようにした。

その結果トラフィックの大洪水が流れ込んだ。Wired誌の記事によると、攻撃に使われたmemcachedのインスタンスはデータ量を約50倍に増幅した。

GitHubの着信トラフィックが攻撃により急上昇

GitHubは、Akamai Prolexicに助けを求めた。後者はGitHubへのトラフィックを同社の“スクラビング”センター(別名“洗濯機”)に迂回させ、悪者と思われるブロックデータを削除した。すると攻撃が始まってから8分後に、犯人たちは攻撃をやめ、DDoSは止まった。

結局、GitHubがオフラインだったのは17:21 – 17:26 UTCの5分間、断続的な接続状態になったのは17:26 – 17:30 UTCの4分間だった。

GitHubのサービスは、コードを扱う企業にとってきわめて重要で、しかもそんな企業はとても多い。どんなに時間が短くてもサービスの停止は喜べないが、しかし今回の対応は見事であり、良い前兆だ。GitHubは、今回のような、あるいはまったく別の、攻撃がまたあっても、適切に防御できる、と言っている。

事件の詳細はGitHubのブログ記事にある。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

どこかの政府ご愛用のCellebriteに頼めばiOS 11が動くiPhoneをアンロックできる

Forbesの記事によると、イスラエルの企業Cellebriteが今や最新機種のiPhoneをアンロックできるそうだ。Cellebriteは、警察の捜査目的などのために、ロックされているモバイルデバイスからデータを取り出す科学捜査ツールを売っていることで有名な企業だ。

iOSの初期のバージョンはあまり安全ではなかったが、近年それは大きく変わった。今売られているiOSデバイスはすべて安全な隔離領域があり、パスコードを使っていればデータはすべて暗号化され、ブート時やデバイスの使用時には何段階ものセキュリティチェックが行われる。

だから、パスコードを知らない人がデバイス上のデータに触ろうとしても、それは難しい。しかし多くの企業が、モバイルデバイスをアンロックする脆弱性を見つけようと努力している。諜報機関などが、そんな捜査ツールの企業にお金を払ってモバイルデバイスをアンロックしようとするから、それはかなり儲かる商売でもある。

そんな捜査ツールが、後れをとることもある。たとえばiOS 8が動いているiPhone 6をアンロックするデバイスは、簡単に見つかる。しかしForbesの記事とCellebriteのWebサイトが正しければ、政府機関などはCellebriteにお金を払って、iOS 11の動くiPhone 8をアンロックできる。なお、Cellebriteは最近のAndroidデバイスもアンロックできる

最新バージョンのiOS 11(11.2.6)でもアンロックできるのか、それとも昨年の9月の11.0だけか、そこは不明だ。すべてのiOSデバイスなのか、一部のデバイスだけか、それも分からない。Forbesが見つけた記事によると、iPhone XもCellebriteによってアンロックされたようだ。

これは、猫と鼠の追いかけっこゲームだ。Appleの技術者たちは今ごろ、すべての脆弱性を塞ごうと躍起になっているだろう。とにかく、自分のスマートフォンから個人情報を読まれたくなかったら、デバイス…ハードウェアもOSも…を最新に保つべきだ。

新しい機能があることに加えて、当てられているセキュリティパッチの数も最新機/最新OSでは多い。ハッカーは前と同じ手口を使おうとして、行き詰まるだろう。

[Edward Snowden: オープンで安価な製品を買わずにiPhoneを買う唯一の理由は、Appleの厳しいプライバシー保護とセキュリティだ。でもこの記事と、ForbesのCellebriteに関する記事は、iPhoneの価値の核心を脅かす。]

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

保護されたウェブの普及を目指して

この記事は Chrome セキュリティ プロダクト マネージャー、Emily Schechter による Chromium Blog の記事 "Chromium Blog: A secure web is here to stay" を元に翻訳・加筆したものです。また、Google Developers Japan ブログに投稿された記事のクロスポストです。詳しくは元記事をご覧ください。

私たちはここ数年間、サイトで HTTPS による暗号化を採用するよう強く働きかけることによって、保護されたウェブを目指してきました。そして昨年は、「保護されていません」と表示される HTTP ページを徐々に増やすことによって、HTTP サイトが保護されていないことをユーザーに理解してもらうよう努めてきました。2018 年 7 月に Chrome 68 がリリースされると、すべての HTTP サイトに「保護されていません」と表示されるようになります。

Chrome 68 では、すべての HTTP ページのオムニボックスに「保護されていません」と表示されます。

デベロッパーはサイトを HTTPS に移行し、ウェブを誰でも安全に使えるようにしてきました。昨年の進展はめざましく、その動きはさらに続いています。

  • Android と Windows の Chrome トラフィックの 68% 以上が保護されています。
  • Chrome OS と Mac での Chrome トラフィックの 78% 以上が保護されています。
  • ウェブ上のトップ 100 サイトのうち、81 がデフォルトで HTTPS を使用しています。

Chrome は、HTTPS をできるだけ簡単に設定できるようにするために貢献しています。デベロッパーがサイトを HTTPS に移行する助けになるように、ウェブページを改善するための自動ツール、Lighthouse最新 Node CLI 版では、混合コンテンツの監査が可能になっています。この Lighthouse の新しい監査機能を使うと、HTTP を使ってサイトに読み込まれているリソースや、サブリソースの参照を HTTPS 版に変更するだけで HTTPS にアップグレードできるリソースを見つけることができます。

Lighthouse は、ウェブページを改善する自動デベロッパー ツールです。

Chrome の新しいインターフェースでは、すべての HTTP サイトが保護されているわけではないことがわかりやすくなるため、ウェブをデフォルトで保護された HTTPS に切り替えるよう促す効果があります。HTTPS は、今までになく簡単で安価なものになり、パフォーマンスの改善や、HTTP で扱うには危険だった、パワフルな新機能を利用可能にします。デベロッパーの皆さんは、まずセットアップ ガイドをご覧ください。

Reviewed by Eiji Kitamura - Developer Relations Team

Veilは超心配性な人びとのためのプライベートブラウジング機構

もしあなたが、ブラウザで見ているものを誰かによって知られることを心配しているのなら、それを秘密にするための手段は、手段の難しさと実際の効果は様々だが沢山用意されている。その中でもVeilはおそらく他のどのような匿名ブラウジング手段よりも進化した手法である。単に外部の攻撃者からあなたが見ているページを隠すだけではなく、使っているOSそのものからも見えないようにするからだ。

このサービスについて書かれた論文の中で、Veilを開発したMITの研究者たちは、現状のプライベートブラウジングモードの問題点として、たとえTorやその他の手段を講じていたとしても、そのデバイス自身からのアクセスのトレースはRAMや一時的なストレージ上に残されてしまうことを指摘している。

匿名でページを訪問したとしても、相変わらずそのページとそのコンポーネントはメモリにロードされ、表示され、キャッシュされる必要があり。ライブラリやプラグインはアクセスされたり変更されたりする可能性がある。ブラウザーはこうしたトレースを削除しようとはするものの、その成功の度合いは設定方法によって異なるものとなる。たとえそれが一部のデータのハッシュやタイムスタンプであったとしても、あなたの活動に付き従う影響が、RAMの中に残される可能性がある。

「根本的な問題は、ブラウザーがこうした情報を集めることに起因しています。もちろんブラウザーはそれを消し去ることにも最善を尽くしています。しかしブラウザが最善を尽くしたとしても、最終的に残ってしまうものがあるのです」と、そのニュースリリースの中で説明するのは、論文の第一著者であるMITの大学院生Frank Wangである。「なので私たちはそもそも最初からそうした情報を収集しないことにしました」。

Veilは、サイトの配信を、彼らが「目隠しサーバー」(blinding server)と呼ぶものを介して行うことで、何段階も進んだものにする。ブラウザのアドレスバーではなく、目隠しサーバー上のページでURLを入力すると、対応するページが特別なサーバーたちから読み込まれる。それらは転送時およびキャッシュのなかでは暗号化されたままで、表示されるときだけに復号化される。リンクとURL自体も暗号化されているため、要求されたコンテンツに関連付けられることはない。

さらに、それはユーザーには表示されないゴミコードをページに挿入し、コンテンツの「突然変異」も(これもまた表示されないように)行う、こうすることで同じページを繰り返しロードした際に、ユーザーが見るものは同じままで、結果として得られるハッシュ値やペイロードサイズなどのデジタルフィンガープリントが毎回違うようにすることができる。

このようにして、あなたのコンピューターは実際のURLを覚えることはなく、どのようなデータもキャッシュすることなく、そして残されるトレースはどのようなデータベースに対してもあるいは互いに、マッチすることはない。

最も極端なプライバシーケースでは、利用者は実際のウェブページとやり取りすることさえしない。ただそのイメージを見るだけだ。

WebページをVeilと互換性のあるものに変換するには、研究者たちが提供する特別なコンパイラを使用する。突然変異と追加の暗号処理のせいで、使用帯域とリクエスト回数は増加するが、それ以外はそのまま変らずに使える筈だ。

いやちょっと待った、実はまだ続きがある!こうしたレベルの難読化レベルでさえも、十分ではないと心配している人たち向けには、別の選択肢もある。私も常々可能性を考えていたものの、決して実行されているところを見たことがない方法だ:すなわち画像データだけでやりとりをするのだ。

もしお望みなら、Veilはターゲットサイトの実際のコードを表示する代わりに、スクリーンショットを撮って表示する。スクリーンショット上をクリックすると、そのクリックの位置が記録され、実際のページに送信されて、結果のスクリーンショットが返される。

まあおそらく次のステップでは、どこか完全に別の場所に離れて設置されたコンピューターを眺めて、そこに何が表示されているかをピッグ・ラテン語で報告してくれるロボットが使われることだろう(ピッグ・ラテン語とはふざけてラテン語的な響きをもつ言い回しに変えること)。

もちろん、これはゼロトラストのような状況ではない。目隠しサーバーは、Torノードと同様に、システムを侵害し得るボランティアたちや組織によって運営される(サイトが自身のためのサーバーを運用することもできる)。しかし、そのプロセスが数学的かつ手続き的に検証可能であれば、問題はない。もちろん、セキュリティ研究者たちがコードを監査する必要があるだろう。

Veilは先週サンディエゴで開催された、Network and Distributed Systems Security Symposiumで発表された。ここで全文を読むことができる

[原文へ]
(翻訳:sako)

FEATURED IMAGE: YURI SAMOILOV/FLICKR UNDER A CCPL LICENSE (IMAGE HAS BEEN MODIFIED)

クラウドアプリケーションのセキュリティとコンプライアンスチェックを自動化するChefのInSpec 2.0

データのリポジトリをAmazonでロックすることを忘れて、機密データを露出した、なんて話を何度聞いたことか。それは、稀(まれ)ではなく、びっくりするほど多い。そこでChefは、devやopsの人びとがそんな事件を防ごうとするときの、お手伝いをしたいと考えた。今日同社がリリースしたInSpec 2.0は、クラウド上でアプリケーションのセキュリティとコンプライアンスを自動化する作業を助ける。

InSpecは無料のオープンソースツールで、開発チームはこれを使ってセキュリティとコンプライアンスのルールをコードで表現できる。前の1.0は、アプリケーションの正しいセットアップに主眼を置いた。今度のバージョンは、その能力を企業がアプリケーションを動かしているクラウドに拡張し、クラウドのセキュリティポリシーに合ったコンプライアンスのルールを書いてテストできるようにした。AWSとAzureをサポートし、Docker, IIS, NGINX, PostgreSQLなどなど30種のよく使われる構成が最初からある。

今日の継続的開発の環境では、複数のアプリケーションを複数のクラウドで動かすことが容易ではない。コンプライアンスを人間が継続的にモニタするためには、データベースを露出したままにしておく方が楽だ。

Chefはこの問題の解決を、コンプライアンスを自動化するツールで助ける。何をロックするかなどについて最初に開発とオペレーションが協議しなければならないが、合意に達したらInSpecを使って、クラウドの構成の正しさをチェックするためのルールを書ける。それには、InSpecのスクリプト言語を使う。

Chefのマーケティング部長Julian Dunnによると、スクリプト言語を使い慣れている人ならとっつきやすいだろう、と言う。“InSpecの言語はクラウドに特有のルールをカスタマイズして書くのに適している。クラウドのデプロイのチェックもね”、と彼は語る。

スクリプト言語の例。コードサンプル提供: Chef

“この言語は、読みやすくて書きやすいことを心がけて設計した。プログラミングの経験はないがスクリプトは書いているセキュリティの技術者が、想定ユーザーだ”、とDunnは言う。スクリプトを書いたら、それを自分のコードに対してテストする。そしてコンプライアンス違反が見つかったら、直す。

InSpecは、VulcanoSecを買収した結果として作れた。このドイツのコンプライアンスとセキュリティ企業をChefが買収したのは、2015年だ。InSpec 2.0はオープンソースで、Githubからダウンロードできる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

クラウドのセキュリティが弱いと暗号通貨の採掘に無断で使われる、最新の被害者がTesla

この新種で悪者の暗号通貨採掘者は、手当たりしだい誰でも攻撃しているようだ。最新流行のハッカー行為の今度の犠牲者は、なんとTeslaだ。クラウドコンピューティングのセキュリティが貧弱だったため、彼らはまんまと侵入した。

セキュリティ企業のRedLockはすでにこのタイプの攻撃をいくつか検出していたが、その最新の例がこれだ。いずれの場合も、Kubernetesのアドミンコンソールが完全無防備だった。パスワードすら、なかった。

RedLockに見つかるものなら、当然、ハッカーにも見つかる、…そして、見つけた。そのクラウドコンピューティングの、正規のユーザーによる正常な利用のようなふりをしてログインし、TeslaのAWSエンジンを無断で使って、黙々と採掘をした。ただし、そうやって彼らがマイニングをした時間と、被害額は公表されていない。暗号通貨は乱高下が激しいから、被害額の正しいドル換算は難しいだろう。

言うまでもなく対策は、とにかくインフラストラクチャのセキュリティに万全を尽くすことだ。使えるツールは何でも使おう。また、トラフィックが異様に増えたり、ふつうでない使い方がされていないか、たえずチェックしよう…利口なハッカーが、すでに侵入したかもしれないから。そして、いずれにしても、パスワードは必ず設けよう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Googleは2017年にPlay Storeから70万以上のアプリを削除した、2016年から70%の増加

Androidの比較的オープンな性質は、マルウェアの作成者やその他のあらゆる悪意ある者たちの標的になっている。彼らはしばしばそのソフトウェアを、公式なGoogle Play Store、サードパーティのアプリストア、その他考えられるあらゆる手段を通して送り込もうとする。しかし、ほとんどのユーザーにとっては、Google自身のPlayストアが、主要なAndroidアプリストアである。本日(米国時間1月30日)Gooogleは、70万件に及ぶ潜在的に有害な、または詐欺的なアプリを昨年ストアから削除したことを発表した。この数は2016年から70%増加している。

これが意味するのは、公式Play Storeから悪意あるアプリをインストールしてしまう確率が少なくなるということだ。悪意あるアプリとは、あなたの携帯電話にダメージを与えたり、情報を盗んだりもので、またあるときには悪質なコピーにもかかわらずSpotifyのようなふりをするようなものだ。実際、Googleの副社長でGoogle Playのセキュリティ担当者であるDave Kleidermacherは私に対して、悪意あるアプリをインストールする確率は、いまや0.00006%になったと語った(Googleは、世界中でインストールされるアプリは月間80億件あると見ている)。悪意あるアプリの大半(99%)は、Googleのアルゴリズムとセキュリティチームによって完全に排除され、そもそもストアに入ることはない。

Kleidermacherによれば、Play Store以外の場所から、有害なアプリをインストールしてしまう確率は、Play Storeに比べると10倍に及ぶということだ。

現在20億台以上のデバイスで動作しているGoogle Play Protectは、おそらく世界で最も広く使用されているマルウェアスキャナである。

削除されたアプリ数の増加は、悪意ある開発者たちによる有害なアプリが携帯電話に入ろうとする数が増加していることを意味する。しかしまた同時に、Googleによる機械学習やその他の技術導入の努力によって、これらのアプリがストアに登場する前に発見されてもいるのだ。Googleは新しいアプリケーションの中に、潜在的に悪意のあるコードを見つけるために、長年静的解析技術を使用していたが、ここ数年は機械学習を追加することによって、はるかに広い範囲のアプリを見つけることができるようになっている。Kleidermacherは、これらの機械学習技術の追加を「悪い性質を検出する能力に対する飛躍的な進歩」だと述べている。

Google PlayのプロダクトマネージャーであるAndrew Ahnも教えてくれたように、悪意ある開発者がそのアプリをストアに投入しようとする際には、明確なパターンがいくつかあるという。例えば、彼らはしばしば、自分のアプリを既存の人気のあるアプリのように見せかけてユーザーを騙し、インストールさせようとする。Googleは昨年、こうしたアプリを25万以上削除した。

また他の傾向として、Kleidermacherは、Googleが携帯電話上で暗号通貨マイナー(cryptominers:暗号通貨のマイニングを行うアプリ)を実行させようとする沢山のアプリを発見したということも語った。しかしこうしたことには、頻繁な流行り廃りがある。数年前は、アプリは他のアプリを巧妙にインストールさせようとしていたが、現在はそれほど問題にはならない。Googleが1つ手段を見つけてそれを使えなくすると、また別の手段がすぐに登場して来る。

とはいえGoogleは、悪意のあるアプリのすべてを1つ残らず、ストアに入る前に排除できないこともよく理解している。「私たちは素晴らしい技術を持っていますし、それは99.99994%に対しては上手く働きます」と彼は言う。「しかし決して完璧ではありません」。結局のところ、ある種の不正はGoogleによって検出することはほぼ不可能である、特に現在は、アプリの多くのコードがGoogleの手の届かない、バックエンドシステムで実行されている。あるアプリがサインアップを依頼し、その後その証明書をブラックマーケットに売り払ったとしたら、それを防ぐための手段は電話上には存在しない。これに対抗するため、Googleはユーザーたちがより安全なセキュリティ上の判断を行える方法を、教えようとしている。また同時にGoogleのSafe Browsingツールを用いて、アプリが既知の悪質なサイトに接続されていないかどうかを検出する。

結局のところ、こうした検知網にかからないアプリは常にあるだろう。ただ多くの場合に、こうしたアプリは多くのユーザーの手に届くことはないということが、まだ救いである。

[原文へ]
(翻訳:sako)

Amazon AWSがSqrrlを買収してセキュリティの脅威検出能力を強化

AWSが、NSAにルーツを持つセキュリティ企業、マサチューセッツ州ケンブリッジのSqrrlを買収した。同社は、機械学習を利用してさまざまなソースを分析し、セキュリティの脅威を企業ユーザーが迅速に追跡および理解できるようにする。

発表はSqrrlのホームページで同社のCEO Mark Terenzoniが行っている。“SqrrlがAmazonに買収されたことを共有できて嬉しい。私たちはAmazon Web Servicesの家族の一員になり、共に顧客の未来に貢献していきたい”、と彼は書いている。

では、この買収によって顧客は何を得るのか? 上記の声明を読むと、Sqrrlは少なくとも既存の顧客へのサービスを継続するようだ。

2016年のComputerworldのレビューによると、Sqrrlのソリューションはさまざまなソースからデータを集め、見つけた脅威をセキュリティ担当者のためのダッシュボードに表示する。担当者は、今後ありうる脆弱性の、視覚化された表現を見ることができる。

最近では大規模な侵害事故が増えているので、誰の心にも、その最上部にはセキュリティの懸念があるようになった。昨年はEquifaxの大規模ハックがあったし、年頭早々、チップの脆弱性SpectreとMeltdownが見つかった。セキュリティの脅威は、確かに増大している。最先端のクラウドプラットホームを誇るAmazonのAWSも、その点は同じだ。

Sqrrlは2012年に、NSAやホワイトハウスでセキュリティを担当していた政府職員たちが創業した。同社はこれまで、2600万ドルを調達している。至近の2017年6月には、Spring Lake Equity Partnersがリードするラウンドで1230万ドルを調達した。

その発表は、12月のAxiosの記事が確認している。その記事によると、買収価額の交渉は、4000万ドル周辺で行われている、ということだ。確定額は、本誌もまだ確認していない。

今Amazonにコメントを求めているので、何か得られ次第この記事をアップデートしたい。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

AlphabetがXムーンショット生まれのサイバーセキュリティ企業Chronicleをローンチ

あなたが、まだ間違って“Google”と呼んでるかもしれないAlphabetが今日(米国時間1/24)、新しいサイバーセキュリティ企業Chronicleのローンチを発表した。それは、企業のハッカー検出と撃退能力を高めることがねらいだ。ChronicleはAlphabetのXムーンショットグループから巣立ち、今ではGoogleなどと同じく、Alphabet傘下の単独企業だ。

Google VenturesからXに入り、その前はSymantecのCOOだったStephen Gillettが、この新会社のCEOになる。

最初にChronicleは、二つのサービスを提供する: 企業向けのセキュリティインテリジェンスとアナリティクスのプラットホームと、マルウェアやウィルスをスキャンするVirusTotalだ。後者はGoogleが、2012年に買収したセキュリティ企業だ。

Gillettが書いた記事によると、Chronicleの基本的な目的は、企業のセキュリティの盲点や死角を取り除き、企業が自分たちのセキュリティの全容を細部まで明確に把握できるようにすることだ。Gillettはこう書いている: “企業のセキュリティチームのスピードと実効性を今の10倍にしたい。そのためには、彼らにとってこれまで見つけることが困難だったセキュリティ関連のさまざまなシグナルを、容易に、はやく、そして低コストで捕捉分析できるようにしてあげることが、重要だ。Chronicleが提供するインテリジェンスとアナリティクスのプラットホームは、それを可能にする”。

XのCaptain of Moonshots(ムーンショットのキャプテン)、Astro Tellerによると、“企業のセキュリティチームが攻撃を見つけて調べるために必要な情報は、その企業の既存のセキュリティツールやITシステムの中にある。しかしそれらは膨大な量のデータの中に隠れているから、簡単には見えないし、理解も利用もできない”。

Chronicleのプラットホームは目下構築中で、まだその全貌は見えない。GillettによるとそれはAlphabetのインフラストラクチャの上で動き、機械学習と高度な検索能力により、企業によるセキュリティデータの分析を助ける。そしてChronicleのサービスはクラウドから提供されるので、“企業のニーズの伸縮に応ずる柔軟性とスケーラビリティがあり、企業自身が新たなセキュリティソフトウェアを実装したり管理する必要がない”。

このような、クラウドからのセキュリティサービスはChronicleが初めてではなく、ログを分析する専門企業もあり、またIBMなどもエンタープライズ・セキュリティには力を入れている。そんな競合環境における、Chronicleの差別化要因が何になるのか楽しみだ。

現時点で提供できる詳細情報があまりないことは、Alphabetも認めているが、今Chronicleのサービスは、いくつかのFortune 500社の協力により、アルファテストを行っている。

Chronicleは今日(米国時間1/24)の午後プレスコールを行うので、サービスの詳細が分かり次第、この記事をアップデートしたい。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa