Bezpieczne z założenia - Secure by design

Bezpieczeństwo z założenia w inżynierii oprogramowania oznacza, że produkty i funkcje oprogramowania zostały zaprojektowane tak, aby były fundamentalnie bezpieczne .

Alternatywne strategie, taktyki i wzorce bezpieczeństwa są brane pod uwagę na początku projektowania oprogramowania, a najlepsze są wybierane i egzekwowane przez architekturę i są wykorzystywane jako zasady przewodnie dla programistów . Zachęca się również do korzystania ze strategicznych wzorców projektowych, które mają korzystny wpływ na bezpieczeństwo, nawet jeśli te wzorce projektowe nie zostały pierwotnie opracowane z myślą o bezpieczeństwie.

Secure by Design staje się w coraz większym stopniu głównym podejściem programistycznym w celu zapewnienia bezpieczeństwa i prywatności systemów oprogramowania. W tym podejściu bezpieczeństwo jest brane pod uwagę i wbudowane w system na każdej warstwie i zaczyna się od solidnego projektu architektury. Decyzje dotyczące projektowania architektury zabezpieczeń są oparte na dobrze znanych strategiach, taktykach i wzorcach zabezpieczeń, zdefiniowanych jako techniki wielokrotnego użytku służące do osiągnięcia określonych problemów dotyczących jakości. Taktyki/wzorce bezpieczeństwa zapewniają rozwiązania do egzekwowania niezbędnych wymagań dotyczących uwierzytelniania , autoryzacji, poufności, integralności danych , prywatności, odpowiedzialności, dostępności, bezpieczeństwa i niezaprzeczalności, nawet gdy system jest atakowany. Aby zapewnić bezpieczeństwo systemu oprogramowania, ważne jest nie tylko zaprojektowanie solidnej, zamierzonej architektury bezpieczeństwa, ale także konieczne jest odwzorowanie zaktualizowanych strategii, taktyk i wzorców bezpieczeństwa na rozwój oprogramowania w celu utrzymania trwałości bezpieczeństwa.

Spodziewaj się ataków

Należy zakładać, że złośliwe ataki na oprogramowanie mają miejsce i należy dołożyć starań, aby zminimalizować ich wpływ. Przewiduje się luki w zabezpieczeniach oraz nieprawidłowe dane wprowadzane przez użytkownika . Ściśle powiązana jest praktyka korzystania z „dobrego” projektowania oprogramowania, takiego jak projektowanie oparte na domenie lub natywne dla chmury , jako sposobu na zwiększenie bezpieczeństwa poprzez zmniejszenie ryzyka błędów otwierających luki — mimo że stosowane zasady projektowania nie były pierwotnie pomyślane z myślą o bezpieczeństwie cele.

Unikaj bezpieczeństwa przez ukrycie

Ogólnie rzecz biorąc, projekty, które działają dobrze, nie polegają na utajnieniu . Często tajność zmniejsza liczbę napastników, demotywując podzbiór populacji zagrożeń. Logika jest taka, że jeśli napastnik staje się bardziej złożony, zniechęca go zwiększony wysiłek atakującego, aby złamać cel. Chociaż technika ta wiąże się z mniejszym ryzykiem nieodłącznym, praktycznie nieskończony zestaw cyberprzestępców i technik stosowanych w miarę upływu czasu spowoduje, że większość metod tajności zawiedzie. Chociaż nie jest to obowiązkowe, odpowiednie zabezpieczenia zwykle oznaczają, że każdy może poznać i zrozumieć projekt, ponieważ jest bezpieczny . Ma to tę zaletę, że wiele osób patrzy na kod komputerowy , co zwiększa szanse, że wszelkie wady zostaną wykryte wcześniej (patrz prawo Linusa ). Wadą jest to, że atakujący mogą również uzyskać kod, co ułatwia im znalezienie luk do wykorzystania. Powszechnie uważa się jednak, że zalety otwartego kodu komputerowego przeważają nad wadami.

Najmniej przywilejów

Ponadto ważne jest, aby wszystko działało z możliwie najmniejszą liczbą uprawnień (patrz zasada najmniejszych uprawnień ). Na przykład serwer sieciowy działający jako użytkownik administracyjny („root” lub „admin”) może mieć uprawnienia do usuwania plików i użytkowników. Wada takiego programu może zatem narazić cały system na ryzyko, podczas gdy serwer sieciowy, który działa w odizolowanym środowisku i ma tylko uprawnienia do wymaganych funkcji sieciowych i systemu plików , nie może naruszyć systemu, na którym działa, chyba że otaczające go zabezpieczenia samo w sobie jest również wadliwe.

Metodologie

Bezpieczne projektowanie powinno być brane pod uwagę na wszystkich etapach cyklu rozwoju (niezależnie od wybranej metodologii rozwoju ).

Istnieje kilka gotowych metodologii projektowania Secure By Design (np. Microsoft Security Development Lifecycle ).

Cykl rozwoju zabezpieczeń firmy Microsoft

Microsoft wydał metodologię i wytyczne oparte na klasycznym modelu spiralnym .

Normy i ustawodawstwo

Istnieją normy i przepisy mające na celu wspomaganie bezpiecznego projektowania poprzez kontrolowanie definicji „bezpiecznego” i zapewnienie konkretnych kroków w zakresie testowania i integracji bezpiecznych systemów.

Kilka przykładów norm, które obejmują lub dotykają zasad Secure By Design:

ETSI TS 103 645, który jest częściowo zawarty w „Wnioskach dotyczących uregulowania cyberbezpieczeństwa inteligentnych produktów konsumenckich” rządu Wielkiej Brytanii
Seria ISO/IEC 27000 obejmuje wiele aspektów bezpiecznego projektowania.

Architektury serwer/klient

W architekturach serwer/klient program po drugiej stronie może nie być autoryzowanym klientem, a serwer klienta może nie być autoryzowanym serwerem. Nawet jeśli tak jest, atak typu man-in-the-middle może zagrozić komunikacji.

Często najłatwiejszym sposobem na złamanie zabezpieczeń systemu klient/serwer nie jest zapoznawanie się z mechanizmami bezpieczeństwa, ale ich obejście. Prostym przykładem jest atak typu man in the middle, ponieważ możesz go użyć do zebrania szczegółów, aby podszywać się pod użytkownika. Dlatego ważne jest, aby w swoim projekcie wziąć pod uwagę szyfrowanie , hashowanie i inne mechanizmy bezpieczeństwa, aby upewnić się, że informacje zebrane od potencjalnego atakującego nie pozwolą na dostęp.

Inną kluczową cechą projektowania zabezpieczeń klient-serwer są dobre praktyki kodowania . Na przykład podążanie za znaną strukturą projektowania oprogramowania, taką jak klient i broker, może pomóc w zaprojektowaniu dobrze zbudowanej struktury o solidnych podstawach. Ponadto, jeśli oprogramowanie ma być modyfikowane w przyszłości, jeszcze ważniejsze jest, aby opierało się na logicznej podstawie separacji między klientem a serwerem. Dzieje się tak, ponieważ jeśli pojawia się programista i nie może jasno zrozumieć dynamiki programu, może w końcu dodać lub zmienić coś, co może dodać lukę w zabezpieczeniach. Nawet przy najlepszym projekcie jest to zawsze możliwe, ale im lepsza standaryzacja projektu, tym mniejsza szansa na to.

Languages

In other projects

Bezpieczne z założenia - Secure by design

Zawartość