Jeg ble bedt om for en tid siden hva slags ting som kan være når du ser på Internett Bank.
Nedenfor er en liste over ting som kan vurderes. Det var bare en hjerne dump og derfor ikke kan fullføre.
Ikke undervurder verdien av standard for infrastruktur nettsted konfigurasjon database engine konfigurasjon / arkitektur, staging miljø og utvikling / QA miljøer.
Noen tanker:
- Mange ikke låse kontoer etter X mislykkede påloggingsforsøk, er dette normalt gjøres på god kundeservice, men forlater systemet sårbart.
- Og alle de andre tingene forventet for en ekstern påloggingsøkt (tvunget passordet endres, aldring, osv.))
- Verktøy som Brutus kan bruke til å "brute force hack autentiserte økter.
- Mange tillate økt sekvens tall skal økes, slik at en godkjent bruker for å se på andre kunde økt.
- Disse kan være server side, klientsiden, cookie basert osv.
- Få noen til å se utvikling metoder og koden som brukes.
- Database søkestrenger kan plasseres i test oppføring felt, lar tabellen dumper til leseren.
- Sjekk alle sider servert er trygge og inneholde brukergodkjenning flagg.
- Kundenes data kanskje ikke segregerte, dette må sjekkes.
- Kundenes data skal ikke ligge på Web Server.
- Godkjenning databaser / system data bør ikke ligge på webserveren.
- Databasene bør ligge på et privat / semi-private nettverk.
- Et annet segment til hovedsiden bank system.
- Webserver skal Dual homed eller tilsvarende (noen VLAN teknikkene er bra)
- Skill private og offentlige nettverk kort, overvåking / backup / administrasjon
- Infrastruktur satt opp til å nekte inngående / utgående porter, private IP og overvåking escaping fra nettverket.
- På alle data raseskille poeng at reglene er på plass som verdsetter trafikken skjønt det punktet.
- Alle kunders data der det er mulig bør være hentet fra en sikker baksystemer database.
- Dette kan være et oppsamlingssertifikat miljø. dvs. ingen hoveddisplayet bank system.
- Dette åpner 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 skal være inn-og utgående regler om brannmurer og filtrering rutere.
- Ikke la noen infrastruktur på grensesnittkonfigurasjon å tillate eksterne administrative tilkoblinger. (Telnet, etc.)
- Bruk seriell konsoll port til å koble til en server eller baksystemer terminalserveren.
- Kontroller at en egen utvikling / QA / produksjonsmiljø og egnet prosessen er på plass.
- Tjenester som 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 årsakene til alle åpne porter.
- Ikke bruk de viktigste inngangsporten for klarerte partner tilgang (clearing / RAS / osv.)
- Gjøre alt som standard IIS kontrollerer og NT sjekker (Eksempelkode scripts, endringsledelse, patching metoder, etc.)
- Sikre tjenestenekt forholdsregler er tatt i betraktning for all infrastruktur og serverutstyr.
- Sjekk tilstrekkeligheten av opptrapping prosedyrer brukes.
- Se for sanntids overvåking og varsler.
- Se for ansvar matrise.
- Se for eierskap til saker.
- Tenk oppstrøms operatøren (e) sårbarhet (denial of service, IP-etterligning, DNS hacking, etc)
- Tenk social engineering av kunden, administrative, partner accounts / systemer / infrastruktur.
- Helpdesk prosedyrer og retningslinjer og / eller alternative teknologier (innringer-ID, Gateway IP, etc.).
- Bruk dynamisk passord hvor mulig (SecureID, TACACS osv.).
- Bruke krypterte tunneler hvor nødvendig (IPSec, Firewall-1, etc)
- Vurdere å se på andre kunde godkjenningsmetodene å forbedre eksisterende metoder.
- Digital sertifikat, IP-adresse låst til kontoen, etc.
- Vurder bruk av CVV eller CVN for banken utstedt kort.
- Vurder hvor passord blir distribuert / endret for kunder.
- Ren tekst e-post, telefon, etc.
- Kan passordene endres på nettet?
- Er ytterligere autentisering brukes mellom deler av tjenestene gang godkjent?
- Tenk hva kunden har tilgang til én godkjent.
- Se på SWIFT, RTGS, inter-bankoverføringer, tilgang til kredittkort, etc.
- Hvis en angriper does komme i, hva kan de gjøre?
- Bruke teknikker for å sikre sider, kunde detaljer ikke hurtigbufret til ISP-eller klient-system.
- Dette er flagg som kan settes i sidene.
- Normalt SSL hurtigbufres, men noen proxy leverandører har spilt med teknikker til å gjøre det.
- Hurtigbufring av SSL sider på klientsystemet kan slås på i noen nettlesere.
- Mai banker bruke en Java (eller lignende) appleten for alle kundebevegelsene, begrense alle hurtigbufring problemer.
- Sikre papirbasert og on-line ansvar klausuler er tilgjengelig, er alle berørt områder.
- Sikre innenfor kunde registreringsprosess banktjenester ansvar er redusert.
- Jeg har sett utsagn som "bruker dette systemet på egen risiko, ansvar for erstatningsansvar eller krav vil IKKE ... ..."
- Ikke veldig kundeorientert, men det er hva deres juridiske avdeling anbefales.
Alle disse kan påvirke sikkerhet og / eller drift av et on-line bank system.
Andre ting du bør vurdere:
- Eksterne utvikling og support av programmet.
- Eierskap og styring av maskinvare / programmer
- Publiseringsløsning for nytt innhold (intern / privat / betrodde nettverk eller Internett)
- Topology av grensesnitt. Dvs. Security Architecture dokumentet bør være på plass og håndteres på riktig måte.
- Er begrenset AP testene utføres når det er gjort endringer for miljøet? dvs. integrert AP i Change prosess.
- Database tilgang. Er det bufrede eller er det live til kjernen banksystemer.
- Hva er gitt? Direkte belastning + Kreditkort + SWIFT + ... .... Vurdere ulike scenarier for angrep avhengig av funksjonen.
- Hvilke andre tjenester er delt innen nettverket segment at Internet Banking tjenesten kjører. Kan dette brukes til å kompromittere Internet Banking området. f.eks. forskjellige support / bedrift / utvikling organisasjoner med ulike sikkerhetsstrategier / profiler.
- Betrakt alle eksterne støtter tjenester innen du AP. Se på intern / ekstern DNS forgiftning muligheter post relé, etc. Hva IPS's bruker de har ISP noen mulighet til å få tilgang til systemer eller støtte tjenester som kan påvirke Internet Banking.
- Avhengig av størrelsen på Bank, mange organisasjonen ikke bruke samme støtte grupper for infrastruktur og programmet. Som et resultat av eksterne tilkoblinger til infrastrukturen kan gis for en ekstern støtte organisasjonen til å administrere infrastrukturen.
- Se på forretnings-og brukergodkjenning metoder og baner (klientsiden certs, sikker ID, smartkort, etc). Tenk to faktor autentisering og moderne brukeren identifikasjon metoder. f.eks. Hva er din favoritt mat i tillegg til vanlig brukernavn og passord. Har systemadministrasjon staff bruke dynamiske passord (secureID, osv.)?
- Se om Internet Banking programmet sender e-post til brukerne som kan inneholde interessant informasjon.
- Bedre tilgang til programmet er vanligvis fikk 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.
- Tenk social engineering Hjelp desk å ha en konto passord.
