Insight sobre código seguro

Este artículo apareció originalmente en Information Security Buzzy fue recogido por otros medios. Se ha actualizado para su distribución aquí.

A finales del año pasado, la increíble comunidad de MITRE publicó su lista de los 25 errores de software más peligrosos de la CWE que afectaron al mundo en 2019. Esta lista no se basa en una opinión, sino que es el resultado de un análisis multifacético que utiliza el trabajo de organizaciones como el NIST, así como los datos publicados de Common Vulnerabilities and Exposures (CVE). Para determinar los "principales" defectos, se atribuye una puntuación basada en su gravedad, capacidad de explotación y prevalencia en el software actual. No es el tipo de lista que va a ganar ningún elogio positivo, eso es seguro.

Sin embargo, a diferencia de la mayoría de los resúmenes anuales, muchos de los participantes en esta lista han aparecido antes... una y otra vez. Si ésta fuera la lista de los Billboard Hot 100, sería como si Britney Spears'Baby One More Time y los Backstreet Boys'I Want It That Way aparecieran cada año desde su lanzamiento inicial. ¿Y por qué he elegido esas canciones? Pues porque tienen unos veinte años de antigüedad (¿te sientes ya antiguo?), al igual que algunos de esos peligrosos errores de software que siguen asolándonos en 2020 a pesar de haber sido descubiertos hace décadas.

¿Por qué siguen siendo tan peligrosos los viejos bichos? ¿No sabemos cómo solucionarlos?

El número seis de la lista actual del MITRE es el CWE-89, más conocido como inyección SQL (SQLi). La vulnerabilidad SQLi se descubrió por primera vez en 1998, cuando muchos de nosotros todavía hacíamos nuestras preguntas más candentes a Jeeves en lugar de a Google. Poco después se dio a conocer una solución y, sin embargo, sigue siendo una de las técnicas de hacking más utilizadas en 2019. El informe de Akamai Estado de Internet reveló que SQLi fue el culpable de dos tercios de todos los ataques a aplicaciones web.

En cuanto a la complejidad, la inyección SQL está lejos de ser un exploit de nivel genio. Es una solución sencilla para un desarrollador web, y sabemos sin ninguna duda cómo evitar que esta vulnerabilidad exponga datos valiosos a un atacante... el problema es que para muchos desarrolladores, incluso hoy en día, la seguridad no es una prioridad. Puede que esto fuera más fácil hace veinte años, pero con el enorme volumen de software que se está creando hoy y en el futuro, esto ya no puede seguir siendo la norma.

Los desarrolladores operan en un sistema roto (la mayor parte del tiempo).

Es demasiado fácil sentarse y culpar a los desarrolladores por entregar un código "malo". La verdad es que sus prioridades difieren enormemente de las del equipo de seguridad. Al equipo de desarrollo medio se le pide que haga un software bonito y funcional lo más rápido posible. La insaciable necesidad de software de la sociedad asegura que los equipos de desarrollo ya están sobrecargados, y la seguridad no es una consideración primordial; después de todo, ¿no es por eso que existen los especialistas en seguridad de aplicaciones? Los ingenieros de software están acostumbrados a tener una relación algo fría con la seguridad: sólo tienen noticias de ellos cuando surgen problemas, y esos problemas pueden retrasar la producción de su duro trabajo.

En el otro lado de la valla, los especialistas en seguridad de aplicaciones están hartos de arreglar errores de hace décadas que siguen apareciendo en cada análisis y revisión manual del código. Estos especialistas son caros y escasos, y su tiempo está mucho mejor invertido en fallos de seguridad complejos en lugar de aplastar errores conocidos una y otra vez.

Existe una cultura tácita de señalamiento entre estos equipos, pero tienen (o deberían tener) el mismo objetivo: un software seguro. Los desarrolladores operan en un entorno que rara vez les da la mejor oportunidad de éxito en términos de codificación segura; las mejores prácticas de seguridad rara vez se enseñan como parte de su educación terciaria, y la formación en el trabajo es a menudo demasiado infrecuente, o completamente ineficaz. Hay una clara falta de énfasis en la concienciación sobre la seguridad y en la educación en profundidad y relevante, y el resultado es el coste astronómico de arreglar viejos fallos en el código comprometido, además de la amenaza inminente de una violación de datos que acabe con la reputación.

El factor humano, también conocido como "¿Por qué todas estas herramientas no hacen más seguros nuestros datos?"

Otro problema que aparece con frecuencia es que, en lugar de la formación, se pone un vasto arsenal de herramientas de seguridad a la tarea de encontrar problemas antes de que el software sea liberado en la naturaleza. El conjunto de herramientas de escaneo y protección de aplicaciones(SAST/DAST/RASP/IAST) puede ciertamente ayudar a la producción de software seguro, pero vienen con sus propios problemas. Depender completamente de ellas no garantiza la seguridad, porque:

• Ninguna herramienta puede buscar todas las vulnerabilidades, en todas las estructuras y en todos los casos de uso.
• Pueden ser lentos, especialmente cuando se ejecutan en tándem para proporcionar un análisis de código estático y dinámico
• Los falsos positivos siguen siendo un problema; a menudo detienen la producción y requieren una revisión manual innecesaria del código para dar sentido a las alertas
• Crean una falsa sensación de seguridad, ya que la codificación segura no tiene prioridad con la expectativa de que estas herramientas detecten cualquier problema.

Las herramientas ciertamente descubrirán fallos de seguridad que pueden ser parcheados, pero ¿encontrarán todo? Es imposible garantizar una tasa de aciertos del 100%, y un atacante sólo necesita una puerta abierta para entrar y arruinarle el día.

Afortunadamente, muchas organizaciones se están dando cuenta del factor humano que entra en juego en las vulnerabilidades del software. La mayoría de los desarrolladores no están adecuadamente formados para la codificación segura, y su conciencia general de seguridad es baja. Sin embargo, se encuentran al principio del ciclo de vida del desarrollo de software y están en una posición privilegiada para evitar que las vulnerabilidades lleguen al código comprometido. Si codificaran de forma segura desde el principio, serían la primera línea de defensa contra los devastadores ciberataques que nos cuestan miles de millones cada año.

