top of page

【SCS評価制度】「防御」は点ではなく面で設計する—攻撃者が突くのは、いつも“隙間”

  • 2 日前
  • 読了時間: 8分

SCS評価制度の大分類4「攻撃等の防御」/ 中分類4-2〜4-5「教育・データ・プラットフォーム・ネットワーク」

「防御」で本質的に求められるものとは

SCS評価制度の中分類中分類4-2以降では、EDRやバックアップといった個々の対策ツールを導入することは重要ですが、教育・データ・サーバやOS・ネットワークという複数のレイヤーが、それぞれ独立した「点」としてではなく、互いに補い合う「面」として機能しているかどうかが問われます。


システム・運用・人に存在する脆弱性を攻撃者が狙う様子を示した図。SCS評価制度における教育・データ・プラットフォーム・ネットワークの対策を連携させ、多層防御でセキュリティの隙間をなくす考え方を表している。



はじめに

前回の記事「アイデンティティ管理・ゼロトラスト」では、大分類4-1として「誰がアクセスできるか」というIDの入口を守る話をしました。IDという入口を固めた先に問われるのが、その先にあるシステムそのもの――ネットワーク、端末、サーバ、そしてデータを、どう守るかという視点です。


私たちがセキュリティのご支援をする現場では、UTMやEDRなどのセキュリティ製品を導入し、システム面での対策を進めている企業は数多くあります。

一方で、、「この対策は何を守るためのものなのか」「どこまでを守り、どこからは別の対策が必要なのか」を十分に理解しないまま運用されているケースも少なくありません。

複数のベンダーの製品を組み合わせて導入した結果、それぞれの役割や守備範囲が曖昧になり、誰も守っていない"隙間"が生まれてしまうことがあります。

つまり、個々の対策を導入していることと、組織全体として「攻撃者に突かれる隙間がない状態」であることは、必ずしも同じではありません。

では、そもそも攻撃者はどこを狙い、なぜセキュリティインシデントは発生するのでしょうか。この違いを理解するために、まず「そもそもインシデントはなぜ起こるのか」というところから考えてみます。


インシデントの発生と脆弱性の関わり

セキュリティインシデントは、「脆弱性を突かれること」によって発生します。攻撃者は、ゼロから力ずくで侵入するのではなく、すでに存在している“隙間”を探し、そこを通り抜けようとします。



脆弱性とは何か—システムだけでなく、人にも存在する

「脆弱性」と聞くと、多くの方はOSやソフトウェアに存在する既知の欠陥(CVEとして公表されるようなもの)を思い浮かべるのではないでしょうか。もちろんそれも脆弱性の代表的な形ですが、SCS評価制度が大分類4-2以降で求めている対策の範囲を見ると、脆弱性はそれだけにとどまらないことが分かります。


  • システムの脆弱性:パッチが適用されていないサーバやネットワーク機器、サポートが終了したOS、初期設定のまま変更されていない機器

  • 運用の脆弱性:本来不要なはずの通信経路が整理されずに残っている、パスワードが複数のシステムで使い回されている、ログが取得されていても誰も確認していない

  • 人の脆弱性:不審なメールの添付ファイルを開いてしまう、ルールを知っていても忙しさの中でつい省略してしまう、「うちは狙われない」という思い込みから注意力が下がってしまう


いずれも、単体では小さな“隙”に見えるかもしれません。しかし攻撃者にとっては、そのどれもが侵入や被害拡大のための入口になり得ます。さらに厄介なのは、それぞれ性質が異なることです。システムの脆弱性は、脆弱性診断やパッチ適用によって比較的発見・修正しやすい一方で、運用や人の脆弱性は日々の業務の中に埋もれやすく、気付かないまま放置されることが少なくありません。

例えば、どれだけ最新のEDRやUTMを導入していても、利用者がフィッシングメールに騙されて認証情報を入力してしまえば、その技術的な対策をすり抜けられる可能性があります。反対に、従業員のセキュリティ意識が高くても、インターネットに公開されたサーバに重大な脆弱性が残っていれば、攻撃者はそこを起点に侵入してきます。

つまり、防御すべき対象は「システム」だけでも「人」だけでもありません。組織全体に存在するさまざまな脆弱性を把握し、それぞれに適切な対策を講じることが重要です。


4-2:人への投資—意識向上教育を形骸化させない

前段で触れた「人の脆弱性」に正面から向き合うのが、4-2-1(セキュリティの意識向上教育)、4-2-2(セキュリティインシデント発生時の教育・訓練)です。経営層を含めた全員参加の教育と、実際にインシデントが発生したことを想定した訓練の実施が求められます。

ツールを導入すること自体はもちろん重要ですが、それが実際に機能しているかを確認し、異常に気づいて声を上げられる人がいなければ、宝の持ち腐れになってしまいます。座学の研修だけで終わらせず、「いざという時に、誰が、何に気づき、どう報告するか」まで実践的に確認できているかどうかが問われるポイントです。


