Bezpieczny harmonogram

Stereotyp

Rażące luki bezpieczeństwa to nadal cecha wielu systemów. Zbyt często na później odkładamy implementację zabezpieczeń. Są jeszcze zespoły, w których brakuje wspólnej wizji jak zrobić to dobrze. Poza świadomością pozostaje też fakt, że zarządzanie procesem i planem prac ma niebagatelny wpływ na ten aspekt systemu. Do tego dochodzi jeszcze stereotyp, że wdrożenie polityki bezpieczeństwa to czasochłonne i bardzo trudne zadanie.

Harmonogram

Bezpieczeństwo nie może pozostawać tylko notatką na marginesie harmonogramu. To też funkcja systemu, wymaganie biznesu - nawet jeśli niewypowiedziane. W takim razie aby system realizował w pełni i tę funkcję, tak jak dla każdej innej, trzeba spisać wymagania i przewidzieć czas w harmonogramie. Wtedy dostaniemy o wiele więcej niż zwykły harmonogram, będzie to bezpieczny harmonogram a z nim jasno określone wymagania względem ewentualnej potrzeby uzupełnienia kompetencji niezbędnych do realizacji tak zdefiniowanego celu.

Perspektywy

Bezpieczeństwu warto przyglądać się z różnych perspektyw. Na poziomie kanału komunikacyjnego, na poziomie usług biznesowych, wymiany informacji pomiędzy podsystemami, warstwy przetwarzania i dostępu do danych. Każda faza procesu wytwórczego i każda warstwa systemu to miejsca, w których można i trzeba stawiać pytania o bezpieczeństwo, definiować wymagania i uwzględniać je w harmonogramie.

Faza testów to newralgiczna część cyklu życia projektu. Tu weryfikacji podlegają funkcje systemu wynikające z planu. Bezpieczeństwo jako pełnoprawna funkcja zapisana w grafiku prac, też powinna podlegać tej weryfikacji. Tu też trzeba starannie zaimplementować odpowiedni zbiór testów i, jak zwykle żeby wszystko kosztowało mniej. warto je automatyzować.

Zwykłe wymaganie

Patrząc na bezpieczeństwo jak na zwykłe wymaganie wobec systemu, stosując standardowe praktyki planowania, techniki programowania, testowania i automatyzacji okaże się, że politykę bezpieczeństwa w projekcie można wdrożyć zwinnie i relatywnie niewielkim kosztem.