ぶるーたるごぶりん

UI, UX, セキュリティとか😘

WebアプリケーションにおけるDevSecOpsの理想と現実 Part 1 〜Bot型攻撃から見たパッチ管理について〜

はじめに

本記事では、前回の記事(https://brutalgoblin.hatenablog.jp/entry/2020/02/15/153805)にてあまり触れられなかったWebアプリケーションにおけるDevSecOpsの所感や考え方、動向を個人的思想でまとめた記事になります。

本記事は個人の感想が多分に含まれているため、どこかしらで(何かしらに)寄った意見や 知識不足から来る誤った解釈などが含まれているかもしれません。 もし本記事で誤った箇所や違ったポリシー、事業のフェーズによって違う考え方を持たれている方がいらっしゃいましたら、是非コメントやリプライなどで意見をください。 というか、私自身が迷っている部分も多くあるため、そういった知見を頂けるのであればこの記事を書いた甲斐があるというものなので、是非是非フィードバックを・・・!

本記事は章組をした段階であまりにもデカくになってしまいましたので、記事を分割して公開します。 記事の構成としては大まかに 「何から守るか(攻撃)」「どのように守るか(手段)」「手段には何があるか」「理想と現実」 という流れに沿って話を進めていこうと思いますが、書き終わった内容を順番に投稿していくのでこの流れから大きく脱線するかもしれません。

ちなみに本記事の根底にある考え方は、以下の資料あたりをかなり参考にしています。(パッと思いついたのが以下の資料なので他にも色々ある気がします。)

https://speakerdeck.com/rtechkouhou/cui-ruo-xing-guan-li-falsebesutopurakuteisutosuretutomonitaringu
https://speakerdeck.com/rtechkouhou/e-yi-toshan-yi-gajiao-chai-suru-nei-bu-bu-zheng-toiuming-falsesasupensu
https://medium.com/@NetflixTechBlog/scaling-appsec-at-netflix-6a13d7ab6043

目次

まだ完璧に章組できているわけではないのでどんどん書きながら変えていくと思います。 めっっっっっっっっっっちゃくちゃ長いのでここは読まずに本文に飛んでください

標的型攻撃とBot型の攻撃
  Bot型:
    攻撃シナリオ例(Jenkins)
    アタッカーサーフェイスと攻撃
    CVEとパッチ
    パッチの辛さと現実(ex.攻撃される可能性)
      社としてのベースライン決め
    パッチとPOC、POC評価  
    CVE情報の収集と資産台帳、是正管理
    脆弱性のパターンとレイヤー

------ 今回はここまで ------

  標的型:
    脆弱性診断の限界
    特別なパターンと攻撃
    Cyber-kill-chainと偵察
    サプライチェーン攻撃(と事例)
      npmパッケージのバックドア事件
      難読化されたJSを復号化したらカード搾取のスクリプトだったやつの話(recruitさんの記事)
    最新の攻撃手法とパッチのリリース期間(Zero Hour)
    侵入と横展開(Lateral Movement)
    標的型の対策のために
      侵害されること前提で監視を行う
      安全な環境の提供
      特殊な攻撃パターンをペンテストやバグバウンティでカバー

監視の話と監視以前で食い止める考え方
  スキャンとスパイク
  ログインフォームに対する監視と設計(NIST-800-53とか含めて)
  WAF/IDSの限界
  WAFのバイパス
  ユーザのアクテビティと特徴(404/500スパイクとか)
  アカウントテイクオーバーと監視、機能設計
  ログと個人情報・復号化
  全てを監視に寄せるのは悪手?
  Threat Intelligenceの話とか?

脆弱性に対する「診断・ペンテスト・バグバウンティ・スキャン」について
  脆弱性の限界(再び)
    診断ベンダーの能力、診断スコープ、診断後のリリース品に脆弱性が含まれていたり
  バグバウンティと言う「継続的な擬似攻撃」
    バグバウンティのトリアージが辛いと言う話
  ペネトレーションテスト
    言葉が一人歩きする侵入テスト
    資産評価と厳しさ
    何をゴールとするか
  自動テストとしてのセキュリティスキャン
    インフラレイヤーのスキャン、そして精度
    アプリレイヤーのスキャンと現実
    静的なスキャンと精度
    DevSecOpsでできる範囲を考える

安全な環境の提供
  脆弱性の検出パターンとそれを防止する策
    場当たり的なパッチ、それと全てをガードできる横串の対策
  AWSのGuardDutyとTrustedAdvisor
  DevSecOps Tools Chain

(ここら辺半分メモ書き)
脆弱性のパターンと対策について
  対策方法について
    ベースラインとして確保できそうなやつ
      XSS : CSP, SPA
      SQLInjection : ORMなどの横串対応
      Click Jacking : ヘッダ
      CSRF : Same-Site-Cookie とか横串で対応すれば撲滅
      セキュリティヘッダ : 最初に導入
    静的コード解析で取れる気がするやつ
      SSRF : 静的コード解析
      Command Injection : 静的コード解析
      XXE : 静的コード解析ツールの精度次第
    ある程度検出できる気がするけど難がありそうなやつ
      Open Redirect : ある程度検出できる気がするが評価が難しい
      RFI/LFI : これも検出しにくい気がする
    無理そうなやつ
      Template Injection : 無理な気がする
      CRLF : 無理な気がする
      Path Traversal : 無理な気がする
      安全ではないデシリアライズ : 検出厳しい気がする。Netflixのやつを紹介。
    ガイドラインで対応できそうなやつ
      ログイン機能 : セキュアコーディングガイドラインの制定
      認証・認可 : セキュアコーディングガイドラインの制定
      Cookie : セキュアコーディングガイドラインの制定(と診断)
    会社としてのルールでなんとかできそうなやつ
      ライブラリの最新化 : ルール作成
    (TODO:その他思い出したらかく)
  脆弱性の一覧やガイドラインをどう作るか
    多分ベンダーから買うのが一番安い
    ベンダーから買う奴が現場に適用しずらい部分は絶対あるからチューニング

DevSecOpsと言う耳障りのいい言葉
  金がかかる
  運用や建てつけが考えられていないベンダーの言葉
  診断は1ショットでお金がかかる。アジャイルに組み込めるのか?
  SAST, DAST, WAFとかどこまでお金をかけるの?
    コストとしてのセキュリティ
    経営者と投資判断(そんなに上手くかける自信ないが)
  WAFとバイパス
    軽くかけばいい気がする
    復号化の話も軽く再度触れる
  SAST
    Lintの修正をしない・テストをしない、そんな状況でSASTを入れれるのか・・・?
    誤検知と脆弱性があることの証明の難しさ
  DAST
    スキャンを再度触れる?
    やっぱり辛いぞ動的スキャン
  セキュリティの内製と現実
    色々な職種のあるセキュリティ(ここもうまくかける自信ないが)
  新技術とセキュリティ
    Dockerの登場といった技術のシフト

何もセキュリティをやっていないところからのアプローチ
  まずは診断を受ける
    傾向分析と是正・水平展開
    開発者全員へのフィードバック(例えばポストモーテムみたいな)
  横串での対策検討
  ベースラインの作成とその適用 (AWS Config)
  パッチ管理などを考える(ルール決め・運用決め)
  アタッカーサーフェイスの把握と対応(TrustedAdvisor)
  危険を察知できる環境づくり(GuardDuty, 監視体制の構築)
  侵入された際の対応(例えばラテラルの話、AWS Inspector、どこを調べるか、DockerとSOCなど触れたい)
  脅威の評価と対応手順

チームと運用
  脆弱性を作り込まないためには?
  チーム内での能力差
    「そう言う書き方をすると脆弱性が入るなんて知らなかった!」
    CVEを読めと言うが、そんなつまらない運用を皆やってくれるか?(サボるのでは)
    脅威への対策と自動化
    トイルと自動化
    意義の共有とドキュメンテーション
  診断結果と共有・ポストモーテム
  開発者教育
    輪読会と失敗
    意識啓発とハードニング
    診断結果と知見の共有
    インシデント対応とトレーニング
  開発チームとセキュリティチームのコラボレーション
  採用で採れるセキュリティエンジニアには限りがある
    ユーザ企業系とベンダー系
    内製と外注

AWSのセキュリティ(上で書いてるから冗長)
  TrustedAdvisor, AWS Config, GuardDuty, AWS Inspector

妄想
  SOCの対応と自動クローズ
    ある人からの「脆弱性診断の結果をSOCのアラート自動評価に使えないか」と言う無茶振りと所感
    アラートの評価と各要素の突合・難しさ
    静的コード解析の結果とアラートを突合できるのでは?と言う妄想

後から思いついてどこかに描きたい奴:
  攻撃者目線での「欲しい情報」をもつリスクとビジネス価値
  内部犯行を忘れずに。
  買収と脆弱性

これ書き終わる頃には今年終わってそう・・・。 まあゆっくり進めましょう。

標的型攻撃とBot型の無差別な攻撃

アプリを守るにはまずは攻撃者を知る必要があります。 攻撃を知らなければ私たちは何を守り、どのように守り、何を見なければいけないのかがわからないからです。

まず、一般的な攻撃の分類は、大きく分けて「標的型攻撃」と「無差別な(Bot型)攻撃」に分かれます。 標的型攻撃では、攻撃対象をしっかりと偵察し、攻撃と効果の最大化を狙ってきます。 例えば採用サイトで利用されている技術スタックを調べたり、レスポンスの出方から利用されている技術スタックを調べた上で、対象の換金率が良さそうなデータ(ex. クレジットカード情報、パスワードなど)を狙って監視部門にバレないようにゆっくりとした攻撃を仕掛け、巧妙にデータを盗み取ったりなどです。 データを盗む以外にもサービス停止を実施したり、ランサムウェアなどに感染させて身代金を要求するなど、犯罪のパターンは色々あり、攻撃者が何をゴールとして攻撃を仕掛けてくるかによって様々です。

一方でBot型のような無差別な攻撃は、対象の情報収集など(あまり)行わず、とにかく「刺さる可能性のある攻撃」を所構わず実施して侵入を試みます(正確にはそういう傾向が多いというだけで、バナー情報収集をした上で攻撃するケースなども、もちろんあります)。 例えばSSH総当たり攻撃をしたり、新しく出た大きな脆弱性の攻撃コードを片っ端に打ってきたりなどです。

これらの違いは「執念深い」かどうかだけです。 ただ、このあたりの攻撃の質・脅威のタイプを理解しておかないと、実施するリスク低減措置がどういうリスクケースに効くのかわからなくなってしまいます。

ここからはBot型の攻撃、標的型の攻撃を更にもう少し掘り下げ、 その中で関連するキーワードなどに対してスポットを当てて各要素を見ていきます。

Bot型の攻撃

攻撃シナリオとアタッカーサーフェイス

さて、Bot型の攻撃を行うシナリオをまず見てみましょう。 攻撃シナリオはJenkinsを題材に進めます。

去年(2019年)Jenkinsで、RCE(Remote Code Execution)と呼ばれる「自由なコード実行」に関する脆弱性が報告されました。 詳細については発見者のバグハンターがブログで詳細を書いていますのでそちらを参照ください。 https://blog.orange.tw/2019/01/hacking-jenkins-part-1-play-with-dynamic-routing.html

この脆弱性では、PoC(Proof of Concept、概念実証)コードが公開されており、 脆弱性の中身を知らずともJenkinsに対して攻撃を仕掛けることができました。 つまり、PoC(Exploit Code、攻撃コードレベルのPoC)を知った犯罪者が脆弱性の中身を知らないけど攻撃できる状態となるわけです。 これではスクリプキディ(人の製作したプログラムを利用し、どこかに攻撃を行うような能力が低い犯罪者)が所構わず攻撃を仕掛けてしまいます。 つまり、PoCコードが存在するということは、それだけその脆弱性を悪用した攻撃が増えるわけです。

では、PoCコードを拾ったハッカーが攻撃を仕掛けるまでの流れの例を1つ見てみましょう。 攻撃者はまず攻撃が刺さるサービスを探し出す必要があります。 そこで利用されるのが(世間的にはグレーなサービスである)Port Scanやバナー情報収集を行なっているサービスなどです。 有名なサービスではCencys, Shodanなどがあります。 Cencysは世の中のIPに対して、勝手にPort Scanを行い、空いているポートをリスト化しているサービスです。 Shodanは同じようにオープンになっているサイトに対してクローリングを行い、HTTPヘッダを検索できるDBを提供しているサービスです。

感のいい人であればわかると思いますが、Jenkinsに対する攻撃コードを手に入れられた場合、 攻撃者は対象となりそうなサーバを探して攻撃を仕掛けられます。 例えば Jenkins のHTTPヘッダを含むサーバを探したり、 Jenkinsがデフォルトで開くPortの番号 8080 を探したりなどです。 (Portが汎用的なPortなので、ここでは別のサービスなどを想像していただけるとわかりやすいです。例えばSSH, RDP, AD関連のPortなどなんでも良いです)

ここまでの材料をまとめれば、公開されたPoCコードを使い、PoCコードが刺さるサービスを検索するだけで、即インスタンスを乗っ取る流れができます。 つまり、外部に向けて(この脆弱性が刺さるバージョンの)Jenkinsをオープンにしていると、 ログインフォームがあろうと自由な攻撃が実施できるというわけです。 当たり前ですが絶対に悪用しないでください。 (そもそも少し古い脆弱性なので、外部にJenkinsを公開していた場合は既に侵入されていると思うので悪用できないと思いますが)

この話の中で重要なのは脆弱性の中には攻撃コードが公開されることがあるということと、 無闇矢鱈なポートの解放などは攻撃可能領域を攻撃者に晒すということです。 この攻撃可能領域の事をアタッカーサーフェースと呼びます。 SSHのPortを開けているなら22番、HTTP, HTTPSを開けているなら80, 443と、その上で動いているアプリケーションサーバでやり取りする箇所がアタッカーサーフェースです。

アタッカーサーフェース周りの話では、国立研究開発法人情報通信研究機構NICT)が実施した脆弱なIoTに侵入できるか試す "NOTICE" という試みが別視点で参考になるかもしれません。 大変面白い試みであり、現在の日本の一部はちゃんと守られ、一部の業界ではITセキュリティがあまりにもずさんな状況であるということが多少伝わってくるのではないで消化。 https://www.itmedia.co.jp/news/articles/1902/14/news059.html