4-3:データそのものを守る、そして「復元できる」バックアップ

取引先との情報共有ルール)では、データそのものの保護と、取引先と情報を共有する際のルール策定が求められます。そして4-3-4(適切なバックアップ)では、取得対象・頻度・保管期間を定めるだけでなく、実際に復元できる状態を維持していることが重視されます。

バックアップは「取得すること」がゴールではなく、「必要な時に、確実に戻せること」がゴールです。取得はしているものの、一度もリストア訓練をしたことがない、というのは、私たちがご支援する中でも非常によく見られる状態です。攻撃者に隙間を突かれてインシデントが発生することを完全には防ぎきれない、という前提に立つと、「最後の砦」であるバックアップが本当に機能するかどうかは、被害の規模を大きく左右します。


4-4:プラットフォームの堅牢化—「システムの隙間」を塞ぐ

4-4-1(ハードウェア、OS及びソフトウェアの安全な構成)、4-4-2(サポート期限の切れたOS及びソフトウェアへの対策)、4-4-4(セキュリティパッチ・アップデートの手続)、4-4-5(マルウェア感染からの保護)では、パッチ適用やサポート切れ資産への対応といった、いわば「システムの脆弱性」を塞ぐための基本対策を、担当者の裁量に委ねるのではなく、組織としての手続きに落とし込むことが求められます。

また4-4-3(ログの取得)では、ファイアウォールなど重要な機器のログを一定期間保管することが求められています。これは、平時には気づかれにくい「本来使われていないはずの通信」を、後から検知・調査するための土台になります。


4-5:ネットワーク境界の防護—「不要な通信」を放置しない

4-5-1(ネットワーク境界防護)、4-5-2(社外への不正な通信の遮断)では、ネットワーク機器の初期設定の見直しや、必要最小限の通信のみを許可する設計が求められます。ファイアウォールやVPN機器の初期パスワードを変更する、リモート管理機能を不要なら無効化する、使われていない通信経路を定期的に棚卸しする――いずれも地味に見える対策ですが、「運用の脆弱性」を減らすための、基本かつ重要な取り組みです。


4本柱に共通する考え方—「点」の対策では、隙間は塞がらない

ここまで見てきた教育・データ・プラットフォーム・ネットワークという4つの領域は、それぞれ独立した対策のように見えるかもしれません。しかし、実際にはすべてが密接に関係しています。

システムにも、運用にも、人にも脆弱性は存在します。どれか一つでも対策が不十分であれば、攻撃者はそこを突破口として侵入を試みます。

パッチ管理という「点」、パスワード管理という「点」、教育という「点」を個別に実施するだけでは十分ではありません。それぞれの対策が連携し、組織全体として隙間のない状態を作ることが重要です。

さらに、この考え方は自組織の中だけで完結するものではありません。

現在、多くの企業はクラウドサービスや委託先、取引先とシステムを連携させながら事業を進めています。そのため、自社の対策が万全であっても、接続している取引先やサプライチェーンのどこかに脆弱性があれば、そこが攻撃者の侵入口となる可能性があります。

SCS評価制度が自社だけでなく、サプライチェーン全体を意識したセキュリティ対策を重視しているのも、このためです。

重要なのは、「個々の対策を導入すること」ではなく、それぞれの対策が組み合わさり、組織全体、さらにはサプライチェーン全体で隙間のない防御を実現することです。これが、大分類4-2から4-5までに共通する考え方と言えるでしょう。


おわりに

私たちがセキュリティ対策をご支援する中で、お客様からよく伺うのが、「EDRやUTM、バックアップなどの製品は導入しているのに、なぜここまで細かな項目が求められるのか分からなかった」という声です。

しかし、実際にヒアリングを進めると、多くの場合、導入されているのは個々のセキュリティ製品であり、パッチ適用のルール、不要な通信経路の棚卸し、バックアップの復元訓練、ログの定期的な確認、従業員への教育といった、対策を継続的に機能させるための運用まで整備できているケースは決して多くありません。

脆弱性は、システムだけでなく、運用や人にも存在します。そのため、重要なのは新たな製品を導入することではなく、それぞれの対策を組み合わせ、継続的に機能する仕組みとして運用できているかを見直すことです。

SCS評価制度が大分類4-2から4-5にかけて幅広い観点で対策を求めているのも、個々の対策の有無ではなく、「組織全体として継続的にセキュリティを維持できる状態」を目指しているためだと考えられます。

ぜひこの機会に、自組織の対策が製品の導入だけで終わっていないか、そしてシステム・運用・人のそれぞれに対して継続的な改善ができる仕組みになっているかを、あらためて点検してみてください。

次回は、大分類5「攻撃等の検知」について解説します。どれだけ防御を強化しても、攻撃を100%防ぐことはできません。だからこそ重要になるのが、「攻撃を受けたことに気付き、被害を最小限に抑える仕組み」です。防御の次の段階となる「検知」について、SCS評価制度の考え方とともに解説していきます。


bottom of page