Insight sobre código seguro

ソフトウェアの保護に積極的に取り組むには、最新の標準とコンプライアンス要件を常に把握しておく必要があります。結局のところ、サイバーセキュリティ環境は、特に新しいテクノロジーの出現に伴い、常に新しい脅威や脆弱性によって変化しています。私たちが集まって AI の変曲点に立ち、新しい進化やユースケースが日々出現しているように見える今日ほど、この傾向が当てはまることはありません。

これらの課題に対処するために、OWASP財団は最近、以下の最新版をリリースしました 大規模言語モデル (LLM) アプリケーションに関する OWASP トップ 10は、LLMやジェネレーティブAIアプリケーションを導入する際の潜在的なリスクについて、開発者、アーキテクト、その他のソフトウェア提供者に知らせることを目的としています。そして、Secure Code Warriorでは、この最新バージョンの変更と更新がすでに実装され、当社の安全なコード学習プラットフォームで利用できるようになったことを発表できることを嬉しく思います。これらの新資料や更新資料により、すべてのユーザーが LLM を利用する際のリスク軽減の最前線に立つことができます。

このアップデートでは何が新しくなったのですか？

OWASPは以前のトップ10から2つの項目を削除しました。

• 安全でないプラグイン設計 -LLMがプラグインとどのように相互作用するか、およびプラグインが外部ストレージまたはサービスとどのように相互作用するかに関するものです。
• モデル盗難 -機械学習モデルまたはAIシステムの不正複製または取得を指します。

OWASP Top 10の以前のバージョンと同様に、セキュア・コード・ウォリアーには ガイドライン 当社のLLMトップ10コースの一環としてこれらの脆弱性に関連付けられています。これらのガイドラインは、脆弱性とセキュリティ概念に関するわかりやすい情報をわかりやすく読みやすい形式で提供していましたが、その後コースのカリキュラムから削除されました。ただし、このガイドラインは、提供している他のすべての学習教材とともにExploreで引き続き利用できます。

OWASPはトップ10を公式10に維持しながら、新たに2つのアイテムを追加しました。

• システムプロンプトリーク -モデルの動作を誘導する通常は非表示のプロンプトがユーザーに公開される場合。
• ベクターと埋め込み -公開されていない特定の情報、専有情報、またはリアルタイム情報を公開する可能性があります

これらの脆弱性に関するガイドラインがLLMトップ10コースに追加されました。削除されたガイドラインと同様に、この2つはExploreでも利用でき、自分のペースで学習したいユーザー向けです。

最後に、OWASPはリスト内の既存の脆弱性カテゴリにいくつかの変更を加え、一部のカテゴリの名前をより広範または具体的に変更し、その定義を変更しました。これらのトピックに関する当社のガイドラインは、OWASPのガイダンスからの小さな変更と新しい命名規則の両方を反映するように更新されました。さらに、OWASP LLM Top 10に設定されている順序と一致するように、優先順位順のリストが更新されました。

Secure Code Warriorでは、ユーザーが常に時代の一歩先を行けるよう支援することに全力を注いでいます。OWASPの最新の更新はすでにアジャイル学習プラットフォームに反映されているため、LLMとジェネレーティブAIテクノロジーを導入する際のリスクを軽減し、最新の脆弱性をカバーする最新のトレーニング教材にユーザーが簡単にアクセスできるようにしました。新たに導入された「システムプロンプトリーク」や「ベクトルと埋め込み」の脅威に対処する場合でも、誤情報や無制限消費についての理解を深めたい場合でも、当社のプラットフォームは、セキュリティ体制を改善するためのこれらの重要な概念を習得するために必要なリソースを提供します。

¿Sabía que el 67% de los desarrolladores admite haber enviado código con vulnerabilidades? Imagínese un equipo de trabajadores de la construcción encargado de construir una casa. Tienen todos los materiales y herramientas que necesitan, pero se esfuerzan por seguir los planos y los códigos de construcción. Como resultado, cometen errores y la casa no se construye conforme a las normas.

Esta analogía puede utilizarse para ilustrar los retos a los que se enfrentan los desarrolladores cuando intentan practicar una codificación segura. Al igual que los trabajadores de la construcción tienen que seguir planos y códigos de edificación para asegurarse de que sus casas son seguras, los desarrolladores tienen que seguir prácticas de codificación segura para garantizar que sus aplicaciones de software son seguras.

Hay varias razones por las que la codificación segura puede ser un reto. Por ejemplo:

