Insights sur le code sécurisé

「タップ」と「ハイジャック」を組み合わせたタップジャックは、まさにそれを意味します。これは、攻撃者がユーザーのタップをハイジャックして、意図しないことをするように仕向ける攻撃です。では、この攻撃はどのように機能し、どのように防ぐことができるのでしょうか。

ストーリーはスクリーンオーバーレイから始めます。スクリーンオーバーレイ、またはGoogleが言うところの「TYPE_APPLICATION_OVERLAY」タイプのウィンドウ。 これらは他のアプリの上部に描画されるウィンドウで、通常は画面の一部のみが見えにくくなります。これらは、アプリが新しい権限をリクエストするときによく使用されます (下の画像の例のように)。

これは実際にはクールで楽しい機能であり、ますます多くのアプリが使用され始めています。下のスクリーンショットのように、Facebookのチャットバブルや、画面の隅にあるGoogleマップのナビゲーションについて考えてみてください。

ただし、これらのオーバーレイにはセキュリティ上のリスクが伴います。アクティブなスクリーンオーバーレイはどれもタップを聞き取ることができますが、バブルをタップまたはドラッグしたことをFacebookが知るにはどうすればよいでしょうか？これにより、アプリがユーザーをスパイし、パスワードやクレジットカードデータを盗む可能性があります。

さらに一歩進んで、タップジャックという用語の由来にもなっています。オーバーレイは、他のアプリの上に何かを描画して、ユーザーをだましてさまざまなアクションを実行させることができます。ユーザーは自分がオーバーレイを操作していると思っていますが、実際には、タップは基盤となるアプリでもアクションを実行します。こうすることで、この例のように、オーバーレイはユーザーを騙して特定の権限を有効にさせたり、危険な設定を変更させたりすることができます。 古いユーチューブの動画。

上のデモ動画は2010年にYouTubeにアップロードされたので、古いバージョンのAndroidで撮影したものです。しかし、この攻撃は今日でもなお重要であり、 脆弱性 ヌガーやマシュマロなどの新しいバージョンのAndroidでタップジャックを許可することが明らかになりました。

それで、あなたはそれについて何ができるでしょうか？ユーザーとしては、これらのオーバーレイがもたらす影響を認識し、オーバーレイを使用するアプリについて知っておくことが重要です。API レベル 23 (Android 6.0 マシュマロ) 以降、この権限は次のような権限になりました。 ユーザーによる明示的な許可が必要です。しかし、それは去ります アンドロイドの 50%ユーザーは依然として脆弱です。どのアプリがこの権限を使用しているかは、「他のアプリの上に表示する」の設定で引き続き確認できます。

開発者の責任は、ユーザーのアクションがユーザーの完全な知識と同意を得て行われるようにすることです。Android では、そのためのビュー設定として、次のような設定が用意されています。 フィルタータッチがぼやけている場合。 これを有効にすると、ビューウィンドウが別の表示ウィンドウに隠れると、フレームワークは受け取ったタッチを破棄します。それだけ簡単なので、設定してください。 不明瞭になったらタッチをフィルタする true に設定すると、アプリはタップジャッキングから安全になります。

頑張って、また来週会いましょう！

許可リクエストの付与、購入、広告のクリックなど、ユーザーの十分な知識と同意を得た上でアクションが実行されていることをアプリケーションで確認できることが不可欠な場合があります。残念なことに、悪意のあるアプリケーションが、ビューの意図された目的を隠すことで、気づかないうちにユーザーを騙してこれらのアクションを実行させようとする可能性があります。

https://developer.android.com/reference/android/view/View.html

もともとはに掲載されました DevSecCon ブログ。

私は、セキュリティ・ベスト・プラクティスを守るうえで、開発チームとアプリケーション・セキュリティ・スペシャリストの間に生じる緊張関係について、両者の立場に立ってきたことをよく知っています。

難しいことです。結局のところ、開発者の最優先事項はソフトウェア機能の提供です。美しく、機能的で、アプリケーションの力をアピールできるものでなければなりません。最近ではアジャイル開発手法が一般的に行われているため、これらの機能は厳しい期限内に完成させる必要があります。また、セキュリティが懸念事項のリストの上位にあり、他にも多くのことが危機に瀕していることはめったにありません。

セキュリティはAppSecチームの領域と見なされています。AppSecチームは、コードをスキャンして（さらに悪いことに、1行ずつ手動で確認して）、コードが安全でないか、まったく使用できないことを開発チームに報告するといううらやましいほどの仕事をしています。彼らは自分たちの良い仕事をぶち壊し、イノベーションを阻害し、一般に開発者にとって頭痛の種となる泥棒のような存在です。結局のところ、セキュリティ問題の多くは非常に単純な解決策です。「おそらく、たった1行のコードで、脆弱なバックドアを数分で強化できるでしょう。

しかし、ここに問題があります。「セキュリティ」はネガティブな体験と同義語なので、開発者は本来あるべきほど密接に関わっていないだけです。このような一行の修正は行われていません。結局のところ、AppSecの担当者は常に同じ問題に遭遇しているのです。私たちが最初にSQLインジェクションの欠陥を発見 (およびその後の修正) してから20年以上経った今でも、彼らがSQLインジェクションの欠陥を指摘しているのはかなり腹立たしいことでしょう。

