Pomyślałem, że opiszę tutaj krok po kroku, jak postawić trzywęzłowy klaster Hashicorpowego Vaulta, który w swojej strukturze może przypominać coś produkcyjnego. Oczywiście, można by tu pokusić się o coś bardziej “fancy & jazzy” – całą rolę w Ansible’u – ale jeśli ktoś zabiera się za to po raz pierwszy, lepiej żeby zrozumiał, jak to naprawdę działa. A najlepiej przebrnąć przez tę ścieżkę zdrowia samodzielnie, palce na klawiaturze, krok za krokiem. Mój własny wpis o tym, jak stawiać całe trio – Vault, Consul, Nomad – też już trochę się zestarzał. Ale zaglądałem tam niedawno i muszę przyznać, że wciąż można coś z tego wyciągnąć.

Czego nam potrzeba?

Nic wielkiego, wystarczy jakis Linux z libvirtd i trzema gołymi VMkami, może być Ubuntu, może być Debian.

Architektura

1. Klaster HA, jeden leader + dwóch voters. Klaster jest demokratyczny i wybiera sobie lidera przez głosowanie. Aczkolwiek tego pierwszego trzeba liderem zrobić, by pozostałe miało do kogo radośnie dołączyć, formując klaster.
2. Do tego, by było łatwiej mamy osobnego vaulta przydatnego jako transit-unseal. Będzie udawał AWSowego KMSa. Przydatność polega na tym, że po każdym restarcie nie trzeba uparcie wklepywać 2-3 z pięciu kluczy by “odpieczętować” instancję. Bowiem każda instancja ma specjalny token, którym uwierzytelni się u tego osobnego vaulta, a tamten je automagicznie “odpieczętuje”.

Jeśli rozdział zawiera rozwiązanie jakiegoś problemu w sposób programistyczny, to wypada również podejść do takiego problemu samodzielnie i znaleźć rozwiązanie w ten czy inny sposób. Więc czasem robi się z tego wielomiesięczne studium. Tak było w przypadku “How to measure anything in cybersecurity”, tak jest też w przypadku “The Metrics Manifesto”. Tę drugą właśnie studiuję, wciąż wracając do tej pierwszej.

“We confuse what’s easy to measure, like bullet holes in returned planes, with what is important to measure, like bullet holes in downed planes. We deceive ourselves by measuring only what is obvious, forgetting the goal of our measurement” [R. Seiersen, “The Metrics Manifesto”]

Metryki bezpieczeństwa powinny odpowiadać na całkiem zasadnicze pytania, które zadaje sobie (chyba prawie) każdy odpowiedzialny kierownik czy ekspert dziedzinowy, a także stanowić dane wejściowe do szacowania ryzyka w danym obszarze cyberbezpieczeństwa.

Zamiast liczyć ileż to podatności zostało załatanych miesiąc do miesiąca, czy rok do roku - bo to są tylko metryki logistyczne na zasadzie - tyle a tyle cementu dowieziono - można zadać sobie pytanie: ile średnio, każdego dnia w roku mam niepołatanych podatności o istotności krytycznej w obszarze kluczowych aplikacji. Albo zamiast liczb ile rozwiązano incydentów, jaki jest trend współczynnika incydentów rozwiązanych do nierozwiązanych w podziale na aplikacje czy obszary (np. on-prem vs cloud). Czy też, na podstawie danych z przeprowadzonych testów, oszacować ryzyko phishingu - czyli jaką procentową szanse możemy założyć, że na 1000 wysłanych emaili ileś osób jednak kliknie i obserwować ten trend miesiąc do miesiąca. To można robić i to w całkiem zautomatyzowany sposób. Wystarczą dane, python (albo R) i trochę umiejętności grzebania w danych.

Okazuje się, że naprawdę nie trzeba petabajtów danych, aby przygotować ciekawe metryki. Wystarczy prosty raport z wykrytych i usuniętych podatności w jakimś okresie.

Instalacja Jupytera

Dopóki nie spróbowałem, nie miałem pojęcia jakie to przydatne narzędzie w analityce danych. Środowisko Pythona mam już skonfigurowane z pipenv (łączy w sobie wygodę pip i venv). W danym katalogu projektowym odpalamy pipenv shell i wykonujemy:

$ pipenv install jupyter jupyterlab ipykernel
$ pipenv install numpy scipy pandas seaborn statsmodel scikit
$ python -m ipykernel install --user --name=metrics
$ pipenv run jupyter lab

W nowej zakładce przeglądarki uruchomi się UI Jupyter lab, gdzie należy wybrać kernel - metrics z uprzednio zainstalowanymi bibliotekami. Jeśli jednak jakiejś zabraknie to w linii kodu wystarczy wykonać !pipenv install <brakująca_biblioteka>.

Nieco teorii - tabele przeżycia

Zwane również tabelami trwania życia. Naturalnym skojarzeniem jest od razu ZUS. Nam chodzi o coś innego. Zbadanie rozkładu okresów jakie upływają między danymi zdarzeniami. Na przykład, między pojawieniem się podatności a jej usunięciem. Więc zdarzeniem terminalnym jest tu usunięcie podatności. Celem tabeli jest pomiar szans na przeżycie podatności w danym okresie albo inaczej - wyliczenie prawdopodobieństwa wystąpienia zdarzenia usunięcia podatności w danym okresie. W tym kontekście upraszczając: podatność jest procesem, który wystąpił (data wykrycia) i który mógł zostać przerwany (terminacja, śmierć) przez usunięcie (załatanie podatności, podbicie wersji biblioteki itd.).

Kiedy już wyznaczymy sobie interwał czasowy, w którym chcemy złapać wszystkie zdarzenia wystąpienia podatności i jej usunięcia, musimy wykonać jeszcze dwie czynności - odfiltrować zdarzenia które:

• zaczęły się ale nie skończyły w przyjętym interwale czasowym - ocenzurowane,
• zaczęły się w dniu prawej granicy interwału albo po tym dniu - odrzucone.

Przykład poniżej, przypuśćmy że badamy sobie raport z pierwszej połowy roku, gdzie mamy 8 podatności. V1, V2 i V7 cenzurujemy a V8 odrzucamy.

Python i estymator

Ładujemy plik CSV z raportem podatności do DataFrame:

1
2
3
 
!wget https://raw.githubusercontent.com/ribsy/mdata/main/tmm_start.csv
 

Nagłówki w pliku CSV stają się nazwami kolumn w DataFrame, w naszym przypadku musimy lekko skorygować te nazwy zamieniając kropki na znak podkreślenia.

1
2
3
4
5
 
