Internet Banking Security Assessment överväganden

Tisdagen den 5 aug, 2008 @ 10:38 | Banking och Eftpos, säkerhet

Jag fick för en tid sedan vad för slags saker kan beaktas när man tittar på Internet Banking.

Nedan följer en lista över saker som skulle kunna övervägas. Det var bara en hjärna dumpa och som sådan kanske inte är fullständiga.

Underskatta inte värdet av standard för din infrastruktur, webbplats konfiguration, databas motor / arkitektur, mellanstationer miljö och utveckling / kvalitetssäkring miljöer.

Några tankar:

Många inte låsa konton efter X misslyckade inloggningar, detta görs normalt för god kundservice, men lämnar systemet sårbart.

- Och alla andra saker som förväntas för en avlägsen session (tvingas lösenord förändringar, åldrande, etc))
- Verktyg som Brutus kan använda för att "brute force" hack autentiserade sessioner.

Många tillåta session sekvens nummer som ska ökas så att en autentiserad användare att se andra kund-session.

- Det kan röra serversidan, klientsidan, cookie-baserad, etc.
- Få någon att kontrollera att utveckla metoder och den kod som används.
- Databasfrågan strängar kan placeras i test post områden, vilket gör att tabellen tippar att webbläsaren.
- Kontrollera alla sidor ska visas är säker och innehålla användarverifiering flaggor.

Kunden Uppgifterna får inte vara åtskilda, detta behöver kontrolleras.
Kunduppgifter borde inte finnas på webbservern.

Autentisering databaser / system data bör inte uppehålla sig på den webbserver.
De databaser som bör finnas på en privat / semi-privat nätverk.

- Ett annat segment med de viktigaste banksystemet.

Webbserver bör dubbla homing eller motsvarande (vissa VLAN teknik är bra)

- Separat privata och offentliga nätverkskort, övervakning / backup / administration
- Infrastruktur-set-up för att uttryckligen förneka inkommande / utgående hamnar, privata IP-övervakning flyr från nätet.

Vid alla uppgifter segregation punkter se regler som finns på plats uppskattar trafiken även om denna punkt.

Alla kunduppgifter när så är möjligt bör anskaffas från en säker back-end databas.

- Detta kan vara en mellanstation miljön. dvs de viktigaste banksystemet.
- Denna regel gör det möjligt för transaktioner ska visas i realtid till kunden.
- Många transaktioner kan batched i verkligheten. (intern eller extern till banken)

Se regler som har satts upp brandväggar.

- Det bör finnas för inkommande och utgående regler om brandväggar och filtrering routrar.

Låt inte någon infrastruktur på användargränssnitt för att möjliggöra fjärrkörning av administrativa anslutningar. (Telnet, etc.)

- Använd seriekonsoll port för att ansluta till en server eller back-end Terminal Server.

Håll utkik efter segregation / mellanstationer på nätet kund innehåll från centrala banksystem

Se till att en separat utveckling / QA / produktionsmiljö och lämplig process är på plats.

Tjänster som inte används av systemet är aktiva

- Dessa bör vara inaktiverade.

Port scan av infrastruktur (routrar / växlar) och server (s).

- Undersöka orsakerna till allt öppna portar.

Använd inte de viktigaste gateway för tillförlitliga partners (clearing / RAS / mm)
Göra allt som standard IIS-kontroller och NT kontroller (Exempelskript, Change Management, lappverk metoder, etc.)
Se denial of service försiktighetsåtgärd har beaktats för all infrastruktur och server utrustning.
Kontrollera tillförlitligheten hos den upptrappning som används.

- Titta för övervakning i realtid och larm.
- Leta efter ansvar matris.
- Leta efter ägande av frågor.

Överväga uppströms transportör (er) sårbarhet (denial of service, IP-spoofing, DNS hacking, etc.)
Överväga social ingenjörskonst av kund-, förvaltnings-, partner-konton / system / infrastruktur.