アタッカーサーフェースとCVE・パッチ

前節でPortの無闇やたらな公開はアタッカーサーフェースの領域を広くしすぎてしまい、攻撃を受ける可能性があるということがわかったと思います。 逆に言えば全てのPortを閉じれば安全なわけですが、それではサービスの提供ができません。 サービスを提供する必要がある場合、Port 80, 443 といったHTTP, HTTPSを公開は、ほぼ必須です。 しかしHTTP, HTTPSの領域を公開した場合、脆弱性情報・PoCが公開された場合に攻撃受ける可能性があります。 そこでHTTPなどで動いている受け手側のアプリケーションの脆弱性を無くしていく必要があるわけです。 つまり、運用の中でCVE(Common Vulnerabilities and Exposures)情報の収集とパッチ適用を実施する必要があるわけです。 (もちろん、今回書いていない脆弱性診断・ペネトレーションテスト・バグバウンティなどのブラックボックス的なアプローチも必要です)

CVEとは、脆弱性に割り当てられる共通識別子で、米国政府の支援を受けた非営利団体 MITREが発行するものです。 CVE情報には対象となる脆弱性を持つモジュール名とパッチとなるバージョン、脆弱性の特性やCVSS(Common Vulnerability Scoring System)と呼ばれる危険度の特性を記した情報が含まれています。 CVSSはは複数バージョンがありますが、概ね根底の思想は変わっておらず、それぞれの脆弱性における危険度を様々な観点で評価し、10点満点中何点の危険度であるかを算出しています。 詳細についてはIPAが出している解説をご覧ください。 https://www.ipa.go.jp/security/vuln/CVSS.html

