ロボットホテルの末路


ロボットが接客するホテルチェーン「変なホテル」を運営するH.I.S.ホテルホールディングス(HD)は10月17日、「変なホテル舞浜 東京ベイ」(千葉県浦安市)の全100室に設置していた卵型コミュニケーションロボット「Tapia」に脆弱(ぜいじゃく)性が見つかったと発表した。



「変なホテル」は生産性の向上(人件費の削減)を目的に、フロント業務や荷物運びなど、これまで人が担っていた業務のほとんどをロボットに任せていることが最大の特徴。

生産性の向上でロボットを使っている以上、当然ロボットは通信機能を備えている。

通信機能を備えているということは、外部から入り込む余地を与えるということに他ならない。

今回の脆弱性は、「Tapiaのプログラムを書き換えると、他の客の映像や音声を取得し、遠隔地から任意のタイミングで視聴できる」というもので、twitterからの投稿が発端の様だ。

しかし、せっかく脆弱性の指摘をしてくれたのに、対応を放置したH.I.S.ホテルホールディングスとメーカーのMJIの対応はいかがなものかと思う。

個人的には通信機能を備えたロボットを使う以上、常に不正アクセスとの戦いになることは覚悟しなければならないと思う。

生産性の向上は期待できるかもしれないが、人件費削減の代わりに恒常的なセキュリティ投資が求められるため、トータルで見た場合コストパフォーマンスは悪いのではないのだろうか。

コインチェックの貸仮想通貨サービス

アセットアロケーションの一環で少しだけ仮想通貨を保有しています。(保有比率は諸説あるけど、個人的には現在コモディティと同じ扱いで全体の10%未満にしている)

僕の仮想通貨との出会いのきっかけは、実は、アセットアロケーションの師匠でもある内藤忍さんだったりする。

2014年に、内藤忍さん共催の仮想通貨(リップル)セミナーがありました。

有償のセミナーだったんだけど、払ったお金分リップルがもらえる(確か1,500円くらい)という特典付だった。

その時貰ったリップルは気にも留めていなかったのだが、当時のウォレットであった、リップルトレードが2016年に終了となり、リップルのサルベージを行ったところ、80,000円(約40倍)の価値になっていた。

リップルトレードからのサルベージに相当苦労したこともあり、リップルを見限って全額をビットコインに変えました。

2017年後半から空前の仮想通貨(現 暗号資産)ブームが始まり、保有するビットコインの半分をイーサリアムに変え、ICO(Initial Coin Offering:イニシャル・コイン・オファリング)投資にチャレンジしたが、一つとしてヒットすることなく、投下したイーサリアムはほぼ壊滅してしまった。。。

で、難を逃れた残り半分のビットコインは現在も継続保有している。

あまりリスキーな投資をするつもりはないのだが、暗号資産は金と同じで保有するだけでは資産が増えない。

そこで登場するのが貸仮想通貨(レンディング)サービスである。

貸仮想通貨は、要は預貯金と同じで、預けて満期になると金利がついて返ってくるというもの。

コインチェックが、結構前からこの貸仮想通貨のサービスを行っている。

ネム流出事件が起きてからは、会社存続の危機もあり、怖くて預ける気にもならなかったが、マネックスグループ傘下となったことから、安心感が増し、5月に申し込みを行った。

人気で殺到しているのか、運用難で受付できない状態なのか、5ヶ月たっても運用が開始されない。


コールドウォレットに入れたところで、資産は増えないので、気長に待ちます。。。

気長に待つけど、不正アクセスによる流出だけはまじ勘弁。

COMODO社の情報流出事故

米国にCOMODOという会社がある。

TLSサーバー証明書を発行する認証局事業などを手掛けるセキュリティー企業です。

「コドモ」でも「ドコモ」でもなく、「コモド」です。

このセキュリティー企業が運営するフォーラム(掲示板サイト)が不正アクセスを受け、ユーザーの名前や電子メールアドレスなど、約24万5000人の個人情報が流出する事件が起きました。

【原因】
フォーラムで使用している掲示板構築ソフトvBulletinの脆弱性。

2019年9月23日に見つかった脆弱性で、ソフトベンダーから9月25日に修正プログラムが提供。

不正アクセスは9月29日に受けているので、修正プログラムの適用が遅れたために被害に遭った。