• Desconocimiento de las prácticas de codificación segura. El 86% de los desarrolladores afirman que les resulta difícil practicar la codificación segura.
• Falta de tiempo y recursos. El 24 % de los encuestados afirma que "no disponer de tiempo suficiente" es el mayor impedimento para integrar código seguro.
• La complejidad de la codificación segura. El 63% de los desarrolladores considera difícil escribir código seguro y libre de vulnerabilidades.
• Exceso de confianza en las herramientas. El 57% de los equipos de seguridad de aplicaciones utilizan seis o más herramientas para descubrir vulnerabilidades durante el ciclo de vida de DevSecOps.(GitLab, 2023)

Sin embargo, a pesar de los retos, la codificación segura es esencial. Siguiendo prácticas de codificación segura, los desarrolladores pueden ayudar a proteger sus aplicaciones de vulnerabilidades que puedan ser aprovechadas por los atacantes. Al igual que una casa bien construida tiene menos probabilidades de derrumbarse, una aplicación bien codificada tiene menos probabilidades de ser pirateada.

He aquí algunos consejos para los desarrolladores que deseen mejorar sus prácticas de codificación segura:

• Obtenga formación y educación sobre codificación segura. Hay varios recursos disponibles para ayudar a los desarrolladores a aprender prácticas de codificación segura.
• Utilice herramientas de análisis estático para identificar vulnerabilidades en el código. Las herramientas de análisis estático pueden ayudar a identificar vulnerabilidades en el código que pueden ser difíciles de encontrar manualmente.
• Escriba código fácil de revisar y comprender. El código fácil de revisar y comprender tiene más probabilidades de ser seguro.
• Pruebe el código a fondo. Probar el código puede ayudar a identificar y corregir vulnerabilidades antes de que sean explotadas.

¿Le interesa saber más? Descubre los secretos para desarrollar una estrategia ágil de código seguro con nuestro plan de aprendizaje de código seguro. 

‍

‍

‍

‍

Una versión de este artículo apareció en Bulevar de la Seguridad. Se ha actualizado y sindicado aquí.

A principios de este año, el PCI Security Standards Council presentó la versión 4.0 de su Payment Card Industry Data Security Standard (PCI DSS). Aunque las organizaciones no tendrán que cumplir plenamente la versión 4.0 hasta marzo de 2025, esta actualización es la más transformadora hasta la fecha y exigirá que la mayoría de las empresas evalúen (y probablemente actualicen) procesos de seguridad complejos y elementos de su pila tecnológica. Esto se suma a la implantación de la formación de concienciación sobre seguridad basada en roles y la formación periódica en codificación segura para desarrolladores.

Esto representa una oportunidad de oro para que las empresas del sector BFSI mejoren seriamente sus programas de seguridad, dando paso a una nueva era de ciberresiliencia impulsada por las personas. 

¿Cuáles son los mayores retos a la hora de prepararse para PCI DSS 4.0?

Del mismo modo que el programa de seguridad de una organización lo abarca todo, con complejidades que son exclusivas de sus necesidades empresariales y recursos disponibles, las nuevas normas PCI DSS abarcan mucho terreno. Sin embargo, revelan un cambio significativo hacia la flexibilidad en los enfoques para cumplir los requisitos de seguridad, y en un sector en el que las herramientas, las amenazas, la estrategia y las medidas de cumplimiento pueden cambiar en un instante.

PCI DSS 4.0 adopta el concepto de que hay muchas maneras de alcanzar el mismo objetivo de mejores prácticas de seguridad herméticas. Esto es cierto, pero parece más adecuado para organizaciones con una madurez de seguridad avanzada y deja mucho margen para el error, especialmente para aquellas que no han sido realistas en su assessment de su verdadera madurez de seguridad interna. En última instancia, las empresas deben estar preparadas para comprometerse con la seguridad como un proceso continuo y evolutivo, no como un ejercicio de "fijar y olvidar" de una sola vez. Es imprescindible una cultura de seguridad sólida, con un compromiso de toda la organización con la concienciación en materia de seguridad. 

Y los que trabajan con herramientas a nivel de código -la cohorte de desarrollo- deben estar capacitados para ofrecer software seguro y conforme a las normas en cualquier entorno empresarial que maneje activos y transacciones digitales. 

¿Están preparados sus desarrolladores para ofrecer software conforme?

Los desarrolladores son parte integrante de la consecución de un estado de excelencia en la seguridad del software, y esto es especialmente relevante para algo más que el cumplimiento simbólico de la norma PCI DSS. Es fundamental que los desarrolladores comprendan el panorama más amplio de la norma PCI DSS 4.0 en términos de lo que pueden controlar e integrar como parte de su enfoque predeterminado para la creación de software. 

Tres áreas clave representan los cambios más relevantes para el equipo de desarrollo, y pueden desglosarse del siguiente modo:

