FBI helpt bedrijven hackers te ontmoedigen door het planten van nepdata

Uit een gelekt document blijkt dat de FBI een beveiligingsprogramma heeft opgezet voor bedrijven, waarbij nepdata op de servers wordt gezet. Dit moet zorgen voor verwarring bij inbrekers, en voorkomen dat er belangrijke bedrijfsgegevens worden gestolen.

Het programma is niet door de FBI aangekondigd, maar kwam naar buiten via Ars Technica. De site heeft een document ingezien waarin wordt uitgelegd hoe de Amerikaanse autoriteiten bedrijven helpen om hackers buiten de deur te houden, waarna bevestiging volgde via een woordvoerder van de FBI. Het programma heet IDLE, en staat voor Illicit Data Loss Exploitation.

Via IDLE helpt de FBI onder meer om bedrijven nepdata op hun servers te laten zetten, gemaakt op basis van echte bedrijfsgegevens en verweven in de bestaande bestandsstructuren. Dat moet ervoor zorgen dat hackers niet weten welke gegevens ze kunnen vertrouwen als ze die bij een hack buitmaken. Ook moet het plaatsen van 'lokaas' helpen om indringers op de servers op te sporen. Dat kan bijvoorbeeld als de gegevens elders op het web opduiken. Overigens is het niet de bedoeling dat de FBI de bedrijfsservers monitort; dat moeten de bedrijven zelf doen.

Ook nemen de autoriteiten proactief contact op met bedrijven als zij denken dat er gevaar dreigt. Waarbij er in het verleden met name werd gewacht tot er een hack plaatsvond, probeert de FBI nu juist van tevoren in te grijpen, om de impact van een mogelijke hack te beperken.

Door RoD

Admin Mobile

22-12-2019 • 11:31

89 Linkedin

Reacties (89)

89
84
46
1
0
11
Wijzig sortering
Het klinkt zo omslachtig en arbeidsintensief dat ik me afvraag of dit echt een effectieve manier is om je beveiligingsbudget in te zetten. Je moet die nepdata immers produceren, opslaan, backuppen, monitoren, etc. En het is ook maar beperkt bruikbaar. Een groot lek van nepdata kan nog steeds imagoschade opleveren als het grote publiek (net als de hackers) denkt dat het echt is.
Valt reuze mee qua arbeid. Dit kan heel goed geautomatiseerd worden. Sterker nog, dit is een onderdeel van een van mijn recent ontwikkelde projecten. Het meest lastige is niet de techniek maar het zorgen dat het effectief wordt ingezet :)
Moeten de desbetreffende bestanden ook niet worden geflagged worden als zijnde safe?
Of begrijp ik het verkeerd? De bestanden zouden in principe ook een tracker of iets dergelijk kunnen bevatten om de source van de aanval terug te kunnen traceren. Maar *hier komt de paranoia” zou dan ook weer door de FBI/NSA/... kunnen gebruikt worden om intern nog eens de boel in de gaten te kunnen houden...
Ik denk dat de hackers waar dit voor bedoeld is in alle gevallen weten wat ze aanvallen en wat het plan is. Een dergelijke valse server heeft vast wel een signature die je binnenkort van tig locaties kan ophalen.

In hoeverre hou je de illusie overeind? Alleen al alle aanmaak- en wijzigingsdata voor de bestanden regelen zodat dat daar niks aan opvalt lijkt me best veel werk.

[Reactie gewijzigd door blorf op 22 december 2019 16:25]

Heb je een punt, als hacker monitor je het traffic, dan kan heel snel duidelijk worden dat bepaalde data nooit gelezen of gewijzigd wordt.

Een geloofwaardige datum voor creatie en modificatie geven is niet zo lastig. Zorgen dat het zich continu gedraagt zoals bij normaal gebruikt is een uitdaging.

[Reactie gewijzigd door djwice op 22 december 2019 18:22]

Ik denk dat deze truc beter werkt dan je zou verwachten. Een hacker voelt zich begluurd. Hij is, zodra hij door de beveiligingsbarrieres heen is, immers op een terrein waar hij niet hoort te zijn terwijl hij zijn prooi bijna kan ruiken, zogezegd. Dat geeft druk en stress waardoor een mens ongewild haast gaat maken.

Het grote euvel is dat de hacker geen nep data verwacht ! Hij kijkt waarschijnlijk in eerste instantie niet eens verder dan zijn neus lang is. Laat staan dat hij de data op echtheid gaat analyseren.