【想定被害額】
想定損害賠償額シミュレータの試算結果

・漏洩情報:約24万5000件

・漏洩情報:氏名、メールアドレス

・損害賠償額試算:2,940,000,000円(29億4,000万円)

【所感】

まともにシステム運用しているところであれば、通常検証環境に修正プログラムを適用し、テストを行って数日運用する。

んで、問題なければ本番環境に適用する流れになる。

そうしないと、システムそのものの安定運用が犠牲になってしまうリスクがある。

今回、修正プログラム公開から4日目で攻撃を受けているので、守る側としてはかなりキビシイ時間軸だと思った。

一般企業ならちょっと手に負えない気もする。

セキュリティ企業となると、それでも言い訳は厳しいのかもしれない。

以前マイクソ(マイクロソフトの略)のセキュリティパッチの不具合率を調べたことがあったのだが、セキュリティパッチの3割は不具合を抱えているという結果になった。

それを踏まえるとベンダーがリリースしたパッチを即座に適用するというのは安定稼働の観点からはリスクがある。

一方でパッチを早急に適用しないと、不具合を突いた攻撃を受けることになる。

あ、そこでWAF(Web Application Firewall)の登場となるわけか!

「パープルリス」と「炭鉱のカナリア」


セキュリティのお勉強で久しぶりに英語の雑誌と格闘した。

よく動物を使った格言のようなものがあります。

ちなみに先週知ったのは、

「炭鉱のカナリア」

これは、何らかの危険が迫っていることを知らせてくれる前兆をいいます。

石炭エネルギーが主力だった時代、多くの炭鉱がありましたが、炭鉱では有毒ガスのリスクと闘いながら働くこととなります。

有毒ガスが発生した場合、人間よりも先にカナリアが察知して鳴き声(さえずり)が止むことから、その昔、炭鉱労働者がカナリアを籠にいれて坑道に入ったことに由来するものです。

で、この「炭鉱のカナリア」は投資の世界でも生きていて、株価の急落や景気変調のリスクを示すシグナルの意味で使われます。

ちなみに、先週TOCOM SQUAREのラジオ公開生放送に参加してきたのだが、「炭鉱のカナリア」のサインとして、ハイイールド債から資金が流出しているという話を聞いた。

世界景気の減速は近づいているのだろうか!?




かなり話がそれたので、「パープルリス」の話に戻る。

”Stop Looking for the Purple Squirrel・・・・”というタイトルの記事を見ていたのだが、google先生に翻訳してもらうと、「紫リスを探すのをやめる・・・・」となった。

「パープルリス」って何やねんと思っていたら、驚いたことにWikipedia先生に解説があった・・・。

【Wikipedia先生解説】
パープルリスは、採用担当者が雇用要件に完全に適合する、適切な教育、経験、資格の範囲を正確に備えた求職者を説明するために使用する用語です。含意は、要件の過剰な仕様が紫色のリスと同じくらい見つけにくい完璧な候補になることです。
----

日本もそうですが、米国もセキュリティ業界は人材難な様で、「パープルリス」を探すのではなく、雇用慣行の改善を図ろうという内容でした。

例えば、

・女性や有色人種の登用促進

 それぞれセキュリティ業界の10%程度しかいないらしい

・求人情報の表現見直し
 
 「野心的」、「支配的」、「自信がある」などの男性に関連する言葉が多いらしい

・教育の重視

 資格を持っている人を前提にするのではなく、採用後トレーニングする前提で考える

米国もオープンなようで、あまりオープンではないのですね・・・。

スマホ証券「One Tap BUY」のメリットデメリット


One Tap BUYというスマホ証券がある。

個人的にはスマホでオンラインバンキングやオンラインショッピングというのが理解できない世代なのだが、今の若い人はスマホは使うけどパソコンは使わない人のほうが多いらしいので、そういうご時世ということで。

スマホ証券という時点で個人的には残念な感じしかないのだが、米国株投資に関しては、他の大手オンライン証券にはない独特な特徴がある様である。

メリットデメリット等をまとめてみたい。

【メリット】

■小額(千円)から取引出来る

米国株は日本株と違って1株から取引できるが、千円から取引できるというのは初心者に優しい気がする。

■積み立て購入が可能

これ、実はかなり大きいメリット。米国株を積み立て購入できるのはここだけなのではないだろうか。