Los desarrolladores deben tener la oportunidad de prosperar, con una formación que hable su idioma, que sea relevante para su trabajo y que los entusiasme activamente con la seguridad. Un código sin errores debería ser un motivo de orgullo, al igual que construir algo funcionalmente genial te hará ganar el respeto de tus compañeros.

Un programa de seguridad moderno debe ser una prioridad empresarial.

Los equipos de desarrollo no pueden ponerse de pie por sí mismos y promulgar una conciencia de seguridad positiva en toda la empresa. Necesitarán las herramientas, los conocimientos y el apoyo adecuados para incorporar la seguridad al proceso de desarrollo de software desde el principio.

Está claro que los viejos métodos de formación no funcionan si la lista de MITRE sigue mostrando tantos fallos de seguridad antiguos, así que pruebe algo nuevo. Busque soluciones de formación que sean:

• Práctica; a los desarrolladores les gusta "aprender haciendo", no viendo cabezas parlantes en vídeos
• Relevante; no les hagas entrenar en C# si están usando Java todos los días
• Atractivo; el aprendizaje por bocados es fácil de digerir y permite a los desarrolladores seguir ampliando sus conocimientos previos
• Medible; no se limita a marcar una casilla y seguir adelante. Garantizar la eficacia de la formación y crear vías de mejora
• Diversión; mira cómo puedes crear conciencia de seguridad además de apoyar una cultura de seguridad positiva, y cómo esto puede crear un ambiente de equipo cohesivo.

La seguridad debería ser una prioridad para todos los miembros de la organización, y el CISO debería ser visible y transparente en los esfuerzos realizados en todos los niveles para mantener nuestros datos más seguros. ¿Quién quiere escuchar la misma canción de siempre? Es hora de tomarse en serio lo de aplastar los viejos fallos para siempre.

これは地味な統計だね？ 中小企業の 60% は、サイバー攻撃が成功してから6か月以内に廃業します*。大企業は何百万（あるいは数十億！）もの大企業が大量に出稼ぎ出しています。一方、ブランドの評判は薄れていきました。安全なコーディング手法を採用する組織が増えるにつれ、「シフトレフト」が起こっています。DevSecOps の台頭により、SDLC が始まった当初から安全なコードが焦点になりつつあります。この傾向が現実世界に及ぼす影響を調査するために、Secure Code WarriorとEvans Data Corp***は、安全なコーディング、安全なコード慣行、およびセキュリティ運用に対する開発者の態度に関する最近の調査を委託しました。

左へのシフト — 多くのレベルでのシフト

企業が脆弱性の修正には事後に30倍の費用がかかることに気付くにつれ、先制措置が新しいゴールドスタンダードになりました*。しかし、このような対策が効果的であるためには、 みんな SDLCでは、特に開発者がセキュリティを意識している必要があります。

‍シフトワン — じゃあ、今は誰が責任者なの？

の台頭とともに DevSecOps、組織は安全なコーディング手法を採用しています。その結果、私たちの調査で最初に明らかになった変化の 1 つは、コードセキュリティに対する責任が運用レベルにシフトしていることです。

開発者と開発マネージャーに「コードセキュリティの最終的な責任は誰にあるべきか」と尋ねたところ、、46% がプロジェクト/チームリーダーであると回答しました。これは、責任をアプリケーションセキュリティチームに任せるべきだと答えた人のほぼ2倍です。

これは、セキュリティ責任が従来のアプリケーションセキュリティチームから開発チームリーダーにシフトしていることを明確に示しています。

シフト2 — マネージャーの役割の変化  

セキュア・コード・トレーニングを実施しなければならないというプレッシャーは、さまざまな方向からマネージャーに押し寄せています。

41% が組織的に必要であることを明らかにしている セキュアコードトレーニング 上級管理職から来ています。規制遵守に対する要求の高まりも要因です。

マネージャーは、従来の開発からDevSecOpsへの移行を支援する上で重要な役割を果たしており、トレーニングやツールの購入決定の重要な意思決定者としての地位も高まっています。

‍シフト3 — 開発者のステップアップ

しかし、下層から変化を求める圧力も高まっています。マネージャーの 24% が、開発者からの提案や推奨により、安全なコーディング手法を実装していると回答しています。この点は、自社のセキュリティプログラムに貢献する開発者としての役割がますます重要になっていることを浮き彫りにしています。DevSecOps への移行により、予防的で安全なコーディング手法が新たに重視されるようになったことで、開発者は「防御の最前線」の役割にシフトしています。

シフト4 — チームダイナミクスの向上  

安全なコードプラクティスを実装することはソフトウェアの品質に重大な影響を与えるだけでなく、チームの働き方をより良い方向に変えます。調査対象の開発者の 60% は、安全なコードプラクティスを採用することで他の開発者とのコミュニケーションが向上したと考えていますが、そのメリットはそれだけではありません。

調査対象となった開発者とマネージャーの半数は、安全なコーディング慣行が開発者とそのリーダー間の協力の強化につながったと回答しました。46% が、開発者と利害関係者間のコラボレーションが増えたと回答しました。同時に、41% がリーダーと利害関係者間の協力関係が強化されたと回答しました。

DevSecOpsは、チーム、リーダー、利害関係者を新しい方法で結びつけ、ソフトウェア開発ライフサイクルのさまざまな役割や段階にわたる協力を強化します。

調査対象のマネージャーの 62% が、安全なコードプラクティスがコードリリースのスピードアップに役立つと回答しています。この単一の事実がこれらすべての変化と相まって、DevOps アプローチに移行することの明らかなメリットが浮き彫りになっています。しかし、この記事の前半で述べたように、このような対策が効果的であるためには、 みんな SDLCではセキュリティに対応している必要があります。この洞察は、組織が開発者をどのようにトレーニングするかに重大な影響を及ぼします。チームは最近特定された脆弱性について学び、コーディングに使用する特定の言語、つまりフレームワークで学ぶ必要があります。つまり、日常業務の中で、コード内の既知の脆弱性を発見し、特定し、修正する方法を理解する必要があります。このようなトレーニングにより、チームはリスクの最前線から防御の最前線へと変わります。