サービスを堅牢に保つにはこのCVEを見て、脆弱性が存在するライブラリやミドルウェアなどを利用していた場合は、安全なバージョンへアップデートをする必要があるわけです。

それとここまでの話で「脆弱性診断は不要ということ?」という疑問を持った方もいると思います。 個人的にはこのBot型の攻撃において脆弱性診断は「めちゃくちゃ有効に働くというわけではない」という考えを持っています。 詳細については次の記事で記載する「標的型攻撃のケース」あたりでお話しします。

パッチの適用と現実

CVE情報を手に入れ、パッチとなるfix versionもわかりました。 あとは早急にパッチを当ててサービスを安全な状態にするだけで対応終了です。簡単ですね。

と、そんな理想的な話だったら安全なサービスで溢れかえった素晴らしい世の中になっているはずです。 実際の運用はそこまで簡単ではありません。 パッチ適用にはあまりにも面倒臭い部分がたくさん存在します。 以下に思い当たるパッチ適用に関する問題をリスト化しました。

  • CVE情報(体感 1日で 100 - 500件程度発行)の収集と精査
  • (場合によっては全社で)利用しているライブラリ・OSなどの情報一覧となる資産台帳作成
  • サービスのリリースの度に資産台帳に変更を加える運用フロー
  • パッチ適用のバージョンアップで発生する作業(ex. 依存の解決、廃止されたメソッドの変更など)
  • パッチ適用によるデグレやサービス提供上の問題解消
  • 攻撃が既に確認されている場合、サービス提供停止判断(とその説得材料集め)

