Secure Code Warrior では、ゲーミフィケーションの力を信じて、開発者に安全なコーディングをさせることができると確信していることは周知の事実です。私たちが行っていることであり、これまでのところその成果は素晴らしいものです。しかし、新入社員の評価に実際のビデオゲームを使うのはどうでしょうか？それは行き過ぎなのか、それとも効果的な方法なのでしょうか？

これは、スタートアップのScoutible社が行っていることで、私はこのアプローチに興味を持った。Scoutible社は、ゲーム化された評価ではなく、実際のビデオゲームを使って採用候補者を評価し、特定の状況でその人がどのように行動するかをチェックする。このゲームでは、わずか20分のゲームプレイ中に「候補者のさまざまな属性を測定するための何百万ものデータポイント」を取得し、そのデータポイントを使って候補者が問題となっている仕事にどのように対応するかを評価します。

ここには気に入った点がたくさんあり、また学ぶべき点もたくさんあります。この製品は、顧客のニーズに柔軟に対応しており、採用担当者の多くが長い間抱えていた問題を解決しています。Myers-Briggsのような自己報告型のassessment は、信頼性がありません。完全に正直にならないことで、システムを「ゲーム」することができる、あるいは、そうしようとすることができます。ゲームでは、目的があり、その目的を達成するために適応し、問題を解決しなければなりません。非常にシンプルで、Scoutible社の主張通りに機能するのであれば、独創的なものです。早く話を聞いてみたいものです。

ゲーミングとゲーミフィケーション

Scoutible社のアプローチは、彼らのターゲット層とユースケースに合致しています。Secure Code Warrior の歩みの中で、完全なゲームプラットフォームやトレーニングに組み込まれたミニゲームの価値を検討したこともありましたが、最終的にはそのような角度からのアプローチでは当社の目的に十分な付加価値が得られませんでした。当社のセキュリティトレーニングを受講するエンドユーザーは、自分たちが学ぶべきことを知っています。

当社のSecure Code Warrior プラットフォームでは、ソフトウェア開発者の安全なコーディングスキルを測定すると同時に、ゲームベースの要素を用いて開発者を飽きさせないようにしています。つまり、以下の質問を念頭に置いています。

• ソフトウェアの最も一般的なセキュリティ上の弱点を理解しているか？
• フレームワーク固有のセキュリティ機能を使って、一般的なセキュリティバグを修正できるか？
• 自分のソフトウェア・セキュリティ・スキルに自信を持っているか
• セキュアコードの観点から、彼らの強みとスキルのギャップは何か？

ケアリング・バイ・デザイン

私がScoutible社の製品に強く共感できる理由はもう一つあります。それは、採用企業だけでなく、候補者にとってもメリットがあるということです。優秀な候補者が全員、面接が得意なわけではありません。性格的に面接が苦手な人もいれば、もともと面接が苦手な人もいます。また、面接のコツを教わったことがない人や、社会人になって初めての面接という人もいるでしょう。

ここがソフトウェア開発者との共通点だと思います。残念なことに、多くの大学のプログラムではセキュリティに焦点が当てられていません。開発者志望者は、「仕事をしながら学べばいい」と言われます。開発者は、コードを動作させる方法は知っていても、知らず知らずのうちに、私たちが20年以上にわたって戦ってきたのと同じ脆弱性を蔓延させてしまうのです。

開発者が仕事を得て、セキュリティについて学ぼうと思っても、学生時代よりも時間がないのが現状です。彼らは、機能的で効果的なソフトウェアを作ることで報酬を得ており、開発者向けのセキュリティ・トレーニングの多くは、courses ......まあ、つまらないものです。正直に言おう。

新旧を問わず、開発者がセキュリティについて深く考えずに関心を持てるようにするにはどうしたらいいでしょうか？どうすれば、トレーニングを面白く、魅力的で、楽しいものにし、しかも効果的なものにできるでしょうか？

これが私たちの挑戦であり、Scoutibleと同様に非常に現実的なものです。問題が非常に深刻だからといって、解決策が平凡でつまらないものである必要はありません。私たちはすでにそれを試みました。私たちは、解決策に少しの楽しさ、興奮、競争、関与を注入したいと考えています。これまでのところ、それは非常にうまくいっています。

ゲーム感覚のツールを作り、適切な性格や認知属性のテストを組み込むことができれば、私が研究してきた多くの問題を解決できると考えました。

https://www.inc.com/kevin-j-ryan/scoutible-video-game-reinventing-the-hiring-process.html

