Secure by Design & Default

System YetiForce jest projektowany od podstaw w sposób, który zakłada wysoki poziom bezpieczeństwa na każdej warstwie projektowania aplikacji. Główną dokumentacją na której bazuje nasz zespół, są dokumenty publikowane przez fundację OWASP oraz standardy tworzenie oprogramowania dla języków używanych w systemie.

Dokumentacja źródłowa

Tworząc oprogramowania skierowane dla dowolnej wielkości organizacji, musimy zwracać szczególną uwagę na bezpieczeństwo aplikacji, ponieważ każde duże wdrożenie systemu najczęściej jest poprzedzone dogłębną analizą bezpieczeństwa wykonaną albo przez klienta albo przez niezależną firmę zewnętrzną. Poniżej zostały wymienione dokumenty, które omawiają sposób projektowania bezpiecznych aplikacji a co do których w całości lub w dużej części się stosujemy:

Najważniejsze praktyki wdrożone w systemie YetiForce

OWASP Application Security Verification Standard 4.x

  1. Weryfikacja wymagań bezpiecznego Cyklu Życia Oprogramowania
    1. Zweryfikuj użycie bezpiecznego cyklu rozwoju oprogramowania, który dotyczy bezpieczeństwa na wszystkich etapach rozwoju.
    2. Zweryfikuj wykorzystanie modelowania zagrożeń dla każdej zmiany projektu lub szybkie planowanie, aby zidentyfikować zagrożenia, zaplanować środki zaradcze, ułatwić odpowiednie reakcje na ryzyko i przeprowadzić testy bezpieczeństwa.
    3. Sprawdź, czy wszystkie “user stories” i funkcje zawierają funkcjonalne ograniczenia bezpieczeństwa, takie jak „Jako użytkownik powinienem móc wyświetlać i edytować mój profil. Nie powinienem mieć możliwości przeglądania ani edytowania profilu innych osób”
    4. Sprawdź dokumentację i uzasadnienie wszystkich granic zaufania, komponentów i ważnych przepływów danych aplikacji.
    5. Sprawdź definicję i analizę bezpieczeństwa architektury aplikacji i wszystkich połączonych usług zdalnych.
    6. Zweryfikuj implementację scentralizowanej, prostej (ekonomiczna konstrukcja), sprawdzonej, bezpiecznej i wielokrotnego użytku kontroli bezpieczeństwa, aby uniknąć podwójnych, brakujących, nieskutecznych lub niepewnych kontroli.
    7. Sprawdź dostępność listy kontrolnej bezpiecznego kodowania, wymagań bezpieczeństwa, wytycznych lub zasad dla wszystkich programistów i testerów.
  2. Weryfikacja wymagań architektonicznych dotyczących Autoryzacji
    1. Zweryfikuj użycie unikalnych lub specjalnych kont systemu operacyjnego o niskich uprawnieniach dla wszystkich
      komponentów aplikacji, usług i serwerów.
    2. Sprawdź, czy komunikacja między komponentami aplikacji, w tym API, oprogramowaniem pośrednim i warstwami danych, jest autoryzowana. Komponenty powinny mieć najniższe niezbędne uprawnienia.
    3. Sprawdź, czy aplikacja korzysta z pojedynczego sprawdzonego mechanizmu autoryzacji, o którym wiadomo, że jest bezpieczny, że można go rozszerzyć o silne uwierzytelnianie i czy ma wystarczające logi i monitorowanie, aby wykryć nadużycia lub naruszenia konta.
    4. Zweryfikuj czy pola wejściowe haseł pozwalają lub zachęcają do używania tekstu szyfrującego i nie zapobiegają wprowadzania haseł, które są długimi lub bardzo złożonymi tekstami szyfrującymi.
  3. Wymagania architektoniczne dotyczące Zarządzania Sesją
  4. Wymagania architektoniczne dotyczące Kontroli dostępu
    1. Sprawdź, czy zaufane punkty kontaktowe, takie jak bramy kontroli dostępu, serwery i funkcje bez serwera, wymuszają kontrolę dostępu. Nigdy nie wymuszaj kontroli dostępu na kliencie.
    2. Sprawdź, czy wybrane rozwiązanie kontroli dostępu jest wystarczająco elastyczne, aby spełnić potrzeby aplikacji.
    3. Zweryfikuj egzekwowanie zasady najniższych uprawnień w funkcjach, plikach danych, adresach URL, kontrolerach, usługach i innych zasobach. Oznacza to ochronę przed spoofingiem i zwiększenie uprawnień.
    4. Sprawdź, czy aplikacja korzysta z pojedynczego i sprawdzonego mechanizmu kontroli dostępu do chronionych danych i zasobów. Wszystkie żądania muszą przejść przez ten pojedynczy mechanizm, aby uniknąć kopiowania i wklejania lub niezabezpieczonych alternatywnych ścieżek.
    5. Sprawdź, czy używana jest kontrola dostępu na bazie funkcji lub atrybutów, dzięki której kod sprawdza autoryzację użytkownika dla funkcji/elementu danych, a nie tylko jego rolę. Uprawnienia należy nadal przydzielać za pomocą ról.
  5. Wymagania architektoniczne dotyczące danych wejściowych i wyjściowych
    1. Sprawdź, czy wymagania dotyczące danych wejściowych i wyjściowych jasno określają, w jaki sposób obsługiwać i przetwarzać dane na podstawie typu, treści i obowiązujących przepisów, regulacji i innych zasad zgodności z polityką.
    2. Sprawdź, czy serializacja nie jest używana podczas komunikacji z niezaufanymi klientami. Jeśli jest to niemożliwe, upewnij się, że odpowiednie kontrole integralności (i ewentualnie szyfrowanie, jeśli wysyłane są dane wrażliwe) są wymuszane, aby zapobiec atakom deserializacji, w tym “object injection”.
    3. Sprawdź, czy sprawdzanie poprawności danych wejściowych jest wymuszane na zaufanej warstwie usług
    4. Sprawdź, czy kodowanie wyjściowe występuje blisko lub przez interpretera, dla którego jest przeznaczone.
  6. Kryptograficzne wymagania architektoniczne
    1. Sprawdź, czy istnieje wyraźna zasada zarządzania kluczami kryptograficznymi i czy cykl życia klucza kryptograficznego jest zgodny ze standardem zarządzania kluczami, takim jak NIST SP 800-57.
    2. Sprawdź, czy konsumenci usług kryptograficznych chronią kluczowe materiały i inne tajemnice za pomocą Key Vaults lub alternatyw opartych na API.
    3. Sprawdź, czy wszystkie klucze i hasła są wymienne i są częścią dobrze zdefiniowanego procesu ponownego szyfrowania poufnych danych.
    4. Sprawdź, czy klucze symetryczne, hasła lub tajemnice API generowane przez klientów lub udostępniane klientom są używane tylko do ochrony tajemnic niskiego ryzyka, takich jak szyfrowanie pamięci lokalnej lub tymczasowe efemeryczne zastosowania, takie jak zaciemnianie parametrów. Dzielenie się tajemnicami z klientami jest równoznaczne z użyciem zwykłego tekstu architektonicznie powinno być traktowane jako takie.
  7. Wymagania architektoniczne dotyczące Obsługi i Rejestrowania Błędów
    1. Sprawdź, czy w systemie używany jest wspólny format rejestrowania błędów i to samo podejście.
    2. Sprawdź, czy logi są bezpiecznie przesyłane do zdalnego systemu w celu analizy, wykrywania, alarmowania i eskalacji.
  8. Wymagania architektoniczne dotyczące Ochrony Danych i Prywatności
    1. Sprawdź, czy wszystkie wrażliwe dane zostały zidentyfikowane i sklasyfikowane do poziomów ochrony.
    2. Sprawdź, czy wszystkie poziomy ochrony mają powiązany zestaw wymagań dotyczących bezpieczeństwa, takich jak wymagania dotyczące szyfrowania, integralności, retencji, prywatności i inne wymagania dotyczące poufności, i że są one stosowane w architekturze.
  9. Wymagania architektoniczne dotyczące Komunikacji
    1. Sprawdź, czy aplikacja szyfruje komunikację między komponentami, szczególnie gdy te komponenty znajdują się w różnych kontenerach, systemach, witrynach lub u dostawców chmury.
    2. Sprawdź, czy komponenty aplikacji weryfikują autentyczność każdej strony w łączu komunikacyjnym, aby zapobiec atakom typu „person-in-the-middle”. Na przykład komponenty aplikacji powinny sprawdzać poprawność certyfikatów TLS i łańcuchów.
  10. Wymagania architektoniczne dotyczące złośliwego oprogramowania
    1. Sprawdź, czy używany jest system kontroli kodu źródłowego, z procedurami zapewniającymi, że check-inom towarzyszą issues lub tickety zmian. System kontroli kodu źródłowego powinien mieć kontrolę dostępu i identyfikowalnych użytkowników, aby umożliwić śledzenie wszelkich zmian.
  11. Wymagania architektoniczne dotyczące Logiki Biznesowej
    1. Sprawdź definicję i dokumentację wszystkich komponentów aplikacji pod kątem funkcji biznesowych lub funkcji bezpieczeństwa, które zapewniają.
    2. Sprawdź, czy wszystkie przepływy logiki biznesowej o wysokiej wartości, w tym uwierzytelnianie, zarządzanie sesjami i kontrola dostępu, nie współdzielą stanu niezsynchronizowanego.
    3. Sprawdź, czy wszystkie przepływy logiki biznesowej o wysokiej wartości, w tym uwierzytelnianie, zarządzanie sesjami i kontrola dostępu, są bezpieczne dla wątków i odporne na warunki time-of-check i time-of-use.
  12. Wymagania architektoniczne dotyczące bezpiecznego przesyłania plików
    1. Sprawdź, czy pliki przesłane przez użytkownika są przechowywane poza głównym katalogiem WWW.
    2. Sprawdź, czy pliki przesłane przez użytkownika - jeśli są wymagane do wyświetlenia lub pobrania z aplikacji - są obsługiwane przez pobieranie octet stream lub z niepowiązanej domeny do przechowywania plików w chmurze. Zaimplementuj odpowiednią politykę bezpieczeństwa treści, aby zmniejszyć ryzyko związane z wektorami XSS lub innymi atakami z przesłanego pliku.
  13. Wymagania architektoniczne dotyczące API
  14. Wymagania architektoniczne konfiguracji
    1. Sprawdź segregację komponentów o różnych poziomach zaufania za pomocą dobrze zdefiniowanych mechanizmów bezpieczeństwa, reguł zapory, API gateways, odwrotnych proxy, grup zabezpieczeń opartych na chmurze, lub podobnych mechanizmów.
    2. Sprawdź, czy wdrażanie plików binarnych na niezaufanych urządzeniach używa podpisów binarnych, zaufanych połączeń i zweryfikowanych punktów końcowych.
    3. Sprawdź, czy pipeline kompilacji ostrzega o nieaktualnych lub niezabezpieczonych komponentach i podejmuje odpowiednie działania.
    4. Sprawdź, czy pipeline kompilacji zawiera build step, aby automatycznie budować i weryfikować bezpieczne wdrożenie aplikacji, szczególnie jeśli infrastruktura aplikacji jest zdefiniowana przez oprogramowanie, na przykład skrypty kompilacji środowiska w chmurze.
    5. Sprawdź, czy wdrożenia aplikacji odpowiednio sandboxują, kontenerują i / lub izolują na poziomie sieci, aby opóźnić i powstrzymać atakujących od atakowania innych aplikacji, zwłaszcza gdy wykonują wrażliwe lub niebezpieczne działania, takie jak deserializacja.
    6. Upewnij się, czy aplikacja nie korzysta z nieobsługiwanych, niezabezpieczonych lub przestarzałych technologii klienta, takich jak wtyczki NSAPI, Flash, Shockwave, ActiveX, Silverlight, NACL lub aplety Java po stronie klienta.

Referencje do dokumentów zewnętrznych:

 

  • środa, 08 lipiec 2020