• Autenticación: Un plan viable para el control de acceso siempre ha sido una parte clave del cumplimiento de la PCI, sin embargo, la versión 4.0 eleva este aspecto de una manera que requerirá una cuidadosa implementación tanto interna como externa. La autenticación multifactor (MFA) se convertirá en estándar, al igual que las normas reforzadas sobre la complejidad de las contraseñas y los tiempos de espera.
  
  Dado que los problemas de seguridad en la autenticación y el control de acceso son ahora los más comunes a los que se enfrenta el desarrollador medio, es imperativo que se imparta una formación de precisión para ayudarle a identificar y solucionar estos problemas en el código real.
  
  
• Cifrado y gestión de claves: Operamos en un mundo en el que podemos acceder a parte de nuestra información más sensible a través de múltiples puntos de acceso, como nuestra banca en línea. Con estos datos de gran valor en peligro, el cifrado y unas prácticas de criptografía sólidas son imprescindibles. Los desarrolladores tienen que asegurarse de que disponen de conocimientos actualizados sobre dónde se transmite la información, cómo pueden acceder a ella los usuarios e, incluso en el caso de que acabe en las manos equivocadas, garantizar que sea ilegible para los actores de amenazas.
  
  
• Software malicioso: en las directrices anteriores, los controles de seguridad en torno a la protección del software contra códigos maliciosos se denominaban "software antivirus", pero esto simplifica en exceso lo que debería ser un planteamiento a varios niveles que proteja contra mucho más que los virus por sí solos. Las soluciones antimalware deben aplicarse siempre que sea necesario, y el registro y la supervisión continuos son obligatorios.
  
  También es vital que los desarrolladores tengan vías de aprendizaje que cubran la identificación de componentes vulnerables, especialmente con la mayoría de las bases de código que dependen, al menos en parte, de código de terceros.

¿Qué constituye "suficiente" formación para los desarrolladores?  

Al igual que las recomendaciones anteriores, la norma PCI DSS 4.0 propone que los desarrolladores reciban formación "al menos" una vez al año. Sin embargo, si la implicación es que una vez al año es suficiente para la creación de software seguro, no es ni mucho menos adecuada y es poco probable que dé como resultado un software más seguro y conforme. 

La formación de los desarrolladores debe comenzar con una formación básica sobre las 10 principales vulnerabilidades de OWASP, así como sobre cualquier otra vulnerabilidad que sea relevante para el lenguaje y crítica para la empresa. Esto debería formar parte de un programa continuo, con el fin de seguir desarrollando esas habilidades e integrar la seguridad no sólo en el desarrollo de software desde el principio, sino también en su mentalidad y en el enfoque de su función. Además, las funciones y responsabilidades deben estar muy claras para la cohorte de desarrollo y sus responsables. La seguridad debe ser una responsabilidad compartida, pero es justo documentar las expectativas y asegurarse de que pueden cumplirse adecuadamente.

Con el tiempo de antelación disponible para prepararse para el cumplimiento de la norma PCI DSS 4.0, es posible realizar algunos avances significativos en las mejoras de la cultura de seguridad en toda la organización, y eso es terreno fértil para hacer crecer la cohorte de desarrollo más concienciada con la seguridad que jamás haya tenido.

‍

Secure Code Warriorでは、今日の絶え間なく変化するセキュリティ課題に取り組むための適切なスキルを開発者や組織に提供するために、常に革新を続けています。これは、非常に魅力的で柔軟性があり、管理が容易なセキュアコードイネーブルメントを通じて実現しています。

テクノロジースタックや追加のトレーニングプログラムへの投資に関しては、誰もが投資収益率を高めたいと考えています。ただし、セキュリティに関しては、長期的に取り組む必要があります。開発者が主導するセキュリティに投資すれば、高額な侵害や生産性の低下、蓄積された技術的負債のリスクを軽減できるだけでなく、今日の脅威の状況を先取りするための積極的で費用対効果の高い戦略を立てることができます。

この前四半期に、セキュア・コア・ウォリアーズはコーディング・ラボを使った新しい学習方法を実装しました。この方法は、セキュア・コード・ウォリアーのすべてのお客様にご利用いただけるようになりました。参加管理とコースのバージョン管理の強化を発表できることを嬉しく思います。また、ガイドラインなどの新しいコースアクティビティも作成しました！

さっそく詳しく見ていきましょう！

SCW プラットフォームの幅と深さの拡大

Secure Code Warriorでは、新しいコンテンツへの継続的な拡張により、当社のモジュールが今日のサイバーセキュリティ環境において知っておく必要のある内容に合わせて適切かつタイムリーにカスタマイズされています。55 を超える言語という業界トップクラスの幅と深さを誇るため、多数の言語とフレームワークで開発者をトレーニングするためのプログラムの構築と拡張が容易です。