モバイル向けに開発する場合、アプリケーションはしばしばシステムに何らかの許可を要求しなければなりません。例えば、ユーザーの連絡先へのアクセスや、Bluetooth接続、SMSメッセージの送信などがあります。上述の許可はすべて、Androidフレームワークによって定義されたプラットフォーム許可です。

しかし、これらでは十分ではなく、アプリケーションが独自のカスタムパーミッションを定義する必要がある場合もあります。Secure Code Warrior は、SCWプラットフォーム上でのユーザのパフォーマンスなどのプライベートデータをプロファイルの一部として保存するアプリを作成します。そして、別のセキュリティトレーニングアプリ（例えばDevTrainer）が、ユーザから許可を得た場合に、このデータを使用することを許可したいと思います。これはセンシティブなデータで、ユーザは誰にも知られたくないと思っていますが、SCWAppはそれが有用であるかもしれないので、完全に隠して保護するべきではありません。そのため、ユーザがコントロールできるようにしたいと考えています。ここでカスタムパーミッションの出番です。

SCWAppがカスタムパーミッションを作成し、DevTrainerがこのパーミッションを要求し、ユーザはこれを許可するかどうかを決めることができます。これは一般的な方法で、ホワイトリストに登録されたアプリケーションへのアクセスを制限するのに適した方法です。

残念ながら、カスタムパーミッションには直感的に理解できない動作があり、セキュリティの観点からは危険なものとなっています。具体的には、カスタムパーミッションはどのアプリでもいつでも定義することができ、「先に手を打った者勝ち」となりますが、この戦略にはいくつかの結果が伴います。

以下のシナリオでは、上記で紹介した2つのアプリのプロファイルを定義します（これらのアプリはすべて、デモンストレーションのための架空のものです）。

1. SCWApp: カスタムパーミッションを定義し、そのパーミッションを使用してコンポーネントを防御するアプリです。

2.DevTrainer: このアプリはSCWAppと同じパーミッションを定義し、このパーミッションを保持することをユーザに宣言します。

これは「Peer Apps Case」と呼ばれる一般的なシナリオです。もし、DevTrainerアプリがSCWAppの単なるプラグインであれば、カスタムパーミッションを定義する必要はありません。このケースでは、SCWAppがDevTrainerより先にインストールされ、予期せぬ動作が起こらないことが前提となっています。何らかの方法でユーザがDevTrainerを先にインストールした場合、ユーザにはパーミッションの要求について知らされません。ユーザーが後からSCWAppをインストールした場合、DevTrainerには遡って許可が与えられないため、DevTrainerアプリが保護されたコンポーネントを使用しようとしても失敗します。

ここで登場するのが「Peers App Case」です。場合によっては、一方のアプリが他方のアプリより先にインストールされることを期待できないことがあります。例えば、FacebookとTwitterがお互いのコンポーネントを使用したい場合、お互いのカスタムパーミッションを定義しなければなりません。

しかし、ここからが厄介なのです。DevTrainerアプリが最初にインストールされた場合、ユーザにはカスタム・パーミッションの要求について通知されません。この時点では、ユーザに知らされていないにもかかわらず、DevTrainerはカスタムパーミッションを保持しており、セキュリティで保護されたコンポーネントにアクセスすることができます。

さらにやっかいなことになります。DevTrainerアプリは、パーミッションの保護レベルを変更することができます。Androidは防御側の保護レベルではなく、最初に定義された保護レベルを使用します。つまり、最初にインストールされたアプリが定義できるのです。つまり、DevTrainerがパーミッションレベルを通常に変更した場合、今後このパーミッションを要求するアプリは、ユーザーによる確認を必要とせず、自動的にアクセスが許可されることになります。

このシナリオは、cwac-securityのgithubにあるこの問題の説明からヒントを得ました。

先手必勝」戦略には危険な結果をもたらすものがあり、その動作を知らないと、開発者は信頼できない入力に基づいてセキュリティ上の判断を下し、意図しないアプリに機密データや保護されたサービスへのアクセスを許してしまう可能性があります。信頼できない入力によるセキュリティ上の判断を避けるための詳細については、当社のプラットフォームをご覧ください。この動作は、Android 5.0（Lollipop）で変更されました。しかし、現在、22％以上のAndroidデバイスがまだ低バージョンのAndroidを実行しているため、アプリで元の動作のリスクを軽減することが重要です。アプリの初回実行時にすでにパーミッションが定義されているかどうかを確認し、その場合は適切な対処をしてセキュリティリスクを解決してください。

頑張ってコーディングして、また来週お会いしましょう

