あなたの組織は本当にDevSecに対応していますか？それをテストしてみましょう。
2020年もようやく半分が過ぎようとしていますが、2019年上半期と比較して、盗まれたデータが273％増加しており、すでに厳しいデータ侵害の記録を打ち立てようとしています。最近では、「まだどれだけのデータが盗まれていないのか」という問いかけの方が正確です。COVID-19パンデミックのような世界的な出来事により、これらの攻撃は頻度と効力を増すばかりで、ターゲットはますます脆弱になっています。
セキュリティはもはやオプションではなく、私たちの焦点は先制攻撃でなければならないということは、以前から誰もが知っていたことです。そのためには、SDLCに関わるすべての人、特に開発者がセキュリティを意識する必要があります。これはDevSecOpsの「DevSec」の部分であり、気候変動に対応した理想的なソフトウェア開発手法ですが、多くの組織はこれを効果的に実行するための準備が十分ではありません。
あなたの組織を念頭に置いて、これらの質問をあなたの役割の文脈で考えてみてください。DevSecのテストにかけると、どうなるでしょうか？
DevSec Self-Assessment: あなたのSDLCの庭は、セキュリティを意識したエンジニアを開花させる準備ができていますか？
様々なサイバーセキュリティのリスク要因が、平均的なCISOを夜も眠れない状態にしているかもしれません。しかし気になるのは、多くの企業がセキュリティの優先順位を高めている一方で、その内部アプローチは、潜在的な災害（少なくとも、AppSecチームの大規模な頭痛の種やソフトウェアの出荷遅延）を軽減するのに十分なほど強固ではないかもしれないという現実です。
DevSecOpsは、セキュリティの理想的な現状かもしれませんが、この方法論で取り組んでいる企業はほとんどありません。もしあなたがまだアジャイル（あるいはウォーターフォール）であるならば、セキュリティはまだプロセスから遠く離れた専門家の領域と考えられていることが多く、SDLCの後半に起動して、コードのホットフィックスで開発者の一日を台無しにするために現れます。このような環境では、開発セキュリティ文化を推進することは困難です。開発者は機能構築を好み、優先しますが、セキュリティを望ましいスキルアップの経路と見なすほどの実践的な経験はありません。実際、彼らがセキュリティに触れる機会は、フラストレーションやネガティブなものであるかもしれません。ソフトウェア開発プロセスに関わるすべての人に、セキュリティを意識したアプローチを浸透させるためには、この問題を早急に解決しなければなりません。
中小企業の 60% がサイバー攻撃を受けてから 6 ヶ月以内に倒産しているという統計は、非常に興味深いものです。他の災害と同様に、適切な計画を立てなければ、その影響ははるかに大きくなります。
脅威のモデリングは、セキュリティのベスト・プラクティスの重要な要素であり、AppSec の専門家は、攻撃対象の全容を評価し、適切な防御策、対策、計画を立てることができます。DevSecOps を全面的に採用している企業では、CI/CD パイプラインの早い段階でセキュリティを有効にし、これまでのように生産を遅らせることがないようにしています。セキュリティ、安全なコーディング、継続的な配信はすべてプロセスの一部であり、開発チームには、気密性の高いコードを吐き出すエンジンの主要な構成要素となるために必要なリソースと機会が与えられています。- 開発マネージャーはセキュリティのベストプラクティスを優先していますか？
好むと好まざるとにかかわらず、開発マネージャーはチームのロールモデルです。それは、オフィスでサンダルを履いているとか、「上から目線の管理」をしているといった、文化や雰囲気の問題だけではありません。彼らの仕事の優先順位は、必然的にチームメンバーに吸収されます。もし、セキュリティが重要な目標の一部でなかったり、トレーニングやサポートの面で計画されていなかったりすると、その下にいるエンジニアは見逃してしまい、ビジネスは必要以上に危険にさらされることになります。
私の経験では、人を萎縮させる最も早い方法は、理由を説明せずに、現在のアプローチとは異なることをしなければならないと伝えることです。
「変える」と言われることは、以前のアプローチが間違っていたことを意味しますが、多くの場合、それは後に物事をより簡単に、より効率的にするための単なる強化であることが多いのです。
DevSecOpsは、セキュリティが共有された責任でなければ機能しません。開発者は、自分の役割を果たすために、適切なツール、サポート、トレーニングを必要としています。そして、これを全体的なセキュリティ・プログラムの一部として展開し、完成させるには時間が必要です。最悪のアプローチは、開発者を圧倒し、疎外するものです。開発者があまりにも多くの競合する優先事項を抱え、自分自身を狂わせることなくそれらを管理するための支援を得られない場合がこれに該当します。これは文化的な転換であり、一朝一夕にできるものではありません。
セキュリティの専門家は非常に不足しており、現在の数よりもはるかに多くの人材が必要とされています。これは当然のことですが、よりセキュリティに特化した役割に移る開発者が増えています。一般的には、「セキュリティ・エンジニア」や「DevOpsエンジニア」といった肩書きが多いかもしれません（運が良ければ、この肩書きは徐々に「DevSecOpsエンジニア」に変化していくでしょう！）。DevOpsエンジニアは、事実上あらゆるアプリケーションの機能を開発し、真のCI/CDパイプラインを使ってデプロイすることができます。すべてをエンド・ツー・エンドで行い、通常はセキュリティ意識も高いです。その意味で、彼らはある種の魔法のような存在であり、結果的に希少な存在となっています。
しかし、一部の企業は、このような専門家のエンジニアを雇い、チームに入れて、開発プロセスのすべての段階で、すべてのセキュリティ問題を解決してくれると期待し、これだけで万能だと勘違いしてしまいます。DevSecOpsのマジシャンに過度の負担をかけてしまうと、最初に雇われたときのように、チェック、バランス、セキュリティの精度を欠いたまま、安全でないコードを出荷することになってしまいます。一般の開発チームがスキルアップし、積極的なセキュリティ環境で育成され、有意義な方法で負荷を分担できるようになることが最も重要です。
自分の組織で見たいと思う変化を見つけてください。
セキュリティプログラムの一環としてしっかりとしたトレーニングを実施すれば、開発メンバーの中に隠れた優秀な人材を発見することができます。このような人たちは、日々の仕事の中で否定的な経験をしていても、安全なコーディングやセキュリティのベストプラクティスに情熱を持っている人たちです。このような人たちは、チーム内のセキュリティ・チャンピオンの有力な候補者です。セキュリティとエンジニアリングの間の接点であり、他の人の模範となり、意識を高く保ち、エンゲージメント・イニシアチブを支援する人です。彼らの対人スキルは、セキュリティの喜びを広く伝え、開発者のニーズを経営陣やセキュリティチームに提言する上で非常に重要です。
What's in it for me?" の会話は、前向きな一歩となる。
「dev」から「DevSec」へと飛躍することは、開発者のキャリアにとって素晴らしい後押しとなります。セキュリティ意識の高い開発者は、セキュリティを理解し、自分がコントロールできる領域ではセキュリティに責任を持ち、高品質なコードだけが安全なコードであることを理解して活動するように努力しています。一般的に、開発者は改善したい、新しい問題に取り組みたい、仲間内で目立つような羨ましい機能を作りたいと思っています。彼らに、より高いレベルのソフトウェア開発に到達するための道筋を与えれば、双方にメリットがあります。
DevSecのドリームチームを作るのに遅すぎるということはありません。
もしあなたが開発者を管理していたり、AppSec意識向上チームを率いていたり、あるいはセキュリティ・プログラム戦略の策定に尽力している多くの人の一人であるならば、今こそ、「左遷」よりもさらに上を行くべき時です。適切なトレーニング、ツール、および環境があれば、開発者のためのセキュリティ・インキュベーターを作ることができ、すべての関係者に大きな利益をもたらします。このチェックリストで改善すべき点がいくつか見つかったのであれば、SDLCの初期段階からリスクを低減できるDevSec主導のエンジニアリング部門に向けて組織を準備する絶好の機会となります。
マティアス・マドゥ博士
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
セキュアコーディングに関する最新の知見をブログでご紹介しています。
当社の豊富なリソースライブラリは、安全なコーディングアップスキルに対する人間的なアプローチを強化することを目的としています。
開発者主導のセキュリティに関する最新の研究成果を入手する
ホワイトペーパーからウェビナーまで、開発者主導のセキュアコーディングを始めるために役立つリソースが満載のリソースライブラリです。今すぐご覧ください。
あなたの組織は本当にDevSecに対応していますか？それをテストしてみましょう。
2020年もようやく半分が過ぎようとしていますが、2019年上半期と比較して、盗まれたデータが273％増加しており、すでに厳しいデータ侵害の記録を打ち立てようとしています。最近では、「まだどれだけのデータが盗まれていないのか」という問いかけの方が正確です。COVID-19パンデミックのような世界的な出来事により、これらの攻撃は頻度と効力を増すばかりで、ターゲットはますます脆弱になっています。
セキュリティはもはやオプションではなく、私たちの焦点は先制攻撃でなければならないということは、以前から誰もが知っていたことです。そのためには、SDLCに関わるすべての人、特に開発者がセキュリティを意識する必要があります。これはDevSecOpsの「DevSec」の部分であり、気候変動に対応した理想的なソフトウェア開発手法ですが、多くの組織はこれを効果的に実行するための準備が十分ではありません。
あなたの組織を念頭に置いて、これらの質問をあなたの役割の文脈で考えてみてください。DevSecのテストにかけると、どうなるでしょうか？
DevSec Self-Assessment: あなたのSDLCの庭は、セキュリティを意識したエンジニアを開花させる準備ができていますか？
様々なサイバーセキュリティのリスク要因が、平均的なCISOを夜も眠れない状態にしているかもしれません。しかし気になるのは、多くの企業がセキュリティの優先順位を高めている一方で、その内部アプローチは、潜在的な災害（少なくとも、AppSecチームの大規模な頭痛の種やソフトウェアの出荷遅延）を軽減するのに十分なほど強固ではないかもしれないという現実です。
DevSecOpsは、セキュリティの理想的な現状かもしれませんが、この方法論で取り組んでいる企業はほとんどありません。もしあなたがまだアジャイル（あるいはウォーターフォール）であるならば、セキュリティはまだプロセスから遠く離れた専門家の領域と考えられていることが多く、SDLCの後半に起動して、コードのホットフィックスで開発者の一日を台無しにするために現れます。このような環境では、開発セキュリティ文化を推進することは困難です。開発者は機能構築を好み、優先しますが、セキュリティを望ましいスキルアップの経路と見なすほどの実践的な経験はありません。実際、彼らがセキュリティに触れる機会は、フラストレーションやネガティブなものであるかもしれません。ソフトウェア開発プロセスに関わるすべての人に、セキュリティを意識したアプローチを浸透させるためには、この問題を早急に解決しなければなりません。
中小企業の 60% がサイバー攻撃を受けてから 6 ヶ月以内に倒産しているという統計は、非常に興味深いものです。他の災害と同様に、適切な計画を立てなければ、その影響ははるかに大きくなります。
脅威のモデリングは、セキュリティのベスト・プラクティスの重要な要素であり、AppSec の専門家は、攻撃対象の全容を評価し、適切な防御策、対策、計画を立てることができます。DevSecOps を全面的に採用している企業では、CI/CD パイプラインの早い段階でセキュリティを有効にし、これまでのように生産を遅らせることがないようにしています。セキュリティ、安全なコーディング、継続的な配信はすべてプロセスの一部であり、開発チームには、気密性の高いコードを吐き出すエンジンの主要な構成要素となるために必要なリソースと機会が与えられています。- 開発マネージャーはセキュリティのベストプラクティスを優先していますか？
好むと好まざるとにかかわらず、開発マネージャーはチームのロールモデルです。それは、オフィスでサンダルを履いているとか、「上から目線の管理」をしているといった、文化や雰囲気の問題だけではありません。彼らの仕事の優先順位は、必然的にチームメンバーに吸収されます。もし、セキュリティが重要な目標の一部でなかったり、トレーニングやサポートの面で計画されていなかったりすると、その下にいるエンジニアは見逃してしまい、ビジネスは必要以上に危険にさらされることになります。
私の経験では、人を萎縮させる最も早い方法は、理由を説明せずに、現在のアプローチとは異なることをしなければならないと伝えることです。
「変える」と言われることは、以前のアプローチが間違っていたことを意味しますが、多くの場合、それは後に物事をより簡単に、より効率的にするための単なる強化であることが多いのです。
DevSecOpsは、セキュリティが共有された責任でなければ機能しません。開発者は、自分の役割を果たすために、適切なツール、サポート、トレーニングを必要としています。そして、これを全体的なセキュリティ・プログラムの一部として展開し、完成させるには時間が必要です。最悪のアプローチは、開発者を圧倒し、疎外するものです。開発者があまりにも多くの競合する優先事項を抱え、自分自身を狂わせることなくそれらを管理するための支援を得られない場合がこれに該当します。これは文化的な転換であり、一朝一夕にできるものではありません。
セキュリティの専門家は非常に不足しており、現在の数よりもはるかに多くの人材が必要とされています。これは当然のことですが、よりセキュリティに特化した役割に移る開発者が増えています。一般的には、「セキュリティ・エンジニア」や「DevOpsエンジニア」といった肩書きが多いかもしれません（運が良ければ、この肩書きは徐々に「DevSecOpsエンジニア」に変化していくでしょう！）。DevOpsエンジニアは、事実上あらゆるアプリケーションの機能を開発し、真のCI/CDパイプラインを使ってデプロイすることができます。すべてをエンド・ツー・エンドで行い、通常はセキュリティ意識も高いです。その意味で、彼らはある種の魔法のような存在であり、結果的に希少な存在となっています。
しかし、一部の企業は、このような専門家のエンジニアを雇い、チームに入れて、開発プロセスのすべての段階で、すべてのセキュリティ問題を解決してくれると期待し、これだけで万能だと勘違いしてしまいます。DevSecOpsのマジシャンに過度の負担をかけてしまうと、最初に雇われたときのように、チェック、バランス、セキュリティの精度を欠いたまま、安全でないコードを出荷することになってしまいます。一般の開発チームがスキルアップし、積極的なセキュリティ環境で育成され、有意義な方法で負荷を分担できるようになることが最も重要です。
自分の組織で見たいと思う変化を見つけてください。
セキュリティプログラムの一環としてしっかりとしたトレーニングを実施すれば、開発メンバーの中に隠れた優秀な人材を発見することができます。このような人たちは、日々の仕事の中で否定的な経験をしていても、安全なコーディングやセキュリティのベストプラクティスに情熱を持っている人たちです。このような人たちは、チーム内のセキュリティ・チャンピオンの有力な候補者です。セキュリティとエンジニアリングの間の接点であり、他の人の模範となり、意識を高く保ち、エンゲージメント・イニシアチブを支援する人です。彼らの対人スキルは、セキュリティの喜びを広く伝え、開発者のニーズを経営陣やセキュリティチームに提言する上で非常に重要です。
What's in it for me?" の会話は、前向きな一歩となる。
「dev」から「DevSec」へと飛躍することは、開発者のキャリアにとって素晴らしい後押しとなります。セキュリティ意識の高い開発者は、セキュリティを理解し、自分がコントロールできる領域ではセキュリティに責任を持ち、高品質なコードだけが安全なコードであることを理解して活動するように努力しています。一般的に、開発者は改善したい、新しい問題に取り組みたい、仲間内で目立つような羨ましい機能を作りたいと思っています。彼らに、より高いレベルのソフトウェア開発に到達するための道筋を与えれば、双方にメリットがあります。
DevSecのドリームチームを作るのに遅すぎるということはありません。
もしあなたが開発者を管理していたり、AppSec意識向上チームを率いていたり、あるいはセキュリティ・プログラム戦略の策定に尽力している多くの人の一人であるならば、今こそ、「左遷」よりもさらに上を行くべき時です。適切なトレーニング、ツール、および環境があれば、開発者のためのセキュリティ・インキュベーターを作ることができ、すべての関係者に大きな利益をもたらします。このチェックリストで改善すべき点がいくつか見つかったのであれば、SDLCの初期段階からリスクを低減できるDevSec主導のエンジニアリング部門に向けて組織を準備する絶好の機会となります。
