ソフトウェア・インテグリティ

 

金融サービスのサイバーセキュリティは依然として穴だらけ:レポート

金融サービスに関する新しいサイバーセキュリティ・レポートは、業界がオンライン脅威を認識しているにもかかわらず、システム、ネットワーク、データを保護するための十分な対策を取っていないことを明らかにしています。

金融サービスのサイバーセキュリティは依然として穴だらけ:レポート

この投稿は『Forbes』誌で発表された記事を元にしています。

サイバーセキュリティに関して言えば、米国のビジネス界はもちろんIT版のレイク・ウォビゴンではありません。全員が平均以上ということはあり得ません。

しかし、金融サービス業界(FSI)は、複数の業種を対象にしたソフトウェア・セキュリティ対策(SSI)に関する年次のBSIMM(Building Security In Maturity Model:セキュア開発マチュリティ・モデル)調査で、過去10年間平均を上回っている、つまり平均よりも「成熟度が高い」と主張することができます。

それでも改善の余地があります。Synopsys Cybersecurity Research Center(CyRC)の委託を受けてPonemon Instituteが実施した調査結果をまとめた新しいレポート「The State of Software Security in the Financial Services Industry(金融サービス業界のソフトウェア・セキュリティの現状)」が本日発行されました。このレポートでは、業界がオンライン脅威を認識し、懸念しているにもかかわらず、その脅威からシステム、ネットワーク、データを保護するための十分な対策を取っていないことを明らかにしています。

つまり、「言行が一致していない」ということです。

金融サービスのサイバーセキュリティに関するレポートを入手する

サイバーセキュリティの失敗に注目を集めたCapital Oneの侵害

確かに、今週の物証Aは、紛れもないFSIの代表的企業でありクレジットカード、銀行、ローンを取り扱う巨大企業、Capital Oneの侵害のニュースです。

サイバーセキュリティの失敗に注目を集めたCapital Oneの侵害

FBI捜査官は月曜日、複数の報道で「構成に誤りがあった」とされるアマゾンのクラウド・データ・サーバーから約1億600万人分のCapital Oneクレジット申請データをダウンロードした容疑でシアトルのソフトウェア・エンジニア、ペイジ・A・トンプソンを逮捕しました。侵害されたデータには、個人情報が含まれ、中には社会保障番号と銀行口座番号が含まれているケースもありました。

このような事件は頻繁に起こるものではないかもしれませんが、FSIの400人以上のセキュリティ実務者に対するPonemonの調査から得られた以下の主要な調査結果を考えると、このような事態は不可避です。

  • 半数以上が、過去に機密性の高い顧客情報が盗まれたことがあると認めています。
  • 多くの組織はサードパーティーが提供する金融ソフトウェアやシステムを使用し、回答者の74%がサードパーティー製品のセキュリティ上の脆弱性を懸念しています。その一方で、ベンダーにサイバーセキュリティ要件の遵守を義務付けたり、ベンダーのセキュリティ・プラクティスを検証している組織は全体の半分にも達していません。

半数以上が、過去に機密性の高い顧客情報が盗まれたことがあると認めています。

サプライチェーンのリスク管理が課題