カスタムパーミッションを定義することで、アプリはそのリソースや機能を他のアプリと共有することができます。

https://developer.android.com/guide/topics/permissions/defining.html

サイドチャネル攻撃とは、アルゴリズムの理論的な弱点やソフトウェアのコードのバグではなく、ソフトウェアシステムの物理的な実装からハッカーが情報を収集できることを言います。

私がこのことをより明確にするために使いたい例は、ユーザー名の列挙を行う方法です。ユーザー名の列挙とは何か、なぜそれが悪いのかを知りたい方は、当社のウェブサイトでビデオによる説明をご覧になるか、コードで識別できるかどうかチャレンジしてみてください。

サイドチャネル攻撃によってユーザ名の列挙がどのように行われるかを理解するためには、最新のウェブアプリケーショ ンでパスワードがどのように扱われているか（あるいは少なくともそうあるべきか）をある程度理解しておく必要があります。優れたウェブアプリケーションは、あなたのパスワードを知りませんし、どこにもパスワードを保存しません。では、あなたが入力したものが正しく、実際にあなたのパスワードであることをどうやって知ることができるのでしょうか？パスワードはハッシュ化されています。

ハッシュ関数とは、一方通行で実行するのは簡単だが（多少計算コストはかかるが）、逆に実行するのは非常に困難な数学的演算であり、優れたハッシュアルゴリズムでは、入力に応じて出力が一意になる。Webサイトに登録すると、パスワードそのものではなく、そのハッシュが安全に保存されます。つまり、ログインするたびに、ウェブアプリケーションは入力をハッシュ化し、ハッシュ化された結果を保存されたハッシュと比較するのです。安全なパスワード保存について詳しく知りたい方は、私たちのプラットフォームで学ぶことができます。

入力のハッシュ化はコンピュータでは時間がかかるため、開発者はユーザーがスムーズに利用できるように、書いたものすべてを最適化しようと常に心がけています。プログラムを高速化する一つの方法は、必要のないハッシュ化を省略することです。たとえば、ユーザー名が存在しない場合（つまり、パスワードをチェックする必要がない場合）には、ユーザーに即座に応答することができます。このようにして、パスワードのハッシュ化という遅い計算を省略することができます。ユーザー名が正しければ、入力されたパスワードをハッシュ化して、保存されているハッシュと比較します。

この時点で、何が問題になるか想像がつくかもしれません。実際にはハッシュ化にかかる時間はわずか数ミリ秒ですが、ハッカーはこの追加された遅延を利用して、入力したユーザー名が正しいかどうかを調べることができます。間違ったユーザー名の場合はハッシュ化が行われていないため、わずかに速いレスポンスが得られます。このようなサイドチャネル攻撃はタイミング攻撃と呼ばれ、異なる非機能要件がお互いに打ち消しあう良い例となります。高速性と安全性を同時に実現できないコードもあります。

そのため、パスワードが完璧に処理され、表示されるメッセージが一般的なもので、パスワードやユーザー名が間違っているかどうかを知らせるものではないにもかかわらず、システムには脆弱性があります。解決策は簡単です。常にパスワードをハッシュ化するか、ハッシュ化にかかる時間分だけ返信を遅らせるのです。

得られた情報は、攻撃者がシステム上のユーザーのリストを得るために使用することができます。この情報は、ブルートフォース攻撃やデフォルトのユーザー名/パスワード攻撃など、ウェブアプリケーションへの攻撃に使用することができます。

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

コンピュータシステム上でファイルを削除するのは厄介だ。誰もが、たとえあなたのお母さんであっても、これまでにファイルを削除しすぎて、まだゴミ箱に残っているのを見つけて、それを回復できたことを喜んだことがあるでしょう。

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

通常、ファイルを削除しても、ファイルを表すビットには何も起こりませんが、簿記データが変更されることで、システムはストレージのこの部分が無意味になったことを認識し、再利用できるようになります。この場所に別のファイルが保存され、この場所のビットが上書きされるまでは、保存されていたデータを復元できることが多いのです。これは、ファイルを削除する際の速度を向上させるだけでなく、削除を元に戻すための便利な機能であることが多い。

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

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

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

データの残存とは、何らかの方法で消去されたデータの物理的な表現が残っていること。記憶媒体が消去された後、データを再構築できるような物理的特性が残っている場合があります。

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

BSIMM 8がリリースされました。素晴らしいですね。大企業が安全なソフトウェアを作るためにどのようなセキュリティ対策を行っているかを調査した唯一無二の大規模調査です。

