『今からはじめるインシデントレスポンス――事例で学ぶ組織を守るCSIRTの作り方』を読んだ

年始にリアル本屋で気なったので買ってみた。偶然にも買った2日後に CircleCI のインシデントが発生したけど、特に関係はない。

gihyo.jp

買った理由

CSIRT やインシデントレスポンスの本は色々あったけど、この本を選んだ理由は技術的な面ではなくて組織だったり運用面についてが書いてありそうだったから。

自分はフォレンジック調査だったり分析だったりのがっつりセキュリティの仕事をしているわけではないので、技術的なことがそこまで書いていない本の方がよいだろう。 また具体的な手法を知ってもそれを活かすのが難しいだろうと思っていた。

また目次を見ているとセキュリティ組織を作っていく中で現実によくありがちな課題について触れられていたのが印象的だったのもある。

  • 3-02 専任か兼任か
  • 4-02 経営層にCSIRTを認知させる
  • 5-06 目標設定と評価を行う
  • etc...

専任か兼任か経営層に〜 の文字だけでこれは悪くなさそうだなと思っていた。

感想

タイトル通り CSIRT の作り方が書いてある本だなと思う。強いて言うならば CSIRT を作るときに考えること・出てくる課題が書いてある本 で具体的にどう解決するかまでは書いてくれていない。 CSIRT について知らない人が CSIRT が何かについて把握し、この組織を作っていこうと思った際に考えることが網羅されているといった様子。

1つ1つのテーマについて書かれていることが短くまとまっているので、その意味では読みやすい。 他方そのテーマについて課題に思っている人が解決策を求めていると期待外れになるだろう。

目次を読んだ時に思った現実の課題について触れられているかについては印象通りだった。 特に 第4章 CSIRTを立ち上げる - 4-05 ミッションを定義する で「決して背伸びをしない」ことが強調されていたのが印象的だった。 思えばセキュリティの事を考えるにあたって、領域を広げることを意識しすぎていた気がしなくもないと、これを読んで反省できた。

具体的なことがあまり書かれていないのは企業・組織毎によって解決策が千差万別だからではないかと想像している。 組織によって文化や状況、リソースなど変数が様々あるので、一般化しづらいことなのではと思った。

とは言え、テーマ毎にパターンを提示してくれているので、全く具体化されていないかと言うとそうでもないように感じる。 組織を作っていく中で課題が出てきた際の状況整理のツールとして利用できるのではと思った。

また既に CSIRT がある場合でも、自分のところの組織との比較が出来るのでその面でもよいと思った。

まとめると

  • タイトル通り CSIRT の作り方について考える本
  • 具体的な解決策が書いてあるわけではないが、現実に起こる課題についても触れられているので網羅性が高いように思う

CSIRT について考えている人がいたらとりあえずこれを読んでみることをお勧めできると思う。

1Password で SSH の鍵生成・管理、また Git のコミット署名を行うのが便利そう。今後はこれを使っていきたい

developer.1password.com

パスワード管理ソフトで有名な 1Password に SSH の鍵管理の機能が追加されていた。 新たにセットアップする機会がなかったのでスルーしていたが、セットアップ機会が訪れたので試してみたところ、思った以上に体験が良かった。

また GitHubSSH 鍵でコミットの署名・検証を行える機能が追加された。 これらが組み合さって、これまでの鍵管理やコミット署名と比べて手間無くセキュアに出来ることに気づいてきたので紹介してみる。

1Password での SSH 鍵生成/管理

まず、1Password 8 から SSH の鍵を生成 / 管理できるようになった。

blog.1password.com

詳しいやり方は上記のブログやドキュメントを見てもらう方がわかりやすい。

この機能を使った GitHub への鍵の登録イメージはブログにもあるこの動画を見てもらうと想像出来ると思う。

youtu.be

見ての通り、1Password 拡張を入れていればブラウザだけで SSH 鍵の生成と登録が出来るようになる。 自動で公開鍵をペーストしてくれるので、よくわからずに秘密鍵の方を貼り付けるといったこともなくなる。 さらに署名アルゴリズムのデフォルトが Ed25519 で生成するので、よくあるコピペそのままを使って RSA を利用するといったこともなくなる*1

