Nie będę się rozpisywał o usłudze GuardDuty. W dużym skrócie, na podstawie różnych danych potrafi wykryć na naszych kontach rzeczy, które nie powinny mieć miejsca. Ktoś na przykład zacznie kopać bitcoiny, to usługa powinna to wykryć i nas o tym powiadomić. No właśnie, powiadomić. Domyślnie dostajemy w konsoli tak zwane znaleziska

 

Tylko trzeba tam zaglądać. A to nie zawsze będzie miało miejsce. Jest tyle rzeczy, które mogą nam w tym przeszkodzić.

Sporo z nas używa dziś MS Teams. Pokażę więc jak przekazać problemy znalezione przez GuardDuty do Teamsów. Na koniec zrobimy małą zmianę i połączymy się ze Slackiem.

MS Teams

Aby móc przesyłać wiadomości do MS Teams trzeba utworzyć w nich tak zwany łącznik (connector).

Nie będę pokazywał na to zrobić. Łatwo znaleźć instrukcje. Będziemy po prostu potrzebowali unikalnego adresu URL, na który można wysyłać wiadomości na kanał w MS Teams.

Zakładam, że to mamy.

I po stronie AWS

Temat wydaje się dość skomplikowany. Pewnie będzie potrzebne jakieś programowanie. Otóż nie. Nie napiszemy ani jednej linijki kodu. Wszystko co będzie potrzebne zapewni nam AWS. Skorzystamy z dostępnych serwisów, które tylko odpowiednio skonfigurujemy.

Skorzystamy z usługi EventBridge, która z jednej strony pozwoli nam podpiąć się pod zdarzenia z GuardDuty, a ponad to umożliwi nam wyłuskanie danych ze zdarzenia i wysłanie ich w odpowiednim formacie do MS Teams.

Pierwsze co powinniśmy utworzyć to tak zwana EventRule, czyli subskrypcja do określonych zdarzeń w środowisku AWS. Nas będą interesowały zdarzenia przesyłane przez GuardDuty. Będziemy więc szukali takich eventów.

EventPattern: {"source": ["aws.guardduty"],"detail-type": ["GuardDuty Finding"]}

EventBridge pozwala rozsyłać wiadomości do wielu różnych usług. Aby wysłać wiadomość na adres connectora MS Teams użyjemy API Destinations, które pojawiły się niedawno. Pisałem już o tym, zachęcam do lektury.

Aby utworzyć API Destination potrzebujemy zdefiniować tak zwane Connection:

EventRuleConnection:
  Type: AWS::Events::Connection
  Properties: 
    AuthorizationType: BASIC 
    AuthParameters: 
      BasicAuthParameters:

które wykorzystamy w samym API Destination:

EventRuleApiDestination:
  Type: AWS::Events::ApiDestination
  Properties: 
    ConnectionArn: !GetAtt EventRuleConnection.Arn
    HttpMethod: POST
    InvocationRateLimitPerSecond: 10
    InvocationEndpoint: !Ref TeamsWebHook

Jako adres url naszego webhooka Teams wykorzystamy parametr i jego wartość ustalimy przy tworzeniu stacka.

Błędy, błędy, błędy

Teoretycznie w tym momencie wiadomości z GuardDuty zostaną przesłane do naszych MS Teams. Jednak niestety nie zostaną one wyświetlone. MS Teams, jak można się tego spodziewać, wymaga odpowiednich danych.  Zanim przejdziemy do formatowania danych, dodajmy do naszego stacka kolejkę na błędy (Dead Letter Queue)

DeadLetterQueue:
    Type: AWS::SQS::Queue

oraz przypiszmy ją do naszego targetu w Event Rule

GuardDutyEventRule:
  Type: AWS::Events::Rule
  Properties: 
    Targets:
      - Arn: !GetAtt EventRuleApiDestination.Arn
        ...
        DeadLetterConfig:
            Arn: !GetAtt DeadLetterQueue.Arn

Pozwoli nam to, w przypadku wystąpienia błędu na podejrzenie wiadomości wysyłanej przez API Destination

i sprawdzenie błędu, który spowodował problem.

Formatujemy wiadomości

Event Grid ma między innymi możliwość utworzenia wiadomości na podstawie danych, które zostały do niego przekazane. Służy do tego tak zwany InputTransformer. Więcej o tym możecie poczytać tutaj. To co my zrobimy, to wyłuskamy z wiadomości przesłanej z GuardDuty tytuł, id konta AWS oraz opis

InputPathsMap:
 title: $.detail.title
 account: $.detail.accountId
 description: $.detail.description

i użyjemy tych danych podczas tworzenia paylodu wysyłanego do MS Teams.

InputTransformer:
 InputTemplate: >
 {
  "themeColor": "FFA500",
  "title": <title>,
  "text": "Account: <account> Finding <description>"
 }

Dodatkowo, ustawimy kolor na pomarańczowy.

Testujemy

Aby wygenerować przykładowe zdarzenia (findings) w GardDuty w zakładce Settings klikamy w Generate sample findings

i po chwili powinno się pojawić kilkanaście testowych naruszeń

a po następnych kilku chwilach (pamiętajcie, jedna chwila to trzy momenty ;-), to nie nastąpi natychmiast) powinniście dostać powiadomienia w Teamsach.

Jeżeli coś pójdzie nie tak, sprawdźcie w pierwszej kolejności kolejkę DLQ.

A co ze Slackiem?

Nie ma oczywiście problemu, aby zamiast MS Teams użyć Slacka. Musimy podać oczywiście jako parametr przy tworzeniu stacka url go webhooka slackowego i zmienić format przesyłanych danych

InputTemplate: >
{
   "text": "Account: <account> Finding title <title> and description <description>"
}

To tyle.

Podsumowanie

Chmura publiczna pozwala na zautomatyzowanie prawie wszystkiego. Bardzo ważne jest to w przypadku bezpieczeństwa. Wyobraźcie sobie, ze macie kilkadziesiąt lub więcej kont AWS i próbujecie to ogarnąć ręcznie. Będzie to praktycznie niemożliwe.

Automatyczne reagowanie na zdarzenia i zagrożenia jest czymś o czym, myślę, powinniśmy pomyśleć i wdrożyć na naszych kontach.

Oczywiście Amazon EventBridge możemy wykorzystać na wiele innych sposobów, tu pokazałem jeden z nich. I to nie najważniejszy.

Przykładowy tempate dostępny jest na moim GitHub-ie.