import pandas as pd
df = pd.read_csv('tmm_start.csv')
df.rename(columns = {'first.seen':'first_seen', 'last.seen':'last_seen', }, inplace = True
 

Nasza tabela nie zawiera jeszcze dwóch kolumn istotnych dla naszej analizy. Jedna to okres występowania podatności (czyli last_seen - first_seen) i status podatności - Ok, czy ocenzurowana. Pierwsza linijka kodu wylicza nam deltę dla każdej wartości kolumn last_seen i first_seen, druga linijka zmienia nam tę deltę na liczbę dni i pakuje do nowej kolumny o nazwie delta. A trzecia linijka sprawdza czy daną podatność trzeba ocenzurować i w zależności od tego w kolumnie status pakując tam 0 lub 1. W ostatniej linii filtrujemy sobie dane i pakujemy je do nowej tabeli DataFrame.

1
2
3
4
5
6
7
8
9
 
from datetime import datetime as dt
from datetime import timedelta

delta = [(dt.strptime(stop,"%Y-%m-%d") - dt.strptime(start,"%Y-%m-%d"))+timedelta(days=1) for start, stop in zip(df['first_seen'],df['last_seen'])]
df['delta'] = [x.days for x in delta]
df['status'] = [1 if (dt.strptime(stop,"%Y-%m-%d") < dt.strptime('2020-12-31',"%Y-%m-%d")) else 0 for stop in df['last_seen']]
df_flt = df[(df.idTeam == 1) & (df.group == 1) & (pd.to_datetime(df.first_seen) <= pd.to_datetime('2020-10-01'))]
 

I to właściwie tyle. Dane mamy przygotowane. Teraz wykorzystamy je do (wyliczenia i przedstawienia graficznego) odpowiedzi na pytanie: jaka liczba podatności zostaje usunięta po X dniach z wyliczonym prawdopodobieństwem. Do tego celu użyty został estymator Kaplana Meiera. Estymator ten prognozuje funkcję przeżycia danej frakcji (podzbioru) podatności.

Na początku, zdefiniowałem dwa kryteria (dwie frakcje - podatności krytyczne i high), a potem już poszło sprawnie. Wywołanie objektu KaplanMeierFitter() i zastosowanie metody fit gdzie podałem wyliczoną deltę i status dla każdego wiersza naszej tabeli df_flt.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
import datetime
from lifelines import KaplanMeierFitter
import matplotlib.pyplot as plt

critical =  ((df_flt.severity == 'extreme') | (df_flt.severity == 'critical'))
high = (df_flt.severity == 'high')
ax = plt.subplot()
kmf = KaplanMeierFitter()
kmf.fit(durations=df_flt[critical].delta, event_observed=df_flt[critical].status, label='Critical vulns')
kmf.plot_survival_function(ax=ax)
kmf.fit(durations=df_flt[high].delta, event_observed=df_flt[high].status, label='High vulns')
kmf.plot_survival_function(ax=ax)
plt.title('Vulns survivability based on their relevancy')
plt.show()
 

Jaką informację mamy zawartą na powyższym wykresie (oś x - liczba dni, oś y - % liczby zdarzeń)? A taką że - w zadanym okresie:

• Podatności krytyczne są szybciej usuwane niż te o statusie High (to dobrze, ale nie zawsze jest oczywiste),
• Srednio 50% usuwanych podatności krytycznych jest usuwana po ok. 23-29 dniach a High po 58-62 dniach,

Mając różne atrybuty podatności w raporcie, w rodzaju: która aplikacja, który zespół, itd. możemy te podatności badać w rozbiciu na różne podzbiory (frakcje). Poniżej, przykład podobny do pierwszego, ale niosący dodatkową informację jak sobie różne zespoły radzą z usuwaniem podatności:

Warto zauważyć, że im więcej danych, tym przedziały wiarygodności, będa węższe a więc nasze prognozy - trafniejsze. I to tyle na razie. Poza tym można podobną analizę zastosować do zidentyfikowanych zagrożeń, obsługi incydentów bezpieczeństwa, z badaniem czy SLA są dotrzymane itd. Całość kodu w Jupyter notebook

Bibliografia:

• “The Metrics Manifesto”
• “Manipulating DataFrames with pandas”
• “Plotting Kaplan-Meier survival curves”

Jestem zadowolony z treści i formy tamtych wpisów, ale to jeszcze nie było to. To “to” właśnie się zmaterializowało. A wszystko zaczęło się od intensywnego kursu przypominania sobie i rozwijania Pythona świetnie opracowanego i prowadzonego przez wykładowców uniwersytetu stanowego w Michigan. Python jest mi potrzebny do paru innych rzeczy, więc połowę tego kursu połknąłem w tydzień. Zacząłem sobie wymyślać jakieś przydatne i praktyczne juzkejsy. I nagle.. “hello! ..I am here!” Zawołała do mnie z półki moja ulubiona zielona książka, machając przy tym swoimi małymi zielonymi łapkami. “I am your goddamn usecase!” wrzasnęła..

Czym innym jest opowiadać na lewo i prawo jak świetną książkę napisali panowie Hubbard i Seiersen, a czym innym zupełnie zademonstrować jak działa ilościowa metoda szacowania ryzyka w cyberbezpieczeństwie (ale nie tylko). Przed kontynuacją czytania tego wpisu, polecam przypomnieć sobie poprzednie wpisy, od tygrysów, przez rury po Bayesa. Sam tak właśnie zrobiłem. Ważny jest kontekst. Przedstawiona tutaj ilościowa metoda analizy ryzyka opiera się na rachunku prawdopodobieństwa, zwykłej prostej algebrze z odrobiną statystyki. Od tego jest właśnie rachunek prawdopodobieństwa i statystyka aby nasze estymacje dotyczące oceny szans czy możliwości materializacji ryzyka (czyli oddziaływania jakichś zidentyfikowanych i opisanych zagrożeń) w naszych niedoskonałych i podatnych na owe zagrożenia (nie na ryzyka!!!) systemach IT.

Właściwa estymacja powinna opierać się na danych, tych które mamy w firmie, bądź takich do których możemy dotrzeć w internecie (chociażby coroczny raport Verizona). Nasze zdarzenia zagrożeń, mogą być też bezpośrednim wynikiem zastosowania metodyki MITRE ATT&CK lub chociażby STRIDE (dla jakiegoś projektu rozwiązania). Do tego odpowiednio dobrane grono ekspertów powinno samodzielnie i osobno popracować nad estymacją listy takich zdarzeń. Dlaczego osobno? Otóż dlatego, że jako stworki stadne, leniwe i sprytne, mamy wpływ na innych w takim sam sposób jak inni mają wpływ na nas. Na przykład dla świętego spokoju czy też z niemania-i-niechcenia-mania-pojęcia po prostu zgodzimy się z innymi na takiej nasiadówie, byleby tylko ją szybko skończyć w poczucie dobrze odwalonej pracy. Ale ok, żarty na bok. Chodzi o to by łatwiej zidentyfikować i uzasadnić ewentualne rozbieżności przy wynikach estymacji dla konkretnych osób. Pamietamy, że nasze mózgi mają swoje ograniczenia gatunkowe. Szybkie myślenie, problemy z prawdopodobieństwem jako takim, intuicja, zakotwiczenie, zbytnia pewność siebie, itd. Czy już mówiłem? polecam tę zieloną książkę.. i parę innych (wymienionych we wpisach na tym blogu.

Mamy więc listę dziesięciu zdarzeń, których P wyestymowaliśmy, biorąc pod uwagę rozmaite dane własne, raporty i statystyki dostępne z internetu, następnie wykonany rachunek Bayesa, wyniki porównane z innymi. Dotyczy to również przedziału strat. Konkretnie parametryzujemy sobie takie zdarzenie, przydzielając mu określone P w ciągu roku (12 miesięcy), oraz przedział możliwych strat z 90% poziomem ufności.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
events = {
    "event1": (0.21, 100000, 550000, "Successful DDoS on the cloud base core app"),
    "event2": (0.08, 500000, 1500000, "Sensitive data exfiltration"),
    "event3": (0.15, 200000, 1000000, "Malicious code injected into production pipeline"),
    "event4": (0.38, 10000, 100000, "Laptop with sensitive data lost/stolen"),
    "event5": (0.17, 15000, 50000, "Malicious code in 3rd party dependencies"),
    "event6": (0.15, 1000, 150000, "Broken backups"),
    "event7": (0.04, 1000000, 12000000, "Malware attack, knocked out internal network"),
    "event8": (0.05, 10000, 500000, "Insider's threat"),
    "event9": (0.03, 1000000, 11500000, "Terrorist attack"),
    "event10": (0.25, 5000, 50000, "Broken app release")
}
 

Mamy również oszacowany mityczny “apetyt na ryzyko” czy też “tolerancję na ryzyko” po dłuższej dyskusji z naszymi “finansowymi”. Rozkład ewentualnych strat z oszacowanym prawdopodobieństwem wystąpienia w przeciągu 12 miesięcy. Wiadomo, małe straty to wyższa akceptacja dla ich wystąpienia, wysokie straty to niższa i bardzo niska. Czyli nieakceptowalna. Ten krok jest nie mniej ważny od poprzedniego.

1
2
3
4
5
6
7
8
9
10
 
risk_tolerance = [
    (100000, 90), 
    (250000, 50), 
    (500000, 30), 
    (750000, 15), 
    (1000000, 2), 
    (10000000, 0.2)
]
 

Do kompletu naszych danych wejściowych potrzebujemy jeszcze listę ewentualnych wdrożeń z dziedziny bezpieczeństwa i cyberbezpieczeństwa. Mogą to być działania planowane, nie-planowane. Idzie o to aby pokazać jak nakłady na tę dziedzinę ponoszone przez firmę wpływają na szanse wystąpienia różnych ryzyk. Albowiem właśnie po to są wdrożenia w cyberbezpieczeństwie. Warto więc sprawdzić czy coś dają. Tutaj pod ten konkretny przykład utworzyłem listę 1-do-1 ze zdarzeniami zagrożeń. Możemy to jednak przedstawiać w różnej formie, a potem w kodzie odpowiednio warunkując. Np. Wdrożenia ABC dotyczy zdarzeń: 1,3,4,7 dla każdego estymujemy że wpływ na wystąpienie spadnie o dany % (to ta druga liczba w krotce poniżej, pierwszą jest symulowana wartość inwestycji w cyberbezpieczeństwo).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
sec_controls = {
    "event1": (70000, 0.65),
    "event2": (200000, 0.55),
    "event3": (77000, 0.7),
    "event4": (30000, 0.37),
    "event5": (25000, 0.42),
    "event6": (100000, 0.62),
    "event7": (230000, 0.85),
    "event8": (121000, 0.47),
    "event9": (130000, 0.6),
    "event10": (25000, 0.45)
}
 

Nasz wehikuł metodyczny nabiera prędkości. Przed Państwem - Monte Carlo! Metoda Monte Carlo jest szeroko stosowana w zarządzaniu ryzykiem w wielu obszarach - finansowym, wydobywczym, wszędzie tam gdzie zamiast “best educated guess” panuje logika, matematyka i dbałość o własne pieniądze. Skąd się wzięła? Wymyślił ją wielki polski matematyk Stanisław Ulam. Był chory i stawiał z nudów jakiegoś trudnego pasjansa. Wtedy zdał sobie sprawę, że bardzo trudno byłoby obliczyć, jakie było prawdopodobieństwo powodzenia tego pasjansa. Natomiast w miarę łatwo, jak sądził, można by było zamodelować to z pomocą komputera. Taki komputer który mógłby przeprowadzić bardzo wiele prób, dzięki czemu można by zaobserwować rozkład prawdopodobieństwa powodzenia pasjansa. Ponoć nazwa wzięła się ze skojarzenia z wujem profesora Ulama, który zwykł pożyczać pieniądze od rodziny, po czym radośnie przepuszczać je właśnie w Monte Carlo.

Metoda ta posłuży tutaj do zamodelowania rozkładu prawdopodobieństwa wystąpienia zdarzenia i związanej z nim straty. Posługując się generatorem losowym Pythona i metodą Monte Carlo sprawdzimy 10 tysięcy razy dla tych 10 zdarzeń (każdy), czy zdarzenie wystąpi, a jeśli tak to z jaką losowo wygenerowaną stratą z przedziału. Jeśli zdarzenie nie wystąpi, strata wynosi 0. Mamy już jeden rozkład, który stanowi dla nas niejako benchmark dla porównania z naszymi wynikami - nasza “tolerancja na ryzyko”. Zakres strat przypisany do każdego zdarzenia nie będzie zamodelowany rozkładem normalnym - czyli takim, gdzie najprawdopodobniej strata losowa wypadnie nam gdzieś po środku przedziału. Będzie zamodelowana rozkładem logarytmicznie normalnym (log-normalnym). A to taki rozkład, gdzie najbardziej prawdopodobne liczby z naszego przedziału wyskakują bardziej przy jego początku i są mniej prawdopodobne przy końcu takiego przedziału. Dlaczego tak? Weźmy pod uwagę naturę incydentów czy zdarzeń w obszarze cyberbezpieczeństwa. Jest to statystycznie pewne - że występuje daleko więcej zdarzeń o małej bądź nawet znikomej wartości strat, od zdarzeń których konsekwencje są znaczne albo nawet katastrofalne. Stąd asymetria kształtu względem rozkładu normalnego. Ponad to, wartości występujące w tym rozkładzie mogą być tylko równe lub większe od zera.

Jeśli zdarzenie zaistniało w naszej symulacji to wyliczamy medianę i odchylenie standardowe i zwracamy wartość straty wygenerowanej losowo dla tak sparametryzowanego rozkładu.

1
2
3
4
5
6
7
8
 
def threat_event_loss(lower_bnd, upper_bnd):
    """If threat event occured, let's get its loss it inflicts,
    given lower and upper bounds of 90% CI"""
    mean = (np.log(lower_bnd) + np.log(upper_bnd))/2
    std_deviation = (np.log(upper_bnd) - np.log(lower_bnd))/3.29
    return round(float(np.random.lognormal(mean, std_deviation)),2)
 

I tak postępujemy 10 tysięcy razy dla całej listy naszych zdarzeń. Zwrotnie dostaniemy dystrybucję takich strat na wykresie:

Tak samo postępujemy z wariantem, w którym scenariusze naszych przypadków kompensowane są naszymi inwestycjami w cyberbezpieczeństwo z oszacowanym wpływem na wystąpienie zdarzenia.

Już na pierwszy rzut oka widać, że dystrybucja i gęstość zdarzeń ze stratami jest mniejsza niż bez środków kompensujących.

Jedna rzecz, którą warto mieć na uwadze wprowadzając estymaty zakresu strat dla zdarzeń. Jeśli przyjmiemy zakres gdzie jego dolna wartość będzie o rzędy wielkości mniejsza od górnej wartości to możemy dostać dość nierealne wygenerowane wartości. Trzymajmy się zasady że maksymalna różnica to jeden rząd wielkości. Np. 10 tys. do 100 tys.

Funkcje loss_distribution i loss_distribution_reduced zapewniły nam dystrybucje strat i wygenerowały dane wejściowe (w postaci listy list kolejnych prób) do wygenerowania krzywej strat w funkcji prawdopodobieństwa.

To ten kawałek kodu w sekcji #run:

1
2
3
4
 
losses_no_ctrls = loss_distribution(events, NO_SIMULATIONS)
losses_with_ctrls = loss_distribution_reduced(events, sec_controls, NO_SIMULATIONS)
 

Te zmienne stają się argumentem dla wywołania funkcji generującej odpowiednio: wykres dla strat bez kompensacji i z kompensacją:

1
2
3
4
 
plot_loss_exceedance(loss_exceedance_curve(losses_no_ctrls, STEP), risk_tolerance, "Fig-3.png")
plot_loss_exceedance(loss_exceedance_curve(losses_with_ctrls, STEP), risk_tolerance, "Fig-4.png")
 

Dodatkowo w wyniku otrzymujemy wartości średniej oczekiwanej straty dla obu wariantów i nakłady finansowe na program komensacji tych ryzyk:

(python-exercises) 18:51:25:[python-exercises/distros] >> python3 cyberrisk_sim_multi.py
Average loss: 558,023.05 EUR with no controls in place
Average loss: 175,437.74 EUR with controls in place
Total security investments: 1,008,000.00 EUR

Na podstawie takich wyników można wysnuć całkiem konkretne wnioski. Na przykład:

1. W wyniku nakładów w wysokości ~1mln EUR średnia oczekiwana strata spada nam mniej więcej 2.5 krotnie w ciągu roku. Przy czym prawdopodobieństwo jej wystąpienia spada dwukrotnie (z ok. 40% do ok. 20% - patrząc na wykresy 3 i 4)
2. W wyniku tychże nakładów nasze ryzyka mieszczą się w założonej tolerancji na ryzyko, gdzie bez tych nakładów, straty powyżej 1 mln EUR są powyżej założonej tolerancji (wykres 3).
3. Widać, że po wdrożonym programie kompensacji ryzyk, nawet te straty o niskiej wartości są mniej prawdopodobne o ok. połowę.
4. Widać wyraźnie, że powinniśmy się skupić na zagrożeniach i podatnościach w naszym IT, które moga przynieść bardzo wysokie straty, pomimo niskiej szansy ich wystąpienia.
5. Widać wreszcie, jak można zamodelować koszty w bezpieczeństwie i bez ich wydawania, po prostu wspomóc efektywniejsze planowanie.

Podsumowując, analiza ilościowa bazująca na faktach, przy możliwie poprawnej estymacji, biorąc pod uwagę fakty i przetwarzając to logicznie i matematycznie, da nam wiele równie konkretnych i pomocnych odpowiedzi, których nie da nam żadna najbardziej kolorowa heatmapa. Kluczową sprawą jest tutaj jakość estymacji.

Kod nie jest ani finezyjny ani optymalny, ale działa. Będę jeszcze nad nim pracował, rozwijał. Pewnie jak się douczę modułu pandas będę mógł z tym zrobić o wiele więcej i pewnie szybciej. Przedstawioną metodę, można też rozwinąć dodając rachunek Bayesa i zdarzenia zależne - jeśli event1 zaistniał to event3 jest bardziej prawdopodobny, bo otwiera możliwość ataku z wielu kierunków. Ogólnie rzecz biorąc, temat nie jest łatwy i trzeba mu poświecić sporo uwagi i czasu. Aczkolwiek jeśli pracownikom pytającym o bonus roczny, nie odpowiadamy, że dostaną między MEDIUM a MEDIUM-LOW ..to może tez warto przestać odpowiadać tak kierownictwu w kwestii ryzyka i strat? :)

Terraform i Vault

W Vaulcie trzymam kredki dla AWSa (iam_user). Backup (snapshot) magazynu danych Vaulta leci na szyfrowany dysk. Załatwia to Consul, który serwuje Vaultowi rozproszony storage - RAFTem po HTTPSie (co prawda to rozproszenie jest trochę symulowane - bo jak szlag trafi NUC-a to i moją wirtualną sieć i VMki). Ale zostanie mi dysk :)

Sprawa jest prosta - w Vaulcie wrzucam kredki do kv/aws i kv/terraform (o czym za chwilę). A potem każę terraformowi, je sobie pobrać wykorzystując terraformowe źródło danych vault_generic_secret a potem kojarząc z dostawcą.

