Kto powinien ponieść konsekwencje wycieku danych, spowodowanych cyberatakiem? Te pytanie, każde przedsiębiorstwo rozpatrywało dotąd indywidualnie, jednak nowe dyrektywy międzynarodowe, dokładnie określiły kto musi zadbać o wprowadzenie praktyk bezpieczeństwa, a następnie dbać o ich egzekwowanie. Nowy trend związany z dodatkową odpowiedzialnością finansową zarządu, zapoczątkowany w Stanach Zjednoczonych, ma szansę rozprzestrzenić się na kolejne kraje.

Średnio 1000 zgłoszeń, dotyczących zagrożeń cyberbezpieczeństwa otrzymuje codziennie Zespół Reagowania na Incydenty Bezpieczeństwa Komputerowego CSIRT GOV prowadzony przez Szefa Agencji Bezpieczeństwa Wewnętrznego. Pokazuje to skalę działalności cyberprzestępców.

Celami ataków są głównie pracownicy, w tym managerowie wysokiego szczebla, którzy mają dostęp do poufnych informacji na temat przedsiębiorstwa. Według raportu „2024 Data Breach Investigations Report”, około 68% naruszeń bezpieczeństwa zawierało element ludzki, taki jak błąd użytkownika lub skuteczne ataki socjotechniczne, co pokazuje, że czynnik ludzki nadal jest kluczowym słabym ogniwem w zabezpieczeniach organizacji​.

Do tej pory trudno było ocenić, kto powinien ponieść konsekwencje cyberataku. Innowacyjny pomysł zgłosił Brad Smith, wiceprezes Microsoftu, podczas przesłuchania komisji w Izbie Reprezentantów w sprawie kwestii bezpieczeństwa firmy. Koncern stanie się jednym z pierwszych przedsiębiorstw, gdzie cyberbezpieczeństwo będzie bezpośrednio wpływało na premie dla kadry kierowniczej.

Rozszerzenie zasobów połączyliśmy z ważnymi zmianami w zarządzaniu bezpieczeństwem w firmie. Oprócz kluczowej, długoletniej roli Chief Information Security Officer (CISO), stworzyliśmy Office of the CISO z senior-level Deputy CISOs, aby rozszerzyć nadzór nad różnymi zespołami inżynieryjnymi, oceniać i zapewniać, że bezpieczeństwo jest „wbudowane” w procesy podejmowania decyzji inżynieryjnych.

Ostatecznie zmiana kultury wymaga odpowiedzialności. Jest to coś, co rozumieją wszyscy nasi senior liderzy, zaczynając od Satyi jako CEO firmy. Zamiast delegować ogólną odpowiedzialność za bezpieczeństwo na kogoś innego, przejął on tę odpowiedzialność osobiście, pełniąc rolę głównego dyrektora z pełną odpowiedzialnością za bezpieczeństwo Microsoftu.

Dlatego też ogłosiliśmy 3 maja, że część wynagrodzenia zespołu Senior Leadership Team będzie uzależniona od postępów w realizacji naszych planów i celów bezpieczeństwa. Od tego czasu pracowaliśmy nad dopracowaniem tych kroków dotyczących wynagrodzenia i innych środków odpowiedzialności na następny rok fiskalny, który zaczyna się 1 lipca[1]. – mówił Brad Smith przez Komisją Izby Reprezentantów ds. Bezpieczeństwa Wewnętrznego Stanów Zjednoczonych

Działania zapoczątkowane przez Microsoft, mają zdaniem analityków szansę stać się trendem globalnym. Jak sytuacja wygląda w Unii Europejskiej, która zwykle wprowadza zmiany wolniej niż Stany Zjednoczone?