この調査は、ゲイリー・マクローの監修のもと、アプリケーション・セキュリティの専門家によって実施されており、収集されたデータが一貫性のある正確なものであること、そして30万人の開発者が日々行っていることへの洞察を与えてくれることを確認しています。最新のプレゼンテーションでは、BSIMMの数字を参照し、平均して100人の開発者に対して2人のアプリケーション・セキュリティの専門家がいると述べました。

しかし、BSIMM4以降はそうなっていません。BSIMM8によると、この数字はさらに少なくなり、開発者100人あたり1.6人となっています。アプリケーション・セキュリティの専門家を増員しても、人材が不足しているため、単純にはうまくいきません。これまで以上に、開発者に、安全なコードを書くためのツールとトレーニングを提供する必要があります。それは、実践的で、すぐに利用でき、組織にとってスケーラブルなものです。

また、このレポートによると、トレーニング業務の中で最も一般的な活動は、全従業員に対する意識向上のためのトレーニングの提供であり、その割合は67%でした。私は、Secure Code Warrior （SCW）で行っているトレーニングに関する活動をマッピングしてみたところ、当社のソリューションは、トレーニングに関する活動のレベル1（ほとんどの企業が行っている）からレベル3（ごく少数の企業が行っている）までの12の活動すべてに当てはまることがわかりました。

1つのソリューションで練習全体をカバーすることができます！12のトレーニングプラクティスのうち、Secure Code Warrior のソリューションで最も興味深いプラクティスは次のとおりです。

• レベル1：啓発活動の実施
• レベル1：オンデマンドの個別トレーニングの提供
• レベル2：トレーニングによるサテライトの強化（SCW測定基準
• レベル3：カリキュラムの進行に応じた報酬（SCWバッジ
• レベル3：ベンダーや外部委託先へのトレーニングの提供（SCWアセスメント
• レベル3：外部ソフトウェアセキュリティイベントの開催（SCWTournament モード
• レベル3：トレーニングによるサテライトの特定（SCWの測定基準

現在のソリューションがこれらのプラクティスに対応していると確信していますか？

なぜ、ある開発者のアプリケーション・セキュリティ・トレーニング・プログラムは、他のプログラムよりも良い結果をもたらすのでしょうか？

SANSのトレーナーとしての10年以上の経験と、Secure Code Warrior （SCW）を設立して構築したこの3年間で、トレーニングプログラムが最高の結果を生むために時間とリソースを投資することの価値を実感しました。

販売開始から1年で、当社は1万人以上の開発者をセキュアコードトレーニングに参加させましたが、最も効果的な展開をした開発者の間で、いくつかの傾向があることに気づきました。彼らの結果は心温まるものでした。素晴らしいエンゲージメント、セキュリティ意識の向上、そして高額になる前にセキュリティの弱点を早期に発見することによるプログラムの強いROIです。

認めたくはありませんが、「労力をかけない」アプローチで、トレーニングへのリンクを記載したメールを送ってプログラムを展開しようとした人も少なからずいたようです。驚くことではありませんが、これではうまくいかず、私たちはこれらの展開を修正しなければなりませんでした。

ここでは、私たちを含めた開発者向けセキュリティトレーニングプログラムの参加レベル、インパクト、成功率を大幅に向上させる5つの重要な教訓を紹介します。

1.インパクトのあるプログラムにするには、キックオフに楽しさを入れる

キックオフの日に特別なイベントを用意したり、プログラムに映画やゲームなどのテーマを与えることで、最初からの盛り上がりや参加率に大きな違いが生まれます。ある大企業のお客様は、人気テレビシリーズをテーマにしたファンタジーなプログラムを作り、Tシャツやバッジ、ステッカーなどを用意して、開発者にとって見逃せない体験となるようなトレーニングプログラムにしました。また、スター・ウォーズをテーマにしたイベントを5月4日に開催しました。ちょっとした遊び心があれば、社員のモチベーションも上がりますし、短時間での重要な開発者向けセキュア・コード・スキル・トレーニングも、やらなければならない仕事の一つではなく、仕事の合間に行うような感覚になります。マイルストーン1は達成されました。私たちは社員の注目を集め、彼らはこのプログラムについて知っています。

2.適切な開発者のセキュリティトレーニングチャンピオンを見つける（ヒント：セキュリティスキルよりもコミュニケーションスキルが必要です