さてパッと出しただけでもこれだけあります。そしてどれも難敵です。 順に見ていきましょう。

CVE情報(体感 1日で 100 - 500件程度発行)の精査

タイトルの通りですが、CVEは1日に多いと500件程度発行されます。 これを見るのは苦痛ですが、CVEから逃げるとロクなことにならないため、 見て、評価し、社内の環境を確認してパッチの適用を進めなければなりません。 この作業を毎日100件など実施しなければならず、漏れなどが起きる可能性だってあります。

そもそも、多くの会社で「どのように見ればいいのかわからない」「どの場合に対応を実施すればいいかわからない」 といった知見が無い会社は多くあるのではないでしょうか? ここに関する解決策や考え方は後述します。

(場合によっては全社で)利用しているライブラリ・OSなどの情報一覧となる資産台帳作成

さて、これは部署レベルでやるのと会社の横断部署でやる場合に大きく難易度が変わる点です。 自部署のサービスであれば一覧を作成するのに(それほどは)労力がいらないでしょうし、 そのライブラリなどに対する知識もあるためアタッカーサーフェースなどを考慮した上での 資産台帳を作成することができます。 ※ここでいう資産台帳は利用しているライブラリなどの一覧という意味で言っています。

一方で横断部署のようなところですと、全社で利用しているライブラリ・ミドルウェア一覧を作る必要があり、 部署間のコミュニケーションコストや、見ず知らずのライブラリの脆弱性情報を収集するという 難易度が高めの対応をしなければならなくなります。

