2017-05-09

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.

以上。

2017-04-03

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のマスターに格納されているっぽい。ここのセキュリティはどう担保しているのか気になる

2017-03-12

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 マルウェアアプリの解析などやっていきたい気持ちです。

2017-01-22

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で設定

f:id:kengoscal:20170122021432p:plain

join all/#channel1, #channel2

Verboseモードの設定

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

verbose on #channel1, private1

f:id:kengoscal:20170122021601p:plain

IPを検査する

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

f:id:kengoscal:20170122021710p:plain

サイトを検査する

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

ファイルを検査する

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

MD5 ハッシュ値を検査する

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

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

2017-01-08

もしも社長がセキュリティ対策を聞いてきたら

読書まとめセキュリティメモ

もしも社長がセキュリティ対策を聞いてきたら（日経BP Next ICT選書）

作者: 蔵本雄一
出版社/メーカー: 日経BP社
発売日: 2015/06/30
メディア: Kindle版
この商品を含むブログを見る

上記のメモといっても、自分が流し読みした本に対するいいまとめがあったのでそれを元に構成変更・追記を実施。

元ネタ: http://booklog.jp/item/1/4822215911

・セキュリティは「監視的コスト」

上流の話

セキュリティ対策の優先度付け -> 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（スタイル・社風）：ソフト

要素技術

認証基盤構築のポイント

IDはユニークに
パスワード管理ポリシーの矯正
管理者IDは強く(ICカードなどの利用)
認証基盤は統合

エンドポイントの一般的対策

ウイルス対策ソフトの導入と定義ファイルの常時最新化
パッチ(セキュリティ更新プログラム)の適用と更新
不正プログラムの起動防止(起動可能なソフトをホワイトリスト方式で管理)
不正通信の禁止
盗難・紛失による情報漏えいを防止(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版
この商品を含むブログを見る

2017-01-01

大陽日酸に対するサイバー攻撃についてまとめてみた

セキュリティニュースまとめ

イントロ

工場や医療現場で使われる酸素や窒素、二酸化炭素などを製造、販売する国内最大手の大陽日酸がサイバー攻撃に合っていた模様。報道された2017/1/1には対応済みっぽい。

タイムライン

日時	出来事	備考
2015/11	最遅でもこの時点で侵入済み
2016/3/11	外部からの不正接続(海外?)を確認。ウイルス感染を確認。サイバー攻撃と認知
2016/3下旬	ウイルスを駆除
2016/4/28	警視庁に被害相談
2016/4/29	流出範囲(可能性)の特定
2017/1/1	公開報道。ホームページには未記載
2017/1/5	ホームページに公式発表公開。

攻撃の概要

ぱっと見、標的型攻撃っぽいところはある

攻撃の影響と成否

以下の事実が確認されている。

管理者権限の奪取
システム内の情報が外部から見れる状態。600台に対して、外部から管理者権限によるログインが可能だった。
情報の流出は~~未確認~~、1万人の社員情報が流出した可能性あり

武器化

Delivery

Exploit

Install

成功 -> 最終的に4種類のマルウェアに感染していたところから。

C&C

(2015年11月までに)成功 -> 外部からの管理者権限を使った遠隔操作で、システム内の大半にあたる６百数十台のサーバーに接続できる状態。サーバーの一つから２回にわたり外部と不正通信が発生。

データの破壊・盗難

成功(可能性が高い) -> グループ国内従業員ら11,105人分の個人情報(社名・氏名・職位・メアド)など内部情報を複数の圧縮ファイルにまとめていた痕跡。サーバーの一つから２回にわたり外部と不正通信が発生。

被害額

窃取された情報から、直接的な被害額は発生していない。ちなみに株価(1/4)時点では下がるどころか上がってる。世間が気づいてないか、気づいてるけど大して重要視してないか、それともトランプ効果があるからか、これから下がるのか。 f:id:kengoscal:20170104110344p:plain

原因

社内システムの通信記録（ログ）の保存が不十分だったため、侵入の経緯などの詳しい調査ができていない

対策

サイバー攻撃早期検知のための監視体制強化
管理者権限の搾取対策今日か
不正遠隔操作を某氏するための対策強化
大陽日酸ではないが、窃取された社員情報を利用した標的型攻撃に気をつける必要はありそう。
例えば「Title: [大陽日酸からの重要なお知らせ] Body: Hoge部長のFugaです。この度は云々カンヌン」みたいな。

所感

~~piyologはやすぎぃ！~~ やっぱりpiyologはすごい。必ず1歩先をいかれている。
~~後、具体的な数字(600台とか1万人の社員とかサーバ内情報とか)が出てて凄い。どこにあったんだろう~~ 公開情報。
2017/1/1に報道公開した意図は不明。
~~株価への影響をみたい。1/4に要チェキ~~
~~これ以上、続報でなさそう。~~
最初に報道したところが、次の報道も早いと考えたほうがいいかも？
JTBの時もそうだが、nikkeiは遅いかも。
"当社の生産設備制御系システムは、基本的には今回サイバー攻撃を受けた情報系ネットワークおよびインターネットとは接続されておらず、今後もサイバー攻撃の影響を受けないと考えます。"　おっ、そうだな。
警視庁公安部が不正アクセス容疑で操作...あっ（察し)

反省

検索方法: 大陽日酸サイバー site:( OR OR OR OR )
検索方法: Google News

更新内容

2017/1/1: 初版
2017/1/3: 多数のニュースサイトで取り上げられるも、新しい情報なし。ホームページへの記載もまだ。
2017/1/4: 太陽日酸 -> 大陽日酸。ワロッシュ。どうりで検索も引っかからないはずやで。
2017/1/5: ホームページ上で公式発表。

Ref

ガス大手にサイバー攻撃警視庁が捜査 - 産経ニュース

ガス大手にサイバー攻撃ウイルス感染、警視庁捜査 | どうしんウェブ／電子版（社会）

ガス大手にサイバー攻撃、管理者権限奪われる : 社会 : 読売新聞（YOMIURI ONLINE）

ガス大手にサイバー攻撃 | ロイター

http://www.tn-sanso.co.jp/jp/_documents/info_07830547.pdf

通信記録の保存不十分…サイバー攻撃調査できず : 社会 : 読売新聞（YOMIURI ONLINE）