Due dilligence i nätverkssäkerhet

Rörande Comprehensive National Cybersecurity Initiative är initiativ sju intressant formulerat:

"Increase the security of our classified networks. Classified networks house the Federal Government’s most sensitive information and enable crucial war-fighting, diplomatic, counterterrorism, law enforcement, intelligence, and homeland security operations. Successful penetration or disruption of these networks could cause exceptionally grave damage to our national security. We need to exercise due diligence in ensuring the integrity of these networks and the data they contain."

Notera att man skriver due diligence och inte risk management vilket verkligen är två olika begrepp. Exakt hur man här ska tolka due diligence är svårt att exakt veta men gissningsvis menar man att kostnaden för att hålla något säkert givet riskerna hanterade i risk management måste vägas mot värdet det representerar och när det inte väger upp läggas ner.

Det tycker jag låter helt sunt och ju enklare struktur man har desto bättre kan det skyddas. Den situation som idag är det normala både i gamla företag, myndigheter och givetvis samlat amerikanska myndigheterna med enorma mängder affärs- och verksamhetssystem, nätverk, organisationer o.s.v. är oerhört svåra att ha överblick av.

Om man med due diligence menar vad jag tror är det vad jag tycker imponerar i det där dokumentet som jag i övrigt upplever kanske praktiskt uttrycker sig för singulärt rörande vissa praktiska saker. Säkerhet ska bäst vara enkelt, överblickbart och tillämpat på enkla saker. Givet detta handlar det sedan om att eliminera eventuell risk för Single point of failure:

"A Single Point of Failure, (SPOF), is a part of a system which, if it fails, will stop the entire system from working. They are undesirable in any system whose goal is high availability, be it a network, software application or other industrial system."

Samtidigt i stora organisationer finns en förkärlek för att skapa ett enormt projekt där man bygger en enorm silver bullet. Att bygga saker inom säkerhet är dock ingenting åtminstone jag skulle om jag hade övergripande ansvar för säkerhet skulle göra. Hellre skulle jag välja gamla om än betydligt mer begränsade än ett tänkt ideal fast inarbetade lösningar med välkända problem och kombinera dem.

Att bygga säkerhetslösningar är farligt. Det är vad bäst ett företag eller öppen källkods projekt gör specialiserat per applikation eller för ett fåtal. Att bygga säkerhetsapplikationer snarare än välja och implementera dem med ett specifikt framför ögonen ska man låta bli.

Ändå om jag nu ska gissa är jag lätt skeptisk till att det egentligen är vad man gjort. Snarast handlar det nog om konfiguration och paketering av ett par inarbetade lösningar. Då är dock frågan hur man gjort. Handlar Einstein 3 om att man switchar till en viss applikation som nu integreras och ersätter? Eller är det ett komplement? Elegant för att få security in deep är ju annars för en IDS något liknande:

1. IDS I - Något ganska trivialt men ändå för mer eller mindre allt ofta fullt tillräckligt. Snort är ett lika bra val som något annat.

2. IDS II - Propertiär utan något publikt känt men väsentligt annorlunda tänk. Fullstack inspection är självklart en möjlighet man ser till finns även om jag egentligen tvivlar på att det alltid tillför något. Poängen är dock att ha skild teknik jämfört med IDS I.

3. IDS III - Hanterar särskilda applikationer och verksamhets- och affärssystem för vilka utökade säkerhetskrav finns på. Det kan handla om vad man själv utvecklat eller köpt in. Ofta går stränger m.m. lägga i IDS I och IDS II men för stora nät har det vissa trevliga egenskaper att hålla allt specifikt separerat från dessa då det ändå representerar vad som implicit kan påverkas och för något som typiskt finns att tillgå att experimentera på.

4. IDS IV - Ligger både före och efter IDS I till III. Emulerar av och till trafik och kontrollerar att IDS:er korrekt svarar. En sak att här hantera är att detta inte får ske på ett sätt där kontroll av larm behöver ske men får heller inte innebära att faktiska angrepp motsvarande teststrängar inte larmar. Syftet är att IDS:er inte ska gå att ta ner och ev. rent av ersättas med en "fullt" funktionell IDS men som kontrolleras av denna. Även om en sådan kan passera dessa tester skapar sådant införande tidsluckor där ingen lösning svarar.

5. IDS V - Lösning ej aktuell för väldigt formella organisationer där inte en paranoid ledare kan lägga något eget men är verkligen vad som kan vara viktigt nog. Det är en lösning ingen annan mer än kanske någon annan vidrör eller ens behöver känna till. Kanske är den inte mer avancerad än att rapportera mängden nätverkstrafik som går till ett visst system.

I IDS I till V ligger vi nätverksarkitektur. En annan frågeställning är självklart IDS:er lokaliserade på enskilda system eller klienter (vilket givetvis också är aktuellt för IDS I - V i exemplet).

Även om man har ett lateralt tänk ovanför enskilda komponenter för att hålla allt enkelt och strukturerat är åtminstone en sak man absolut vill undvika att man har en enormt komplicerad och stor lösning samlat på en server som hanterar allt. Sådant är verkligen bara att öppna upp en till angreppsväg.