(1)大規模なクラスに拡張可能であり、(2)安全な設計を教えるクラスプロジェクトを探しています。これは、コンピュータセキュリティに関する学部課程向けです。うまくいけば、それは学生にとって教育的で楽しいものになるでしょう。
最初の要件は、クラスプロジェクトのグレーディングがスケーラブルである必要があることです。このコースには300〜400人の学部生がいます。コースプロジェクトを採点するためのリソースはいくつかありますが、多くはありません。したがって、どのコースプロジェクトも、大規模に採点できるものでなければなりません。
採点に利用できるリソースは、コースを受講する学生の数に比例します。大まかに言えば、コースプロジェクトの採点の予算は、ティーチングアシスタントから10〜15分(コースの学部生1人あたり)に加えて、経験の浅い採点者(コースの学部生ごと)。ティーチングアシスタントはセキュリティについてかなり知識があります(通常、コンピュータセキュリティの研究を積極的に行っている博士課程の学生)。採点者はそれほどではありません(通常、以前にコンピュータセキュリティのコースを受講したが、他の経験や知識がない学部生)。
もちろん、プロジェクトがグループごとに[〜#〜] n [〜#〜]の学生がいるグループプロジェクトの場合、採点に利用できるリソース各プロジェクトは[〜#〜] n [〜#〜]の係数で増加します。ただし、実際的な理由から、[〜#〜] n [〜#〜]はおそらく3または4より大きくすることはできません。
スケーラビリティ要件は、そうでなければ非常にクールな多くの潜在的なプロジェクトを除外します。たとえば、プロジェクトを採点するために、経験豊富なティーチングアシスタントが、コースを受講する学部生ごとに1,000行のコードを読む必要がある場合、それは単に実現可能ではありません。 5〜10ページの設計ドキュメントを読み、システムアーキテクチャの脅威分析を行う必要がある場合は、それも難しいかもしれません。
2番目の要件は、クラスプロジェクトが安全な設計を教えるである必要があることです。学生が何らかのシステムを攻撃しようとするコースプロジェクトを思い付くのは簡単です(たとえば、Webアプリケーションの脆弱性を見つけたり、バッファオーバーランを悪用したりするなど)。私はその種の素晴らしいプロジェクトをたくさん持っています。ただし、学生には、安全なシステムの設計の経験を積んでもらいたいと思います。たとえば、いくつかの要件から始めて、オプションを検討し、システムアーキテクチャまたは設計アプローチを選択して、それを構築する必要があります。
これらの2つの要件は緊張しています。良いデザインを評価するのは難しいです。提案された設計を分析し、それが良いか悪いかを判断するには時間がかかります。そのため、学生が安全な設計を実践できるコースプロジェクトを作成することはそれほど簡単ではなく、大規模に有意義に評価することができます。コンピュータセキュリティに関する他の多くの学部コースのコースプロジェクトを調べたところ、スケーラブルなプロジェクトや安全な設計を教えるプロジェクトがたくさん見つかりましたが、両方を同時に行うプロジェクトは見つかりませんでした。
これらの要件を満たすコースプロジェクトは何でしょうか?
(背景:優秀な学生グループができて幸運です。学生は洗練されていて、頭が良く、一生懸命働くことを恐れません。通常、大学3年生または4年生のコンピュータサイエンス専攻です。全員がそこにいます。彼らはそこにいたいので、コースは選択科目であり、必須のコースではありません。プロジェクトが重要な何かを設計および/または実装することを含むことは問題ありません。プロジェクトが業界または彼らの将来のキャリアに関連している場合は、より良い!)
@Davidが述べたように、eコマースWebサイトまたは「機密」データを処理するものはすべて良いスタートになります。
2番目の要件について話しましょう。 Webアプリケーションの安全な設計について話している場合は、明らかにそれらを OWASPトップテン に向けたいと思うでしょう。リストは完全に近いものではありませんが、良いスタートです。おそらく、生徒にそれを読んでもらい、リスト内の各項目をどのように軽減するかを説明する設計ドキュメントを考えてもらいます。
最初の要件は少し注意が必要です。コードレビューは結局のところ退屈なプロセスです。学生が以前にプログラミングの経験があり、コード自体の品質で学生を評価していない場合は、完全にブラックボックスのアプローチで評価することをお勧めします。生徒にお互いのコードを攻撃してもらいます。私は自分の answer を支持します。安全なコーディングについて学ぶ最良の方法は、誰かにそれを破らせることです。おそらく、グレーディングを3つのコンポーネントに分割することを考えることができます。最初のコンポーネントは、脅威モデルの学生の分析と提案された対策を詳述する初期設計文書になります。 2番目のコンポーネントは、ピアのコードに対する「侵入テスト」のレポートです。これは、ブラックボックス攻撃またはコード分析のいずれかである可能性があります。 3番目のコンポーネントは、学生がコードで見つかった欠陥を修正する方法を詳しく説明するレポートです。
このようにして、生徒は、発生したバグにパッチを適用するまで、安全な開発プロセス全体を体験できます。