読書メモ/「診断戦略: 診断力向上のためのアートとサイエンス」

医療関係者では無いのですが、Webの脆弱性の検査とかやってますので「診断」という技法それ自体は共通ではないかと思い、パクれる点は無いかな～と購入してみて、少しずつ、一年かけてゆーっくり読み終えました。

感想としては、おなじ診断業務ということもあり、いくつか参考にできそうな考え方がありました。
もちろん病気の鑑別とWebアプリの脆弱性の判定とで異なる部分も多々ありますが、著者の診断にかける真剣さや情熱は大いに共感できるところです。

ということで、いくつか「これは」と思った考え方やポイントを抜書きしてきます。さすがに業務内容に近い部分は書けませんが、一般論レベルで「診断ならこうだよな～」というのをコメントしてます。
なお、ここでのWeb脆弱性診断は基本的にブラックボックステストによる検査を想定してます。

System1(直観的診断), System2(網羅的・論理的・分析的診断), System3(ラテラル・アプローチ)

基礎的な診断戦略として、3種類が紹介されている。うち、System1(直観的診断), System2(網羅的・論理的・分析的診断)は昔からある戦略。System3が水平思考を活用した「ラテラル・アプローチ」で、最近出てきた戦略。

• System1(直観的診断) : 患者の見た目や訴える症状、実際に聴診や触診してみた結果など、すぐに分かる現象から診断につなげる。
  • メリットとしては迅速に行えるため、緊急性の高い外傷などで必要となる。また、すぐに鑑別できるような明確なものであれば、こちらの方が効率的。
  • デメリットとしては外部から見える・聞こえる・触れる現象のみを元にするため、診断員の思考にバイアスがかかり、誤った診断を下す可能性がある点。
  • 上記のような特徴から、主に経験を積んだ熟練者により運用される戦略。
• System2(網羅的・論理的・分析的診断) : 直観的な要素だけでは決めずに、漏れ無くロジックを組み立てて、この症状はどれに当てはまる・当てはまらないを緻密に判定していく。
  • メリットとしては網羅性が高いため、診断の抜け・漏れを抑えられる。
  • デメリットとしては十分な情報を集めるために過剰に検査をしてしまうなど、時間がかかる点。さらに集まったデータも膨大になりがちなので、データから鑑別に必要なものは何かを見抜く力も必要。
  • 上記のような特徴から、直観思考がまだ経験不足のため使えない、初心者が運用することが多い。
• System3(ラテラル・アプローチ)
  • 発想の転換で、今までとは違ったアプローチで診断に迫っていく。
  • 代表的な例が、直接患者に、何が原因だと患者自身は考えているのか聞いてしまう。
  • 患者に直接聞くメリットとしては圧倒的なスピードがある。
  • 患者に直接聞くデメリットとしては、患者の話にアンカリングされてしまい、バイアスとなってしまう。

System1/System2は、どちらかだけで診断を進められるというようなものではなく、System1で立てた仮設を検討するためにSystem2のフレームワークを使ったり、逆に、System2の結果からSystem1の直観的な思考がひらめくこともある。
System3は、上手くあつかうことで診断を効率化したり、System1/2とうまく連携できる。

System1(直観的診断)のポイント

1. 察知力 : KFD(Key fact for diagnosis)に気づく察知力
   1. 色々な初期状況のなか、どれが鑑別を決定するための決め手となる情報(KFD)かを見抜く直観力を育てる。
2. 姿勢 : 直観力を高めようとするマインドセット
   1. 失敗したからといって、「やっぱり直観力が無いんだ(´・ω・｀)」で終わらず、前向きに失敗を活かそうとうする姿勢。
3. 経験 : 量と質
   1. やっぱり経験値重要。また、他の同僚から話を聞いたりするなどして、知識を広げていくのもポイント。
4. フィードバック : 思考のバイアスで間違えてしまったことに気づけるか、気づいた後に、今後バイアスにはまらないようにするにはどうするか、など。
5. 試練 : この戦略を使わなければ切り抜けられないような状況への曝露。若いうちに苦労しておけ、という話。

経験とフィードバックについては、「診断エラーノート」というので診断の経験を蓄積していこう、というのが紹介されてました。

Web脆弱性診断の現場なら・・・

アプリの挙動から「このパラメータが怪しい」など見当をつけて、実際に検査するという、ヒューリスティック性の高い検査に相当すると考えられます。
パラメータの用途などを確認してから、それならこういう脅威は考えられないか？として、試すケースが多いと思います。