これまでに行ったことは、期待していたほど効果的に機能していません。私たちは、開発者とアプリケーション・セキュリティ・スペシャリストの間の架け橋を修復することに注力し、開発者がこの分野で真のインパクトをもたらすためのツールとトレーニングを受けられるような、ポジティブなセキュリティ文化の構築に努める必要があります。

誰が知っている？私のように彼らも好きになるかもしれない！

ポジティブ・セキュリティは、アプリケーション・セキュリティを向上させる最も迅速で簡単な方法です

「シティ」と、いや、目に見えない成果については大げさではありません。これは、安全なコーディングを成功に導くための絶対不可欠な要素です。

開発者は、最初に安全なコードを書くことによって、本番環境の最初からセキュリティを向上させる鍵を握っています。ポジティブなセキュリティ文化を醸成し、開発者がアプリケーションのセキュリティにワクワクするようになれば、AppSecの領域でスキャンや手動によるコードレビューを受ける前に、一般的な脆弱性を一掃できます。

それは すでにコミットされているコードの脆弱性を修正すると、30 倍の費用がかかるしたがって、開発者の強みを生かし、関心を持ち、実際に機能するトレーニングを見つけることは、繰り返し発生する脆弱性を特定して修正するための将来のコスト削減における大きな一歩となります。

開発者に焦点を当てた積極的な取り組みは、適切なセキュリティ文化を育みます。

全員がセキュリティのベストプラクティスを理解していれば、ポジティブなセキュリティ文化は幸せで不可欠な副産物になります。

積極的でスケーラブルな開発者中心の取り組みは、適切なセキュリティ文化を育みます。開発者を勝利に導くためには、問題解決能力と創造性を備えた開発者の意欲を引き付けることが不可欠です。また、新入社員がチームのセキュリティに対する期待に迅速に対応できるようにすることも重要です。 連絡を取る 開発者のセキュリティ関係がどのように発展してきたかについての概要と、セキュリティ意識向上プログラムを組織で成功させるためのアイデアを紹介します。

コンピュータシステム上のファイルを削除するのは難しいです。お母さんも含め、誰もが以前にファイルを削除しすぎたことがあるので、ゴミ箱に残っていて元に戻せることに満足しています。

コンピュータシステムのデータは一連のビットで表されます。つまり、システムは、どのビットがどのファイルを表しているのかを知るために、ファイルシステム内で何らかの管理を行う必要があります。この情報には、ファイルのサイズ、最終更新日時、所有者、アクセス権などがあります。この簿記データはファイルの内容とは別に保存されます。

通常、ファイルが削除されても、そのファイルを表すビットには何も起こらないが、記憶域のこの部分は無意味で再利用できることをシステムが認識できるように、記録データが変更される。この場所に別のファイルが保存され、その場所のビットが上書きされるまで、保存されたデータを回復できることがよくあります。これにより、ファイルの削除速度が向上するだけでなく、削除を取り消すのに便利な機能であることがよくあります。

ただし、このアプローチには欠点があります。コンピューターシステム上のアプリケーションが機密情報を処理する場合、そのデータはファイルシステムのどこかに保存されます。ある時点で、その情報が不要になると、このデータは削除されることがあります。開発者の意図がすべてのデータを削除したとしても、特に注意を払わなければ、このデータは回復可能な場合があります。

そのデータを完全に消去する最も簡単な方法は、ファイルの内容をランダムなデータで書き換えることです (場合によっては数回繰り返すこともあります)。既存の安全なファイル削除方法はいくつかあり、それらはストレージの種類やファイルシステムによって異なります (Gutmann メソッドなど)。ただし、日常的なアプリケーションの使用では、これらは少しやり過ぎで、自分でデータを上書きするだけで済みます。

ただし、注意してください。すべてゼロやその他の低エントロピーのデータは使用しないでください。多くのファイルシステムは、このようなスパースファイルの書き込みを最適化し、元の内容の一部を残す場合があります。ファイル自体を削除する前に、安全にランダムなデータを生成してファイルの内容全体を上書きすることが推奨されます。

データ残留とは、何らかの方法で消去されたデータが物理的に残っている状態のことです。ストレージメディアを消去した後には、データを再構築できる物理特性がある場合があります。

https://fas.org/irp/nsa/rainbow/tg025-2.htm

Alors que le nombre de cyber-menaces ne cesse d'augmenter, les organisations doivent quotidiennement faire des compromis entre la sécurité, l'aspect pratique et la rapidité, s'exposant ainsi à des risques. De nouvelles approches du codage sécurisé sont nécessaires, c'est pourquoi Secure Code Warrior s'est engagé avec Evans Data Corp. à mener une recherche primaire sur les attitudes des développeurs envers le codage sécurisé, les pratiques de codage sécurisé et les opérations de sécurité (téléchargez le livre blanc ici).

Ce rapport a révélé que si la pensée réactive "à l'ancienne" domine encore, il y a une prise de conscience croissante de la nécessité de solutions plus proactives, qui transforment les développeurs eux-mêmes en première ligne de défense.  

Toute exploration de l'adoption de pratiques de codage sécurisées doit commencer par une compréhension des personnes impliquées dans sa mise en œuvre, de leurs perceptions et de leur capacité à la mettre en œuvre. Cela nous amène à la pièce la plus importante du puzzle : comment leur donner les moyens de coder de manière plus sûre dès le départ et de livrer un code de qualité plus rapidement et en toute confiance ? 

Codage sécurisé - où en sommes-nous aujourd'hui et qu'est-ce qui doit changer ? Téléchargez l'infographie l'infographie "L'élément humain".