Mits deze nepdata goed is opgezet is het in het hoofd zoiets van "Hebbes ! Gauw downloaden en weer weg."

Voor de hacker door heeft dat hij de verkeerde bestanden te pakken heeft is er voor hem kostbare tijd verloren gegaan en die tijd kan gebruikt worden om zijn werkwijze te analyseren en het gat te dichten.
Gelukkig lezen hackers geen nieuws 8)7
'tuurlijk wel.... en ze vergeten het vaak ook weer snel. Net zoals al die andere berichten is dit bericht over een jaar ook weer in de vergetelheid
Hackers kunnen ook gewoon de tijd nemen, sommigen vinden het leuk om anderen te slim af te zijn en zijn lang, maanden tot zelfs enkele jaren, ongemerkt actief op een netwerk.

Snelheid is nodig als wat je wil vergaren binnenkort verdwijnt of als wat je wilt bereiken tijd gebonden is. In alle andere gevallen; why would he?

Ik vraag me af of hackers zich ongemakkelijk voelen op machines en netwerken van anderen. Waarom zouden ze? Het is voor hun dagelijkse kost.

[Reactie gewijzigd door djwice op 22 december 2019 23:56]

Zelfs de impact van de belasting van het systeem is terug te halen uit reactietijden van netwerk-handelingen. Iets wat niet echt in gebruik is of waarbij gebruik wordt nagebootst met een te eenzijdig proces valt zo door de mand... Probleem met hackers is dat ze nooit achterlijk zijn. :)

[Reactie gewijzigd door blorf op 22 december 2019 18:24]

Flauwekul. Dan moet je beweren dat alle netwerkapparatuur op een binnenlandse route naar een Amerikaans bedrijf 'dirty' is en buiten TCP/IP om een ander kanaal handhaaft dat alleen de betrokken autoriteiten kennen. Ze zullen mogelijk gewoon binnen zijn gelaten bij bepaalde partijen maar dan is er geen geheime dienst oid meer nodig. Niemand kan in het geheim data van a naar b krijgen over een publiek netwerk met apparatuur conform publieke standaarden. Dat kan versleuteld en zijn en door een doolhof gaan, maar het is altijd zichtbaar bij vertrek en aankomst. En voor 'binnen' zijn is tweerichtingsverkeer nodig...

[Reactie gewijzigd door blorf op 22 december 2019 19:00]

Er zijn gewoon baasjes security die toegang geven, en intern vereisen dat alles via een centrale server met https offloading gaat en daar gescant wordt, óf dat het unencrypted moet zijn intern.
En dan ook al het traffic van het hele netwerk dupliceren naar hun scanners/loggers.

[Reactie gewijzigd door djwice op 22 december 2019 18:54]

Datamining is iets anders dan ergens binnen zijn...
LOL, klopt, tenzij je die data gewoon transparant doorstuurt naar hun servers.
Je bedoelt de geheime dienst haalt de data op via een geheime methode.

Via een geheime straalverbinding? Zonder dat je het zelf door hebt en zonder dat een ander, voorbij je modem het ziet gaat met normaal internet niet lukken.

Volgens mij begrijp je niet hoe computernetwerken in elkaar steken. Elke reeks bits naar binnen of buiten is altijd zichtbaar aan de andere kant van de lijn. Dat komt omdat je internet-standaarden gebruikt en iedereen weet hoe die werken. Wijk je daar van af dan snapt het eerstvolgende apparaat aan de andere kant van de lijn het niet meer.

[Reactie gewijzigd door blorf op 22 december 2019 23:54]

Nee, joh, de data wordt gewoon netjes naar hun gepusht. Hoofd security werkt daar aan mee, dan wel om een schoon bord te houden, kiest hij een vendor die dat voor hem regelt via hun SaaS plug-in op de on-prem appliances. Hij wil ook door kunnen blijven groeien en sterkt op deze manier zijn politieke positie.

[Reactie gewijzigd door djwice op 23 december 2019 00:01]

Ja dan zijn ze 'binnen' ja. :+
Precies. Social hacking is nog altijd de meest effectieve methode.
Niet nodig. Dat is gewoon er actief aan meewerken. Zeg dan dat en vergeet netwerken en hacken.

Microsoft: "sja, we hebben een geinfiltreerde NSA medewerker gesnapt, sorry, we dachten dat hij .NET programmeur was maar hij zat de hele dag te uploaden en viel iedereen lastig voor wachtwoorden". Hele wereld over op Linux... :+

[Reactie gewijzigd door blorf op 23 december 2019 00:36]