System2(網羅的・論理的・分析的診断)

直観的思考で上手く行かなかった場合に、System2の分析的思考の出番となる。

1. フローチャート、アルゴリズム、ディシジョンツリー
2. スコアリングシステム、診断クライテリア
3. Bayesの定理、オッズ、尤度比
4. 他のフレームワーク
   1. 階層型
   2. マトリクス型
   3. 時系列型
   4. グループ型
   5. 並列型

重要なのは分析的思考に切り替えるための質問、"Conquer BIAS" の語呂合わせ。

1. "Context" : 診断がその患者の病歴やバックグラウンドに沿っているか？
2. "Bias" : その診断仮説はバイアスがかかってないか？
3. "Input" : 情報のインプットは正しく、かつ十分か？
4. "Alternative/Additive diagnosis" : 他の診断ではないか？重複する診断ではないか？
5. "Script" : 診断の仮説でしっかりと説明できるか？

これらにより、バイアスを回避して、分析的思考と併せて診断の精度を高められる。

Web脆弱性診断の現場なら・・・

検査ツールなどを利用して、パラメータを網羅的に検査するのがこれに相当すると考えられます。
パラメータの値を不正な擬似攻撃用の値に改ざんして送信していきますが、パターンの質や量とサーバのレスポンスが、検査にかかる時間に直接反映されます。
また、ツールによる大量の通信結果を精査する必要があるため、ツールの検出特性や結果の見せ方(UI)が作業コストに影響してきそうです。

System3(網羅的・論理的・分析的診断)

患者に直接聞く、の他に、以下のような戦略が紹介されてる。

Pivot and Cluster Strategy(PCS) : ピボット・クラスター戦略

直観で鑑別した診断だけで終わらせず、臨床上の表現形が似ている他の診断を検討にあげ、その診断はありえないか検証する。
直観のスピードを維持しつつ、似たような表現形を持つ鑑別を漏らさないよう網羅性を上げることが出来る。
ただし、もちろん、ある症状から、それと似た表現形の病名を想起できないといけないので、相応の知識と経験は必要。

Horizontal-Vertical Tracing(HVT)

合併疾患をトレース、つまり水平方向での他の診断が一緒にできないか思考する。
さらに、疾患の原因に別の病気が存在するケースもあるため、垂直方向に疾患の原因を掘り下げていく。

Mesh Layers Approach (MLA)

上記までの複数の戦略を重ねて使い、絞り込んでいく。
さらに奥の手として、同僚や上級医に聞いてみる、ググる、など。

Web脆弱性診断の現場なら・・・

判定に直接結びつくわけではありませんが、レスポンスがひどく遅くなったりして、お客様にサーバの状況を確認するケースがあります。
また、もし陽性なら危険度が高いので指摘したいが、どうにもサーバの反応が曖昧で、白黒判別しきれない場合に、お客様に状況を伝えて、直接確認してもらうケースもまれにあります。
あまり遭遇したことのない独自性の高い機能で、どう脅威を考えれば良いのか分かりづらい場合、同僚や上級診断員と相談して知恵を借りる場合があります。

診断戦略をひらめく、イノベーション

• アブダクション : ふとしたきっかけで新しいアイデアがひらめく。
• 診断戦略カンファレンス : 診断事例や判定時の思考を共有するカンファレンスを開催する。
• 「なぜ」を日常的に考え、突き詰めて考える思考力を鍛えていく。
• 専門領域以外のことに目を向ける。別の分野の歴史や教養にヒントを得たりできる。
• 自分だけの時間を確保する。

Web脆弱性診断の現場なら・・・

• どうにもテストケースと脅威について思考が煮詰まってて、帰るために会社の扉を出た瞬間に「あ、あれってこういうことか！？」となることがよく有ります。
• あと、自宅でリラックスしてる時＝トイレやお風呂に入ってる時にアイデアが思い浮かぶ場合があります。
• 「なぜ」を突き詰めるのは、Webアプリの挙動を正確に把握するために必須です。また、どこからがわからないことなのか、をクリアにするためにも必要です。
• Webセキュリティの検査となりますと、やっぱりWebアプリの開発知識が必要になりますので、そちらの技術を追っかける必要があります。

病歴の技法

患者に病歴を聞くときの技法について、実践的なノウハウが紹介されています。

