Cloud Security Notification Framework / CSNF(組織)
パブリッククラウド(用語)
データレイク(用語)

【コラム】パブリッククラウドにおけるセキュリティ課題の解決に向けて

次の記事

テクノロジーと災害対応の未来3「接続性、地球が滅びてもインターネットは不滅」

編集注:本稿の著者Nick Lippis(ニック・リッピス)氏は、先進的なIPネットワークとそのビジネス上のメリットに関する権威。大企業のITビジネスリーダー約1000人が参加する年2回のミーティングを主催するONUGの共同設立者であり、共同議長も務めている。

ーーー

専門家の間では、データレイク市場は今後6年間で315億ドル(約3兆4000億円)の巨大市場になると言われており、この予測は大企業の間で大きな懸念となっている。データレイクの増加はパブリッククラウドの使用量の増加を意味し、その結果、通知、警告、セキュリティイベントの急増につながるというのがその理由である。

Sumo Logic(スモーロジック)による調査結果を引用した2020年のDark Readingの記事によると、企業組織の約56%が毎日1000件以上のセキュリティアラートを処理しており、70%のITプロフェッショナルが過去5年間でアラートの量が倍増したと報告している。実際、ONUGコミュニティでは、1秒あたりに約100万件のイベントが発生しているという。1秒あたりである。という事は年間で数十ペタのイベントが発生していることになる。

あらゆることのデジタル化が進む今、この数字は増え続ける一方だ。企業のITリーダーらは日々このようなイベントへの対応に追われ、より優れた対処方法がないかと頭をひねらせている。

今や社会の運営基盤となっているパブリッククラウドのセキュリティに、なぜ標準的なアプローチが存在しないのか。

パブリッククラウドのセキュリティに対処するための統一されたフレームワークがないことが、この問題を悪化させている一因だ。エンドユーザーやクラウド消費者は「適切な」セキュリティ体制で運用するために、SIEM、SOAR、セキュリティデータレイク、ツール、保守、スタッフなどのセキュリティインフラへの支出の増加を余儀なくされている。

今後パブリッククラウドがなくなることはなく、データやセキュリティへの懸念が消えることもありえない。しかし、この問題を解決するためにITリーダーは延々と奮闘し続けなければいけないのだろうか。我々は現在、高度に標準化された世界に住んでいる。小学生の送り迎えや社用車の借り出しなどのごく単純な作業にでも、標準的な業務プロセスが存在する。それではなぜ、今や社会の運営基盤となっているパブリッククラウドのセキュリティに標準的なアプローチが存在しないのか。

ONUG Collaborative(ONUGコラボレティブ)も同じ疑問を感じていたようだ。FedEx(フェデックス)、Raytheon Technologies(レイセオン・テクノロジーズ)、Fidelity(フィデリティ)、Cigna(シグナ)、Goldman Sachs(ゴールドマン・サックス)などのセキュリティリーダーが集結し、Cloud Security Notification Framework(CSNF)を設立した。クラウドプロバイダーがセキュリティイベント、アラート、アラームを報告する方法に一貫性を持たせ、エンドユーザーにデータの可視性とガバナンスの向上をもたらすというのがこの取り組みの目的である。

パブリッククラウドのセキュリティ上の課題と統一されたフレームワークによって、CSNFがどのようにこの課題を解決しようとしているのかを詳しくご紹介したい。

問題の根源

パブリッククラウドにおけるセキュリティアラートの増加を引き起こしている主な要素は次のとおりだ。

  • 新型コロナウイルス(COVID-19)を発端とした急速なデジタルトランスフォーメーション
  • 現代の在宅ワーク環境によるネットワークの広がり
  • セキュリティ攻撃の種類の増加

最初の2つの課題は密接に関連している。企業がオフィス閉鎖を余儀なくされ、業務と従業員をリモート環境に移行することになった2020年3月、サイバー脅威と安全性の間を隔てていた壁が音を立てて崩れた。すでにリモート運用を行っていた企業にとっては大きな問題ではなかったものの、多くの企業にとってはすぐに問題が表面化することとなった。

当時はセキュリティよりもスピードが重視されていたと複数のリーダーが筆者に話している。ガバナンスよりもすべてを早く稼働させることが優先されていたわけだ。会社のネットワークエッジの一部を各従業員の自宅のホームオフィスに持ち込み、基本的なガバナンス管理や従業員へのフィッシングやその他の脅威の見分け方を教えるトレーニングが行われないまま、攻撃がいつされてもおかしくない状況を作り上げていたのだ。