Perspectives actuelles - réactivité ou proactivité

Lorsque les développeurs et les responsables du développement ont été interrogés sur les activités qu'ils associent au codage sécurisé, les trois réponses les plus fréquentes ont été les suivantes :

• Utilisation d'outils d'analyse sur les applications déployées.
• Examiner manuellement le code pour détecter les vulnérabilités.
• La pratique active et continue de l'écriture de logiciels protégés contre les vulnérabilités.

Comme nous pouvons le constater, deux des trois premières réponses se concentrent toujours sur des approches réactives - la première dépend d'outils (scanners), et la seconde du développeur (c'est-à-dire de l'homme) qui effectue des vérifications manuelles.

Dans le même temps, deux des trois activités proposées reposent sur l'élément humain. Cela montre que la sécurité est de plus en plus perçue comme une question humaine. Mais de toutes les activités proposées, la plus révélatrice est la n° 3, qui identifie le facteur humain dans l'écriture de logiciels protégés dès le départ contre les vulnérabilités. Cela met en évidence un changement vers la gauche - une approche proactive et préventive qui intègre la sécurité dans les logiciels dès le début du cycle de vie du logiciel (SDLC). 

Quelle est la place de la sécurité dans le cycle de développement durable ? 

Lorsqu'on demande aux développeurs et aux responsables du développement où ils considèrent que les pratiques de codage sécurisé s'intègrent dans le cycle de développement durable, les avis divergent. 55 % des responsables pensent que le codage sécurisé est intégré dans l'ensemble du processus de développement, contre seulement 43 % des développeurs. Cette différence pourrait refléter les rôles différents de ces deux groupes au sein du cycle de développement durable. La direction est généralement moins impliquée dans le travail de codage proprement dit et a tendance à avoir une vue d'ensemble, tandis que les développeurs peuvent être plus concernés par les rouages.

Mais du point de vue de la sécurité globale et de la qualité du code, ce qui est alarmant, c'est que seulement 13 % des développeurs et 10 % des responsables affirment que les pratiques de code sécurisé devraient être intégrées dans les étapes de conception - dès le début du cycle de développement durable. Il s'agit là d'une opportunité énorme et inexploitée. Selon une étude d'IBM, il est trente fois plus coûteux de corriger les vulnérabilités d'un code après sa publication que si elles avaient été détectées et corrigées dès le départ.1 Il s'agit là d'une puissante incitation à une nouvelle défense proactive et humaine de la sécurité des logiciels, qui permette aux développeurs de coder de manière plus sûre, dès le départ. La sécurité des logiciels ne peut être résolue en s'appuyant uniquement sur des outils - elle doit tenir compte de l'élément humain. 

L'élément humain est-il prêt ?

97 % des développeurs interrogés estiment avoir reçu une formation suffisante en matière de codage sécurisé, et 95 % reconnaissent que cette formation a été utile à leur carrière. Mais avant d'accepter ces affirmations à leur juste valeur, nous devons nous poser la question suivante : pourquoi les vulnérabilités du code sont-elles encore si répandues ? Les affirmations des développeurs concernant leur expertise en matière de codage sécurisé ne sont-elles qu'une question d'ego humain ? Les faits vont certainement dans ce sens. Plus modestement, plus de 88 % des développeurs interrogés admettent que le codage sécurisé est difficile à apprendre, et 91 % des responsables du développement reconnaissent que les pratiques de codage sécurisé sont difficiles à mettre en œuvre. Lorsqu'on leur demande d'identifier leurs principales préoccupations personnelles concernant la mise en œuvre du codage sécurisé, 28 % des développeurs trouvent le processus d'apprentissage difficile, tandis que 24 % trouvent le processus d'apprentissage ennuyeux. Cela montre que la formation des développeurs doit être améliorée. 

De quoi l'élément humain a-t-il besoin ? 

Pour surmonter le facteur "défi", une formation sécurisée digne de ce nom nécessite un processus d'"échafaudage" qui aide le développeur à acquérir des compétences de codage sécurisé étape par étape. Pour une pertinence maximale et une applicabilité immédiate, cette formation doit se dérouler dans le langage spécifique : le cadre qu'ils utilisent tous les jours.

Pour surmonter le facteur "ennui", la formation au code sécurisé doit être dispensée de manière pratique - il a été prouvé qu'elle est beaucoup plus attrayante pour les développeurs que les modèles obsolètes de salle de classe ou de "visionnage de cette vidéo". Ces méthodes doivent inclure des simulations en direct qui permettent aux développeurs de relever des défis parfois risqués en matière de sécurité dans un environnement sûr. L'objectif devrait être d'enseigner aux développeurs comment trouver et corriger les vulnérabilités dans le code au fur et à mesure qu'ils travaillent et d'intégrer le codage sécurisé dans leur travail quotidien. Un autre facteur clé est le linting et le coaching à l'intérieur de l'IDE, qui aident les développeurs à apprendre et à se perfectionner en permanence au fur et à mesure qu'ils codent, en prévenant et en éliminant les vulnérabilités au fur et à mesure de leur travail.

Si vous souhaitez découvrir comment fournir à vos développeurs ce nouveau niveau d'outils et de formation centrés sur le développeur, réservez une démonstration dès maintenant.

Vous pouvez également télécharger votre exemplaire du livre blanc Passer de la réaction à la prévention : Le nouveau visage de la sécurité des applications.

‍

