Internet Banking Security Assessment Considerations
Aug 05, 2008 in Bank-en EFTPoS, Veiligheid
Ik was enige tijd geleden gevraagd wat voor soort dingen kan worden beschouwd bij het zoeken op Internet Bankieren.
Hieronder is een lijst van dingen die kunnen worden overwogen. Het was gewoon een brain dump en als zodanig kan niet worden voltooid.
Niet onderschatten de waarde van de norm voor uw infrastructuur, website configuratie, database-engine configuratie / architectuur, enscenering milieu en ontwikkeling / QA omgevingen.
Enkele ideeën:
- Veel niet blokkeren rekeningen na X mislukte logins, dit is normaal gesproken alleen voor een goede klantenservice, maar laat het systeem kwetsbaar.
- En alle andere dingen worden verwacht voor een externe sessie (gedwongen wachtwoord veranderingen, veroudering, etc.))
- Hulpmiddelen zoals Brutus kan worden gebruikt om brute kracht hack geauthentiseerd sessies.
- Veel mogelijk sessie volgnummers te worden opgehoogd, waardoor een geverifieerde gebruiker om andere klant sessie.
- Deze kan worden server, client-kant, op cookies gebaseerde, enz.
- Haal iemand om de ontwikkeling van methoden en de code wordt gebruikt.
- Database query strings kan worden geplaatst in de test invoervelden, waardoor tabel stortplaatsen tot browser.
- Controleer of alle pagina's zijn beveiligd en bevatten gebruikersverificatie vlaggen.
- Klant gegevens mogen niet worden gescheiden, dit moet worden gecontroleerd.
- Klant gegevens niet bewaard op de webserver.
- Authenticatie databanken / systeem moeten de gegevens niet op de webserver.
- De databanken moeten verblijven op een prive / semi-prive-netwerk.
- Een ander segment van de belangrijkste bancaire systeem.
- Webserver moet dubbele homed of gelijkwaardig (sommige VLAN technieken zijn goed)
- Aparte private en publieke netwerk kaarten, monitoring / backup / administratie
- Infrastructuur set-up expliciet ontkennen inbound / outbound havens, prive IP & controle ontsnapt uit het netwerk.
- Op alle gegevens segregatie punten zorgen regels bestaan die waardering voor al het verkeer dat punt.
- Alle klant-gegevens waar mogelijk moet afkomstig zijn van een veilige back-end database.
- Dit kan een staging omgeving. dat wil zeggen niet de voornaamste bank-systeem.
- Dit staat meestal voor transacties te verschijnen real-time aan de klant.
- Veel handelingen kunnen worden batched in werkelijkheid is. (intern of extern aan de bank)
- Zorgen voor passende regels zijn set-up op firewalls.
- Er moet worden inkomende en uitgaande regels over firewalls en routers filteren.
- Staan echter helemaal geen infrastructuur op de front-end om externe administratieve aansluitingen. (Telnet, etc.)
- Gebruik de seriële console poort te verbinden met een server of back-end-terminal-server.
- Kijk voor de scheiding / enscenering van online klant de inhoud van de voornaamste bankstelsels
- Ervoor zorgen dat een aparte ontwikkeling / QA / productie omgeving en geschikt proces is.
- Diensten die niet gebruikt worden door het systeem actief zijn
- Deze moeten worden uitgeschakeld.
- Port scan van de ondersteunende infrastructuur (routers / switches) en server (s).
- Onderzoek naar de redenen voor alle open poorten.
- Gebruik niet de belangrijkste toegangspoort voor betrouwbare partner toegang (clearing / RAS / enz.)
- Doe alles wat standaard IIS-controles en NT controles (Voorbeeld scripts, change management, patching methoden, enz.)
- Zorgen voor denial of service voorzorg in aanmerking zijn genomen voor alle infrastructuren en server apparatuur.
- Controleer de geschiktheid van de escalatie procedures gebruikt.
- Kijk voor real-time monitoring en alarmering.
- Kijk voor verantwoordelijkheid matrix.
- Kijk voor de eigendom van zaken.
- Overweeg stroomopwaarts vervoerder (s) kwetsbaarheid (denial of service, IP-spoofing, DNS hacking, enz.)
- Overweeg social engineering van klant-, administratieve, partner accounts / systemen en infrastructuur.
- Helpdesk procedures en het beleid en / of alternatieve technologieën (Caller ID, Gateway-IP, enz.).
- Gebruik maken van dynamische wachtwoorden waar mogelijk (SecureID, TACACS, enz.).
- Gebruik versleuteld tunnelling waar nodig (IPSec, Firewall-1, etc)
- Overwegen te kijken naar andere klant authenticatie methoden ter verbetering van bestaande methoden.
- Digitale cert, het IP-adres geblokkeerd te houden, enz.
- Overweeg het gebruik van CVV of CVN voor bank uitgegeven kaarten.
- Overwegen hoe wachtwoorden worden gedistribueerd / veranderd voor de klanten.
- Platte tekst e-mail, telefoon, enz.
- Kan wachtwoorden online worden gewijzigd?
- Is extra authenticatie gebruikt tussen delen van de diensten eenmaal geauthenticeerd?
- Overweeg wat de klant toegang heeft tot een keer geverifieerd.
- Kijk op SWIFT, RTGS-, inter-bank transfers, toegang tot krediet kaarten, enz.
- Als een aanvaller gaat krijgen, wat kan het doen?
- Gebruik technieken om pagina's, de klant gegevens worden niet opgeslagen in het cachegeheugen op ISP, of client systeem.
- Dit zijn vlaggen die kan worden ingesteld binnen pagina's.
- Normaal SSL-cache is opgeslagen, maar sommige proxy verkopers zijn spelen met technieken om dat te doen.
- Caching van SSL-pagina's op de client-systeem kan worden ingeschakeld op sommige browsers.
- Mei banken gebruik maken van een Java-(of soortgelijke) applet voor alle interactie met de consument, het beperken van alle caching kwesties.
- Zorgen voor de papieren en online-aansprakelijkheid clausules beschikbaar zijn alle getroffen gebieden.
- Zorgen binnen de klant aanmelden bancaire aansprakelijkheid wordt verminderd.
- Ik heb gezien uitspraken als "het gebruik van dit systeem op uw eigen risico, de verantwoordelijkheid voor eventuele aansprakelijkheid of vordering zal niet ... ..."
- Niet erg klantgericht, maar dat is wat hun juridische afdeling aanbevolen.
Alle bovenstaande kan effect op de veiligheid en / of de exploitatie van een on-line banking systeem.
Andere dingen om te overwegen:
- Externe ontwikkeling en ondersteuning van de aanvraag.
- Eigendom en beheer van de hardware / toepassingen
- Publishing punten voor nieuwe inhoud (intern / particulier / vertrouwde netwerk of internet)
- Topologie van front-end. Dwz Security Architecture document moet worden opgezet en beheerd adequaat.
- Zijn beperkt AP tests uitgevoerd telkens wanneer er wijzigingen zijn aangebracht aan het milieu? dwz geïntegreerde AP in Change Management proces.
- Database toegang. Is het gebufferd of is het live op de core banking-systemen.
- Welke faciliteiten zijn voorzien? Automatische incasso + Credit Card + SWIFT + ... .... Beschouw de verschillende scenario's voor uw aanval afhankelijk van de functie.
- Welke andere diensten worden gedeeld binnen het netwerk segment dat het Internet Banking-service wordt uitgevoerd. Kan deze worden gebruikt om de Internet Banking site. Bijv. verschillende support / bedrijven / organisaties met verschillende veiligheidsstrategieën / profielen.
- Overweeg alle externe ondersteunende diensten binnen je AP. Kijk interne / externe DNS vergiftiging kansen, mail relay, enz. Wat IPS's doen zij gebruik heeft de ISP enige kans om toegang te krijgen tot systemen of ondersteunende diensten, die van invloed kunnen zijn op Internet Bankieren.
- Afhankelijk van de grootte van de Bank, veel organisatie geen gebruik maken van dezelfde steungroepen voor de infrastructuur en de toepassing. Als gevolg externe verbindingen met de infrastructuur kunnen worden voorzien van een externe organisatie voor het beheer van de infrastructuur.
- Kijk naar het bedrijfsleven en de gebruikers authenticatie methoden en paden (client certs, beveiligde ID, smartcard, enz.). Beschouw twee factor authenticatie en moderne gebruiker identificatie methoden. Bijv. wat is uw favoriete voedsel in aanvulling op de normale gebruikersnamen en wachtwoorden. Heeft systeembeheer personeel gebruik maken van dynamische wachtwoorden (SecureID, etc)?
- Zien of de Internet Banking aanvraag stuurt e-mail aan gebruikers die kunnen bevatten interessante informatie.
- Betere toegang tot de applicatie kan doorgaans worden verkregen na toegang tot het systeem. dus krijg een legitieme account op het systeem. Ik heb geconstateerd dat sommige monster / administratie schermen zijn beperkt tot geauthentiseerde gebruikers.
- Overweeg social engineering de Help-desk te hebben een account wachtwoord resetten.




