ik zei ook geen hacken, ik zei dat ze al binnen het netwerk zijn en dat klopt.
Als degene die bij de gegevens wil, maar het idee heeft dat er nepdata tussenzit. Kunnen ze hun tijd verdoen met zoeken naar iets dat er niet is.
En het effectief inzetten moet waarschijnlijk ook betekenen dat je eigen bedrijfsvoering er geen last van heeft. Als de gegevens inderdaad tussen alle betrouwbare gegevens door moeten staan, hoe gaan de medewerkers wel het verschil zien of er niet mee in aanraking komen zonder dat de hacker het op die manier door kan hebben?
Het probleem is eerder. Wanneer de hackers de nepdata in handen krijgen en ze merken het. Dat ze wel erg boos zijn. En nog gekkere dingen gaan doen.

Daarnaast waarom zou de imago kapot gaan. Want je klantengegevens liggen niet op straat. En je PR kan dan een goed woordje doen bij de press

"van ja de hackers hebben nep data meegenomen ipv echte data waardoor het allemaal veilig gesteld is, en we nog ons beter best doen om dat zo te houden"

dan een pr press release. Ja gevoelige data ligt op straat bij criminelen. We proberen en alles aan te doen om de schade zo min mogelijk te maken.
Boze mensen maken sneller fouten, dus dat kan een voordeel opleveren. Het lijkt mij verstandig dat afdeling communicatie niet wordt geïnformeerd dat de gelekte data nep is.

Ik zou eerder communiceren dat de gestolen data de volledige klantdatabase bevat, maar dat hij zo goed versleuteld is dat de hackers er de komende 100 jaar niets mee kunnen.

[Reactie gewijzigd door djwice op 22 december 2019 18:28]

Dit zou iedereen gewoon standaard moeten doen, maar helaas..
Wat voor gespuis willen ze er mee vangen?
De drive-by aanvaller? Die pak je daar wel me. Maar daar heb je geen last van als je de beveiliging op orde hebt. Dan gaan ze namelijk naar de buren waar het makkelijker binnen komen is.
De gerichte aanvaller? Die weet wat ze zoeken, die gaan er gericht op af. Die laten zich misschien misleiden maar ze zullen alles pakken, zowel de echte gegevens als de 'alternatieve'.

Kijk ook naar wat de bedrijven zelf al hebben. Zeker daar waar ze groot en serieus met het gereedschap om gaan. In veel gevallen is die software dubbel uitgevoerd, 1 voor productie en 1 voor acceptatie. De acceptatie omgeving is vaak gevuld met oude/achterhaalde/geanonimiseerde/versleutelde/minder/test gegevens. Dat werkt al als 'honnypot' of hoe je het ook wilt noemen. Zaak is alleen dat dus aan te laten staan, ook als je niet in een acceptatie traject bezig bent.
Als de gerichte aanvaller creditcard nummers zoekt, en vervolgens een database krijgt waar 99% van de nummers fake zijn (*), is de hack zo goed als waardeloos.

* maar wel de validatie algoritmes passen, maar dan failen op expiratie datum, ccv code, verkeerde naam/adres of domweg niet bestaand bij misbruik.

[Reactie gewijzigd door Washell op 22 december 2019 16:52]

Ga er maar van uit dat hackers ook toegang hebben tot de lijst met valide nummers en lijst met testnummers. Dus die zullen de dataset dan direct classificeren als nep en verder zoeken.

[Reactie gewijzigd door djwice op 22 december 2019 18:34]

Ja en ga er ook maar van uit dat hackers weten dat je nu uit je nek aan het kletsen bent. Er is geen lijst met valide nummers of testnummers. Creditcard nrs worden gewoon gegenereerd op basis van een algoritme en iedereen kan geldige nrs maken, maar daar heb je niets aan wanneer je niet echte accounts hebt met naam, vervaldatum en cvc-code.

En als ze al een lijst hebben met geldige accounts, waarom zouden ze dan nog een keer gaan hacken? 8)7
Er zullen weinig bedrijven zijn die meer nep-gegevens hebben dan echte gegevens. In de regel is de hoeveelheid nept/test/validatie informatie een (veel) kleinere hoeveelheid dan de echte hoeveelheid.
Wat @Washell zegt geldt ook voor anderen, bijvoorbeeld: Een ziekenhuis met patientgegevens. Bij nader inzien blijkt de helft van de gegevens nep en / of de helft van hun data. Ga als hacker maar eens uitzoeken welke helft echt is. Terwijl de nep-data niet toegankelijk is voor echt ziekenhuis-medewerkers, wordt door de software aangemaakte nep-data op gezette / randomized tijden 'bijgewerkt' door net-medewerkers.

