改訂された PCI セキュリティ標準化協議会ガイドライン:十分に左にシフトしているか?

この記事のバージョンは、最初に公開されました デジタル・トランザクション・マガジン。

今年、PCI セキュリティ標準委員会はまったく新しいセットをリリースしました ソフトウェアセキュリティガイドライン PCIソフトウェアセキュリティフレームワークの一部として。このアップデートは、ソフトウェアセキュリティのベストプラクティスを最新のソフトウェア開発と一致させることを目的としています。これは、このプロセスが時間の経過とともにどのように変化してきたかを認識した素晴らしい取り組みであり、私たちの生活の大部分が急速にデジタル化されるずっと前に設定されていたセキュリティ基準を再考する必要があります。

これは、私たちの業界が適応可能なガイドライン（ニーズの変化とともに進化するガイドライン）の考え方と、安全な開発プロセスを緩め続けるとすぐに制御不能になりかねないサイバーセキュリティ環境の要求に、より密接に関わっていることの明らかな証拠です。当然のことながら、PCI Security Standards Councilが銀行および金融業界の統治機関としての役割を果たしているため（たとえば、私たちが信頼するソフトウェアのセキュリティ基準を設定して、私たちのお金、クレジットカード、オンライン取引、およびPOSでのすべての保護を保護する）、これらには多くのリスクが伴い、リスクを軽減したいという大きな動機があります。

これらの標準は確かに以前のバージョンよりも改善されており、全体的な品質評価の一環としてセキュリティを優先する迅速で革新的な機能開発における穴を埋めるのにいくらか役立ちますが、まだ長い道のりがあることに気付くのはやや残念な現実です。

いいえ、それは私が「ああ、ハンバグ！」と言っているのではありません。このイニシアチブに。実際のところ、これらの新しいセキュリティガイドラインでは、私たちを左に動かすだけでは十分ではありません。

私たちはまだテストに固執していました（そしてテストが遅すぎました）。

PCI セキュリティ標準フレームワークで見つかった明白な問題の 1 つは、明らかにテストに依存していることです。もちろん、ソフトウェアのテストはまだ必要ですが (SAST/DAST/IAST プロセスにもその役割はあります)、それでも私たちは同じ罠に陥り、異なる結果を期待していました。

誰が後に行を書くのか コード行 私たちが知っていて愛し、信頼しているソフトウェアを作るためですか？ソフトウェア開発者。

スキャンツールと手動によるコードレビューのどちらかで、このコードをテストするなんて、誰がうらやましいと思いますか？アプリケーション・セキュリティ・スペシャリスト。

これらの専門家は何を発見し続けているのでしょうか？何十年も私たちを悩ませてきたのと同じバグ。何年もの間修正方法がわかっている単純なもの: SQL インジェクション、 クロスサイトスクリプティング、 セッション管理の弱点... こいつらにとってはグラウンドホッグデーみたいだ彼らは、開発者自身が長年修正する力を持っていたコード違反を見つけて修正することに時間を費やしました。ただし、セキュリティはプロセスの最優先事項になっていませんでした。特に、機能提供が主流であり、セキュリティが創造的なプロセスとプロジェクト完了の勝利を奪うグリンチであるアジャイル開発の時代には特にそうです。

これはどちらのチームにとっても否定的な評価ではありません。開発者とアプリケーション・セキュリティ・プロフェッショナルはどちらも、やるべき非常に重要な仕事を抱えていますが、互いに邪魔をし続けています。このような状況は、欠陥のある SDLC を永続させるだけです。セキュリティ意識がほとんどない開発者が、ネガティブなセキュリティ文化の中で活動し、安全でないコードを生成し、最初に記述した後でそれをスキャン、評価、修正する必要があります。AppSecは、本当に複雑な問題を解決する時間がほとんどありません。なぜなら、AppSecは繰り返し発生する小さな問題に追いつきすぎていて、放置しておくと企業にとって大惨事になる可能性があるからです。

