Internet Banking Assessment betraktninger
Jeg ble bedt om en tid siden hva slags ting kan være når vi ser på Internet Banking.
Nedenfor er en liste over ting som kan vurderes. Det var bare en hjerne dump og som sådan ikke kan fullføre.
Ikke undervurder verdien av standard for infrastruktur, nettside-konfigurasjon, database konfigurasjon / arkitektur, staging miljø og utvikling / QA miljøer.
Noen tanker:
- Mange ikke låse regnskapet etter X mislykkede pålogginger, er dette normalt gjøres for god kundeservice, men blader systemet sårbart.
- Og alle andre ting som forventet for en ekstern innloggingen (tvungen endring av passord, aldring, osv.))
- Verktøy som Brutus kan bli bruk for å "brute force" hacke autentiserte sesjoner.
- Mange tillate økt sekvensnummere skal økes, slik at en godkjent bruker for å vise andre kunde økt.
- Disse kan være server side, klientsiden, cookie-basert, etc.
- Få noen til å kontrollere utviklingen metoder og koden som blir brukt.
- Database søkestrenger kan settes inn i testen oppføring felt, slik at tabellen dumper til leseren.
- Kontroller alle sider som serveres er sikre og inneholde brukergodkjenning flagg.
- Kundens data kanskje ikke isolert, dette må sjekkes.
- Kundens data bør ikke ligge på webserveren.
- Godkjenning databaser / system data bør ikke ligge på webserveren.
- Databasene bør ligge på et privat / semi-private nettverk.
- Et annet segment til de viktigste banktjenester systemet.
- Webserver bør doble homed eller tilsvarende (noen VLAN teknikkene er bra)
- Skill private og offentlige nettverk kort, overvåking / backup / administrasjon
- Infrastruktur oppsettet for å eksplisitt nekte inngående / utgående porter, private IP og overvåking rømmer fra nettverket.
- På alle data raseskille poeng at reglene er på plass som verdsetter trafikken selv om dette punktet.
- Alle kunders data der det er mulig bør være hentet fra en sikker back-end database.
- Dette kan være en staging-miljø. dvs. ikke de viktigste banktjenester systemet.
- Dette gjør det mulig for transaksjoner som skal vises i sanntid til kunden.
- Mange transaksjoner kan være batched i virkeligheten. (intern eller ekstern til banken)
- Sikre hensiktsmessige regler har blitt satt opp på brannmurer.
- Det bør være inngående og utgående regler om brannmurer og rutere filtrering.
- Ikke tillater noen infrastruktur på grensesnitt for å la eksterne administrative forbindelser. (Telnet, etc.)
- Bruk seriell konsoll port til å koble til en server eller back-end terminalserver.
- Se etter raseskille / staging av online kunde innhold fra viktigste banktjenester systemer
- Sikre at en egen utvikling / QA / produksjon miljø-systemet og egner prosessen er på plass.
- Tjenester ikke brukes av systemet er aktive
- Disse bør være deaktivert.
- Port scan av støtte infrastruktur (routere / switcher) og server (e).
- Undersøk årsaken til alle åpne porter.
- Ikke bruk den viktigste inngangsporten for pålitelig partner tilgang (clearing / RAS / etc.)
- Har alle som standard IIS-kontroller og NT-sjekker (eksempelskriptene, endrer ledelse, patching metoder, etc.)
- Sikre denial of service forholdsregler har blitt tatt i betraktning for all infrastruktur og server utstyret.
- Kontroller tilstrekkelighet av opptrapping prosedyrene brukes.
- Se for real-time overvåking og alarmering.
- Se for ansvar matrise.
- Se for eierskap av problemene.
- Vurder oppstrøms operatøren (e) sårbarhet (denial of service, IP spoofing, DNS hacking, etc)
- Vurder social engineering av kunden, administrative, partner accounts / systemer / infrastruktur.
- Helpdesk prosedyrer og retningslinjer og / eller alternative teknologier (ringer, Gateway IP, etc.).
- Bruk dynamisk passord hvor mulig (SecureID, TACACS, osv.).
- Bruk kryptert tunnelling hvor nødvendig (IPSec, Firewall-1, osv.)
- Vurder å se på andre kunde-godkjenning metoder for å forbedre eksisterende metoder.
- Digitale sertifikat, IP-adresse låst til kontoen din, osv.
- Vurder bruk av CVV eller CVN for banken utstedt kort.
- Vurder hvor passord blir distribuert / endret for kunder.
- Vanlig tekst e-post, telefon, etc.
- Kan bli endret passordene på nettet?
- Er ytterligere godkjenning brukt mellom deler av tjenestene gang godkjent?
- Vurdere hva kunden har tilgang til én godkjent.
- Se på SWIFT, RTGS, inter-bankoverføringer, tilgang til kredittkort, etc.
- Hvis en angriper ser komme i, hva kan de gjøre?
- Bruke teknikker for å sikre sider, kunde detaljene ikke er bufret på ISP, eller klient.
- Dette er flagg som kan settes i sidene.
- Normalt SSL er arkivert, men noen proxy-leverandører har vært å spille med teknikker for å gjøre det.
- Caching av SSL sider på klienten systemet kan slås på på enkelte nettlesere.
- Mai banker bruker et Java (eller lignende) applet for alle kunde interaksjon, begrenser all caching problemer.
- Sikre papir basert og on-line ansvar klausuler er tilgjengelig, er adressen alle berørt områder.
- Sikre innenfor kunde-registreringsprosessen banktjenester ansvar er redusert.
- Jeg har sett utsagn som "bruk dette systemet på eget ansvar, ansvar for eventuelle erstatningskrav eller krav vil IKKE ... ..."
- Ikke veldig kundeorientert, men det er det deres juridiske avdeling anbefales.
Alle disse kan påvirke sikkerhet og / eller drift av en on-line bank-systemet.
Andre ting å vurdere:
- Eksterne utvikling og støtte av programmet.
- Eierskap og styring av maskinvare og applikasjoner
- Publisering poeng for nytt innhold (intern / privat / betrodde nettverk eller Internett)
- Topologi av grensesnitt. Dvs. Security Architecture dokumentet bør være på plass og forvaltet på riktig måte.
- Er begrenset AP tester som er utført når det er gjort endringer for miljøet? dvs. integrert AP i Change Management prosess.
- Database tilgang. Er det bufret eller er det live til kjernen banktjenester systemer.
- Hvilke fasiliteter er gitt? Direkte belastning + Kreditkort + SWIFT + ... .... Vurdere ulike scenarier for angrep avhengig av funksjonen.
- Hvilke andre tjenester er delt i nettverket segment som Internett Banking-tjenesten kjører. Kan dette brukes til å kompromittere Internet Banking området. f.eks. forskjellige support / bedrift / utvikling organisasjoner med ulik sikkerhet strategier / profiler.
- Vurder alle ytre støtte tjenester innen du AP. Se på interne / eksterne DNS-forgiftning muligheter, e-post relé, etc. Hva IPS står gjøre de bruker har ISP noen mulighet til å få tilgang til systemer eller støtte for tjenester som kan påvirke Internet Banking.
- Avhengig av størrelsen på Bank, mange organisasjonen ikke bruker den samme støtte grupper for infrastruktur og programmet. Som et resultat av eksterne tilkoblinger til infrastruktur kan være tilgjengelig for en ekstern støtte organisasjonen til å administrere infrastrukturen.
- Se på forretnings-og brukergodkjenning metoder og baner (klientsiden trening, sikker ID, smartkort, osv.). To faktor autentisering og moderne brukeren identifikasjon metoder. f.eks. Hva er din favorittmat i tillegg til vanlige brukernavn og passord. Har systemadministrasjon personalet bruke dynamiske passord (secureID, osv.)?
- Se om Internett Banking-programmet sender e-post til brukere som kan inneholde interessant informasjon.
- Bedre tilgang til programmet kan vanligvis være vunnet etter tilgang til systemet. dvs. få en legitim konto på systemet. Jeg har funnet ut at noen eksempler / administrasjon skjermene har vært begrenset til godkjente brukere bare.
- Vurder social engineering i Help Desk å ha en konto for tilbakestilling av passord.
Legg igjen en Svar