なぜ日本で大企業のセキュリティ対応が全然進まないのか
セキュリティ侵害の事案が多発しています。AI時代でもなぜセキュリティ対応が全然進まないのか説明していきます。
セキュリティ能力というよりIT実行能力がない
たとえばセキュリティパッチを当てるとしましょう。このとき、実はセキュリティエンジニアにできることは脆弱性の情報収集、パッチ対応の調整や取りまとめをするぐらいです。実際は運用部門、開発部門に対応が委ねられます。該当脆弱性が実際に影響あるかどうかの調査すら現場が行うことがほとんどです。
このとき仮に最優先だったとしても対応に1週間-1ヶ月かかるのはザラです。 こんなに時間がかかるのはセキュリティ能力ではなく、IT実行能力が欠如しているからです。セキュリティ関係に限らずなにをやっても1週間-1ヶ月単位でかかるため。 優先順位の理解不足のパターンもありますが純粋に工数、人員に余力があってもこれだけかかります。
そもそも脆弱性がネットで騒ぎになってからパッチを当てるのでは遅く、常時パッチを当てるのが適切です。これは今現在セキュリティにかけている(かかっている)お金の問題ではなく汎用的なIT実行能力の問題です。
パッチ適用に毎回、対象の調査、手順書作成、申請、手作業、目視確認が必要なら、人員に余力があっても時間はかかります。資産情報、構成管理、テスト、デプロイなどを機械で扱える状態にしていないので、変更するたびに人が調べ直し、調整し直すことになります。設計が貧弱で扱う資産の範囲を狭められてないのもそうでしょう。
AI以前にIT部門のIT化が進んでないことが多く、IT企業でもIT化が遅れていることがよくあります。
コーディングもそうです。セキュリティエンジニアを集めてもコードのチェックぐらいはできますが、そもそもコードに脆弱性がある時点で取り返しがつきにくい。
セキュリティも検査ではなく工程で作り込む必要があります。基本的なセキュリティコーディング能力が欠いたエンジニアに開発させるのは穴が空いたバケツに水を溜めるようなものです。 セキュリティコーディング能力からおおよそ開発者の能力が推定できるでしょう。 コーディングだけではなく設計や設定も同じです。セキュリティのようなサブ分野であっても重要なシステムを興味持ってまじめにやっていれば自然と学んでいくものです。
大量生産型の製造業であれば、品質管理の一つの方法として生産にはコストをかけず検品で弾いたり返品でカバーする方式もありえますが、一品物でそれは不可能です。
ログやメトリクス、請求書の話もしましょう。これらは日常的に重要なもので、システムを活用するうえで定期的に見るべきものです。クラウドの請求書から侵害に気づくことも可能です。が、そもそも誰も見てません。
逆に、セキュリティエンジニアはセキュリティ対応ばかり行うため、開発や運用に対する知見が欠けている事が多いです。
残念ながらセキュリティエンジニアで開発を理解しているのは日本で3桁人ぐらいでしょうか。 開発者でセキュリティを理解しているのは数千人ぐらいかもしれません。
そしてそのような人たちは取り合いになり、大企業や開発運用の外注先企業で働くことはありません。
仮にGoogleで実績のあるエンジニアが一人入社してくれたとしても、権限、開発基盤、契約、評価制度といった環境まで一緒に入ってくるわけではありません。本人の成果にも限界があり、組織を変える仕事まで背負わせれば定着も難しくなる。部長や役員クラスでも同様です。
関係者それぞれの事情
現場：セキュリティの重要性を理解していない。脆弱性がビジネスに与える影響までは把握は困難。目の前の仕事が一番大事。提案は苦手。ITに興味がある人は少数派。
開発/運用外注先：セキュリティ関係をやる動機が文字通りなにもない。収益となる工数とは無関係のため。契約にあれば最低限対応するぐらい。
セキュリティ部門：IT実行能力を損なわずにセキュリティを強化する、むしろ両方強化するといった提案は苦手 開発/運用のイメージがない。逆に強く出られると止まってしまう。 セキュリティに興味がある人は少数派。
CIO：セキュリティ対応を実際にやったことがないので何もイメージが付かない。
私が見る限り、プロフェッショナルとして恥ずかしいであったり、お客さんに申し訳ないという気持ちを持ったりする人は少数派です。クラフトマンシップは貴重で、史上最低クラスの脆弱性診断結果をつきつけられても特に自分からなにかする気はない人が多数派。
外部に対して、現場が一緒になってできない理由を反論するのはよくない傾向です。内容は事実なのだからそれを経営レイヤーに働きかける、それでも変わらないなら退職するのがよいでしょう。外部の人を敵に回すのではなく応援してもらう。
セキュリティエンジニアやセキュリティ製品を増やせばよいのか
上記の通りボトルネックはセキュリティ部門ではなくIT部門です。 セキュリティコストや人員はおおよそITコストや人員に対する割合で妥当性が決まります。
外部プロダクトの選定能力が弱い
実際のニュースを見ているとマーケティングなどに利用しているマイナーツールからの漏洩も目立ちます。 セキュリティ面を除外してもなぜそのツールを選んだのか選定に疑問を感じます。
セキュリティに限らず、基本的に選定するもの、利用する道具で能力が見えます。付き合ってるベンダーだけで実力が推定できるでしょう。これは他の部門でもあっても同様で、どの専門でも専門家なら外注先を見れば実力がどのランクかわかるものです。
そして乗り換えにもIT能力が必要なのが難しいところです。
セキュリティプロダクトも同じ
セキュリティ関係のプロダクトもプロダクトであり、プロダクト開発の一種です。 結局ビジネスであり、セキュリティ対応より目の前の開発が優先されるでしょう。セキュリティプロダクトのセキュリティが貧弱なのはよくあることです。
ITでは競争優位性を生み出さない。IT能力がなくても困らない
日本国内だけの日本の大企業同士の競争だとITで抜き出たところで差が生まれません。 そもそも株主からも経営効率の向上、競争力の向上が求められていません。
そのため改革が進みません。今のままでも本当は特に誰も困っていません。
多角化、非中核事業の多さ
非中核事業だと刷新は優先されにくいでしょう。撤退・売却・統合もしなければ、古いシステムを維持する仕事が残り続けます。範囲が広すぎて中央で対応するセキュリティ部門も疲弊します。とくに業務要件や必要なレベルが異なると複雑性が広がって足が止まります。
セキュリティインシデントが発生しても何も変わらない
最近はセキュリティインシデントで業務が止まる事案が発生するようになりました。が、抜本的なITステージの進化にはつながっていません。
インシデントで事業が止まると取引がなくなりそうなものですが、日本ならではの顧客との関係の強さもあれば、事実上独占による弊害もあるでしょう。替えがないので継続されます。
不正のトライアングル: 動機、機会、正当化
セキュリティということで古典的ですが不正のトライアングルを使い検討してみましょう
| 要素 | セキュリティ対応が進まない条件 |
|---|---|
| 動機・プレッシャー | 対応を放置しても責任を問われず、取引や組織も維持されるため、改善への動機・圧力が弱い |
| 機会・実行可能性 | IT能力が欠如し、必要性を認識しても改善を実行できない |
| 正当化 | 「現場は忙しい」「リソースがない」「事業優先」「契約にない」「他社も同じ」で先送りを容認できる |
AIでどうなるか
率直に言えば日本の大多数を占めるITエンジニアよりフロンティアモデルのほうが速度だけではなくアウトプットの質でも上回っています。もう少し具体的には製品管理、要件定義、信頼性、品質保証、パフォーマンス、可読性、ユーザビリティ、セキュリティのいずれにおいても、AIに敗北しています。ただ、コーディングエージェントが利用できない会社も多くあるのでそのような組織はしばらく低調なままでしょう。
一方で、IT実行能力は組織や人、プロセスの問題であり、AIでは解決の見込みがありません。9割近くの人員をカットしつつ人を入れ替えたりすれば可能性はありますが現実的ではないでしょう。
現実的ではない以上、何も変わりません。相変わらず攻撃され続け、漏洩し続けるでしょうが誰も何も圧力をかけないので10年後も何も変わらないでしょう。経時的に言えば20-30年以上なにも変わってないのでその意味でもこのタイミングで変わる根拠がありません
どのような条件なら変わるか
セキュリティではなく、環境の問題です。いくつか可能性を考えてみました。
古い企業の倒産が相次ぐ / スタートアップ含めた新規参入企業が増加する
古い組織やシステムを保持しているから変わらないので、定期的になくなれば問題もなくなります。 プレッシャーが増えれば内部からの改革も進む可能性はあります。
エンジニアリング能力が高い創業者が増える
実力がある人は自然と適切なことを行います。GitやContinuous Integrationも今では常識です。 常識をいちいち疑ったりROIを求める人はいません。
もっと簡便で効果がある特効薬はないのか？という質問もあるでしょうが、あったらもうとっくに変わっているのではないでしょうか。
規制による推進
たとえばPHPを利用しているプロダクトは取引禁止となれば、PHP脱却が一気に進むでしょう。パスワードのメール送信禁止などもそうです。 国や業界団体、業界大手など力のあるプレイヤーによる規制は効果的です。 ただし規制は諸刃の剣で、誤った規制内容だと悪化する可能性はあります。パスワードの定期変更問題が例として挙げられます。ガイドラインの内容が古ければ悲惨でしょう。半年単位での見直しが必要です。
結論
セキュリティ能力がない => セキュリティだけ挙げることはできない。基本的なIT実行能力がない => 能力をあげる動機がない => どうするか. どうしようもない
基礎能力をあげるべきだし上げないと無理です。でもできない、つまりこのままなのではないでしょうか。
補足：セキュリティの能力を推定する方法
いろいろありますがデザイン、パフォーマンスからもわかってしまいます。 デザインやUXが古いものがセキュリティが高いことはありません。 パフォーマンスも同様です。比較してパフォーマンスが貧弱、操作して遅いならセキュリティも貧弱です。 記事に記載した通り利用しているベンダーも使えます。
これらはIT能力のランクを示しています。各ジャンルのうち特定のなにかだけ突出することはありません。ダメな奴は何をやってもダメという格言がありますが、これは根本的なインプット、解釈、反応といった能力が欠如している状態です。