コースで利用できるコーディングガイドライン

ガイドラインの追加により、開発者は主にセキュリティ緩和策を対象とした、状況に応じた自分のペースで学習できます。ガイドラインは動画よりも詳細で、特定の言語やフレームワークに焦点を当てています。チャレンジ、ミッション、ウォークスルーなどの他の攻撃ベースのアクティビティでは、すでに開発者が脆弱性を理解している必要があります。これらのアクティビティを防衛的な観点から補完するガイドラインを作成しました。

開発者はコース内のガイドラインを読み、管理者はコーステンプレートでガイドラインを使用できます。ガイドラインは、OWASP Top 10 2021 にリストされている脆弱性を対象としており、C#、Java、JavaScript、Python、擬似コード、PHP のコードスニペットも含まれています。

新しいチャレンジコンテンツ

Secure Code Warriorは、組織のニーズに合わせた関連性の高いタイムリーな課題を定期的に更新して作成しています。以下で利用できる拡張された課題を発表できることを嬉しく思います。

• Dart: Flutter-AndroidとiOSでスムーズなクロスプラットフォームアプリを構築するためのモバイル言語
• Terraform: GCP-Google クラウドプロバイダーのコード開発言語としてのインフラストラクチャ。

開発者はコードを分析して脆弱性を発見し、批判的思考を働かせて、リストされている脆弱性を防ぐための最適なセキュリティ実装を選択できます。

近日公開:新しいフロントエンドデベロッパーコンテンツ

フロントエンド開発者にも安全なコード有効化が必要です！そのため、ミッションとウォークスルーではフロントエンドの脆弱性をさらにリリースする予定です。フロントエンドの開発者は、コース内のフロントエンド固有のミッションにもアクセスできるようになります。

これらのアップデートは、DOM ベースの XSS などの一般的な脆弱性から、CSS インジェクションなどのあまり発生頻度の低い脆弱性まで、フロントエンド固有の脆弱性を包括的にカバーすることを目的としています。

ステップバイステップのウォークスルーでは、脆弱性がどのように悪用されているかについて、フロントエンド開発者に信頼できるガイダンスを提供します。上級開発者はトーナメントのフロントエンドミッションで自分のスキルをテストすることもできます。

管理者と開発者のエクスペリエンスを簡素化

プラットフォームの使いやすさが大幅に向上したことで、スケーラブルで魅力的な安全なコード教育プログラムの構成がこれまでになく簡単になりました。

‍

コースのバージョン管理、アーカイブ、参加管理

既存のプログラムを編集する新しい方法で、組織のプログラムの絶え間なく変化するニーズに対応できるようになりました。コースのバージョン管理により、管理者は新しいコースを作成しなくても既存のコースを編集できます。管理者は、開発者が登録していないテストコースや関連性のないコースを削除して、アーカイブを整理することもできます。

さらに、コース管理ページで追加のフィルターを適用できるため、管理者は作業したいコースに簡単に絞り込むことができます。コースは、コースステータス、終了日、登録チームなど、さまざまな属性でフィルタリングできます。たとえば、管理者は、時間制限のあるすべてのコース、コース終了時の評価が添付されているコース、またはコースがドラフトまたはプレビュー中のコースを簡単に見つけることができます。

コースのバージョン管理とフィルタリングに加えて、管理者はコース参加者を一括で再招待したり、必要に応じてコースから削除したりできるようになりました。これにより、システム管理者はワンクリックで開発者を「招待済み」の状態で再招待できるようになり、プラットフォームに戻って学習を開始するように促すための貴重な時間と労力を節約できます。

‍

これで、今四半期の新機能の説明は終わりです。フォロー Twitterのセキュア・コード・ウォリアー 最新のリリースや改善点に関する最新情報を入手してください。

セキュア・コード・ウォリアーを試してみたいけど、まだアカウントを持っていないということはありませんか？にサインアップ 無料トライアルアカウント 今日から始めましょう。

En esta ocasión anual tan festiva para los profesionales de la ciberseguridad, el Mes Nacional de la Concienciación sobre la C iberseguridad es un momento que muchas empresas utilizan para reflexionar y evaluar el ritmo general de la concienciación sobre la seguridad en toda la organización. Y con el 62% de las empresas que experimentaron un ataque de phishing o ingeniería social solo en 2018, no se puede exagerar la importancia de garantizar que cada individuo en la empresa, ya sea en un papel de seguridad o no, tenga una formación adecuada de concienciación sobre la ciberseguridad.

