AS / FIELD NOTES SECURITY RE:THINK CHAPTER 01 / 問題提起 DIALOGUE MODE

SECURITY / SLIDE EDITION

なぜ日本で大企業のセキュリティ対応が全然進まないのか

BREAK THE LOOP

CHAPTER 01 / 問題提起

NEXT / → で、この章を始める

問題提起

侵害が続く。何が足りない?

疑問 / QUESTION

侵害のニュースが続いている。AI時代になっても、どうして対応が進まないの?

応答 / REPLY

製品か、人員か。それだけで考えると、本当のボトルネックを見落とす。まず、パッチを当てる現場から見ていこう。

今回たどる3つの問い
  1. 能力

    なぜ、直すだけのことができない?

  2. 動機

    なぜ、改善しなくても困らない?

  3. 環境

    何が変われば、動き出す?

さらに掘る この場面の詳細・原文

セキュリティ侵害の事案が多発しています。AI時代でもなぜセキュリティ対応が全然進まないのか説明していきます。

CHAPTER 02 / 17

EXECUTION

セキュリティ能力というよりIT実行能力がない

NEXT / → で、この章を始める

セキュリティ能力というよりIT実行能力がない

見つける人と、直す人は違う。

疑問 / QUESTION

セキュリティ担当を増やせば、パッチ対応は速くなる?

応答 / REPLY

発見や調整は強化できる。でも、実際にシステムを変更するのは開発・運用。詰まっている場所が違う。

パッチは誰が当てる?
  1. セキュリティ部門

    脆弱性情報を集める/対応を調整する

  2. 開発・運用部門

    影響を調べる/修正する/適用する

最優先でも、1週間〜1ヶ月かかることがある。

さらに掘る この場面の詳細・原文

たとえばセキュリティパッチを当てるとしましょう。このとき、実はセキュリティエンジニアにできることは脆弱性の情報収集、パッチ対応の調整や取りまとめをするぐらいです。実際は運用部門、開発部門に対応が委ねられます。該当脆弱性が実際に影響あるかどうかの調査すら現場が行うことがほとんどです。

このとき仮に最優先だったとしても対応に1週間-1ヶ月かかるのはザラです。 こんなに時間がかかるのはセキュリティ能力ではなく、IT実行能力が欠如しているからです。セキュリティ関係に限らずなにをやっても1週間-1ヶ月単位でかかるため。 優先順位の理解不足のパターンもありますが純粋に工数、人員に余力があってもこれだけかかります。

セキュリティ能力というよりIT実行能力がない

では、現場に人を増やせば?

疑問 / QUESTION

現場の人手を増やせば、速くなるんじゃない?

応答 / REPLY

余力があっても、変更のたびに調べ直し、申請し直すなら時間はかかる。騒ぎになってから動くのではなく、常時更新できる仕組みが必要。

変更のたびに、この道を通る
  1. 調査

    対象の資産・影響を調べ直す

  2. 手順書

    作業方法を人が書く

  3. 申請

    関係者と調整し直す

  4. 手作業

    人がパッチを適用する

  5. 目視確認

    人が結果を確かめる

資産情報・構成管理・テスト・デプロイを、機械で扱える状態へ。

さらに掘る この場面の詳細・原文

そもそも脆弱性がネットで騒ぎになってからパッチを当てるのでは遅く、常時パッチを当てるのが適切です。これは今現在セキュリティにかけている(かかっている)お金の問題ではなく汎用的なIT実行能力の問題です。

パッチ適用に毎回、対象の調査、手順書作成、申請、手作業、目視確認が必要なら、人員に余力があっても時間はかかります。資産情報、構成管理、テスト、デプロイなどを機械で扱える状態にしていないので、変更するたびに人が調べ直し、調整し直すことになります。設計が貧弱で扱う資産の範囲を狭められてないのもそうでしょう。

セキュリティ能力というよりIT実行能力がない

AIの前に、IT部門のIT化。

疑問 / QUESTION

AIを使えば解決……という前に、開発の工程に問題がある?

応答 / REPLY

IT企業でも、IT部門自体のIT化が遅れている。コードの脆弱性も、最後に専門家がチェックすれば済む話ではない。

