Jest dostępne publicznie

Powiedzieliśmy już, że kod nie staje się magicznie bezpieczny tylko z powodu poddania go publicznej inspekcji. Z drugiej strony, nie staje się przez to automatycznie niebezpieczny. Dobrze napisany program nie ma usterek, które uczyniłyby go podatnym na atak tylko dlatego, że ludzie przeczytali kod (a napastnicy wcale nie czytają kodu częściej niż obrońcy w obu przypadkach ludzie sumienni i ostrożni czytają kod, a większość po prostu kompiluje go i jest dobrej myśli).

Ogólnie rzecz biorąc, kod dostępny publicznie jest modyfikowany szybciej niż kod prywatny, co oznacza, że usterki są naprawiane wkrótce po ich odkryciu. Szybsze tempo zmian ma swoje wady, o których wspomnieliśmy wcześniej, ale oznacza, że jesteś mniej narażony na stare błędy.

Zostało z powodzeniem zaatakowane. Oczywiście, nie chciałbyś instalować oprogramowania, które ludzie umieją już zaatakować. Powinieneś jednak przywiązywać wagę nie tyle do ataków, co do reakcji na nie. Udany atak (nawet bardzo poważny i nagłośniony) może nie mieć znaczenia, jeśli problem był nowy i został szybko rozwiązany. Często powtarzające się wariacje na temat tego samego problemu lub niechęć producenta do naprawiania usterek to prawdziwe powody do niepokoju, ale nie pojedynczy udany atak nawet taki,

o którym rozpisują się ogólnokrajowe gazety. Prawdziwe wskaźniki bezpieczeństwa. Poniższe czynniki powinny zwiększyć twoje poczucie bezpieczeństwa: Bezpieczeństwo było jednym z kryteriów projektowych.

Wydaje się, że dostawca zna główne typy problemów z bezpieczeństwem i potrafi powiedzieć, jak próbował ich uniknąć. Możesz samodzielnie przejrzeć kod. Ktoś, kogo znasz i komu ufasz, przejrzał kod.

Istnieje procedura powiadamiania o problemach z bezpieczeństwem i uaktualniania serwera. Serwer w pełni realizuje najnowszą (ale akceptowaną) wersję protokołu. Program używa standardowych mechanizmów rejestrowania błędów (syslog w Uniksie, Event Viewer w Windows NT).

Istnieje bezpieczny mechanizm dystrybucji oprogramowania. Bezpieczeństwo było jednym z kryteriów projektowych. Pierwszym krokiem do opracowania bezpiecznego programu jest próba napisania właśnie takiego. To nie może się udać przypadkiem. Dostawca programu musi dowieść, że myślał o bezpieczeństwie już w fazie projektu, i że jego poglądy na bezpieczeństwo są takie same jak twoje. Nie wystarczy, aby „bezpieczeństwo” było jedną z rzeczy do odfajkowania na jakiejś liście. Zapytaj, co spróbowano zabezpieczyć

Leave a reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>