Les cyberattaques sont, sans aucun doute, en augmentation. Selon le rapport Verizon 2021 Data Breach Investigations Report, le paysage des menaces est aujourd'hui plus dangereux que jamais. Les organisations de toutes tailles sont confrontées à un volume d'attaques plus important et à un niveau de sophistication plus élevé de la part des acteurs de la menace qui les ciblent. Les taux de réussite des attaquants montent également en flèche.

L'analyse des attaques les plus récentes permet de révéler certaines des vulnérabilités et des techniques les plus courantes utilisées par les pirates au cours de cette offensive sans précédent contre les cyberdéfenses. Certaines des attaques les plus populaires, comme celles qui figurent dans le Top 10 des risques et vulnérabilités de sécurité pour 2021 de l'Open Web Application Security Project (OWASP), impliquent le vol ou la compromission d'informations d'identification. Et selon les recherches sur la sécurité menées par Akamai, l'écrasante majorité, près de 75 %, ciblait directement les informations d'identification détenues par les API.

L'essor et la possible ruine des API

Il n'est pas étonnant que les interfaces de programmation d'applications, plus communément appelées API, soient de plus en plus présentes dans les réseaux de presque toutes les organisations. Elles constituent un élément essentiel de la plupart des services en nuage, qui remplacent rapidement les fonctions des actifs sur site dans la plupart des entreprises, organisations et agences gouvernementales. De nos jours, il est pratiquement impossible d'exercer une activité ou d'accomplir une tâche sans passer par le cloud, en particulier pour les activités tournées vers le public. Cela signifie que les API seront certainement le ciment qui maintiendra ensemble un grand nombre de services dans chaque réseau.

Ce qui est étonnant avec les API, c'est qu'elles sont généralement petites et discrètes en termes d'allocation des ressources du réseau. De plus, elles sont totalement flexibles, ce qui leur permet d'effectuer presque n'importe quelle tâche. À la base, les API sont des éléments individuels de logiciel conçus pour contrôler ou gérer un programme particulier. Elles peuvent être utilisées pour exécuter des fonctions très spécifiques, comme l'accès aux données d'un système d'exploitation hôte, d'une application ou d'un service.

Malheureusement, c'est cette même flexibilité, et le fait qu'elles soient souvent petites et négligées par les équipes de sécurité, qui font des API des cibles attrayantes. La plupart des API sont conçues par les développeurs pour une flexibilité totale, de sorte qu'elles peuvent, par exemple, continuer à fonctionner même si le programme de base qu'elles gèrent est modifié ou changé. Et il existe peu de normes. Presque comme des flocons de neige, de nombreuses API sont uniques en ce sens qu'elles sont créées pour remplir une fonction particulière avec un seul programme sur un réseau spécifique. Si elles sont codées par des développeurs qui ne sont pas très sensibilisés à la sécurité ou qui ne se concentrent pas spécifiquement sur la sécurité, elles peuvent présenter et présenteront probablement un certain nombre de vulnérabilités que les attaquants pourront trouver et exploiter.

Malheureusement, le problème devient rapidement incontrôlable. Selon Gartner, d'ici 2022, les vulnérabilités impliquant des API deviendront le vecteur d'attaque le plus fréquent dans toutes les catégories de cybersécurité.

La principale raison pour laquelle les attaquants veulent compromettre les API n'est pas qu'ils puissent prendre le contrôle d'une fonction spécifique de l'API, mais plutôt qu'ils volent les informations d'identification qui y sont associées. L'un des plus gros problèmes des API, outre le fait qu'elles sont pleines de vulnérabilités, est qu'elles sont souvent sur-autorisées par rapport à leur fonctionnalité de base. Pour simplifier, la plupart des API ont un accès proche de celui d'un administrateur sur un réseau. Si un attaquant prend le contrôle d'une API, il peut souvent utiliser ses autorisations pour lancer des incursions plus profondes et plus substantielles dans un réseau. Et comme l'API a l'autorisation d'effectuer toutes les tâches vers lesquelles l'attaquant la redirige, ses actions peuvent souvent contourner la surveillance traditionnelle de la cybersécurité, car l'API n'enfreint aucune règle grâce à son accès à toutes les zones et à son laissez-passer VIP pour les coulisses.

Si les entreprises ne font pas attention, l'augmentation des API au sein de leur réseau et de leurs nuages peut également entraîner de graves problèmes si elles sont la cible d'attaquants.

Défendre les API

Aussi dangereuse que soit la situation des API, elle est loin d'être désespérée. Des mouvements tels que DevSecOps s 'efforcent de sensibiliser les développeurs à la sécurité et d'intégrer la sécurité et les meilleures pratiques dans tous les aspects de la création de logiciels, du développement aux tests et au déploiement. L'intégration de la sécurité des API dans le cadre de cette formation sera essentielle pour toute organisation qui souhaite contrer la tendance à l'exploitation des API jusqu'en 2022 et au-delà.

Cela dit, il existe quelques bonnes pratiques qui peuvent être mises en œuvre dès maintenant en termes de sécurité des API.

La première chose à faire est d'inclure des contrôles d'identité stricts pour toutes les API. Vous devriez presque les considérer comme des utilisateurs humains lorsque vous attribuez des autorisations. Ce n'est pas parce qu'une API n'est conçue que pour remplir une fonction spécifique que vous devez penser à ce qui pourrait se produire si un pirate parvenait à la compromettre. Envisagez d'utiliser un contrôle d'accès basé sur les rôles. Idéalement, vous devriez appliquer les principes de la confiance zéro à vos API et à vos utilisateurs, mais la route est souvent longue. Une bonne gestion des identités est un bon point de départ. Veillez simplement à inclure les API dans ce programme.