各スクラムチームに適切なセキュリティチャンピオンを見つけられるかどうかは、特に大規模な組織において、プログラムを継続的に成功させるために重要である。私の経験では、高度に熟練したセキュリティや開発者の専門家が、高度に発達した人間力やコミュニケーション・スキルを持っているとは限らない。プログラムに継続的な効果をもたらす最高のセキュリティ・チャンピオンは、セキュリティに情熱を持ち、強力な人間力、影響力、コミュニケーション・スキルを持つ人である。性格やコミュニケーション能力を考慮して、賢く選んでください。

3.スキルを評価するクールな報酬を用意する

一般的に、開発者を含むすべてのコンピュータオタクは、自分の知性やスキルを認められたいと思っています。自分のスキルを認めてもらうために、特別なステータスシールやマニアックなガジェット、特別なバッジ、カスタムプリントのTシャツなどをプレゼントすれば、彼らはそれを誇りを持って身につけたり飾ったりするでしょう。トレーニングプログラムの中で何か重要なことを成し遂げた人がいたら、その人を評価し、露出させる方法を考えることが大切です。あるお客様は、Secure Code Warrior チャンピオンの写真を定期的に撮影し、その写真とCISOからのメッセージを社員向けのニュースレターに掲載するという素晴らしい取り組みをされています。

4.開発者をセキュリティの専門家にしようとしないこと

開発者が安全なコードを書けるようにすることで、開発者をセキュリティ・プログラムの「第一防衛ライン」にしたいと考えていますが、だからといって、開発者をビジネスにおける最も詳細なセキュリティの専門家にする必要はありませんし、新しいセキュリティの脆弱性やデータ侵害の事例を継続的に紹介する必要もありません。セキュリティは重要ですが、彼らの主な目的は、優れた製品やサービスを構築し、ビジネスのペースに従うことです。あまりにも多くのセキュリティを盛り込みすぎると、彼らの関心を引いてしまう危険性があります。主な教訓としては、基本的なセキュリティ衛生を理解し、安全なコーディングを行うためのツールを提供する必要がありますが、会社のセキュリティ専門家になる必要はありません。

5.トレーニングを測定するのではなく、インパクトを測定する

開発者が何時間のトレーニングを受けたか、何本のビデオを見たかではなく、各チームでプログラムを開始する前に、コード解析、バグバウンティ、あるいは古典的な脆弱性テストを通じて、開発ライフサイクルの中で発見された脆弱性の数を測定してください。 トレーニングプログラムが機能していれば、発見される脆弱性の数は減少するでしょう。次に測定すべきことは、脆弱性を修正するのにかかる時間です。開発者が脆弱性を修正するのに1ヶ月かかる場合、彼らがその方法を理解していないことを明確に示していますが、1時間で修正できる場合は、彼らがスキルを習得していることを示しています。これらの2つの指標は、賢い企業が開発者向けのセキュアコーディングトレーニングの効果を測るために採用しているものです。

開発者向けセキュリティトレーニングを効果的に展開するための5つの重要な教訓。

1. インパクトのあるプログラムにするためには、キックオフに楽しさを盛り込む必要があります。
2. 開発者に適したセキュリティ・トレーニング・チャンピオンを見つける（ヒント：セキュリティ・スキルよりもコミュニケーション・スキルが必要！）。
3. スキルを評価するクールなリワードを用意
4. 開発者をセキュリティの専門家にしようとするな
5. トレーニングを測るのではなく、インパクトを測る

バージニア工科大学の研究者は、最も人気のある開発者フォーラム（Stack Overflow）の何百もの投稿を分析し、論文を発表しました。この論文では、セキュリティに関する質問の種類、コミュニティで最も多く寄せられる回答、コードソフトウェアエンジニアに与える影響などを調べています。

しかし、開発者の視点からは、この問題をもっと認識する必要があります。

• コーディングフレームワーク（JAVA Springなど）が提供するセキュリティ機能は、複雑すぎて文書化されていません。
• かなりの数の開発者が、コーディングオプションのセキュリティへの影響を理解していないようで、サイバーセキュリティのトレーニングが不足していることがわかります。
• これらのフォーラムでの提案や「修正」の多くは安全ではありませんが、ポジティブな投票を得ていたため、評価が高くなっています。

報告書では、以下のような解決策を提案しています。

• 従業員の再教育
• 半自動化されたセキュリティバグの検出と修正

今日のビジネスのスピードを維持するためには、開発者にとってセキュリティを簡単にし、最初からビルトインする必要があります。

