チェキしたいセキュリティ系スタートアップ - 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
Illusive Networks Ltd.
- Deception Technology
- データのハニーポットみたいな(命名 by Kengo)
Creates an alternative reality transparently woven into your existing network
Insights
- 機械学習を活用した攻撃検知・分析・封じ込めプラットフォーム
- インシデントレスポンスプラットフォーム
- Demisto, Phantomとかぶる？
Kenna
LogicMonitor
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
StackPath
- セキュアCDN/WAFのプラットフォーム
- Fastly/Akamai Konaとどう違うのか？
Skybox Security
360 Mobile Security
Refs
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ハッシュ値を検査する
凄い（小並感 以上です。機会があれば、Slack版ではないFree版も試して見ようと思います。
もしも社長がセキュリティ対策を聞いてきたら
もしも社長がセキュリティ対策を聞いてきたら（日経BP Next ICT選書）
- 作者: 蔵本雄一
- 出版社/メーカー: 日経BP社
- 発売日: 2015/06/30
- メディア: Kindle版
- この商品を含むブログを見る
上記のメモといっても、自分が流し読みした本に対するいいまとめがあったのでそれを元に構成変更・追記を実施。
・セキュリティは「監視的コスト」
上流の話
セキュリティ対策の優先度付け -> FMEA
リスク優先度算出時の構成要素：
- 発生頻度、影響度、防御困難度
- それぞれに対して4段階で点数化し、
- 優先度の高い内容から対策を施していく。
- 場合によっては、影響度のポイントを上げる。
セキュリティ対策の種別 -> Get Secure And Stay Secure
- Get Secure：セキュアにする
- システム化、教育といった対策
- Stay Secure：セキュアに保つ
- 検知、可視化、改善
セキュリティ対策による部分最適にならないためには
- 運用管理しやすい仕組み
- 他の階層と連携（認証基盤・アクセス制限・ファイアウォールなどの連携)
- 認証基盤の統合
- CISOの設置
セキュリティ対策のコスパ
アプローチ
- 守備範囲の限定
- 標準機能の活用
- アリモノを更新
- 多層防御
ソリューション選定 -> コンジョイント分析
- 対策から各アプローチから選定されたソリューションの特徴を抽出し、比較検討する
特長例
- ウイルス対策: 検出率、IT基盤統合、管理工数、ライセンス費用
- 出口対策: 提供形態、レポート、リセンス費用、認証ユーザー
多層防御
- 物理セキュリティ
- セキュリティポリシー
- 認証基盤
- NW境界
- 内部ネットワーク
- エンドポイント
- アプリ
- データ
セキュリティ対策の効果測定 -> PDCA
中長期: 計画達成のPDCA
- Plan
- Do
- Check
- Action
短期: 問題解決のPDCA
- Problem-Finding：問題発見
- Display：可視化
- Clear：問題解決
- Acknowledge：確認
セキュリティ対策の必要性や脅威の動向を経営者に説明する -> PEST分析
- Political：政治的環境要因
- Economic：経済的環境要因
- Social：社会的環境要因
- Technology：技術的環境要因
セキュリティ対策の4段階 -> NIST SP800-61
- 準備 → 検知・分析 → 根絶・復旧・封じ込め → 事件発生後の対応
- 検知・分析部分の強化が早期発見への近道。
セキュリティルール作りの際の考え方
- ポリシー：情報セキュリティに関する基本方針
- スタンダード：実施する対策
- プロシージャ：利用する製品や管理手順
ルール実施までの流れ
- ルール作成・みなおしの体制創り -> CFT(Cross Functional Team)
- ルール切り分け -> 技術的な強制ルール vs 強制しないルール
- ルールに応じた仕組みの実装 -> ペナルティや損害イメージ
ルール切り分けの方針 -> MMOから考える
- Measure/Motivation/Opportunity(MMO)から考える
- MotivationとOpportunityを下げることで発生頻度を下げるのがよい。
ルールの効果測定方法 -> DAGMARモデル
- 5段階の達成度合いを計測:
- 未知: まだ知られていない状態
- 認知: 存在を認知
- 理解: ルールの内容・背景を理解
- 確信: 良いモノ（重要性)だと確信
- 行動: 順守
企業文化・人材も視野に入れた包括的なセキュリティ対策: -> マッキンゼーの7S
- Shared Value（価値観）：ソフト <- 他のSにも影響
- Strategy（戦略）：ハード
- Structure（組織）：ハード
- System（システム）：ハード
- Skill（スキル）：ソフト
- Staff（人材）：ソフト
- Style（スタイル・社風）：ソフト
要素技術
認証基盤構築のポイント
エンドポイントの一般的対策
- ウイルス対策ソフトの導入と定義ファイルの常時最新化
- パッチ(セキュリティ更新プログラム)の適用と更新
- 不正プログラムの起動防止(起動可能なソフトをホワイトリスト方式で管理)
- 不正通信の禁止
- 盗難・紛失による情報漏えいを防止(FDE/リモートワイプ)
安全・柔軟なIT基盤 -> 3A(AnyTime, AnyWhere, AnyDevice)
- AnyTime: 社内のどこでも -> 無線LAN, デジタル証明書(or パスワードとMACアドレス制限)
- AnyWhere: リモートワーク(部分アクセス(クラウド) or 完全アクセス(VPN))
- AnyDevice: BYOD(検疫ネットワーク)
セキュリティ対策を支援する機能
- OS標準イメージ
- インベントリ収集
- アプリやセキュリティ更新プログラムの配布（サイレントインストールとスケジュール)
- バックアップ
- 特定の実行ファイル・起動時間の把握(利用頻度のか把握や感染端末の特定など）
- ヘルプデスク支援
- 安全な構成
- 管理者権限のコントロール
例
- 操作ログを取得する
- 操作ログを分析する
- 管理者権限は申請時しか利用させない
- セキュアな領域での作業は必ず2人1組
もしも社長がセキュリティ対策を聞いてきたら（日経BP Next ICT選書）
- 作者: 蔵本雄一
- 出版社/メーカー: 日経BP社
- 発売日: 2015/06/30
- メディア: Kindle版
- この商品を含むブログを見る