セキュアコーディングにおける変革の推進者として、Secure Code Warriorは人間主導のアプローチを採用して組織の「シフトレフト」を支援し、全体的なセキュリティアプローチを事後対応型から事前対応型へと移行します。

DevSecOpsの未来を実現するためのマネージャー、開発者、組織のニーズを一致させる、実践的で魅力的で実績のある安全なコードトレーニングについて詳しく知りたい場合は、 今すぐデモを予約。

‍

*中小企業の60％は、ハッキングされてから6か月以内に閉鎖されます。
‍https://cybersecurityventures.com/60-percent-of-small-companies-close-within-6-months-of-being-hacked/

**IBM Software Group; コード欠陥の最小化によるソフトウェア品質の向上と開発コストの削減
‍https://docplayer.net/11413245-Minimizing-code-defects-to-improve-software-quality-and-lower-development-costs.html

***対応から予防への移行：アプリケーションセキュリティ2021の変わりゆく様子 セキュア・コード・ウォリアーとエバンス・データ・コーポレーション
https://scw.buzz/3169uzS

2019年6月11日、米国国立標準技術研究所（ニスト）は、詳細を説明した最新のホワイトペーパーをリリースしました いくつかの行動計画 削減用 ソフトウェアの脆弱性 そしてサイバーリスク。タイトル セキュアソフトウェア開発フレームワーク (SSDF) の採用によるソフトウェア脆弱性のリスクの軽減、NISTは、データ侵害による厄介な（費用のかかることは言うまでもありません）の結果を回避するための確固たるガイドラインを組織に提供しています。

SSDFは意図的に汎用的なものであり、すべての組織がまったく同じソフトウェア・セキュリティ目標を持っていることを前提としているわけではなく、またそれを達成するための正確なメカニズムを規定しているわけでもないことに注意することが重要です。主な目的は、セキュリティのベストプラクティスを実装することです。ライターのDonna Dodson氏は次のように述べています。「各セキュリティプロデューサーが適用可能なすべてのプラクティスに従うことが望まれていますが、各プラクティスの実装の程度は、プロデューサーのセキュリティ前提によって異なることが予想されます。これらのプラクティスは実装者にとって柔軟性を提供しますが、解釈の余地があまり大きくなりすぎないようにすることも明確です。」

もちろん、私が特に興味を持ったのは、開発者向けのソフトウェア・セキュリティ・トレーニングに関する具体的な内容でした。開発者がソフトウェア開発プロセスの初期段階から組織を守るためには、十分なトレーニングが必要であることは以前からわかっていました... しかし、何がそうなのでしょうか？ 十分な、正確に?世の中にはさまざまな意見があります。しかし、ようやく大きなポジティブな結果につながる方向に限界が押し広げられていると思います。

セキュリティトレーニングと効果的なセキュリティトレーニングがあります。

これまで、ソフトウェア・セキュリティ・トレーニングをより効果的に実施し、開発者のニーズに応え、それに合わせて調整する必要性について長々と話してきました。今でも、多くの組織では、せいぜい「チェックする」だけの練習に過ぎません。おそらく、数時間のビデオトレーニングがあるかもしれませんし、授業ベースの学習のためにツールを使わない貴重な時間を費やすことさえあるかもしれません。よく知られている (通常は簡単に修正できる) 脆弱性を悪用する攻撃者による大規模なデータ侵害が 1 日おきに発生しているという事実は、ソフトウェアセキュリティトレーニングが必要以上に効果的ではないことの証拠です。そして、おそらく最も重要なのは、トレーニングがまったく効果があったかどうかを検証するための準備がほとんど整っていないことです。脆弱性はより早く修正されたのでしょうか。コードの脆弱性は減少しているのか？受講者は実際にトレーニングを完了したのか、それとも「次へ」をクリックして修了しただけなのか。

開発者は忙しい人で、厳しい締め切りに間に合うように一生懸命働いています。セキュリティはたいてい不便であり、サイバーリスクをうまく軽減するための知識を教育中に身につけていることはほとんどありません。通常、「セキュリティ」という言葉は、AppSecチームのメンバーが自分の仕事の欠点を指摘しているときに出てきます。その結果、かなり冷淡で機能不全な関係になってしまいます。「あなたの赤ちゃんは醜いです。直してください」というシナリオ。

これは何を教えてくれますか？これは数十年前の危険信号です。開発者がセキュリティに関して十分な努力をしていないということです。開発者は責任を取る意欲がなく、機能的でありながらセキュリティのベストプラクティスを念頭に置いて作られたソフトウェアを作成するために必要なツールを探す意欲もありません。

開発者は賢く、創造的で、問題を解決するのが大好きです。セキュリティの脆弱性に関する動画を延々と視聴しても、開発者がワクワクしたり、エンゲージメントを維持したりできるとは考えにくいです。私がSANSのインストラクターを務めていたとき、最高のトレーニングは実践的なものであることがすぐにわかりました。そのため、生徒は脳をテストし、事前の学習に基づいて構築する実際の例を使用して、分析し、知的に挑戦することを余儀なくされました。ゲーミフィケーションと友好的な競争は、誰もが新しい概念を理解できるようにすると同時に、応用において有用で実用的なものであり続けるための強力なツールでもあります。

NISTのガイドラインには、次のように明記されています。「安全な開発に貢献する責任を負う役割を担うすべての職員に、役割別のトレーニングを提供する。職務別の研修を定期的に見直し、必要に応じて更新する。そして後で、「サイバーセキュリティスタッフ、セキュリティチャンピオン、上級管理職、ソフトウェア開発者、製品所有者、その他SDLCに関わる人たちの役割と責任を定義する」

この声明は、トレーニングの種類については具体的に述べていませんが、依然として組織を左派にシフトさせ、セキュリティのベストプラクティスを常に念頭に置いておくのに役立ちます。これは、効果的でより具体的なトレーニングソリューションを見つけることに責任を会社に負わせることであり、その結果、開発者が成功するための適切なツールと知識を身に付けることにつながることが期待されます。

文化:ミッシングリンク.

組織が開発者やその他の主要スタッフのトレーニングに時間とリソースを費やし、脆弱性の防止とセキュリティリスクの軽減における彼らの役割に重点を置いていても、組織のセキュリティ文化が根本的に壊れたままであれば、その努力が無駄になることがよくあります。