ドルコスト平均法を活用してコツコツ購入していくことができる。



【デメリット】

■取り扱い銘柄が少ない

■手数料がちょっと高い(大手オンライン証券会社と比較して0.05%割高)

■指値注文とかができない

--

少額から米国株に投資できるのはとても魅力的。

親の管理が前提となるが、未成年でも口座が作れるため、子供の口座を作り、米国株をお年玉としてプレゼントすれば、投資教育にもなるかもしれない。

個人的には同じプレゼントでも、現金を消費するより、米国株でプレゼントしたほうが遥かに精神衛生上良い。

気になった点としては、少額で投資を始めるのはいいとして、出口戦略をどうするかかな。

投資にある程度慣れてスキルアップしてくると、少しでも良い条件で購入したくなってくる。

つまり、指値注文とかを駆使したくなってくるタイミングがいずれやってくることになるが、One Tap BUYは初心者向きゆえ、そのような高度な注文には対応していない。

そうなると、別の証券会社に移行することになるが、その場合の手数料とかってどうなんだろう?

PaaSとIaaS


恥ずかしながら、PaaSとIaaSの違いを混同していたことが判明したため、再整理。


PaaSとは?

Platform as a Serviceの略。

アプリケーションソフトが稼働するためのデータベースやプログラム実行環境などが提供されるサービス。

プログラムだけを用意すればよいというメリットがある一方、データベースの設定やプログラムの実行環境に制限があるので、開発の自由度は下がる。

インフラから開発する手間を省きたいけれど、ある程度カスタマイズしたいというときに利用するのが良い。

例:Google Apps Engine、Microsoft Azure


IaaSとは?

Infrastructure as a Serviceの略。

情報システムの稼働に必要な仮想サーバやハードディスク、ファイアウォールなどのインフラを、インターネット上のサービスとして提供する形態。

SaaSやPaaSなどと違って自由度が高く、ハードウェアのスペックやOSを好きなように選べる。

その分、OSやハードウェア、ネットワークの知識が必要となり、セキュリティ対策も当然必要。

例:Google Compute Engine、Amazon Elastic Compute Cloud(AWS)

ドキュメントルートに受領ファイルを置かない


保険業界は重要インフラ分野の一つとなり、当然セキュリティ対策にしっかり投資を行っている。

一方で保険業界には大小様々な代理店が存在しており、保険証券を扱う代理店は「セキュリティってな~に~」みたいなところが多く、保険証券のデータの保存先がコンシューマー用のNASであったり、保険の相談申込ページ(Webサーバ)に保険証券をアップロードさせてWebサーバ上に保険証券を保存するというびっくり運用が存在する。

そもそもの話として、今回はWebサーバで実施しておく基本的なセキュリティ対策(apacheベース)を整理しておきたい。

まず、認識しておかないといけないのは、Webサーバをデフォルトの状態で運用することは、「危険」な状態であるということです。

ウェブサーバは通常、インターネット上に配置され不特定多数からのアクセスが発生するため、デフォルトの状態で運用するということは、外出時に自宅に鍵をかけないどころか、ドアを全開放して「外出中です」と張り紙を出して外出するようなものです。

1.ディレクトリ内容一覧表示の無効化

apacheには公開しているディレクトリ内容を一覧表示するディレクトリリスティング機能が実装されています。

本機能が有効になっているディレクトリを表示すると、以下のようなインデックス画面が表示されます。

デフォルトでは、ドキュメントルートでこの機能が有効になっています。

この場合、Webサーバの公開ディレクトリに直接アクセスを行うと、ディレクトリ内に存在するファイルの一覧が表示され、ディレクトリ内のファイルの一覧を取得することが可能です。

つまり、冒頭で話した様な、保険証券を問い合わせフォームに添付してアップロードさせるようなケースの場合、保険証券のデータをこのドキュメントルートに保存すると、保険証券のデータは漏洩します。

ディレクトリでファイルの一覧が表示されることにより、外部に流出する情報として、他に以下のような内容が考えられます。

【ファイル一覧機能により、外部に流出する可能性がある情報】

□公開を意図しないファイル

□バックアップファイル

□一時ファイル

□隠しファイル(ドットで始まるファイル名のファイル)

□ファイルの命名規則