• 最初の30秒で患者の話を聞くときに集中し、患者に対する信頼感を醸成することに注力する。焦ってclose questionで鑑別に持ち込まず、open questionを駆使してKFDを引き出す。
• 患者の言葉を置き換えずに、他の医師と共有する。言い換えてしまうと、言い換えられた言葉で持って他の医師は思考を開始するため、患者の言葉ではなく、言い換えられた言葉の方に思考がアンカリングされてしまう。
• 患者に対する好奇心、「なぜ？」「どうして？」を大切にして、患者の理解に努める。
  • 信頼関係を醸成することになり、さらに患者からの情報提供が増え、KFDを得やすくなる。また、患者のメンタル面からの行動について納得が得られることが多く、それによる患者へのメンタル面でのケアにFBできれば患者の満足感も高くなる。

Web脆弱性診断の現場なら・・・

お客様のエンジニアと会話する場合に、こちらがセキュリティを監査する立場になりますので、上から目線になってしまったり、非難するような物言いにならないよう気をつけます。
お客様のエンジニアあってこそのセキュリティということですので、上下関係ではなく協力関係にある、という点をこちらも意識し、お客様にも意識させるような言葉遣いに気をつけます。

診断学の教育

こうした戦略を以下に駆使したり、思考力を鍛えるか。診断学の教育について、「カンファレンス」という形で部署内・院内などで知識や事例を共有するのが良いが、どのような運営の仕方をするか、によっても効率面で違いが出てくる。

• 知識共有型のカンファレンス：全員を一同に集めて共有するには、時間の拘束性と、人数が増えれば増えるだけ需要と供給のギャップが広がるなど、無駄が大きくなる。単に知識を得るだけであればネットの活用も進んでいるので、そちらに役割を移す方針もあり。
• 思考型カンファレンス：参加者に、実際に診断や鑑別について「自分だったらどうするか？」など考えてもらう形態。双方向的であり議論も引き出しやすいため、参加者を絞れば有意義なものとなりそう。

著者としては上記に加え、やはりベッドサイド教育、つまり実際に患者と相対して会話して思考していくのを推奨している。
さらに、診断に特化した部門を結成し、研修医の上に上級医を据えて監督した上で、ローテーションなどで事例を共有しつつ、診断技法を高めていく組織的なアプローチを考察している。

Web脆弱性診断の現場なら・・・

診断員の教育となりますと、最近ですとスキルマップが提案されたり活発です。
診断員自体が歴史の浅い職務ですので、これからどう教育や研修コースが整備されていくのか、これからの話になりそうです。

診断を困難にする"霧"への対処法

• ブイ(buoy)疾患：ある症状に対して、原因となる別の疾患が隠れているケース
• オッカムとヒッカムの切り替え：患者が若ければオッカムのルール、50代以降ならヒッカムのルールが当てはまりやすいが、例外もあるため、とらわれ過ぎない。
  • オッカムの剃刀：「説明に最低限必要でない余計な存在がある、そうしたものは不必要なものなのだからそぎ落とすべきである。」
  • ヒッカムの格言：「どの患者も偶然に複数の疾患に罹患しうるため、症状に対して複数の原因を探すべき」

Web脆弱性診断の現場なら・・・

ある現象にたいして、ある脆弱性を判定できたとして、じつは別の脆弱性でもあった、という合わせ技的な現象がママあります。
一個の脆弱性の判定で意識を止めてしまうと、さらなる問題の見当を見逃す場合もありますので、他の問題は無いか見当する必要があります。
例えば、エラーメッセージの詳細が出てるのでその問題を指摘してそこで終わりではなく、エラーメッセージの内容をよくよく見てみたらSQL文が含まれてて、それをヒントにSQLインジェクションを見つけられるケースが時々あります。

医療の診断現場と、Web脆弱性の診断現場ですが、かかるプレッシャーについては比べ物になりません。
とはいえ、プレッシャーの特性としての「網羅性の保証」や「漏れ・抜けに対するリスク」という特徴は似通っていますし、診断や検査という業務特性も似通っています。
そのため、よりプレッシャーの高い医療の診断現場の話は、Web脆弱性の診断に色々と応用が効きそうに思い、読んでみましたが、案外面白かったです。
著者の体験として、患者の訴えや聴診・触診結果、病歴などから思考を重ねて鑑別していくエピソードがいくつかありましたが、いずれも読んでいてワクワクしてくるような面白さを感じました。
恐らく当事者としても、患者と共同して診断を積み上げていき、治療を進めるのはやりがいと面白みのある部分なのだろうと推察いたします。

Web脆弱性診断の教育や研修を担当される方に、一読をオススメしたい一冊でした。

※なお、プレッシャー等についての心構えなどについてはこちらがオススメ。