資産台帳にリリースの度に変更を加える運用フロー

資産台帳は作ったら終わりではありません。 作成し、変更が発生する度に変更を資産台帳(やそれに類するもの)に記載しなければなりません。 例えば台帳を作った次の日に新規のライブラリがサービスに追加され、それに脆弱性があったとします。 すると資産台帳の更新サイクルは1年だった場合、1年間問題が野放しになるといった事象が発生します。

パッチ適用のバージョンアップで発生する作業(ex. 依存の解決、廃止されたメソッドの変更など)

この問題については開発者であれば書かずともわかっていただけると思います。 パッチを適用するということは、今までのサービスに変更を加えるということです。 これまで動いていたサービスが落ちる可能性がありますし、慎重な対応をしなければなりません。

マイナーバージョンであれば(多少は)気楽にできるかもしれませんが、 メジャーバージョンのアップデートだった場合、公式のマイグレーションプランや アップデート内容の精査を行い、プロダクトに影響がないことを確認した上で、 マイグレーションプランに沿ってアップデートを実施する必要があります。 例えば廃止されたメソッドの置き換え、依存の解消などです。

ただ、中にはマイナーバージョンでも破壊的なアップデートが含まれていることもありますし、 アップデートしたにも関わらず脆弱性が治っていないということもありえます。

パッチ適用によるデグレやサービス提供上の問題解消

これは一つ前のもので触れましたが、アップデートを行うということは、 サービスに変更を与えるということです。 アップデートを慎重に行わないとサービス提供に問題が発生する場合があります。

攻撃が既に確認されている場合、サービス提供停止判断(とその説得材料集め)

これも難しい問題で、解がありません。

「世間一般で攻撃が起きてるぞ」という情報を知った場合、「攻撃をされた場合の影響度」などを踏まえて、「サービスを一旦停止し、パッチを適用したい」とチーム内や上司と議論することがあるかもしれません。 しかし上司や上層部にはどう説明すれば良いでしょうか? 上司や上層部は何を持ってサービス停止を許可すればよいでしょう? 果たして「攻撃されると全データが漏洩する!」「1回のリクエストでサービスがダウンする!」といった説得で十分でしょうか。正直それだとまともな交渉をできないはずです。 サービスを停止するということは、その分の機会損失などが発生するわけです。 そういった要素を丸っとまとめて納得してもらうのは至難の業です。