"本研究の意義は、これまで報告されていなかった相当数の憂慮すべきセキュアコーディングの問題について、実証的な証拠を提供したことにあります" と論文は述べています。"これらの問題は、企業のセキュリティ・アプリケーションの必要性が急速に高まっていること、ソフトウェア開発者のセキュリティ・トレーニングの不足、セキュリティ・ライブラリの設計不良など、さまざまな理由に起因しています。"

https://www.theregister.com/2017/09/29/java_security_plagued_stack_overflow/

今月初め、ベルギーのバグバウンティハンターである Inti De Ceukelaireが、数百の企業に影響を与える独創的なハッキングを公開しました。このトリックは、誤ったビジネスロジックを利用して ビジネスロジックイントラネット、ソーシャルメディアのアカウント、YammerやSlackのチームへのアクセスを可能にします。詳細については、Inti社のブログ記事をご覧ください。 Inti社のブログ記事.そこで、Intiにいくつか質問をしてみましたので、その答えをご紹介します。

インティさん、こんにちは！ 読者の皆さんに簡単な自己紹介をお願いします。

私は、IntigritiとHackeroneのバグバウンティハンターのIntiです。ベルギーのアールストに住んでいて、日々物を壊して過ごしています。

先週、私はあなたが「チケット・トリック」と呼んでいるものについてのブログ記事を読み、この攻略法を見つけたあなたの創造性に感銘を受けました。どのようにしてこのトリックを試すアイデアを思いついたのですか？

私はバグバウンティプログラムに参加しています。バグバウンティプログラムとは、特定のウェブサイトが、責任あるセキュリティ研究者がユニークな脆弱性を発見した場合に金銭を提供するというものです。競争が激しいので、他の人がまだ発見していないものを探し続ける必要があります。Slackには機密情報が含まれていることが多く、会社の有効な電子メールだけで済むこともあるので、攻撃の手段としては面白いと思いました。そこで私は、ビールを手に取り、ソファに横になって、ありとあらゆる攻撃ベクトルについて考え始めました。突然、斬新なアイデアが浮かんできて、それがうまくいったのです。私は頭に浮かんだことは何でも試してみます。たとえ数回しか成功しなくても、それが利益につながるのです。)

普段、コードのセキュリティを確保するために逆の立場で仕事をしている者としては、ペンテストのセッションはどのようなものかとよく考えます。 どこで作業しているのでしょうか？空いた時間にソファに座ってするものですか？それとも、オフィスで座っているのでしょうか？

昼間は、Studio Brusselというラジオ局でデジタル・クリエイティブ・コーダーとして働いています。この仕事には、プログラミングとソーシャルメディアが含まれますが、セキュリティはありません。私は自分の趣味とプロの仕事を混同しないようにしています。そんなことをしたら、創造性が失われてしまうからです。ハックする頻度はそれほど多くなく、週に数時間が限度です。テーブルでもソファでもベッドでも、その時に快適なものであれば何でもいいです。

どうやって始めるの？チートシートはありますか？入力の検証や出力のエスケーピングが十分に行われているかどうかをテストするための入力はありますか？

私は本当に混沌としているので、チェックリストはなく、直感で判断しています。ほとんどの場合、偵察と呼ばれる作業から始めます。興味深いターゲット情報、サブドメイン、IPアドレスなど、見つけられるものはすべてリストアップします。ハッキングを開始する前に、全体像を把握し、ビジネスロジックを理解するようにしています。教科書に載っているような標準的な脆弱性だけを探していては、より巧妙で複雑な欠陥の多くを見逃してしまいます。入力に関しては、1つのペイロードで可能な限り多くの脆弱性をカバーするようにしています。何か面白いものを見つけたら、しばらくそれで遊んで、システムがそれにどう反応するかを見るために、たくさんの無意味なものを投げ込んでみます。最高のバグは、ウェブアプリケーションのより離れた部分で見つかることが多いので、できるだけ深く掘り下げるようにしています。

良いペンタリストの条件は何だと思いますか？何かコツのようなものがあれば、教えてください。

私はペンテスターではないので、一般的なペンテスターのことは言えませんが、モチベーションと粘り強さが最も重要な資産だと思います。Googleには世界最高のエンジニアがいるのに、毎年何百万ものバグ報奨金を出しているので、ほとんどの人はセキュリティの脆弱性を探そうとも思わないでしょう。私は2年以上ターゲットに取り組んでいますが、今は本当に面白いバグにたどり着き始めています。それには時間がかかります。通常のペンテストの問題点は、重大な脆弱性を発見してもしなくても、テスターには決まった報酬が支払われることです。フェイスブックにはまだたくさんのバグが残っていると思いますが、深く掘り下げようとする人が必要です。

