V1. Architektura, projektowanie i modelowanie zagrożeń

Architektura nie jest implementacją, ale sposobem myślenia o problemie, który ma potencjalnie wiele różnych odpowiedzi i nie ma jednej „poprawnej” odpowiedzi. Zbyt często bezpieczeństwo jest postrzegane jako nieelastyczne i wymagające, ponieważ programiści muszą naprawiać kod w określony sposób, podczas gdy mogą znać znacznie lepszy sposób rozwiązania problemu. Nie ma jednego, prostego rozwiązania dla architektury, a udawanie, że jest inaczej, jest niekorzystne dla inżynierii oprogramowania.

V1.1: Weryfikacja wymagań bezpiecznego Cyklu Życia Oprogramowania

V1.1.1 Zweryfikuj użycie bezpiecznego cyklu rozwoju oprogramowania, który dotyczy bezpieczeństwa na wszystkich etapach rozwoju

Wszystkie procesy związane z bezpiecznym cyklem rozwoju oprogramowania oparte zostały na modelu DevOps [klienci] lub SAMM [Yetiforce], który znacząco zmniejsza ryzyka związane z częstym wydawaniem wersji oraz wdrażaniem wielu systemów YetiForce w tym samym czasie. Każde wdrożenie, zmiana lub rozbudowa YetiForce przechodzi przez podstawowe i bezpieczne etapy tj.:

  • Planowanie
  • Analiza
  • Projekt
  • Wdrożenie
  • Utrzymanie

Dodatkowo korzystamy z wielu narzędzi, które pozwalają automatyzować zadania na każdym etapie cyklu rozwoju oprogramowania. Do największych platform wspomagających mozna zaliczyć m.in. GitHub, na którym oparty został projekt oraz szereg narzędzi do automatyzacji.

V1.1.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