「じゃあ攻撃されるパーセンテージを出せばいい!」と言うのは悪魔の証明なので無理でしょう。 かと行って判断軸がしっかりと定まっていない状態では決められません。 そこで、予め「どのレベルの問題であれば強権を発動してサービス停止をするか」と言ったことをあらかじめ決めておくと、問題が発生した際に対処がスムーズに進むと思います。 これは色々な視点を含めて総合的に決めるとよいと思います。 例えばアタッカーサーフェース・脆弱性の発見しやすさ・CVSSの内容・脆弱性の内容・漏洩するデータ・脅威の多さや能力、 これらの情報をもとに「自社としてどこをベースラインとするか」を決めることが大切です。

ベースラインについて考えたことも無いと言った方は、是非OWASPの脅威モデリングのページなどに目を通してみてください。 この中にはリスクを洗い出すためのDREADと呼ばれる評価手法などについて書かれており、 リスクにおける要素に何があるのと言った外観が多少見えてくるかもしれません。

https://en.wikipedia.org/wiki/DREAD_(risk_assessment_model) https://owasp.org/www-community/Application_Threat_Modeling (少し前までOWASPにも載ってたのですが今は見当たらない・・・)

もちろんその他にも脅威モデリングフレームワークはあるため、どれを使うのはお好みだと思います。

ただ忘れてはいけないのがビジネスあってのセキュリティです。 資産が無いところにセキュリティはありません。 適切で現実的なベースラインと運用設計をすることが重要だと自分は思っています。

パッチ適用のためのベースラインを決める

一つ前で脆弱性評価におけるベースラインについて記載しました。 ただ、流石に「脅威モデリングのページ読んでね」では雑かもしれないため、自分の考える要素の一部を軽く書いてみます。

  • 危険度
  • 脆弱性のパターン
  • POCコードの有無(流通)
  • 世間の話題性
  • 自社のアタッカーサーフェース
  • 攻撃された際の損失のでかさ
  • (危険度などに対する)対応までの時間

上記を読むと感のいい人ならわかると思いますが、実は先ほど貼ったOWASPに記載されている脅威モデリングの手法(DREAD)に出てくる要素と殆ど同じです。 DREADでは、以下の要素を元にリスク値を割り出します。

ダメージ・再現の容易性・攻撃のための専門知識の必要度・影響度・脆弱性の発見容易性

結局のところ既存のフレームワークに乗っ取ろうと、リスクを評価する際に出てくる登場人物と言うのは概ね変わりません。

こうみるとリスク評価とその指標作りは、登場人物の少なさから簡単にできるように思えますが、 やってみると思ったよりも手こずると思います。

例えば、軽くベースラインを作って見た後に、次の質問内容をベースラインに適用してみてください。

  • DoSと情報漏洩ならどちらが危険ですか? (おそらく世界中全てが「情報漏洩の方が危険」と言わないでしょう)
  • JenkinsでRCEの脆弱性が出ました。でも社内のJenkinsは外部に露出していません。何日以内に直しますか?
  • RCEが出ました。でもサービスの奥深くで1箇所だけ利用している機能の中で利用されたメソッドをが原因で侵入し辛い箇所です。いつ直しますか?

おそらく複雑な条件が混じってきた場合、ベースラインの適用と評価だけでも時間がかかったり、そもそも判断がつかないと言った状態になると思います。 そのため、これらをある程度理解して深掘りし、適切で「現実的」に運用が可能なベースラインを敷くことが重要だと自分は考えています。 もちろんこの「現実的」かどうかは事業や会社の規模・風土などで大きく変わるはずなので私から「これが答えだ」とは明言できません。 なので強い気持ちで「これがルールだ」と決めるしかないです、誰も決めないのであれば。

ベースラインをあまり考えず、CVSSの点数による一律の評価を行うと言った手法も存在します。 ただ、個人的にはこれはあまりオススメできません。多くの会社ではおそらく運用が回らなくなって失敗する気がします。 CVSSのみにこだわった評価でパッチ管理を行うと、 アタッカーサーフェースの考慮や攻撃コードの有無、攻撃者に見つかる可能性などの観点が抜け落ち、 おそらく開発現場に負荷がかかりすぎるはずです。 なんせ毎日何十という数のRCEが出てるわけなので、とにかく毎日パッチ祭りということになりかねません。 (とはいえ、CVSSのみの運用は評価コストは低かったり、絶対に入らせないと言う考え方でベースラインを高めにできるのでメリットはもちろんあります。これも一つの選択です。)

