閉域網やレガシー環境にも手が届く、脱Excelからの自動管理で構成情報をリアルタイムに可視化

FutureVulsは、大規模かつミッションクリティカルな金融システムにも適合する脆弱性管理ツールです。

 

閉域網かつレガシー環境でも、既存システムとの干渉を引き起こさず、様々な手段で構成情報を取得することが可能です。

 

一度、構成情報を登録しておくだけ脆弱性検知、トリアージ、タスク化までの一連の流れを自動化し、リアルタイムでのモニタリングを実現します。

financial_top

🏦金融業の特有課題🏦

最小リソースの運用で既存環境の適合と
説明責任が求められる

PROBLEM
  • icon_1

    ミッションクリティカルな金融システムでサービスに支障をきたさないこと

  • icon_2

    閉域網(クローズドネットワーク環境)の内部システムの情報取得の難易度

  • icon_3

    EOLを迎えたOSやソフトウェアが稼働しているため、導入のハードルが高い

  • icon_4

    発見されたすべての脆弱性に対応することは、テストの負荷や既存システムとの干渉の観点から困難

  • icon_5

    金融庁のサイバーセキュリティガイドラインでは、IT資産のEOLに伴う対応計画や脆弱性管理の監査証跡が必須要件

Excelと手動管理から抜け出せない深刻な理由

金融業はクライアントPCに強いIT資産管理ツールと、サーバーレイヤーに強い脆弱性管理ツールでソリューションが分断されており、「痒い所に手が届かない」ことが現場のリアルな課題です。パッチ適用による業務システム停止への懸念や高い費用対効果と効率化が求められ、根本的な対応が先送りされるケースも散見されます。

導入テストの手間と難易度
手動管理から
始めた弊害
手動管理で脆弱性管理をスタートしたことで、人手で運用ができているように感じられるため、ツール導入の優先度が先送りとなる。
脆弱性検知の難しさ
オープンとクローズド環境
内部システムとクライアントPCの両側面にアプローチできるソリューションが少なく、検討が先送りになりがち。
稼働継続の最優先
稼働継続
の最優先
ダウンタイムの許容は不可で繊細な制御ソフトウェアが誤作動を起こし、物理的な事故や製品不良を招くリスクを回避する必要がある。
レガシーシステム
レガシーシステムとの共生

メーカーサポートが終了しているOSやソフトウェアが稼働しているため、新たなソフトウェアのインストールを行う際、他のシステムと干渉を引き起こしやすい。

手動管理だと見逃されているOSSのEOL
―法的負債となるリスクが残存

FutureVulsで国内企業の実稼働にあるOSSの約16,000種類を分析した結果、提供元から公式にEOLが宣言された「公式EOL」は9.4%のみであり、OSSが抱えるリスクの全体像から見れば、水面に現れた氷山の一角に過ぎません。私たちは、今まで可視化されてこなかった「実質的 EOL」と「開発停滞」という2つの巨大なリスクを明らかにしています。

公式EOLは氷山の一角-1

金融業のお悩み、

Logo

 が解決します!

 

厳格な環境にも適合し最小リソースでの脆弱性管理

SOLUTIONS

FutureVulsはシビアな金融内部システムに導入した実績があります。脆弱性管理に必要な各プロセスの自動化と効率化にも寄与し、手作業での作業負荷の効率化を行うことが可能です。

Feature_overview2

通信不要&端末負荷なしでシステムの構成情報を取得

FutureVulsのペーストスキャン機能を活用することで機器に直接負荷をかけず、構成情報の登録が可能です。IP接続不要でレガシーシステムの繊細な端末でも支障をきたさずに脆弱性管理を行えます。

 

スキャナーのインストールが不要な登録手法で事前の検証作業も不要なため、スムーズに脆弱性管理をスタートすることができます。

financial_ip

リスク評価と対応可否を自動化し最小リソースでの運用が可能

検知された全ての脆弱性に対処することは現実的ではありません。そのため、FutureVulsに組織固有のポリシーを登録し、脆弱性のリスク評価や対応有無の判断を自動化します。

 

例えば、CVSSスコアや攻撃コードの有無、警戒情報の状況など、さまざまな条件を組み合わせたルールを設定可能です。これにより、脆弱性のリスクレベルを正確に評価し、最も重要な脆弱性から優先的に対応できるよう運用を最適化します。

OSSのEOLを即時検知&管理で説明責任を果たす

世界中の脆弱性データベースや公式サイトから収集した膨大なEOL情報を、お客様のSBOMと自動的に突合します。

 

公式からのEOL宣言がなくても、開発停滞や長期間放置されているOSS をリスク状態(もしくはリスク予備軍)と判定することが可能です。

 

OSSの脆弱性と自社製品独自の脆弱性を統合管理

 「金融業」の事例

CASE