後から探すか、工程で防ぐか
  1. 最後に検査

    できあがったコードから穴を探す。見つかっても、手戻りは大きい。

  2. 最初から設計

    設計・実装の段階から安全性を作る。検査だけに頼らない。

さらに掘る この場面の詳細・原文

AI以前にIT部門のIT化が進んでないことが多く、IT企業でもIT化が遅れていることがよくあります。

コーディングもそうです。セキュリティエンジニアを集めてもコードのチェックぐらいはできますが、そもそもコードに脆弱性がある時点で取り返しがつきにくい。

セキュリティ能力というよりIT実行能力がない

検品だけでは、守れない。

疑問 / QUESTION

チェックを強化するより、最初から安全に作るべきということ?

応答 / REPLY

基本的な安全な実装ができないまま開発を続けるのは、穴の空いたバケツに水を注ぐようなもの。設計や設定も同じだ。

品質は、工程で作り込む
核心 / THE POINT

セキュリティだけを、後付けで強くはできない。

  1. 大量生産の検品との違い

    不良品を弾き、返品でカバーする方式を、一品物のシステムにそのまま持ち込めない。

さらに掘る この場面の詳細・原文

セキュリティも検査ではなく工程で作り込む必要があります。基本的なセキュリティコーディング能力が欠いたエンジニアに開発させるのは穴が空いたバケツに水を溜めるようなものです。 セキュリティコーディング能力からおおよそ開発者の能力が推定できるでしょう。 コーディングだけではなく設計や設定も同じです。セキュリティのようなサブ分野であっても重要なシステムを興味持ってまじめにやっていれば自然と学んでいくものです。

大量生産型の製造業であれば、品質管理の一つの方法として生産にはコストをかけず検品で弾いたり返品でカバーする方式もありえますが、一品物でそれは不可能です。

セキュリティ能力というよりIT実行能力がない

日常の兆候を、誰が見ている?

疑問 / QUESTION

ログや請求書を見るような、日常の運用はどう? 専門家に任せればいい?

応答 / REPLY

ログ・メトリクス・請求書は、日常的に見るもの。請求書から侵害に気づくこともある。でも、そもそも見ていなければ始まらない。

特別な装備の前に、日常の運用
  1. LOG

    システムで何が起きているか

  2. METRICS

    いつもと振る舞いが違わないか

  3. BILLING

    想定外の利用が発生していないか

一方、セキュリティ専門家にも開発・運用の知見が足りないことがある。

さらに掘る この場面の詳細・原文

ログやメトリクス、請求書の話もしましょう。これらは日常的に重要なもので、システムを活用するうえで定期的に見るべきものです。クラウドの請求書から侵害に気づくことも可能です。が、そもそも誰も見てません。

逆に、セキュリティエンジニアはセキュリティ対応ばかり行うため、開発や運用に対する知見が欠けている事が多いです。

セキュリティ能力というよりIT実行能力がない

両方わかる人が、足りない。

疑問 / QUESTION

開発とセキュリティ、両方がわかる人はどれくらいいると思う?

応答 / REPLY

開発とセキュリティは分断されがち。両方を理解する人は希少で、取り合いになる。次の数字は統計ではなく、経験に基づく推測。

日本にどのくらいいるか:統計ではなく推測
  1. 3桁人ぐらい?

    開発を理解するセキュリティエンジニア

  2. 数千人ぐらい?

    セキュリティを理解する開発者

そうした人材は、大企業やその外注先には集まりにくい。

さらに掘る この場面の詳細・原文

残念ながらセキュリティエンジニアで開発を理解しているのは日本で3桁人ぐらいでしょうか。 開発者でセキュリティを理解しているのは数千人ぐらいかもしれません。

そしてそのような人たちは取り合いになり、大企業や開発運用の外注先企業で働くことはありません。

セキュリティ能力というよりIT実行能力がない

一人の実力では、持ち込めないもの。

疑問 / QUESTION

なら、Googleで実績のある人を一人採用すれば変わる?

応答 / REPLY

Googleで実績があっても、前職の環境までは持ってこられない。組織改革まで一人に背負わせれば、成果も定着も難しくなる。部長や役員でも同じ。

採用で手に入るもの/入らないもの
  1. 本人の経験・能力

    優秀な人は入ってくる。

  2. 組織の実行環境

    権限・開発基盤・契約・評価制度は、そのまま。