Synopsysのセキュリティ・コンサルティング担当マネージング・ディレクター、Drew Kilbourneは、ソフトウェア・セキュリティに対する正しいアプローチは1つではないが、「サプライチェーンのリスク管理を改善する必要性が非常に高い」ことを調査結果は示していると述べました。

  • 大多数は、公開されているセキュアなソフトウェア開発ライフサイクル(SSDLC)に従っていると回答していますが、脆弱性をテストした金融ソフトウェアおよびテクノロジーは、平均して全体の3分の1程度に過ぎません。
  • テストを行っている場合でも、大半は、テクノロジーのセキュリティ保護をペネトレーション・テストとセキュリティ・パッチ管理に依存しています。どちらもソフトウェア開発ライフサイクル(SDLC)の終了時またはリリース後に行います。
  • 当然の帰結として、多くのFSI組織は、ソフトウェアのサイバーセキュリティの脆弱性評価をリリース後になってから行います。ソフトウェアの設計、開発、テストの段階で評価を行うとした回答は半数未満です。したがって、市場に投入する前に金融ソフトウェアおよびシステムのセキュリティの脆弱性を検出できると確信している組織は25%に過ぎないという結果も驚くには当たりません。
  • オープンソース・コードの脆弱性やライセンスの競合を特定して解決するためにソフトウェア・コンポジション解析(SCA)を利用しているという回答はほとんどありませんでした。オープンソース・コードのインベントリを保持し、それを管理するためのプロセスが欠落している組織がほとんどです。
  • 多くのFSI組織は、ソフトウェア開発者向けにセキュア開発のトレーニングを実施していますが、トレーニングを必須にしている組織の割合はわずか(19%)です。
  • FSI組織は、BSIMMやOWASP SAMM(Software Assurance Maturity Model:ソフトウェア保証成熟度モデル)などの独立した外部の評価ツールを使用するよりも、セキュリティ・プログラムの有効性を内部で評価する傾向があります。

「恐ろしいケースも存在する」

以上のすべてを総合すると、悪い兆候が見えてきます。その兆候は、30のFSIモバイル・アプリをリバースエンジニアリングし、180の「重大な」セキュリティ・プログラムを発見した実態を文書化したレポートを著して4月に発表したAiteのシニア・アナリスト、Alissa Knight氏にとっては驚くに当たらないものです。

「恐ろしいケースも存在する」

「8分程度でリバースエンジニアリングすることができました。」とKnight氏は述べています。「ハードコーディングされた認証情報、弱い暗号、秘密鍵の公開などが見つかりました。中には、ユーザー名とパスワードの妥当性検証さえ行っていない恐ろしいケースも存在します。」

Knight氏はさらに、FSIは全般に「API(アプリケーション・プログラミング・インターフェイス)に関するセキュリティ・ハイジーン(衛生状態)がきわめて貧弱だということもわかった」と指摘しました。

Kilbourne氏は、業界としてのFSIはソフトウェア・セキュリティに関して比較的成熟しているものの、「組織は急速に進化するテクノロジー環境に取り組んでおり、ますます高度化する敵に直面している」と指摘しました。

改善のためのツール

しかし、悪い兆候があるからといって絶望的であることにはなりません。業界も進化する可能性があり、調査結果は組織が問題意識を持っていることを示しています。

また、組織は改善するために、いわゆる車輪の再発明をする必要はありません。既に十分に確立された、利用可能な方法が存在します。

専門家が常に言っているように、組織を防弾することは不可能です。しかしハッカーによる侵入をはるかに困難にし、なんとか侵入したハッカーの検出を容易にすることは可能です。

FSI組織はハッカーの検出を容易にすることが可能です。

基本となる最も重要な手段の一つは、「大多数の回答者が現在行っている対策を逆転させること」です。SDLCの最後にペネトレーション・テストとパッチ管理で「リスクを管理」するのではなく、ソフトウェアの専門家が10年以上にわたり説いてきた 「シフトレフト」 を実行するべきです。言い換えると、「最後まで待つな」ということです。開発の最初から最後まで全体にわたってソフトウェアにセキュリティを組み込んでください。

そのためには、複数の自動化ツールを使用して、バグが後になってペネトレーション・テストの段階で発見される前に、あるいは、市場に出ている製品がハッキングされて緊急パッチが必要になる前に、開発段階で発見して修正できるようにする必要があります。

サイバーセキュリティに対する階層的なアプローチを取る

ソフトウェア・コードのすべての欠陥を魔法のように捕捉する「オールインワン」ツールがないことを肝に銘じておくことがきわめて重要です。少なくとも半ダースのツール(略語が多すぎて混乱しそうです)が必要ですが、それとは別に、オープンソース・コンポーネントなど、それぞれに特定の検索ターゲットを設定し、異なる状態(静的、動的、インタラクティブ)でソフトウェア・コードをテストします。