2020年、FBIのサイバー部門にはセキュリティインシデントに関する苦情が1日あたり4000件近く寄せられていた。これはパンデミック前と比べて400%の増加である。

向上し続けるサイバー犯罪者の知能もセキュリティ上の問題の1つである。Dark Readingの記事によると67%のリーダーが、管理しなければならないセキュリティ脅威の種類が常に変化していることがコアとなる課題だと主張している。サイバー犯罪者はこれまでになく賢くなっている。フィッシングメール、IoTデバイスからの侵入、その他さまざまな手段を駆使して組織のネットワークに侵入するため、ITチームは常に対応を迫られ、何が重要で何が重要でないかの選別作業に貴重な時間を奪われているのだ。

統一されたフレームワークがなければ、インシデントの量は制御不能に陥ることになる。

CSNFが活躍できる場所

CSNFはクラウドプロバイダーとITコンシューマーの双方にとって有益なものとなるだろう。通常、セキュリティプラットフォームでは、アセットインベントリー、脆弱性評価、IDS製品、過去のセキュリティ通知など、サイロ化されたソースからすべてのデータを取り込むために、統合タイムラインが必要となる。またこういったタイムラインには高額なコストがかかり効率も悪い。

しかし、CSNFのような標準化されたフレームワークを使用すると、過去の通知の統合プロセスが簡略化され、エコシステム全体のコンテキストプロセスが改善されるため、支出を効率的に削減し、SecOpsチームやDevSecOpsチームはセキュリティ体制の評価、新製品の開発、既存のソリューションの改善など、より戦略的なタスクに集中する時間を確保することができる。

標準化されたアプローチがすべての関係者にもたらすメリットについて詳しく見てみよう。

  • エンドユーザー:CSNFは、IT部門などの企業のクラウド利用者のオペレーションを効率化し、データのセキュリティ体制の可視化やコントロールの向上を可能にする。クラウドガバナンスの改善によるこういった安心感の向上は、誰にとっても有益なことである
  • クラウドプロバイダー:CSNF は、追加のセキュリティリソースを解放することで、企業が特定のクラウドプロバイダーからの追加サービスを利用することを妨げている現在の参入障壁を取り除くことができる。またエンドユーザーのクラウドガバナンスが向上することで、クラウド利用が促進され、プロバイダーの収益が増加するとともに、データの安全性に対して安心感を提供することができる
  • クラウドベンダー:SaaSソリューションを提供するクラウドベンダーは、日々増え続けるセキュリティ通知に対応するため、エンジニアリングリソースに多くの費用を費やしている。標準化されたフレームワークを導入すれば、このような追加リソースは必要ない。特定のニーズや労働力にコストをかける代わりに、従業員はユーザーダッシュボードやアプリケーションなどの製品やオペレーションの改善に専念できるようになる

すべてのグループが協力することで、セキュリティアラートによる摩擦を効果的に減らし、長期にわたって確実にコントロールされたクラウド環境を構築することができる。

今後の展開

現在CSNFは構築段階にある。クラウドの消費者が団結して要件をまとめ、プロトタイプの確立に向けてガイダンスを提供し続けている。そしてクラウドプロバイダーは今、CSNFの重要なコンポーネントであるDecoratorの構築を進めている。Decoratorとはオープンソースのマルチクラウドセキュリティ報告書の翻訳サービスを提供するものだ。

パンデミックは我々の世界に多くの変化をもたらし、それはパブリッククラウドにおける新たなセキュリティ上の課題にまでに及んだ。セキュリティに関する安心感を高め、リソース増加の必要性を回避し、より多くのクラウド消費を可能にするために、ITにおける課題の軽減が最優先されなければ堅実なガバナンスと効率的な運用を続ける事はできない。デジタルトランスフォーメーションが急速に進むこの時代、ONUGは業界がセキュリティイベントの一歩先を行くことができるよう取り組んでいる。

関連記事
オープンクラウドセキュリティフレームワークの構築をマイクロソフトやグーグル、IBMらが支持
【コラム】スタートアップにとって信頼できるセキュリティとはコンプライアンス基準以上のものだ

カテゴリー:セキュリティ
タグ:データレイクパブリッククラウドCloud Security Notification Framework(CSNF)DXパンデミックコラム

画像クレジット:Blue Island / Shutterstock

原文へ

(文:Nick Lippis、翻訳:Dragonfly)