providers.tf:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
data "vault_generic_secret" "tf_token" {
  path = "kv/terraform"
}

data "vault_generic_secret" "aws_creds" {
  path = "kv/aws"
}

provider "aws" {
  region  = data.vault_generic_secret.aws_creds.data["DEFAULT_REGION"]
  access_key = data.vault_generic_secret.aws_creds.data["AWS_ACCESS_KEY_ID"]
  secret_key = data.vault_generic_secret.aws_creds.data["AWS_SECRET_ACCESS_KEY"]
}

provider "consul" {
  token = data.vault_generic_secret.tf_token.data["access_token"]
} 
 

Terraform i Consul

Pliki stanu terraforma pakuję do Consula. Tenże robi za backend dla terraforma. A konkretnie to za backendowy key-value store. Ale taki pojemniejszy niż Vault. Za to bez szyfrowania at-rest. Co prawda padła propozycja, by Vault stał się takim właściwym backendem, póki co jednak Hashicorp nie rozważa takiej ścieżki rozwoju.

Tutaj też, konfiguracja jest dość prosta i szybka. Po skonfigurowaniu backend.tf i wykonaniu komendy terraform init, terraform zapyta o migrację i zamelduje wykonanie zadania. Poniżej kawałek “meldunku”:

$ terraform init

Initializing the backend...
Do you want to copy existing state to the new backend?
  Pre-existing state was found while migrating the previous "local" backend to the
  newly configured "consul" backend. No existing state was found in the newly
  configured "consul" backend. Do you want to copy this state to the new "consul"
  backend? Enter "yes" to copy and "no" to start with an empty state.

  Enter a value: yes


Successfully configured the backend "consul"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Reusing previous version of hashicorp/vault from the dependency lock file
[..]

a brakującym kawałkiem układanki jest ten oto backend.tf:

1
2
3
4
5
6
7
8
9
10
11
 
terraform {
  backend "consul" {
    address      = "powernukeint.nukelab.home:8501"
    scheme       = "https"
    path         = "terraform/aws/project1/terraform.tfstate"
    lock         = true
    gzip         = false
  }
}
 

Brakuje tu jednej linijki z tokenem. Ta jest jednak niepotrzebna, bo temat załatwia zdefiniowane źródło danych w Vaulcie. No i sobie to tak działa. Tym sposobem unikamy nawet przypadkowej publikacji plików stanu w repozytorium i namnażania tych plików w lokalnym systemie plików. Consul i Vault mają kontrolę dostępu. No i jeden i drugi jest dostępny przez odpowiedni token. Vault - źródło danych uwierzytelniających, Consul - w miarę bezpieczna przechowalnia plików stanu.

Na obrazku widzimy prosty algorytm postępowania z MITRE ATT&CK aby odpowiedzieć sobie na pytanie, co zrobić by być bezpiecznym przed konkretnym profilem zagrożeń. Nie jest to jakiś złoty środek na wszystko. Przez przypadek, domowe IoT stało się po prostu wdzięcznym przykładem dla przedstawienia tej metodyki, w miarę zwięzły sposób. Przy poważniejszych projektach, należy zabrać się jeszcze za szacowanie pracochłonności, kosztów, zasobów. Przemyśleć i oszacować wpływ na operacje i utrzymanie. Najważniejsze jednak, że mamy logiczną i spójną odpowiedź - DLACZEGO chcemy takiego wdrożenia. Bowiem jest to metodyka, którą można (i chyba nawet powinno się) stosować przy projektach cyberbezpieczeństwa. Tak by nie strzelać na ślepo, nie próbować interpretować kolorowych nonsensownych HEATMAP albo też wierzyć tylko “sejlsom”, po iluś spotkaniach (“masowania klienta”, jak to oni mówią), że teraz to już będzie dobrze.

Analityka

Przeglądając zaznaczone w poprzednim wpisie techniki w mapowaniu MITRE, uznałem, że nieco się rozpędziłem. Zawsze przyda się drugie spojrzenie i weryfikacja. Zatem według tego “drugiego spojrzenia” nasi potencjalni złoczyńcy (wg scenariuszy nakreślonych w poprzednim wpisie) mogliby posłużyć się takimi oto technikami:

A skąd akurat te, a nie inne? Pamiętajmy, że rozpatrujemy konkretne scenariusze zagrożeń, których celem jest nasza domowa instalacja IoT. Wobec tego tzw. powierzchnia ataku jest już znacznie bardziej ograniczona niż jakieś złożone systemy automatyki przemysłowej w przemyśle motoryzacyjnym czy przetwórstwa żywności (i napojów..). Przy rozpatrywaniu takich czy innych technik, nalezy też mieć na uwadze nie tylko szanse powodzenia takich technik, ale i szanse ich wystąpienia. Czyli szanse, że taki złoczyńca się pojawi, a jego zamiary będą mu się opłacać. Tym bardziej, że Shodan.io jest dość bezlitosny dla beztroskich entuzjastów IoT i Tasmoty.

I z tego punktu widzenia, taktyka “Initial Access“ czyli możliwość znalezienia punktu zaczepienia do dalszego postępowania w ataku praktycznie, przy naszych scenariuszach ograniczyć może się do max. trzech możliwości:

• “External Remote Services” - opis tej techniki może sugerować np. taką możliwość, iż istnieje jakiś portal, który poprzez SEO przyciąga uwagę amatorów Tasmoty, tam czai się już skrypt w zwykłym PHP, który wykona się na laptopie takiego amatora i sobie ładnie wypróbkuje sieć na obecność urządzeń z dostępem bez ustawionego hasła, bądź “admin/admin”. Jak włamywacz będzie miał więcej szczęścia, a entuzjasta bardziej niefrasobliwy, to od razu tamten podgra temu swój firmware. Przypadek opisany w issues na Githubie dla Tasmoty;
• “Supply Chain Attack” - ten przypadek już pokrótce opisałem w poprzednim wpisie, kupujemy sobie gniazdko z jakiegoś “tańszego” źródła, gdzie cena jest po prostu haczykiem lub wykonujemy aktualizację nie bacząc na źródło pochodzenia binarki;
• “Wireless Compromise” - i ten przypadek jest najbardziej prawdopodobny. I nieszczególnie też trudny do realizacji. Sposoby przechwytywania i łamania haszy przy wymianie komunikacji uwierzytelniającej klienta z Access Pointem są opisane na 950 tysięcy sposobów w Internecie, krok po kroku z komendami i przykładami. Wystarczy mieć laptopa z WiFi, resztę zrobi aircrack-ng nawet z tutoriali.

W taktyce “Execution“ - nie, to jeszcze nie egzekucja - mamy techniki, które pozwolą cyberzbójcerzom zacząć mościć sobie wygodne gniazdko w gniazdkach naszej sieci. O ile, oczywiście nie jest to atak jednorazowy bez specjalnie wielkich planów na przyszłość. Tasmota charakteryzuje się tym, że jak na swoje 630kB ma i WebUI z funkcjonalnością konsoli, wystawia API do którego również możemy wysłać zdalnie komendy dla urządzenia. Wisienką jest możliwość sterowania urządzeniem przez tematy MQTT (ang. topics), na przykład wysyłając urządzeniu na jego właściwy temat komendę resetu hasła do “admin/admin”:

• “Command-Line Interface”;
• “Native API”.

Zastosowanie technik z taktyki “Persistence“ pozwoli natomiast cyberzbójcerzom albo na dłuższy niedostrzeżony pobyt w naszym IoT albo też na bezpieczne (dla nich) powroty w chwili gdy uznają, że mają w naszym IoT jeszcze coś do załatwienia. Tutaj wybrałem dwie techniki, możliwe do wykorzystania, skoro już udało się na samym początku, a więc:

• “Hardcoded Credentials” - Tasmota ma fabrycznie ustawionego użytkownika “admin”, zostaje albo odgadnąć hasło albo je zmienić na “admin”. O ile mnie własne testy nie mylą, to Tasmota pozostaje niewzruszona na brute-force-ową zgadywankę. Przy czym, może się okazać, że hasło jest takie samo dla wszystkich urządzeń. Ja mam cztery takie gniazdka, ale ktoś może miec ich 140..
• “System Firmware” - tutaj, w kontekście naszych scenariuszy i przedmiotu ataku, mamy tę samą praktycznie technikę, jak przy “Supply Chain Attack”. Co nie musi być regułą w innych przypadkach.

Taktyka “Discovery“ posłuży atakującym na bliższe poznanie się z naszą zaatakowaną siecią, jej strukturą i innymi domownikami. O ile powiodły się poprzednie techniki, nasz złoczyńca ma do dyspozycji konsole, wszelkie ustawienia WiFi, IP, DNS, NTP, MQTT, itd. Jeśli nie mamy ustawionej polityki Network Isolation czy też wyłączonego forwarding chain na ruterze/WAP, to bardzo ułatwiamy robotę nieproszonym odkrywcom. Dlatego też, poniższe dwie techniki będa raczej pasować:

• “Network Connection Enumeration” - popatrzy w logi, popatrzy w konfigurację
• “Remote System Information Discovery” - ..i już będzie wiedział, gdzie co jest i gdzie warto sięgnąc, aby być może twórczo rozwinąć atak na inne potencjalnie ciekawe miejsca w naszej sieci.

Techniki z “Lateral Movement“ i “Inhibit Response Function“ praktycznie wykorzystują (w naszym przypadku) już zdobyte dostępy i uprawnienia. Chodzi o rozprzestrzenienie się po sieci, np. po odgadnięciu IP/nazw i tematów innych urządzeń, schemat dla jednego zapewne zadziała dla innego tylko np. trzeba zmienić numerek IP na kolejny i w nazwie ostatnią cyfrę. To samo dotyczy maskowania swojej obecności przez modyfikację parametrów odpowiedzi na jakieś zdarzenia rejestrowane przez urządzenia IoT.

Ostatnia z taktyk to nic innego jak próba doprowadzenia do opłacalnej monetyzacji tego ataku, więc otwarcie bramy, odwrócenie kamery, zamknięcie/otwarcia zaworu itd. A więc sprowadzenie na instalację, dom, domowników zagrożenia całkiem bezpośredniego. Uszkodzenie jakiejś instalacji przez zakłocenie działania funkcjonalności dbającej o bezpieczeństwo fizyczne instalacji sterowanej i dozorowanej przez IoT. Ostatecznie sięgnięcie po inne zasoby informatyczne domowników, na ile konfiguracja sieci na to pozwalała, a co zostało rozpoznane w fazie “Discovery”.

A co z pozostałymi fazami, które nie zostały tutaj ujęte na obrazku? Navigator ma fajną funkcjonalność ukrycia rzeczy, które nas nie interesują. Dla przejrzystości rozpatrywanego obrazka. Jak już wspomniałem na początku trzymamy się konkretnego kontekstu, pamiętając, iż ICS to znaaacznie, znaaacznie szersze pojęcie, niż najszersze IoT.

Obrona

Również pamiętamy, że każda rozpatrzona tutaj technika ma w metodyce ATT&CK zamapowane mechanizmy przeciwdziałania. Aczkolwiek, jesli je zacznę tutaj jedna po drugiej mapować po kolei, to wszyscy tu zaraz usną, wraz z autorem (późno już jest.). Ale tutaj nic szczególnie skomplikowanego się nie dzieje. Co robimy?

1. Mapujemy sobie nasze taktyki na mechanizmy przeciwdziałania (“Mitigation”) i detekcji (“Detection”).
2. Następnie oceniamy - wciąż trzymając się kontekstu - co jest w całości możliwe do zastosowania, w częsci, co można zastąpić innym mechanizmem, a co trzeba odpuscić zupełnie. Ocena taka powinna brać pod uwagę nie tylko to co umiemy, mamy pod ręką, jesteśmy się w stanie nauczyć, czy tez kupić. Należy przy tym antycypować utrzymanie takiego systemu, który i nam może się mocno rozrosnąć w swojej złożoności, kiedy zaczniemy dodawać do niego kolejne klocki. Np. zadając sobie pytanie - czy będziemy okresowo poświęcać dzień w miesiącu, by kompilować i testować nowy firmware, wraz z pojawieniem się nowej wersji bazowej, bądź kiedy pojawi się jakaś dziura (a taką informację też musimy monitorować subskrybując jakieś źródło informacji o podatnościach. A te będziemy sumiennie przeglądać.. i tak dalej). A może sobie tę kompilację firmware-u zautomatyzować? Ale! ale to też kosztuje..i tak dalej. O ile nie jesteśmy szurnięci na punkcie bezpieczeństwa i jednak skłonni nie budować fortecy zdolnej przeżyć jednoczesny atak kilkunastu APT i nalot B-52 naraz, tylko dlatego, że umiemy albo chcemy :)
3. A na koniec proponujemy sobie rozsądne i konkretne rozwiązania nie tylko nie zamieniającego naszego codziennego życie w utrzymanie naszych IoT, ale skutecznie utrudnią realizację niecnych planów, np. czyniąc takie realizacje nieopłacalnymi z punktu widzenia intencji włamywacza - np. szybki i duży zysk, minimalne szanse wykrycia - a komplikatory mają bezpośredni wpływ i na szanse wykrycia i na szybkość i wysokość zysku. Pewne sugestie co do zabezpieczeń w tekście niniejszego wpisu już padły.