1Password で生成した SSH 鍵を使い Git のコミット署名をする

次に 1Password で生成した SSH 鍵を使って Git のコミット署名を行うことについて説明する。

これまでも GitHub は GPG や S/MIME を使った署名・検証を行えたが、この8月の機能追加で SSH 鍵を使ったコミット署名の検証に対応した。

github.blog

そして2週間後、1Passwordを使いGitのコミット署名を行うブログが出た。これがビジネスのスピード感。

blog.1password.com

これも同じようにブログにある動画を見てもらった方がわかりやすい。

youtu.be

動画の通りわずか1分で署名用の鍵の登録と Git の設定が完了した。 上手く見せてるだけと思うかもしれないが、自分自身が試したときもこれと同じステップで設定が完了した。時間を使ったのはせいぜい 1Password に登録する名前を考えるくらい。

自分はこれらの機能が出る前から GitHub でコミット検証が出来るように設定していたが、1Password を使うやり方と比べたらはるかに手間や知識が必要と感じた。

基本的には GitHub が用意しているドキュメント通りにやれば出来るものの、GnuPGを入れたりCLI操作が必要だったり、コミットに署名するための設定を .gitconfig に追記したり等、様々な手順が必要だった。

コミット署名の検証を管理する - GitHub Docs

それがこの 1Password での SSH 鍵管理と GitHubSSH 鍵によるコミット検証対応で、非常に簡単な操作かつ追加のインストールを必要とせず行えるようになった。 このことの衝撃が多少なりとも伝わればと思う。

試してみた感想

既に書いてしまっているが、実際に試してみた感想や思ったことを書き出してみる。

SSH 鍵の管理を考えなくてよくなった

これまで真面目に鍵の管理を考えていたわけではないが、1Password に保存されることで全てをそちらに任せられる。

鍵の管理を意識するのは、特に端末を移行する際鍵をどう移行させるかといったときに考える。 もちろん移行はそこまで手間のかかる作業ではないが、面倒で新しく鍵を生成することもよくあった。

これが 1Password に保存されることで 1Password のセットアップさえ出来ればそれで済むことになり、管理だけでなく SSH 鍵のポータビリティが向上していると思う。

コミット署名の設定が楽

これは既に書いているが、コミット署名の設定が非常に楽になった。

追加のインストールが必要ないだけでなく、1Password が自動で .gitconfig に追記してくれるので、ボタン1クリックでコミット署名の設定が完了した。 デフォルトでコミット署名を行うようになるので、ユーザーは何も意識せずに署名と検証が出来るようになる。

これまでは設定が手間でコミット署名を行ってこなかった人も、こんなに簡単に出来るのなら設定しておくかと思うのではないか。

全ての開発者に Git のコミット署名をお願いしやすくなった

Git のコミット署名・検証は行えた方がよいとされているはず*2GitHub でどのアカウントによる変更か正しく追跡できるようになるし、Branch Protection Rule で署名付きコミットのみに制限することも可能になる。

しかし、Git のコミット署名は面倒だったので設定しないことが多かった。自分も面倒さのために最近まで設定できていなかった。 自分自身が出来ていないので、他人に勧めたりチームや会社のルールにして必須化するまでは考えにくかったが、この 1Password と GitHub の機能追加によって状況が変わったように思う。

ターミナル操作を行わなくても10クリック程度でコミット署名の設定が行えるようになったし、1Passwordで鍵のポータビリティが上がったことで鍵の移行も間違いなく出来る。

この利便性の向上によって、全ての開発者に Git のコミット署名の設定をお願いしやすくなったと思う。 ここでの開発者はエンジニアだけでなく、デザイナーなどの職種も含んでいる。

コミット署名はやれた方がいいが、他に優先させることがあれば後回しになる類の設定になると思う*3。 署名しなくても Git は使えるし、設定不備によるサポートの手間も考えなくてはいけなくなる。 署名によるセキュリティの向上具合を考えたら、他に取り組むべき課題を優先させることがあってもおかしくはないだろう。 しかし、10クリック程度で簡単に設定できるなら、簡単なので署名をしようという方向に出来ると思う。