Como evento cada vez más global, el mes representa un punto de encuentro para discutir las mejores prácticas, y las iniciativas son deliberadamente superficiales. Sin embargo, incluso las organizaciones con sólidos programas de seguridad y especialistas internos pueden aprovechar este momento para evaluar a los equipos más técnicos en cuanto a lo que necesitan para ser más conscientes de la seguridad en el contexto de su función.

Para los especialistas en seguridad de las aplicaciones, los líderes de los equipos de desarrollo y los miembros más expertos en seguridad de la cohorte de ingenieros, puede parecer un poco como si les enseñaran a chupar huevos, pero son estos campeones dentro de la empresa los que pueden llevar la seguridad y la protección a nuevas cotas, en toda la empresa.

Cómo elevar el mes de la concienciación sobre la ciberseguridad

Esta es una oportunidad de oro para que el equipo de seguridad extienda una especie de rama de olivo al equipo de desarrollo, quizás en forma de actividades y programas entre equipos que puedan ayudar a los desarrolladores a sentirse más positivos respecto a la seguridad en el contexto de su trabajo.

Algunas ideas de inicio son:

1. Ayude a los desarrolladores a obtener el apoyo que necesitan para aprender a codificar de forma segura. No disponer de las herramientas adecuadas para el trabajo es una buena manera de justificar el hecho de que una tarea sea demasiado difícil. Si los desarrolladores no tienen la formación y las herramientas adecuadas para considerar la seguridad como una prioridad en el proceso de codificación, no es de extrañar que muchos equipos estén mal equipados para mantener las vulnerabilidades comunes fuera de su código.
   
   Aprovecha este mes para entender qué falta en la pila tecnológica de desarrollo, qué gestores pueden trabajar juntos para mejorar la comunicación y aumentar la visibilidad de la seguridad, y quién puede seguir defendiendo y defendiendo la seguridad en el futuro.
   
2. Organice un evento "Lunch and Learn". Las comunidades de ciberseguridad y desarrollo están, en general, repletas de gente increíblemente generosa que está encantada de compartir su experiencia. Ponte en contacto con los ponentes de las conferencias, los compañeros de tecnología de otras empresas o incluso los capítulos locales de OWASP, y mira quién podría venir a charlar con el equipo o grabar un seminario web con alguien de la organización. Es una ganancia relativamente rápida, y puede ser un gran beneficio para los desarrolladores prometedores para ver diferentes vías de carrera de seguridad en frente de ellos.
   
3. Reúnete para una competición amistosa. Aprender sobre seguridad es mucho más divertido cuando se hace algo un poco diferente y especial. La codificación segura tournaments es una forma estupenda de que los desarrolladores pongan a prueba sus habilidades de codificación segura y compitan con sus compañeros en un entorno de juego. Organiza un concurso de disfraces y sé creativo con los equipos (¿qué tal si los desarrolladores se enfrentan a sus jefes?). Pida pizza y bebidas, y ponga música enérgica, y puede ser un evento para recordar para toda la organización.

Retribuir a la comunidad: Descargue su aplicación gratuita Secure Code Bootcamp

Yo mismo soy desarrollador y siempre hemos buscado lo que podemos compartir y utilizar de forma gratuita. Es un orgullo hacer algún programa gratuito que pueda ayudar a los demás, y este mes es un buen momento para reflexionar sobre nuestras raíces y ver lo que podemos aportar a la comunidad.

Para ello, nos complace anunciar nuestra nueva aplicación gratuita, Secure Code Bootcamp. Se trata de un compañero de codificación segura de bolsillo para los programadores que quieran desafiarse a sí mismos, aumentando progresivamente su conciencia de la seguridad en cualquier lugar y en cualquier momento.

Descargue ahora la aplicación para iOS y Android y aprenda a localizar e identificar las vulnerabilidades OWASP en Node.JS, Python:Django, Java:Spring, C# .NET: MVC:

No es ningún secreto que nuestra principal misión es hacer que el software y su desarrollo sean seguros; creados teniendo en cuenta la seguridad desde el principio de la producción. Nuestra visión establece un nuevo punto de referencia para la creación de software, en el que los desarrolladores cuentan con las habilidades y los conocimientos necesarios para detectar el código vulnerable durante el proceso de escritura y solucionarlo incluso antes de que se convierta en un problema.

Así que, teniendo esto en cuenta, puede que piense que estamos encantados de oír hablar de nuevas violaciones de datos, ciberataques y códigos explotados que afectan a empresas de todo el mundo; estos incidentes ciertamente ponen de manifiesto la necesidad de nuestro servicio en múltiples verticales. La verdad es que es bastante frustrante. Está claro que, como industria, estamos cometiendo los mismos errores una y otra vez, porque la mayoría de la educación en seguridad no es lo suficientemente sólida como para minimizar el riesgo y detener estas violaciones.