チケット・トリックの規模がわかったとき、最初に思ったことは何ですか？

複雑な心境でした。驚きとともに、すぐにバグバウンティのことが頭に浮かびましたが、その一方で、こんなことが可能なのかとショックを受けました。このように何かを見つけると、悪意のある人が興味を持つような貴重な情報を突然手に入れることになります。できるだけ多くの企業に知らせる必要がありますが、その一方で、情報が漏洩したり悪用されたりしないようにしなければなりません。

なぜ、より多くの賞金を集める前に情報を公開しようと思ったのですか？

正しいことをすることは、バウンティを集めることよりも重要です。私はそれなりのものを得たと思っていますし、今はコミュニティに恩返しをしたいと思っています。それに、私は何ヶ月も前からこの問題を企業に知らせていたので、より多くの人がこの問題を知っていました。漏洩したり、悪意のある人に悪用されたりするのは嫌だったからね。

影響を受けた企業の対応についてどう感じましたか？

ほとんどの回答は満足のいくものでした。中にはあまり気にしていない企業もありましたが、結局は彼らの損失なのです。セキュリティ・リサーチャーとして拒絶されることはゲームの一部なのです。少なくとも、私は訴訟を起こされませんでした。10年前であれば、おそらくそうなっていたでしょうね。

最後の質問ですが、redditではバグバウンティで8,000ドルを請求したと書かれていましたが、このお金を使って何か素敵な計画はありますか？

合計すると、このバグで2万円以上を手に入れたことになる。そのうちの半分以上は税金に充てています。残りは旅行や食事など、普通のことに使っています。)

お時間をいただきありがとうございました。

このバグはまだ存在しています。すぐに修正できるものではありません。この数ヶ月間、私はバグバウンティプログラムの一環として、何十社もの企業や影響を受けたベンダーに連絡を取り、セットアップの修正を依頼しました。

https://medium.freecodecamp.org/how-i-hacked-hundreds-of-companies-through-their-helpdesk-b7680ddc2d4c

公的機関、商業施設を問わず、あらゆる組織を見てみると、2つのことが保証されています。1つ目は、製品やサービスのデジタル化が進んでいること、つまり、ソフトウェア開発者がコードを作成していることです。第二に、これらのデジタルビジネスは、よりダイナミックでグローバルな世界で活動している従来の競合他社や非従来の競合他社からのプレッシャーにさらされています。

このような環境の中で、CIOは新たなイノベーターとなり、権力と影響力を持つ立場となっています。しかし、市場投入までの時間を短縮し、品質を向上させ、柔軟性を高めなければならないという強いプレッシャーから、複雑な分散型の開発チームが形成され、機能や特徴を迅速に開発することに集中し、その結果、脆弱性を生み出す可能性があることを認識していません。

今まで以上に、新しい働き方が求められています。最近のEquifax社の情報漏えい事件では、安全ではないコーディングが原因で核被害が発生したことを見ればわかるでしょう。CIOやCISOは、開発チームがリスクの第一線なのか、それとも会社のセキュリティ・チャンピオンであり、会社の真の「第一防衛線」なのかをよく考えるべきです。

私は、CIOやCISOが、自社の開発チームが、より速く、より良く、より安全なコードでイノベーションを起こすことができるセキュアコーディングのチャンピオンになれているかどうかを検討するために、このセキュアコーディング・チェックリストを作成しました。

1.従来のネットワークセキュリティでは不十分であることをCレベルの役員は認識していますか？

従来のセキュリティ対策でネットワーク層を保護することはもはや十分ではなく、セミプロのハッカーに対しても成功することはほとんどありませんでした。ベライゾンの「2017 Data Breach Investigations Report」では、今日のデータ漏洩の35％がWebアプリケーションの脆弱性によって引き起こされていると報告されています。Webアプリケーションのセキュリティは、ネットワークセキュリティと同様に重要です。

2.最初からセキュリティを考えていますか？

現在のアプリケーション・セキュリティ・ツールは、ソフトウェア開発ライフサイクル（SDLC）の右から左への移行に重点を置いています。このアプローチは、セキュリティチームが記述されたコードの脆弱性を検出し、それを修正するために反応するという、検出と反応をサポートするものです。米国国立標準技術研究所（NIST）によると、コミットされたコードの脆弱性を検出して修正するには、IDEでコードを書くときに脆弱性を防ぐのに比べて30倍のコストがかかります。言うまでもなく、問題の解決には時間的な遅れが生じます。セキュアコードチャンピオンは、SDLCの最左端からスタートし、開発者にセキュアコーディングのトレーニングを継続的に行うことに注力します。そうすることで、開発者は組織の最初の防衛線となり、そもそも脆弱性を防ぐことができます。