個人が効果的にトレーニングされ、目標が設定され、期待が明確になれば、セキュリティ環境における自分の位置を理解し、必要に応じて責任を取ることがはるかに容易になります。特に開発者の場合は、最初から安全なコードを書くためのツールと知識が与えられます。ただし、これは、二重処理や責任追求、サイロ化されたプロジェクト作業が少ない、ポジティブなセキュリティ環境で調整するのが最適です。

セキュリティは組織全体の最優先事項であり、優れた安全なソフトウェアを提供するための支援と協力的な取り組みが必要です。つまり、現実世界のコードの脆弱性を利用した楽しく魅力的なトレーニングを展開するのに十分な予算を確保し、勢いを維持するために組織全体で賛同を得られるようになるということです。この絶え間なく進化するデジタル環境では、トレーニングは提供と同じくらい継続的でなければなりません。過去に、「1回限りの」または「設定したら忘れる」コンプライアンストレーニングが適切または効果的であると言われたことがありますが、これは誤りです。

この新しいNISTの枠組みには、ポジティブな安全保障文化を育むための要件が具体的に明記されているわけではありませんが、そのガイドラインをうまく遵守するには、間違いなくそれが必要です。ただし、組織は「開発者が従うべき安全なコーディング手法を含め、組織のソフトウェアが満たすべきセキュリティ要件を明記したポリシーを定義する」べきだと述べています。

上記は、チーム内のセキュリティスキルを強化し磨くために不可欠です。自社のポリシーと現在のアプリケーションセキュリティ環境を評価する際には、次の点を考慮すると役立つ場合があります。

• ソフトウェア・セキュリティのガイドラインと期待事項は明確に定義されていますか?
• 目標を達成するために自分が果たす役割について、全員が明確に理解できているか?
• トレーニングは頻繁に行われ、評価されていますか？
• 開発者は、一般的なセキュリティバグを発生前に排除するうえで、自分たちが果たせる大きな役割を認識していますか？

さて、最後の部分は、すでに述べたように、主に組織と彼らが選択するトレーニング次第です。関連性があり、頻繁に実施し、参加してもらえるものでなければなりません。日常業務に適用できるソリューションを見つけ、状況に応じて知識を深めましょう。

これからどうする？