La última víctima de la violación de datos es Ticketmaster. Si te encuentras entre los miles de clientes afectados, habrás recibido un correo electrónico en el que se te notifica el incidente y que debes cambiar tu contraseña. Nadie espera que sus datos personales sean violados simplemente por comprar entradas para un concierto o un evento deportivo, y sin embargo aquí estamos.

Es una situación horrible para todos; perjudicial para la reputación de Ticketmaster y una experiencia de cliente francamente mala. Sin embargo, hay un problema: no fue del todo culpa suya.

La empresa utilizaba los servicios de una aplicación de atención al cliente de terceros de Inbenta Technologies. Ticketmaster UK descubrió que el producto contenía un código malicioso, lo que hizo que el cinco por ciento de los datos de sus clientes a nivel mundial se vieran comprometidos.

¿Y cómo consiguieron exactamente los hackers explotar este sistema? Manipularon una única línea de código JavaScript, personalizada por Inbenta Technologies para las necesidades de Ticketmaster. Según Inbenta, el código se utilizó en una página para la que no fue construido, y de haberlo sabido, lo habrían identificado como una vulnerabilidad de seguridad.

La vulnerabilidad en sí es esencialmente un problema de seguridad de la biblioteca de carga/almacenamiento de archivos, en el que una sola violación puede afectar a todos los sitios en los que se cargue el mismo código. El código puede ser modificado para recoger y redirigir datos personales a los atacantes, sólo para empezar. Se trata de un simple exploit con un potencial de daño de gran alcance, y es algo contra lo que estamos trabajando con una serie de ejercicios de formación en la plataforma para los desarrolladores.

Por supuesto, es prácticamente imposible dirigir un negocio sin depender de algunas aplicaciones de terceros. Sin embargo, no tienes ningún control sobre cómo construyen su software, y esencialmente cero visibilidad en la fuerza de seguridad de su código. Se convierte en un ejercicio de confianza. Si su socio externo es poco riguroso en sus prácticas de codificación segura, puede estar abriendo la puerta a una brecha en su empresa.

Entonces, ¿cuál es la solución? En pocas palabras: todos debemos hacerlo mejor. Debemos dejar de pensar en la seguridad como un obstáculo irritante en el camino de la innovación empresarial.

Es más fácil de lo que cree dotar a su equipo de desarrollo de las herramientas y los conocimientos adecuados para adoptar la seguridad y detener el código malicioso en su camino. Nos ha complacido ver que muchas de las empresas financieras, de telecomunicaciones, de venta al por menor y de tecnología más grandes y conocidas del mundo han adoptado este nuevo enfoque, pero no debería ser un dominio exclusivo de las empresas de la lista Fortune 100 el tomar medidas en materia de educación en seguridad. Todas las empresas que cuentan con desarrolladores entre su personal necesitan implementar la formación para ayudar a los equipos a codificar de forma segura.

El libro blanco recientemente publicado que escribí junto con nuestro CTO Matias Madou, muestra los beneficios de construir una cultura de seguridad en su organización. Detallamos por qué es la clave para desbloquear la innovación, mantenerse ágil y reducir el impacto financiero del código inseguro.

Encontrarás consejos como:

Cómo hacer que la formación en seguridad sea relevante y atractiva para los desarrolladores

Cómo enseñar a los desarrolladores a identificar y solucionar sus propios problemas

* Cómo ayudar a los desarrolladores a construir su propio código de forma segura.

Le invito a que descargue este recurso y lo utilice para defender la seguridad en su organización, desarrollar las habilidades de su equipo y estar a la vanguardia del establecimiento de un estándar de código más alto.

Debemos dejar de pensar en la seguridad como un obstáculo irritante en el camino de la innovación empresarial.

Si le preguntara cuánto costaría cambiar una sola línea de código informático en un dispositivo que ya está en servicio, ¿qué cifra le vendría a la mente? ¿Unos cientos de dólares? ¿Tal vez miles?

Según Aviation Today, a una compañía aérea comercial le cuesta un millón de dólares actualizar una línea de código en sus aviones. Para un coste tan importante, probablemente necesitarían una razón de peso para dar los pasos necesarios para realizar cualquier actualización de los sistemas de sus aviones, lo que realmente me hizo pensar en una serie de factores.

Desglosar el coste

Aunque el artículo no explica en qué consiste el coste de un millón de dólares, creo que es una cifra viable. No soy un experto específicamente en actualizaciones de software de aerolíneas, pero puedo suponer algunos de los pasos que la aerolínea se ve obligada a dar en esta situación.