Unijne przepisy dotyczące cyberbezpieczeństwa wprowadzone w 2016 r. zostały zaktualizowane dyrektywą NIS2, która weszła w życie w 2023 r. Zmodernizowano w niej istniejące ramy prawne, aby nadążyć za rosnącą cyfryzacją i zmieniającym się krajobrazem zagrożeń dla cyberbezpieczeństwa. Państwa UE mają obowiązek wdrożyć do 17 października tego roku, nowe wytyczne do krajowego porządku prawnego np. przy pomocy ustawy.

Według szacunków PwC, nowa dyrektywa obejmie ponad 6000 podmiotów działających w 18 sektorach gospodarki, w Polsce.[2]

W rozdziale IV dyrektywy, artykuł 20, możemy przeczytać:

1.   Państwa członkowskie zapewniają, aby organy zarządzające podmiotów kluczowych i ważnych zatwierdzały środki zarządzania ryzykiem w cyberbezpieczeństwie przyjęte przez te podmioty w celu zapewnienia zgodności z art. 21, nadzorowały ich wdrażanie i mogły być pociągnięte do odpowiedzialności za naruszanie przez te podmioty tego artykułu.

Stosowanie niniejszego ustępu nie narusza przepisów krajowych dotyczących zasad odpowiedzialności instytucji publicznych oraz odpowiedzialności urzędników publicznych oraz urzędników wybranych lub mianowanych.

2. Państwa członkowskie zapewniają, aby członkowie organu zarządzającego podmiotów kluczowych i ważnych mieli obowiązek odbywać regularne szkolenia w celu zdobycia wystarczającej wiedzy i umiejętności pozwalających im rozpoznać ryzyko i ocenić praktyki zarządzania ryzykiem w cyberbezpieczeństwie oraz ich wpływ na usługi świadczone przez dany podmiot, a także zachęcają podmioty kluczowe i ważne do oferowania podobnych szkoleń ich pracownikom.[3]

Jak widać Komisja Europejska wprowadziła zapis, w którym to kierownictwo wyższego szczebla, w tym członkowie zarządu, ponoszą odpowiedzialność za zapewnienie zgodności organizacji z wymaganiami dotyczącymi zarządzania ryzykiem cybernetycznym oraz zgłaszania incydentów. Dyrektywa nakłada obowiązek, aby osoby na stanowiskach kierowniczych zapewniały odpowiednie środki zabezpieczające i były odpowiedzialne za ich skuteczność.

Dyrektywa NIS2 objęła szeroki zakres podmiotów, zarówno publicznych, jak i prywatnych, które świadczą usługi krytyczne dla funkcjonowania społeczeństwa i gospodarki.

Podmioty objęte dyrektywą:

Podmioty podstawowe (essential entities):

• Sektory energetyczne (elektryczność, gaz, olej)
• Sektory transportowe (lotnictwo, kolej, wodny, drogowy)
• Sektory bankowe i infrastruktury rynków finansowych
• Sektory zdrowotne (szpitale, dostawcy opieki zdrowotnej)
• Woda pitna i gospodarka ściekowa
• Infrastruktura cyfrowa (dostawcy usług DNS, rejestry domen, dostawcy chmur obliczeniowych)
• Administracja publiczna (podmioty centralne i regionalne)

Podmioty ważne (important entities):

• Poczta i usługi kurierskie
• Gospodarka odpadami
• Produkcja, produkcja i dystrybucja chemikaliów
• Produkcja żywności (podmioty zajmujące się produkcją i przetwórstwem przemysłowym)
• Podmioty produkcyjne (produkcja urządzeń medycznych, komputerowych, elektronicznych, pojazdów)
• Dostawcy usług cyfrowych (platformy mediów społecznościowych, dostawcy usług wyszukiwarek internetowych)
• Organizacje badawcze

Podmioty kluczowe i ważne muszą wdrożyć odpowiednie polityki bezpieczeństwa, aby zapewnić systematyczną i dogłębną analizę ryzyka. Polityki te powinny obejmować podejście uwzględniające wszelkie możliwe zagrożenia, w tym te związane z bezpieczeństwem fizycznym (all-hazard approach). Odpowiedzialność za wdrożenie tych polityk spoczywa bezpośrednio na zarządach.