Poniżej widać tabelkę z tak zmapowanymi propozycjami przeciwdziałania, dla każdej z technik. Jest to tylko próbka. Cała tabelka dostępna będzie tutaj.

Detekcja

Jeśli chodzi o możliwości wykrywania podejrzanych działań, w przypadku urządzeń z Tasmotą, można po skonfigurować logowanie zdarzeń i wysyłanie ich do zdalnego sysloga. Jeżeli mamy MQTT i brokera Mosquitto, można też skonfigurować logowanie zdarzeń na tym komponencie. Logowanie zdarzeń z urządzenia z Tasmotą obejmie nam zdarzenia prób logowania się do urządzenia, aktualizację firmware, włączenia, wyłączenia zmiany parametrów. Wiele więcej nie zrobimy. Tym bardziej, że samo wysyłanie logów nam niczego nie załatwi. Musielibyśmy “uzbroić” naszego konsumenta syslogowego w jakąś warstwę pozwalającą na reakcje na określone zdarzenia przez powiadamianie, alerty w dashboardzie itd.

Architektura

Po takiej analizie, można zabrać się za rozrysowanie sobie docelowej architektury, czy też topologii z naniesioną koncepcją obrony.

Do naszej (zakładam) istniejącej sieci z ruterem internetowym, który zapewnia nam w domu tez WiFi i jest odpowiednio już zabezpieczony dokładamy kolejny WAP (Wireless Access Point).Tenże WAP może być podłączony z naszym ruterem albo ethernetem albo też po WiFi. I na tym WAPie ustawiamy osobny WLAN, a komunikację zapewniamy odpowiednimi regułami firewalla i rutingiem. Odcinamy dostęp do internetu z tego WLANu. Podczas przeglądu możliwości Tasmoty natknąłem się na funkcjonalność wystawiania metryk dla Prometheusa. Tym samym można zredukować złożoność rozwiązania rejestracji pomiarów. Zamiast:

można zrobić to tak:

Tym samym wyłączamy kompletnie MQTT i możliwości z tym związane - czyli sterowanie urządzeniem poprzez komendy wysyłane do tematu MQTT (np. Publish <device_topic>/cmnd/WebPassword 0). Pozbawiamy się tym samym możliwości np. resetu hasła na urządzeniu, czy zdalnie wysłania aktualizacji firmware-u. Aczkolwiek, również potencjalny atakujący zostaje pozbawiony tych możliwości. Kluczowe przy obu rozwiązaniach monitoringu danych z urządzeń - są bakupy konfiguracji i przechowywanie haseł w bezpiecznym miejscu. Albowiem, jeśli hasło zostanie “zapomniane” to czeka nas twardy update firmware-u przez USB-UART i WebInstaller, bo przecież nie zalogujemy się do urządzenia by wykonać zmianę hasła, którego nie pamiętamy. Prócz tego, wciąż potrzebujemy udostępnienia trzech usług z naszej sieci - nazwanej umownie “Labem”: Syslog, DNS i NTP.

Ponad to, autorzy Tasmoty w dokumentacji publikują konkretne zalecenia i przykłady możliwości zabezpieczeń urządzeń przed atakami.

Nasz Firmware

Możliwość łatwej “kastomizacji” firmware-u jest zapewniona, poprzez przegląd my_user_config.h i edycję pliku user_config_override.h gdzie wpisujemy te definicje z my_user_config.h które zapewnią wymaganą konfigurację firmware. Konfiguracja user_config_override.h nadpisuje ustawienia z my_user_config.h Zalecenia i podpowiedzi w kwestii kompilacji również są opublikowane w dokumentacji. Dobrze mieć wolne urządzenie do testów rezultatów naszych kompilacji by mieć pewność, że założone cele zostały zrealizowane. No to ściągamy kod źródłowy. Należy też mieć świadomość różnic między ESP8266/8285 a ESP32. Główna jest taka, że ten pierwszy ma 1MB RAM, a ten drugi 4MB. Dlatego to co jest dobre dla ESP32 może nie być możliwe dla ESP8266. Moje Gosund-y SP111 to ESP8285 właśnie. Przy przeglądaniu kodu Tasmoty, warto wyłączyć plugin VSC “Intellisense C/C++” będzie pyszczył o konwersję plików .ino do .cpp. Biorąc pod uwagę przyjętą strategię, że użytkownik urządzenia NIE będzie miał uprawnień administratora, możemy tam zdefiniować wszystkie niezbędne parametry do połączenia z Wifi, ustawienia NTP, MQTT, MQTT z TLSem, serwera Web, a nawe IPv6 czy TLS dla komunikacji z chmurą AWS lub Azure. Jest tam mnóstwo innych ustawień, pod konkretne sensory. Więc, jeśli czymś nie jesteśmy zainteresowani, bo nasze urządzenie po prostu tego nie robi, można spróbować wyłaczyć i dzieki temu uzyskać mniejszą objętość firmware-u.

Rozwiązanie techniczne z konfiguracją brokera, Telegrafa i InfluxDB przedstawię w ostatnim odcinku. Temat z metrykami dla Prometheusa jest wciąż testowany.

Rosnące ceny energii i ogólny rozwój “inteligencji” naszych domów i mieszkań, przy boomie na fotowoltaikę przyciągnął na dłużej moją uwagę. A jakieś ogólne rozważania o bezpieczeństwie IoT (ale też i wysokości rachunków za prąd) pchnęły mnie do działania. Na pierwszy ogień poszły gniazdka Gosund SP111 z Tasmotą na pokładzie. Fajna rzecz, wytrzymymuje obciążenie do 3,45kW i jeszcze mierzy prąd, napięcie, obiążenie i cosinus fi - czyli też przesunięcie fazowe!. A jak weterani różnych elektrycznych techników pamietają, ongi cosinus fi przynosiło się w wiaderkach. ;-) A tu proszę.. mierzy samo i z wiadrami żadnymi latać nie trzeba.

No więc do ad remu przechodząc, po głowie chodził mi temat pomiaru poboru mocy przez różne urzadzenia pożerające prąd (..i cosinus fi!), ale w jakiś uporządkowany i bezpieczny sposób. W swojej wrodzonej i nabytej nieufności do rzeczy, w których “samo się” dzieje, gdzie przy rzeczach “inteligentnych” zapala się czerwona lampka, chciałem zbudować działającą koncepcję tak realizowanych pomiarów. Najlepiej spełniającą kardynalny postulat “to co dzieje się w domu, pozostaje w domu”. Dlatego też, odpadły wszelkie chmury, historie typu “zanim wepniesz gniazdko.. załóż konto..” i “wygodne appki na telefon”. Postanowiłem zrobić PoCa (ang. Proof of Concept).

Elementy układanki

Poniższa lista przedstawia wszystkie elementy układanki, które postanowiłem złożyć w jedno rozwiązanie, działające i bezpiecznie i wygodnie i sprawnie. Dużo tego nie ma, ale myślę, że takie na pozór łatwe ćwiczenie dało mi niezłą dozę wiedzy, z jakimi przeciwnościami losu trzeba się mierzyć by zadbać o bezpieczeństwo takich instalacji.

• Gosund SP111 - inteligentne gniazdko (układ ESP8285),
• Tasmota 12.3.1 - firmware Open Source do gniazdka,
• Mosquitto - Open source-owy broker MQTT,
• Telegraf - konsument danych z MQTT, translacja danych do TSDB,
• InfluxDB TSDB.

Tu opcjonalnie, na sam koniec można dodać jeszcze Grafanę, w której można opracować ładniejsze i bardziej niż w samym InfluxDB, funkcjonalne dashboardy, alerty i powiadomienia. Na PoC wystarczy to co jest.

Analiza zagrożeń

Z życia wiemy, że zagrożenia czyhają na nas wszędzie i nie chodzi tylko o własną, niewymuszoną niefrasobliwość, bądź głupotę. Postronnym sluchaczom może się to wydawać jakąś fantasmagorią - ej, no weź.. kto Ci się będzie włamywał do gniazdek?!. I tak dalej. Nie, nie będziemy tutaj znowu uprawiać Bayesa, chociaż można by spróbować zebrawszy uprzednio jakieś wiarygodne statystyki dotyczące włamań do domowych IoT (nie przemysłowych - to inna odmiana tego samego zagrożenia, bo intencje są inne) i szkód przezeń spowodowanych. No dobrze, ale kontynuując - takie domowe gniazdka skoro mają nam służyć swoją nietuzinkową inteligencją, muszą zostać podłączone do jakiejś sieci TCP/IP (przez Wifi) i obsługiwać komunikację do i z gniazdka.

Zagrożenia

Zagrożenie właściwie jest jedno - włamanie do domowej sieci. Natomiast jedną z miar zagrożeń (przy rozpatrywaniu istotności takiego zagrożenia) mogą być intencje, które warunkują cele takich włamań. Spróbujmy je wymienić:

• Scenariusz 1: Włamanie do sieci celem przejęcia kontroli nad “inteligecją” domową - z intencją późniejszego włamania do samego domu. A zatem przejęcie kontroli nad “inteligencją” posłuży do tego, aby np. w nocy brama została otwarta, a czujniki ruchu wyłączone, a przez kamerę przy wejściu prześledzić można zwyczaje domowników, kto kiedy wychodzi i wraca..itd.
• Scenariusz 2: Włamanie do sieci celem dojścia do ważnych zasobów informacji na komputerach domowych z intencją późniejszego wykorzystania danych - wykorzystanie danych osobowych do wzięcia stu pożyczek, kompromitacja ofiar w internecie wykorzystując wrażliwe dane prywatne, itd.
• Scenariusz 3: Włamanie się do sieci celem wykorzystania zasobów domowych z intencją użycia zasobów domowych jako trampoliny do dalszych niecnych działań w internecie - np. przez instalację botnetu i realizacja kampanii phishingowych (tu mam żywy przykład u pewnej rodziny sprzed 2 tygodni, przyszła do nich policja że z IP - rutera domowego, a miał statyczny, wysyłany był malware, przez który ludzie z innych stron Polski potracili pieniądze z kont bankowych - przyczyną nie musiało być IoT, ale skądinąd akurat mogło być..)
• Scenariusz 4: Włamanie celem wyrządzenia szkód - jeśli na IoT mamy jakąś zaawansowaną automatykę sterującą pompą ciepła, piecem, regulacją fotowoltaiki itd. to człowiek z takimi intencjami i zaawansowanymi umiejętnościami, może np. popsuć urządzenia warte kilkanaście - kilkadziesiąt tys. złotych.
• Scenariusz 5: Włamanie do sieci, celem zdobycia informacji pozwalającej na wyrządzenie szkód konkurencji, bo np. ofiara jest prezesem jakieś ważnej spółki i byłoby super dostać się do jej laptopa, a jak wiemy nie tylko korporacje z zabezpieczonymi po zęby laptopami biorą udział w ważnych i dużo wartych przetargach. Wiele osób ma np. tylko darmowego Avasta, jeśli ma cokolwiek..

Jeśli w ten sposób spojrzymy na instalacje IoT i pomyślimy jako szczęśliwy posiadacz i użytkownik instalacji IoT - to którykolwiek z w/w scenariuszy zagrożenia z pewnością będzie mógł przypisać do swojej sytuacji. Ale jak!? No to prześledźmy:

Profile potencjalnych ofiar włamów do/przez IoT:

1. Nie mam domu, nie mam fotowoltaiki, nie jestem prezesem i nie prowadzę w ogóle żadnej firmy, nie mam nawet konta w banku:
   • Scenariusz 2 lub/i
   • Scenariusz 3,
2. Mam dom, nie mam fotowoltaiki, nie jestem prezesem i nie prowadzę żadnej firmy:
   • Scenariusz 1,
   • Scenariusz 2,
   • Scenariusz 3,
   • może Scenariusz 4
3. Mam dom, fotowoltaikę, prowadze firmę, która startuje w różnych przetargach:
   • tu właściwie wszystkie scenariusze nam się “uaktywniają” jako możliwe, a nawet ich kombinacje.

Podsumujmy ten alarmistyczny wywód w kontekście natury takich małych a inteligentnych urzadzonek jak żarówki, gniazdka, czujniki czy kamery. Są to sprzety małe, oparte o układy przemysłowe, wytwarzane na przemysłową skalę, których specyfikacje i oprogramowanie jest szeroko dostępne (jak np. Tasmota). Ze swojej natury borykają się z licznymi ograniczeniami - i nie są to tylko zaniechania producentów - jest to na przykład ograniczona pojemność RAM w którą można upakować nie tylko niezbędną funkcjonalność, ale i nie-funkcjonalność w postaci mechanizmów bezpieczeństwa. Takich jak: możliwość zmiany fabrycznie ustawionej nazwy konta admina, możliwość konfiguracji TLS 1.2 do komunikacji, bezpieczne (silnie zaszyfrowane) przechowywanie haseł czy tokenów uwierzytelniających, zaawansowane metody uwierzytelniania, obsługa WPA3 czy choćby WPA2-PSK ale z szyfrowaniem AES, zmiana MAC adresu, czy choćby nazwy urządzenia. Takie gniazdko Gosund SP111 ma 1MB RAM, z czego firmware z tym co oferuje zajmuje 630kB.