Kilbourne氏は「各ツールは1つの仕事を的確にこなしますが、それぞれ検索する内容が異なります。」と述べています。

ソフトウェア・コードのすべての欠陥を魔法のように捕捉する「オールインワン」ツールはありません。

Synopsysの金融サービス担当マネージング・プリンシパル、Nabil Hannanは、優先順位を設定することから始める必要があると指摘しました。Hannanは、「一度にすべてを見つけようとするのではなく、自動化では発見しやすいものに的を絞るべきだ」と述べました。「複数の分析手法を利用することで、一般的な脆弱性を早期に検出してブロックするための信頼度が高まります。」

確かに、こうしたツールを導入するにはコストがかかりますが、長期的には時間とコストの削減につながります。専門家が言うように、リリース後にソフトウェアにパッチを適用することは、後から「セキュリティの追加」を試みる方法になります。

サードパーティーがセキュリティを台無しにする

第2の基本は、「サードパーティーのリスクに対処すること」です。

まず、サードパーティー・ベンダーに同じセキュリティ・スタンダードを要求します。サードパーティー・ベンダーがセキュアでなければ、自社組織もセキュアではありません。サードパーティー・ベンダーがハッキングされる可能性があれば、自社組織もハッキングされる可能性があります。実際、サイバー犯罪者が被害者のネットワークの侵害を拡大し、被害者のサプライチェーン内の他の組織への侵入も狙って行う行為を表す「アイランドホッピング」という言葉があります。

悪名高く壊滅的な、2013年末の小売業大手Targetに対する侵害はほんの一例に過ぎません。4,000万件のデビットカード番号とクレジットカード番号、住所と電話番号を含む7,000万件の記録を暴露したこの侵害は、あるサードパーティー(暖房、空調、冷凍を扱う契約業者)に対するEメールによるフィッシング攻撃によって実現されました。

そこで、ベンダーに対しては、開発中にソフトウェアをテストし、業界のセキュリティ・スタンダードに準拠していることを実証し、SSIの独立した評価を利用するように要求する必要があります。

Knight氏によると、もう一つのサードパーティーのリスクは、多くのFSI組織がモバイル・アプリの開発を外部委託し、その際にベンダーに提供したAPIキーをベンダーの開発者が「(アプリの)コードにハードコーディング」したとしても気付かないことです。

「ベンダーのセキュリティは控えめに言っても所々に難点があり、その難点には浸透性がある」とKnight氏は指摘します。

また、Hannanは、もう一つの課題として、インサイダーの脅威からサプライチェーンのセキュリティを確保することを挙げました。「この課題は達成することが難しく、完全な自動化はほぼ不可能であり、新しいワークフローとガバナンス・プロセスを必要とする」とHannanは述べました。

従業員は第1の防衛線

3つ目の基本は、「人材をセキュリティに精通させること」です。従業員を訓練し、悪意のあるリンクをクリックするように巧妙に工夫されたフィッシングメール、または攻撃者が法執行機関や人事担当者を装い、従業員の役に立ちたいという欲求を悪用して機密情報を提供させようとする電話による「ビッシング」を見分けられるようにします。

従業員は第1の防衛線

その他のセキュリティの基本:

  • デバイスやサーバーが正しく構成されていることを確認する。デフォルト設定の変更を怠ってCapitol Oneの二の舞になることのないようにご注意ください。
  • パッチの適用を怠らない。パッチを常に注視し、速やかにインストールしてください。
  • エンドツーエンドの暗号化を徹底する。セキュアな暗号鍵管理を装備していることを確認します。

セキュリティの基本の大部分は、夜間に金庫とドアをロックし、警備システムを稼働させるというセキュリティ対策をデジタル化したものです。これらのすべてを実行した組織は業界において平均以上の成果が上がるでしょう。上述のセキュリティの基本は平均を上回りセキュリティリスクを低減するための方法だからです。

金融サービスのサイバーセキュリティに関するレポートを入手する

 

この著者によるその他の情報