Chcesz porozmawiać o cyberbezpieczeństwie Twojej firmy? Napisz do nas

[contact-form-7]

[1] https://blogs.microsoft.com/on-the-issues/2024/06/13/microsofts-work-to-strengthen-cybersecurity-protection/

[2] https://www.pwc.pl/pl/uslugi/nis2-nowe-wymogi-dotyczace-cyberbezpieczenstwa.html

[3] https://eur-lex.europa.eu/eli/dir/2022/2555/oj

Wraz ze wzrostem liczby zagrożeń cybernetycznych, uwierzytelnianie wieloskładnikowe (MFA) stało się dla wielu firm standardem w politykach bezpieczeństwa.  MFA zwiększa ochronę, wymagając od użytkowników weryfikacji tożsamości za pomocą wielu metod. Takie uwierzytelnianie stało się więc standardową praktyk, dodając dodatkową warstwę ochrony.

Wśród różnych metod, uwierzytelnianie oparte na SMS wyróżnia się równowagą między bezpieczeństwem a wygodą użytkownika. Jednak tworzenie niestandardowego uwierzytelnienia SMS w ramach dostawcy tożsamości, takiego jak Keycloak, może być skomplikowanym i złożonym procesem, wymagającym zrozumienia jego architektury i możliwości rozszerzania.

Interfejs Dostawcy Usług (SPI)

Keycloak ma na celu obsługę większości przypadków użycia bez konieczności tworzenia niestandardowego kodu. Oferuje także elastyczność w zakresie dostosowywania. W tym celu Keycloak udostępnia kilka SPI, które pozwalają na wdrażanie własnych rozwiązań. Zamierzamy wdrożyć uwierzytelnianie, które wymaga ważnego kodu SMS. Aby stworzyć tę funkcję, musimy  zaimplementować interfejsy org.keycloak.authentication.AuthenticatorFactory i Authenticator. AuthenticatorFactory jest odpowiedzialny za tworzenie instancji Authenticatora. Oba interfejsy rozszerzają ogólny zestaw interfejsów Provider i ProviderFactory, które są używane przez inne komponenty Keycloak.

Pakietowanie klas

Będziemy pakietować nasze klasy do jednego projektu. Musi on zawierać plik o nazwie org.keycloak.authentication.AuthenticatorFactory, który powinien znajdować się w katalogu META-INF/services/. Plik ten musi zawierać pełne kwalifikowane nazwy klas każdej implementacji AuthenticatorFactory, którą masz w pliku JAR. Na przykład:

pl.inero.keycloakext.authenticator.sms.SmsAuthenticatorFactory
pl.inero.keycloakext.authenticator.custom.CustomUsernamePasswordFormFactory
pl.inero.keycloakext.authenticator.custom.CustomCookieAuthenticatorFactory

Plik services/ jest używany przez Keycloak do skanowania dostawców, których musi załadować do systemu.

CredentialModel i CredentialProvider

Pierwszym krokiem jest skonfigurowanie naszych klas związanych z poświadczeniami, ponieważ numer telefonu użytkownika powinien być przechowywany jako rekord poświadczeń. Jak widać poniżej, klasa Sms2faCredentialData jest prostym kontenerem danych do przechowywania numeru telefonu powiązanego z użytkownikiem.

public class Sms2faCredentialData {

private String phoneNumber;

@SuppressWarnings("unused") //used for credentials deserialization
public Sms2faCredentialData() {
}

public Sms2faCredentialData(String phoneNumber) {
     this.phoneNumber = phoneNumber;
}

public String getPhoneNumber() {
     return phoneNumber;
}

@SuppressWarnings("unused") //used for credentials deserialization
public void setPhoneNumber(String phoneNumber) {
     this.phoneNumber = phoneNumber;
}
}