Z drugiej strony tak jak w całym świecie IT i na całym świecie mamy zaniechania, lenistwo i nieświadomość człowieczą, przy instalacji i eksploatacji. Poza tym nie każdy instalator IoT musi się znać na wszelkich typach ruterów bezprzewodowych - na jednym “network isolation” ustawia się jednym klikiem, na innych wyłącza po prostu forwarding ruchu sieciowego, ale trzeba dorzucić reguły do firewalla. No i te aspekty dodane do siebie, wyczerpują nam w zupełności powagę istotności opisanych scenariuszy zagrożeń.

Co robić, jak żyć?

Znowu (po raz któryś! dziwne..) pojawia się zasadnicze leninowskie pytanie “co robić?!”. Spróbować wybrać tak, i zaprojektować tak, i poskładać tak tę instalację aby się przed takimi zagrożeniami jednak obronić. To znaczy tak utrudnić potencjalnym amatorom silnych wrażeń w IoT zadanie, żeby im się nie opłacało w ogóle nawet chcieć. W ocenie zagrożeń i doborze technik przeciwdziałania może nam pomóc matryca MITRE dla ICS (ang. Industrial Control Systems).

MITRE

Towarzyszom niedoli z mojej branży nazwa MITRE kojarzyć się może z bazą podatności CVE. Ale nie tylko. MITRE jako organizacja non-profit sponsorowana przez rząd USA zajmuje się też rozwojem metodyki analizy zagrożeń w cyberprzestrzeni (IoT jest jej częścią) zwanej ATT&CK. Rzecz polega na bieżącej analizie i profilowaniu zagrożeń w cyberprzestrzeni i mapowaniu zaobserwowanych działań w podziale na poszczególne fazy ataków - taktyki oraz techniki i pod-techniki służące osiąganiu celów pośrednich by przejść do kolejnych faz i ostatecznie osiągnąć sukces (a przynieść straty ofiarom). I takie mapowanie właśnie wykonano też dla ICS, u nas znane bardziej jako systemy automatyki przemysłowej. Bo z tego właśnie nasze domowe IoT wyewoluowało wraz z postępującą miniaturyzacją, standaryzacją protokołów komunikacji, niskimi kosztami wytwórczymi i upowszechnieniem internetu. I jak się okazuje - całkiem nieźle pasuje nawet do tak niewyszukanych instalacji IoT jak moja.

No to nieźle. Z głupiego (sorry.. inteligentnego!) domowego gniazdka wypłynęliśmy na szerokie wody cyberprzestrzeni i sponsoring USA! A to by się Lenin zdziwił, taką odpowiedzią. ;) No niestety, jeśli chodzi o bezpieczeństwo w cyberprzestrzeni (też!) to nikt nie dzwoni do Szwecji. Bierzemy się do pracy. Pokażę, jak te groźne scenariusze zagrożeń opisane powyżej, przekładają się na metodykę ATT&CK. A także jakie zabezpieczenia adekwatne do skali i możliwości naszego rozwiązania mogą przeciwdziałać tym zagrożeniom.

ATT&CKujemy IoT

Sprawczość pomocnicza w ochronie naszego IoT, objawia się w możliwości odpowiedzi na następujące pytania:

1. Na jakie scenariusze zagrożeń jesteśmy narażeni posiadając taki-a-taki system IoT, który ma zaimplementowane takie-a-takie mechanizmy bezpieczeństwa i przeciwdziałania włamaniom?
2. Jakie mechanizmy bezpieczeństwa i przeciwdziałania włamaniom powinniśmy zaimplementować, aby udaremnić realizację danych scenariuszy zagrożeń?
3. Czy zaimplementowane mechanizmy bezpieczeństwa i przeciwdziałania włamaniom uchronią nas przed danymi zagrożeniami?

I jak myślicie - na które pytanie zechcemy sobie odpowiedzieć? No tak, robimy PoC-a, jakieś pojęcie mamy, ale chcemy uzyskać konkretną listę, konkretnych tematów do implementacji w naszym PoC-u, aby nie martwić się o scenariusze, którymi sam siebie wystraszyłem tam nieco powyżej w tekście. A więc będzie to pytanie nr 2.

Co przeanalizujemy? Potencjalny atak, jego wektor i cele atakującego zakładamy w treści scenariusza nr 2 i 3. Celem ataku będzie zwyczajna, powszechna sieć domowa WiFi, czyli ruter WiFi podpięty do infrastruktury dostawcy z jakąś konfiguracją zapewniającą szybki internet dla domu, kilka urzadzeń domowych - komputerów/laptopów, może serwer jakiś, może jakiś TV i nasze gniazdka.

Otwórzmy sobie w przeglądarce narzędzie analityczne ATT&CK Navigatora. Wybierzmy “Create New Layer” i poniżej kliknijmy w “ICS”. Pojawi nam się matryca z ponazywanymi kolumnami, a w każdej z kolumn techniki realizacji ataku. Coś takiego:

Jeśli wrócimy do domowej strony matrycy dla systemów automatyki przemysłowej i klikniemy np. w pierwszą na samym dole technikę “Wireless Compromise”, to w taktyce “Initial Access” zobaczymy zamapowane scenariusze przeciwdziałania (ang. Mitigations) dla podstawowej taktyki ataku naszego systemu IoT. Bowiem, moim zdaniem, domowe IoT nie będą w dużej mierze celem samym w sobie, a słabością, którą wykorzysta atakujący by zrobić nam krzywdę (albo nawet nie nam) gdzie indziej - o czym mowią opisane wyżej scenariusze. Więc ruszajmy dalej. Pierwszym zadaniem na liście “Mitigation” jest “M0802 Communication Authenticity “ czyli zapewnienie autentyczności komunikacji. Klikając w tę pozycję dostajemy zwrotnie listę technik atakującego, które zostaną uniemożliwione lub utrudnione przez to przeciwdziałanie. W treści tego przeciwdziałania jest link do CISA (kolejne agencji bezpieczeństwa) gdzie w prosty sposób wyszczególnione są konkretne działania do realizacji. Pasuje do naszych scenariuszy? Pasuje. Dalej pod “Mitigation” mamy mechanizmy detekcji - “Detections” z listą co powinniśmy mieć skonfigurowane, by realizację tej techniki przez atakującego wykryć! W Navigatorze zaznaczamy tę technikę na czerwono. Drugą techniką w taktyce “Initial Access”, która może realna dla naszego przypadku to moim zdaniem “Supply Chain Compromise”, czyli naruszenie łańcucha dostaw. Przekładając to na realia - możemy mieć już w nierozpakowanym pudełku gniazdko z firmwarem, które zawiera nieprzyjemną niespodziankę - wgrany firmware ma dwie malutkie zmiany, praktycznie powodujący może minimalne zmiany w wielkości pliku firmware-u - podmieniony został URL do aktualizacji i uaktywniona opcja automatycznej aktualizacji. Albo też, jeszcze nieobeznani, nieostrożni, ale zapaleni do działania, sami ściągamy upgrade firmware-u z jakiejś nieznanej nam bliżej witryny w internecie. A i w repozytorium Tasmoty - open source-owego firmware-u dla mojego gniazdka, sygnatur nie stosuje się.

I w ten sposób przeglądamy resztę taktyk zaznaczając te, które nam możliwie pasują do rozpatrywanych scenariuszy mając na uwadze zaproponowany (i już nieco rozpoznany) stos technologiczny naszego PoC-a. Tym sposobem, przeglądając resztę technik oraz ich “Mitigation” i “Detection” dochodzimy do końca matrycy. Na czerwono w matrycy w Navigatorze zaznaczamy te, które uznamy za właściwe, możliwe i zgodne z celem i intencją rozpatrywanego przez nas scenariusza zagrożenia. Ostatecznie dostajemy coś w rodzaju takiego obrazka:

Odpowiedź na pytanie

Jakie mechanizmy bezpieczeństwa i przeciwdziałania włamaniom powinniśmy zaimplementować, aby udaremnić realizację danych scenariuszy zagrożeń? Poniżej jest lista, opracowana przeze mnie na podstawie analizy poszczególnych technik. Należy naturalnie wziąć pewną poprawkę na to, że propozycje implementacji tych mechanizmów dotyczą ICS a nie IoT i nie w domu a w przedsiębiorstwie. Wobec tego zalecenia dotyczące np. audytu tego czy owego wypada “przełożyć” na rozwiązanie domowe, np. lepsze ustawienie alertów, albo okresowy jakiś prosty przegląd logów, ostatecznie skreślić z listy. No bo skąd niby w domu miałby się wziąć jakiś audyt? :) Tak samo “Supply chain management” czy “Vulnerability management”. Będą więc propozycje, które:

• Da się zrealizować,
• Częsciowo da się zrealizować,
• Da się zastąpić inną metodą,
• Nie da się zrealizować.

Przy tworzeniu tej listy robimy od razu coś w rodzaju “oceny przydatności”. Z całą tą listą z zawartą tam oceną przydatności i uzasadnieniem rozprawimy się w kolejnym wpisie. Ten wydaje się już i tak dość długi.

Nie mniej jednak, dzięki tej liście, będziemy mogli odpowiedzieć na kolejne pytanie - czy dobór komponentów do PoC zapewni nam oczekiwany poziom bezpieczeństwa (np. uchroni nas przed paskudnymi skutkami scenariuszy zagrożeń). Odpowie nam też na pytanie jaką pracochłonność powinniśmy zaplanować na wdrożenie, ile rzeczy trzeba się nauczyć, ile przetestować, które elementy w naszym PoCu podmienić. No i wreszcie ile to wszystko będzie kosztować.

Podsumowanie

Ten wpis miał być o technicznym wdrożeniu prostego systemu pomiaru poboru mocy przez urządzenia domowe przy pomocy gniazdka Gosund SP111 z Tasmotą na pokładzie. A jednak (surprise, surprise!) przerodził się w rozważania analityczne o bezpieczeństwie takiego rozwiązania. Nic nie szkodzi, w kolejnym wpisie przedstawię techniczną implementację tego PoC wg nakreślonych na samym początku założeń. Przykład, hmm.. może nie być zbyt adekwatny do popularnych potrzeb (mało kto w domu ma serwery z Nomadem, Consulem i Vaultem gdzie w bezpieczny sposób może składować i wymieniać dane uwierzytelniające poszczególnych komponentów rozwiązania). No ale tez chodzi o to, aby pokazać, że nie jesteśmy bez szans, ani nie jesteśmy skazani na umowne “bezpieczeństwo” danych w jakichś tam chmurach producenckich.

Among these great tools (like this absolutely fantastic threat calculator supported by sound and logic methodology) there’s ATT&CK Workbench written and maintained by CTID. An open source tool to operationalize sharing a knowledge base grown amongst blue and red teams in their efforts to keep threats at bay. A very fine tool. However, as being lately into DevOps for sometine, I’ve managed to grow this kind of devops anxiety (or “compulsive neurosis”) which makes me always keep seeking for those aspects of application development associated with proper components management in respect to security and updates through an SDLC of the app.

So, while enjoying the chapter of “Extending ATT&CK with ATT&CK Workbench” I cloned the repositories and fired off the docker-compose up on my Docker Desktop, just to explore the tool and get this chapter accomplished. First thing which popped up right away was the size of the docker containers of this app (frontend, api and collection manager). Almost 1GB each. Wow! I took some time and searched through countless micro-tutorials on how to dockerize an angular app. None that I found had followed docker best practises. Just install the angular CLI, copy over the whole app, run npm install and get it into the NGINX base, et voila!. The only prevailing pattern was this NGINX. Apparently the Workbench creators followed those tutorials. So, let’s quickly examine this tool and fix its components Dockerfiles.

attack-workbench-frontend_collection-manager	    959MB
attack-workbench-frontend-rest-api			    1.06GB
attack-workbench-frontend_frontend			    142MB

Well, next step was to see what trivy was about to say:

attack-workbench-frontend_frontend (debian 10.9)
================================================
Total: 336 (UNKNOWN: 3, LOW: 146, MEDIUM: 62, HIGH: 81, CRITICAL: 44)

attack-workbench-frontend_collection-manager (debian 10.13)
===========================================================
Total: 2028 (UNKNOWN: 0, LOW: 1231, MEDIUM: 463, HIGH: 301, CRITICAL: 33)

attack-workbench-frontend_rest-api:latest (debian 10.13)
========================================================
Total: 2028 (UNKNOWN: 0, LOW: 1231, MEDIUM: 463, HIGH: 301, CRITICAL: 33)