さらに掘る この場面の詳細・原文

仮にGoogleで実績のあるエンジニアが一人入社してくれたとしても、権限、開発基盤、契約、評価制度といった環境まで一緒に入ってくるわけではありません。本人の成果にも限界があり、組織を変える仕事まで背負わせれば定着も難しくなる。部長や役員クラスでも同様です。

CHAPTER 03 / 17

CONFLICT

関係者それぞれの事情

NEXT / → で、この章を始める

関係者それぞれの事情

必要だとしても、自分の仕事?

疑問 / QUESTION

現場や外注先は、なぜ自分から動かないの?

応答 / REPLY

現場には目の前の仕事がある。外注先には契約と収益の事情がある。重要だと伝えるだけでは、このずれは埋まらない。

それぞれの事情を並べると
  1. 現場

    目の前の仕事が最優先。事業影響は把握しにくく、提案も苦手。ITに関心のある人は少数派。

  2. 開発・運用外注先

    契約にない仕事は、収益となる工数につながらない。対応は契約上の最低限に寄る。

さらに掘る この場面の詳細・原文

現場:セキュリティの重要性を理解していない。脆弱性がビジネスに与える影響までは把握は困難。目の前の仕事が一番大事。提案は苦手。ITに興味がある人は少数派。

開発/運用外注先:セキュリティ関係をやる動機が文字通りなにもない。収益となる工数とは無関係のため。契約にあれば最低限対応するぐらい。

関係者それぞれの事情

指揮する側も、現場が見えない。

疑問 / QUESTION

セキュリティ部門やCIOが、そこを動かせない?

応答 / REPLY

開発・運用をどう動かすかの像がないと、実行力を損なわずに安全性を上げる提案ができない。強く反論されれば、そこで止まる。

司令塔にもある断絶
  1. セキュリティ部門

    開発・運用のイメージが薄い。IT実行力と安全性を一緒に高める提案が苦手。

  2. CIO

    実際に対応した経験がなく、何をすればよいか像が結びにくい。

さらに掘る この場面の詳細・原文

セキュリティ部門:IT実行能力を損なわずにセキュリティを強化する、むしろ両方強化するといった提案は苦手 開発/運用のイメージがない。逆に強く出られると止まってしまう。 セキュリティに興味がある人は少数派。

CIO:セキュリティ対応を実際にやったことがないので何もイメージが付かない。

関係者それぞれの事情

指摘した人を、敵にしない。

疑問 / QUESTION

悪い診断結果を突きつけられたら変わる? 外部の指摘にはどう向き合うべき?

応答 / REPLY

私の見る限り、悪い診断結果でも自発的に動く人は少ない。職業上の誇りや顧客への責任感だけに期待できない。だから、問題を向ける先が重要になる。

「できない理由」の向け先
  1. 外部に反論する

    現場が一緒に、指摘した人を敵に回す。

  2. 経営に働きかける

    できない理由が事実なら、経営に環境の改善を求める。外部には応援してもらう。

それでも変わらないなら、退職を選ぶのがよい。

さらに掘る この場面の詳細・原文

私が見る限り、プロフェッショナルとして恥ずかしいであったり、お客さんに申し訳ないという気持ちを持ったりする人は少数派です。クラフトマンシップは貴重で、史上最低クラスの脆弱性診断結果をつきつけられても特に自分からなにかする気はない人が多数派。

外部に対して、現場が一緒になってできない理由を反論するのはよくない傾向です。内容は事実なのだからそれを経営レイヤーに働きかける、それでも変わらないなら退職するのがよいでしょう。外部の人を敵に回すのではなく応援してもらう。

CHAPTER 04 / 17

NO FIX

セキュリティエンジニアやセキュリティ製品を増やせばよいのか

NEXT / → で、この章を始める

セキュリティエンジニアやセキュリティ製品を増やせばよいのか

増やす場所を、間違えない。

疑問 / QUESTION

セキュリティエンジニアや製品を増やすのは、解決にならない?

応答 / REPLY

詰まっているのはIT部門。セキュリティ部門だけを増やしても、調整の先にある作業は速くならない。

増強すべきは、ボトルネック側
核心 / THE POINT

装備の数と、変更を届ける力は別。

  1. 予算・人員の見方

    セキュリティの費用や人数は、IT全体の費用・人員に対する割合で妥当性を考える。