コードのセキュリティ上の弱点をすべてテストに任せることで、時間、お金、リソースを浪費しています。また、1 日おきに大規模なデータ漏えいが発生しているため、この方法は、たとえあったとしても最適に機能していないことは明らかです。これらの新しい標準は、まだ最終製品の状態を評価している段階です (おそらく、すべての開発者がセキュリティを意識していると仮定していますが、そうではありません)。すでに構築されているようなものです。これは、欠陥の修正に最も費用がかかり、難しい段階です。おしゃれな新しい家を建て、入居したその日に安全チームを招いて危険をチェックするようなものです。基礎に何か問題があったら、そのエリアに行って問題に取り掛かるのにかかる時間、費用、そして頭が痛くなることを想像してみてください。多くの場合、最初からやり直すほうが簡単で安価です (最初のバージョンを構築したすべての人にとっては、まったく満足のいくプロセスではありません)。

私たちは絶対にゼロから取り組む必要があります。開発チームにセキュリティのベストプラクティスに取り組んでもらい、効率的に安全にコーディングするための知識を彼らに与え、ポジティブなセキュリティ文化を創造して維持することに加えて、開発チームにセキュリティのベストプラクティスを提供することです。 ごと 職場。

それは学習曲線ですか?ええ、そうです。無理なの？絶対にありません。退屈な骨の折れる作業である必要はありません。開発者の創造的で問題解決能力に直接訴えるトレーニング方法は、銀行や金融セクターですでに大きな成功を収めています。 ラス・ウルフェスのキャピタル・ワンでの経験 何らかの兆候です。

私たちはまだ完璧な「エンドステート」を探しています。

更新されたPCIセキュリティ基準を、その意図された文脈で見れば、たとえば、完成したユーザーがすぐに使える金融商品は、最適なセキュリティと安全性を実現するためにこれらのベストプラクティスに従う必要があるというように、まったく問題ありません。しかし、私の考えでは、金融企業であろうとなかろうと、すべての企業が、機能の品質と高水準のセキュリティの両方を代表するソフトウェアの最終段階に到達する可能性が最も高いのは、一歩下がって、サイクルの最初からこれを行う方がはるかに効率的であることに気づいた場合です。

その完璧なエンドステート？製品がスキャンされ、手作業でレビューされ、完璧でエラーのない状態になったときに起こるケースをご存知ですか？まだ探している最中です。現時点ではユニコーンです。

なぜそんなにとらえどころがないのですか?いくつかの要因があります。

• スキャンツールは信頼されていますが、常に効果的であるとは限りません。誤検出は、DAST/SAST/PCIスキャンを組み合わせても、コードベースで考えられるすべての脆弱性を特定して明らかにすることができないという事実と同様に、その使用による苛立たしい時間の浪費の副産物です。確かに、彼らは かもしれない はっきりさせておきますが本当に全部探しているんですか?攻撃者は 1 つの脆弱性を悪用するだけで、保護されていると思われるものにアクセスすることができます。
• 開発者は同じ過ちを犯し続けています。セキュリティに関する知識は開発者間で分散されておらず、よく知られて文書化されている「安全なコードレシピ」(優れた安全なコードパターン) もありません。
• 協調的で前向きなセキュリティ文化の構築には重点が置かれていません。
• 開発者は、クリエイティブなプロセスやアジャイル開発手法を中断することなく、開発する製品にセキュリティを組み込むための適切なツールを手に入れる必要があります。

これらのガイドラインは、ソフトウェアが遵守すべきセキュリティ基準の強力な検証チェックリストですが、ソフトウェアをその状態にする最善の方法は議論の余地があります。

安全でないソフトウェアがあるのはスキャナーがないからであり、開発者にガイドとなる使いやすくわかりやすいセキュリティツールが提供されていないため、安全でないソフトウェアがあるのです。

私たちは今、進化の時代にいます。長年にわたり、ソフトウェアセキュリティは一般的にオプションでした。今日では、特に機密情報 (金融、医療、社会保障...) の管理者にとっては必須です。

PCI Security Standards Councilはベンチマークの設定を支援していますが、業界からの尊敬と影響力をもって、適切で積極的なトレーニングとツールに重点を置いて、開発者向けの実践的なガイドラインを含めるよう取り組んでほしいと思います。現時点では、開発チームがセキュリティを認識し、コンプライアンスを遵守していることを確認するよう組織に圧力をかけることはありません。また、多くの開発者は、危害を加えようとする人々に悪用された場合、これらの小さくて簡単に修正できるミスの大きさを理解していません。

人生でやりがいのあることなら何でも期待されるように、本当に変化を起こすには村が必要です。そして、空気中の変化が（願わくば）私たち全員を席巻してくれるでしょう。 さらに左へ。