- Helpdesk och politik och / eller alternativa tekniker (telefon, Gateway IP, etc.).

Använda dynamiska lösenord där så är möjligt (SecureID, TACACS, etc.).
Använda krypterade tunnlar där det behövs (IPSec, Firewall 1, etc)
Överväga att titta på andra kunden metoder för att förbättra befintliga metoder.

- Digital CERT, IP-adress låst till svars, etc.
- Överväg användning av CVV eller CVN för banken utfärdade kort.

Överväga hur lösenord distribueras / ändrats för kunderna.

- Vanlig text e-post, telefon etc.
- Kan lösenord ändras online?

Är ytterligare verifiering användas mellan delar av de tjänster som en gång verifieras?
Överväga vad kunden har tillgång till en gång verifieras.

- Titta på SWIFT, RTGS-, mellan-banköverföringar, tillgång till kreditkort, etc.
- Om en angripare blir i, vad kan de göra?

Använda tekniker för att säkerställa sidor, kundens information inte är cachad på ISP, eller klient system.

- Det är flaggor som kan ställas in inom sidor.
- Normalt SSL är cachad, men vissa proxy säljare har spelat med teknik att göra det.
- Cachning av SSL-sidor på kundens system kan kopplas på om vissa webbläsare.
- Maj banker använder ett Java (eller liknande) applet för alla kundernas interaktioner, som begränsar alla caching frågor.

Se pappersform och på nätet ansvar klausuler som finns tillgängliga är itu med alla de berörda områdena.
Se inom kunden registrerar sig process bank ansvar minskas.

- Jag har sett uttalanden som "använda detta system på egen risk, ansvar för eventuell skuld eller fordran kommer inte ... ..."
- Inte mycket kundorientering, men det är vad deras juridiska avdelning rekommenderas.

Alla ovanstående kan verkställa säkerhet och / eller drift av en on-line banking system.

Andra saker att tänka på:

Extern utveckling och stöd för ansökan.
Ägandet och ledningen av hårdvara / program
Publicering för nytt innehåll (inre / privat / betrodda nätverk eller Internet)
Topologi av gränssnitt. Dvs Security Architecture dokument bör vara på plats och hanteras på lämpligt sätt.
Är begränsade AP test som utförs när förändringar görs för miljön? dvs integrerat AP i Change management process.
Databas access. Är det buffrade eller är det levande till centrala banksystem.
Vilka hjälpmedel finns? Direktdebitering + Kreditkort + SWIFT + ... .... Överväga olika scenarier för din attack beroende på funktion.
Vilka andra tjänster som är gemensamma inom nätverket segment som Internet Banking körs. Kan denna användas för att äventyra Internet Banking webbplats. t.ex.. olika stöd / företag / organisationer med olika strategier / profiler.
Beakta alla externa stödtjänster inom dig AP. Titta på interna / externa DNS-förgiftning möjligheter, post relä, etc. Vad IPS: s använder de har ISP någon möjlighet att få tillgång till system eller stödtjänster som kan påverka Internet Banking.
Beroende på storleken på banken, många organisationen inte använder samma stöd grupper för infrastruktur och tillämpning. Som en följd av externa anslutningar till infrastruktur kan tillhandahållas för ett externt stöd organisationen för att förvalta infrastruktur.
Titta på företag och användarverifiering metoder och vägar (klientsidan CERT, säkra ID, Smart Card, etc). Överväg två faktor autentisering och moderna användaren att identifiera metoder. t.ex.. Vad är din favoritmat utöver normal användarnamn och lösenord. Har systemadministration personal använda engångslösenord (SecureID, etc)?
Se om Internet Banking ansökan skickar e-post till användare som kan innehålla intressant information.
Bättre tillgång till ansökan kan i allmänhet fick efter tillträde till systemet. dvs få en legitim grund för systemet. Jag har upptäckt att vissa prov / administration skärmar har begränsats till autentiserade användare.
Överväga social ingenjörskonst "Help Desk" att ha ett konto återställa lösenord.