Kolejnym krokiem jest rozszerzenie klasy CredentialModel, która może generować prawidłowy format poświadczeń w bazie danych. Aby obiekty Sms2faCredentialModel były w pełni funkcjonalne, muszą zawierać nie tylko surowe dane JSON odziedziczone po klasie bazowej, ale także odmarshallowane obiekty wewnątrz swoich własnych atrybutów. Zapewnia to szeroką dostępność i wykorzystanie poświadczeń, umożliwiając łatwą integrację i obsługę procesów uwierzytelniania.

public class Sms2faCredentialModel extends CredentialModel {

public static final String TYPE = "sms2fa";
private Sms2faCredentialData smsCredentials;

public Sms2faCredentialModel(Sms2faCredentialData smsCredentials) {
     try {
         this.smsCredentials = smsCredentials;
         setCredentialData(JsonSerialization.writeValueAsString(smsCredentials));
         setUserLabel("tel: " + smsCredentials.getPhoneNumber());

         setType(TYPE);
     } catch (IOException e) {
         throw new RuntimeException(e);
     }
}

public String getPhoneNumber() {
     return smsCredentials.getPhoneNumber();
}
}

Podobnie jak w przypadku innych dostawców w Keycloak, utworzenie CredentialProvider wymaga obecności odpowiadającej mu CredentialsProviderFactory. Aby spełnić ten wymóg, implementujemy Sms2faCredentialProviderFactory.

public class Sms2faCredentialProviderFactory  implements CredentialProviderFactory<Sms2faCredentialProvider> {

public static final String PROVIDER_ID = "keycloak-ext-sms2fa";

@Override
public String getId() {
     return PROVIDER_ID;
}

@Override
public CredentialProvider<Sms2faCredentialModel> create(KeycloakSession session) {
     return new Sms2faCredentialProvider(session);
}
}

Interfejs CredentialProvider jest zbudowany z parametrem generycznym, który rozszerza CredentialModel, zapewniając kompatybilność z różnymi typami poświadczeń. Dodatkowo musimy zaimplementować interfejs CredentialInputValidator, co wskazuje Keycloak, że ten dostawca jest przygotowany do uwierzytelniania poświadczeń dla naszego niestandardowego Authenticatora. Chociaż nie będziemy tu omawiać pełnej architektury, dokumentacja Keycloak obejmuje dodatkowe metody.

Nasza implementacja obejmuje funkcje tworzenia i usuwania poświadczeń. Funkcje te wykorzystują menedżera poświadczeń, odpowiedzialnego za przechowywanie i pobieranie poświadczeń, niezależnie od tego, czy są one przechowywane lokalnie, czy w systemach magazynowania federacyjnego.