Looks like a friggin lot of the crits. Snyk also confirmed that the culprit was the outdated Debian based NGINX image.

[..]
Docker image:      attack-workbench-frontend_frontend:latest
Platform:          linux/amd64
Base image:        nginx:1.19
Licenses:          enabled

Tested 136 dependencies for known issues, found 225 issues.

Base Image  Vulnerabilities  Severity
nginx:1.19  225              30 critical, 34 high, 26 medium, 135 low

Recommendations for base image upgrade:

Minor upgrades
Base Image  Vulnerabilities  Severity
nginx:1.22  84               0 critical, 0 high, 0 medium, 84 low

Alternative image types
Base Image         Vulnerabilities  Severity
nginx:1.23.1-perl  84               0 critical, 0 high, 0 medium, 84 low

The frontend

Further poking around showed up, that the docker wrapping was never updated since the first launch. Hence, my first move was to get this suite wrapped up with my latest alpine-node16 and refresh the NGINX parts. It’s a known docker technique to reduce size of the image - multi-stage build, where the last final image gets only compiled and static web contents of the app, accessible through nginx web server. However, to further reduce the size I used the base alpine 3.16.2 with nginx added from the distribution.

Modified attack-workbench-frontend/Dockerfile:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
FROM powernuke.nukelab.home:5443/base-alpine-node16:16-3 as build

WORKDIR /home/node/app

COPY ./app/package*.json ./
  
RUN npm install -g @angular/cli && \
    npm install 
 
COPY ./app .
 
COPY ./docs ../docs
 
RUN npm run build-prod
 
FROM powernuke.nukelab.home:5443/base-alpine:3.16-3
 
