Security für Admin-Accounts

[testperson 1.675]

vor 9 Minuten schrieb MurdocX:

• Sammeln (und auswerten) der Logs der Netzwerkkomponenten

 

Und hier wird es meiner Meinung nach nicht nur im KMU "schwierig". Das Sammeln passiert sicherlich 24/7. -> Das Auswerten auch? -> Jetzt gibt es ja entsprechende MDR und/oder SOC (as a Service) Lösungen. -> Ist ein passender / sind passende Entscheider 24/7 auf Abruf verfügbar? -> Ist ein passender / sind passende Techniker 24/7 verfügbar, um den Entscheidungen Taten folgen zu lassen?

 

Natürlich ist es hilfreich am nächsten (Werk) Tag die Info zu haben, dass es verdächtige Aktivitäten gab/gibt. Aber ob es dann nicht bereits zu spät ist?

[MurdocX 949]

vor 13 Minuten schrieb testperson:

Natürlich ist es hilfreich am nächsten (Werk) Tag die Info zu haben, dass es verdächtige Aktivitäten gab/gibt. Aber ob es dann nicht bereits zu spät ist?

Das Thema wird man sicherlich nicht vom Tisch bekommen.

 

Auch die Frage für welchen - gefühlt macht jeder etwas Größere SOC - Dienstleister man sich im Endeffekt entscheidet. Sind die Mitarbeiter gut geschult? Ist Regelwerk auch gut ausgearbeitet, um das Verhalten zwischen den vielen False/Postive herauszufiltern?

[v-rtc 88]

vor 1 Stunde schrieb MurdocX:

 

Falls du unterfordert sein solltest, hier wären noch weitere Themen zum anknüpfen:

• Supportete u. mit aktueller Firmware Netzwerkkomponenten
• Sammeln (und auswerten) der Logs der Netzwerkkomponenten
• Härten der Netzwerkkomponenten
• Blick auf die Passwortrichtlinien werfen
• Regelmäßiges wechseln der Admin- u. Service-User Passwörter (krbtgt nicht vergessen...)
• Authentifizierungsrichtlinien für Service-User (FGPP)
• Nicht benötigte SPNs entfernen
• Umgebung auf AES128 umstellen (RC4 deaktivieren)
• Beschränken der Berechtigungen zum Erstellen von Tasks
• Schwachstellen-Management (und ja, das macht Arbeit ;) )
• NTLM beschränken
• HVCI (und auch aktuell halten)
• Näheren Blick auf CIS u. STIGs werfen
• Updatestand auf den Servern und Clients aktuell halten

Coole Liste. Härten der Netzwerkgeräte bedeutet unnötige Zeilen entfernen oder gibt es da noch mehr? Mein Wissen ist leider von 2017 noch…und ja Schwachstellenmgmt ist ein riesiger Aufwand :-(

[MurdocX 949]

vor 1 Minute schrieb v-rtc:

Härten der Netzwerkgeräte bedeutet unnötige Zeilen entfernen oder gibt es da noch mehr?

Viele Hersteller bieten etwas (bspw.):

• Cisco - Cisco Leitfaden zur Härtung von Cisco IOS-Geräten - Cisco
• HP - ArubaOS-Switch Hardening Guide for 16.06 (hpe.com)

Ergänzend würde ich mir die Richtlinien von CIS noch ansehen.

 

vor 8 Minuten schrieb v-rtc:

Mein Wissen ist leider von 2017 noch…und ja Schwachstellenmgmt ist ein riesiger Aufwand :-(

Hier ist die Taktik "Weniger ist Mehr"

 

[Gulp 254]

vor einer Stunde schrieb MurdocX:

.....

 

Hier ist die Taktik "Weniger ist Mehr"

 

 

Weniger Management oder weniger Schwachstellen? Wenn man sich mal so umschaut, kanns ja fast nur ersteres sein ........

 

Grüsse

 

Gulp

[MurdocX 949]

Meine persönliche Überraschung beim Schwachstellen-Management war die riesige Anzahl an Schwachstellen und deren Alter. Bei uns gab es eine 14 Jährige alte Adobe-Schwachstelle.

 

vor 5 Stunden schrieb Gulp:

Weniger Management oder weniger Schwachstellen?

Weniger Anwendungen = weniger Schwachstellen = weniger Management

bearbeitet 11. Februar von MurdocX

[NilsK 2.934]

Moin,

 

vor 18 Stunden schrieb MurdocX:

Bei uns gab es eine 14 Jährige alte Adobe-Schwachstelle

 

Vorsicht, 14-Jährige dürft ihr gar nicht beschäftigen!

 

Gruß, Nils

 

[wznutzer 35]

vor 22 Stunden schrieb MurdocX:

Falls du unterfordert sein solltest, hier wären noch weitere Themen zum anknüpfen:

Gute Liste. Ich habe mich z. B.  gegen das ständige Wechseln der Passwörter entschieden und wo möglich gMSA-Konten verwendet (ich hoffe korrekt konfiguriert ). Dafür lange, komplexe Passwörter per Richtlinie und Account-Lockout.

 

Gerade das Auswerten von Logs hat mich auch schon beschäftigt, also das Erkennen wenn etwas passiert ist. Security Onion finde ich gut, werde ich wahrscheinlich demnächst produktiv einsetzen. Dauerhaft darf es aber nicht zu oft Alarm geben, wenn nichts ist.

 

Wenn man Veeam einsetzt, kann man z. B. mit Sure-Backup die Backups automatisiert offline scannen, wenn der Scanner per Kommandozeile gesteuert werden kann. Wer mag kann den Scanner von Nextron probieren, macht mir aber zu viele Fehlalarme.

 

Jetzt sind wir zwar etwas von "Security für Admin-Accounts weg", aber trotzdem interessant.

[StefanWe 14]

Toller Thread, ich hoffe noch nicht zu alt. 
wir haben das Tier Modell bei uns auch umgesetzt. Bis ich die alten Hasen erklärt habe, warum wir das tun, sind schon Monate vergangen. Der ein oder andere sagt heute noch, das die Arbeit kaum zu erledigen ist, weil der Verwaltungsoverhead enorm ist. 
 

Tier0 ist simpel. Bei Tier 1 und 2 wird’s haarig. Gerade Tier2. Wir haben dem normalen Useraccount das Tier2 Recht gegeben. Damit ist halbwegs normales arbeiten möglich. Nicht gut, ich weiß. 
 

paws haben wir noch nicht eingeführt, weil schlicht noch kein sauberes Konzept vorliegt, wie man auch aus dem Home Office diese nutzen kann. 
 

richtig Grenzwertig wurde es als wir 2 FA für die Tier User eingeführt haben. Zu erst mit Yubico als Smartcard. 
das geht aber nur sauber, wenn überall der yubico minidriver installiert wird. Da wir noch xp clients in der Produktion haben, hat uns dass das durchgängige Konzept verhagelt. Auch wollten wir nicht auf jedem Server den Treiber installieren. Ende vom Lied, kein durchgängiges Konzept, alle unzufrieden.

 

als Lösung haben wir dann Silverfort gekauft, geniale Lösung. Auf einmal war jeder Netzwerkzugriff mit 2fa geschützt. Einzig, cached Credentials können es für die lokale Anmeldung außer Kraft setzen. 
 

Aber genau das war nun das Problem mit den eigenen Workstations. So richtig glücklich sind wir damit auch nicht. 
achja, die Tier1 Admins in die Protected User Gruppe aufnehmen? Schlechte Idee, wenn man Radius zur Anmeldung an den Switchen verwendet. Geht dann nämlich nicht mehr. 
 

also, eigener User zur Verwaltung der Switche?

 

@wznutzer bei Service Accounts regelmäßig die Kennwörter zu ändern halte ich für nicht realistisch, jedenfalls nicht, wenn die IT normal bis unterbesetzt ist. 

 

das Thema ist so unfassbar komplex, es gibt nicht die eine Lösung. Aber sich damit zu beschäftigen und so viel wie möglich umzusetzen, ist schon mal ein sehr guter Schritt. 
 

@daabm mit welchen Usern verbindet ihr euch über cyberark mit den Servern? Gibt es da einen generellen Account und ihr verbindet euch mit dem persönlichen gegen cyberark? 

bearbeitet 24. April von StefanWe

[daabm 1.354]

Ein Account für CyberArk und individuelle Tresore mit den Zielaccounts.

[falkebo 21]

Am 2.2.2024 um 11:32 schrieb soulseeker:

Die Frage kommt jetzt vielleicht etwas plump daher, aber mich würde mal interessieren, wie es bei anderen Firmen/IT-Abteilungen so läuft, wenn es um das Thema Security geht. Hier ist das Thema seit einiger Zeit sehr hoch aufgehangen, daher habe ich persönlich so ziemlich mit allen den genannten Themen zu tun, was einem das administrative Leben natürlich nicht einfacher macht.

 

 

Aus meiner Sicht ist es ganz wichtig zu verstehen, dass solche Projekte komplex, umfangreich und zwingend erforderlich sind.

 

Mehrere Perspektiven dazu.

• In über 35 schwerwiegenden Security Vorfällen die ich in den letzten 4 Jahren bearbeitet habe, gab es nur einen Kunden der ein Tiering implementiert hatte (leider lückenhaft).
• In über 20 durchgeführten Pentests sind wir immer Domain Admin geworden, bis auf einen einzigen Kunden. Das war auch der einzige Kunde der das Tiering Konzept inkl. PAWs (und anderen Komponenten) richtig umgesetzt hat.

Da ich bei Kunden (von 300 Mitarbeitern bis 50.000) schon solche Konzepte erarbeitet und umgesetzt habe, kann ich dir sagen, dass es unerlässlich ist ein solches Konzept zu erstellen. Abgesehen vom Tiering gibt es noch viel mehr Komponenten die hier zusammenspielen, damit das AD robust aufgebaut wird.

[v-rtc 88]

vor 4 Minuten schrieb falkebo:

 

Aus meiner Sicht ist es ganz wichtig zu verstehen, dass solche Projekte komplex, umfangreich und zwingend erforderlich sind.

 

Mehrere Perspektiven dazu.

• In über 35 schwerwiegenden Security Vorfällen die ich in den letzten 4 Jahren bearbeitet habe, gab es nur einen Kunden der ein Tiering implementiert hatte (leider lückenhaft).
• In über 20 durchgeführten Pentests sind wir immer Domain Admin geworden, bis auf einen einzigen Kunden. Das war auch der einzige Kunde der das Tiering Konzept inkl. PAWs (und anderen Komponenten) richtig umgesetzt hat.

Da ich bei Kunden (von 300 Mitarbeitern bis 50.000) schon solche Konzepte erarbeitet und umgesetzt habe, kann ich dir sagen, dass es unerlässlich ist ein solches Konzept zu erstellen. Abgesehen vom Tiering gibt es noch viel mehr Komponenten die hier zusammenspielen, damit das AD robust aufgebaut wird.

Kannst Du noch ein bisschen mehr erzählen aus dem Nähkästchen? 
Mich würde interessieren, was so die häufigsten Fehler waren… und was Du mit Lückenhaft meinst… und welche Komponenten ebenfalls wichtig wären? Habe bisher nie die Unterstützung für sowas bekommen … :-( aber Zeiten ändern sich ☺️

[daabm 1.354]

Es gibt nicht "den" häufigsten Fehler, aber ganz vorne dabei: Fehlerhafte ACLs auf höher berechtigten Konten (gMSA - das ist uns bspw passiert...), lateral Movement, vertical Movement. Und fehlende Koordination zwischen verschiedenen Teams und auch innerhalb eines Teams.

 

Das mit dem gMSA war ein echter Anfängerfehler - Teammember, die überwiegend den operativen Teil abdecken, haben den gMSA etabliert für Splunk. Und dabei die Tier-Trennung übersehen - allowedToRetrievePassword: Domain Computers. b***d dabei nur: Der wurde auch für Domain Controller genutzt. Zack bist Du pwned.

 

"Selber suchen" ist IMHO übrigens sinnlos - man ist da leider betriebsblind und hat weder einen strukturierten Angriffsplan noch ausreichend ungestörte Zeit.

[v-rtc 88]

vor 2 Stunden schrieb daabm:

Es gibt nicht "den" häufigsten Fehler, aber ganz vorne dabei: Fehlerhafte ACLs auf höher berechtigten Konten (gMSA - das ist uns bspw passiert...), lateral Movement, vertical Movement. Und fehlende Koordination zwischen verschiedenen Teams und auch innerhalb eines Teams.

 

Das mit dem gMSA war ein echter Anfängerfehler - Teammember, die überwiegend den operativen Teil abdecken, haben den gMSA etabliert für Splunk. Und dabei die Tier-Trennung übersehen - allowedToRetrievePassword: Domain Computers. b***d dabei nur: Der wurde auch für Domain Controller genutzt. Zack bist Du pwned.

 

"Selber suchen" ist IMHO übrigens sinnlos - man ist da leider betriebsblind und hat weder einen strukturierten Angriffsplan noch ausreichend ungestörte Zeit.

Vielen Dank für die Offenheit 👍 ja Betriebsblind ist nicht schön.

[daabm 1.354]

Gern geschehen. Lösung des gMSA-Fehlers übrigens: Es gibt pro Benutzerdatenbank einen eigenen Account. Soll heißen: Alle DCs nutzen gemeinsam einen gMSA, und auf allen Membern ist es ein computerlokaler Account mit individuellem Zufallskennwort, das niemand kennt. Wird bei der Agent-Installation ausgewürfelt, auf dem Account gesetzt und in der Service-Konfig eingetragen, dann weggeworfen.

(g)MSA pro Member wäre auch noch ok, ein gMSA für eine große Gruppe von Membern schon nicht mehr (lateral movement...).