(翻訳)セキュリティで飯食いたい人向けの行動指針

• (7/21) コメント欄の指摘を受け英訳追記

前文

本記事はGoogleのセキュリティ担当者 Parisa Tabriz氏(異名: Security Princess)のSo, you want to work in security?を翻訳したものです。

go for it!

— Parisa Tabriz (@laparisa) 2016年12月25日

うっ…半年以上前…

意訳したりわからない部分もあったので、原稿の全てを反映できているか自信はありません。元ブログも是非ご一読ください。

—————————————- ここから翻訳 ————————————————-

セキュリティ分野(コンピュータ、情報、サイバー…etc)でキャリアを積みたい人からメールをもらうことがある。素晴らしいことだと思う。テクノロジーを安全にしていくパション、創造性を持ち、ハードワークをこなせる仲間はいつだって必要だ。金銭的な意味で、安定した生活を送れるようにもなるだろう。

他にも同じトピック（キャリア）で似たようなポストがあるが、私の経験から導き出した上流の考えを共有していこうと思う。

警告: 映画のような華々しさはない

実際の現場はハリウッド映画とは違う。私はハッカー映画やドラマは好きだが、私の仕事の経験上、映画のようなスリルでセクシーな場面には遭遇しない。 しかし、(恐らく他の職種もそうだろうが)セキュリティはとても刺激的で、チャレンジングな、そしてやりがいのある仕事だと思う。

完全もしくは標準的なカリキュラムなどない

セキュリティは広範で、インターディシプナリー(学問的横断)で、応用的な分野だ。セキュアなシステムをデザイン・構築する、それを攻撃する、検知する、など役割は多岐にわたる。そのなかに唯一無二で標準的なカリキュラムなどない。この分野がより成熟するにつれ、カリキュラムも充足してくるかもしれないが、私はそうなるとは思えない。

もし、あなたがコンピューターサイエンス、コンピュータ、ソフトウェアの仕組みを理解するのであれば、それらは大いに役に立つであろう。コンピューターサイエンスは抽象的なレイヤーの問題を解決する学問であり、セキュリティはその抽象レイヤーにおけるミスを見つけ直す（もしくは攻撃する）学問だ。

私はイリノイ大学のコンピューターサイエンス部で学んだ。中でもOS、ネットワーク、コンピューター・アーキテクチャ、コンパイラーなどのコースが役に立った。それに加え、私が興味をもった技術コース（信号処理、バイオメディカル工学、人工知能）や、インターン、学生クラブのプロジェクトで携わったネットワーク、プライバシー向上技術、Web/クライアントアプリ作成などで経験と積んだ。

ユーザーや顧客がどのようにテクノロジーを使うか理解するのも有効だ。もし私が大学に戻るのであれば、心理学、社会学、ヒューマン・ファクターのコースをとるかもしれない。

私は似たようなバックグラウンドを持つ専門家とも、そうでない専門家とも仕事をしたことがある。専門家には学位を取る前に中退した人もいる。

私は特にセキュリティの資格をもっていない。それによって不利益を被ったこともない。なにかしらの産業や国ではプロフェッショナルとして必要かもしれない。they’re certainly a thing that some reasonable people have pursued — caveat emptor(?) -> 持っていた方が雇い主が安心できるケースはあるかもしれない。

ハッカーの文化を理解するために、Hacker ManifestoやHow to Become a hackerを読むといいだろう。セキュリティ専門家の行動指針・行動規範になるだろう。もし、ハッカーでなくても、ハッカーのマインドセットを理解するのに役立つはずだ。

他にも色々なインプットをする場がある。私がインプットする先はこのTwitter security listにいるひとたちからであることも多い

手を動かせ。実践しろ。

どの業種でもいえることだが、業務経験はなるべくはやく始めることだ。始めることで興味、強み、将来のキャリアプランを計画できる。日常業務や環境がどういった要素から構成されており、そのうち何が好きで何が嫌いか学べる。私の人生で最も価値があった経験の一つは、おおよそ全く好きになれなかったインターンシップだ。私の将来の方向性は大きく変化した。