これらの新しいガイドラインを深く掘り下げてみると、かなり圧倒されるでしょう。ほとんどの企業が必要とする強固で安全なソフトウェアを、可能な限り最も安全な方法で作成、検証、展開するには、本当に多くの人手が必要です。トレーニングだけの問題ではありません。サードパーティ製ソフトウェアを使用する際に考慮すべきガイドラインがあります (既知の脆弱性を持つコンポーネントの使用 まだ座っている OWASP トップ10結局のところ）、検証、ペネトレーションテスト、コードレビューに関する提案、セキュリティ記録管理に関するガイドライン、適切なツールチェーンなど。全体像を把握するための実用的な洞察は、Gary McGraw博士の論文にあります。 BSIMM モデルこれはNISTのドキュメント全体で参照されています。

ただし、開発者が適切なツールと知識を得て、最初から安全なソフトウェアの構築に真に成功できれば、最速で成果を上げることができます。SDLC の後の段階でよくある脆弱性が何度も出現するのを防ぐ方が、ビジネスにとってはより安価です (そして全体的に迅速です)。その強みを活かし、組織のセキュリティ面に関わるインセンティブを提供しましょう。本当に楽しいことですし、彼らは悪者を排除し、私たちのデータを安全に保つために必要なジャストインタイムのヒーローになることができます。

参考文献:

1. SSDF の採用によるソフトウェア脆弱性のリスクの軽減 (2019 年 6 月 11 日) ページ 2。
2. SSDF の採用によるソフトウェア脆弱性のリスクの軽減 (2019 年 6 月 11 日) ページ 5。
3. SSDF の採用によるソフトウェア脆弱性のリスクの軽減 (2019 年 6 月 11 日) ページ 4。

若い頃、よく遊んでいました 破滅そして確かに、最初は、ゲームの最初の2、3回のランスルーを完了するために、さまざまな難易度を切り替える必要がありました。「アイム・トゥー・ヤング・トゥ・ダイ」（イージー）から「ナイトメア」（ヴェリー・ハード）まで多岐にわたりました。テクノロジー企業を経営する上での難易度を単純にリセットして変更できたらいいなと思う日があります。特に、非常に多くの要素がデリケートで不安定で、失敗しやすい初期段階ではそうです。

統計は 有名で地味な：スタートアップは90％前後の割合で倒産しています。これは長年続いていますが、さらに掘り下げてみると、一般的な内訳では、スタートアップの21％が初年度、30％が2年以内、30％が2年以内に、50％が5年以内に、70％が最初の10年以内に失敗します。

共同創設者のマティアス・マドウ、ファテマ・ベイドン、コリン・ウォン、ネイサン・デズメット、ヤップ・カラン・シンが「レベル10」にたどり着いたことを誇りに思います。これは、ゴールドマン・サックス、シスコ・インベストメント、パラディン・キャピタル、フォージポイント、エアツリー、タイダルなどの投資家と、私の独立取締役であるジム・プフラギングとナンヒ・シンの支援に支えられて、「レベル10」に到達したことを誇りに思います。。

創設チームは、10年間、すべての教訓、勝利、挫折を乗り越えて団結し、船を導いてきました。私たちは規模を拡大しつつあり、開発者リスク管理のリーダーとして、次の章である SCW 2.0 に立ち向かう準備ができています。

2024年：業界初のデータインサイトツールを市場に投入した年。

人材のスキルアップによる投資収益率を実証することは非常に困難ですが、2024年、SCWは業界全体が求めていたものを達成しました。「開発者のスキルを向上させることで、ソフトウェアの安全性が向上することを証明できますか？」私たちは、定評のあるプログラムを実行している大口のお客様から脆弱性と問題の修復に関するデータを収集しました。お客様からの検証により、安全な開発者が作成したコードが他の開発者が作成したコードと比較して、脆弱性の減少の中央値が 53% であったことを誇らしげに証明できました。また、セキュア開発者はセキュリティ問題を 2 ～ 3 倍速く修正できるため、時間を節約し、リスクにさらされるリスクを軽減できることも証明されました。

最初に門を出たのは SCW トラストスコア、 のみ 企業のセキュア・コーディング・プログラムの影響を定量化するベンチマーク機能セキュリティリーダーは、開発チームのセキュア・コーディング・スキルについて、データに裏打ちされたきめ細かなインサイトを得たり、業界標準と比較したりすることが初めて可能になりました。これは、多くの開発者がプログラムの重要な調整を行うために待ち望んでいた完璧な可視性であり、個々の開発者が生涯にわたってセキュリティスキルを強化するための学習経路を提供するために待ち望んでいたものです。さらに、次のような記事も公開しています。 研究論文 元米国ナショナル・サイバー・ディレクターのクリス・イングリスと、パラディン・グローバル・インスティテュート会長で元米国ナショナル・サイバー・ディレクター代理のケンバ・ウォルデンと。

その後、リリースしました SCW トラストエージェントは、組織のコードリポジトリ全体を可視化し、すべてのコミットを開発者の安全なコーディングスキルと照らし合わせて分析するコンパニオンサービスです。SCW Trust Agent は SCW Trust Score に基づいて構築されており、企業のセキュリティプログラムがすべてのコミットにどれほど効果的に適用されているかを協力して実証しています。

これらのツールは、企業のセキュリティリーダーが次のような目標を達成するのに役立ちます。 CISAのセキュリティ・バイ・デザイン・ガイドライン開発者のセキュリティスキルの検証、安全なコミット、そして最終的には実証済みの安全な設計原則に必要な脆弱性のカテゴリの根絶を行います。

やあ、パートナー！パートナーネットワークは拡大を続けており、顧客ベースも拡大を続けています。

サイバーセキュリティ業界に携わることで心温まる側面の1つは、本質的に、私たち全員が1つの大きくてマニアックで情熱的なコミュニティであり、ほとんどの場合、相互の成功だけでなく、すべての人にとってより安全なデジタル世界を追求するために力を合わせることをいとわないということを理解することです。

さまざまなセキュリティおよびテクノロジー企業に電話できることを光栄に思います 私たちのビジネスパートナー当社のパートナープログラムは、当社が成長を促進するうえで重要な役割を果たしています。2024年末に向けて、情報管理のグローバルリーダーとの2回目のOEMパートナーシップを発表しました。 オープンテキスト。この開発は、当社の主力OEMパートナーと相まって、 ブラックダックは、企業とそのセキュリティプログラムの現代のニーズに応える、本格的で包括的なソリューションを提供する素晴らしい機会を与えてくれます。

さらに、現在、650を超える企業顧客を誇っています。10 年前、最初の大口顧客を祝って 4 人のチームに安い昼食を勧めたときのことを覚えています。私たちは、開発者を変化の担い手として、予防的セキュリティに取り組むことを恐れないクライアントの健全な足跡をしっかりと築いてきました。

究極のディスラプターであるAI、そして開発者が主導するセキュリティの未来

人工知能、LLM、AI コーディングツールは、2 年以上にわたり、すべての IT プロフェッショナルの口で話題になっています。そして、私たちは社会として、テクノロジーの歴史における決定的な瞬間にいます。ほぼすべてのカテゴリーに豊富な AI ツールが揃っているため、生産性が大幅に向上することが期待されています。ソフトウェア開発では、 最近の GitHub アンケート ほとんどのエンジニアがAIを活用したコーディングアシスタントの採用を開始していることが明らかになりました。

これらのツールの使用を承認している組織はわずか38％ですが、現在ではソフトウェア開発環境の一部となっています。ツールの使用は避けられないため、セキュリティリーダーは「シャドーAI」の状況を作り出すのではなく、開発者を安全で責任あるコーディングの旅に導くことに注力すべきです。セキュリティ意識の高い開発者は、セキュリティスキルの低い開発者が抱える継続的なリスクを増大させることなく、生産性の向上から真に利益を得るために必要な批判的思考とセキュリティに関する専門知識をもってこれらのツールを活用できます。

2025年は、AIコーディングの進歩が続く年です。それでも、企業がこの分野やその他多くの分野で開発者リスク管理を効果的に適用できるよう支援できることが1つまたは2つあるかもしれません。今後の動向に注目して、私たちの旅が私たちをどこへ導くのか見守っていただきたいと思います。

サイバー脅威が蔓延し、高度化するにつれて、サイバーセキュリティの焦点は安全なコードの重要性に集中しています。ホワイトハウスの 国家サイバーセキュリティ戦略 およびサイバーセキュリティおよびインフラストラクチャセキュリティ庁（CISA）の セキュリティ・バイ・デザイン イニシアチブは、他の国のイニシアチブや法律とともに、セキュリティに対する責任をソフトウェア開発者に真っ向から負わせています。ソフトウェア開発ライフサイクル (SDLC) の早い段階でセキュリティを確保するために左へ、より正確には左にシフトすることが、かつてはあれば良いと考えられていましたが、今や組織にとってデータやシステムを保護し、侵害による規制の影響を回避するために不可欠です。

安全なコーディングプラクティスを実現するための鍵は、開発者のトレーニングにあります。ソフトウェアエンジニアは通常、以下の内容を受け取ります。 サイバーセキュリティ教育はほとんどまたはまったくない。特に今日の加速するDevOps環境における彼らの仕事は、急速に機能するジェネレーティブAIモデルの助けを借りて、新しいアプリケーション、アップグレード、サービスをできるだけ早くスピンアウトし、SDLCの後半のある時点でセキュリティチームがサイバーセキュリティの問題に対処できるようにすることでした。これは、大量のコードが作成されることで発生する大量の欠陥に対処するには非効率的な方法であり、その結果、ソフトウェアの脆弱性がエコシステムに放出されることがよくあります。

開発者は、最初から安全なコードを書くためのトレーニングを受け、AI によって生成されたコードや、使用しているオープンソースやその他のサードパーティソフトウェアに含まれる安全でないコードを検出できるようにする必要があります。多くの開発チームや組織にとって、これは未知の領域です。開発者が自分たちに必要なトレーニングを受けていることをどうやって知るのでしょう?そして、そのトレーニングは定期的に実施されているのでしょうか？

開発者教育に取り組む企業の中には、開発者が習得するためのベースラインとなるスキルセットを確立し、明確に定義されたベンチマークに照らして進捗状況を測定することが有益であると考える企業もあります。その取り組みを支援するために、Secure Code Warriorは開発者のセキュリティトレーニングの進捗状況を正確に測定するためのベンチマークを開始しました。は SCW トラストスコア これにより、組織はトレーニングが仕事にどの程度適用されているかを測定し、セキュリティ、開発者、エンジニアリングの各チームが協力できるようになります。

これは、改善すべき分野を特定しながら、セキュアコードトレーニングが定着しつつあることの証拠を確認する方法です。

セキュアデザインの事例

ソフトウェア開発者は、プロセスの開始時にSDLCにセキュリティを導入する理由は十分にあります。アプリケーションやサービスに対する需要の高まりと、AI が開発プロセスにもたらすスピードは、 役に立った ジェネレーティブAIをすぐに採用した開発者にとっても、結果的には必然的に バギーソフトウェア パイプラインにリリースされています。生成されるコードが増えれば増えるほど、欠陥も増えます。 最近の研究 は、アプリケーションの4分の3近く（作成方法に関係なく）に少なくとも1つのセキュリティ上の欠陥があり、その20％近くが重大と見なされていることを発見しました。

SDLCの後半で脆弱性に追いつくのは、非常に時間とコストがかかるようになっています。米国国立標準技術研究所 (NIST) 見つけた テスト中の欠陥の修正には、SDLCの開始時にソフトウェアを保護するよりも15倍の時間がかかり、展開/保守段階での修正には30〜100倍の時間がかかることがあります。

これらすべてが、開発サイクルの最初にセキュリティを適用することの重要性を浮き彫りにしています。これは、リスクを軽減する最も効果的な方法であるだけでなく、最も費用対効果が高いことが証明されています。SDLC の開始時にセキュリティを導入するにあたっては、開発者が個別の組織として機能するのではなく、セキュリティチームと連携して作業するのが最適な立場にあります。また、セキュリティのベストプラクティスのトレーニングを受けた開発者は、脆弱性を効果的に軽減してきました。問題は、トレーニングを受けた開発者がほとんどいないことです。

ベンチマークの魅力

企業にとっての基本的な道筋は、セキュリティスキルのベースラインを確立し、トレーニングを提供し、開発者が必要なスキルを習得していることを組織と規制当局の両方に検証することです。これは、あらゆる経済セクターの多くの組織にとって困難であることが証明されていますが、必ずしもそうである必要はありません。

セキュリティリーダーが指摘する課題の 1 つは、トレーニングプログラムを企業全体に拡大することの難しさです。しかし、SCW の調査によると、特に開発者の幹部が大勢いる組織は、セキュア設計アプローチをうまく実装できることが分かっています。小規模な組織の結果では、セキュリティバイデザインの原則をどの程度うまく適用しているかが大きく異なる傾向にあります。それでも、彼らもトラストスコアを含むアプローチの恩恵を受けることができ、より早く改善が見られる可能性があります。

Trust Scoreは、ベンチマーク指標を使用して個々の学習者の進捗状況を測定し、スコアを集計してチーム全体のパフォーマンスを評価し、組織の進捗状況を業界のベンチマークやベストプラクティスと比較します。トレーニングを追跡するだけでなく、開発者が新しいスキルを日常的にどの程度うまく活用しているかを示します。また、組織がトレーニング/スキルアッププログラムを最適化できるように、改善が必要な分野も浮き彫りになっています。

CISA全体で 重要インフラセクター データが入手できたとしても、ほとんどの組織は安全な設計の原則をほぼ同じレベルで実装しています。金融サービスや防衛産業の基盤から、医療、IT、重要製造に至るまで、さまざまなセクターのトラストスコアは同じ範囲で低下し、1,000点満点で300点をわずかに上回りました。最も規制の厳しい業界である金融サービスが最前線にあるという従来の通念にもかかわらず、どの業界も他の業界を上回ることはありません。

化学、エネルギー、原子力事業など、トラストスコアランキングに含まれていない重要インフラセクターは、一般的に独自のソフトウェアを作成せず、代わりに他のセクター、特にITに依存しています。しかし、これらのセクター内で安全なシステムを維持することの重要性（原子力発電所が危険にさらされるのを誰も望んでいない）は、そもそもそのセクターが使用するソフトウェアを保護することがいかに重要であるかを示しているに過ぎません。

結論

規制圧力の高まりとサイバー脅威の状況の現実により、データ、システム、事業運営、評判を保護したい組織にとって、セキュアバイデザインのアプローチが不可欠になっています。安全なソフトウェアの開発は大部分が開発者の手に委ねられていますが、必要な教育を提供し、その適用方法を示す徹底的なスキルアップとトレーニングプログラムという形での支援が必要です。

Trust Score などのツールに裏打ちされたベンチマークを含むプログラムでは、開発チームの重要な進捗状況を明確に把握できます。これは、開発者と彼らが働く企業の両方にとって、セキュアなソフトウェア開発スキルを常に向上させながら、新しいSecure-by-Designの要件を満たすために必要な、極めて重要な新しいアプローチです。

‍

で セキュア・コード・ウォリアー、私たちのモットーは常に、開発者に実践的なアジャイル学習体験を提供することでした。つまり、日常業務の一部として、現実世界で実践的なセキュリティトレーニングを提供することです。私たちはこれを「実践による学習」と呼んでいます。

開発者が今取り組んでいることに的を絞ったトレーニングは、企業にとってさらに有意義な結果をもたらすのに役立つやりがいのある体験を提供することを私たちは知っています。つまり、バトルテストされ、品質管理され、タイムリーに市場に出荷する準備ができているコードリリースをより迅速に行うことができます。そのサウンドが気に入らない企業などあるでしょうか。

とのエキサイティングな新しい統合を通じて、このエクスペリエンスを強化しています アピイロは、重要なアプリケーションリスクの優先順位付け、修正、防止、管理に必要な可視性をAppSecチームとリーダーに提供する、主要なアプリケーションセキュリティポスチャ管理（ASPM）プラットフォームです。2 つのプラットフォームを統合することで、開発者がセキュリティリスクを修正する際に、関連性の高いコンテキストとリアルタイムのセキュリティトレーニングが開発者に提供されます。これにより、開発者はコンテキストを切り替えたり、日常的に使用する開発ツールの使い慣れた環境から離れることなく学習できるようになります。

では、この魔法はどのようにして起こるのでしょうか？Apiiroは、Apiiroによって検出された、またはサードパーティのセキュリティツールによって取り込まれたアプリケーションのセキュリティ結果を、Secure Code Warriorのタイプと言語別の関連トレーニングにマッピングし、チケット、問題、またはメッセージとして関連する開発者またはチームに提供します。Apiiro と Secure Code Warrior の統合により、別のツールで別の時点でアクションを実行する必要がなくなるため、ソフトウェア開発ライフサイクルの中断を最小限に抑えることができます。これは、企業が質の高いコードをより早くリリースし、開発者の効率を高められるよう支援するもう一つの方法です。

この新しい統合とパートナーシップの詳細については、以下をご覧ください アピイロのブログはこちら。

‍

ほとんどの組織は、ソフトウェア開発ライフサイクル（SDLC）の重要な要素としてセキュリティを重視することに依然として苦労しており、堅牢なDevSecOpsアプローチを克服できる組織はほとんどありません。多くの企業にとって、機能やリリース期限を優先することが、依然としてセキュリティよりも優先されています。これには、高額なデータ漏えいのリスクが高まったり、チームがセキュリティチケットをふるいにかけてやり直したりすることによる生産性の低下などの影響が伴います。

なぜなら、開発者はリスクを排除するための最前線だからです ソフトウェアの脆弱性、組織にとって自社の成熟度を高めることを考えることは重要です 開発チーム。しかし、これにはいくつかの疑問が生じます。

組織は開発チームのセキュリティ成熟度をどのように評価していますか?セキュリティ成熟度ロードマップを設定することが不可能な作業に思えないようにするにはどうすればよいでしょうか。開発者のエンゲージメントを維持し、セキュリティの成熟度を高めるためのモチベーションを維持するにはどうすればよいでしょうか。

セキュア・コード・ウォリアーからの洞察を利用しました 開発者主導のセキュリティ調査の現状 これらの質問に対する答えを理解し、世界クラスのカスタマーサービスチームを活用して、他の組織が答えを見つけるために何をしているのかを調べました。‍

開発チームのセキュリティ成熟度を高めるにはどうすればよいでしょうか?

セキュリティ成熟度の向上に関しては、同じ組織は2つとありません。企業が左にシフトする取り組みの成功に影響を与える可能性がある考慮すべき要素は数多くあります。そうする企業には、コードの作成やリリースが速くなるなど、ほとんどまたはまったくなくても済むなど、多くのメリットがあります。 脆弱性これにより、費用のかかるやり直し作業が減り、最終的にはリスクが軽減されます。

進歩を遂げている組織には、経営陣の支援を得た明確な計画と、（とりわけ）以下を含むセキュリティの成熟度を長期にわたって継続的に改善するためのまとまりのあるアプローチがあります。

• セキュリティ成熟度ベースラインの定義
• チームのセキュリティ成熟度の評価
• 主なセキュリティ弱点の特定
• ポジティブなセキュリティ文化の構築

新しいホワイトペーパーをご覧ください 開発チームにおけるセキュリティ成熟度の重要性 以下を詳しく見てみましょう。

• 開発チームにおけるセキュリティ成熟度とは何か、なぜ重要なのか
• 開発チームのセキュリティ成熟度のさまざまな段階と特徴は何か?
• 開発チームのセキュリティ成熟度を高めるには何が必要ですか?

Hace cinco años, los bancos belgas se unieron para hacer este fantástico anuncio de televisión, compartiendo la historia de Dave, un clarividente extremadamente dotado que conoce información personal y financiera muy específica. El anuncio logró que millones de consumidores se dieran cuenta de que toda su vida puede ser encontrada en Internet y animó a todo el mundo a estar atento.

Echa un vistazo al vídeo y verás que es aún más relevante hoy que en 2012, y sabemos que las consecuencias son aún más aterradoras.

Si cree que la formación en ciberseguridad es un gran dolor de cabeza para su equipo directivo y sus empleados, que implica una aburrida formación con diapositivas, normas opresivas y alguien que les dice lo que no deben hacer todo el tiempo, puede ser un buen momento para ver este vídeo para obtener algo de inspiración creativa.

Vea el vídeo, compártalo con sus equipos de recursos humanos y de comunicación, y pídales ayuda para que la seguridad de la información vuelva a ser divertida.

No importa si está formando a la alta dirección en ciberseguridad o ayudando a los desarrolladores en JAVA o C# a asegurar sus habilidades de codificación, hay un lugar para la creatividad, la gamificación y la diversión.

No importa si está formando a la alta dirección en ciberseguridad o ayudando a los desarrolladores en JAVA o C# a asegurar sus habilidades de codificación, hay un lugar para la creatividad, la gamificación y la diversión.

一方 VxWorks 平均的な消費者にはあまり馴染みのない名前ですが、このソフトウェア製品は、あなたや私のような多くの人々に毎日利益をもたらすことは避けられません。世界で最もポピュラーなリアルタイムオペレーティングシステム (RTOS) であるこの製品は、エンタープライズネットワークやファイアウォール、航空宇宙インターフェース、産業機器、さらには一部の医療機器に電力を供給するために、(プロキシ経由で) 私たちが頼りにしている主力製品であり、その用途が広く使われている例をいくつか挙げてみます。

そして今、私たちは、そうでなくても何億人もの可能性に直面しています。 数十億、これらのデバイスのうち、現在少なくとも11の脆弱性が侵害されています。ウインドリバーのチーフセキュリティアーキテクトであるアーレン・ベイカーは、以下の記事でこの件数に異議を唱えています。 検索セキュリティ、正確な範囲を明らかにすることは未確認であり、それほど高いとは考えられていません。それにもかかわらず、データ侵害や攻撃は常に発生していることはすでにわかっていますが、これは次のレベルです。確認された欠陥は比較的簡単に悪用され、攻撃者はネットワークパケットの送信を通じてデバイスをリモートで制御できるようになります。

もちろん、Wind Riverは影響を受けた顧客やアソシエイトに一連の修正とパッチをリリースしました。問題は、パッチアップデートを必要とするデバイスの数が非常に多いことにあります。サノスが指一発で世界を終わらせるのと同じように、まさにそうです。 避けられない その数のデバイスはパッチが適用されないままになり、長期間にわたって脆弱になります。

セキュリティ会社 アーミス この巨大な発見の背後にいたのは彼らの発見だと言って 緊急/11。複数の媒介動物からの攻撃が容易であることと、広範囲に及ぶ感染の可能性があることからも、深刻な感染が確認されたことは間違いありません。MRI スキャナーや VoIP 製品から、鉄道ネットワークや信号機に至るまで、あらゆるものを支えるソフトウェアにワームを作成して展開することは完全に可能です。

パニックになる時間ですか？

セキュリティ意識向上を人生の重要な使命としてきた者として、私は日常的に潜在的なセキュリティ問題をたくさん目の当たりにしています。パニックに陥りすぎると、1 日の大半をヒステリックな状態で過ごしてしまいます (結局のところ、むしろ教育やバグ修正の手伝いをする仕事に取り掛かりたいのです!)。しかし、URGENT/11の調査結果の範囲はかなり怖いです。見つかった 11 件の脆弱性のうち、6 件が重大と見なされています。として ハッカーニュース これらの欠陥は、バージョン6.5以降（VxWorks 653やVxWorks Cert Editionなどの認証用に設計されたバージョンを除く）VxWorksを実行しているデバイスに存在していたことが確認されています。つまり、一部の重要なテクノロジーは、10年以上にわたってデバイス乗っ取り攻撃の脅威にさらされてきました。すべてのデバイスが11の欠陥すべてに対して脆弱であるわけではなく（攻撃者が同じLABサブネットにいる場合にのみ悪用されるものもあります）、凡庸なハッカーでも必要なのはほんの少しの機会だけです。

Wind Riverには 迅速に行動し、詳細なアドバイスを提供しました アーミスがそうであるように、問題の軽減についてです。そして、VxWorks RTOSは非常に広く採用されています。 なぜなら 非常に信頼性が高く、ソフトウェア安全規制のスコアも高くなっています。通常、バグバウンティハンターはあまり気にしません。しかし、セキュリティ企業とウインドリバーがこの問題を解決するためにできることは限られています。パッチをダウンロードし、セキュリティアドバイスに耳を傾け、自社のデバイスを強化するのはエンドユーザーの手に委ねられており、そこが難しいところです。

まだ慌てる必要はないかもしれないが、この獣と格闘して服従させるには村が必要かもしれない。

緊急/11の脆弱性の説明

この時点で、バージョン6.5以降の侵害されたVxWorks TCP/IP IPNetスタックに接続されているすべてのデバイスが、少なくとも1つのURGENT/11の影響を受ける可能性があります。(ウインドリバーの CVE の全リストについては、以下を参照してください) ここに)。