En primer lugar, la compañía aérea tiene que descubrir un fallo o una vulnerabilidad que haga necesaria la actualización. El ejemplo citado consiste en una investigación realizada por el Departamento de Seguridad Nacional de Estados Unidos (DHS) en un Boeing 757. Los resultados -un hackeo remoto tras sólo dos días de trabajo- son más que convincentes para que cualquier aerolínea tome nota.

A partir de ahí, los desarrolladores de software tienen que analizar los resultados, escribir un nuevo código y probarlo en un entorno seguro para asegurarse de que el problema está solucionado. Ahora viene la parte complicada. La aerolínea tiene que dejar en tierra cada avión vulnerable o defectuoso, aplicar el nuevo código, probarlo para asegurarse de que funciona con ese avión concreto y, a continuación, volver a certificar ese plan para el vuelo comercial.

Según airfleets.net, Southwest Airlines tiene actualmente 499 aviones Boeing 737-700 en su flota. Considere la inversión de tiempo y dinero que supondría la aparición de un fallo de seguridad en este modelo de avión en particular.

No es sólo un reto para las aerolíneas

Está claro que las compañías aéreas deberían tener interés en emplear principios de codificación seguros desde el principio. Después de pensarlo un momento, pude ver numerosas industrias y situaciones en las que podría aplicarse un coste similar. En lugar de preocuparse por los aviones que caen del cielo debido a una vulnerabilidad hackeada, ¿qué pasa con los dispositivos médicos como los marcapasos? ¿Cuánto cuesta retirar y actualizar medio millón de piezas electrónicas que salvan vidas?

En la industria del automóvil, seguimos oyendo hablar y preocuparnos por la seguridad de los coches autoconducidos. Sin embargo, incluso nuestros vehículos "típicos" dependen más que nunca de la conectividad a Internet, lo que lleva directamente a algunas preocupaciones de seguridad preocupantes, aunque entretenidas.

Es un hecho simple que cuesta mucho más dinero y lleva más esfuerzo y tiempo actualizar los dispositivos o sistemas después de que se hayan lanzado en un entorno de producción, o antes de que se hayan producido en masa, que construir la seguridad en su proceso de desarrollo inicial. Sin embargo, seguimos viendo cada día nuevos fallos de software y vulnerabilidades de ciberseguridad evitables, lo que subraya la necesidad de que las empresas busquen formas de incorporar el desarrollo de software seguro a su cultura de desarrollo.

El coste de cambiar una línea de código en un equipo de aviónica es de un millón de dólares, y se tarda un año en aplicarlo. Para Southwest Airlines, cuya flota se basa en el 737 de Boeing, les llevaría a la "quiebra" si una cibervulnerabilidad fuera específica de los sistemas a bordo de los 737

‍

A principios de este mes, tuve la oportunidad de asistir al OWASP AppSec Day 2019 en la hermosa Melbourne. Estos eventos centrados en los desarrolladores están entre mis favoritos del calendario; proporcionan un humilde recordatorio de la comunidad que trabaja incansablemente para educar y empoderar a los ingenieros y especialistas de software para defender la seguridad en su trabajo.

El cartel de invitados fue sensacional -por no hablar de su refrescante diversidad- y es una gran sensación que, incluso después de todos estos años en el sector, yo también pueda salir inspirado. Personas como Tanya Janca, Toni James y Teri Radichel ofrecieron presentaciones increíbles, mientras que Wireghoul'Eldar Marcussen puso a prueba a todo el auditorio con desafíos de codificación segura en el acto, pero fue genial ser testigo de tanta conciencia de seguridad entre los asistentes.

Este año, Secure Code Warrior fue un patrocinador platino del evento. Tuve que sonreír al recordar que hace sólo cuatro años, era el equipo detrás de OWASP AppSec Day el que ayudaba a nuestra startup de arranque con un stand gratuito y promoción. Fue un momento de orgullo al ver lo lejos que habíamos llegado como empresa, y un momento para agradecer que exista una comunidad tan generosa de gente increíble.

Toni James: La seguridad desde la perspectiva del desarrollador

Si hay algo que debemos cultivar más en este mundo, es la empatía. Y cuando se trata de hacer que el software sea más seguro en todos los ámbitos, es esencial comprender la difícil situación del desarrollador.

Me gustó mucho la presentación de Toni, y estoy seguro de que todos los desarrolladores pudieron identificarla al instante. Hay mucho más en la historia que simplemente "escribir código seguro", y aunque ciertamente creo que los desarrolladores formados eficazmente en seguridad son nuestra mejor oportunidad en la lucha contra las vulnerabilidades, es imperativo considerar sus desafíos diarios.