どのように業務経験を始めるかは人による。学生クラブやキャリアフェアに出席し、熱意を向けられるインターンシップやバイトに応募しよう。私の場合、ライフガードコミュニティでやっていた清掃バイトの伝手で、大学寮のシステム管理業務をやることになった。ここで積んだ経験を活かし、大手製薬会社でITインターンをすることになった。また、授業ではなく大学のクラブ内で実際のソフトウェア作成の経験をつみ、サイバーセキュリティインターンシップをみつけた。こうやって私は、Googleの中のひとに「どれいっちょ面接するか」と思ってもらえるぐらいの経験を積んだ。

コードを書け

私の知っている優秀なセキュリティエンジニアは、コードをよく書く。ソフトウェアを書くことで、セキュリティ的なバグを埋め込むこともある。この過程から開発者に対してリアルな共感をもつことができるのだ。結局のところセキュアでないコードを指摘するより、継続してセキュアなコードを作っていく方が難しいことを認知できる。

もし、どこから始めれば良いのか分からければ、オープンソースのバグを潰すところから始めるといいだろう。バグ潰しは感謝される。プロジェクトのメンバーに感謝されるだけでなく、将来的な仕事につながることもある。

コードを壊せ

ソフトのバグを探すことに時間を費やせ。デバッガ・ネットワークスキャナー・ウェブプロキシ・ソフトウェアfuzzerの使い方を学ぼう。ハッカープレイグラウンドで遊ぼう。私は大学の時、http://seclists.org/bugtraq Hack This Site!をつかっていた。他のハッカー養成場は https://infosec.rocks.にリストされている。CTFなどのハッキングチャレンジりすとはここだ。バグバウンティをやっている会社にばぐを報告するのもよいだろう。

バグを探すだけでなく、bugtrag/fulldisclosure/oss-secから他者がみつけたことを追い、学ぶことも推奨する。

知識を共有しろ

私は大学時代に、ACMグループのSigMil(?)にいた友人からセキュリティを教わった。そこでは興味のある分野についてプレゼンをするメンバーがいた。我々はまた、DEFCONへ巡礼したり、セキュリティ本を買ったり、外国の同じ志をもつ同士と成果物についてチャットしあったりした。Googleでは、専門性・苦心していること・半熟なアイディアを同僚と共有することで、たくさんのことを学べた。

知識の共有はいくつかの理由で重要だ。 1. 知識の共有は、セキュリティのベストプラクティスやハマリポイントを横断的に展開していくのに有効だ。 2. プレゼンやドキュメントの作成の過程でたくさんのことを学べるので、隠れたトピックまで見渡せられる 3. 質問・コメント・ディスカッションを通して、聴講者からも学びがある。 4. Pay it forward(?) -> その恩は周囲の人にも広がる

本当にたくさんのことを学んだ。

コミュニケーションを怠るな

セキュリティをするということは、同じバックグラウンドを共有しない人に対して、複雑な技術的問題を日常的に説明することになる。そして、聴講者はそれぞれ異なる単語・専門性・動機をもつことになるだろう。あなたは脆弱性の重要さについて国際的な基準にたよることは滅多にできないし、セキュリティのプラクティスを実践するときに、輝かしいデモはできない。あなたは、聴講者にフラストレーションを感じさせてはならない。

これをするにはコミュニケーションが必要であり、時には説明と交渉をしなければならない。技術的リソースだけでは身につかないため、練習し、パブリッシュし、継続的に向上させていかなければならない。

辛いことも失敗もある

当たり前のことだが、明確にしておきたい。 セキュリティは大変な仕事だ。我々が古いものを撤廃するより圧倒的早く、我々が守るべき技術分野は変わる。従って、新しいことを学び続けねばならない。攻撃者は我々より時間とリソースを持っており、既存の防御手法にも追いつきやすい。

セキュリティはストレスの多い仕事だ。不明瞭な問題や不完全なソリューション、あまりないデータ、何より人の安全を脅かす現実の脅威と向き合わなければならない。

セキュリティは成功を可視化しにくい仕事だ。私の経験上、失敗の方が人の目につきやすい。だが、我々は究極的にリスク緩和までしか対応できず、銀の弾丸は存在しない。

楽観者でいよう

