Ź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 🙂