SSH 鍵の管理と Git のコミット署名の設定の体験が良くなったことで、特別なことをせずにセキュリティを向上させられていると感じている。 このことは 1Password もブログに書いていて、複雑さを無くすことでセキュリティリスクを下げられることについて書いている。

blog.1password.com

気になるかもしれないこと

懸念もないわけではないので、書いておく。

SSH 鍵のパスフレーズを設定できない?

既にパスフレーズが設定されているものをインポートしたときは要求されたが、新規で作る際は要求されなかった。UIも見辺らないし今は実装されていないのかもしれない。

このパスフレーズ秘密鍵が窃取されたり、端末にアクセスされた際に利用されないようにするもの*4。 端末へアクセスについては 1Password のマスターパスワードで代替できているとしてもいいだろう。 一方秘密鍵が窃取された状況はカバー出来ていないかもしれない。 そう考えるとこれはやや微妙に感じるポイントかもしれないが、そもそも 1Password 保管庫にある情報が窃取されている状況はもっと深刻な被害になるような気はする……。

秘密鍵クラウド上に保管していいのか?

秘密鍵をローカルPC以外に保存したことがなかったので一瞬考えたが、既に重要なサービスの認証情報を 1Password に置いているのなら何も気にすることはないと思い杞憂であると思った。 むしろ秘密鍵~/.ssh/ 以下にそのまま置いてあるより安全なのではないか。 これはもう 1Password をどの程度信用するかに寄ると思う。

SSH 鍵をコミット署名に利用していいのか

GPG の方が確実で信用できる、といった議論が出来る知識は乏しいのでここでは議論しない。

使いものになるかの話で言うと、1Password で管理することで鍵のポータビリティが上がり同じ SSH 鍵を利用し続けるコストが低くなったため、署名・検証が機能するのではと考えている。

まとめ

1Password で SSH の鍵生成・管理、また Git のコミット署名を行うことについて紹介した。

第一印象は今すぐにでも広めたいくらいだが、まだ気づいていない問題点があるかもしれない。 実際私用で試し始めたばかりなので、しばらく使ってみて改めて振り返ってみようと思う。

パスワードレスの世界が本当に来そうなタイミングで、1Password が開発者向けツールを模索していることはとても納得がいく。 複雑さを無くすことでセキュリティリスクを下げるといったことにも共感するので、これからの動向にも期待したい。

参考情報

自分の行っているセキュリティ関連の情報収集

聞いてるポッドキャストでセキュリティ情報収集どうしているのかといった話題があった*1ので、いい機会だから自分の行っているセキュリティ関連の情報収集をまとめてみた。

前提

  • どんな人
    • セキュリティに興味あるWebアプリケーションエンジニア*2
  • 興味の範囲
    • Webアプリケーションにまつわるセキュリティ全般
    • サービス開発・運用まわりに関するセキュリティ
  • 知りたい情報
    • 関係ありそうな脆弱性情報
    • 興味範囲の最近の話題やトレンド
    • その他セキュリティ関係で話題になっていそうなこと

話題やトレンドはキーワードを拾い後から調べられるように脳にインデックスを作っておくのが目的で、網羅や詳細に知ることはあまり意識していない。

情報ソース

前提に書いた知りたい情報を、各種サイト・ブログ、TwitterPodcast から収集している。 Twitter脆弱性情報などスピードが重要なものからトレンドまで幅広く知れてやっぱり便利。

サイト・ブログ

インシデントや脆弱性情報などのニュース的なものは Security NEXT で知り、ブログや発表などは はてなブックマーク に流れてくるものを見ている。 はてブに流れてくるものは関心ワード機能を使ってセキュリティに関する情報を集めるようにしている。

id:piyokango さんのブログは出来事を詳細にかつ客観的にまとめてくださっているので、理解の助けになる。 また、自分がでタイトルだけ見てスルーしていた出来事でも、ここで取り上げているのを切っ掛けに出来事を知ったり考えたりしているので、新たな視点を得る機会にもなっている。いつもありがとうございます。