□設定ファイルによるサーバ設定情報

□スクリプトファイルによるサーバ内部処理情報



2.HTTP TRACEメソッドの無効化

まず、そもそもTRACEメソッドとは?から。

HTTP 1.1(RFC2616)で定義されている、8種類のメソッドの一つ。

GET、POST、HEADなどはおなじみのものですが、それ以外にPUT、DELETE、OPTIONS、TRACE、CONNECTの5種があります。

このうち、TRACEメソッドは、HTTPリクエストを「オウム返しに」HTTPレスポンスとして返すもので、以下のようにGET等の代わりにTRACEとしてWebサーバーにリクエストします。
TRACE /auth/index.php HTTP/1.1
Host: example.jp
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:18.0) Gecko/20100101 Firefox/18.0
Cookie: PHPSESSID=4lel0hml53u2tbhcd9pmo7pkc4
Authorization: Basic eWFtYWRhOnBhc3N3b3Jk
Connection: keep-alive
レスポンスの例を以下に示します。
HTTP/1.1 200 OK
Date: Tue, 22 Jan 2013 13:51:09 GMT
Server: Apache/2.2.14 (Ubuntu)
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: message/http
Content-Length: 198

TRACE /auth/index.php HTTP/1.1
Host: example.jp
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:18.0) Gecko/20100101 Firefox/18.0
Cookie: PHPSESSID=4lel0hml53u2tbhcd9pmo7pkc4
Authorization: Basic eWFtYWRhOnBhc3N3b3Jk
Connection: keep-alive
で、このTRACEメソッドが有効になっていると、Cross-Site Tracing(XST)攻撃と呼ばれる、XSS(Cross-Site Scripting)とTRACEメソッドを組み合わせた攻撃のリスクが発生する。(詳細はコチラ

そのため、TRACEメソッドを無効にすることでセキュリティを確保します。



3.X-Frame-Optionsヘッダの設定

クリックジャッキング攻撃の対策となるX-Frame-Optionsヘッダを設定します。

クリックジャッキングとは、ユーザが意図しない操作(ボタンやリンクのクリック)を実行させられる攻撃です。
(クリックジャッキングの詳細はコチラ

情報の公開・非公開設定がユーザの意図に反して気づかないうちに変更された結果、情報漏えい事故につながる等の被害が想定されるため、X-Frame-Optionsヘッダを設定します。



4.apache バージョンの非表示化

apacheのバージョン情報を取得することができる設定がデフォルトでは有効になっています。

バージョン情報の表示は直接の脆弱性とは関係ありませんが、利用しているapacheに脆弱性が存在する場合に脆弱性を突いた攻撃等を実施する手がかりとして利用される恐れがあります。

サービスへのアクセス時に表示されるこれらの情報はバナー情報と呼ばれ、バナー情報の隠蔽は攻撃者に攻撃の手がかりを与えないために有用な対策となるため、バナー情報はできる限り非表示とすることでセキュリティを向上できます。



5.SSL/TLSにおける安全性の低い暗号スイートの無効化

サーバ側のSSL/TLS設定において安全性の低い暗号スイート(プロトコル・暗号アルゴリズム、鍵長、ハッシュ関数)をサポートしている場合、安全性の低い暗号スイートが利用されることで、通信内容の盗聴につながる可能性が高まります。

安全性の低いプロトコル・暗号化アルゴリズム、鍵長、ハッシュ関数を無効化し、安全性の高いプロトコル・暗号化アルゴリズム、鍵長、ハッシュ関数のみをサポートすることでセキュリティを確保できます。

一般的に安全性の低い暗号スイートと呼ばれるものは、下記があります。

・MD5

・RC4

・3DES

・SSLv2

・SSLv3



6.SSL/TLSプロトコルのデータ圧縮機能の無効化

SSL/TLSプロトコルのデータ暗号化時の圧縮機能が有効になっている場合、SSL/TLSによって暗号化された通信内容の一部が漏えいする可能性があります。

暗号化前のデータ長(サイズ)の情報からデータ内容の総当たりによる推測が行われた場合、Cookie等のHTTPヘッダの一部が取得される脆弱性が存在するため、SSL/TLSにおけるデータ圧縮処理(Compression)機能は無効化します。

出典:攻撃を受ける前に見直すApacheの基本的なセキュリティ10のポイント