El trabajo de un desarrollador de software puede estar a la vista de millones de usuarios, dar soporte a infraestructuras críticas y ser la fuerza motriz de servicios que damos por sentado. La creación de características, la ejecución de innovaciones empresariales y el cumplimiento de plazos de entrega ajustados suponen una gran presión, y eso antes de que un equipo de AppSec se asome a su trabajo. Toni habló de cómo es la vida en este entorno, y de cómo una buena dosis de empatía por parte de todos puede conducir a procesos y resultados de seguridad mucho mejores. Me complace mucho ver que se están dando pasos tan saludables para salvar la brecha entre los desarrolladores y los equipos de AppSec; al fin y al cabo, este es un elemento crítico en una cultura de seguridad positiva y próspera, y Toni es un excelente ejemplo de que este proceso funciona increíblemente bien.

Tanya Janca y Teri Radichel: Superhéroes de la seguridad

No es que sea una competición, pero las contribuciones de Tanya Janca y Teri Radichel a la conferencia estuvieron entre mis favoritas. A los diez minutos de su tutorial sobre evaluaciones de seguridad en la nube DIY, se puso de manifiesto su increíble amplitud de experiencia, cualificaciones y conocimientos, pero también su genuina calidez y deseo de compartir conocimientos y apoyar a la comunidad de desarrolladores. Juntos, presentaron acciones realistas y ejecutables para garantizar que las implementaciones de Azure fueran seguras, incluyendo consejos prácticos para establecer políticas de seguridad y medidas de mínimo privilegio.

Una rápida búsqueda en Google le dirá todo lo que necesita saber sobre su dedicación a apoyar a los desarrolladores a nivel de base, con una gran cantidad de recursos gratuitos, oportunidades de tutoría y entrevistas para promover el lado divertido y atractivo de la seguridad del software. Son campeones inspiradores y vitales de nuestra comunidad; si intervienen en la próxima conferencia de seguridad a la que asistas, estarías loco si te perdieras su sesión.

Clientes en el gran escenario

Fue brillante ver a tantos de nuestros clientes no sólo en la asistencia, sino también siendo dueños del escenario y compartiendo sus inmensos conocimientos de seguridad con la audiencia.

Conseguimos ver a Andrew Bailey, de Telstra, dando una importante charla, "Añadiendo el "Sec" a DevOps". Su gran experiencia como ingeniero de software senior, ahora centrado en la seguridad de las aplicaciones y la codificación segura, fue una perspectiva excelente para destacar. Dio consejos de principio a fin sobre cómo inyectar la seguridad en cada etapa del SDLC (incluyendo, por supuesto, justo al principio, formando a más desarrolladores en la codificación segura).

Ken Johnson forma parte del equipo de seguridad de GitHub, y me encantó verlo unirse al panel de expertos al final de la conferencia. Él, junto con los demás panelistas, estuvo encantado de responder a las preguntas urgentes del público, incluidas aquellas que no reciben necesariamente la atención que merecen en los medios de comunicación. Además de varias ideas del sector, hizo que el panel hablara de la importancia del bienestar y del equilibrio entre el trabajo y la vida privada, algo muy importante en esta época de agotamiento de los desarrolladores.

Me gustaría extender un enorme agradecimiento a Julian Berton y a todo el equipo de OWASP Melbourne por otra increíble conferencia. Nos vemos el año que viene (con más pegatinas).

Recientemente me entrevistaron para el podcast Silver Bullet, presentado por Gary McGraw, en el que hablé de las ventajas de la industria sobre la investigación académica, de por qué no es fácil crear una empresa en Europa y de hacia dónde se dirige la industria de la seguridad de las aplicaciones en el futuro.

Aunque nunca fue mi intención iniciar un negocio, lo hice porque vi que demasiadas empresas luchaban con el mismo problema; escribir código seguro es un reto para la mayoría de los desarrolladores. Tenemos toda una industria centrada en encontrar problemas de seguridad en el código, y estos problemas no hacen más que acumularse.

Hay muy pocas soluciones que se centren realmente en ayudar de forma eficiente a las organizaciones y a su equipo de desarrollo que luchan por arreglar los problemas encontrados, y menos aún en tratar de evitar que se introduzcan más problemas en el código. Cada vez más, las organizaciones están tomando conciencia de este círculo vicioso y se están dando cuenta de que su equipo de desarrollo necesita ser entrenado en la escritura de código seguro desde el principio y necesitan estar equipados con las herramientas y procesos que les permitan.

Si quieres saber más sobre cómo Gary McGraw y yo mismo vemos el avance de la industria, ¡consulta el podcast Silver Bullet!

Programa 139: Matias Madou habla de la formación en desarrollo seguro y de la investigación en pruebas de seguridad del software

https://www.synopsys.com/software-integrity/resources/podcasts/show-139.html