3.知識だけを与えるのではなく、実際にセキュリティスキルを身につけているか？

ほとんどのトレーニングソリューション（オンラインおよび教室でのトレーニング）は、スキルの習得よりも知識の習得に重点を置いています。 開発者が安全なコードを書くためには、積極的に学習し、安全なコーディングスキルを身につけることができる実践的な学習に定期的にアクセスする必要があります。開発者は、最近確認された脆弱性について、実際のコードや自分の言語／フレームワークを使って学ぶ必要があります。この学習経験は、コード内の既知の脆弱性を見つけ、特定し、修正する方法を理解するのに役立つはずです。

4.自分のセキュアコーディングスキルをリアルタイムの指標で測定していますか？

開発者のセキュアコーディングスキルが向上していることを、開発者とその組織に証明する証拠を作ることが重要です。測定できないものは改善できません。評価は、開発チームの進捗状況をリアルタイムに把握し、セキュアコーディングの強みと弱みをベンチマークするのに役立つものでなければなりません。

5.外部委託先が安全なコーディング技術を適用していることを確認していますか？

多くの企業は、開発作業を大規模なオンショアまたはオフショアの開発会社に委託することを決定します。最良のケースでは、組織がセキュリティに関して求める唯一の保証は、契約書の中で成果物が「安全」であることを要求する文言だけである。これらの開発会社のスキルを前もって検証する人はほとんどおらず、最終的には優れた安全なコーディング・プラクティスに従っていないソフトウェアが提供されます。最悪のシナリオは、彼らがそれらを知らずにアプリケーションを稼動させてしまうことです。 最も一般的なシナリオは、専門のスペシャリストが（そのための費用を）負担して、稼動開始の遅れや、これらのセキュリティ上の弱点を修正するために誰が支払うべきかという契約上の議論に直面することです。前もって賢くなって、次のアプリケーションを作る開発者のアプリケーション・セキュリティ・スキルを評価しましょう。

6.開発者は、最も一般的なセキュリティ上の弱点を認識していますか？

Web アプリケーションの脆弱性の 85.5%は、OWASP のトップ 10 と呼ばれる 10 個の既知の脆弱性に起因しています。アプリケーション・セキュリティのトレーニングでは、最低でもこれらをカバーし、さらに多くの種類の脆弱性をカバーする必要があります。開発者がこなす課題は、新しいコーディングフレームワークや新しい脆弱性の種類に応じて、継続的に修正・更新される必要があります。

7.社内にセキュリティ・チャンピオンはいるか？

開発者が多い組織では、開発チームの中でセキュリティを擁護する人に投資すべきである。彼らの目的は、セキュリティに関する質問をする人のサポート窓口となるだけでなく、チーム内でのセキュアコーディングやセキュアアーキテクチャの実践を推奨することです。

8.安全なコーディングを容易にするために、開発者向けのツールに投資していますか？

アプリケーションの変更が多い環境や、アジャイル開発が行われている環境では、セキュリティの一部を自動化することが、そのペースとボリュームに対応するために不可欠です。開発ライフサイクルの各段階で、アドバイザー、品質ゲート、または検出ツールとしての役割を果たすツールがあります。特定の種類のセキュリティ・バグに焦点を当て、開発者がコードを書いているときにスペル・チェッカーのように機能するIDEプラグインがあるとよいでしょう。また、ビルドプロセスと統合して、コードがコードリポジトリに提出される際に特定のタイプの弱点を検出するツールもあります。また、コードの自動テストを実行し、ソフトウェアの運用開始後にハッキング技術をシミュレートするツールもあります。いずれもメリットと課題があり、セキュリティ上の問題がないことを100％保証するものではありません。基本的には、弱点を早期に発見できれば、ビジネスへの影響を最小限に抑えながら、より早く、より安く弱点を修正することができます。

CIOがエンタープライズ・アジャイル能力を積極的に構築する中で、セキュア・コーディング・スキルはイノベーションの武器となり、それを持たないことは破壊の道具となります。 この重要な能力をスキップする前に、よく考えてください。

このチェックリストに対して、あなたの組織はどうだったのでしょうか？

CIOがエンタープライズ・アジャイル能力を積極的に構築する中で、セキュア・コーディング・スキルはイノベーションの武器となり、それを持たないことは破壊の道具となります。この重要な能力をスキップする前に、よく考えてください。