Hvis et slagteri sender kontamineret fars på markedet og/eller har problemer med egenkontrollen, kan fødevarestyrelsen idømme en bøde.
Hvorfor er der ikke en tilsvarende styrelse der kan idømme YouSee en bøde for ikke at have styr på sikkerheden ?
Den bedste måde at forbedre IT-sikkerheden, er at indføre et 100% erstatningsansvar, så dem der tager beslutningen om sikkerheden også bærer konsekvensen af forkerte beslutninger.
phk
Den udskældte beskatning af ‘fri telefon’ får igen hårde ord med på vejen. Dansk Byggeri har fået Skat til at offentliggøre, hvad der inddrives fra beskatningen af arbejdstelefoner, der også bruges privat. Tallet lyder på omkring 500 millioner, og dem vil Dansk Byggeri nu have tilbage, skriver epn.dk.
Da den nyeste lov omkring beskatning af arbejdstelefoner, døbt smartphone-skatten, trådte i kraft 1. januar 2012, skete det som reaktion på stor kritik af multimedie-skatten, der inddrev en halv milliard til statskassen. Erhvervslivet fandt det urimeligt, at ansatte skulle brandbeskattes for at være i besiddelse af et uundværligt arbejdsredskab.
Derfor meldte daværende skatteminister Thor Möger Pedersen dengang ud, at den nye såkaldte smartphone-beskatning kun ville inddrive i omegnen af 50 millioner. Smartphone-skatten skal betales af alle, der har betalt telefon af arbejdsgiveren, der også kan bruges privat. I 2014 skal der svares skat af 2600 kroner uanset, hvor meget telefonen bruges privat.
Men de nye tal, som Dansk Byggeri er i besiddelse af, viser, at den totale skattemæssige værdi af de ‘frie telefoner’ udgør 1 milliard i Danmark, hvilket giver omtrent samme provenu for staten, som under den tidligere multimedie-skat.
Med de nye tal fra Skat, der viser, at indtjeningen i virkeligheden har været en faktor 10 højere, mener Dansk Byggeri, at det er på sin plads, hvis de overskydende penge sættes tilbage i omløb.
»Regeringen har hevet en halv milliard kroner ud af borgerne og erhvervslivets lommer. Når et politisk område hvert eneste år overfinansieres med så stort et beløb, er det kun rimeligt at bruge det til at finansiere en vækstpakke. Hvorfor ikke lade det komme borgerne til gavn,« spørger cheføkonom Bo Sandberg fra Dansk Byggeri ifølge epn.dk.
Men skatteminister Morten Østergaard (RV) har ikke tænkt sig at føje Dansk Byggeris krav om tilbagebetaling, da han mener, det allerede er sket i form af vækstpakker og skattelettelser, skriver epn.dk
»Regeringen har taget en lang række initiativer til at sætte gang i væksten og har løbende fokus på, hvordan vi kan forbedre erhvervslivets rammevilkår. De initiativer er ikke afhængige af, om der kommer færre eller flere penge ind i den ene eller anden type skat,« siger Morten Østergaard ifølge epn.dk.
Den udskældte beskatning af ‘fri telefon’ får igen hårde ord med på vejen. Dansk Byggeri har fået Skat til at offentliggøre, hvad der inddrives fra beskatningen af arbejdstelefoner, der også bruges privat. Tallet lyder på omkring 500 millioner, og dem vil Dansk Byggeri nu have tilbage, skriver epn.dk.
Da den nyeste lov omkring beskatning af arbejdstelefoner, døbt smartphone-skatten, trådte i kraft 1. januar 2012, skete det som reaktion på stor kritik af multimedie-skatten, der inddrev en halv milliard til statskassen. Erhvervslivet fandt det urimeligt, at ansatte skulle brandbeskattes for at være i besiddelse af et uundværligt arbejdsredskab.
Derfor meldte daværende skatteminister Thor Möger Pedersen dengang ud, at den nye såkaldte smartphone-beskatning kun ville inddrive i omegnen af 50 millioner. Smartphone-skatten skal betales af alle, der har betalt telefon af arbejdsgiveren, der også kan bruges privat. I 2014 skal der svares skat af 2600 kroner uanset, hvor meget telefonen bruges privat.
Men de nye tal, som Dansk Byggeri er i besiddelse af, viser, at den totale skattemæssige værdi af de ‘frie telefoner’ udgør 1 milliard i Danmark, hvilket giver omtrent samme provenu for staten, som under den tidligere multimedie-skat.
Med de nye tal fra Skat, der viser, at indtjeningen i virkeligheden har været en faktor 10 højere, mener Dansk Byggeri, at det er på sin plads, hvis de overskydende penge sættes tilbage i omløb.
»Regeringen har hevet en halv milliard kroner ud af borgerne og erhvervslivets lommer. Når et politisk område hvert eneste år overfinansieres med så stort et beløb, er det kun rimeligt at bruge det til at finansiere en vækstpakke. Hvorfor ikke lade det komme borgerne til gavn,« spørger cheføkonom Bo Sandberg fra Dansk Byggeri ifølge epn.dk.
Men skatteminister Morten Østergaard (RV) har ikke tænkt sig at føje Dansk Byggeris krav om tilbagebetaling, da han mener, det allerede er sket i form af vækstpakker og skattelettelser, skriver epn.dk
»Regeringen har taget en lang række initiativer til at sætte gang i væksten og har løbende fokus på, hvordan vi kan forbedre erhvervslivets rammevilkår. De initiativer er ikke afhængige af, om der kommer færre eller flere penge ind i den ene eller anden type skat,« siger Morten Østergaard ifølge epn.dk.
Jeg vil lige dele en idé, i håb om andre kan bruge og gerne forbedre den. Kort fortalt er jeg kommet op med en relativt dynamisk metode til at blokere kommunikation med alverdens hackeres foretrukne netværk, nemlig Tor.
Løsningen skal i nuværende form betragtes som et “proof of concept”, baseret på et Windows PowerShell script, der styrer et Active Directory »Group Policy Object« (GPO), som igen styrer »Windows Firewall with Advanced Security« (WFAS) konfigurationen på linkede Windows servere og klienter (Windows Vista og op).
Tor-netværket er en bekvem måde at gemme sig på for en angriber, da man herfra kan optræde stort set anonymt. Jeg skal ikke her gå i detaljer med teknologien bag Tor. Det vigtigste er at vide, at »Exit Nodes« er de servere, hvor Tor-klienterne routes ud anonymt.
Jeg er ganske klar over, at Tor kan anvendes til helt legitime forhold, og at det kan have sin berettigelse i mange sammenhænge, men desværre er det overvejende brugsmønster af mistænkelig karakter. En sikkerhedsbevidst virksomhed kan derfor forsvare et strategisk valg om helt at fravælge kommunikation med Tor-brugere.
For nogle år siden skrev jeg et VBScript, som downloadede en liste over Tor »Exit Nodes« og oprettede eksplicitte Deny-regler for hver af disse IP-adresser i regelsættet på Microsoft ISA og TMG firewalls.
Formålet med mit script var dengang at sikre, at der ikke kunne oprettes forbindelse til eller fra Tor »Exit Nodes« for interne klienter og servere på det firewall-beskyttede lokalnetværk.
I disse tider, hvor mobilitet er i højsædet i de fleste virksomheder, så er perimeter-tankegangen ikke længere tilstrækkelig. Det er ikke nok at blokere adgang i den centrale firewall, selvom det selvfølgelig stadig kan være gavnligt. Med WAN-tilsluttede laptops, split-tunneling VPN, DirectAccess og lignende teknologier, så er det i høj grad op til klienterne selv (typisk Windows) at gardere sig mod angreb.
Formålet med det nye script var derfor først og fremmest at få funktionaliteten ud på klienterne. Som en lille bonus blev det med central administration og mulighed for jævnlige opdateringer, da Tor netværket jo er relativt dynamisk.
Jeg har gjort mig nogle forskellige overvejelser omkring hvordan funktionaliteten skulle implementeres.
Hvilken blokeringsmekanisme?
Først er der selve blokeringsmekanismen. Der er flere måder at sikre, at en Windows klient ikke kan kontakte (initiere forbindelse til) – eller kontaktes af – en given IPv4-adresse.
Først overvejede jeg faktisk at oprette »null routes« på klienten. Det findes dog ikke rigtig under Windows, men funktionaliteten kan dog emuleres med »Route Add« kommandoen. Med denne kommando kan man sikre, at en klient benytter en bestemt IP som gateway til en given destination (host eller subnet). Det kunne så være en »dummy« gateway adresse, hvilket svarer lidt til en »null route«.
Som alternativ kunne den lokale host firewall anvendes. Den indbyggede firewall i Windows (WFAS) er en oplagt kandidat, da det rent faktisk en rigtig fornuftig lokal firewall – hvis den altså er konfigureret korrekt. Dertil er den (forhåbentlig) aktiveret på alle Windows klienter og servere i forvejen (hvis ikke der anvendes 3. parts host firewalls).
Da route-tilgangen syntes lidt skrøbelig, og længst fra “best practice”, gik jeg efter en løsning baseret på WFAS.
Hvordan styrer vi så firewallreglerne?
Dernæst måtte jeg finde ud af hvordan disse firewallregler skulle oprettes og opdateres.
Én metode er at gå efter en lokal processtyring via »Task Scheduler«, hvor klienten selv henter en liste over Tor »Exit Nodes« jævnligt og ud fra denne opdaterer sin lokale WFAS konfiguration, f.eks. med »Netsh Advfirewall« kommandoen.
I stedet for »Nesh«, så kan der under Windows 8.1 og Windows Server 2012 R2 benyttes en ny PowerShell cmdlet kaldet »New-NetFirewallRule«. Hermed ville alle andre Windows klienter dog blive udelukket, hvilket er lidt synd når så mange stadig er på Windows 7 – og forhåbentlig ikke Windows XP, vel 
En absolut fordel ved den lokale tilgang er, at computere som ikke er medlem af et Active Directory domæne (hovedparten af private computere er standalone klienter), også ville have mulighed for at anvende scriptet. Dog vil det for virksomheden resultere i en alt for dynamisk og ukontrolleret tilgang til netværkssikkerheden.
Jeg valgte at fokusere på en typisk virksomheds behov, men det vil være relativt enkelt at skrive scriptet om til at virke for standalone klienter.
Synergien mellem Group Policy og PowerShell
Selve konfigurationen af WFAS kan snildt foregå fra en central Group Policy under Active Directory. Langt de fleste virksomheder er familiære med denne administrationsmetode.
En anden fordel med Group Policy er, at man ikke behøver at opdatere firewallpolitikkerne manuelt via Group Policy Management Editor. Mange policy-settings kan opdateres vha. et PowerShell script, som eksempelvis kan eksekveres fra en »scheduled task«, i kontekst af en brugerkonto som har skriveadgang til den pågældende GPO (og ikke så meget andet).
Det kræver blot, at der én gang oprettes en GPO til formålet, linker den til rette containere og/eller Organizational Units for Windows computerobjekter, og til sidst sætter korrekte filtre og rettigheder på.
Mit script er som sagt alene udarbejdet som en inspiration til andre. Det medfører bl.a., at der formentlig er masser af ting som kan gøres mere elegant, smartere og hurtigere. Jeg har prioriteret en vis læsevenlighed, således at andre nemt kan modificere, hvor der måtte være specielle forhold, ønsker eller krav.
Scriptet har i nuværende form følgende funktioner:
Der foretages minimal error handling, langt fra nok af til et professionelt driftsmiljø.
Jeg håber, at andre vil forbedre koden – og dele med os andre her på siden!
Enhver anvendelse af scriptet foregår på eget ansvar. Til gengæld kan det anvendes og redigeres uden omkostninger.
Funktionaliteten er testet på en Windows Server 2008 R2 Domain Controller, en Windows Server 2012 R2 Domain Controller og en Windows 7 klient med RSAT.
Du kan hente scriptet i seneste version her!
GPO Unique ID (Guid) findes under Group Policy Management Console > Details fanebladet:
Under Group Policy Management Console > Settings kan man se de automatisk oprettede regler:
Her ses de oprettede inbound-regler under Group Policy Management Editor:
På de klienter og/eller servere, som rammes af GPO’en, vil de oprettede regler kunne ses under »Windows Firewall with Advanced Security«:
Scriptet opretter som standard en samlet log-fil og filer med de downloadede Tor-lister (én for hver kørsel):
Update: 31-03-2014 kl. 11:49, rettet slåfejl “Windows Server 2010″ til 2012.
Jeg vil lige dele en idé, i håb om andre kan bruge og gerne forbedre den. Kort fortalt er jeg kommet op med en relativt dynamisk metode til at blokere kommunikation med alverdens hackeres foretrukne netværk, nemlig Tor.
Løsningen skal i nuværende form betragtes som et “proof of concept”, baseret på et Windows PowerShell script, der styrer et Active Directory »Group Policy Object« (GPO), som igen styrer »Windows Firewall with Advanced Security« (WFAS) konfigurationen på linkede Windows servere og klienter (Windows Vista og op).
Tor-netværket er en bekvem måde at gemme sig på for en angriber, da man herfra kan optræde stort set anonymt. Jeg skal ikke her gå i detaljer med teknologien bag Tor. Det vigtigste er at vide, at »Exit Nodes« er de servere, hvor Tor-klienterne routes ud anonymt.
Jeg er ganske klar over, at Tor kan anvendes til helt legitime forhold, og at det kan have sin berettigelse i mange sammenhænge, men desværre er det overvejende brugsmønster af mistænkelig karakter. En sikkerhedsbevidst virksomhed kan derfor forsvare et strategisk valg om helt at fravælge kommunikation med Tor-brugere.
For nogle år siden skrev jeg et VBScript, som downloadede en liste over Tor »Exit Nodes« og oprettede eksplicitte Deny-regler for hver af disse IP-adresser i regelsættet på Microsoft ISA og TMG firewalls.
Formålet med mit script var dengang at sikre, at der ikke kunne oprettes forbindelse til eller fra Tor »Exit Nodes« for interne klienter og servere på det firewall-beskyttede lokalnetværk.
I disse tider, hvor mobilitet er i højsædet i de fleste virksomheder, så er perimeter-tankegangen ikke længere tilstrækkelig. Det er ikke nok at blokere adgang i den centrale firewall, selvom det selvfølgelig stadig kan være gavnligt. Med WAN-tilsluttede laptops, split-tunneling VPN, DirectAccess og lignende teknologier, så er det i høj grad op til klienterne selv (typisk Windows) at gardere sig mod angreb.
Formålet med det nye script var derfor først og fremmest at få funktionaliteten ud på klienterne. Som en lille bonus blev det med central administration og mulighed for jævnlige opdateringer, da Tor netværket jo er relativt dynamisk.
Jeg har gjort mig nogle forskellige overvejelser omkring hvordan funktionaliteten skulle implementeres.
Hvilken blokeringsmekanisme?
Først er der selve blokeringsmekanismen. Der er flere måder at sikre, at en Windows klient ikke kan kontakte (initiere forbindelse til) – eller kontaktes af – en given IPv4-adresse.
Først overvejede jeg faktisk at oprette »null routes« på klienten. Det findes dog ikke rigtig under Windows, men funktionaliteten kan dog emuleres med »Route Add« kommandoen. Med denne kommando kan man sikre, at en klient benytter en bestemt IP som gateway til en given destination (host eller subnet). Det kunne så være en »dummy« gateway adresse, hvilket svarer lidt til en »null route«.
Som alternativ kunne den lokale host firewall anvendes. Den indbyggede firewall i Windows (WFAS) er en oplagt kandidat, da det rent faktisk en rigtig fornuftig lokal firewall – hvis den altså er konfigureret korrekt. Dertil er den (forhåbentlig) aktiveret på alle Windows klienter og servere i forvejen (hvis ikke der anvendes 3. parts host firewalls).
Da route-tilgangen syntes lidt skrøbelig, og længst fra “best practice”, gik jeg efter en løsning baseret på WFAS.
Hvordan styrer vi så firewallreglerne?
Dernæst måtte jeg finde ud af hvordan disse firewallregler skulle oprettes og opdateres.
Én metode er at gå efter en lokal processtyring via »Task Scheduler«, hvor klienten selv henter en liste over Tor »Exit Nodes« jævnligt og ud fra denne opdaterer sin lokale WFAS konfiguration, f.eks. med »Netsh Advfirewall« kommandoen.
I stedet for »Nesh«, så kan der under Windows 8.1 og Windows Server 2012 R2 benyttes en ny PowerShell cmdlet kaldet »New-NetFirewallRule«. Hermed ville alle andre Windows klienter dog blive udelukket, hvilket er lidt synd når så mange stadig er på Windows 7 – og forhåbentlig ikke Windows XP, vel
En absolut fordel ved den lokale tilgang er, at computere som ikke er medlem af et Active Directory domæne (hovedparten af private computere er standalone klienter), også ville have mulighed for at anvende scriptet. Dog vil det for virksomheden resultere i en alt for dynamisk og ukontrolleret tilgang til netværkssikkerheden.
Jeg valgte at fokusere på en typisk virksomheds behov, men det vil være relativt enkelt at skrive scriptet om til at virke for standalone klienter.
Synergien mellem Group Policy og PowerShell
Selve konfigurationen af WFAS kan snildt foregå fra en central Group Policy under Active Directory. Langt de fleste virksomheder er familiære med denne administrationsmetode.
En anden fordel med Group Policy er, at man ikke behøver at opdatere firewallpolitikkerne manuelt via Group Policy Management Editor. Mange policy-settings kan opdateres vha. et PowerShell script, som eksempelvis kan eksekveres fra en »scheduled task«, i kontekst af en brugerkonto som har skriveadgang til den pågældende GPO (og ikke så meget andet).
Det kræver blot, at der én gang oprettes en GPO til formålet, linker den til rette containere og/eller Organizational Units for Windows computerobjekter, og til sidst sætter korrekte filtre og rettigheder på.
Mit script er som sagt alene udarbejdet som en inspiration til andre. Det medfører bl.a., at der formentlig er masser af ting som kan gøres mere elegant, smartere og hurtigere. Jeg har prioriteret en vis læsevenlighed, således at andre nemt kan modificere, hvor der måtte være specielle forhold, ønsker eller krav.
Scriptet har i nuværende form følgende funktioner:
Der foretages minimal error handling, langt fra nok af til et professionelt driftsmiljø.
Jeg håber, at andre vil forbedre koden – og dele med os andre her på siden!
Enhver anvendelse af scriptet foregår på eget ansvar. Til gengæld kan det anvendes og redigeres uden omkostninger.
Funktionaliteten er testet på en Windows Server 2008 R2 Domain Controller, en Windows Server 2012 R2 Domain Controller og en Windows 7 klient med RSAT.
Du kan hente scriptet i seneste version her!
GPO Unique ID (Guid) findes under Group Policy Management Console > Details fanebladet:
Under Group Policy Management Console > Settings kan man se de automatisk oprettede regler:
Her ses de oprettede inbound-regler under Group Policy Management Editor:
På de klienter og/eller servere, som rammes af GPO’en, vil de oprettede regler kunne ses under »Windows Firewall with Advanced Security«:
Scriptet opretter som standard en samlet log-fil og filer med de downloadede Tor-lister (én for hver kørsel):
Update: 31-03-2014 kl. 11:49, rettet slåfejl “Windows Server 2010″ til 2012.
Hvad der godt kunne kandidere til det værst tænkelige scenarie, ser ud til at være blevet en realitet i Yousees store wifi-sats, hvor hardware hos kunderne får åbnet et ekstra opkoblingspunkt, som andre Yousee-kunder kan bruge til at få internetforbindelse, når de er i nærheden.
Dørene mellem de to opkoblingspunkter, SSID’er, skulle – i sagens natur – være hermetisk lukkede, så de brugere, der kobler på det eksterne og åbne SSID ikke kan tilgå data på det private net hos kunden, hvor udstyret står. Men det har tilsyneladende ikke været tilfældet.
Pressechef hos TDC, der ejer Yousee, Ib Konrad Jensen oplyser til Version2, at det under bestemte omstændigheder har været muligt for brugere af det eksterne SSID at tilgå filer på det private net. Eksempelvis hvis der har været delte mapper eller en netværksharddisk på netværket.
»Der er en risiko for, at man kan få adgang til delte filer på tværs af nettene,« siger han og fortæller, at han ikke kan uddybe, hvori den præcise sårbarhed består, andet end det relaterer sig til ‘nogle bestemte omstændigheder’.
Yousee har som konskvens af sikkerhedsbristen lukket helt ned for det åbne wifi-hotspot i udstyret hos kunderne. Det er sket ved at opdatere en konfigurationsfil.
Ib Konrad Jensen oplyser, at Yousee ikke har kendskab til, at hullet er blevet udnyttet til at tilgå andres data.
En sådan uretmæssig adgang vil dog ikke nødvendigvis blive opdaget af den, det går ud over.
Yousees hotspot-produkt fungerer ved, at alle kunder i udgangspunktet, og hvis deres udstyr ellers understøtter det, har fået åbnet en ekstra trådløs forbindelse, som andre kan koble på. Det er altså ikke noget, folk har skullet tilvælge, men noget, de dog kan fravælge.
Det berørte udstyr er Netgear CG3000, CG3700 og Cisco EPC3925. Yousee er i kontakt med Netgear og Cisco for at få løst problemet. I den forbindelse vil Yousee også se på, hvad der kunne være et andet problem, og om det kan løses i forbindelse med en softwareopdatering.
»Vi har fået en tilbagemelding fra enkelte kunder, der har sagt, at deres bredbåndshastighed er gået ned i forbindelse med, at det her er blevet implementeret på deres router,« siger Ib Konrad Jensen og tilføjer, at Yousee endnu ikke kan sige, om bredbåndsproblemerne, kunderne melder om, er relateret til softwareopgraderingen og dermed også kan løses softwaremæssigt.
Ib Konrad Jensen fortæller, at Yousee har planer om at åbne op for wifi-hotspottene igen, når problemet er løst, han kan dog ikke sige, hvornår det er.
Hvad der godt kunne kandidere til det værst tænkelige scenarie, ser ud til at være blevet en realitet i Yousees store wifi-sats, hvor hardware hos kunderne får åbnet et ekstra opkoblingspunkt, som andre Yousee-kunder kan bruge til at få internetforbindelse, når de er i nærheden.
Dørene mellem de to opkoblingspunkter, SSID’er, skulle – i sagens natur – være hermetisk lukkede, så de brugere, der kobler på det eksterne og åbne SSID ikke kan tilgå data på det private net hos kunden, hvor udstyret står. Men det har tilsyneladende ikke været tilfældet.
Pressechef hos TDC, der ejer Yousee, Ib Konrad Jensen oplyser til Version2, at det under bestemte omstændigheder har været muligt for brugere af det eksterne SSID at tilgå filer på det private net. Eksempelvis hvis der har været delte mapper eller en netværksharddisk på netværket.
»Der er en risiko for, at man kan få adgang til delte filer på tværs af nettene,« siger han og fortæller, at han ikke kan uddybe, hvori den præcise sårbarhed består, andet end det relaterer sig til ‘nogle bestemte omstændigheder’.
Yousee har som konskvens af sikkerhedsbristen lukket helt ned for det åbne wifi-hotspot i udstyret hos kunderne. Det er sket ved at opdatere en konfigurationsfil.
Ib Konrad Jensen oplyser, at Yousee ikke har kendskab til, at hullet er blevet udnyttet til at tilgå andres data.
En sådan uretmæssig adgang vil dog ikke nødvendigvis blive opdaget af den, det går ud over.
Yousees hotspot-produkt fungerer ved, at alle kunder i udgangspunktet, og hvis deres udstyr ellers understøtter det, har fået åbnet en ekstra trådløs forbindelse, som andre kan koble på. Det er altså ikke noget, folk har skullet tilvælge, men noget, de dog kan fravælge.
Det berørte udstyr er Netgear CG3000, CG3700 og Cisco EPC3925. Yousee er i kontakt med Netgear og Cisco for at få løst problemet. I den forbindelse vil Yousee også se på, hvad der kunne være et andet problem, og om det kan løses i forbindelse med en softwareopdatering.
»Vi har fået en tilbagemelding fra enkelte kunder, der har sagt, at deres bredbåndshastighed er gået ned i forbindelse med, at det her er blevet implementeret på deres router,« siger Ib Konrad Jensen og tilføjer, at Yousee endnu ikke kan sige, om bredbåndsproblemerne, kunderne melder om, er relateret til softwareopgraderingen og dermed også kan løses softwaremæssigt.
Ib Konrad Jensen fortæller, at Yousee har planer om at åbne op for wifi-hotspottene igen, når problemet er løst, han kan dog ikke sige, hvornår det er.
TDC-ejede YouSee har lukket for den hotspot-tjeneste, som selskabet for nylig lancerede, efter der er blevet konstateret et sikkerhedshul i softwaren på routerne. Det oplyser YouSee.
Sikkerhedshullet findes i den software, som YouSee har lagt ind på tre af selskabets routere og kabelmodems med wifi, som har gjort det muligt at bruge kundernes routere til en stor hotspot-tjeneste.
Ifølge YouSee har det været muligt via hotspottet at få adgang til delte mapper på computere eller netværksharddiske, som ikke har været beskyttet med en adgangskode. YouSee oplyser, at selskabet ikke er orienteret om konkrete tilfælde af misbrug.
Hotspot-tjenesten er nu lukket ned, indtil sikkerhedshullet er fundet og lukket. YouSee oplyser desuden, at selskabet undersøger, om der er en sammenhæng mellem sikkerhedshullet og de YouSee-kunder, som har klaget over hastighedsproblemer på deres netværk, efter hotspot-tjenesten blev lanceret.
TDC-ejede YouSee har lukket for den hotspot-tjeneste, som selskabet for nylig lancerede, efter der er blevet konstateret et sikkerhedshul i softwaren på routerne. Det oplyser YouSee.
Sikkerhedshullet findes i den software, som YouSee har lagt ind på tre af selskabets routere og kabelmodems med wifi, som har gjort det muligt at bruge kundernes routere til en stor hotspot-tjeneste.
Ifølge YouSee har det været muligt via hotspottet at få adgang til delte mapper på computere eller netværksharddiske, som ikke har været beskyttet med en adgangskode. YouSee oplyser, at selskabet ikke er orienteret om konkrete tilfælde af misbrug.
Hotspot-tjenesten er nu lukket ned, indtil sikkerhedshullet er fundet og lukket. YouSee oplyser desuden, at selskabet undersøger, om der er en sammenhæng mellem sikkerhedshullet og de YouSee-kunder, som har klaget over hastighedsproblemer på deres netværk, efter hotspot-tjenesten blev lanceret.
Microsoft vil fremover ringe til de officielle myndigheder, når virksomheden mener, der er god grund til at gennemgå kundernes Hotmail, eller andre private oplysninger i Microsoft-skyen. Det skriver Ars Technica.
Tidligere har virksomheden tilladt sig selv fri adgang til kundernes data, hvis der var noget, der tydede på at tjenester blev brugt til kriminalitet mod Microsoft. Men den praksis er slut nu. Fremover tager de rette myndigheder sig af efterforskningen, og det vil være op til myndighederne at forlange adgang til de rette informationer.
Den nye praksis kommer efter en afsløring, af at Microsoft havde gennemgået en række private mails til en blogger fra en tidligere utilfreds Microsoft-ansat. Den har ret har virksomheden nemlig givet sig selv i sine servicebetingelser. Det samme gør sig iøvrigt gældende for Apple, Yahoo og Google.
Men i en post-Snowden verden blev kunder og kritikere bekymret over at se sådan en praksis i brug. Derfor føler Microsoft sig nu nødsaget til at ændre sin politik og kræve nøjagtigt den samme retspraksis, som det gælder i hvilken som helst anden efterforskning ført af myndighederne.
I de kommende måneder vil Microsoft ændre sine servicebetingelser, så de passer med den nye praksis.