Vous devez également contrôler étroitement les différents appels effectués par vos API dans la mesure du possible. Si vous limitez ces appels à des demandes très contextuelles, il sera beaucoup plus difficile pour un pirate de les modifier à des fins malveillantes. Vous pouvez même superposer vos API, une API initiale effectuant un appel très contextuel à une autre API qui sait exactement ce qu'elle doit rechercher et ce qu'elle doit ignorer. Cela peut être un moyen efficace de limiter la fonctionnalité disponible pour un acteur de la menace, même s'il est en mesure d'exploiter et de compromettre une API au sein de cette chaîne.

Les menaces qui pèsent sur les API peuvent certainement sembler écrasantes. Mais en mettant en œuvre les meilleures pratiques et en aidant et récompensant les développeurs qui deviennent des champions de la sécurité, la situation peut sembler beaucoup moins désespérée. Avec une bonne formation et une bonne pratique, vous pouvez mettre en place un programme de sécurité solide qui laisse peu de marge de manœuvre aux attaquants, même s'ils devaient compromettre l'un de vos minuscules mais essentiels chevaux de bataille que sont les API.

アプリケーションセキュリティの専門家として、組織のアプリケーションのサイバーセーフティを確保するのがあなたの仕事です。ただし、アプリケーションを実行するコードを書く責任はあなたにはありません。開発チーム内のエンジニアが担当します。では、セキュリティを念頭に置いてシステムを開発していることを確認するにはどうすればよいでしょうか。

ほとんどの場合、次の一部、またはすべてを実行しているはずです。

• すべてのコードにセキュリティ上の欠陥がないか確認し、開発チームに報告して修正します。
• 安全な開発ライフサイクル全体を通じて、厳格なピアレビュープロセスを実施します。
• 社内または社外のセキュリティチームによる定期的なアプリケーション評価/侵入テストを実施する。
• 脆弱性を検出するためのスキャンツールを実装します。
  

これらは優れたベストプラクティスですが、費用もかかり、病気になるたびに抗生物質を服用するのと似ています。これには高額な費用がかかるだけでなく、効能が失われ、時間が経つにつれて免疫系が弱まる可能性があります。

そもそも、開発者が出荷するコードが安全に記述されていることを実際に確認するにはどうすればよいのでしょうか。

安全なコーディングはさておき、まず人々がどのように学ぶかを考えてください。私たちのほとんどは視覚的な学習者であり、実践を通して学びます。それでも、セキュア・コード・トレーニングは「すぐに使える」アクティビティとして提供されることが多く、開発者の日常業務には関係ありません。これは、開発者が業界標準に準拠するためにセキュリティトレーニングを頻繁に受けていることを証明することを目的としており、開発者が実際にその知識を身につけること、ましてや学習プロセスを楽しむことは言うまでもありません。

人間が学ぶ傾向があるもう一つの方法は、免疫システムが学ぶのと同じように、間違いを通して学ぶことです。T細胞は、過去にどのような病原体に遭遇して根絶に成功したかを記憶しているので、将来それらから身を守ることができます。これこそまさに、開発者が果たすべき役割です。 安全です SDLC。

間違いを犯さないことを期待するのは非現実的ですが、将来セキュリティ上の脆弱性につながるコーディングパターンを認識できるように準備しておくことはできます。

これが、堅牢なピアレビュープロセスが非常に強力になる理由でもあります。ある開発者がセキュリティ上の欠陥に気づかないからといって、別の開発者が気づかないわけではなく、開発チーム全体のトレーニングが行き届いていればいるほど、脆弱性が彼らの足跡に引っかかり、本番環境には届かない可能性が高くなります。

ソフトウェアの脆弱性は病原体のようなものです

ソフトウェアの脆弱性は、対処するためには覚えておく必要があるという意味で病原体のようなものです。病原体の場合、重篤な病気やそれ以上の症状を避けるために、免疫系に何回も曝露しないといけないことが多いです。

脆弱なソフトウェアによるサイバー攻撃が成功すると、組織が深刻な機能不全に陥ったり、死滅したりする可能性があります。しかし、開発者が制御された環境で最初にソフトウェアの脆弱性に触れるようになれば、セキュアコーディングの知識とスキルを高め、定期的に実践することで、脅威に対する免疫力を高めることができます。

管理された環境で開発者をセキュリティ上の欠陥にさらす

病気から完全に身を守ることはできませんが、免疫システムを高め、できるだけ健康を維持するためにできることはあります。定期的な運動、健康的な食事、十分な睡眠などは、一般的に強い免疫システムに関連するライフスタイルの選択肢の1つです。しかし、これらすべてには少しの努力が必要であり、継続的でなければなりません。毎日ジョギングを1週間続けたり、1か月間飲酒をやめたりしても、全体的な健康状態はほとんど変わりません。また、ランニングを始めた初日に外に出て10kを走るのはお勧めできません。まず、心臓と筋肉を運動にさらす必要があります。また、自分の体と大好きな健康的な食べ物や運動のバランスが取れるようになるまで、少し実験する必要があることもわかっています。