さらに掘る この場面の詳細・原文

上記の通りボトルネックはセキュリティ部門ではなくIT部門です。 セキュリティコストや人員はおおよそITコストや人員に対する割合で妥当性が決まります。

CHAPTER 05 / 17

SELECT

外部プロダクトの選定能力が弱い

NEXT / → で、この章を始める

外部プロダクトの選定能力が弱い

選ぶ道具に、能力が出る。

疑問 / QUESTION

外部ツールからの漏洩も多い。製品の選び方に問題がある?

応答 / REPLY

マイナーな外部ツールからの漏洩も目立つ。安全性以前に、なぜそれを選んだのか。選定する能力も、IT能力の一部だ。

専門家は、付き合う相手も見る
  1. 外部ツール

    利用目的に対して、なぜその製品なのか。

  2. ベンダー・外注先

    誰に何を任せているかにも、選定側の実力が表れる。

さらに掘る この場面の詳細・原文

実際のニュースを見ているとマーケティングなどに利用しているマイナーツールからの漏洩も目立ちます。 セキュリティ面を除外してもなぜそのツールを選んだのか選定に疑問を感じます。

セキュリティに限らず、基本的に選定するもの、利用する道具で能力が見えます。付き合ってるベンダーだけで実力が推定できるでしょう。これは他の部門でもあっても同様で、どの専門でも専門家なら外注先を見れば実力がどのランクかわかるものです。

外部プロダクトの選定能力が弱い

選び直すにも、実行力が要る。

疑問 / QUESTION

問題のある製品なら、乗り換えればいいのでは?

応答 / REPLY

その乗り換えを実行するのもIT部門。問題のある道具を選んでしまう組織は、そこから抜け出す段階でも同じ能力を問われる。

気づいたら終わり、ではない
  1. 選ぶ

    外部プロダクトを選定する

  2. 気づく

    選定に問題があったとわかる

  3. 乗り換える

    ここでも、IT実行能力が必要

さらに掘る この場面の詳細・原文

そして乗り換えにもIT能力が必要なのが難しいところです。

CHAPTER 06 / 17

BLIND SPOT

セキュリティプロダクトも同じ

NEXT / → で、この章を始める

セキュリティプロダクトも同じ

売る側も、事業をしている。

疑問 / QUESTION

セキュリティ製品を作る会社なら、自社のセキュリティは万全?

応答 / REPLY

セキュリティ製品もプロダクト開発の一種。目の前の開発が優先される事情は同じで、製品自身の安全性が弱いこともある。

製品の目的と、開発組織の実力は別
  1. 売っているもの

    セキュリティ対策のための製品

  2. 作っている組織

    納期や事業上の優先順位を持つ開発組織

さらに掘る この場面の詳細・原文

セキュリティ関係のプロダクトもプロダクトであり、プロダクト開発の一種です。 結局ビジネスであり、セキュリティ対応より目の前の開発が優先されるでしょう。セキュリティプロダクトのセキュリティが貧弱なのはよくあることです。

CHAPTER 07 / 17

NO PRESSURE

ITでは競争優位性を生み出さない。IT能力がなくても困らない

NEXT / → で、この章を始める

ITでは競争優位性を生み出さない。IT能力がなくても困らない

変わらなくても、組織は続く。

疑問 / QUESTION

そもそも、IT能力を上げようという圧力が弱いのはなぜ?

応答 / REPLY

日本の大企業同士の国内競争では、ITで差をつける圧力が弱い。株主からの効率・競争力への要求も弱ければ、改革は進まない。

能力を上げる動機が生まれにくい
  1. 競争圧力が弱い

    ITで抜き出す必要が小さい

  2. 改革を求められない

    効率や競争力への要求も弱い

  3. 今のまま続く

    本当は、特に誰も困っていない

さらに掘る この場面の詳細・原文

日本国内だけの日本の大企業同士の競争だとITで抜き出たところで差が生まれません。 そもそも株主からも経営効率の向上、競争力の向上が求められていません。

そのため改革が進みません。今のままでも本当は特に誰も困っていません。

CHAPTER 08 / 17

COMPLEXITY

多角化、非中核事業の多さ

NEXT / → で、この章を始める