ほとんどの場合、これらの欠陥によりリモートコード実行（RCE）攻撃やサービス拒否攻撃が可能になり、その一部が情報漏洩につながり、 ビジネスロジック 問題も。この場合、攻撃者はエンドユーザーの操作なしにデバイスの制御を乗っ取ることができるため、リモートコード実行は特にデリケートな問題です。疑わしいものを誤ってクリックしたり、何かをダウンロードしたり、詳細を入力したりする必要はありません。これにより、VxWorksデバイスは高度に「ワーム可能」になり、攻撃自体が自動的に実行されます。EternalBlueの製品を思い出してください ワナクライ ワーム?URGENT/11も同様ではあるが壊滅的な可能性を秘めており、世界規模の悩みの種となっている。

私たちはそれについて何ができるでしょうか？

さて、これを書いている時点では、URGENT/11の結果は不明のままです。メディアは業界に認識を示しており、ウインドリバーは明らかに影響を受けた人々を支援しています。今後数か月で、攻撃者がこれらの既知の欠陥を有意義な方法で悪用するかどうか明らかになりますが、それまでの間、明らかな解決策は、大量のアドバイスに耳を傾け、軌道上の関連デバイスにパッチを適用することです。

長期的に見ても、使命は変わりません。ソフトウェアセキュリティに関しては、誰もがもっとうまくやる必要があるということです。URGENT/11 CVEは、一般的に、簡単に通り抜けることができるように心配なほどシンプルなバックドアであり、長年にわたって発見されなかったという事実は、業界全体の懸念と認識がかなり低いことの証です。

