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

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

会場は、前回に引き続きHAPON新宿
ビアバッシュ形式でプシュッとしてからの開始です。
会場はほぼ満席。温まっていい感じです。

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の要件に対して、多く対応している
監査員との会話が楽になるかも

最後に

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

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