@Override
public CredentialModel createCredential(RealmModel realm, UserModel user, Sms2faCredentialModel credentialModel) {
if (credentialModel.getCreatedDate() == null) {
     credentialModel.setCreatedDate(Time.currentTimeMillis());
return user.credentialManager().createStoredCredential(credentialModel);
}

@Override
public boolean deleteCredential(RealmModel realm, UserModel user, String credentialId) {
logger.debugv("Delete Sms2fa credential. username = {0}, credentialId = {1}", user.getUsername(), credentialId);
return user.credentialManager().removeStoredCredentialById(credentialId);
}

Dla interfejsu CredentialInputValidator główną metodą do zaimplementowania jest isValid, która sprawdza, czy dane poświadczenie jest ważne dla danego użytkownika w danej domenie (realm). Jest to metoda wywoływana przez Authenticator, gdy chce zweryfikować dane wprowadzone przez użytkownika.

@Override
public boolean isValid(RealmModel realm, UserModel user, CredentialInput credentialInput) {
final Sms2faCredentialModel credentialModel = getDefaultCredential(session, realm, user);
final String secretData = credentialModel.getSecretData();
return secretData != null && secretData.equals(credentialInput.getChallengeResponse());

Teraz powinniśmy mieć wszystko, aby móc przejść do implementacji samego Authenticatora.

AuthenticatorFactory i Authenticator

Klasa SmsAuthenticatorFactory zawiera logikę potrzebną do skonfigurowania i tworzenia instancji SmsAuthenticator, który wykonuje walidację OTP opartą na SMS. Obsługuje dostosowywanie poprzez kilka konfigurowalnych właściwości.

supports customization through several configurable properties.
public class SmsAuthenticatorFactory implements AuthenticatorFactory {

@Override
public String getId() {
     return "sms-authenticator";
}

@Override
public String getDisplayType() {
     return "SMS Authentication";
}
@Override
public String getHelpText() {
     return "Validates an OTP sent via SMS to the users mobile phone.";
}
     (…)
}

Teraz przejdźmy do samego Authenticatora. Główna metoda, na której się skupimy, to sendChallenge(). Kiedy przepływ jest początkowo wyzwalany, ta metoda jest wywoływana. Ważne jest, aby zauważyć, że nie obsługuje ona przetwarzania formularza kodu SMS. Jej rola polega na renderowaniu strony lub kontynuowaniu przepływu.

Strona HTML, która prosi o wprowadzenie otrzymanego kodu, jest prezentowana użytkownikowi, który następnie wprowadza kod i przesyła go. Wówczas wysyłane jest żądanie HTTP do przepływu za pomocą adresu URL akcji określonego w formularzu HTML. To wyzwala metodę action() w naszej implementacji Authenticatora. Jeśli podany kod jest nieprawidłowy, rekonstruujemy formularz HTML, dodając komunikat o błędzie. Następnie używamy metody failureChallenge(), przekazując powód niepowodzenia. Działa ona podobnie do challenge(), ale dodatkowo loguje błąd, co pomaga wykryć ewentualne możliwości ataku.

private void sendChallenge(AuthenticationFlowContext context) {
(…)
credentialModel.setSecretData(code);
user.credentialManager().updateStoredCredential(credentialModel);
AuthenticationSessionModel authSession = context.getAuthenticationSession();
authSession.setAuthNote("ttl", Long.toString(System.currentTimeMillis() + (ttl * 1000L)));

try {
     /* sending SMS */
     context.challenge(context.form().setAttribute("realm", context.getRealm()).createForm(TPL_CODE));
} catch (Exception e) {
     context.failureChallenge(AuthenticationFlowError.INTERNAL_ERROR,
             context.form().setError("smsAuthSmsNotSent", e.getMessage())
                     .createErrorPage(Response.Status.INTERNAL_SERVER_ERROR));
}
}

@Override
public void action(AuthenticationFlowContext context) {
(…)
final Sms2faCredentialModel credentialModel = getCredentialProvider(session).getDefaultCredential(session, context.getRealm(), user);
boolean isValid = getCredentialProvider(context.getSession()).isValid(context.getRealm(), context.getUser(),
       new UserCredentialModel(credentialModel.getId(), getCredentialProvider(context.getSession()).getType(), enteredCode));
if (isValid) {
     if (Long.parseLong(ttl) < System.currentTimeMillis()) {
         // expired
         context.failureChallenge(AuthenticationFlowError.EXPIRED_CODE,

                 context.form().setError("smsAuthCodeExpired").createErrorPage(Response.Status.BAD_REQUEST));
     } else {
         // valid
         context.success();
     }
} else {
     context.getEvent().user(user).error(Errors.INVALID_USER_CREDENTIALS);
     context.failureChallenge(AuthenticationFlowError.INVALID_CREDENTIALS,
             context.form().setAttribute("realm", context.getRealm())
                     .setError("smsAuthCodeInvalid").createForm(TPL_CODE));
}
}

Authentication Flow

Aby dodać Authenticator do przepływu, administrator musi przejść do Konsoli. W sekcji Uwierzytelnianie (Authentication) i zakładce Przepływy (Flows) powinien zobaczyć istniejące przepływy. Wbudowane przepływy nie mogą być bezpośrednio modyfikowane, więc aby zintegrować nowo utworzony Authenticator, musimy albo zduplikować istniejący przepływ, albo stworzyć nowy od podstaw.

Required actions

Jeśli telefon nie jest skonfigurowany, powinniśmy wywołać niestandardowe wymagane działanie. Ponownie, powinniśmy dodać pełną kwalifikowaną nazwę klasy do katalogu META-INF/services i zaimplementować interfejs RequiredActionProvider. Metoda requiredActionChallenge() jest odpowiedzialna za renderowanie HTML, który poprowadzi wymagane działanie.

@Override
public void requiredActionChallenge(RequiredActionContext context) {
LoginFormsProvider form = context.form();
if (getSmsAuthenticatorConfig(context) == null) {
     form.setError("smsAuthMissingAuthenticatorConfig");
}
final Response response = form.createForm("sms-2fa-register.ftl");
context.challenge(response);
}

Ta część jest odpowiedzialna za przetwarzanie danych wejściowych z formularza HTML wymaganego działania. Po wprowadzeniu otrzymanego kodu SMS, numer telefonu powinien zostać zapisany w bazie danych jako poświadczenie. Przy następnym logowaniu będziemy mogli skorzystać z tej formy OTP.

@Override
public void processAction(RequiredActionContext context) {
    (…)
final String phoneNumber = params.getFirst("phoneNumber");
final String code = params.getFirst("code");

if(StringUtils.isBlank(phoneNumber) && StringUtils.isBlank(authSession.getAuthNote("phone_number"))) {
     //if no phone number is set, redirect to the first page
     requiredActionChallenge(context);
     return;
}
if (phoneNumber != null) {
     sendPhoneNumberVerificationChallenge(context, authSession, phoneNumber, smsAuthenticatorConfig.getConfig());
     return;
}
if (code != null) {
     /* verify provided SMS code */ 
    }
}

Ostatnią rzeczą, którą musisz zrobić, jest przejście do Konsoli Administratora i zakładki Wymagane Działania (Required Actions). Twoje nowe działanie powinno teraz być wyświetlone i włączone na liście wymaganych działań.

Jeśli użytkownik nie podał wcześniej numeru telefonu, a uwierzytelnianie SMS jest ustawione jako wymagane w przepływie uwierzytelniania, powinna pojawić się nowa widok.

Podsumowując, konfiguracja SMS MFA obejmuje ustawienie niestandardowych wymaganych działań oraz dostawców uwierzytelniania, ale oczywiście istnieją inne kwestie do uwzględnienia, takie jak komunikacja między Keycloak a bramką SMS. Zagadnienia, które omówiliśmy w tym poście, to oczywiście tylko część możliwej konfiguracji, ale najważniejsza i specyficzna dla Keycloak.

Jedną z istotnych zalet wdrożenia SMS MFA jest jego powszechna dostępność, ponieważ większość użytkowników posiada telefony komórkowe zdolne do odbierania wiadomości SMS. Dodatkowo, zapewnia to prostą obsługę dla użytkowników, wymagając minimalnej konfiguracji i znajomości. Jednak mechanizm ten ma swoje wady, w tym potencjalne zagrożenia, takie jak ataki polegające na zamianie kart SIM lub przechwytywaniu kodów SMS. Ponadto, dostarczanie wiadomości SMS może czasami być zawodnym procesem, co prowadzi do opóźnień lub nieudanej dostawy, wpływając na doświadczenie użytkownika. Powinniśmy być tego świadomi przed podjęciem decyzji o zastosowaniu tej metody, szczególnie w erze nowszych rozwiązań, takich jak mobilne aplikacje OTP.