すべての開発者には自分の役割を果たす機会があり、本番環境の最初からコードを保護する方法を学ぶためのサポートが必要です。アプリケーションセキュリティから経営幹部に至るまで、周囲の影響力のあるチームが、ビジネス内のあらゆるソフトウェアタッチポイントでポジティブなセキュリティ文化を確実に浸透させることができます。

自分のセキュリティ意識を試してみませんか？当社のゲーミフィケーションプラットフォームでは、URGENT/11 で発見されたものと同様の実際のコード課題が発生する可能性があります。それらをチェックして、どうなるか見てみましょう。

• DHCP オファーのヒープオーバーフロー/ipdhcpc の ACK 解析のヒープオーバーフロー（CVE-2019-12257）
  メモリ破損-ヒープオーバーフロー
• 不正な形式の TCP オプションによる TCP 接続 DoS（攻撃拒否）（CVE-2019-12258）
  トランスポート層保護が不十分-機密情報の無防備な転送
• ipdhcpc DHCP クライアントによる IPv4 割り当てにおける論理的な欠陥（CVE-2019-12264）
  ビジネスロジックの欠陥
• IGMP 解析におけるヌルデリファレンス経由の DoS 攻撃 (CVE-2019-12259)
  メモリ破損-NULL デリファレンス
• IGMPv3 固有のメンバーシップレポートによる IGMP 情報の漏えい（CVE-2019-12265）
  情報漏えい-機密データ漏えい