DSaaS インストールから設定まで

# インストール
インストールスクリプトが自動生成できます
最初は `セキュリティポリシー` は無しで大丈夫です :smile:

<img width="1201" alt="スクリーンショット_2018-08-02_14_38_51.png" src="https://qiita-image-store.s3.amazonaws.com/0/164563/ac862df0-2311-8674-edff-5770937eea5d.png">
<img width="898" alt="スクリーンショット 2018-08-02 14.42.03.png" src="https://qiita-image-store.s3.amazonaws.com/0/164563/a5b07393-431e-4028-f39e-7337bc5ad386.png">
<img width="890" alt="スクリーンショット 2018-08-02 14.42.11.png" src="https://qiita-image-store.s3.amazonaws.com/0/164563/2689937d-895c-32bf-79ab-77e5f387c7fc.png">


```shell:
#!/bin/bash
# This script detects platform and architecture, then downloads and installs the matching Deep Security Agent package
 if [[ $(/usr/bin/id -u) -ne 0 ]]; then echo You are not running as the root user.  Please try again with root privileges.;
    logger -t You are not running as the root user.  Please try again with root privileges.;
    exit 1;
 fi;
 if type curl >/dev/null 2>&1; then

〜（略）〜

 fi
sleep 15
/opt/ds_agent/dsa_control -r
/opt/ds_agent/dsa_control -a dsm://agents.deepsecurity.trendmicro.com:443/ "tenantID:XXXXXXXXXXXXX" "token:XXXXXXXXXX"
```
実はインストールとアクティベートを同時に行なっている

## 常設インスタンスにインストールする場合
上記シェルを叩くだけ :hammer::hammer::hammer:

## AutoScalingインスタンスにインストールしたい場合
AMI作成前のベースインスタンスにて、先ほどのシェルを叩く:hammer::hammer::hammer:
インストールされた状態のAMIを作成した上で、
その後、AWS起動設定のユーザデータにアクティベート処理を入れる
 `policyid` は後で作るポリシーのIDを入れます :policeman: 

```ユーザデータ
#!/bin/bash
/opt/ds_agent/dsa_control -a dsm://agents.deepsecurity.trendmicro.com:443/ "tenantID:XXXXXXXXXX" "token:XXXXXXX" "policyid:XXXX"
```
`#!/bin/bash` を忘れると起動しないので注意

# ルールの適用
まずは利用する機能を決定する
<img width="187" alt="スクリーンショット 2018-08-02 15.33.37.png" src="https://qiita-image-store.s3.amazonaws.com/0/164563/b2c7b29f-9103-e3f0-28a5-7329e8d28667.png">

各サーバの用途に応じて利用する機能を考える必要がある。
私のサービスでは下記を利用
* 不正プログラム対策
* 侵入防御
* 変更監視
* セキュリティログ

## 推奨ルールの適用
* 侵入防御
* 変更監視
* セキュリティログ
においては、ルールを設定する必要があり、ここからが本当DSaaSとの勝負 :facepunch::facepunch::facepunch::facepunch::facepunch:

<img width="903" alt="スクリーンショット_2018-08-02_16_13_10.png" src="https://qiita-image-store.s3.amazonaws.com/0/164563/6b0face8-2e1b-933e-b7b4-549a55cdfee7.png">
ここで推奨ルールを検索する

## 過不足精査
<img width="990" alt="スクリーンショット_2018-08-02_15_56_21.png" src="https://qiita-image-store.s3.amazonaws.com/0/164563/f9f16dfd-2f1f-6cb5-4d91-e577a5a840d3.png">
<img width="1007" alt="スクリーンショット_2018-08-02_15_58_30.png" src="https://qiita-image-store.s3.amazonaws.com/0/164563/b1c82793-7025-7c64-433b-b79a0ed18637.png">

不足はそこまで発生しなかったが、必要あるか？みたいなルールは数多くあった。
ここで、too much の精査が出来てないと後でSlackでの精査が大変になるので、ちゃんと
`すべて` のルールをチェックすることを推奨する。

# ポリシーの設計と作成
自サービス内のサーバをカテゴライズ（Web用、Bat用など用途で）して、ポリシーを設計することを推奨する（自分のサービスは１ポリシーでやってるので死んだ :coffin:  ）

各ポリシーを作成して、推奨ルールを検索したサーバからルールをエクスポートして、ポリシーでインポートするのがお勧め

<img width="989" alt="スクリーンショット_2018-08-02_16_17_36.png" src="https://qiita-image-store.s3.amazonaws.com/0/164563/17bd19d3-85c5-88d1-bd0f-aefd8ac59066.png">
その後、サーバごとの差異ルールをポリシーの画面でON/OFFする 
<img width="977" alt="スクリーンショット_2018-08-02_16_15_25.png" src="https://qiita-image-store.s3.amazonaws.com/0/164563/1a9778ac-8936-0933-4079-c4f09adecd54.png">



# ポリシーの設定
ポリシーが作成できたら、インストールスクリプト生成画面でポリシーIDを指定して確認する。
<img width="875" alt="スクリーンショット_2018-08-02_16_56_06.png" src="https://qiita-image-store.s3.amazonaws.com/0/164563/51e9a8bf-9113-739f-b186-bd9aeafec563.png">


インストールスクリプト、AutoScalingインスタンスのユーザデータにpolicyidを設定する
"policyid:XXX"

設定すると、アクティベート時にポリシーが設定されるので、各サーバ毎に最適な運用が可能となる。

# Slack通知する
DSaaS→AWS SNS→Lambda→Slack（→Cloudwatch）を実装する

DSaaS→AWS SNSまでは下記通りでOK
https://dev.classmethod.jp/cloud/aws/deepsecurity-aws-sns/

LambdaはトリガーをAWS SNSにして実装するだけ

<img width="1189" alt="スクリーンショット 2018-08-02 16.26.07.png" src="https://qiita-image-store.s3.amazonaws.com/0/164563/aadb0b4d-b2b9-460d-22fa-5fbeb599d0de.png">


## 全部通知したら大変なことになったのでチューニング
変更監視系のメッセージはlogrotateも見逃さない :eye:
パーミッションが変わっただけで大騒ぎ 🎉🎉🎉🎉
<img width="672" alt="スクリーンショット_2018-07-27_14_51_23.png" src="https://qiita-image-store.s3.amazonaws.com/0/164563/8abd95c8-ff8a-89e7-54c5-85acd697af2d.png">


運用後はlambdaのソースにJsonをチェックしたフィルタリング処理を無理やり入れて、チューニングしましょう
`フィルタリングした通知は捨てるのではなく、Cloudwatchに記録すると吉`

# TIPS
### DSが返す JSONの形式が知りたい
https://help.deepsecurity.trendmicro.com/ja-jp/Events-Alerts/sns-json-config.html
HostAgentGUIDが返って来てるけどリファレンスにないとか不備も多い

### yumでM/Wに更新かけると変更監視のSlack通知テストができる時がある

### 謎のエラー 対策
https://qiita.com/kenji-toforone/items/3dea07edd4b7acd96d7e
https://qiita.com/kenji-toforone/items/1a3ca23fad811bc04e46

# 結局は
* サービスの全サーバにインストールされているM/Wの把握
* 各種ルールをM/Wや `ルールの特性` を理解した上での、適用/非適用を判断
* Slack、Lambda、Cloudwatch、AWS SNSと連携しないと運用監視という意味では、`無意味`