Det upplevde jag för några år sedan tittande ytligt på förslagen och vad publicerat en hel del risker med idén om en stor pan-amerikanskt IDS-lösning för myndigheter m.m. I rapporterings-mening är det excellent men fodrar också att man tänker redundans i annan mening än flera lager av säkerhet i definierade lösning hanterande risken att samtliga är osäkra samtidigt eller i sig självt introducerande säkerhetsproblem påverkande samtidigt "allt".
Projektet fördröjdes i driftsättning och även om vi inte ska utesluta att mina och troligt en hel del andras indikation kring dom riskerna spelar in ska vi också förstå stora IT-projekt oavsett i myndighet eller företag som vad som välkomnar frågetecken av typen nya övergripande risk att hantera, politiska frågor som behöver säkerställas o.s.v. Stora projekt är har alltid mer kvar att göra när det ska driftsättas (då får i värsta fall den stackars configuration mananger resa iväg och göra driftsättning i tjänstetecken som "råkar gå fel": kan det vara hårdvaran i er testmiljö? Vi får pröva igen i morgon).
Antar vi nu att projektet nått längre idag - jag har ej följt upp - kommer logiskt en punkt givet den utgångspunkt och idé-system för nationell säkerhet man tidigt indikerade som vision att se kritisk infrastruktur som kritisk oavsett om formellt statligt, i statligt kontrollerat bolag eller överhuvudtaget inte statligt.
D.v.s. vi kan tänka oss att man hänger på IDS-systemet utanför befintliga infrastruktur-nära eller stora internet-strukturer (ex. sökmotorer, sociala media m.m.).
Om så är fallet är frågan hur bra gjord IDS-lösningen är. Är den helt tyst är det excellent därför om den inte är tyst såvida inte whitening är infört välgjort (och det är den föga troligt om IDS-lösningen redan på trivial nivå inte är tyst) berättar den saker för mig. Den läcker information.
Mer uppenbart kan det handla om problem med den själv relaterat vilken mjukvara den har installerad. Inte lika problematiskt men väl så mycket lättare att angripa är om IDS-lösningen gör information sharing som kan användas för att politisk angripa entiteter som stött lösningen, konceptet i sig själv eller som den av en egentligen icke-relaterad länge pågående kampanj (där det inte behöver ha särskilt stor betydelse vem, vad eller ens hela USA som koncept den riktar sig mot så länge entiteten som är målet kan associeras till lösningen).
Antag nu att information relaterat "hostile spidering" d.v.s. strunta i dom små konfigurations-filerna och hämta ut den statistik vi är intresserade av säg ex. av några myndigheters sökmotorer (där även om jag inte nödvändigtvis själv skulle göra det vet att taket sitter ganska högt generellt på amerikanska myndigheters sajter: de klarar en hel del och vill dela information) propageras som risk indication till sökmotorer och internet-tjänster där du är inloggad.
Om så kan åtminstone jag se med din statistik över väldigt många koncept associerade politiska kampanjer såväl som några år en ganska flitig leverantör av press-releaser, nyhetshändelser (ex. företag A får en nyhet att leverera branschtidning B så att dom syns för att visa kompetens och slå-ner konkurrent inför upphandling relaterat säkerhetsproblem, driftinstabilitet eller liknande) o.s.v. att ett politiskt säkerhetshål har introducerats.
Vad mera är kommer nu frågan om information sharing konceptet i sig läcker information om användar-profilerna. Ingenting indikerar nu det och jag ser inte att jag korrekt kan pröva det liksom ej heller att jag skulle det med mindre än att man hade betalat mig per timme för det från nät- och produkt-ägare eller lösningen i sig indikerat hotar struktur jag har ett direkt ansvar för där finansiering hanteras i det och genomfört juridiskt korrekt (ej fallet). Men att sådana över-uttryckta information-sharing kan läcka information är en risk vi ska värdera jämförande med historiken vi har för generella kommunikationsprotokoll, krypteringslösningar i protokoll (jfr SSL, SPKM, GSS-api med associerade kompisar, Kerberos o.s.v.). Och när tester och quality assurance planeras tänka: På vilken nivå ungefär ligger vårt säkerhetstänk jämfört med generella kommunikations- och säkerhetsprotokoll? Och under det vilket eller vilka sådana är vår lösning beroende av? Där den stora frågan är om det hela rent av läcker direkt till klient i data och timing sequences den humpar tillbaka ner till.
Men här är vi ute i det mycket spekulativa därför jag har inte följt upp ens om lösningen fortsattes som projekt, om så driftsatts seriöst eller hur man ser den specifikt ska passas in. Jag noterade endast att man nät-dumper flaggade samtidigt som min webbläsare flaggade interferens rörande ett ej exakt motsvarande exempel men som möjligen föreslår något åt det hållet.