安全なソフトウェア開発に関しても、それほど違いはありません。学習は時間をかけて実践しながら行われます。開発者がセキュアコーディングのスキルを定期的に高めるには、同じ継続的なトレーニングが必要です。言うまでもなく、ソフトウェア開発は常に進化し、適応しています。つまり、脆弱性も同様です。そのため、簡単なトレーニングコースだけでは不十分です。開発者は、潜在的な脅威に十分精通し、それらから防御するための適切な準備を整えるために、定期的なスキルアップが必要です。

開発チーム内での集団免疫の実現を目指す

1 人ですべてのセキュリティ問題を防ぐことはできません。チームにセキュリティチャンピオンがいるのは素晴らしいことですが、最善の保護を受けるには、セキュリティの脆弱性とその防止方法について学んだ人が増えれば増えるほど、組織がそれを防ぐ可能性が高まります。繰り返しになりますが、免疫系が目的に応じてさまざまな種類のT細胞を使用する方法と大差ありません。すべての開発者は、セキュリティを確保するチームの一員です。責任を取る権限を与えられ、それをうまく行い、さらには楽しんで取り組めるようになれば、結果として、開発チーム内でサイバー脅威に対する集団的免責を築くことができます。

繰り返し露出されることでセキュリティを最優先に

私たちの脳は、免疫システムが機能するのと同じような方法で学習します。ドイツの心理学者 ヘルマン・エビングハウス 記憶と学習の分野のパイオニアでした。彼は、学習は時間をかけて、複数の学習セッションを経て行われなければならないと推論しました。私たちが学校にいるとき、最初の導入後に新しい知識を身につけることは決して期待されていません。最初に情報が提示され、次にガイダンスを受けて練習し、次に自分で練習します。そして、試験に合格するほど十分に学んだ後でも、時間と労力をかけて学んだ知識を定期的に活用しなければ、すぐに情報が忘れられがちです。高校時代のフランス語を覚えていると言える人はどれくらいいますか？

では、ある日、スライドを見て、誰かがセキュリティについて話しているのを聞くだけで、出席している開発者がより安全にコーディングできるようになったとどうして信じられますか？

繰り返し発生する脆弱性のパターンから、これはまったく機能しないことがわかります。

安全な開発免疫を実現するにはどうすればよいでしょうか？

答えは私たちの本性にあります。私たちの体と心は同じように働き、問題に逆らわずに一緒に働く限り、問題に対する美しい解決策を提供します。

アプリケーションの安全性を確保するには、まず開発者に安全なコードを書くためのスキルアップから始める必要があります。そうしないと、AppSecは引き続きすべてのコードのセキュリティ欠陥の確認と、繰り返し発生する同じ脆弱性の開発チームへの報告に全時間を費やし、何も学ばずに迅速に修正することになります。そして、次のリリースに向けてもう一度やり直してください。

それでは繰り返しましょう。

開発マネージャーと協力してそれを行うと、安全なSDLCを実装し、コンプライアンスボックスのセキュリティトレーニング要件を満たすだけでなく、開発プロセスに現実的な影響を与えることができます。何よりも重要なのは、AppSecが脆弱性に繰り返し遭遇したり、開発チームに報告したりすることがなくなり、開発者が脆弱性の修正に費やす時間が減るということです。つまり、世界をより良くする素晴らしいソフトウェアの作成と改善に、より多くの時間を費やすことができるということです。

開発チームのスキルアップの準備はできていますか？さっそく進んで デモを予約 私たちと一緒に。

ソフトウェア開発以外で働く人にとっては直感に反するように思えるかもしれませんが、長年にわたってアプリケーションセキュリティに携わってきた専門家の多くは、プログラミングの経験がほとんどまたはまったくないまま、これらの重要な役割を担ってきました。これらのアプリケーション・セキュリティ・プロフェッショナルは、多くの業界や組織の生命線となっているアプリケーションに脆弱性が忍び寄らないようにする責任を負うチームの一員ですが、実際に自分でコードを直接評価したり修正したりできる人はほとんどいません。

多くのセキュリティプロフェッショナルは、コーディングのバックグラウンドではなく、攻撃ベクトル、脅威、エクスプロイト、ビジネスリスクに関する重要な知識の観点から自分の役割に取り組んでいます。コードに対する見方は限られています。AppSecの達人全員が同じスキルセットを持っているわけではありませんが、多くの人は通常、コードレビュー担当者やスキャンツールと協力して、プログラムやシステムが組織の標準や関連する業界や政府の枠組みに従って保護されていることを確認しています。その後、調査結果に関するレポートを作成し、コードを破壊する可能性のある攻撃ベクトルに関する情報を送り返します。そうすれば、現在の作業にどんなに支障をきたすとしても、必要な修正を行うのは開発者次第です。

このような状況になった理由は、ネットワークとアプリケーションを保護する仕事が非常に大きいため、サイバーセキュリティに携わるすべての人がすべての役割を果たすことを期待するのは意味がないというのが長年の論理でした。深いコーディングスキルは開発者に任され、開発パイプラインのさらに下位でコードを記述したり編集したりできることはほとんど重視されませんでした。

その考え方は急速に変化しており、開発者がAppSecに有利なキャリアシフトやキャリアシフトを行うまたとない機会となっています。すべての開発者がいわゆるダークサイドを受け入れたがるわけではなく、多くの開発者はアプリケーションセキュリティチームについて特に前向きな意見を持っていません。しかし、そうする人にとっては、ますます魅力的になる真鍮の指輪を手に入れるのに今ほど良い時期はありません。

DevSecOps はほぼすべての業界を牽引しています

どの組織においても、セキュリティ意識の高いプログラマーや開発者の価値を高める最大の要因の1つは、よりアジャイルな開発手法を採用する動きがほぼ普遍的に行われていることです。 DevSecOps など。開発、セキュリティ、運用が組み合わさると、サイバーセキュリティは新しいソフトウェアの開発に端から端まで組み込まれる共通の責任となります。このような環境では、コーディング能力が全体的に貴重な資産と見なされるようになってきており、セキュリティを本質的に理解しているエンジニアにとっては特にそうです。

サイバーセキュリティを高いレベルで理解しているだけでなく、すべてを機能させるコードも理解しているAppSecプロフェッショナルは、理論的な知識に集中している人よりも、どの組織にとっても本質的に価値があります。コード内に見つかった脆弱性を迅速に発見して評価し、それらの問題を軽減できることが、DevSecOpsがこれほど人気を集めている理由の核心です。

AppSecで働く開発者は、彼らを雇用するあらゆる組織にとってもう一つの大きな利点でもあります。社内の開発側から来ているため、開発者はセキュリティや脆弱性について開発者と話しやすくなります。また、開発チームのコーチになるのがずっと簡単になり、開発チームがより優れたコーダーになるのに役立ちます。時間が経てば、AppSecの「ダークサイド」という汚名を取り除き、組織全体のソフトウェア開発チームを一つにまとめる助けにもなるかもしれません。

サイバーセキュリティのスキル不足は悪化の一途をたどっています

シェイクスピアは、それは誰にも何の役にも立たない悪風だと黙想しました。彼が言いたかったのは、どんなに暗い状況でもおそらく誰かに利益をもたらすということでした。サイバーセキュリティのスキル不足はその好例です。

人員不足はほとんどどこでも深刻に感じられています。で 最近の調査 戦略国際問題研究センターが実施した調査では、ITの意思決定者の 82% が、組織がサイバーセキュリティスキルの不足に苦しんでいると答え、71% が、その不足が組織に直接かつ測定可能な損害をもたらしたと回答しました。この危機をさらに詳しく見ると、報告書は、米国だけでも、2020年には約94万人しか雇用されていない分野で、サイバーセキュリティの求人が52万件以上空いていたと指摘しています。

サイバーセキュリティ人材の不足は、ますます危険になる脅威環境からインフラストラクチャ、ビジネス、データを保護しようとしている組織にとって悪いニュースです。しかし、アプリケーションセキュリティとセキュリティに参入しようとしている開発者にとっては良い機会となります。サイバーセキュリティとアプリケーションセキュリティに関する職種は、ほとんどどこでも募集されている可能性があります。また、サイバーセキュリティの職種は平均して 21% 時間の増加 最近は給料がずいぶん上がってきています

アプリケーション・セキュリティへの移行

開発者にとって、日当たりの良いセキュリティ分野に有利なジャンプをするのに今が絶好のタイミングかもしれません。セキュリティ意識の高い開発者は、もはや暫定的なセキュリティ手法の一部ではなく、サイバーセキュリティの防御者として、全面的かつ尊敬される役割を果たしています。これは特に、DevSecOps やその他のよりアジャイルな開発方法論を採用している組織に当てはまります。また、サイバーセキュリティの人材が不足しているということは、ほぼすべての企業、政府機関、組織でポジションが空いているということです。適切なスキルを持っている人は、働きたい場所を選ぶことができます。

AppSecへの移行はすべての人に適しているわけではありません。もちろん、ほとんどの開発者は素晴らしい機能の構築に引き続き注力するでしょう。しかし、移行を検討している人にとっては、セキュリティ・トレーニングに投資して既存のコーディング・スキルを強化することで、多くの可能性が開ける可能性があります。最高のアプリケーション・セキュリティ人材は、テクノロジーを深く理解し、仲間の開発者の窮状に共感しているため、エンジニアリングの分野で活躍しています。DevSecOpsということは、今や誰もがセキュリティの責任を負っていることを意味します。現在の重要なスキル不足を利用して、アプリケーション・セキュリティ分野でキャリアを積んでみませんか？あなた自身、家族、そしてキャリアのために前向きな動きをするのに今ほど良い時期はありません。

On parle d'attaque par canal latéral lorsqu'un pirate informatique peut obtenir des informations à partir de la mise en œuvre physique d'un système logiciel plutôt qu'à partir d'une faiblesse théorique dans l'algorithme ou d'un bogue dans le code du logiciel.

Un exemple que j'aime utiliser pour rendre cela plus clair est une façon d'énumérer le nom d'utilisateur. Si vous voulez savoir ce qu'est l'énumération de noms d'utilisateur ou pourquoi c'est mauvais, visitez notre site web pour une explication vidéo ou jouez à un défi pour voir si vous pouvez l'identifier dans le code.

Pour comprendre comment l'énumération des noms d'utilisateur peut être effectuée par le biais d'une attaque par canal latéral, vous devez comprendre comment les mots de passe sont (ou du moins devraient être) traités dans les applications web modernes. Une bonne application web ne connaît pas votre mot de passe, elle ne l'enregistre ni ne le stocke nulle part. Alors comment sait-elle que ce que vous avez tapé est correct et qu'il s'agit bien de votre mot de passe ? Eh bien, votre mot de passe est haché.

Une fonction de hachage est une opération mathématique facile à réaliser dans un sens (bien qu'un peu coûteuse en termes de calcul), mais très difficile à inverser. Lorsque vous vous inscrivez sur un site web, c'est ce hachage qui est stocké en toute sécurité, et non votre mot de passe lui-même. Cela signifie qu'à chaque fois que vous vous connectez, l'application web procède au hachage de votre entrée et compare les résultats du hachage au hachage stocké. Si vous souhaitez en savoir plus sur le stockage sécurisé des mots de passe, vous pouvez le faire sur notre plateforme.

Le hachage des données prend un certain temps sur un ordinateur et les développeurs essaient toujours d'optimiser tout ce qu'ils écrivent pour que les utilisateurs aient une expérience fluide. L'un des moyens d'accélérer le programme est d'ignorer le hachage lorsqu'il n'est pas nécessaire. Par exemple, lorsque le nom d'utilisateur n'existe pas (et donc qu'aucun mot de passe ne doit être vérifié), ils peuvent répondre à l'utilisateur immédiatement. De cette façon, ils peuvent sauter le calcul lent du hachage du mot de passe. Si le nom d'utilisateur est correct, il hachera le mot de passe saisi et le comparera au hachage stocké.

À ce stade, vous avez peut-être deviné où les choses peuvent mal tourner. Même si, en réalité, le hachage ne prend que quelques millisecondes, un pirate peut utiliser ce délai supplémentaire pour savoir si le nom d'utilisateur qu'il a saisi est correct ou non, car un nom d'utilisateur erroné aura une réponse légèrement plus rapide puisque aucun hachage n'a été effectué. Ce type d'attaque par canal latéral est appelé attaque temporelle et constitue un bon exemple de la manière dont différentes exigences non fonctionnelles peuvent se contrecarrer mutuellement. Parfois, un code ne peut pas être à la fois rapide et sûr.

Ainsi, même si les mots de passe sont traités parfaitement et que le message affiché est générique et ne précise pas si le mot de passe ou le nom d'utilisateur est incorrect, le système reste vulnérable. La solution est simple : toujours hacher le mot de passe ou retarder l'envoi de la réponse du temps nécessaire au hachage.

Les informations obtenues peuvent être utilisées par un pirate pour obtenir une liste des utilisateurs du système. Ces informations peuvent être utilisées pour attaquer l'application web, par exemple, par une attaque par force brute ou par nom d'utilisateur/mot de passe par défaut.

https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)

開発者のセキュリティスキルの重要性は、2022年のガートナー社の「ソフトウェアエンジニアリングにおけるクールベンダー」で強調されています。 レポートの全文はこちらでご覧いただけます。

セキュア・コード・ウォリアーは、4つのうちの1つとして認められていますソフトウェアエンジニアリングにおけるクールなベンダー:開発者の生産性の向上'、ガートナー社ガートナーによると、「クールベンダーの定義とは、革新的でインパクトのある、または興味をそそるテクノロジーやサービスを提供する小規模企業のことです。」クールベンダーには、次の 3 つの要素があります。

革新的 —ユーザーが以前はできなかったことを実行できるようにします。

インパクトのある — テクノロジーそのものだけでなく、ビジネスにも影響を及ぼしている、またはもたらす可能性がある。

興味をそそる —過去6か月間にガートナーの関心を集めました。

レポートで概説されているように、「ソフトウェアエンジニアは、生産性を維持しながら、複雑なコード環境をナビゲートし、構築したシステムのセキュリティを向上させることに苦労しています。これらのクールなベンダーは、ソフトウェアエンジニアリングリーダーが開発者の生産性を高め、セキュリティリスクを軽減するのに役立つ革新的なソリューションを提供しています。」

この評価は、開発者が主導するセキュリティに焦点を当てている唯一の上場企業であり、この評価は、適切なセキュリティスキルとコンテキストツールを備えた開発者がスキルを迅速に学習、構築、適用してソフトウェアのセキュリティを向上させるための安全なコードを迅速に配信できるようにするという当社の戦略の証です。

左にシフトすることのメリットは以前から称賛されてきましたが、多くの組織は、ソフトウェア開発ライフサイクルの最初にセキュリティを考慮に入れることにまだ苦労しています。私たちの最近の '開発者主導のセキュリティ調査の現状 安全なコーディング手法を採用する際に克服すべき最大のハードルは時間不足であることを強調しました。これは最近のガートナー社のレポートにも反映されています。熟練したエンジニアが大幅に不足していることと、膨大で複雑なコードリポジトリと、ランタイムスタックの半分以上がオープンソースソフトウェアで構成されているため、開発者は既存のコードを保守する時間がほとんどありません。セキュリティを確保することは気にしないでください。

Secure Code Warriorのソリューションは、ソフトウェアのセキュリティを確保すると同時に生産性を向上させるというニーズに応えています。前述の調査では、安全なコーディング手法を採用する時間が足りないと回答したにもかかわらず、76% の回答者が、安全なコーディングの適切なトレーニングは実際にはそうなるだろうと回答しました。 生産性の向上 セキュリティチケットの数が減り、管理の手間が省けます。適切なセキュリティスキルとツールがあれば、開発チームはリスクを簡単に軽減し、革新的な機能を備えた、安全で高品質なコードを迅速かつ一貫してリリースできます。

Secure Code Warriorだけでなく、セキュリティスキルのある開発者がサイバーセキュリティにおいて果たすことができる重要な役割を強調してくださったガートナーに感謝します。
‍

にアクセスする ソフトウェアエンジニアリングにおけるガートナー社のクールなベンダー:開発者の生産性の向上 今すぐ報告してください。

‍