学生として、学校環境での深刻なセキュリティ問題を安全かつ責任を持って開示するにはどうすればよいですか？
私は地元の学校の生徒です。
約8か月前、私はつまずきanyユーザーが地区全体でany学生のIDを発見できるセキュリティホールに遭遇し、私はIDは学生に関連付けられた唯一の一意の識別子であるため、IT部門は学生IDをできるだけ秘密に保つ傾向があることに注意してください。
私が最初に問題を見つけたとき、私はコンピューターサイエンスの先生から、寝かせて誰にも報告しないように勧められました。ただし、8か月が経過したため、IT部門はこの問題を解決するために何もしていません。
私は最終的に責任あるセキュリティ問題を経営陣に開示する勇気を築きました。私が報告を恐れた理由は、1つの間違ったステップが私を熱湯に落ちさせ、「ハッキング」のために停止する可能性があるので、私は非常に注意深く踏まなければならないということです。現時点では、自分以外にこのエクスプロイトを発見した人は誰もいません。
繰り返しますが、私はセキュリティホールを積極的に探していませんでした。むしろ、私は単につまずきました。
セキュリティ上の問題を責任を持って開示する一方で、罰せられるリスクを最小限に抑えるために講じる最善の措置は何ですか？
私は長年大学で働いた経験がありますICTチーム。これは私の経験に基づいて私が推薦するものです。
私は管理職には行きません、彼らは気にしないでしょう、または技術者ではないマネージャーが過剰反応して個人的な使命として問題を引き受けます。さらに、「ハッキング」で非難されるのではないかと心配している場合、それを行う可能性が最も高いのは非技術的な管理者です。
セキュリティ上の欠陥を文書化し、ICTサービスデスクに提出することをお勧めします。
学生としてサービスデスクにアクセスできない場合は、直接電子メールで送信するか、オフィスのドアを開けて状況を説明し、続行方法をアドバイスします。 （ドアを閉めるのがおそらく最良の選択肢です）技術者が問題を確認するためのチケットを発行するだけで、そこからエスカレーション手順が実行されます。
この問題を彼らと一緒に持ち出すことについて心配しないでください。それが何もないことが判明したとしても、ほとんどのチームはこれらの種類の欠陥の積極的な報告を喜んでします。経験から、それがサポートスタッフであれアカデミックスタッフであれ、アカデミアでは、ICT）で障害が発生するのは、個人的に影響がある場合に限ります。
私は過去に障害を発見しましたが、問題の障害が数か月前からあったことをスタッフのメンバーだけが教えてくれました。私の返答は常に同じでした、「なぜICTそれを修正するためにチケットを上げなかったのですか？」
学生として問題を提起しないでください。あなたの懸念は妥当です：学校は通常、生徒をその行動がせいぜい無意味で最悪の場合は悪意のある子供であると認識します。最良の場合、あなたは無視され、最悪の場合、彼らはメッセンジャーを撃ち、ハッキングの規律をつけます。彼らは過去に未解決の学生IDの乱用についてあなたを非難することさえあるかもしれません。
両親を通して問題を提起することをお勧めします。大人がアプローチする場合、学校の管理は通常、はるかに協力的です。 「問題を修正するか、私が報道機関に話しかける」キッカーは、たいていうまく機能します。
attorneyを見つけて、公開してください。彼らはあなたの身元を秘密にしておく必要があります。たぶんあなたはこれを無料でやる気のある人を見つけることができます。またはあなたの両親はそれを知っているかもしれません。
TheJulyPlot に同意します。セキュリティの問題は、Webサイトのセキュリティを担当するIRT/CSIRT/SOC/CERTチームに提出する必要があります。 大学 は確かにそうですが、小さな学校は専用のポジションを持っていないかもしれません。
目標は、これらの人々が（a）報告している内容を理解するための技術的能力と（b）あなたが実際に彼らを助けていることに気づいていることです。必要に応じて、より正確な受信者にそれをルーティングできること（たとえば、実際の障害は、別の開発チームが修正する必要がある場合があります）。
機関のセキュリティ問題を処理しているチームまたはそれらに連絡する方法がわからない場合は、1つ上のレベルに上げることができます。国立CERTに連絡するか、大学の場合は、所属する研究ネットワークのCERTに連絡します。
たとえば、あなた（およびエンティティ）の拠点に応じて、米国では US-CERT 、英国では JANET CSIRTに通知できます 、スペインでは INCIBE-CERT 、カザフスタンでは KazAcad CSIRT ...
チームの完全なガイドはありませんが、通常、 [〜＃〜] first [〜＃〜] または-for Europeanで、ケースに最も関連するCSIRTを検索できますCERTs- Trusted Introducer 。
そこにはそれぞれ独自の選挙区があることに注意してください。国のCERTは、必要に応じて大学にリダイレクトするレポートを処理できますが、まったく関係のない民間企業のCSIRTはそれを破棄する可能性があります。
（ほとんど？）すべてのケースで、インシデントのレポートを電子メールで送信することができます（リストされていない場合は、RFC 2350のセクションを探してください）。つまり、基本的な匿名性のレベルでは、新しいフリーメールアカウントを作成し、それを使用してインシデントレポートを送信できます。実際、新しい電子メールの作成をスキップして、通常の電子メールアドレスから送信することもできます（匿名のままにしないことをレポートで言及することもできます）。あなたが犯罪を犯しなかったとしたら、誰かがあなたが本当に誰であるかを気にかけることはまずありません。 「送信して忘れる」のではなく、そのメールを確認することをお勧めします（必要に応じて更新を依頼してください）。あなたは単純に感謝され、彼らがこれからこれを処理することを知らせるかもしれませんが、彼らはあなたにもっと多くの情報を要求するかもしれませんし、別のチームに送るようにあなたに頼むかもしれません。
また、逆火の可能性を最小限に抑えるために、発見後できるだけ早く報告することをお勧めします。見当違いの人々は、あなたが発見したものは何でも、実際の脆弱性がどんなにばかげていても、悪用して悪質なハッカーであると思い込むかもしれません。しかし、それを修正するために迅速に行動することによって（そして実際にはそれを乱用していません！）おそらくチェックできるいくつかのログがあります。彼らがあなたが脆弱性をテストしたことを彼らが見つけた場合（たとえ彼らが自分で見つけるのに数か月かかるとしても）、彼らがレポートを受け取る前に1時間前にそれを行ったことは、彼らが6か月前にそれを発見したことに気づくのとはまったく異なる画像をペイントします。何らかの理由で連絡が届かなかったとしても（たとえば、乱用メールボックスがいっぱいだったとしましょう！）、脆弱性を開示している電子メールプロバイダー（送信済みメール）のレコード自体は、必要な場合に役立ちます。 。