CISA を見ているのは Known Exploited Vulnerabilities Catalog に追加される脆弱性を見てヤバそうな脆弱性を把握するため。本当は KEV の更新だけ見たいが、これだけ見るには ML に登録する必要があり、面倒で見なくなる気がしたので CISA の更新を丸ごと見ている。

他にも見ているサイトやブログはあるが、常に見ているのはこの4つが主。 他のサイトは大チェッカーにまとめておく。

Twitter

興味範囲の界隈の人をTwitterのリストに入れて見ている。 過去24時間分を遡れないくらいの人数は入れていない。今数えたら35アカウントだった。

これについては先人の方がまとめてくださっているのでそちらを参照しておく。

ポッドキャスト

日本語でセキュリティについて話すポッドキャストがいくつかあるので聞いている。

ポッドキャストは情報の内容を知ることはもちろんだが、情報そのものよりもそれを元に話される考察だったり話者の反応だったりが一番タメになると思って聞いている。 考察はニュース的なメディアだと得づらいし、テキストだと反応や雰囲気を感じにくい場合もあるので、ここがポッドキャストを聞く価値かなと思う。

また、雑談パートがあるなど聞いていて楽しくラジオ的に聞けるのも重要だと思う。 自分の性格かもしれないが、娯楽な要素があることで聞き続けられる面もあると感じている。

一時期英語圏ポッドキャストも登録していたが、英語のリスニングと内容理解を同時に行うことは今の自分にはやや負荷になるなと思いやめてしまった。いつか再チャレンジしたい。

情報収集に使っているツールと使い方

ここではツールの紹介。

  • Slack RSS
    • サイト・ブログの更新チェックに使っている
    • RSS リーダーも使っていたけど、これが一番定着した
    • Slack はずっと立ち上げているし、更新もわかりやすい
    • PC / スマホ / タブレット とマルチデバイスで同期も取れているというもの要素の一つかも
  • Twitter
    • リスト機能で気になる人のツイートを見るため
  • はてなブックマーク関心ワード
    • 話題になっている情報を見るため
    • ホットエントリーだと見たい情報を絞れないので、関心ワード機能で気になる話題だけ見ている
    • キーワードにしているのは Securityセキュリティ の2つ
      • 微妙に流れてくる情報が違うので、2つ入れることで網羅性を上げている
      • ただし、 セキュリティ の方は時期によってはサイバーセキュリティ以外の情報が多く流れてくるので注意が必要
  • Google Podcasts
    • ブラウザがあればどこでも聞けるのが便利で使っている
    • ただし質は微妙な気がするので、代わりになりそうなものがあれば検討したい

普段の情報収集の様子

毎日・週1、更新があればの3パターン。 全部丁寧に見ていると大変なので、ポッドキャスト以外はあまり時間をかけずにさっと流す程度にしている。

  • 毎日
    • Twitterのリストに入れている人の直近の更新を眺める
    • RSSの更新を眺める
    • 更新量は日に1回でも見切れる量だが、2,3回に分けてみると丁度いい
      • 自分は暇になったり休憩中に見たりしている
  • 週1
    • はてなブックマークの関心ワードを1週間分眺める
      • 週に1回会社のセキュリティ会という集まりがあるので、それにあわせて見る
      • 全部見るのではなく、気になったページを開く程度
      • 読むのに時間がかかりそうなものはブラウザのタブで開きっぱなしにしていたり あとで読む 系ものに放り込んだりする
    • セキュリティのアレを聞く
      • 月曜の夜更新なので、だいたい火曜の午前中に聞いている
  • 更新があれば

まとめ

自分のセキュリティ関連の情報収集のやり方をまとめてみた。 書き出してみると、結構色々やっていることに気がついた。

インプット分のアウトプットやそれ以外の何かが出来ているのかと言うと微妙な気もしてきたので、今後はアウトプットの方も意識していきたいなと思う。 まずは感想をツイートしてみるくらいから始めていきたい。