Do najważniejszych frameworków, którym posługujemy się podczas tworzenia bezpiecznego cyklu, można zaliczyć: Software Assurance Maturity Model (SAMM) [https://www.opensamm.org/]. Uproszczony proces związany z rowojem oprogramowania, jest zblizony do modelu opisanego poniżej. W praktyce model ten może ulec rozbudowie lub uproszczeniu w momentach w których to odbiorca systemu zdecyduje o zmianie modelu tworzenia oprogramowania.

OWASP SAMM

Główny system powstaje przy zachowaniu najwyższych standardów opisanych w SAMM jednakże praca z klientem często wymaga zwinnej pracy w oparciu o DevOps.

V1.1.3 Sprawdź, czy wszystkie “user stories” i funkcje zawierają funkcjonalne ograniczenia bezpieczeństwa

YetiForce posiada na starcie ponad 80 funkcjonalności po stronie użytkownika oraz tysiące pól i zależności. System został tak zaprojektowany, aby wszystkie scenariusze użytkownika oraz mechanizmy, funkcjonalności i narzędzia były oparte o jeden centralny system zarządzania uprawnieniami i dostępem. Logika wdrożona po stronie użytkownika, jest taka sama na każdej warstwie systemu [np. API] a więc wszystkie polityki i reguły zostały scentralizowane. W praktyce oznacza to, że wszystkie formularze, pola a nawet zapytania za pomoca API mają ustalone te same centralne zasady bezpieczeństwa.

Wdrożone automatyczne skrypty wyszukujące podatności i niepoprawności w kodzie, potrafią automatycznie zweryfikować reguły i ograniczenia we wszystkich modułach [typu entity] w całym systemie.

V1.1.4 Sprawdź dokumentację i uzasadnienie wszystkich granic zaufania, komponentów i ważnych przepływów danych aplikacji

Do najwazniejszych mechanizmów systemu, jest zbiór kilkunastu narzędzi, za pomocą których administrator ma pełną kontrolę nad tym do jakich danych, funkcjonalności, narzędzi i pól mają dostęp użytkownicy, ale również mogą w pełni konfigurować poziomy dostępu czy też sposób realizacji przepływu danych dla wszystkich uprawnionych [użytkownicy, super użytkownicy, użytkownicy zewnętrzni [np. API, Portal, Serwis WWW].

Inspektor uprawnień wbudowany w system, pozwala na weryfikacją uprawnień również od strony użytkownika, gdzie osoby będące wyżej w hierarchii organizacji mogą weryfikować poziom dostępu do danych osobom znajdującym się niżej w hierarchii organizacji. System nie posiada dokumentacji opisującej granice zaufania dla komponentów i ważnych przepływów danych, ponieważ jest to realizowane dla każdego klienta indywidualnie i za pomocą wbudowanych mechanizmów ogólnych konfigurowalne zgodnie z oczekiwaniami i wymaganiami biznesowymi.

V1.1.5 Sprawdź definicję i analizę bezpieczeństwa architektury aplikacji i wszystkich połączonych usług zdalnych

Zachowanie wszystkich usług i użytkowników jest monitorowane na wielu warstwach systemu m.in.

  • zachowanie i naruszenia w API
  • zachowanie i naruszenia bez autoryzacji [w tym CSRF]
  • zachowanie i naruszenia użytkowników i super użytkowników
  • zachowanie i naruszenia administratorów

System pozwala przeglądać nieprawidłowości, które następnie stają się podstawą do poprawiania mechanizmów bezpieczeństwa i weryfikują pierwotne założenia dla bezpieczeństwa. Za pomocą wbudowanych narzędzi, administrator ma pełną wiedzę i kontrolę nad tym co się dzieje i może w czasie rzeczywistym reagować na incydenty.

W przypadku naruszeń i incydentów na innych warstwach takich jak system operacyjny, aplikacje serwera www i baz danych, sprzęt, wizualizacja, to jest to monitorowane poza główną aplikacją YetiForce. System YetiForce można tak rozbudować, aby stał się centralnym systemem do zbierania danych z innych systemów tj. SIEM czy DLP.

V1.1.6 Zweryfikuj implementację scentralizowanej, prostej, sprawdzonej, bezpiecznej i wielokrotnego użytku kontroli bezpieczeństwa, aby uniknąć podwójnych, brakujących, nieskutecznych lub niepewnych kontroli

Oprócz scentralizowanych mechanizmów kontroli błędów, naruszeń i bezpieczeństwa dla administratora, w systemie został zaimplementowany zaawansowany mechanizm debugowania, który pozwala wyłapać wszystkie błędy aplikacji [tak samo wszystkie narzędzia zalecane w stosie technologicznym przez producenta, mają taką możliwość].

Dla usług zewnętrznych, aplikacja posiada gotowe rozwiązania API Proxy, które ma wbudowane niezależne mechanizmy zbierania informacji o zapytaniach, błędach i naruszeniach, które zabezpieczają samą komunikację i mogą zablokowac usługę, która zachowuje się podejrzanie.

Wieloetapowe mechanizmy kontroli i weryfikacji, pozwalają na wyłapywanie nieprawidłowości na każdej warstwie komunikacji, co znacząco zwiększa bezpieczeństwo i pozwala monitorować bezpieczeństwo i nieprawidłowości niezależnie przez różne zespoły w organizacji. 

 V1.1.7 Sprawdź dostępność listy kontrolnej bezpiecznego kodowania, wymagań bezpieczeństwa, wytycznych lub zasad dla wszystkich programistów i testerów

Każdy etap wytawarzania kodu przez zespoły programistyczne i zespoły testerów jest ściśle zaprojektowany i realizowany zgodnie z politykami opisanymi w dokumencie OpenSAAM. Przyjęto ustalenia wdrożone w organizacji producenta [które obowiązują wszystkich pracowników pracujących w cyklu tworzenia oprogramowania]:

  1. Zarządzanie
    1. Strategia i wskaźniki
      1. Ustanowiono ujednolicony strategiczny plan działania dotyczący bezpieczeństwa oprogramowania w organizacji;
      2. Zmierzono względną wartość danych i zasobów oprogramowania oraz określono poziomy ryzyk;
      3. Dopasowano wydatki na bezpieczeństwo
    2. Reguły i zgodność
      1. Zapoznano się z istotnymi czynnikami odpowiedzialnymi za nadzór i zgodność w organizacji;
      2. Ustalono linię bazową bezpieczeństwa i zgodności oraz określono ryzyka związane z projektem;
      3. Wymagamy zgodności i mierzymy projekty pod kątem zasad i standardów obowiązujących w całej organizacji;
    3. Edukacja i doradztwo
      1. Przekazano programistom dostęp do zasobów związanych z bezpiecznym programowaniem i wdrażaniem;
      2. Przeszkolono cały zespół, udzielając wskazówek dotyczących bezpiecznego rozwoju dla konkretnych ról;
      3. Wykonujemy kompleksowe szkolenia w zakresie bezpieczeństwa oraz dostarczamy niezbędną wiedzę;
  2. Tworzenie
    1. Ocena zagrożeń
      1. Zidentyfikujemy zagrożenia na wysokim poziomie dla organizacji i poszczególnych etapów cyklu;
      2. Regularnie zwiększamy dokładność oceny zagrożeń i poprawiamy szczegółowość zrozumienia całego cyklu;
      3. Powiązujemy zasady bezpieczeństwa z każdym zagrożeniem w całym cyklu tworzenia oprogramowania;
    2. Wymagania bezpieczeństwa
      1. Przy tworzeniu wymagań uwzględniamy bezpieczeństwo;
      2. Uszczegóławiamy wymagania bezpieczeństwa wynikających z logiki biznesowej i znanych zagrożeń;
      3. Weryfikujemy wymagania bezpieczeństwa dla bibliotek zewnętrznych;
    3. Bezpieczeństwo architektury
      1. Uwzględniamy wszystkie istotne wskazówki dotyczące bezpieczeństwa w procesie projektowania oprogramowania;
      2. Wytwarzamy oprogramowanie zgodnie z obowiązującymi standardami i stosujemy obowiązujące zalecenia dla używanych technologii;
      3. Kontrolujemy proces projektowania oprogramowania i weryfikujemy wykorzystanie bezpiecznych komponentów;
  3. Weryfikacja
    1. Przegląd projektu
      1. Regularnie wykonujemy kontrole projektu oprogramowania, aby wyłapać potencjalne zagrożenia i niezgodności;
      2. Realizujemy oraz oferujemy usługi oceny projektu pod kątem najlepszych praktyk w zakresie bezpieczeństwa;
      3. Oceniamy i weryfikujemy funkcjonalności, aby uzyskać szczegółowe zrozumienie mechanizmów ochrony;
    2. Przegląd kodu
      1. Weryfikujemy w czasie rzeczywistym ryzyka wynikające z jakości kodu i podatności bibliotek zewnętrznych;
      2. Automatycznie weryfikujemy jakość kodu na różnych etapach jego wytwarzania a następnie poddajemy go ręcznej kontroli;
      3. Wykonujemy kompleksową oraz podwójną analizę kodu, za pomocą "pull requests" wbudowanych w GIT
    3. Testy bezpieczeństwa
      1. Realizujemy zaawansowane testy bezpieczeństwa w oparciu o standardy tworzenia aplikacji
      2. Wykorzystujemy możliwości GitHub i innych otwartych platform do automatyzacji wszystkie procesów związanych z bezpieczeństwem
      3. Zalecamy specyficznych dla aplikacji testy bezpieczeństwa, aby zapewnić wysoki poziom bezpieczeństwa przed wdrożeniem
  4. Implementacja
    1. Zarządzanie podatnościami
      1. Wdrożyliśmy wysokopoziomowym plan reagowania na zgłoszenia oraz incydenty dotyczące luk w zabezpieczeniach
      2. Opracowaliśmy standardy dotyczące procesu odpowiedzi, aby poprawić spójność i komunikację
      3. Optymalizujemy analizę i gromadzenie danych w ramach procesu odpowiedzi w celu uzyskania informacji zwrotnych na temat proaktywnego planowania
    2. Ulepszanie środowiska i systemu
      1. Stworzyliśmy idealnie zaprojektowane środowisko dla systemu i aplikacji powiązanych
      2. Zwiększyliśmy zaufanie do operacji aplikacji dzięki wzmocnieniu środowiska operacyjnego
      3. Weryfikujemy środowisko aplikacji zgodnie z najlepszymi praktykami dla używanych technologii
    3. Praca zespołowa
      1. Zbudowaliśmy komunikację między zespołami  w celu uzyskania krytycznych danych istotnych dla bezpieczeństwa
      2. Poprawiamy i ulepszamy procedury w celu poprawy bezpieczeństwa systemu, aplikacji, środowiska i danych
      3. Narzucamy zgłaszanie informacji o naruszeniach i bezpieczeństwie jako proces ciągłego doskonalenia

V1.2: Weryfikacja wymagań architektonicznych dotyczących Autoryzacji

V1.2.1 Zweryfikuj użycie unikalnych lub specjalnych kont systemu operacyjnego o niskich uprawnieniach dla wszystkich komponentów aplikacji, usług i serwerów

Na każdej warstwie aplikacji, mamy możliwość kontrolowania dostępu do modułów, pól, narzędzi, widoków oraz danych. Dla systemu operacyjnego, serwera WWW oraz baz danych są stosowane standardy normujące bezpieczny sposób konfiguracji tych usług:

W praktyce, nadajemy zawsze najniższy możliwy poziom uprawnień, dla każdej aplikacji, usługi oraz użytkownika.

V1.2.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

Poziom uprawnień każdego komponentu jest sterowane przez administratora systemu tak samo jak dla każdego użytkownika, w praktyce oznacza to, że mamy nieograniczone możliwości sterowania dostęp do funkcjonalności, pól, operacji czy też danych na jakich pracuje komponent. Dostęp jest scentralizowany i dla wszystkich mechanizmów działa zawsze tak samo.

V1.2.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

Wszystkie mechanizmy i usługi bazują na jednym scentralizowanym mechanizmie autoryzacji [można też zintegrować się z LDAP], który był audytowany przez niezależnych eksportów bezpieczeństwa a dodatkowo można go wzmianać za pomocą 2FA. Każda operacja wykonywana przez użytkownika, aplikację lub komponent jest monitorowana i logowana [zgodnie z poziomiem konfiguracji logowania]. Dodatkowo dla komponentów utworzono mechanizmy API Proxy, mające dodatkowe zabezpieczenia i dodatkową warstwę komunikacyjną.

V1.2.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

Aplikacja pozwala na konfigurowanie poziomu zabezpieczeń poszczególnych mechanizmów z możliwością ich rozbudowy lub rozszerzenia o niestandardowe rozwiązania szyfrujące. Nawet jeżeli aplikacja posiada ograniczenia, w bardzo łatwy sposób na etapie wdrożenia można dowolnie zwiększyć oczekiwane parametry i ustawić poziom zabezpieczeń adekwatny do danych, które są w systemie przetwarzane, bez żadnych ograniczeń, których nie można w łatwy sposób zmodyfikować.

V1.3 Wymagania architektoniczne dotyczące Zarządzania Sesją

 

  • poniedziałek, 26 kwiecień 2021