先述の通り、 (‘A`)ｳﾂになることもあるであろう。テクノロジーの進歩についていけないと思うかもしれない。2016年の今日でもバッファオーバーフロー脆弱性を利用して、インパクトのでかい攻撃をされている。セキュリティは不可能であり、悪くなっており、なぜ我々が失敗してるか指摘する人を良く見ることになるだろう。

現実は辛いかもしれない。だが、テクノロジーが我々にもたらしたことを考えてみよう。その成果はすばらしいの一言だ。もちろん完璧ではないし、将来的にも完璧にはならない。だが、セキュリティは10年前より確実によくなってるし、それなりのレベルで保証されるようになってきている。だから私は楽観者でいられる。

助けを求めよう

嫌な奴はいる。嫌な奴にくじかれるな。男性優位主義でエゴイスティックな側面を長いことみてきた。会話がマウント取りに発展することは珍しくない。

私の今までの成功は、他のセキュリティ専門家の人の支援・アドバイス・教育からなっている。助けを求めても、それは仕事から外されるということではない。

なので、助けが必要であれば聞こう。デューディリジェンスをちゃんとし、助けを提供しやすいようにしよう。スコープを適切に切って、コンテキストを共有し、タイポを減らせば、良いレスポンスが返ってくるはずだ。

Good luck and happy hacking!

チェキしたいセキュリティ系スタートアップ - 2017年編

• 1月から書こうと思ってた内容をいまさら書くという。
• 多分偏ってる。
• 所感: 大体のサービスにおいてポリシーをもとに設定するという文が目立った。恐らく会社のポリシーがあることが前提になるので、それをしないで導入しても所謂運用でカバーするみたいな残念な結果になると思われる。まずは頑張ってポリシーを作ろう。
  • ポリシーをコンフィグにして、それが設定に反映されるソリューションかはちゃんとチェックしてない

Argus Cyber security

• 車セキュリティ
• 車どころか免許も持ってないザコなのでスルー

Bitglass

• CASB
• エージェントレスらしい
  • Netskopeはどうだったっけ
• セキュアアクセスが可能
  • これがどういう意味での「セキュア」かは調査してない

Bromium

• EDR(といっていいのか？）
• エンプラデスクトップ向け仮想化ソリューション。
• ファイルを開くと仮想環境上で開く。
• 勝手にマルウェアを隔離し、ダッシュボードを作る。これによってマルウェアに関連するキルチェーンが可視化される

Cyence

• サイバーリスクモデリングツール
• Financial impactの算出を実行
• 保険会社向け

Darktrace

• エンプラネットワーク内でのActivityを異常検知& 自己学習

Demisto

• SOC向けChatOps
• 詳しくはこっち見てみそ

Druva

• クラウドデータプロテクション
• 各種クラウドストレージのバックアップとしても昨日するっぽい
  • リモートオフィスからも、アプリからも
• データガバナンスにも、コンプライアンス分析もできる
• Accessトークンの監視など、今時の開発・運用環境に利用できそう
• bitglass, demistoと合わせて俺の中で熱い

Eviden

• クラウドプロバイダーのコンプライアンスモニタリング
• AWSアカウント・サービス・リージョンの監視とリスク分析をする
• 上記の検知はコンプライアンスに基づく
• どこまでしてくれるかわからんけど、AWS上のAPI叩けば良いんじゃない…?

Fugue

• クラウドプラットフォーム(ex: AWS)上で
  • スタンダード・ポリシーに従った設定を反映
  • 変更管理のトラッキング
• Terraformとどう違うのかな?

Illusive Networks Ltd.

• Deception Technology
• データのハニーポットみたいな(命名 by Kengo)
• Creates an alternative reality transparently woven into your existing network

Insights

• 機械学習を活用した攻撃検知・分析・封じ込めプラットフォーム
  • インシデントレスポンスプラットフォーム
• Demisto, Phantomとかぶる？

Kenna

• 脆弱性トリアージ、リスク分析、レポート
  • リスク分析って聞こえはいいけど、スコアリングシステムの中身知らないと意味ない気がする今日このごろ

LogicMonitor

• SaaSベースのパフォーマンス監視サービス
  • PrometeusとかGoogle StackDriverではできないことがあるのだろうか？

NetSkope

• CASB
• ロードバランサーすだちくんが暑く語ってたので、こちらを聴くと良いかも 『Track 18 シンジ(cloudpack)さんと最近の情報システム部門の話』のメモ – cloudinfra-audio

NEXThink

• 端末ベースのネットワーク・サービスの可視化、
• 分析・インテリジェンスプラットフォーム
• SIEM/SOC統合もあるよ！

Onion ID

• 特権管理SaaS。
• 各種Web管理画面のJust-In-Time Privilegesもできるっぽい。
• 振る舞い検知もするらしい。
• 個人的にホットな分野だが、当該企業の情報が少ない

PerimeterX

• 振る舞い検知型のWeb系攻撃の防御
  • Botによるサービス・アプリへの自動化された攻撃を防御するっぽい

Phantom

• インシデントレスポンスのセキュリティオートメーション・オーケストレーション
• Demistoと似てる?

Prevalent

• 3rdパーティ・ベンダーの自動リスク分析・脅威監視

RiskIQ

• ユーザーをフィッシングサイトなど、自社サービスを装ったものを監視する

Silent Circle

• eメール、スマホ、テレカンを通したセキュアな通信
• PGPのPhil Zimmermanがいる
• よくわからん。

StackPath

• セキュアCDN/WAFのプラットフォーム
• Fastly/Akamai Konaとどう違うのか？

Skybox Security

• 分析・インテリジェンスプラットフォーム
  • 脆弱性管理
  • 脅威管理
  • リスク管理
  • 変更管理
  • Firewall管理

360 Mobile Security

• モバイル向けセキュリティソフトのパッケージ
  • アンチウイルス、メモリ最適化、デバイスクリーンツール
• あんまり興味ないかな…

Refs

• https://www.darkreading.com/careers-and-people/20-cybersecurity-startups-to-watch-in-2017/d/d-id/1328251?image_number=2
• http://www.wsj.com/graphics/25-technology-companies-to-watch/
• http://www.wsj.com/graphics/25-technology-companies-to-watch/

GCP + k8sで共有registryからコンテナImageを読み込む #gcp #メモ

プロジェクト毎にregistry作るの意味なくね？と思ったので、ほぼ全てのコンテナImageをアップロードしたregistry付きプロジェクト(以降project-reg)を作った。 ここに対してImageをpullするには、docker login -e相当のことをpodでしなければならない。

Service Account on GCPを作成

project-regにroles/storage.objectViewerロールの付与されたService Accountを作成。 Terraformだと↓。

resource "google_service_account" "container_registry_reader" {
  account_id   = "docker-image-reader"
  display_name = "Docker Image Reader(Puller)"
}

resource "google_project_iam_policy" "project_owner" {
    project = "${var.project_id}"
    policy_data = "${data.google_iam_policy.image_puller.policy_data}"
}

data "google_iam_policy" "image_puller" {
    binding {
        role = "roles/storage.objectViewer"
        members = [
            "serviceAccount:${google_service_account.container_registry_reader.email}",
        ]
    }
}

該当Service Accountのkeyを作成

Terraformのやりかたはわからなかった。

gcloud iam service-accounts keys create docker-image-reader-secret.json --iam-account=docker-image-reader@project.iam.gserviceaccount.com

Kubernetesにシークレットを作成

% kubectl create secret docker-registry gcr-pull-key --docker-email=docker-image-reader@project.iam.gserviceaccount.com --docker-password="$(cat docker-image-reader-secret.json)" --docker-server=https://gcr.io --docker-username=_json_key

PODのサービスアカウントを更新

% kubectl get sa default -o yaml > ./service_accounts.yaml
% vim service_accounts.yaml
# [delete line with key "resourceVersion"]
# [add lines with "imagePullSecret:"]
% kubectl replace sa default -f ./service_accounts.yaml

PODのコンテナ更新

% vim deployment.yaml
% kubectl replace --filename ./deployment.yaml

GCP上のプロジェクトをTerraformで作成する #GCP #Terraform

追記

• 2017/05/12: 下記の備忘録は正確ではない可能性がある。下記の設定を実際に反映させてないのに、プロジェクトが作成できたから。

本編

GCPの備忘録を作っていこうと思う。 今までプロジェクトを2個つくり、最初は GUIでポチポチと、２個目は極力gcloud と kubectlだけで作成をした。今回は可能な限りTerraformをつかい、記録を残したいと思う。 というわけで、プロジェクトの作成から。

いきなりTerraformから逸脱してしまうが、ProjectをTerraformから作るにあたり"roles/resourcemanager.projectCreator"が付与されたIAM Policyが必要だ。これを個人メアドに割り当てることもできるが、冗長性や拡張性を意識しグループメアドに割り当てるのが得策だとかんがえる（システム用アカウントは極力作りたくない）。

ので、まずGsuiteでグループメアド(infra-admin@hogehoge.com)を作り、そこにインフラに携わる人間のアカウントを追加する。そして、iam_policyを作る

gcloud alpha organizations add-iam-policy-binding ${ORG_ID} \
            --member='group:infra-admin@hogehoge.com' --role='oles/resourcemanager.projectCreator'

これをTerraformで記述する

data "google_iam_policy" "admin" {
    binding {
        role = "roles/resourcemanager.projectCreator"
        members = [
            "group:infra-admin@hogehoge.com"
        ]
    }
}

後は、providerとproject.tfを書けば、おｋ

// Configure the Google Cloud provider
provider "google" {
  project     = "${var.project_id}"
  region      = "${var.region}"
}

resource "google_project" "proj-hoge" {
    project_id      = "${var.project_id}"
    org_id          = "${var.org_id}"
    name            = "${var.project_id}"
}

Plan & Apply

% terraform plan
% terraform apply                                                                 (git)-[master]
data.google_iam_policy.admin: Refreshing state...
google_project.proj-hoge: Creating...
  name:        "" => "gcp-hoge"
  number:      "" => "<computed>"
  org_id:      "" => "${ORG_ID}"
  policy_data: "" => "<computed>"
  policy_etag: "" => "<computed>"
  project_id:  "" => "gcp-hoge"
  skip_delete: "" => "<computed>"
google_project.proj-hoge: Still creating... (10s elapsed)
google_project.proj-hoge: Creation complete (ID: gcp-hoge)

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

以上。

Railsアプリ(Production)のシークレットキーをGKE & k8sに読み込ませる

An unhandled lowlevel error occurred. The application logs may have details.

kubectl create -f services hogehoge.ymlし、公開IPにアクセスした際に出た表示↑ Application系のエラーらしいので、kubectl logs -f [POD_NAME] [IMAGE_NAME]でログを流してみたら、config/secrets.ymlにsecrete_key_baseが設定されてないとのこと。

見てみると、SECRET_KEY_BASEという環境変数にシークレットキーを設定していなかった。ちなみにアプリを開発してるのは別の人で、自分はWebアプリにあまり詳しくないマン。 　

% cat config/secrets.yml                                                                           
default: &default
  secret_key_base: XXXXXXXXXXXXXXXX

development:
  <<: *default

test:
  <<: *default

production:
  <<: secret_key_base: <%= ENV['SECRET_KEY_BASE'] %>

当然、SECRET_KEY_BASEにシークレットキーを設定してやればいいだけなんだけど、Githubに上がるのであればDockerfileやapp-deployment.ymlなどにはべた書きにはできない。なので、k8sでそのシークレットファイルを作成・管理する。

% kubectl create secret generic app-secrets --from-literal=secret_key_base=`bundle exec rake secret`
% kubectl describe secrets app-secrets

ここで作られたシークレットをデプロイ中に環境変数としてセットするため、deployment.ymlを編集

% kubectl edit deployment/app
    spec:
      containers:
      - image: gcr.io/YOUR_REPO/YOUR_IMAGE:v1.0.0
        name: mds-web
        env:
          - name: RAILS_ENV
            value: production
          - name: SECRET_KEY_BASE
            valueFrom:
              secretKeyRef:
                name: app-secrets
                key: secret_key_base
% kubectl rollout status deployment/app

ロールアップが完了後、再度アクセスしてもんだいないことを確認。

余談

• secretはk8sのマスターに格納されているっぽい。ここのセキュリティはどう担保しているのか気になる

DroidKaigi2017の振返り「ドキッ★脆弱性 onCreate() から onDestroy() まで」#droidkaigi #android

DroidKaigi2017に登壇・運営スタッフ参加したので、その振返りです。

ドキッ★脆弱性 onCreate() から onDestroy() まで

スピーカーとしての振返り

8000円の参加費をとる平日開催のカンファレンスなので気合いれてたつもりだ。 まずやったことは、OverViewの作成だ。１月頭にグワ〜っと各章のタイトルと順番をつけていった。この時点で講演時間は考慮していない。

次に、各章の締め切りとアウトプットする場を設けていった。具体的にいうと毎月開催されるPotatotipsなどの勉強会でLTをすることで、各章を完遂させた。例えば1月には、当時の体制や対応のタイムラインについてPotatotipsで話した。２月には脆弱性が生まれた原因を潰すカスタムリントを作って、やはりPotatotipsでLTした。同月には、セキュリティの勉強会で脆弱性の原因についてLTした。

最後に、各章の整理だ。これは、リハーサルと同時並行で実施した。実際に声煮出すことで、聴講向けのスムーズな構成にするだけでなく、内容を記憶できたため、資料をスリム化させることができた。

本番だが、練習のお陰で、言葉につまることは少なかったと思う。資料に目を向けることを最小限にしつつ、リスナーとうまい具合にコミュニケーションを取れたと思う。ただ、滑舌に改善の余地はあるので、気長に取り組んでいきたい。尚、練習時は25分の長さだったが、本番時は20分まで短縮できた。

誤算としては、30分が意外に短く、かなり内容を削らなければならなかったこと。50分にしておけば実際の攻撃デモや体制を紹介できたのではないだろうか。また、折角の共有なのだから、英語でチャレンジするのも良かったのではないだろうか…後はおまけスライドにミスがあったことかな…

余談ですが、筋肉の前説をいれたのは（自分の）緊張をホグすためでした。

運営としての振返り

事前準備に関しては、基本的に箱詰めをお手伝いしたり、請求書を集めたりなどの簡単な作業をお手伝いしてた。会場の支払い、CONBUさんとの交渉、タスク管理、受付のプラン、公式アプリを作るなどなどと比べてライトな作業だったと思います。そういったことを本業と並行してするのはスゴイの一言に尽きますよね。自分は面と向かって褒めるのがこっ恥ずかしくて苦手なのですが、「同じ時間と空間を過ごせたことに、感謝と誇り」を感じています（僕なりの最大の賛辞表現）

当日はTwitter広報役をやっていましたが、詳しくは@keithyokoyama山のブログをを見ていただくとよいです。反省点としては、海外からいらしたスピーカーをもっとクローズアップすればよかったと思います。自分の主観でしたが、英語喋れない人と日本語喋れない人の間に交流があまりなかったような気がしています。その間の橋渡しをするためにTwitterで「Mr. AAはXX社でAndroidのUIエキスパート的なことをしてます」みたいな紹介をすべきだった、来年はしよう、という気持ちです。

総じて#droidkaigiを見ていると、好意的な感想をいただけているので嬉しく思います。 次回はより大きなイベントになると思うので、自分としてはセキュリティ面でバリューを発揮出来るようにしていこうかな、と思います（すでにご相談いただいたりしているので）

今後のAndroidと私

最近Androidいじってねーんだよな〜というのが悩み。Authenticatorアプリを作ってみたいのと、Android Thingを攻めて行きたい気持ちはあります。後は、講演の最後でも言ったような安全なアプリを作るためのトレーニング、Androidマルウェアアプリの解析などやっていきたい気持ちです。

Demistoによって俺たちはSOCから解放されるのではないか #セキュリティ #chatops #demisto

結論: とりあえずSlackのintegrationでDemisto入れてみようず

Demistoとは

SOC的な業務は面白い事も沢山ありますが、それと同じくらいダルくもあります。例えば、「ドキュメントの作成」「進捗図の更新」「エビデンスの確保」「レスポンス前の細かい初期確認・トリアージ作業」。自分にとって、これらは出来ればやりたくない仕事です。というのも、フロー・マニュアルが定まっており、ちょっとコストをかければ誰でも再現可能な作業だからです。よって自動化したいと常々考えていたのですが、良さげなサービスを見つけたので紹介します。それがChatOpsベースのSOCサービス(「DEMISTO」)https://www.demisto.com/です。

サービス内容

DEMISTOのサービスは以下のものがあります。なお、ホームページからしか読めてないので、本当のところどうかは知らない

レスポンス製品と情報インベントリ製品との双方向な統合

「Bi-directional Integration with products for Information Enrichment and Response Actions」を直訳したので、頭痛が痛いみたいな表現になってしまい、お詫び申し上げます。

Twilio, Exabeam, Black Carbon, Slack, Active Directory, CheckPointのロゴから、恐らく「大量に外部送信してる通信(CheckPoint)かつ通常行動パターンとことなる挙動(Exabeam)を端末がしてて、Black Carbonがアラートあげてるから、管理者に連絡して(Twillio, Slack)、アカウントを一旦凍結(Active Directory)しつつ、穴を閉じ(CheckPoint)〜ましょ〜」のように、アクションとインベントリの連携を設定可能なんじゃないでしょうか。

自動プレイブックの生成と準備

DEMISTOは、インシデントが発生した場合、事前に定義した条件から、適切なPlayBookを選択します。このPlaybook内には複数のタスクが含まれており、自動で担当・期限が割り当てられるなど、それぞれの進捗確認・更新が容易になっています。各タスクについては、アサインされた担当がマニュアルに従って仕事をすることも可能ですが、Demistoが自動実行することもあるそうです。

セキュリティChatOpsによる調査と連携

これはタイトルそのままですが、過去分の調査と被ってないか自動でチェックしてくれたり、調査結果をエビデンス保存するなどの機能が、チャット上でワンクリックで実行可能なようです。便利です〜

ジャーナリングとエビデンスサポート

上述通り

自動ドキュメントによるレポート、評価、監査

自組織が抱えているインシデント全体のレポートを作成してくれるようです。抱えているインシデントの数、SLAの状況、インシデントの種類といったことを分かりやすいレポートにおとしてくれます。SOCやCSIRTそのもので役に立つより、チーム外にSOCの成果を報告する上でよさそうです。

Slack版Demisto

さて、上記の基本機能はFree Editionから限定的に使えるようになりましたが、仕事上のアカウントを使わねばならないので気軽に試せません。しかし、更に限定的とは言えSlack integrationもあります。こちらは気軽にインスコできるので試してみました。

Slack版で出来ること

脅威インテリジェンスの連携のみが可能です。脅威インテリジェンスとは、複数のセキュリティ関連データを集約したものです。マルウェアのハッシュ値や、レピュテーションスコアの低いIPアドレスなどをデータベース化したものですね。通常だとブラウザなどから入力しなければならないのですが、Slack版Demistoを使えばSlack上で完結します。アラートもSlackに流しておけば、作業を大幅に効率化できます。現時点では、IBM X-Force、Virus Total、Cylanceといった脅威インテリジェンスと連携しているようです。

デモ

• 事前準備: ここから自組織Slackに連携

監視するチャネルを指定する

• dbot(Slack連携すると追加されるボットアカウント)とのDirect Messagesで設定

join all/#channel1, #channel2

Verboseモードの設定

• dbotとのDirect Messagesで設定
• 実際に脅威インテリジェンスと照合した結果を通知するためには、これを設定する必要があります

verbose on #channel1, private1

IPを検査する

• dbotがjoin済み・verbose on済みのチャネルにIPを打ちます

サイトを検査する

• dbotがjoin済み・verbose on済みのチャネルにURLを打ちます

ファイルを検査する

• dbotがjoin済み・verbose on済みのチャネルにファイルをアップロードします

MD5ハッシュ値を検査する

• dbotがjoin済み・verbose on済みのチャネルにファイルのハッシュ値を打ちます
• 尚、sha256/sha1は検査されません

凄い（小並感 以上です。機会があれば、Slack版ではないFree版も試して見ようと思います。