OWASP AppSensor .NET – architektura

OWASP AppSensor .NET – architektura

owasp-architektura
Źródło

Po dokładnym opisaniu mechanizmu czas na przedstawienie planowanego rozwiązania AppSensor.NET – architektura jest jedną z istotniejszych składowych projektu. Warto też zdefiniować jego cel oraz zestaw kroków, które zawiodą mnie do jego wykonania.

Założenia i funkcjonalności MVP

Zacznijmy więc od zdefiniowania funkcjonalności, które chcemy osiągnąć w projekcie. Oczywiście można założyć, że docelowo chcielibyśmy zaimplementować spójny mechanizm OWASP AppSensor w pełnym jego zakresie, z implementacją wszystkich zdefiniowanych punktów detekcji i integracji z innymi systemami. Jednak z doświadczenia wiem już, że ten sposób określania wymagań nie jest dobry, bo dość słabo motywuje do pracy i do skończenia projektu. Zamiast tego zdefiniujemy MVP naszego projektu.

MVP (Minimum Viable Product) jest to pojęcie zaczerpnięte z metodologii Lean Management (szczupłego zarządzania). Według tej koncepcji pierwsza wersja projektu powinna być jak najmniejsza i udostępniać tylko najważniejsze funkcjonalności. W szczególności jedną funkcjonalność. Dzięki temu można stosunkowo szybko stworzyć projekt, który będziemy dalej rozwijać. Możliwość szybkiego zbudowania czegoś działającego daje sporo motywacji i zapału do tworzenia. Dodatkowo po powstaniu MVP możemy zdecydować, w którą stronę chcemy rozwijać dalej nasz projekt.

Tak więc lista funkcjonalności MVP:

  • bazowy silnik do przechowywania logów (przechowywanie w bazie danych),
  • biblioteka do konfiguracji zasad wykrywania i progów (konfiguracja z kodu),
  • implementacja 3 najpopularniejszych puktów detekcji:
    • RE1: Unexpected HTTP Command
    • RE3: GET When Expecting POST
    • RE4: POST When Expecting GET
  • implementacja 3 metod reakcji:
    • logowanie informacji
    • wylogowanie
    • blokowanie użytkownika

Składowe systemu

Bazując na szczegółowym opisie technologii OWASP AppSensor można podzielić projekt na niżej wymienione moduły. Każdy z nich postaram się zaimplementować jako oddzielną bibliotekę.

  • Biblioteka do rejestrowania punktów wykrywania (z regułami – z możliwością wyniesienia konfiguracji poza aplikację):
    • definicje punktów detekcji
    • definicje sposobów reakcji
  • Biblioteka do automatycznego podpinania punktów wykrywania do WebAPI
  • Biblioteka rejestrująca zdarzenia podejrzane
  • Serwer logowania (własny i integracje z gotowymi w chmurze) [Kibana, Analogi, Loggly, Splunk]
  • Pulpit podsumowujący zagrożenia w czasie rzeczywistym
  • Aplikacja demonstracyjna
  • Testy dla aplikacji demonstracyjnej

Planowane zadania

Zadania, którymi się zajmuję będę na bieżąco rejestrował w odpowiedniej planszy Trello. Podzieliłem je na 5 grup:

  • Planned – pomysły
  • ToDo – do zrobienia w najbliższym czasie
  • In progress – w trakcie implementacji
  • Done – zrobione
  • Released – skończone i zamknięte w nowej wersji biblioteki

Implementację zacznę od warstwy testowania zagrożeń, przez aplikację demonstracyjną, aż do implementacji samych mechanizmów wewnętrznych. Nie będę tutaj wypisywał konkretnej listy zadań, bo jest ona dostępna publicznie i z natury dość dynamiczna.

Do dzieła 🙂

Sign up for free end-to-end testing training

Learn how to create end-to-end tests for your applications from the beginning to mobile testing
Name
Email address

GET YOUR EMAIL UPDATES

Get great contents delivered straight to your inbox everyday, just a click away, Sign Up Now.
Name
Email address