[fagpakke beskrivelse]

Projekter i it sikkerhed

Arbejdet i kurset består af projekter gennemført i grupper af 1 til 4 personer. Gruppedannelsen kan finder sted via foraet Gruppedannelse på Webboard. AULA, AULA (Kurset hedder: "Projekter i it sikkerhed"), vil også blive brugt til udlevering af dokumenter. Aflevering sker til Jesper på jbn@cs.au.dk.

Projektet

I vælger selv hvad problemstillingen for projektet skal være og hvordan det udføres, under følgende begrænsninger: Projekterne foregår under vejledning, men I antages at være den aktive part. Projekter falder traditionelt i en af to hovedgrupper, eller er en kombination:

Læs, forstå og reflekter

Går ud på at tilegne sig et nyt kryptografisk emne der ligger i forlængelse af pensum fra de to foregående moduler, men som ikke er dækket af dette. Eksempler kunne være at læse en videnskabelig artikel eller en del af en lærebog.

En del af målet er at forstå emnet godt nok til at kunne give et overblik over de vigtigste dele i egne ord.

En anden del af målet er at kunne reflektere over emnet, fx. komme med kritiske kommentarer, bedømme hvor praktisk de tilegnede teknikker er og evt. komme med forslag til udvidelser eller anvendelser.

I en større gruppe kan projektet også bestå af en implementation af de tilegnede teknikker, hvis det er relevant.

Her er en liste med forslag til kryptografiske emner.[html] Hvis man har andre emner man synes kunne være interessante, men ikke lige har et forslag til en artikel at studere, kan man skrive til Jesper og få hjælp til at finde en.

Her er et eksempel på en rapport af denne type.[pdf,html]. Der er flere eksempler i AULA under [Documents/Eksempler på Rapporter].

Brug værktøjskassen på praksis

Går ud på at tage teknikker og teorier fra de to foregående moduler og bruge dem på en praktisk situation, fx fra ens egen arbejdssituation.

Man kan fx analysere om en given praksis er sikker og foreslå de nødvendige ændringer, eller man kan identificere et helt konkret sikkerhedsproblem og foreslå og implementere en løsning.

Her er et eksempel på en rapport af denne type.[pdf]. Der er flere eksempler i AULA under [Documents/Eksempler på Rapporter].

Rapporten

Rapporten afleveres som pdf fil i AULA i gruppens område. Software afleveres som kildekode i et seperat bibliotek i gruppens område. Hvis relevant må der også meget gerne laves on-line adgang til at køre evt. implementerede program.

I forbindelse med implementering er der ingen begrænsninger på programmeringssprog.

Projektforløbet bedømmes primært på rapporten. Karakteren gives efter 7-trins-skalaen. Der er ekstern censur.

Det er vigtigt at bemærke at projektet primært bedømmes på rapporten, sekundært på implementationen og ikke på andet. Rapporten er det første og sidste censor læser - ingen kan forventes at læse kildeteksten fra ende til anden, og ingen kan vide hvor meget arbejde I har lagt i projektet hvis det ikke er rapportéret i rapporten. Det er derfor vigtigt at rapporten er god.

En god rapport: En god rapport er ikke: Det er vigtigere at beskrive hvilke beslutninger der er taget og hvorfor end at beskrive slutproduktet. Det er også vigtigt at skrive om ting I forsøgte, som gik galt, hvis man kan reflektere over hvorfor det gik galt.

En mulig skabelon for en rapport:
  1. Introduktion til scenariet.
  2. Hvilke deltagere har vi, dvs. personer, maskiner, softwarekomponenter.
  3. Hvilke mål har vi for sikkerheden (sikkerhedspolitikken)?
  4. Hvilke trusler vil vi beskytte os mod?
  5. Den foreslåede løsning - overordnet
  6. Beskrivelse af implementationen:
    1. Hvordan er den bygget op, og hvorfor?
    2. Hvilke vanskeligheder mødte vi, hvordan løste vi dem?
    3. Hvordan har vi testet, hvad var resultaterne?
    4. Opfylder løsningen vores krav? Og hvorfor?
Det er svært at give en generel guideline for længden af en god rapport, men 10 + 10p sider, hvor p er antal personer i gruppen er en grov guideline.

Projektforløb

24. august - 2. september: Udarbejdelse af projektbeskrivelse
I bruger første uge på at samle jer i grupper og skrive en projektbeskrivelse der opridser emnet/problemstillingen for projektet og hvordan I vil arbejde med emnet/problemstillingen. Projektbeskrivelsen skal godkendes af Jesper. Gruppedannelsen finder sted via AULA. I forbindelse med udarbejdelse af projektbeskrivelsen kan der bookes fysiske møder mellem grupperne og Jesper, og disse møder erstatter første seminar.
2. september: Godkendt projektbeskrivelse.
Dette er sidste frist for at have en godkendt projektbeskrivelse. Den uploades som pdf dokument via AULA.
12. september: Fremlæggelse af projektbeskrivelser.
Hver gruppe fremlægger ved seminaret deres projektbeskrivelse og beskriver det arbejde der allerede er lavet. Resten af seminaret bruges til at arbejde i grupperne og få vejledning.
3. oktober: Fremlæggelse af projekter.
Hver gruppe fremlægger ved seminaret det arbejde der er lavet i forbindelse med projektet. Målet er at broderparten af arbejdet i projektet er gennemført på dette tidspunkt, så resten af perioden kan fokuseres på at udarbejde en god rapport. Resten af seminaret bruges til at arbejde i grupperne og få vejledning.
18. oktober: Aflevering.
Dette er sidste frist for at aflevere den skriflige rapport. Rapporten uploades som pdf dokument via AULA.