RUN apk --update add nginx && \
    rm -rf /var/cache/apk/*

COPY ./nginx/nginx.conf /etc/nginx/nginx.conf

WORKDIR /usr/share/nginx/html 

COPY --from=build  /home/node/app/dist/app .
 
EXPOSE 80 

STOPSIGNAL SIGQUIT 

CMD ["nginx", "-g", "daemon off;"]
 

Result:

attack-workbench-frontend_frontend:latest               33.4MB

Trivy:

attack-workbench-frontend_frontend:latest (alpine 3.16.2)
=========================================================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

The rest (api and collection manager)

Let’s move onward and get the other two cleaned up. Replace old and grumpy node:14 with my freshly built base-alpine-node16:16-3, address a very bad practise of running an app as local root - with the USER node line and see:

Result:

attack-workbench-frontend_rest-api:latest               353MB

Trivy - shows no issues on the OS level, however it looks like the old code has some flawed libs (npm packages):

attack-workbench-frontend_rest-api:latest (alpine 3.16.2)
=========================================================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)


Node.js (node-pkg)
==================
Total: 7 (UNKNOWN: 0, LOW: 0, MEDIUM: 2, HIGH: 2, CRITICAL: 3)

Well, let’s just run npm update right before the npm install that’s hopefully gonna fix buggy npm modules. Ok, how’s now?

attack-workbench-frontend_rest-api:latest (alpine 3.16.2)
=========================================================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

Node.js (node-pkg)
==================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)


attack-workbench-frontend_collection-manager:latest (alpine 3.16.2)
===================================================================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

Node.js (node-pkg)
==================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

The ultimate /attack-workbench-rest-api/Dockerfile (and for the collection manager as well) now is:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
FROM powernuke.nukelab.home:5443/base-alpine-node16:16-3

WORKDIR /home/node/app

COPY package*.json ./

RUN npm update && \
    npm ci --only=production && \
    npm cache clean --force

COPY . .

RUN chown -R node:node /home/node

USER node

CMD [ "npm", "start" ]
 

Oh, by the way the .dockerignore should be set in the way so that you won’t copy all the Dockerfiles and other unnecessary stuff into the image with the COPY . . line.

Results

The size:

attack-workbench-frontend_collection-manager     142MB
attack-workbench-frontend_rest-api               338MB
attack-workbench-frontend_frontend               33.4MB

..down from original:

attack-workbench-frontend_collection-manager    959MB
attack-workbench-frontend-rest-api             1.06GB
attack-workbench-frontend_frontend              142MB

..and from thousands vulnerabilities (with over 100 critical) down to none. Security of the code, secure MongoDB, authentication is another story. Nevertheless, properly maintaining the Dockerfile alone can significantly reduce headaches and ..the attack surface. :)

ps. If anyone wants to use these fixed Dockerfiles, you need to replace my alpine built node16 with regular alpine base node 16 and nginx 1.23 also alpine based.

Czym jest Traefik proxy?

Jest kawałkiem oprogramowania, którego jedynym przeznaczeniem jest rola reverse proxy. Dlaczego właśnie to on? Dlatego, że od początku autorzy postawili na integracje i automatyzację z różnymi technologiami orkiestracji i zarządzania mikro-serwisami. Jest tam docker, kubernetes (a jakże!), Nomad, Consul, Mesos itd. Przy czym wersja community - a więc darmowa, posiada dostateczne możliwości i funkcjonalności do zautomatyzowania. W przeciwieństwie do NGINX. Dla Traefika pojawienie się nowego serwisu nie wymaga restartu czegokolwiek. Traefik jako Nomad deployment skorzysta z integracji Nomada i z Consulem i z Vaultem. W taki sposób, że Nomad zapewni bezpieczne dostarczenie Consul Tokena (przechowywanego w Vaulcie) konfiguracji Traefika do integracji z Consulowym katalogiem serwisów. Dzięki temu, Traefik na bieżąco będzie w stanie obsłużyć cały cykl życia usług i aplikacji.

Logika Traefika - jak to działa?

Koncepcja przedstawiona na diagramie zamieszczonym poniżej jest następująca:

1. Uruchomiony Traefik jako job w Nomadzie poleceniem nomad job run -check-index 0 traefik.nomad (jobspecs file tutaj)
2. Traefik skonfigurowany zostaje tak aby dla swej statycznej, sięgnąć do Vaulta po:
   • certyfikaty TLS dla *.nukelab.home(generowanie certyfikatu opisane tutaj)
   • Consul Token celem autoryzacji dla integracji z consulowym katalogiem usług (Consul Catalog),
   • Przygotowania dynamicznej konfiguracji (docelowo ta konfiguracja powinna być usunięta z pliku jobspecs i umieszczona w GitHubie)
3. Aplikacja myapp.nukelab.home zostaje uruchomiona w Nomadzie, z odpowiednimi tagami dla usługi (Traefik: labels), które zostaną zaprezentowane w Consulu - Nomad wszystko co się w nim uruchomi, melduje Consulowi jako usługę.
4. Nomad jako orkiestrator - zapewnia komunikację między wirtualną siecią dokera (domyślnie ustawiona jako bridge) a interfejsem hosta, łącznie z mapowaniem i wystawieniem odpowiednich portów tcp/udp.
5. DNS na potrzeby ćwiczenia, ma rekord dla *.nukelab.home ustawiony na IP Traefika,
6. Traefik pobiera sobie stan katalogu usług z Consula wraz z pełną informacją o każdej usłudze,
7. Przychodzi zapytanie o myapp.nukelab.home i dzięki w/w Traefik wie, przez który swój wewnętrzny ruter i do jakiego endpointa ma skierować ruch.

Na plasterki!

No to poszatkujmy tego słonia na plasterki, aby kawałek po kawałku pokazać jak to wszystko zostało skonfigurowane i jak działa. Aspekt integracji Nomada, Consula i Vaulta jest poza zakresem tego wpisu. Ważne jest aby klient Nomada (agent) mógł sięgać zarówno do Vaulta jak i Consula, autoryzując się tokenami. Podpowiem, token do autoryzacji w Vaulcie Nomad ma w swoim pliku konfiguracyjnym agenta, a token do Consula przechowuje w.. Vaulcie. Zaczniemy zatem od konfiguracji Traefika.

Konfiguracja Traefika

Konfiguracja Traefika w pliku nomadowym może być zrealizowana poprzez zmienne środowiskowe, pliki konfiguracyjne YAML albo TOML oraz parametry przy odpalaniu binarki. Wykorzystamy kombinację. Parametry - przy uruchomieniu podamy traefikowej binarce ścieżkę do plików konfiguracyjnych i pliki YAML - te, wygenerujemy poprzez template nomadowy. Naszym słoniem będzie jobspecs dla Traefika.

Zaczynamy od wiersza 19, gdzie zaczyna się stanza group:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
  group "traefik" {
    count = 1
    update {
      auto_revert = true
    }
    network {
      port  "http" {
        to     = 80 
        static = 80
      }
      port "https" {
        to     = 443
        static = 443
      }
      port  "api" {
        to     = 8080
        static = 8080
      }
      dns {
        servers = ["192.168.120.231"]
      }
    }

 

W tym miejscu mapujemy i wystawiamy do sieci porty Traefika, w jego nomenklaturze zwane entrypointami. Można jeszcze wystawić metryki na port 8082/tcp, ale na nie jest to niezbędne na potrzeby naszego ćwiczenia. Dalej będzie już tylko ciekawiej.

Od wiersza 44:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
    service {
      port = "https"
      tags = [
          "traefik",
          "traefik.enable=true",
          "traefik.http.routers.dashboard.rule=Host(`traefik.nukelab.home`) && (PathPrefix(`/api`) || PathPrefix(`/dashboard`))",
          "traefik.http.routers.dashboard.tls: true",
          "traefik.http.routers.dashboard.service=api@internal"
      ]
      check {
       type     = "tcp"
       interval = "15s"
       timeout  = "5s"
      }
    }

    service {
      tags = ["lb", "api"]
      port = "api"
 
      check {
        type     = "http"
        path     = "/ping"
        interval = "15s"
        timeout  = "5s"
      }
    }
 

W ramach grupy traefik i wystawionych portów, definiujemy usługi, które Nomad zamelduje Consulowi. Pierwsza usługa z portem https to sam on - Traefik. Sam dla siebie musi wiedzieć, że jak ktoś wyśle zapytanie o https://traefik.nukelab.home/api|dashboard to ma odpowiedzieć własnym dashboardem.

• "traefik", tag, który oznacza usługę, która ma być wystawiona przez Consula do Traefika
• "raefik.enable=true", tag potwierdzający gotowość do usługi do obsługi (sic!) przez Traefika
• "traefik.http.routers.dashboard.rule=Host(traefik.nukelab.home) && (PathPrefix(/api) || PathPrefix(/dashboard))" - tag definiujący ruter i reguły sterujące tym ruterem,
• "traefik.http.routers.dashboard.tls: true", tag, który mówi tyle, że wszystko co przechodzi przez ten ruter ma być obłużone przez HTTPS,
• "traefik.http.routers.dashboard.service=api@internal", serwis traefikowy który ma być obsłużony przez ten ruter

Druga usługa to api. Obie usługi mają zdefiniowane checki - też dla Consula, aby ten wiedział czy usługi żyją i są zdrowe. A więc tu dochodzimy do ważnej obserwacji - w Nomadzie, aby dana aplikacja czy cokolwiek innego (MongoDB, czy inny mikro-serwis) był widoczny i obsłużony przez nasze rev-proxy, musi mieć odpowiednie tagi w definicji service.

Od wiersza 74:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
task "proxy" {
      driver = "docker"
      config {
#        network_mode  = "host"
        command       = "traefik"
        args          = [ "--configFile", "/local/traefik.yml" ]
        image         = "powernuke.nukelab.home:5443/traefik:2.8.4-8"
        ports         = ["api", "http", "https"]
      }
      vault {
        policies = ["traefik-access"]
      }
 

Tutaj standard, Nomad po prostu każe dockerowi ściągnąć obraz, odpalić z zadanymi argumentami i wystawić uprzednio zdefiniowane porty. Dzięki integracji z Vaultem, na końcu pojawia się deklaracja, że w tym przypadku agent nomadowy będzie autoryzowany przez politykę Vaultową o nazwie traefik-access do sięgnięcia po sekrety w Vaulcie, w ścieżce przeznaczonej dla Traefika. Obraz Traefika mam swój - żadna filozofia, alpine 3.16 z binarką Traefika + entrypoint.sh.

Dalej, od wiersza 89 do 134:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
      template {
       data        = <<EOH
tls:
  stores:
    default:
      defaultCertificate:
        certFile: /local/traefik.crt
        keyFile: /local/traefik.key
EOH
       destination = "/local/dynamic.yml"
       change_mode = "restart"
       splay       = "1m"
      }
 

Budujemy tutaj konfigurację dynamiczną, którą poprzez konfigurację statyczną, Traefik sobie “w locie” sprawdza, czy nie ma jakichś zmian. Ta jest inicjalna, więc może tu być, ale np. inne certyfikaty, czy inne specyficzne sprawy dla danej usługi wypada obsługiwać przez kontrolę wersji w GitHubie i po przez GH Action zasilać ten katalog local.

1
2
3
4
5
6
7
8
9
10
11
12
13
 
      template {
        data        = <<EOH
{{ with secret "kv/data/traefik/nukelab" }}
{{ .Data.data.certkey }}
{{ end }}
EOH
        destination = "/local/traefik.key"
        change_mode = "restart"
        splay       = "1m"
      }
      [..]
 

Mamy trzy instancje template. Po kolei - pierwsza wyciąga z Vaulta klucz do certyfikatu dla *.nukelab.home, druga sam certyfikat, a trzecia CA. Przy czym, znalazłem tutoriala, gdzie autor miał jakieś problemy i jemu zadziałało to tylko wtedy kiedy miał cert fullchain, łącznie z kluczem (czyli: klucz, cert, intermediate, ca). U mnie działa poprawnie, a nie działało jak sugerował :-) Sekrety wyciągnięte z Vaulta lądują w lokalnym katalogu kontenera z Traefikiem w /local. Można podejrzeć w Nomadzie (o ile ma się token dostępowy admina - rzecz jasna):

Na koniec konfiguracja statyczna Traefika

Od wiersza 138:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
 
      template {
        data = <<EOH
{{ with secret "kv/data/traefik/nukelab" }}
serversTransport:
  insecureSkipVerify: true
entryPoints:
  web:
    address: ":80"
  websecure:
    address: ":443"
api:
  dashboard: true
  insecure: false
  debug: true
ping: {}
accessLog: {}
log:
  level: DEBUG
providers:
  providersThrottleDuration: 15s
  file:
    watch: true
    directory: "/local"
  consulCatalog:
    endpoint:
      scheme: https
      address: "powernuke.nukelab.home:8501"
      datacenter: nukelab
      token: {{ .Data.data.consultoken | toJSON}}
      tls:
        ca: /local/ca.crt
        cert: /local/traefik.crt
        key: /local/traefik.key
        insecureSkipVerify: true 
    cache: false
    prefix: traefik
    connectAware: true
    exposedByDefault: false
    watch: true
{{ end }}
EOH

       destination = "local/traefik.yml"
       change_mode = "noop"
 

Template w tym wypadku ściąga nam token Consula, dlatego występuje. Jadąc od góry:

1. Definicja entrypointów - porty dla HTTP i HTTPS,
2. Dostępność dashboardu Traefika po HTTPS,
3. Ustawienie poziomu logowania zdarzeń na DEBUG,
4. Najważniejsza rzecz: providers - file i tutaj Traefik dynamicznie obserwuje katalog /local oraz..
5. consulCatalog - gdzie definiujemy rodzaj komunikacji HTTP/HTTPS (w naszym przypadku), URL Consula, token i ścieżki do certyfikatów TLS - Consul sprawdza poprawność certyfikatów klienta. Ważne by mieć definicję providers file bez tego nie zadziała nam HTTPS, po prostu Traefik nie będzie wiedział, gdzie ma pliki z certami,
6. Na koniec prefix czyli tag jaki musi mieć każda usługa zdeployowana w Nomadzie, którą chcemy udostępnić przez Traefika, connectAware czy obsługiwać Consul Connecta (jeszcze nie do końca wiem co robi, ale nie przeszkadza), i exposedByDefault ustawiony na false - czyli nie chcemy aby Consul udostępniał Traefikowi wszystkiego co ma, a tylko te usługi otagowane “traefik”.

Poniżej pliki konfiguracyjne deploymentu Traefika widziane przez konsolę Nomada:

Zmiany w aplikacji

W nomadowym pliku aplikacji zmieniło się tylko to, że doszły tagi w definicji usługi (service stanza) - wiersz 63:

1
2
3
4
5
6
7
8
 
      tags = [
        "traefik",
        "traefik.enable=true",
        "traefik.http.routers.myapp.rule=Host(`myapp.nukelab.home`)",
        "traefik.http.routers.myapp.tls=true",
      ]
 

Tak jak przy objaśnieniu konfiguracji samego Traefika, znaczą one tyle:

1. Usługa udostępniana Traefikowi przez Consula,
2. Ruter myapp ma obsługiwać tylko zapytania dla myapp.nukelab.home
3. i tylko poprzez entrypoint HTTPS

Jest też testowa usługa whoami

Jak to wygląda?

• Dashboard:

• Informacja o ruterze dla myapp:

• Informacja o serwisie myapp:

• Tagi aplikacji w Consulu:

• Obsługa aplikacji przez HTTPS:

Podsumowanie

Mamy rev-proxy, który zapewnia nam bezpieczeństwo serwisów uruchomionych na naszej platformie. A także, jakiś elementarny porządek. Oczywiście, w środowisku produkcyjnym, wildcard cert nie jest mile widziany i naprawdę nie wypada w dzisiejszych czasach nie mieć PKI czy jakiegoś Sectigo dla certów. Prócz tego, w Traefiku możemy też skonfigurować integrację z CrowdSec czy plugin Souin (HTTP cache z ciekawymi opcjami). Przedstawioną wyżej konfigurację można zrealizować pewnie bardziej elegancko, bądź w ogóle inaczej - sekrety wstawić do GitHub Secrets pliki konfiguracyjne osobno i tylko templetami wciągać do jobspecs, a dla pełnej dynamiki katalog /local po prostu podmontować jako host mounted catalog w tasku (też jobspecs).

Co jeszcze?

Warto byłoby zabezpieczyć same serwisy w Consulu, stosując Consul intentions i Consul Connect - czyli takie reguły firewallowe regulujące ruch do/z usługi i poprzez CC - poufność tego ruchu stosując side-car proxy Envoy i TLS.

I tym sposobem dotarliśmy do końca pod-ścieżki rozwoju i zabezpieczania naszych deploymentów. Kolejne wpisy powrócą do głównego zadania jakim jest automatyzacja i testy w moim domowym CI/CD wykorzystując GH Actions. I w ramach powrotu do głównego wątku, zajmę się testowaniem różnych rozwiązań SAST/SCA. No, i oczywiście automatyka samego deploymentu.

Użyteczne sznurki:

• Traefik service discovery in Nomad
• Integracja Traefika z Vaultem
• Traefik + TLS
• Network Automation with Hashicorp and Traefik - use cases
• Pomoce naukowe do w/w webinara

Usprawnienia deploymentu

W międzyczasie, usprawniłem i poprawiłem specs file dla deploymentu aplikacji z MongoDB, tak aby temat był ogarnięty w jednym jobie a aplikacja została uruchomiona wtedy i tylko wtedy kiedy stan zadania deploymentu MongoDB jest healthy. Ta technika w świecie Nomada nazywa się prestart side-car. I MongoDB jest takim side-carem.

Jak widzimy, side-car może być uruchomiony jako:

• prestart - zanim uruchomimy co innego, ten musi działać, bez niego nic dalej nie pójdzie,
• poststart - wjeżdża po tym jak główne zadanie - aplikacja - zostanie uruchomiona,
• poststop - uruchomione po tym jak główne zadanie przestaje działać, np. jakieś zadanie “sprzątające”

A tu jest specs file. Prócz skonsolidowania dwóch odrębnych deploymentów w jednej grupie jako dwa zadania; to pierwsze - dla Mongo ma dodatkowy wpis:

1
2
3
4
5
6
 
lifecycle {
        sidecar = true
        hook = "prestart"
      }
 

Bez tej zmiany, oba zadania nadal są zależne od siebie, ale bardziej jako towarzysze niedoli - jeśli którekolwiek z zadań jest unhealthy i koniec końców umiera (status: dead), to nomadowy scheduler widząc to, solidarnie uśmierca też to już działające. Co oczywiście zabiera mu trochę czasu, generuje logi, komunikaty i trochę komplikuje troubleshooting. Stąd wynikło ulepszenie a to przy kolejnym zadaniu związanym z dostępnością ułatwi zabawę. Dlatego tak zdefiniowany deployment będzie bazą do dalszych rozważań i usprawnień. Na przykład do tego, by rozbić oba serwisy na dwie grupy, tak by można było utworzyć kilka instancji aplikacji (a niekoniecznie już MongoDB).

Co z tą dostępnością?

Kolejnym etapem dbania o bezpieczeństwo aplikacji jest zapewnienie jej dostępności (jeden z wymiarów bezpieczeństwa). Wypadałoby postawić jakiejś reverse-proxy, na podstawie nagłówków sprawdzić czy zapytanie jest Ok, przekierować (ang. upstream) do właściwego serwisu, trzymać sesję itd. Generalnie są trzy scenariusze, jak można to zrobić:

• albo wykorzystując jeden główny rev-proxy dla całego klastra Nomadowego z auto-skalowaniem (w ramach pojedynczego data-center, ang. ingress),
• albo wykorzystując technikę side-car i dać aplikacji jej własnego i osobistego rev-proxy w ramach pojedynczego deploymentu,
• albo ulepszony scenariusz pierwszy - tzn. na każdym serwerowym węźle lokalnego klastra Nomadowego postawić rev-proxy, ustawić round-robin w DNSie dla pojedynczej nazwy klastra i ustawić rozproszony load-balancing temu proxy, poprzez konfigurację Consula.

Jak wszystko, te podejścia mają swoje wady i zalety. Przy pierwszym podejściu - “wiadomix” - pojedynczy punkt awarii, jak nam ten ingress siądzie to kicha z dostępem do wszystkiego co tenże proxy obsługuje. Z drugiej strony jeden proxy, jeden payload, jeden proces/kontener. Łatwo się kontroluje, mało zasobów zżera Nomadowi et consortes (+Consul i Vault). Drugie podejście ma odwrotnie - jak się popsuje, to nie działa jedna appka z wielu, ale też tych proxiaków możemy mieć poupychane w klastrze na tyle ile mamy tych aplikacji. A zatem, to rozwiązanie nadaje się na np. deployment pojedynczego autonomicznego klastra z aplikacją w AWSie. Najfajniej byłoby mieć to trzecie rozwiązanie - czyli stoją sobie proxy na każdym węźle, user robi deployment na adres Nomada, np. nomad.mojadomena.com, robi się aktualizacja konfiguracji proxy o nowy upstream e voila!. To ostatnie podejście jest najbardziej skomplikowaną sprawą do konfiguracji. Celowo tutaj nie wspominam jeszcze o obsłudze certyfikatów, żeby nie komplikować. Po kolei.

Nomad z Consulem, czyli po polsku ;) - orkiestracja z mesh-em (sic!) są w stanie obsłużyć wszystkie te podejścia z wykorzystaniem najpopularniejszych proxy: NGINX, HA-Proxy, traefik i envoy. Przy czym ten ostatni jest w pełni zintegrowany w taki sposób, że wystarczy “hokus-pokus” (z wykorzystaniem Consul Connect) w specs file-u nomadowym i mamy serwis obługiwany poprzez envoya w ramach pierwszego scenariusza. Natomiast ja wolałbym się zająć, już tradycyjnie komplikując sobie, tym ostatnim scenariuszem. Przypomina to taki systemowy ingress kubernetesowy (np. NGINX), gdzie wszystko definiuje nam helm chart i odpowiednie annotations,a my tylko robimy deployment i hyc! ..pod wskazanym URI odnajdujemy nasz serwis.

Poniżej diagramy przedstawiające poglądowo scenariusz, który chcę zrealizować i opisać w kolejnej części - a będzie tego sporo: grzebanie w konfiguracji Nomada i Consula, poprawnie zestawione TLSy między komponentami klastra, integracja, consul-template, przykładowe problemy do troubleshootingu, przykłady spraw niejasno opisanych w dokumentacji, konfiguracja proxy i na koniec certyfikaty. Fajnie byłoby mieć gotowe PKI na Vaulcie, ale to na razie w planach, jako wisienka na torcie.

Diagram logiki rozwiązania - Nomad odpali kontenery z proxy i z instancjami aplikacji na runtime dokerowym

Diagram logiki sieciowej (usługi Consula) - usługi przy deploymencie zostaną zarejestrowane w Consulu przez Nomada z informacjami o IP, portach, healthcheck-ach, a proxy przy pomocy Consul template zaktualizuje swoją konfigurację.

Użyteczne sznurki:

• Integracja Consula z proxy
• Tutka dla Nomad+NGINX (i inne)
• Tutka dla Consul+NGINX (i inne)
• LB w meshu Consula +zintegrowany Envoy
• Deployment zależny w Nomadzie lifecycle
• Nomad + Consul TLS + kontrola dostępu
• Consul Connect + envoy

Thoughts on some DevOps improvement tactics

A migration is often a painful process. Especially migrating some old applications along with the delivery process around them to a new platform featuring all those modern bells and whistles (like AWS/Azure driven Kubernetes or HashiCloud Platform etc.). And it does not only convey switching the technology from A to B (or lift-shift), nor only focuses on writing a new set of procedures (playbooks) on how to do things on Platform B - either. It actually requires a thorough refinement of the SDLC process, which all teams engaged and involved in this process should follow in their daily work to benefit from the new platform and make the migration meaningful and cost controlled.

A bit of background - a very common story

Imagine that once, the whole software delivery was a model of four teams - the architects, the development team, the Q/A team and the maintenance team. Each managed independently. Of course there were also some business analysts who were shovelling the requirements to the architects. They all followed a sequence of hand-offs to get the apps to production. However, there was no automation in place. The architects were making nice looking drawings in PPT, discussing some non-functional requirements with (totally separate, living on another planet) security dudes and that was it. The PPT diagrams were then handed over to the development team, who led by a PM and business relation analysts were taking care for functionalities to be cranked out of it. The developers were working on their own separate branches (multi-branch approach). So, once a specific functionality was announced done, it took a while merging those branches to the main one. Then Q/A was taking care of testing for weeks.. or months. When they were happy a release took place and if it worked bottles of champagne could be put to an ice bucket and celebration of a release could start. After those (rare) moments of sheer joy, the app was then handed off to the maintenance team, who were to support the app, handle issues reported by the users. Yet, they had no idea how the app was designed, developed and tested. They operated through playbooks.

Unfortunately, while the process looked orderly and coherent, it had certain flaws due to siloed teams and the way the communication across the SDLC process functioned. Even though, the Agile methodology was introduced, it had very limited impact on efficiency and productivity, mainly because only the development team alone followed the agile principles with all those sprints and stand-ups. While the maintenance followed through tickets in mainly a reactive mode. That all being said, resulted in perception of the reality around a given app - it was either in project-driven state (new functionalities were developed and old bugs being remediated) or in a business as usual mode where only maintenance teams were actively operating around the app, while the other teams already jumped out to another projects. Neither reality fit the Continuous Delivery model.

What was wrong in this picture?

1. The architects position was so low in the process, that once their job was done and the design was handed off to the developers, they were never given any feedback and never had any say (as not being involved) in subsequent sprints onward regarding new functionalities, design flaws, enhancements etc.
2. The only pattern the architects followed was a PPT pattern. There we no design pattern and components were largely determined by the business expectations and business analysts advocacy towards certain technology stacks.
3. The developers considered diamonds in the crown, were essentially cranking out new features, not quite caring of the code quality, tech stacks, libraries, security nor were they using any advanced tooling beyond their IDE on laptops (Visual Studio Code).
4. The Q/A were testing things manually, which lasted weeks and months.
5. The maintenance team, disconnected from the design and development phases were handed off just a piece of software being told what to do (scope limited to the playbooks they were given).
6. There was a separate ticketing system for developers and maintenance teams.
7. No continuous delivery was actually happening, although Jenkins and Docker orchestration with some monitoring was in place.

So, did the Jenkins pipelines, some basic Docker orchestration, Agile development and some monitoring establish any DevOps practise? The answer is: No. Not at all. It’s just a good starting point.

Why? A common platform was indeed in place (the Docker orchestration) where the apps landed, built and pushed through Jenkins pipelines. Yes, but all profound principles of DevOps were still missing, undermining the whole effort. Some tech/Linux savvy architects had built the platform and set up the pipelines. Hence, effectively all the components were commodity operated on daily basis without any thoughts on improvements going forward.

Symptoms, gaps

The “DevOps” is just a term, a buzzword. Can be meaningful or meaningless. Like Agile, if best practises are not followed within the entire delivery process setup, it’s miserably falling into old days Ford’s assembly line model - I did my part, now you do yours, bye. Regardless how agile a given organisation looks on a powerpoint presentation, these below are signs (or metrics) that Agile in the core development phase of the SDLC does not bring expected benefits:

• the organisation is unable to act quickly upon critical bugs or vulnerability found,
• the organisation is unable to provide frequent successful deployments on daily basis,
• the organisation is unable to act frequently, so that delta between changes is kept low, hence less risky for any potential piled up faults,
• the deployment process is not transparent to the user community (downtime announcements),
• the organisation is unable to bring and test new feature within 24h after a standup.

Gaps

The above listed are symptoms. And usually what it means is that there are certain (and very common) gaps at the operational and technical layers of any given DevOps to-be-driven environment:

• designs of the apps handled through the DevOps driven process are either outdated, non existent, or not consulted and agreed with the relevant IT architects (proper design and changes to the design must be a prerequisite for any further proceeding across the CI/CD),
• no automated tests in place - unit tests, acceptance tests, integration tests, security tests, smoke tests; or at least their coverage is not satisfactory,
• teams do not truly works together (there’s no real devops philosophy in place of a shared responsibility),
• long technical debt tail, long time spans between updates and upgrades (if any were in place),
• outdated documentation,

Real cases

Let’s see what it all means in real world:

• Case 1: At any given moment the organisation is unable to provide a successful production deployment, due to outstanding vulnerabilities in the codebase, which makes one of the quality (security) gate blocking the release, effectively stalling the deployment.
• Case 2: At any given moment, the organisation is unable to patch up and test a deployment, because there are no automated post-commit checks which would catch all outstanding discrepancies and overall quality posture.
• Case 3: Faulty deployments are handled ex-post, upon users community feedback; yet without any traces back in the CI/CD steps. And it requires hours to troubleshoot efforts to find a root cause.
• Case 4: Developers and/or Q/A manually test things with no quick feedback featured across the delivery process.

Also, often teams although empowered by visibility and controls do not feel responsibility for the design, quality, testing and deployment. They do not feel it’s a loop and that any single prod deployment does not ends their mission.

Some improvements

To engage with the DevOps philosophy and gradually improve the awareness and fluency across the teams, a dedicated and devoted DevOps team had to start from themselves. Let’s see it as a DevOps center of excellence at its very infancy. The team’s main purpose was:

• be a platform (or XaaS) team - helps the other teams to overcome obstacles while working towards successful (more secure, quicker, more stable) software delivery. Also, they were up to detect and identify flaws, deficiencies and missing capabilities. And to promote enhancements and mindset shifts across the table. The main way of communication in this role is : component as a service (Jenkins, Docker orchestration, Vault etc.) offered to other teams use, for all components of the platform.
• be the Enablers - beyond what they were up to wearing the “Platform” hat, they provided a steady and upward learning curve delivering new/improved components, techniques and products to accelerate the delivery process. Showcasing them and explaining profits to the other teams.

Given these two major roles of the DevOps team, they managed to establish some specific way of communication. Which also had positive impact on outlooks for successful development of DevOps practices. There were four main ways of communication they were trying to establish (really, everyone talking to everyone is not the best idea):

• Collaboration, based on daily routines, pieces of sprints, and other tasks - the DevOps team collaborates on daily basis using available instant communication means like Zoom, Teams, Slack channels, virtual boards. It’s important to record these efforts through JIRA or the likes.
• X-as-a-service, this model of communication is largely streamlined through dedicated ticketing system board to measure overall improvements and enhancements of the whole DevOps eco-systems put together encompassing a bunch of components/services.
• Facilitators, advocating, helping, showcasing the other teams the enhancements, introduced principles (like semantic versioning, docker image optimisation techniques), good practises and methodologies (like Trunk Based Development) or changes impacting daily routines of the other teams. Zoom & Teams.
• Writers, finding a common platform to host all necessary documentation, tagged and sorted out appropriately, supported by a search engine. So, that during any talks, discussions any good pattern to follow, any how-to write-up, design or tech structure can be found, referred to and understood broadly. A platform like Wiki would be helpful. Sharepoint is awful for this kind of stuff, but doable.

Considerations before taking on a migration

The apps

Usually there are variety of flavours and designs of the running apps across the organisation. Their architecture, technology differ from one another. Nevertheless, let’s group them up and later, propose a possible approach to tackle issues and problems associated with the modernisation and migration to the “new default” given the app’s tech stack.

Windows Realm:

• Apps developed in .Net, codebase stored in TFS, built locally on a programmer’s machine & IDE. Deployed straight to non-prod/prod WinTel server with IIS. Largely a monolithic design, lack of proper documentation. Some integration with back-end MS SQL or other MS oriented services. The apps often suffer from lack of proper documentation, standardised security controls, no automated testing, and no secure coding practises. Deployments take place occasionally with many teams around engaged to address issues.

Open Source Realm:

• Apps developed using open source stacks like popular Node.JS+Angular, and the likes. Some already docker-ized run on Docker swarm or just on a docker runtime. Most of those IDE environment consist of defined Jenkins pipelines, however there’s no clear evidence on using only declarative pipelines, some of them are outdated and or not properly maintained. Often these apps are integrated with other Open Source components like MongoDB, PostgreSQL, Kafka etc. The codebase is stored at some git driven repositories (Gitlab, BitBucket, TFS). Active development is in place, hence the support is somewhat more reliable in terms of updates, testing and upgrades. None the less, automated testing is scarce, and no coherent best practises in coding or security is in place (secrets are stored in Jenkins, git repository, local programmer’s computer etc.).

One of the most prevailing advantages of moving into containerisation in Cloud is leveraging and driving modern and secure design, programming (TDD, TBD, DDD) and continuous delivery approaches. Ensuring appropriate security are in place in both CI/CD pipelines and the developed product (security by design).

Strategies

Inspired by some white papers regarding moving-to-the-cloud strategies, some standardised approaches can be proposed given current apps states. They may be considered as a general effort for the modernisation. The 6Rs. Collectively known as the “6R of migration”. Actually some of them can be applicable in most cases:

• Retiring, you just plan decommissioning of the app and designing a new one, from scratch. Also functionality can be replaced by some other app/component(s) being already migrated or augmented by an off-the-shelf purchase to the existing IT eco-system.
• Retaining, you keep the thing as is for determined time span. As a given app is going to be replaced or phased out altogether (by “retiring” approach in future). Associated costs of maintenance as well as other apps or components this retained app integrates with, will also remain.
• Re-hosting, known as “lift and shift” approach, where you move the app as is to the new environment and new platform. Apps with long tail of technical debt will likely incur costs of maintenance to cut the tail and conform to new S-SDLC (quality and security gates).
• Refactoring - and re-architecting if the scope requires some profoundly deep changes of the applications. This approach is usually driven by a need to add features, make the app passable through the new platform quality gates, security checks, automated testing - all leveraging much quicker and transparent deployments and scalability. Refactoring often boosts agility, business continuity, shifted-left security and overall productivity through better collaboration across the teams. However, this strategy tend to be most time and resource consuming.

Best Practises

These best practises should be tirelessly propagated and advertised by the DevOps team. However, a successful migration can be achieved (where a given timeframe and assessed costs are met) through the IT organisation capabilities, which should be capable to ensure the following best practises:

Architecture:

• Precise design using modern methodologies (DDD),
• Precise and standardised design covering all functional and non-functional requirements, clear components lists, specified tech stack (compliant with approved tech stack components), concise and clear diagrams, threat model, identified risks and agreed trade-offs,
• Standardised building components and valid sources (delivery chain security),
• Statelessness of the app components - meaning that the app’s state is not retained within the app, and can be easily scaled out through orchestration platform,

Programming:

• Trunk Based Development (or further monorepo),
• Test Driven Development,
• At least two programmers in the project, to facilitate such good practises like “code review”, “secure branching”, etc.
• Semantic versioning,
• Standardised building components and IDE integrated with modern secure development components like GitGuardian, Snyk, (hashicorp vault), Docker Desktop, other SAST/SCA/DAST scanners, Sonarqube,

CI/CD:

• full automation of all repeatable steps,
• quick and comprehensive feedback from the automated components,
• unit tests, acceptance tests, integration tests, security tests, capacity/load/smoke tests etc.
• Capacity and scalability testing under various load (require business metrics the Kubernetes will act on),
• Frequent small, atomic changes to the codebase (to keep delta at manageable level and make the code reviewers life easier, not to let them review hundreds line of code changes across multiple files),
• Deployments fully transparent to the user communities.

Clear communication channels for the DevOps team:

• Team - enablers/collaborators - working together as time allows to discover and experiment with new solutions, fixes, ideas through technologies, APIs, methodologies, etc.
• Team - Platform/XaaS - provide support for multiple SDLC components - like Jenkins, GitHub, SonarQube, Nomad, Vault, etc.
• Team - Facilitating/performing - showcasing, coaching, lending hand to other teams about changes, shifts, best practises, gradual improvements.

Organisational capabilities:

• Less risk of cognitive overload, so the DevOps and other teams have comfort for deep working, learning and experimenting,
• Keeping the teams project agendas close to one another and the once formed teams are not getting disbanded too often, so that natural engagement in a project does not take long each time it starts (storming, norming, performing),
• Apps grouped up around business areas and business values, so the support teams is not required to spread their limited cognitive capacity across multiple exclusive (constantly evolving) tech stacks.

Further (good) readings

• Dave Farley’s blog should be read frequently, before you take a look at your morning news, get to Dave’s first,
• “Continuous Delivery” by Dave Farley and Jez Humble, an absolute must read!
• “Accelerate - the science of Lean Software and DevOps “ by Jez Humble, Nicole Forsgren and Gene Kim, you should know at least two out of these three names from “the Unicorn Project”,
• “Continuous Delivery blog”, principles and other varia by Jez Humble,
• “Monolith to Microservices” by Sam Newman, if you want to understand and support an old app migration,