多角化、非中核事業の多さ

事業が広がる。守備範囲も広がる。

疑問 / QUESTION

多角化や非中核事業の多さも、セキュリティに響く?

応答 / REPLY

非中核事業は刷新が後回しになる。撤退・売却・統合もなければ、古いシステムを維持する仕事が残り、中央のセキュリティ部門まで疲弊する。

優先されない仕事が、消えずに積もる
  1. 古いシステム

    刷新されず、維持する対象が残る

  2. 異なる業務要件

    必要な水準が違い、複雑さが増す

  3. 広すぎる範囲

    中央で一括対応しようとしても足が止まる

さらに掘る この場面の詳細・原文

非中核事業だと刷新は優先されにくいでしょう。撤退・売却・統合もしなければ、古いシステムを維持する仕事が残り続けます。範囲が広すぎて中央で対応するセキュリティ部門も疲弊します。とくに業務要件や必要なレベルが異なると複雑性が広がって足が止まります。

CHAPTER 09 / 17

LOOP

セキュリティインシデントが発生しても何も変わらない

NEXT / → で、この章を始める

セキュリティインシデントが発生しても何も変わらない

事故のあとも、元のループへ。

疑問 / QUESTION

インシデントで業務が止まったら、さすがに抜本的な改革が進むのでは?

応答 / REPLY

業務停止が起きても、ITの段階が抜本的に進化するとは限らない。強い顧客関係や、事実上の独占で代替がなければ取引は続く。

事故だけでは、環境は変わらない
  1. 侵害・業務停止

    事業が止まる

  2. それでも取引継続

    関係が強い/替えがない

  3. 改革圧力は弱いまま

    抜本的なIT刷新にはつながらない

さらに掘る この場面の詳細・原文

最近はセキュリティインシデントで業務が止まる事案が発生するようになりました。が、抜本的なITステージの進化にはつながっていません。

インシデントで事業が止まると取引がなくなりそうなものですが、日本ならではの顧客との関係の強さもあれば、事実上独占による弊害もあるでしょう。替えがないので継続されます。

CHAPTER 10 / 17

TRIANGLE

不正のトライアングル: 動機、機会、正当化

NEXT / → で、この章を始める

不正のトライアングル: 動機、機会、正当化

先送りを支える、3つの条件。

疑問 / QUESTION

この先送りの構造を、整理するとどうなる?

応答 / REPLY

古典的な「不正のトライアングル」を借りて整理すると、動機も、実行力も弱い。そのうえ、放置を正当化する理由がそろっている。

不正のトライアングルを、対応の停滞に当てはめる
  1. 動機・プレッシャー

    放置しても責任を問われず、取引や組織が維持される。

  2. 機会・実行可能性

    必要性がわかっても、IT能力がなく実行できない。

  3. 正当化

    「忙しい」「リソースがない」「事業優先」「契約外」「他社も同じ」

さらに掘る この場面の詳細・原文

セキュリティということで古典的ですが不正のトライアングルを使い検討してみましょう

不正のトライアングルと、対応が進まない条件
要素セキュリティ対応が進まない条件
動機・プレッシャー対応を放置しても責任を問われず、取引や組織も維持されるため、改善への動機・圧力が弱い
機会・実行可能性IT能力が欠如し、必要性を認識しても改善を実行できない
正当化「現場は忙しい」「リソースがない」「事業優先」「契約にない」「他社も同じ」で先送りを容認できる

CHAPTER 11 / 17

AI ≠ ORG

AIでどうなるか

NEXT / → で、この章を始める

AIでどうなるか

生成する力と、届ける力は違う。

疑問 / QUESTION

AIは、エンジニアの能力や組織の実行力を変えられる?

応答 / REPLY

AIは速度だけでなく成果の質でも、多数のエンジニアを上回っていると考える。でも、人・組織・プロセスの問題まで導入だけで解けるわけではない。

AIで変わる領域/そのまま残る領域
  1. 成果物を作る力

    製品管理・要件定義・信頼性・品質保証・性能・可読性・使いやすさ・安全性。

  2. 組織を動かす力

    権限・契約・プロセス。エージェントの利用すらできない企業もある。

約9割を削減し人員を入れ替えれば可能性はあるが、現実的ではない。

さらに掘る この場面の詳細・原文