Bij een bedrijf kun je dezelfde truc doen maar dan bijvoorbeeld met klanten en opdrachten.

Alleen al het benaderen of inzien van de nep-data door derden is een signaal dat er een hacker bezig is óf een medewerker fout zit.
Bij een ziekenhuis zullen echt geen nep gegevens tussen de echte gegevens staan. Dat is veel te gevaarlijk. Jij wilt niet geholpen worden aan iets waar jij geen weet van hebt maar dat wel in jou dossier staat omdat het zo nodig met nep gegevens gevoed moet worden.
Die nep-gegevens zijn nooit te vinden voor echte users, zoals de ziekenhuismedewerkers, dat is het hele idee.
Ik weet nog in de tijd van de piratenzenders op zee dat het vermoeden rees dat Veronica de nieuwsberichten van de Radio Nieuwsdienst letterlijk overnam. Toen hebben ze een nepbericht voorgelezen, kippenschuur in Barneveld in brand, en dat namen ze bij Veronica letterlijk over. Toen wisten ze het zeker. Een technologie bedrijf kan gemakkelijk doorbraken en uitvindingen verzinnen waarvan iedereen in het bedrijf wel weet of dat waar is, lijkt me. Diverse reacties hier zien het veel te gecompliceerd vind ik.
Daarvoor heb je geen nepberichten nodig als berichten letterlijk, woord voor woord, overgenomen worden. Die nepberichten zijn in jouw voorbeeld pas nuttig als Veronica de berichten herschreef zodat het leek alsof zij een andere bron gebruikten.
Als het om copyright gaat zijn er zat leuke voorbeelden voor listen en valstrikken. Bijvoorbeeld landkaarten en kaarten met straten en wegennetwerken. Die informatie is in princiepe openbaar maar je kan niet zonder toestemming zomaar iemands anders kaart overnemen. Daarom werden er vaak op een aantal paginas verzonnen straatnamen of opzettelijke misdrukken toegevoegd, in het geval van een rechtzaak konden die details dan vergleken worden ook al was de kaart op een iets andere manier getekend. Natuurlijk wanneer een regio groeit en meer gebieden bebouwt worden kan het zomaar voorkomen dat een fictieve straat opeens wel bestaat en mensen de naam die op de kaart staat er voor gaan gebruiken 8)7
Dat is ook hoe de Amerikanen tijdens de Tweede Wereld oorlog erachter kwamen dat de Japanners de Amerikaanse eilandbasis Midway wilde aanvallen. Ze hadden het gemunt op 'AF', maar de Amerikanen wisten niet zeker welk doelwit dat was. Ze stuurde een onversleuteld bericht over waterfilteringsproblemen op Midway, en jawel, de Japanners begonnen te communiceren over waterfilteringsproblemen op AF.

[Reactie gewijzigd door ThePendulum op 22 december 2019 16:17]

Hmm, cool idee, eigenlijk een honeypot verwerken in je productie omgeving. Wat ik me dan wel af vraag, is hoe zien medewerkers het verschil tussen echte data en deze ruis, en is dát dan niet de nieuwe attack vector. Nou ja, dan heb je ze in ieder geval langer aan het lijntje, kan het verschil tussen miljoenen verlies en niet betekenen.
Juist omgekeerd.

Als je ziet dat eigen medewerkers een honeypot benaderen, dan valt er wat te winnen mbt interne veiligheid en bijbehorende instructies.

Eigen medewerkers zouden alleen eigen mappen en gegevens moeten kunnen benaderen en niet zomaar klakkeloos overal rond kunnen koekeloeren zonder juiste toestemming.


Zouden bedrijven vaker moeten doen waarbij ze niet moeten schromen om het nog wat aantrekkelijker te maken voor eigen medewerkers omdat dat (on)bewust vaak de zwakste schakel is.
Ja bij normale honeypots is dat zekert het geval, maar hier wordt voor zover ik snap de data verweven op de echte productie servers. En hoe je dan zorgt dat medewerkers geen onzin te zien krijgen volgens de normale software oplossingen was meer mijn vraag. Er moet dan toch ergens een filterlijst oid. zijn
Je kunt je software laten schrijven naar 10 db's en lezen uit 1
Als je het zo simplistisch aanpakt dan zal het voor een hacker niet lastig zijn om te ontdekken welke data echt is en welke nep; dan is het hele plan meteen waardeloos. Dus ja, @GLaDTheresCake heeft zeker een goede vraag, ik ben alleen bang dat het antwoord waarschijnlijk geheim moet blijven (omdat het hele idee anders als een kaartenhuis in elkaar stort).

