Drobne nawiązanie do tekstu Czy potrzebujesz właśnie testów penetracyjnych i tematów podnoszonych przez Michała (xterm) w komentarzach.
Pierwsze pytanie: czego chce klient. Stwierdzenie, że klient chce dupokrytki choć brutalne, jest często prawdziwe. Być może chodzi o wykazanie należytej staranności na wypadek, gdyby coś poszło nie tak. Można wówczas pokazać, że przecież zleciło się "audyt bezpieczeństwa", a że audyt tego nie wykazał - no trudno, my dochowaliśmy należytej staranności, winni są ONI. Czasami pojawia się nawet pytanie, czy można wydać "certyfikat bezpieczeństwa" dla badanej aplikacji. Oczywiście można, tylko co taki certyfikat miałby poświadczać? Być może upowszechnienie się Application Security Verification Standards na wystawianie takich "certyfikatów" pozwoli. Osobiście jestem zdania, że takie "poświadczenia" i "certyfikaty" mają sens jedynie wówczas gdy sposób weryfikacji/testowania jest metodyczny i powtarzalny oraz porównywalny między różnymi zespołami wykonującymi testy, czyli w szczególności gdy jest jakaś "lista kontrolna" która ma zostać wypełniona w oparciu o określone testy i na podstawie tej listy można wydać konkretną opinię. Dla przeciętnego klienta jednak zagadnienia te są niezrozumiałe, a skoro klient chce mieć certyfikat, to znajdzie się ktoś, kto mu ten certyfikat da... Rzeczywista jakość i wartość takiej usługi może jednak pozostawiać bardzo wiele do życzenia, ale to już problem klienta.
Moje zdanie jest takie - jeśli (potencjalny) klient chce tylko dupokrytki w postaci "certyfikatu do powieszenia na ścianie" i w dodatku chce to szybko i tanio a wszelkie próby jego "edukowania" kończą się niepowodzeniem, lepiej podziękować mu za współpracę. Ja wiem, że jest to dość kontrowersyjne podejście i nie zawsze można sobie na nie pozwolić. Patrzę na to jednak w ten sposób, że z jednej strony jest klient, który potrzebuje (konkretnej) usługi, z drugiej strony jest wykonawca usługi oferujący. Albo klient z wykonawcą spotkają się "gdzieś pośrodku" w temacie potrzebnej/oferowanej usługi, albo nie. Jeśli klient potrzebuje innej usługi niż ta, którą wykonawca jest w stanie dostarczyć, lepszym rozwiązaniem może być wskazanie kogoś, kto właśnie taką usługę zaoferuje (z ewentualną opcją na podwykonawstwo w pewnym zakresie). Jeśli klient chce określonej usługi, ale narzuca jednocześnie na wykonawcę takie ograniczenia, że usługi nie można wykonać rzetelnie (kwestia dyskusyjna co to dla kogo oznacza), lepiej się w to nie pchać.
Druga kwestia to pokazanie wyższości testów ręcznych nad testami automatycznymi. W zasadzie nawet nie chodzi o pokazanie wyższości tylko o pokazanie różnic. Jak już pisałem testy automatyczne mają swoją wartość, w niektórych sytuacjach narzędzia automatyczne sprawdzają się naprawdę dobrze, w innych - są bezużyteczne. Trzeba umieć podkreślić te różnice. Tu ponownie wiążę duże nadzieje ze wspomnianym już ASVS i różnicami między Level 1 – Automated Verification oraz Level 2 – Manual Verification. Przy okazji proponuję przyjrzeć się konkretnym "punktom kontrolnym" na poziomach 1A oraz 1B i zastanowić się ile narzędzi automatycznych rzeczywiście jest w stanie je zweryfikować.
Jest jeden problem - czy po stronie klienta jest ktoś, kto chce rzeczowych argumentów słuchać i jest je w stanie zrozumieć?