率直に言えば日本の大多数を占めるITエンジニアよりフロンティアモデルのほうが速度だけではなくアウトプットの質でも上回っています。もう少し具体的には製品管理、要件定義、信頼性、品質保証、パフォーマンス、可読性、ユーザビリティ、セキュリティのいずれにおいても、AIに敗北しています。ただ、コーディングエージェントが利用できない会社も多くあるのでそのような組織はしばらく低調なままでしょう。

一方で、IT実行能力は組織や人、プロセスの問題であり、AIでは解決の見込みがありません。9割近くの人員をカットしつつ人を入れ替えたりすれば可能性はありますが現実的ではないでしょう。

AIでどうなるか

AIが進んでも、同じ場所にいる?

疑問 / QUESTION

組織が変わらないなら、この先も同じことが続く?

応答 / REPLY

人や組織の入れ替えが非現実的で、外からの圧力もないなら、侵害と漏洩は続く。10年後も変わらないのではないか。

技術の進歩だけでは、変化の根拠にならない
  1. 20〜30年以上

    この間、根本の構造は変わっていないと感じる

  2. 今回だけ変わる?

    このタイミングで変わる根拠がない

さらに掘る この場面の詳細・原文

現実的ではない以上、何も変わりません。相変わらず攻撃され続け、漏洩し続けるでしょうが誰も何も圧力をかけないので10年後も何も変わらないでしょう。経時的に言えば20-30年以上なにも変わってないのでその意味でもこのタイミングで変わる根拠がありません

CHAPTER 12 / 17

CHANGE

どのような条件なら変わるか

NEXT / → で、この章を始める

どのような条件なら変わるか

変える条件を、考え直す。

疑問 / QUESTION

では、どんな条件なら変わる可能性がある?

応答 / REPLY

問題はセキュリティ単体ではなく、環境。改善が必要になり、適切な実践が当たり前になる条件を考えよう。

可能性のある3つの入口
  1. 競争と新陳代謝

    古い企業の退出と、新規参入の増加

  2. 技術を理解する経営

    エンジニアリング能力の高い創業者

  3. 適切な規制

    力のあるプレイヤーによるルール

さらに掘る この場面の詳細・原文

セキュリティではなく、環境の問題です。いくつか可能性を考えてみました。

CHAPTER 13 / 17

NEW ENTRY

古い企業の倒産が相次ぐ / スタートアップ含めた新規参入企業が増加する

NEXT / → で、この章を始める

古い企業の倒産が相次ぐ / スタートアップ含めた新規参入企業が増加する

退出と参入が、圧力になる。

疑問 / QUESTION

古い企業の退出や、新規参入が増えたらどうなる?

応答 / REPLY

変わる可能性はある。古い企業の退出が進めば、古い組織やシステムが温存される状況も変わる。新規参入で競争が強まれば、既存企業も内部改革を迫られる。

温存される環境から、競争する環境へ
  1. 古い企業の退出

    組織とシステムが、永久に維持されるわけではなくなる。

  2. スタートアップなどの参入

    競争が強まり、変わらないことへの圧力になる。

さらに掘る この場面の詳細・原文

古い組織やシステムを保持しているから変わらないので、定期的になくなれば問題もなくなります。 プレッシャーが増えれば内部からの改革も進む可能性はあります。

CHAPTER 14 / 17

ENGINEER

エンジニアリング能力が高い創業者が増える

NEXT / → で、この章を始める

エンジニアリング能力が高い創業者が増える

当たり前を、当たり前にする。

疑問 / QUESTION

エンジニアリング能力の高い創業者が増えると、何が違う?

応答 / REPLY

実力のある創業者なら、適切な実践を自然に選ぶ。GitやCIのように、常識を採用するたびに疑いやROIの説明から始める必要はない。

エンジニアリング能力が、経営の前提になる
核心 / THE POINT

適切な実践を、毎回の説得から解放する。

  1. もっと簡単な特効薬は?

    あるなら、とっくに変わっているのではないか。安易な近道には期待できない。

さらに掘る この場面の詳細・原文

実力がある人は自然と適切なことを行います。GitやContinuous Integrationも今では常識です。 常識をいちいち疑ったりROIを求める人はいません。

もっと簡便で効果がある特効薬はないのか?という質問もあるでしょうが、あったらもうとっくに変わっているのではないでしょうか。

CHAPTER 15 / 17

DOUBLE EDGE

規制による推進

NEXT / → で、この章を始める

規制による推進

規制は効く。間違えれば、逆効果。

疑問 / QUESTION

規制で進める手はある? 間違ったルールを作る危険は?

応答 / REPLY

国・業界団体・大手企業のルールには力がある。ただし、誤ったルールを強制すれば悪化する。規制は作って終わりではない。

規制の推進力と、誤った規制の危険
  1. 変化を強制できる

    仮にPHP製品との取引を禁止したら、脱却は進むだろう。ほかに、パスワードのメール送信禁止。

  2. 古い常識も固定してしまう

    パスワードの定期変更が例。ガイドラインが古ければ悪影響が広がる。

規制・ガイドラインは、半年単位で見直す必要がある。

さらに掘る この場面の詳細・原文

たとえばPHPを利用しているプロダクトは取引禁止となれば、PHP脱却が一気に進むでしょう。パスワードのメール送信禁止などもそうです。 国や業界団体、業界大手など力のあるプレイヤーによる規制は効果的です。 ただし規制は諸刃の剣で、誤った規制内容だと悪化する可能性はあります。パスワードの定期変更問題が例として挙げられます。ガイドラインの内容が古ければ悲惨でしょう。半年単位での見直しが必要です。

CHAPTER 16 / 17

THE TRUTH

結論

NEXT / → で、この章を始める

結論

守りだけを、強くはできない。

疑問 / QUESTION

結局、何が根本の問題で、どうすべきなの?

応答 / REPLY

基礎的なIT実行能力を上げる必要がある。でも、それを上げる動機も環境も弱い。そこが変わらなければ、このままなのではないか。

問いの行き着く先
核心 / THE POINT

足りないのは、変更を届ける力。

  1. 能力がない → 動機がない → 変わらない

    セキュリティの問題を、セキュリティ部門だけの仕事に閉じ込めない。

さらに掘る この場面の詳細・原文

セキュリティ能力がない => セキュリティだけ挙げることはできない。基本的なIT実行能力がない => 能力をあげる動機がない => どうするか. どうしようもない

基礎能力をあげるべきだし上げないと無理です。でもできない、つまりこのままなのではないでしょうか。

CHAPTER 17 / 17

EVIDENCE

補足:セキュリティの能力を推定する方法

NEXT / → で、この章を始める

補足:セキュリティの能力を推定する方法

能力の兆候は、別の場所にも出る。

疑問 / QUESTION

最後に。外からセキュリティ能力を推定するなら、どこを見る?

応答 / REPLY

デザイン・UX・性能・ベンダーの選び方にも、共通のIT能力が表れる。特定分野だけが突出するとは考えにくい。

セキュリティ能力を推定する着眼点
  1. DESIGN / UX

    古い見た目や使い勝手

  2. PERFORMANCE

    他と比べて劣る性能、操作の遅さ

  3. VENDOR

    選んだ道具・付き合うベンダー

根本のインプット・解釈・反応の能力は、各分野に表れる。

さらに掘る この場面の詳細・原文

いろいろありますがデザイン、パフォーマンスからもわかってしまいます。 デザインやUXが古いものがセキュリティが高いことはありません。 パフォーマンスも同様です。比較してパフォーマンスが貧弱、操作して遅いならセキュリティも貧弱です。 記事に記載した通り利用しているベンダーも使えます。

これらはIT能力のランクを示しています。各ジャンルのうち特定のなにかだけ突出することはありません。ダメな奴は何をやってもダメという格言がありますが、これは根本的なインプット、解釈、反応といった能力が欠如している状態です。

END OF REPORT / FILE 788A6E9F

THEEND.

守る力は、
変える力から。

READ COMPLETE

STAFF ROLL

TEXT & DIRECTION
AS
ORIGINAL ARTICLE
なぜ日本で大企業の
セキュリティ対応が
全然進まないのか
EFFECT STUDY
桜井政博のゲーム作るには
8つのヒットストップ仕様 ↗

THANK YOU
FOR READING.最後まで読んでいただき、ありがとうございます。

CASE ARCHIVE / SECURITY RE:THINK

調査記録

FILE 01

原文 / SOURCE