Wydział Informatyki - Informatyka (S1)
specjalność: systemy komputerowe i oprogramowanie
Sylabus przedmiotu Problemy bezpieczeństwa w inżynierii oprogramowania:
Informacje podstawowe
| Kierunek studiów | Informatyka | ||
|---|---|---|---|
| Forma studiów | studia stacjonarne | Poziom | pierwszego stopnia |
| Tytuł zawodowy absolwenta | inżynier | ||
| Obszary studiów | nauki techniczne, studia inżynierskie | ||
| Profil | ogólnoakademicki | ||
| Moduł | — | ||
| Przedmiot | Problemy bezpieczeństwa w inżynierii oprogramowania | ||
| Specjalność | systemy komputerowe i oprogramowanie | ||
| Jednostka prowadząca | Katedra Inżynierii Oprogramowania | ||
| Nauczyciel odpowiedzialny | Witold Maćków <Witold.Mackow@zut.edu.pl> | ||
| Inni nauczyciele | Tomasz Hyla <Tomasz.Hyla@zut.edu.pl> | ||
| ECTS (planowane) | 2,0 | ECTS (formy) | 2,0 |
| Forma zaliczenia | zaliczenie | Język | polski |
| Blok obieralny | 10 | Grupa obieralna | 8 |
Formy dydaktyczne
Wymagania wstępne
| KOD | Wymaganie wstępne |
|---|---|
| W-1 | ukończony kurs Podstawy ochrony informacji |
| W-2 | ukończony kurs Podstawy programowania |
| W-3 | ukończony kurs Inżynieria oprogramowania |
Cele przedmiotu
| KOD | Cel modułu/przedmiotu |
|---|---|
| C-1 | zapoznanie studentów z wybranymi zagrożeniami bezpieczeństwa oprogramowania |
| C-2 | zapoznanie studentów z zasadami projektowania bezpiecznego oprogramowania |
| C-3 | ukształtowanie umiejętności z zakresu implementowania bezpiecznego oprogramowania |
| C-4 | ukształtowanie umiejętności z zakresu analizy i testowania bezpiecznego oprogramowania |
Treści programowe z podziałem na formy zajęć
| KOD | Treść programowa | Godziny |
|---|---|---|
| laboratoria | ||
| T-L-1 | Analiza podatności oprogramowania zaimplementowanego w języku C na wybrane ataki. | 2 |
| T-L-2 | Analiza podatności oprogramowania zaimplementowanego w języku Java na wybrane ataki. | 2 |
| T-L-3 | Analiza podatności oprogramowania webowego na wybrane ataki. Wykorzystanie cech oprogramowania nie wynikających z użytego języka. | 2 |
| T-L-4 | Wykorzystanie rozszerzeń języka modelowania UML do projektowania bezpiecznych aplikacji (SecureUML). | 3 |
| T-L-5 | Implementacja i testowanie bezpiecznego kodu. Studium przypadku dla języka C. | 3 |
| T-L-6 | Implementacja i testowanie bezpiecznego kodu. Studium przypadku dla języka C. | 3 |
| 15 | ||
| wykłady | ||
| T-W-1 | Problem bezpieczeństwa oprogramowania. Iinżynieria oprogramowania a bezpieczeństwo systemów informatycznych. | 1 |
| T-W-2 | Przegląd znanych podatność oprogramowania. Oprogramowanie webowe. Studium przypadków dla języków C i Java. | 3 |
| T-W-3 | Opracowywanie wymagań projektowych dla bezpiecznego oprogramowania. Inicjatywy i zalecenia wspierające tworzenie bezpiecznego oprogramowania (np. OWASP.org i CERT.org). | 1 |
| T-W-4 | Architektury i projektowanie bezpiecznych aplikacji. Eliminacja znanych podatności i błędów na etapie projektowania. Narzędzia do projektowania bezpiecznych aplikacji (np. SecureUML). | 3 |
| T-W-5 | Implementowanie bezpiecznego oprogramowania. Normy, zalecenia i dobre praktyki. Studium przypadków dla języków C i Java. | 4 |
| T-W-6 | Testowanie bezpieczeństwa oprogramowania. Analiza statyczna. Studium przypadków dla języków C i Java. | 3 |
| 15 | ||
Obciążenie pracą studenta - formy aktywności
| KOD | Forma aktywności | Godziny |
|---|---|---|
| laboratoria | ||
| A-L-1 | Udział w zajęciach laboratoryjnych | 15 |
| A-L-2 | Przygotowanie do zajęć laboratoryjnych | 15 |
| 30 | ||
| wykłady | ||
| A-W-1 | Udział w wykładzie | 15 |
| A-W-2 | Przygotowanie do zaliczenia formy zajęć | 13 |
| A-W-3 | Udział w zaliczeniu formy zajęć | 2 |
| 30 | ||
Metody nauczania / narzędzia dydaktyczne
| KOD | Metoda nauczania / narzędzie dydaktyczne |
|---|---|
| M-1 | wykład informacyjny |
| M-2 | ćwiczenia laboratoryjne |
Sposoby oceny
| KOD | Sposób oceny |
|---|---|
| S-1 | Ocena formująca: wejściówka (ocena przygotowania do zajęć) |
| S-2 | Ocena formująca: sprawozdanie z wykonywanego zadania (ocena pracy wykonywanej na zajęciach) |
| S-3 | Ocena podsumowująca: zaliczenie ustne |
Zamierzone efekty kształcenia - wiedza
| Zamierzone efekty kształcenia | Odniesienie do efektów kształcenia dla kierunku studiów | Odniesienie do efektów zdefiniowanych dla obszaru kształcenia | Odniesienie do efektów kształcenia prowadzących do uzyskania tytułu zawodowego inżyniera | Cel przedmiotu | Treści programowe | Metody nauczania | Sposób oceny |
|---|---|---|---|---|---|---|---|
| I_1A_O8/10_W01 potrafi wymienić i scharakteryzować typowe podatności oprogramowania mające wpływ na jego bezpieczeństwo | I_1A_W06, I_1A_W22 | — | — | C-1 | T-W-1, T-W-2, T-L-1, T-L-3, T-L-2 | M-1, M-2 | S-3 |
| I_1A_O8/10_W02 potrafi wymienić i opisać poszczególne etapy procesu tworzenia bezpiecznego oprogramowania (wymagania, projektowanie, implementacja, testowanie) | I_1A_W06, I_1A_W22 | — | — | C-3, C-2, C-4 | T-W-3, T-W-5, T-W-6, T-W-4, T-L-6, T-L-4, T-L-5 | M-1, M-2 | S-3 |
Zamierzone efekty kształcenia - umiejętności
| Zamierzone efekty kształcenia | Odniesienie do efektów kształcenia dla kierunku studiów | Odniesienie do efektów zdefiniowanych dla obszaru kształcenia | Odniesienie do efektów kształcenia prowadzących do uzyskania tytułu zawodowego inżyniera | Cel przedmiotu | Treści programowe | Metody nauczania | Sposób oceny |
|---|---|---|---|---|---|---|---|
| I_1A_O8/10_U01 potrafi określić wymagania bezpieczeństwa, zaprojektować i zaimplementować bezpieczną aplikację zgodnie z przyjętymi normami, zaleceniami i dobrymi praktykami | I_1A_U01, I_1A_U10 | — | — | C-3, C-2 | T-W-3, T-W-5, T-W-6, T-W-4, T-L-6, T-L-4, T-L-5 | M-1, M-2 | S-1, S-2 |
Zamierzone efekty kształcenia - inne kompetencje społeczne i personalne
| Zamierzone efekty kształcenia | Odniesienie do efektów kształcenia dla kierunku studiów | Odniesienie do efektów zdefiniowanych dla obszaru kształcenia | Odniesienie do efektów kształcenia prowadzących do uzyskania tytułu zawodowego inżyniera | Cel przedmiotu | Treści programowe | Metody nauczania | Sposób oceny |
|---|---|---|---|---|---|---|---|
| I_1A_O8/10_K01 ma świadomość wpływu posiadanej wiedzy, jej aktualności, jakości własnej pracy oraz znajomości przepisów prawa w zakresie bezpieczeństwa informacji na bezpieczeństwo projektowanych systemów informatycznych i przetwarzanych przez nie informacji | I_1A_K01, I_1A_K02 | — | — | C-1, C-2 | T-W-1, T-W-2, T-L-1, T-L-3, T-L-2 | M-1, M-2 | S-2, S-3 |
Kryterium oceny - wiedza
| Efekt kształcenia | Ocena | Kryterium oceny |
|---|---|---|
| I_1A_O8/10_W01 potrafi wymienić i scharakteryzować typowe podatności oprogramowania mające wpływ na jego bezpieczeństwo | 2,0 | nie spełnia kryteriów określonych dla oceny 3 |
| 3,0 | potrafi wymienić wybrane podstawowe klasy podatności | |
| 3,5 | potrafi wymienić i krótko scharakteryzować wybrane klasy podatności | |
| 4,0 | potrafi wymienić i krótko scharakteryzować większość klas podatności | |
| 4,5 | potrafi sklasyfikować podatności według ich wpływu na bezpieczeństwo aplikacji | |
| 5,0 | potrafi wskazać aktualne zalecenia (np. organizacji OWASP) dla najważniejszych klas podatności | |
| I_1A_O8/10_W02 potrafi wymienić i opisać poszczególne etapy procesu tworzenia bezpiecznego oprogramowania (wymagania, projektowanie, implementacja, testowanie) | 2,0 | nie spełnia kryteriów określonych dla oceny 3 |
| 3,0 | potrafi wymienić i krótko opisać poszczególne etapy wytwarzania bezpiecznego oprogramowania | |
| 3,5 | potrafi opisać proces definiowania wymagań bezpieczeństwa dla oprogramowania | |
| 4,0 | potrafi wskazać i opisać narzędzi pozwalające na projektowanie bezpiecznych aplikacji (przykładowo rozszerzenie języka modelowania SecureUML) | |
| 4,5 | potrafi wskazać wymienić i krótko scharakteryzować wybrane zalecenia implementacyjne związane z wytwarzaniem oprogramowania w językach C i Java | |
| 5,0 | potrafi wymienić i krótko scharakteryzować procedury testowe bezpieczeństwa kodu i systemów oprogramowania |
Kryterium oceny - umiejętności
| Efekt kształcenia | Ocena | Kryterium oceny |
|---|---|---|
| I_1A_O8/10_U01 potrafi określić wymagania bezpieczeństwa, zaprojektować i zaimplementować bezpieczną aplikację zgodnie z przyjętymi normami, zaleceniami i dobrymi praktykami | 2,0 | nie spełnia kryteriów określonych dla oceny 3 |
| 3,0 | potrafi określić i formalnie zapisać wymagania bezpieczeństwa dla prostego systemu oprogramowania oraz wykorzystać rozszerzenia języka UML (np. SecureUML) do przestawienia architektury oprogramowania na bazie określonych wymagań bezpieczeństwa | |
| 3,5 | potrafi zaimplementować oprogramowanie w wybranym języku na bazie opracowanego projektu z uwzględnieniem konieczności wykorzystania mechanizmów poprawiających bezpieczeństwo w oparciu o określone wcześniej wymagania | |
| 4,0 | potrafi praktycznie wykorzystać wskazania norm i zbiorów dobrych praktyk dotyczących implementacji bezpiecznego oprogramowania w danym języku | |
| 4,5 | potrafi przeprowadzić w ograniczonym zakresie testy bezpieczeństwa stworzonego oprogramowania | |
| 5,0 | potrafi przeprowadzić proces tworzenia oprogramowania wymagany na ocenę 4,5 dla alternatywnego języka oprogramowania |
Kryterium oceny - inne kompetencje społeczne i personalne
| Efekt kształcenia | Ocena | Kryterium oceny |
|---|---|---|
| I_1A_O8/10_K01 ma świadomość wpływu posiadanej wiedzy, jej aktualności, jakości własnej pracy oraz znajomości przepisów prawa w zakresie bezpieczeństwa informacji na bezpieczeństwo projektowanych systemów informatycznych i przetwarzanych przez nie informacji | 2,0 | nie spełnia kryteriów określonych dla oceny 3 |
| 3,0 | ma świadomość istnienia norm, zaleceń i zbiorów dobrych praktyk związanych z wytwarzaniem bezpiecznego oprogramowania | |
| 3,5 | potrafi wskazać wybrane normy, zalecenia i dobre praktyki związane z wytwarzaniem bezpiecznego oprogramowania, których użył podczas rozwiązywania zadań | |
| 4,0 | ma świadomość jakie przepisy prawa mogą zostać naruszone w wyniku korzystania z wadliwego i niebezpiecznego oprogramowania | |
| 4,5 | aktywnie uzupełnia wiedzę o najnowsze informacje mogące mieć wpływ na bezpieczeństwo wytwarzanego i eksploatowanego oprogramowania | |
| 5,0 | zna metody udostępniania własnej wiedzy mogącej mieć wpływ na bezpieczeństwo wytwarzanego i eksploatowanego oprogramowania |
Literatura podstawowa
- Julia H. Allen, Sean J. Barnum, Robert J. Ellison, Gary McGraw, Nancy R. Mead, Software Security Engineering: A Guide for Project Managers, Addison-Wesley Professional, 2008
- Robert C. Seacord, The CERT C Secure Coding Standard, Addison-Wesley Professional, 2008
- Fred Long, Dhruv Mohindra, Robert C. Seacord, Dean F. Sutherland, David Svoboda, The CERT® Oracle® Secure Coding Standard for Java, Addison-Wesley Professional, 2011
Literatura dodatkowa
- Maura A. van der Linden, Testing Code Security, Auerbach Publications, 2007
- Brian Chess, Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007
- Mark Curphey, Joel Scambray, Erik Olson, Improving Web Application Security. Threats and Countermeasures, Microsoft, 2003