[Reactie gewijzigd door robvanwijk op 22 december 2019 20:05]

Als een hacker op het niveau zit dat hij kan meekijken waarheen en waar vandaan wordt geschreven en gelezen dan ben je toch al de sjaak, er zijn zoveel dingen denkbaar, je kunt ook alle 10 db's lezen maar alleen de info van 1 db weergaven op het scherm. Je kunt elke info op 20 verschillende manieren in al die db's stoppen, je kunt het zo uitgebreid maken als je wilt maar er is ook een kostenplaatje.
en een inbreker die de DB even 2 seconden monitort ziet meteen waar de activiteit heen gaat :+
Dat is al een hele oude truuk door bv. "confidential" opmerkingen bij en in een confidential document weg te laten. Op de torrent zien we grote blanco files als de nieuwste films met ook nog eens positieve reacties en zo zijn er meer voorbeelden om mensen af te leiden.
Hackers doorzien een simpele misleiding wel.
Het gaat hier om een complexe methode waarbij nep data slim verweven wordt.
De hackers zien dan niet direct dat het om nep gaat en denken de hoofdprijs gescoord te hebben.
Tegelijkertijd biedt dit mogelijkheden om de hackers te traceren.
Optie 1: Je verweeft de onzindata door de gewone of plaatst het ernaast, maar maakt het onzichtbaar voor gewone medewerkers. Dat werkt wanneer een hacker volledige toegang krijgt en de hele schijf bitje voor bitje uitleest, maar is totaal nutteloos wanneer ze (bijvoorbeeld via phishing) toegang krijgen tot een account van een medewerker, wat een stuk vaker zal gebeuren dan dat ze meteen root access op de server krijgen).
Optie 2: Je maakt de onzindata ook zichtbaar voor de gewone medewerkers. Om te zorgen dat ze die data niet gaan gebruiken moet het dan als onzin voor hun herkenbaar zijn, wat betekent dat de meeste hackers dat ook binnen een paar seconden er uit kunnen filteren.
Optie 3: Je maakt de onzindata voor alle medewerkers zichtbaar, en maakt het zo onduidelijk wat echt is en wat niet dat niemand meer iets met de data kan.
Optie 4: Zelfde als optie 3, maar je geeft de medewerkers software waarmee ze wel het verschil kunnen zien en waarmee nieuwe data ook direct ge-obfusceerd wordt. Dat werkt tot zo'n programmaatje uitlekt, bijvoorbeeld door een niet geformateerde harddisk. Als het niet op de computer van de medewerkers draait maar op de server dan heeft een hacker bij root access op de server (ook wanneer het read-only is) alsnog alles.

Weet niet hoe ze het gaan implementeren, maar bij de verkeerde implementatie zal het eerder problemen veroorzaken dan oplossingen aandragen.
Waarom moet een medewerker het verschil kunnen zien ? Ik denk dat dat in veel gevallen niet nodig is. Meestal zal je b.v. zoeken naar de gegevens van een specifiek, echt bestaand persoon. Zolang je niet hele lijsten met gegevens gaat opvragen maar alleen specifieke data dan maakt het niet uit dat er onzin in de database staat, omdat je daar nooit naar zal zoeken.

