SECURITY / SLIDE EDITION
なぜ日本で大企業のセキュリティ対応が全然進まないのか
BREAK THE LOOP
CHAPTER 01 / 問題提起
NEXT / → で、この章を始める
問題提起
02侵害が続く。何が足りない?
侵害のニュースが続いている。AI時代になっても、どうして対応が進まないの?
製品か、人員か。それだけで考えると、本当のボトルネックを見落とす。まず、パッチを当てる現場から見ていこう。
- 01
能力
なぜ、直すだけのことができない?
- 02
動機
なぜ、改善しなくても困らない?
- 03
環境
何が変われば、動き出す?
さらに掘る この場面の詳細・原文
セキュリティ侵害の事案が多発しています。AI時代でもなぜセキュリティ対応が全然進まないのか説明していきます。
CHAPTER 02 / 17
IT実行能力
EXECUTION
セキュリティ能力というよりIT実行能力がない
NEXT / → で、この章を始める
セキュリティ能力というよりIT実行能力がない
04見つける人と、直す人は違う。
セキュリティ担当を増やせば、パッチ対応は速くなる?
発見や調整は強化できる。でも、実際にシステムを変更するのは開発・運用。詰まっている場所が違う。
- 01
セキュリティ部門
脆弱性情報を集める/対応を調整する
- 02
開発・運用部門
影響を調べる/修正する/適用する
最優先でも、1週間〜1ヶ月かかることがある。
さらに掘る この場面の詳細・原文
たとえばセキュリティパッチを当てるとしましょう。このとき、実はセキュリティエンジニアにできることは脆弱性の情報収集、パッチ対応の調整や取りまとめをするぐらいです。実際は運用部門、開発部門に対応が委ねられます。該当脆弱性が実際に影響あるかどうかの調査すら現場が行うことがほとんどです。
このとき仮に最優先だったとしても対応に1週間-1ヶ月かかるのはザラです。 こんなに時間がかかるのはセキュリティ能力ではなく、IT実行能力が欠如しているからです。セキュリティ関係に限らずなにをやっても1週間-1ヶ月単位でかかるため。 優先順位の理解不足のパターンもありますが純粋に工数、人員に余力があってもこれだけかかります。
セキュリティ能力というよりIT実行能力がない
05では、現場に人を増やせば?
現場の人手を増やせば、速くなるんじゃない?
余力があっても、変更のたびに調べ直し、申請し直すなら時間はかかる。騒ぎになってから動くのではなく、常時更新できる仕組みが必要。
- 01
調査
対象の資産・影響を調べ直す
- 02
手順書
作業方法を人が書く
- 03
申請
関係者と調整し直す
- 04
手作業
人がパッチを適用する
- 05
目視確認
人が結果を確かめる
資産情報・構成管理・テスト・デプロイを、機械で扱える状態へ。
さらに掘る この場面の詳細・原文
そもそも脆弱性がネットで騒ぎになってからパッチを当てるのでは遅く、常時パッチを当てるのが適切です。これは今現在セキュリティにかけている(かかっている)お金の問題ではなく汎用的なIT実行能力の問題です。
パッチ適用に毎回、対象の調査、手順書作成、申請、手作業、目視確認が必要なら、人員に余力があっても時間はかかります。資産情報、構成管理、テスト、デプロイなどを機械で扱える状態にしていないので、変更するたびに人が調べ直し、調整し直すことになります。設計が貧弱で扱う資産の範囲を狭められてないのもそうでしょう。
セキュリティ能力というよりIT実行能力がない
06AIの前に、IT部門のIT化。
AIを使えば解決……という前に、開発の工程に問題がある?
IT企業でも、IT部門自体のIT化が遅れている。コードの脆弱性も、最後に専門家がチェックすれば済む話ではない。
- 01
最後に検査
できあがったコードから穴を探す。見つかっても、手戻りは大きい。
- 02
最初から設計
設計・実装の段階から安全性を作る。検査だけに頼らない。
さらに掘る この場面の詳細・原文
AI以前にIT部門のIT化が進んでないことが多く、IT企業でもIT化が遅れていることがよくあります。
コーディングもそうです。セキュリティエンジニアを集めてもコードのチェックぐらいはできますが、そもそもコードに脆弱性がある時点で取り返しがつきにくい。
セキュリティ能力というよりIT実行能力がない
07検品だけでは、守れない。
チェックを強化するより、最初から安全に作るべきということ?
基本的な安全な実装ができないまま開発を続けるのは、穴の空いたバケツに水を注ぐようなもの。設計や設定も同じだ。
セキュリティだけを、後付けで強くはできない。
- 01
大量生産の検品との違い
不良品を弾き、返品でカバーする方式を、一品物のシステムにそのまま持ち込めない。
さらに掘る この場面の詳細・原文
セキュリティも検査ではなく工程で作り込む必要があります。基本的なセキュリティコーディング能力が欠いたエンジニアに開発させるのは穴が空いたバケツに水を溜めるようなものです。 セキュリティコーディング能力からおおよそ開発者の能力が推定できるでしょう。 コーディングだけではなく設計や設定も同じです。セキュリティのようなサブ分野であっても重要なシステムを興味持ってまじめにやっていれば自然と学んでいくものです。
大量生産型の製造業であれば、品質管理の一つの方法として生産にはコストをかけず検品で弾いたり返品でカバーする方式もありえますが、一品物でそれは不可能です。
セキュリティ能力というよりIT実行能力がない
08日常の兆候を、誰が見ている?
ログや請求書を見るような、日常の運用はどう? 専門家に任せればいい?
ログ・メトリクス・請求書は、日常的に見るもの。請求書から侵害に気づくこともある。でも、そもそも見ていなければ始まらない。
- 01
LOG
システムで何が起きているか
- 02
METRICS
いつもと振る舞いが違わないか
- 03
BILLING
想定外の利用が発生していないか
一方、セキュリティ専門家にも開発・運用の知見が足りないことがある。
さらに掘る この場面の詳細・原文
ログやメトリクス、請求書の話もしましょう。これらは日常的に重要なもので、システムを活用するうえで定期的に見るべきものです。クラウドの請求書から侵害に気づくことも可能です。が、そもそも誰も見てません。
逆に、セキュリティエンジニアはセキュリティ対応ばかり行うため、開発や運用に対する知見が欠けている事が多いです。
セキュリティ能力というよりIT実行能力がない
09両方わかる人が、足りない。
開発とセキュリティ、両方がわかる人はどれくらいいると思う?
開発とセキュリティは分断されがち。両方を理解する人は希少で、取り合いになる。次の数字は統計ではなく、経験に基づく推測。
- 01
3桁人ぐらい?
開発を理解するセキュリティエンジニア
- 02
数千人ぐらい?
セキュリティを理解する開発者
そうした人材は、大企業やその外注先には集まりにくい。
さらに掘る この場面の詳細・原文
残念ながらセキュリティエンジニアで開発を理解しているのは日本で3桁人ぐらいでしょうか。 開発者でセキュリティを理解しているのは数千人ぐらいかもしれません。
そしてそのような人たちは取り合いになり、大企業や開発運用の外注先企業で働くことはありません。
セキュリティ能力というよりIT実行能力がない
10一人の実力では、持ち込めないもの。
なら、Googleで実績のある人を一人採用すれば変わる?
Googleで実績があっても、前職の環境までは持ってこられない。組織改革まで一人に背負わせれば、成果も定着も難しくなる。部長や役員でも同じ。
- 01
本人の経験・能力
優秀な人は入ってくる。
- 02
組織の実行環境
権限・開発基盤・契約・評価制度は、そのまま。
さらに掘る この場面の詳細・原文
仮にGoogleで実績のあるエンジニアが一人入社してくれたとしても、権限、開発基盤、契約、評価制度といった環境まで一緒に入ってくるわけではありません。本人の成果にも限界があり、組織を変える仕事まで背負わせれば定着も難しくなる。部長や役員クラスでも同様です。
CHAPTER 03 / 17
関係者の事情
CONFLICT
関係者それぞれの事情
NEXT / → で、この章を始める
関係者それぞれの事情
12必要だとしても、自分の仕事?
現場や外注先は、なぜ自分から動かないの?
現場には目の前の仕事がある。外注先には契約と収益の事情がある。重要だと伝えるだけでは、このずれは埋まらない。
- 01
現場
目の前の仕事が最優先。事業影響は把握しにくく、提案も苦手。ITに関心のある人は少数派。
- 02
開発・運用外注先
契約にない仕事は、収益となる工数につながらない。対応は契約上の最低限に寄る。
さらに掘る この場面の詳細・原文
現場:セキュリティの重要性を理解していない。脆弱性がビジネスに与える影響までは把握は困難。目の前の仕事が一番大事。提案は苦手。ITに興味がある人は少数派。
開発/運用外注先:セキュリティ関係をやる動機が文字通りなにもない。収益となる工数とは無関係のため。契約にあれば最低限対応するぐらい。
関係者それぞれの事情
13指揮する側も、現場が見えない。
セキュリティ部門やCIOが、そこを動かせない?
開発・運用をどう動かすかの像がないと、実行力を損なわずに安全性を上げる提案ができない。強く反論されれば、そこで止まる。
- 01
セキュリティ部門
開発・運用のイメージが薄い。IT実行力と安全性を一緒に高める提案が苦手。
- 02
CIO
実際に対応した経験がなく、何をすればよいか像が結びにくい。
さらに掘る この場面の詳細・原文
セキュリティ部門:IT実行能力を損なわずにセキュリティを強化する、むしろ両方強化するといった提案は苦手 開発/運用のイメージがない。逆に強く出られると止まってしまう。 セキュリティに興味がある人は少数派。
CIO:セキュリティ対応を実際にやったことがないので何もイメージが付かない。
関係者それぞれの事情
14指摘した人を、敵にしない。
悪い診断結果を突きつけられたら変わる? 外部の指摘にはどう向き合うべき?
私の見る限り、悪い診断結果でも自発的に動く人は少ない。職業上の誇りや顧客への責任感だけに期待できない。だから、問題を向ける先が重要になる。
- 01
外部に反論する
現場が一緒に、指摘した人を敵に回す。
- 02
経営に働きかける
できない理由が事実なら、経営に環境の改善を求める。外部には応援してもらう。
それでも変わらないなら、退職を選ぶのがよい。
さらに掘る この場面の詳細・原文
私が見る限り、プロフェッショナルとして恥ずかしいであったり、お客さんに申し訳ないという気持ちを持ったりする人は少数派です。クラフトマンシップは貴重で、史上最低クラスの脆弱性診断結果をつきつけられても特に自分からなにかする気はない人が多数派。
外部に対して、現場が一緒になってできない理由を反論するのはよくない傾向です。内容は事実なのだからそれを経営レイヤーに働きかける、それでも変わらないなら退職するのがよいでしょう。外部の人を敵に回すのではなく応援してもらう。
CHAPTER 04 / 17
増強する場所
NO FIX
セキュリティエンジニアやセキュリティ製品を増やせばよいのか
NEXT / → で、この章を始める
セキュリティエンジニアやセキュリティ製品を増やせばよいのか
16増やす場所を、間違えない。
セキュリティエンジニアや製品を増やすのは、解決にならない?
詰まっているのはIT部門。セキュリティ部門だけを増やしても、調整の先にある作業は速くならない。
装備の数と、変更を届ける力は別。
- 01
予算・人員の見方
セキュリティの費用や人数は、IT全体の費用・人員に対する割合で妥当性を考える。
さらに掘る この場面の詳細・原文
上記の通りボトルネックはセキュリティ部門ではなくIT部門です。 セキュリティコストや人員はおおよそITコストや人員に対する割合で妥当性が決まります。
CHAPTER 05 / 17
選定能力
SELECT
外部プロダクトの選定能力が弱い
NEXT / → で、この章を始める
外部プロダクトの選定能力が弱い
18選ぶ道具に、能力が出る。
外部ツールからの漏洩も多い。製品の選び方に問題がある?
マイナーな外部ツールからの漏洩も目立つ。安全性以前に、なぜそれを選んだのか。選定する能力も、IT能力の一部だ。
- 01
外部ツール
利用目的に対して、なぜその製品なのか。
- 02
ベンダー・外注先
誰に何を任せているかにも、選定側の実力が表れる。
さらに掘る この場面の詳細・原文
実際のニュースを見ているとマーケティングなどに利用しているマイナーツールからの漏洩も目立ちます。 セキュリティ面を除外してもなぜそのツールを選んだのか選定に疑問を感じます。
セキュリティに限らず、基本的に選定するもの、利用する道具で能力が見えます。付き合ってるベンダーだけで実力が推定できるでしょう。これは他の部門でもあっても同様で、どの専門でも専門家なら外注先を見れば実力がどのランクかわかるものです。
外部プロダクトの選定能力が弱い
19選び直すにも、実行力が要る。
問題のある製品なら、乗り換えればいいのでは?
その乗り換えを実行するのもIT部門。問題のある道具を選んでしまう組織は、そこから抜け出す段階でも同じ能力を問われる。
- 01
選ぶ
外部プロダクトを選定する
- 02
気づく
選定に問題があったとわかる
- 03
乗り換える
ここでも、IT実行能力が必要
さらに掘る この場面の詳細・原文
そして乗り換えにもIT能力が必要なのが難しいところです。
CHAPTER 06 / 17
製品の盲点
BLIND SPOT
セキュリティプロダクトも同じ
NEXT / → で、この章を始める
セキュリティプロダクトも同じ
21売る側も、事業をしている。
セキュリティ製品を作る会社なら、自社のセキュリティは万全?
セキュリティ製品もプロダクト開発の一種。目の前の開発が優先される事情は同じで、製品自身の安全性が弱いこともある。
- 01
売っているもの
セキュリティ対策のための製品
- 02
作っている組織
納期や事業上の優先順位を持つ開発組織
さらに掘る この場面の詳細・原文
セキュリティ関係のプロダクトもプロダクトであり、プロダクト開発の一種です。 結局ビジネスであり、セキュリティ対応より目の前の開発が優先されるでしょう。セキュリティプロダクトのセキュリティが貧弱なのはよくあることです。
CHAPTER 07 / 17
変わらない環境
NO PRESSURE
ITでは競争優位性を生み出さない。IT能力がなくても困らない
NEXT / → で、この章を始める
ITでは競争優位性を生み出さない。IT能力がなくても困らない
23変わらなくても、組織は続く。
そもそも、IT能力を上げようという圧力が弱いのはなぜ?
日本の大企業同士の国内競争では、ITで差をつける圧力が弱い。株主からの効率・競争力への要求も弱ければ、改革は進まない。
- 01
競争圧力が弱い
ITで抜き出す必要が小さい
- 02
改革を求められない
効率や競争力への要求も弱い
- 03
今のまま続く
本当は、特に誰も困っていない
さらに掘る この場面の詳細・原文
日本国内だけの日本の大企業同士の競争だとITで抜き出たところで差が生まれません。 そもそも株主からも経営効率の向上、競争力の向上が求められていません。
そのため改革が進みません。今のままでも本当は特に誰も困っていません。
CHAPTER 08 / 17
広すぎる守備範囲
COMPLEXITY
多角化、非中核事業の多さ
NEXT / → で、この章を始める
多角化、非中核事業の多さ
25事業が広がる。守備範囲も広がる。
多角化や非中核事業の多さも、セキュリティに響く?
非中核事業は刷新が後回しになる。撤退・売却・統合もなければ、古いシステムを維持する仕事が残り、中央のセキュリティ部門まで疲弊する。
- 01
古いシステム
刷新されず、維持する対象が残る
- 02
異なる業務要件
必要な水準が違い、複雑さが増す
- 03
広すぎる範囲
中央で一括対応しようとしても足が止まる
さらに掘る この場面の詳細・原文
非中核事業だと刷新は優先されにくいでしょう。撤退・売却・統合もしなければ、古いシステムを維持する仕事が残り続けます。範囲が広すぎて中央で対応するセキュリティ部門も疲弊します。とくに業務要件や必要なレベルが異なると複雑性が広がって足が止まります。
CHAPTER 09 / 17
事故のあと
LOOP
セキュリティインシデントが発生しても何も変わらない
NEXT / → で、この章を始める
セキュリティインシデントが発生しても何も変わらない
27事故のあとも、元のループへ。
インシデントで業務が止まったら、さすがに抜本的な改革が進むのでは?
業務停止が起きても、ITの段階が抜本的に進化するとは限らない。強い顧客関係や、事実上の独占で代替がなければ取引は続く。
- 01
侵害・業務停止
事業が止まる
- 02
それでも取引継続
関係が強い/替えがない
- 03
改革圧力は弱いまま
抜本的なIT刷新にはつながらない
さらに掘る この場面の詳細・原文
最近はセキュリティインシデントで業務が止まる事案が発生するようになりました。が、抜本的なITステージの進化にはつながっていません。
インシデントで事業が止まると取引がなくなりそうなものですが、日本ならではの顧客との関係の強さもあれば、事実上独占による弊害もあるでしょう。替えがないので継続されます。
CHAPTER 10 / 17
先送りの構造
TRIANGLE
不正のトライアングル: 動機、機会、正当化
NEXT / → で、この章を始める
不正のトライアングル: 動機、機会、正当化
29先送りを支える、3つの条件。
この先送りの構造を、整理するとどうなる?
古典的な「不正のトライアングル」を借りて整理すると、動機も、実行力も弱い。そのうえ、放置を正当化する理由がそろっている。
- 01
動機・プレッシャー
放置しても責任を問われず、取引や組織が維持される。
- 02
機会・実行可能性
必要性がわかっても、IT能力がなく実行できない。
- 03
正当化
「忙しい」「リソースがない」「事業優先」「契約外」「他社も同じ」
さらに掘る この場面の詳細・原文
セキュリティということで古典的ですが不正のトライアングルを使い検討してみましょう
| 要素 | セキュリティ対応が進まない条件 |
|---|---|
| 動機・プレッシャー | 対応を放置しても責任を問われず、取引や組織も維持されるため、改善への動機・圧力が弱い |
| 機会・実行可能性 | IT能力が欠如し、必要性を認識しても改善を実行できない |
| 正当化 | 「現場は忙しい」「リソースがない」「事業優先」「契約にない」「他社も同じ」で先送りを容認できる |
CHAPTER 11 / 17
AIと組織
AI ≠ ORG
AIでどうなるか
NEXT / → で、この章を始める
AIでどうなるか
31生成する力と、届ける力は違う。
AIは、エンジニアの能力や組織の実行力を変えられる?
AIは速度だけでなく成果の質でも、多数のエンジニアを上回っていると考える。でも、人・組織・プロセスの問題まで導入だけで解けるわけではない。
- 01
成果物を作る力
製品管理・要件定義・信頼性・品質保証・性能・可読性・使いやすさ・安全性。
- 02
組織を動かす力
権限・契約・プロセス。エージェントの利用すらできない企業もある。
約9割を削減し人員を入れ替えれば可能性はあるが、現実的ではない。
さらに掘る この場面の詳細・原文
率直に言えば日本の大多数を占めるITエンジニアよりフロンティアモデルのほうが速度だけではなくアウトプットの質でも上回っています。もう少し具体的には製品管理、要件定義、信頼性、品質保証、パフォーマンス、可読性、ユーザビリティ、セキュリティのいずれにおいても、AIに敗北しています。ただ、コーディングエージェントが利用できない会社も多くあるのでそのような組織はしばらく低調なままでしょう。
一方で、IT実行能力は組織や人、プロセスの問題であり、AIでは解決の見込みがありません。9割近くの人員をカットしつつ人を入れ替えたりすれば可能性はありますが現実的ではないでしょう。
AIでどうなるか
32AIが進んでも、同じ場所にいる?
組織が変わらないなら、この先も同じことが続く?
人や組織の入れ替えが非現実的で、外からの圧力もないなら、侵害と漏洩は続く。10年後も変わらないのではないか。
- 01
20〜30年以上
この間、根本の構造は変わっていないと感じる
- 02
今回だけ変わる?
このタイミングで変わる根拠がない
さらに掘る この場面の詳細・原文
現実的ではない以上、何も変わりません。相変わらず攻撃され続け、漏洩し続けるでしょうが誰も何も圧力をかけないので10年後も何も変わらないでしょう。経時的に言えば20-30年以上なにも変わってないのでその意味でもこのタイミングで変わる根拠がありません
CHAPTER 12 / 17
変化の条件
CHANGE
どのような条件なら変わるか
NEXT / → で、この章を始める
どのような条件なら変わるか
34変える条件を、考え直す。
では、どんな条件なら変わる可能性がある?
問題はセキュリティ単体ではなく、環境。改善が必要になり、適切な実践が当たり前になる条件を考えよう。
- 01
競争と新陳代謝
古い企業の退出と、新規参入の増加
- 02
技術を理解する経営
エンジニアリング能力の高い創業者
- 03
適切な規制
力のあるプレイヤーによるルール
さらに掘る この場面の詳細・原文
セキュリティではなく、環境の問題です。いくつか可能性を考えてみました。
CHAPTER 13 / 17
新陳代謝と競争
NEW ENTRY
古い企業の倒産が相次ぐ / スタートアップ含めた新規参入企業が増加する
NEXT / → で、この章を始める
古い企業の倒産が相次ぐ / スタートアップ含めた新規参入企業が増加する
36退出と参入が、圧力になる。
古い企業の退出や、新規参入が増えたらどうなる?
変わる可能性はある。古い企業の退出が進めば、古い組織やシステムが温存される状況も変わる。新規参入で競争が強まれば、既存企業も内部改革を迫られる。
- 01
古い企業の退出
組織とシステムが、永久に維持されるわけではなくなる。
- 02
スタートアップなどの参入
競争が強まり、変わらないことへの圧力になる。
さらに掘る この場面の詳細・原文
古い組織やシステムを保持しているから変わらないので、定期的になくなれば問題もなくなります。 プレッシャーが増えれば内部からの改革も進む可能性はあります。
CHAPTER 14 / 17
技術を理解する経営
ENGINEER
エンジニアリング能力が高い創業者が増える
NEXT / → で、この章を始める
エンジニアリング能力が高い創業者が増える
38当たり前を、当たり前にする。
エンジニアリング能力の高い創業者が増えると、何が違う?
実力のある創業者なら、適切な実践を自然に選ぶ。GitやCIのように、常識を採用するたびに疑いやROIの説明から始める必要はない。
適切な実践を、毎回の説得から解放する。
- 01
もっと簡単な特効薬は?
あるなら、とっくに変わっているのではないか。安易な近道には期待できない。
さらに掘る この場面の詳細・原文
実力がある人は自然と適切なことを行います。GitやContinuous Integrationも今では常識です。 常識をいちいち疑ったりROIを求める人はいません。
もっと簡便で効果がある特効薬はないのか?という質問もあるでしょうが、あったらもうとっくに変わっているのではないでしょうか。
CHAPTER 15 / 17
規制の両刃
DOUBLE EDGE
規制による推進
NEXT / → で、この章を始める
規制による推進
40規制は効く。間違えれば、逆効果。
規制で進める手はある? 間違ったルールを作る危険は?
国・業界団体・大手企業のルールには力がある。ただし、誤ったルールを強制すれば悪化する。規制は作って終わりではない。
- 01
変化を強制できる
仮にPHP製品との取引を禁止したら、脱却は進むだろう。ほかに、パスワードのメール送信禁止。
- 02
古い常識も固定してしまう
パスワードの定期変更が例。ガイドラインが古ければ悪影響が広がる。
規制・ガイドラインは、半年単位で見直す必要がある。
さらに掘る この場面の詳細・原文
たとえばPHPを利用しているプロダクトは取引禁止となれば、PHP脱却が一気に進むでしょう。パスワードのメール送信禁止などもそうです。 国や業界団体、業界大手など力のあるプレイヤーによる規制は効果的です。 ただし規制は諸刃の剣で、誤った規制内容だと悪化する可能性はあります。パスワードの定期変更問題が例として挙げられます。ガイドラインの内容が古ければ悲惨でしょう。半年単位での見直しが必要です。
CHAPTER 16 / 17
結論
THE TRUTH
結論
NEXT / → で、この章を始める
結論
42守りだけを、強くはできない。
結局、何が根本の問題で、どうすべきなの?
基礎的なIT実行能力を上げる必要がある。でも、それを上げる動機も環境も弱い。そこが変わらなければ、このままなのではないか。
足りないのは、変更を届ける力。
- 01
能力がない → 動機がない → 変わらない
セキュリティの問題を、セキュリティ部門だけの仕事に閉じ込めない。
さらに掘る この場面の詳細・原文
セキュリティ能力がない => セキュリティだけ挙げることはできない。基本的なIT実行能力がない => 能力をあげる動機がない => どうするか. どうしようもない
基礎能力をあげるべきだし上げないと無理です。でもできない、つまりこのままなのではないでしょうか。
CHAPTER 17 / 17
能力の兆候
EVIDENCE
補足:セキュリティの能力を推定する方法
NEXT / → で、この章を始める
補足:セキュリティの能力を推定する方法
44能力の兆候は、別の場所にも出る。
最後に。外からセキュリティ能力を推定するなら、どこを見る?
デザイン・UX・性能・ベンダーの選び方にも、共通のIT能力が表れる。特定分野だけが突出するとは考えにくい。
- 01
DESIGN / UX
古い見た目や使い勝手
- 02
PERFORMANCE
他と比べて劣る性能、操作の遅さ
- 03
VENDOR
選んだ道具・付き合うベンダー
根本のインプット・解釈・反応の能力は、各分野に表れる。
さらに掘る この場面の詳細・原文
いろいろありますがデザイン、パフォーマンスからもわかってしまいます。 デザインやUXが古いものがセキュリティが高いことはありません。 パフォーマンスも同様です。比較してパフォーマンスが貧弱、操作して遅いならセキュリティも貧弱です。 記事に記載した通り利用しているベンダーも使えます。
これらはIT能力のランクを示しています。各ジャンルのうち特定のなにかだけ突出することはありません。ダメな奴は何をやってもダメという格言がありますが、これは根本的なインプット、解釈、反応といった能力が欠如している状態です。
END OF REPORT / FILE 788A6E9F
THEEND.
守る力は、
変える力から。
STAFF ROLL
- TEXT & DIRECTION
- AS
- ORIGINAL ARTICLE
- なぜ日本で大企業の
セキュリティ対応が
全然進まないのか
THANK YOU
FOR READING.最後まで読んでいただき、ありがとうございます。