脆弱性は全てを即座に治せればいいんですが、結局は限度のあるリソースをうまくやりくりしてビジネスを継続しながら対応すると言う事になると思います。 全てが治ることは大変良いことですが、ビジネスを停止させる事や現場の負荷、そして会社としてのリスク評価などを天秤にかけ、正しく運用することが重要です。

もちろん業態業種によっては受託と言った形態もありますし、一概に全てこうだとは言いません。 しかしながら脆弱性対策は一つの品質要件として必須になっている現在、ここを決めなければどの業態だろうが一定のレベルの品質を担保するのは不可能ではないかと思っています。

以上、非常に難しい話ではありますが、現実的に可能な範囲でベストな選択ができるような運用方針を立てると良いと思います。 まとめると、脆弱性を軸に各要素を多角的にみてルールなどを設計していく必要があるわけです。

パッチとPoC、PoC評価

一つ前のところで(現実的に運用できる)ベースラインを作ると良いと書きました。 では、開発運用を実施する部門(または自部門)にとって「ベストなリスク評価」とは何でしょうか? 個人的には、攻撃可能性や脅威モデリングなどが全て終了した状態が最も良い状態だと思います。 そこまでいくとかなり正確なリスク評価が行え、ビジネスオーナーなどが対応判断をある程度適切にできるようになるはずです。

しかし、攻撃可能性などの情報洗い出しや、脅威モデリングなどは時間やスキル・知識がかなり必要となってきます。 その上、そこまで行っても「直せば終わり」という結論に至るかもしれません。 結局これらの手法は会社などの風土やビジネスの領域によってアプローチが大きく変わってくると思います。

とは言え、対応方法を確立しておくこと・知っておくことは非常に有意義です。 これらのリスク評価手法の中には、PoCコードの評価などももちろん含まれてきます。 先ほど書いたようにPoCコードがあるということは、それだけ攻撃を受ける可能性があるわけです。 また、PoCコードが本物であることがわかれば、大胆に検証サーバなどに適用し、サービスが攻撃を受ける可能性をより適切に評価できます。 うまく行けばそれを元にWAFでシグネチャを組むことも可能です。 しかし、中にはPoCコードが実はマルウェアだったと言った話もあるため、検証は慎重に行わなければなりません。

PoCの評価では、実際に対象となるサーバや似た環境を用意し、そこにPoCコードを適用するのが最も一般的だと思います。 例えば安全なVM上やDockerコンテナの上に環境を用意し、その上で検証用のアプリケーションサーバを用意、PoCコードを使って攻撃できないか実施します。 (※VM, Dockerと言えども脆弱性が存在するケースがあるため、最新バージョンを利用するなど対策を講じてください。あと問題が起きても私は責任をとりません。) そもそもPoCコードを利用する場合、PoCが安全であるかちゃんとコードの中身などの情報を持って評価してください。そうしないと、ミイラ取りがミイラになります。 このあたりの設定はマルウェア解析+環境などで調べればそれ系の環境設定が出てくると思いますので参考にしてみると良いと思います。

PoCの探し方は色々ありますが、ざっくりと探すなら以下の手順でPoCコードを探すのが一般的だと思います。

  1. TwitterでCVE番号 + PoC (Exploit) などで検索
  2. Exploit DB というサービスでCVE番号の検索

他にも有名な攻撃コードを配信しているサービス・コミュニティがありますが、本記事では上記に留めておきます。 おそらく上記手順だけでも情報収集としてはある程度効果が見込めるはずです。

さて、PoCの有無がわかったらあとはCVSSの情報である程度情報が整います。 なんども言いすぎかもしれませんが、 CVSSなどを見る際に重要となってくるのは「自社でどこまで見るかというベースライン」です。 内部犯行も考えるか、脅威モデリングまで厳密に行うか、自社で一番大切な要素は何か(機密性?完全性?可用性?それともその他のセキュリティ7要素?)。 これらの内容をもとにCVSSを分解して見ていき、どの要素をパッチ管理のフローの中に組み込むか考えましょう。
https://www.ipa.go.jp/security/vuln/CVSS.html

エンジニアでしたら、CVSSにどう言うものがあるかを把握しておくだけでも大変有用であると思います。 考えながら見ると「これはちょっと評価軸としては冗長化かな(ヘヴィかなー)」とか思いつくと思います。

