Internet Banking Security Assessment overwegingen
Ik was enige tijd geleden gevraagd wat voor soort dingen kunnen worden beschouwd als gekeken wordt naar Internet Banking.
Hieronder vindt u een lijst van dingen die zouden 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, de organisatie milieu en ontwikkeling / QA-omgevingen.
Enkele ideeën:
- Veel geen lock-accounts na X mislukte aanmeldingen, dit is normaal gesproken alleen voor een goede klantenservice, maar laat het systeem kwetsbaar.
- En alle andere dingen worden verwacht voor een externe aanmeldingsgegevens zitting (gedwongen wachtwoord veranderingen, veroudering, etc))
- Tools zoals Brutus kan worden gebruikt om brute force hack gewaarmerkt sessies.
- Veel sessie toestaan volgnummers te worden opgehoogd, zodat een geverifieerde gebruiker om een andere klant sessie.
- Dit kan worden serverkant, client-kant, op cookies gebaseerde, enz.
- Kies iemand uit om te controleren of de ontwikkeling van methoden en de code die gebruikt wordt.
- Database-query strings kan worden geplaatst in de test invoervelden, waardoor tabel stortplaatsen te browser.
- Controleer alle pagina's geserveerd worden beveiligd en bevatten gebruikersverificatie vlaggen.
- Klant gegevens mogen niet worden gescheiden, dit moet worden gecontroleerd.
- Klant gegevens niet bewaard op de webserver.
- Authenticatie databases / system-gegevens niet bewaard op de webserver.
- De databanken moeten verblijven op een prive / semi-prive-netwerk.
- Een ander segment van de belangrijkste bancaire systeem.
- Webserver moet worden dual homed of gelijkwaardig (sommige VLAN technieken zijn goed)
- Aparte private en publieke netwerkkaarten, monitoring / backup / administratie
- Infrastructuur set-up om expliciet ontkennen inbound / outbound havens, prive IP & monitoring ontsnappen uit het netwerk.
- Op alle gegevens segregatie punten zorgen regels bestaan die waardering voor al het verkeer dat punt.
- Alle klantgegevens waar mogelijk moet afkomstig zijn van een veilige back-end database.
- Dit kan een staging omgeving. dat wil zeggen niet de voornaamste bank-systeem.
- Deze doorgaans in staat om transacties te verschijnen real-time aan de klant.
- Veel transacties kunnen worden batched in werkelijkheid is. (intern of extern zijn aan de bank)
- Zorgen voor adequate regels zijn set-up op firewalls.
- Er moet worden inkomende en uitgaande regels inzake filtering firewalls en routers.
- Laat niet toe dat alle infrastructuur op de front-end, zodat de administratieve aansluitingen. (Telnet, etc.)
- Gebruik de seriële console poort voor verbinding met een server of back-end terminal server.
- Kijk voor de scheiding / enscenering van de online klant de inhoud van de voornaamste bancaire systemen
- Zorg ervoor dat een aparte ontwikkeling / QA / productie-omgeving en geschikt proces is op zijn plaats.
- 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 vertrouwde partner toegang (clearing / RAS / enz.)
- Doe alles wat standaard IIS-controles en de controles NT (Sample scripts, change management, patching methoden, enz.)
- Zorgen voor denial of service voorzorg rekening is gehouden voor alle infrastructuur-en server-apparatuur.
- Controleer de toereikendheid van de escalatie procedures gebruikt.
- Kijk voor real-time monitoring en alarmering.
- Kijk voor verantwoordelijkheid matrix.
- Kijk voor de eigendom van zaken.
- Overweeg upstream vervoerder (s) kwetsbaarheid (denial of service, IP-spoofing, DNS hacking, enz.)
- Denk aan social engineering van de klant, de bestuurs-, partner-accounts / systemen en infrastructuur.
- Helpdesk procedures en het beleid en / of alternatieve technologieën (Caller ID, IP, enz.).
- Gebruik dynamische wachtwoorden waar dat mogelijk is (SecureID, TACACS, etc.).
- Gebruik encrypted tunneling zo nodig (IPSec, Firewall-1, etc)
- Overwegen te kijken naar een andere klant authenticatie methoden ter verbetering van bestaande methoden.
- Digitale cert, het IP-adres geblokkeerd ter verantwoording te roepen, enz.
- Overweeg het gebruik van CVV of CVN voor de bank uitgegeven kaarten.
- Denk aan de manier waarop wachtwoorden worden gedistribueerd / veranderd voor de klanten.
- Platte tekst e-mail, telefoon, enz.
- Kan wachtwoorden online worden gewijzigd?
- Is extra authenticatie gebruikt tussen afdelingen van de diensten eenmaal geauthenticeerd?
- Denk aan wat de klant toegang heeft tot een keer geverifieerd.
- Kijk naar SWIFT, RTGS-, inter-bank transfers, toegang tot credit cards, enz.
- Als een hacker 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-leveranciers zijn te spelen met technieken om dat te doen.
- Caching van SSL-pagina's op het client systeem kan worden ingeschakeld op sommige browsers.
- Mei banken gebruik maken van een Java (of soortgelijke) applet voor alle interactie met de klant, het beperken van alle aspecten cachegebruik.
- Zorgen voor de papieren en on-line aansprakelijkheid clausules beschikbaar zijn, worden alle getroffen gebieden.
- Zorgen binnen de klant aanmelden bancaire aansprakelijkheid, wordt verkleind.
- Ik heb gezien dat uitspraken als "dit systeem gebruiken voor uw eigen risico, de verantwoordelijkheid voor eventuele aansprakelijkheid of vordering wordt NIET ... ..."
- Niet erg klantgericht, maar dat is wat hun juridische afdeling aanbevolen.
Al het bovenstaande is van invloed op de veiligheid en / of de exploitatie van een on-line banking systeem.
Andere overwegingen:
- Externe ontwikkeling en ondersteuning van de aanvraag.
- Eigendom en beheer van de hardware / toepassingen
- Publishing punten voor de nieuwe inhoud (intern / particulier / vertrouwde netwerk of internet)
- Topologie van de front-end. Dwz Security Architecture document moeten worden in plaats en adequaat beheerd.
- Zijn beperkte AP tests die worden uitgevoerd wanneer er wijzigingen zijn aangebracht aan het milieu? dwz geïntegreerde AP in Change management proces.
- Database toegang. Is het gebufferd of is het leven tot een kerntemperatuur van bancaire systemen.
- Welke voorzieningen worden aangeboden? Automatische incasso + Credit Card + SWIFT + ... .... Denk aan verschillende scenario's voor uw aanval, afhankelijk van de functie.
- Welke andere diensten worden gedeeld binnen het netwerk segment dat Internet Banking-service wordt uitgevoerd. Kan dit worden gebruikt om de Internet Banking site. Bijv. verschillende support / bedrijven / organisaties met verschillende veiligheids-strategieën / profielen.
- Overweeg alle externe ondersteunende diensten binnen je AP. Kijk eens naar de interne / externe DNS-poisoning kansen, mail relay, enz. Wat IPS doen ze gebruiken heeft de ISP geen enkele mogelijkheid om toegang te krijgen tot systemen of ondersteunende diensten die van invloed kunnen zijn op Internet Banking.
- Afhankelijk van de omvang van de bank, veel organisatie geen gebruik maken van dezelfde steungroepen voor de infrastructuur en de toepassing. Als gevolg externe aansluitingen op de infrastructuur kunnen worden voorzien in een externe organisatie voor het beheer van de infrastructuur.
- Kijk bij de zakenreiziger en de gebruiker authenticatie methoden en paden (client certificaten, beveiligde ID, Smart Card, etc). Beschouw twee factor authenticatie en de moderne gebruiker identificatie methoden. Bijv. wat is je favoriete voedsel Naast de normale gebruikersnamen en wachtwoorden. Doe systeembeheer medewerkers gebruik maken van dynamische wachtwoorden (SecureID, etc)?
- Kijk of de Internet Banking applicatie stuurt e-mail aan gebruikers die kunnen bevatten interessante informatie.
- Betere toegang tot de applicatie kunnen over het algemeen worden opgedaan na de toegang tot het systeem. dat wil zeggen krijgen een legitieme account op het systeem. Ik heb geconstateerd dat sommige monster / administratie-schermen zijn beperkt tot geverifieerde gebruikers.
- Denk aan social engineering de Help-desk te beschikken over een wachtwoord voor een account resetten.
Verlaat een Antwoord