Deep Security User Night #4 レポート

こんにちは、ひろかずです。
４回目となるDeep Security User Nightに行ってきましたので、一筆書きます。

- 例によってのリアルタイム執筆なので、抜け漏れ表記ゆれはご容赦ください。

会場は、前回に引き続き[HAPON新宿](http://hapon.asia/shinjuku/)
ビアバッシュ形式でプシュッとしてからの開始です。
会場はほぼ満席。温まっていい感じです。

#Session1 NTTドコモのクラウド利用とDSM共通基盤
守屋さん (株式会社NTTドコモ)

##社内でDSM共通基盤を作って、運用している。
ドコモのクラウド利用

- AWS300アカウント
- AWSは、商用、評価検証使ってる
- 分野もWebから、分析/機械学習、モバイルアプリ・ゲーム等多岐にわたる
- Azureは、検証用途で主に使ってる

クラウドを利用する理由

- 早く試せる
- ダメならすぐ止められる
- 時間を買える

運用でボトルネックは作らない

- アカウントや、サブスクリプションはプロジェクト毎に独立

セキュリティの壁

- ドコモ社内では280項目のセキュリティチェックをクリアする必要がある。

守屋さんの部署はクラウド利用を統括する中で、ガイドラインやデザインパターンなどのノウハウ収集、ツール類を作っている
最終的にドコモクラウドパッケージに落とし込んでいる

##DSの導入背景
- WAF、IDS/IPS、改ざん検知、ウィルス対策の要件がある
- 1製品で対応できる
- ホスト型なので、ネットワーク型のようにセキュリティ機器の障害によるサービス影響がない
- AS対応もできるのはいい
- リファレンスも充実
- クラウドのベストプラクティスにフィットしている

##DSMの選択肢
- DSaaSとDSMのパターンがある

DSaaS

- サーバ側の構築運用保守が不要
- 最新DSMが使える
- 圧倒的に楽

DSM

- オンプレ、クラウドにマネージャを構築
- コントロールできるが、ちょっと面倒

DSaaSを使いたいが、ドコモ的に壁がある

- そもそもSaaS型は厳しい
- コントロールが効かない（ログ保存期間13週だったが、2017年5月から4週に短縮）
- 社内の事情により断念

##プロジェクトによりサブスクリプションを独立する要件がある
答えとしては、自前のDSMをマルチテナントとして構築して、DSMとDSaaSのいいとこ取りをする。

- インターネット経由については、暗号化が適切であれば、OK。
- NAT経由でもOKなので問題はなかった。
- プロジェクト数は20,管理台数は数百台規模

導入効果

- プロジェクトによっては、数十万/つきの運用費削減
- スタートアッププロジェクトで予算がなくても対応できるようになった。
- DSの運用ノウハウが集約

気をつけていること

- マルチテナントのDSMを社内SaaSとして運用
- DSM共通基盤をボトルネックにならないようにする

メリット

- 各プロジェクトからセキュリティ運用ノウハウを収集
- APIによる運用



#Session2 家電のクラウドとセキュリティのお話
音川さん (シャープ株式会社)

ロボホンのリリースでトレンドマイクロ南原さんにお世話になったとのこと。

今日の話は家電のためのクラウドの話をします。
セキュリティは大事なので、ちょっとだけDSの話

##家電がクラウドに繋がるって、IoT
AIoT（造語）

- 家電をクラウドに接続して人工知能化
- もっとヒトと寄り添う存在に
- ロボホン、COCORO+（家電を暮らしのパートナーに変えていくプロジェクト）

実はシャープさんは、10年前からIoT？をやっている

- Aquosオーナーズラウンジ

シャープでは家電のサーバは全部クラウド！（AWS）に持っていってる。

- が、ITは違う
- ITの人たちは、オンプレの視点でクラウドを見るので日々戦い

家電クラウドの目的

- 家電をクラウドで進化
- 家電にコンテンツ供給（レシピの配信etc）
- 家電とサービスの融合（ヘルシオに広告配信：料理ができそうになったら広告表示：引き合い多数）

家電製品は単体でやれることはなくなった（省エネ競争）

家電クラウドの特性

- オープンな環境上のクローズな環境（セキュリティ的にフルオープンはない）
- クライアントのアップデートは期待できない
- 長期稼働の要求（10年後どうなるか）

家電のクラウドシステム

- 家電アダプタ経由でHTTP+ECHONET Lite(HEMS対応)で通信 → データベースに格納
- Web Socketを使ってプッシュ通知

家電のクラウドのセキュリティはとても大事。

- Miraiのようなものが悪さをしないようにしないといけない。
- エアコンの操作は命に関わるかも
- 入念な脆弱性テストを実施
- 加えてDeepSecurity

##シャープのDeepSecurityの利用
クラウドセキュリティの社内の標準ツール

- 検出モード(サービス通信を誤検知しないようにチューニング)
- 防御モード(チューニングを経て攻撃通信を遮断する)

セキュリティ事故の損失

- 経済的損失
- ブランドに対する損失
- 労働力の損失

Webサイトの改ざんは、依然深刻。

- 対応日数は、11日以上かかることが３割

事故を防ぐことが重要
だが、事故が起きた時の対応はもっと重要

Auto Healingシステム

- 攻撃の未意味化
- DeepSecurityで検知した変更をトリガーに、gitから短時間で復帰させる。
- メンテナンス作業の効率化という副次的効果も（ロックファイル運用で、運用負荷を軽減）

#LT枠1 CloudFormation Template for Amazon ECS with Deep Security Agent（俺達のCloud Formation）
姜さん (トレンドマイクロ株式会社) 
サブタイトル：女神は微笑むのか

##今日やること
CloudFormationをつかってスタック２つ

- VPCの上にECSを起動して、ASグループに参加させる
- ECSクラスタサービスを起動して、ALBに参加させる

実機確認では、女神画像が表示されるとのこと（ハズレは別画像）
DS10の機能をちょっとだけ使う

デモ（会場でお楽しみ下さい！）

DS10の部分

- Container内にダウンロードされたファイルのウィルス検知ができるよ！使ってね！
- 今日の内容は、Webで公開予定！「trendmicro aws microsite」で検索！


#LT枠2 One problem and one solution when using DSaaS on the cloud.
工藤さん (アイレット株式会社)

英語書くとslideshareのViewが上げる

##テーマ:出口対策
Outboundは制限するのだけど、DSaaSを使うのに80/443フルオープンが必要
クラウド環境ではIP/portベースでの制限になる。
攻撃の際には、80/443を使う。

- 攻撃通信を制限できないやん！

実際問題としての対応

- プロキシ(Squid)を実装して、trendmicro.comを通す。
- DSaaS側では、FireレピュテーションとWebレピュテーション、DSaaS管理側でプロキシの使用を設定する。
- パブリッククラウドでOutBoundを絞るのは意外と少ないんじゃないかな。

まとめ

- クラウドではOutboundのURLフィルタリングができないので、プロキシでの実装が必要
- 個人情報を持っていたりして気にする人は、Outboundを絞るのがいいんじゃないかな。

#LT枠3 ハンズラボでのDS事情についてゆるっと
加藤さん (ハンズラボ株式会社)

加藤さんはAWSチーム（東急ハンズの９割がAWSを利用）
2015/2016でAWSsamuraiを輩出

##オンプレとクラウドとのセキュリティの違い

- オンプレはネットワークを簡単に引けないので、自然と外部からの経路が増えない
- クラウドでは、ネットワークを簡単に弄れるので、監視しない経路での通信が発生しうる

クラウドの利点ととのトレードオフ

- 利点はスピード
- 個エンジニアの周知徹底

ホスト側で何があってもいい方針(インフラ側)

- publicにはなるべく置かない。Privateに隠蔽する。
- やむなくpublicに置く場合は、NAT GatewayにIGWを向ける。（ひょっとしたらアンチパターンかもしれないけど...）

使いにくいところ

- DBでMySQLやPostgresqlでも使えるようにしたい(無料のDBがいい)
- クラウドアカウント連携は便利だが、Private通信をしたいのに、Public通信になってしまった（いい方法があったら教えて！）

使えるところ

- AWSとの親和性が高い
- PCIDSS要件に多く対応している
- SAQの要件に対して、多く対応している
- 監査員との会話が楽になるかも

#最後に
ユーザー企業の生の声が聞こえて楽しかったです。
次回をお楽しみに！

今日はここまでです。
お疲れ様でした。