CVE情報の収集

脆弱性情報の収集には色々な方法があります。 パッと思いついてすぐ試せるものだと以下あたりがあります。 (ほかにも色々なリソースがありますが、取っ掛かりとしてはいかが良い気がします)

NVDのCVSS RSS (これをSlackのRSS Appなどで流すだけ)
https://nvd.nist.gov/vuln/data-feeds#JSON_FEED

CVE Searchツール
https://github.com/cve-search/cve-search
https://github.com/Beyarz/Cve-api

この辺りを使いながら全件読んだり、対象となるモジュール名などで検索フィルターするようにすれば脆弱性情報の収集はある程度のところまで行くはずです。

さて、脆弱性情報の収集とそれに関する評価をしたら次は是正管理です。 脆弱性、言い換えてインシデントとしましょう。インシデント管理となったら色々なものをまとめなければなりません。 そもそもインシデントにも色々な種類があります。 例えば言葉の通り「アクシデント」、そのほかに「脆弱性診断結果」「ZeroDay(パッチがまだ配布されていない状態での攻撃コード公開)情報」「外部からの脆弱性報告」「バグバウンティ」と言ったものなども入ってくるはずです。 それらをうまくまとめ、是正やリスク低減措置の実施を確認・管理しなければなりません。

と、ここまでさも知っている風に書きましたが、お恥ずかしい話、自分はこのあたりは非常に知見がなくそこまでいいことを書けません。 なので誰かがいい記事とか知見をまとめてくださる(URLを送ってくださる)と思います。 多分ITILとかにその辺りにインシデント管理として出てくる内容なので是非誰か良い記事をください。

前に読んだドキュメントとしては、この辺りが素人目線では綺麗にまとまっているように感じられました。 https://response.pagerduty.com/

脆弱性のパターンとレイヤー

Webアプリケーションで脆弱性が発生する場合、多くは以下のようなレイヤーに分かれると思います。 この脆弱性の発生箇所をレイヤー分けした図は割と重要で、アプリにおけるリスク低減をする際は、頭の片隅に置いておいた方が良い内容だと思います。

^
| ビジネスロジック
| ライブラリ・フレームワーク
| ミドルウェア
| OS
v

例えば何かの脆弱性が発生した場合、アタッカーサーフェース的に見てどの層が影響するのかと言った観点、 ほかにも脆弱性診断を行う場合、どの層に特に効果があり、どの層の脆弱性は検出しにくいかと言った観点です。

例えば脆弱性診断で一番検知しやすいのはビジネスロジックとライブラリ・フレームワークで実装されたの箇所です。 つまり「ライブラリ自体・フレームワーク自体」「ミドルウェア・OS」の脆弱性の多くは検知されません。 理由としては、脆弱性診断の多くはあくまでブラックボックスでのテストであり、後ろに何が動いているかを知らない状態でのテストをするためです。 しかし、脆弱性が見逃された場合、BOT型の攻撃が発生した場合に侵入されるかもしれません。

そのためリスク低減策がどの層(エリア)に特に効果があるかを考えながら実施していくと良いと思います。 個人的には「脆弱性診断によってビジネスロジックの多く・ライブラリとフレームワークミドルウェアの一部」をカバーし、 そこから漏れた箇所は「バグバウンティ」「ペネトレーションテスト」をうまく活用していくのが効果的なリスク低減策だと考えています。 ただバグバウンティとかに軽い気持ちで突っ込むのは絶対失敗すると思うので、この辺りは当分先になりますが、別の記事にて...。 また合わせて今後の記事にて触れるWebアプリケーションの脆弱性対策周りの話で「そもそも脆弱性が起きないようにする」と言ったセキュリティレベルの底上げについて触れられればと思います。

おわりに

これだけガーーーーっと書きましたがあくまで所感をまとめただけのものです。 参考にするもよし、指差して笑うもよしです。

DevSecOpsという言葉が近年一人歩きしてる感じはあるので、うまいことまとめられるか今後が心配ですが、 いい感じにかければいいなという感じでゆっくり記事を書いていきます。

それにしても、まだ章組した内容のうち1割とかそれくらいだと思うと終わる気が一切しません・・・。

あ、それと本題なんですが、こちら自分の欲しい物リストです。 https://www.amazon.jp/hz/wishlist/ls/2UICHQMVQMTJP?ref_=wl_share