Bijvoorbeeld: een helpdesk medewerker zal in principe nooit de gegevens van een niet bestaande klant opzoeken omdat er geen klant bestaat die het klantnummer van een fake klant heeft. (Wel zorgen dat de hamming dinstance tussen klantnummers voldoende is dat je niet door een tikfout oid bij een nepklant uitkomt).
Optie 5: Je werkt met fake accounts in je netwerk. Die wijs je toe aan fake afdelingen met toegang tot fake documenten. Op die manier krijgen de echte medewerkers nooit fake documenten te zien. Om het te verbergen voor de echte medewerkers zou je bijvoorbeeld een afdeling Research & Development (of een andere naam die een hacker interessant zou vinden) kunnen oprichten die in een ander land zit met fictieve medewerkers. In werkelijkheid zit daar misschien alleen maar een postadres. Als het bedrijf een serieuze omvang heeft zullen je eigen medewerkers het misschien niet eens raar vinden dat je een buitenlandse unit hebt.
Voor een grote Nederlandse klant hadden we ook wel een aardige methode, elke week werd er 1 fakeaccount in de echte database gemaakt met een email adres wat echt compleet random was en koppelde dat aan een centrale database, op die manier kun je mogelijk achterhalen of je database compromised is, en sinds wanneer. Echter op een dag kwam er dus echt een mail binnen, er is toen heel goed gerechercheerd of er echt iets mis was, helaas zijn we er nooit achter gekomen, en is er ook nooit meer een mail binnengekomen.
Nou, "aardige methode" dan als je er uiteindelijk nog niets aan gehad hebt?
Het idee van security is dat je een gelaagd model hebt, kortom het slechts een klein onderdeel ban een geheel.
Helpt dit ook om cryptolockers (naar ik begrijp de grootste bron van ellende) af te weren? Volgens mij niet, maar ook dit soort kleine stapjes kan natuurlijk nuttig zijn.
Hmm, misschien wel slim van de FBI. Stel dat je gehackt wordt, dan kun je vervolgens altijd aangeven dat het juist fake-data is die gelekt is en dat er dus eigenlijk niks aan de hand is...
Ik vind het idee leuk, maar het klinkt als security through obscurity.

En, dit is mijn ervaring, zelfs in omgevingen waar IT serieus wordt genomen en flink budget krijgt is het voor beheerders (of DevOps al helemaal) al soms een uitdaging om de complexe systemen te snappen, vooral als er een verstoring is. Om nog meer complexiteit te introduceren met nepdata en nepbestanden, lijkt me niet het allerbeste idee...

Om een voorbeeld te geven, als onderdeel van dienstverlening beheerde ik op een gegeven moment en database met geolokaties van partnerwinkels. Deze werden opgevoerd door de klant en werd gebruikt voor weergave op een kaartje voor eindgebruikers, zodat ze makkelijk 'partnerwinkels in de buurt' konden zoeken.

Op een gegeven moment viel op dat de adressen van sommige winkels niet aan een correcte geolokatie werden gekoppeld en dus niet correct gezocht konden worden. Dat bleek een redelijk obscuur bugje in de applicatie en kregen we pas boven water na het draaien van flink wat query's om de voorwaarden waaronder het optrad te vinden. Als er nepdata tussen had gezeten, vraag ik me af of we de bug boven water hadden kunnen krijgen...
Security through obscurity wordt meestal genoemd alsof het een op zichzelf staand middel is, wat vermoeden moet worden omdat het niet waterdicht is.

Maar in werkelijkheid is niets 100% waterdicht. Je moet het niet zien als een waterdicht middel, maar als een aanvulling op.

De realiteit is, dat allerlei technieken en middelen die gebruikt worden door bedrijven – waaronder, maar niet alleen voor beveiliging – al een hoge mate van 'obscurity' veroorzaken en daarmee (onder andere) de veiligheid verbeteren.

Zo is het gebruikelijk om medewerkers van een groot bedrijf pasjes te geven, om de deur open te maken. Dit is veiliger dan een code intoetsen, terwijl het in feite op hetzelfde neerkomt, omdat codes makkelijk af te kijken (dus kopieëren) zijn, maar pasjes een stuk lastiger.

Zijn pasjes daardoor niet te hacken? Natuurlijk is dat wel mogelijk.. Nemen bedrijven die pasjes om het pand waterdicht te beveiligen? Nee. Maar de pasjes maken het wel lastiger.

Afgezien daarvan kan obscurity wel degelijk de beveiliging helpen. Als de inlogpagina van je site niet te vinden is, gaan 99 van de 100 hackers naar de volgende site. Die ben je alvast kwijt. Nogmaals: Hier kun je niet op vertrouwen als beveiliging, maar het helpt wel.
Anoniem: 428562
22 december 2019 15:55
https://canary.tools/

Order, configure and deploy your Canaries throughout your network. (These can be hardware, virtual or cloud-based birds!) Make one a Windows file server, another a router, throw in a few Linux webservers while you're at it. Each one hosts realistic services and looks and acts like its namesake.

Then you wait. Your Thinkst Canaries run in the background, waiting for intruders.

Attackers prowling a target network look for juicy content. They browse Active Directory for file servers and explore file shares looking for documents, try default passwords against network devices and web services, and scan for open services across the network.

When they encounter a Thinkst Canary, the services on offer are designed to solicit further investigation, at which point they’ve betrayed themselves, and your Canary notifies you of the incident.

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee