aangezien organisaties werken om de productiviteit van werknemers op afstand te garanderen, zal het probleem van in de cache opgeslagen referenties onvermijdelijk verschijnen, wat een probleem veroorzaakt voor de getroffen gebruiker en de IT-Servicedesk.

Het is geen geheim dat een materieel deel van bijna elke workforce op afstand functioneert. U hebt de afgelopen maanden hard gewerkt om externe connectiviteit, cloud-gebaseerde productiviteit en een of andere vorm van allesomvattende beveiliging tot stand te brengen.dit alles om uw externe medewerkers in staat te stellen hun werk te doen en tegelijkertijd zo goed mogelijk te voldoen aan de vereisten van corporate governance op het gebied van beveiliging en compliance. Maar met ongeveer 40% van de externe werknemers met behulp van zakelijke apparaten tijdens het werken vanuit huis, er is een probleem dat kan net om de hoek dat is waarschijnlijk op het punt van steeds een probleem dat die subset van uw gehele externe werknemers zal betrekken – vervallen lokaal gecached referenties.

voor degenen die er nieuw in zijn en niet bekend zijn met lokaal opgeslagen referenties, hier is de zeer korte primer: omdat de gebruiker op afstand is, kunnen ze niet gemakkelijk (of helemaal niet) verbinding maken met een domeincontroller (DC) op het bedrijfsnetwerk. Zo, Windows Houdt een kopie van de referenties van de gebruiker in de cache op het lokale apparaat en de gebruiker kan vrij inloggen lokaal terwijl op afstand zonder verbinding te maken met het bedrijfsnetwerk. Ondanks Microsoft het doden van de eis om gebruikers te verplichten om wachtwoorden vaak te veranderen, zijn er nog steeds scenario ‘ s waar wachtwoorden moeten worden gereset:

• Oud beleid blijft op zijn plaats en een wachtwoord verloopt
• de credential van de gebruiker wordt verdacht gecompromitteerd te zijn door insiderdreiging of cyberaanval en moet administratief worden gereset
• het huidige wachtwoord wordt gevonden met behulp van een gecompromitteerd/uitgelekt wachtwoord en wordt administratief gereset
• de gebruiker vergeet zijn wachtwoord (zoals in, het is zo lang gecached, ze weten niet eens wat het is)

de probleem bij de hand is wanneer het wachtwoord moet worden hersteld op de Active Directory kant van de vergelijking, hoe werkt u de referenties in de lokale cache? De getroffen gebruiker moet worden aangesloten op het bedrijfsnetwerk (met name op een domeincontroller (DC)) om een nieuw ingestelde set referenties-cache lokaal. Nu, sommigen van jullie zijn al voor mij denken, ” mijn gebruikers gebruiken een VPN en zijn, daarom, logisch op het netwerk, dus we zijn prima.”Maar volgens een recente studie van Proofpoint, slechts 39% van de gebruikers hebben een VPN geïnstalleerd en slechts 47% van die mensen gebruiken het consequent. Daarnaast zijn veel VPN-verbindingen met de DC tot stand gebracht na het inloggen, dus niet alle mogelijke scenario ‘ s die zich kunnen voordoen zullen worden opgelost zonder IT-ondersteuning.

kortom, uiteindelijk zal het probleem van lokaal in de cache opgeslagen referenties je inhalen.

dus, wat zijn uw opties om verlopen referenties bij te werken, en wat zijn de beveiliging vertakkingen voor elk?

ten eerste, omdat het probleem dat we oplossen is dat het externe eindpunt apparaat de in de cache opgeslagen referenties moet bijwerken, is het onderliggende proces grotendeels hetzelfde: Het apparaat moet logisch worden aangesloten op het bedrijfsnetwerk (opnieuw, specifiek met toegang tot een DC) via VPN, en zal moeten (ervan uitgaande dat je Windows 10) druk op Ctrl-Alt-Del en kies een wachtwoord wijzigen.

bij het zien van dit proces in praktische toepassing, zijn er een paar scenario ‘ s te overwegen rond het bijwerken van lokaal gecached referenties en hoe elk van invloed is op bedrijfsveiligheid en IT.

1. Bekend, Niet-verlopen wachtwoord, in staat om verbinding te maken – dit is de gouden standaard van mogelijke scenario ‘ s. De tech-savvy gebruiker maakt gewoon verbinding met de VPN, en verandert hun wachtwoord, en gaat over hun dag. Puur nirvana.

2. Bekend, verlopen wachtwoord, niet in staat om verbinding te maken – zonder derde partij wachtwoord reset oplossingen, de VPN is hier een vereiste. De servicedesk gaat worden betrokken om te helpen bij het vergemakkelijken van ten minste de “verbinding maken met het bedrijfsnetwerk”, door handmatig resetten van hun wachtwoord om de bestaande als een potentiële oplossing en het hebben van hen veranderen het onmiddellijk, wat kan inhouden helpen met het vinden van de sleutels die nodig zijn om een wachtwoord te veranderen.

3. Onbekend wachtwoord-zetten de connectiviteit probleem opzij, dit is waar echte veiligheidsrisico begint. Wanneer gebruikers niet weten wat hun wachtwoord is om te beginnen, het vereist uiteraard een eerste reset door de servicedesk, en vervolgens een wachtwoord te wijzigen bij de eerste aanmelding, net als het scenario hierboven. Het beveiligingsrisico komt in de vorm van het identificeren van de gebruiker als de eigenaar van de referenties voordat het overhandigen van het reset wachtwoord. In het eerste scenario ten minste, ze wisten het oude wachtwoord, hoewel niet een zeer veilige verificatiemethode het is een begin. Dus, in dit geval, zonder enige vorm van een tweede authenticatie factor die verder gaat dan: “wie is dit?”of” wat is je werknemers-ID?”is echt riskant.

4. Geforceerde Reset-in gevallen waarin het dwingt een reset van de referenties van een gebruiker (opnieuw, als gevolg van problemen zoals vermoeden dat het is gecompromitteerd door cyberaanval), de handeling van het werken met de gebruiker om een nieuw reset wachtwoord te communiceren moet een aantal zeer specifieke en veilige vorm van het valideren van de eigenaar van de referenties te betrekken voordat het overhandigen van het reset wachtwoord.

credential in de cache bijwerken correct

het probleem hier is tweeledig, credentials in de cache zullen uiteindelijk leiden tot een toename in IT-ondersteuning oproepen en verlies in productiviteit maar er is een beveiligingsprobleem bij de hand hier. De overdracht tussen de gebruiker die beweert de eigenaar van de credential te zijn en de servicedesk agent die een tijdelijk wachtwoord moet afgeven om de credential-update te vergemakkelijken, kan een organisatie blootstellen aan aanvallen.

gebruikers binnen uw organisatie hebben verschillende toegangsniveaus en daardoor een inherent risico. Dus, toe te voegen aan de mix hier dat degenen met verhoogde niveaus van toegang tot gevoelige, eigen, en anderszins waardevolle informatie veel meer validatie dan een van de simplistische methoden vaak gebruikt bij de IT-Servicedesk nodig.

Het bijwerken van de referenties in de lokale cache is een beveiligingsprobleem. En de beste beveiliging is degene die de gebruiker niet weet. Voeg daaraan toe, de beste oplossing is degene die het niet nodig om betrokken te raken met. Het is duidelijk, uit de bovenstaande scenario ‘ s, het scenario met een proactieve, tech-savvy gebruiker voldoet aan de criteria. Maar dat is meestal niet de realiteit. Zo, Er kan een noodzaak om te kijken naar derden wachtwoord self-service oplossing die integreren met de Windows-logon proces om te helpen vereenvoudigen van de drie onbekenden die ik heb vermeld in dit artikel: technische bekwaamheid van de gebruiker, hun vermogen om verbinding te maken met het bedrijfsnetwerk, en het is de mogelijkheid om de persoon die een wachtwoord reset te valideren is in feite de eigenaar van de referenties.

zonder enige oplossing van derden is het antwoord eenvoudig: VPN, Wijzig het wachtwoord. Als dat over het algemeen niet haalbaar is, raad ik u aan om te zoeken naar een oplossing die voldoet aan uw externe medewerkers waar ze zijn, terwijl het helpen om de productiviteit en bedrijfsveiligheid te behouden.