Visma Cloud Gateway security risk High

[Terjes1]

Visma Cloud Gateway blir flagget av vår SOC tjeneste ettersom den oppretter en SSH tunell mot Visma.

For de som ikke er så teknisk så betyr det at Visma har en bakvei inn i systemene. At de kan fra sitt miljø koble seg inn mot Visma serveren lokalt hos kundene og bruke denne tunellen til å hoppe videre til andre servere.

Hvis Visma blir rammet av en ondsinnet aktør så kan de bruke denne tunellen til å ramme kundene sine systemer.

Er det noen som kjenner til hva denne SSH tunellen brukes til?

Er dette noe som må være der for at Visma Business skal fungere med utgående EHF faktura?

[Ruben_Auren]

Hei og takk for gode spørsmål! 

For å starte med det enkle spørsmålet først, VCG benyttes ikke til utsending av faktura. Dette er en API-integrasjon. 

VCG har som formål å opprette en kobling mellom Våre on premise systemer (Visma Business, Visma Global osv) og Visma.net. Hovedsaklig gjelder det Visma.net Approval, Visma.net Autopay, Visma.net Expense, Visma.net Autoreport og Visma.net Payroll.

For at kommunikasjon mellom f.eks Visma Business og disse tjenestene skal fungere må SSH-koblingen fungere. 
Denne koblingen, eller tunnelen opprettes ved å hente et sertifikat i fra Visma.net. Det skjer med at en person som har kundeadministratorrettigheter logger på Visma.net via VCG. Når denne tunnelen lages er det en dedikert kommunikasjonsplatform mellom akkurat denne maskinen, og Visma.net. Det er mulig å opprette flere VCG instanser på en server med kobling mot flere kunder i Visma.net verden, men det kan bare være en kobling mot en visma.net bruker mot en visma.net kunde. 

Vi har også ekstra sikkerhetssjekk over denne tunnelen som sjekker at SSH-brukeren, porten og Visma.netbruker matcher det som er registrert på tunnelen. 
Du finner mer detaljert informasjon om denne SSH-koblingen i dokumentasjonen jeg har lagt ved. 😊

Glemte å svare på det siste spørsmålet: VCG er den eneste mulige løsningen for å få kommunikasjon mellom Visma Business og Visma.net. Det vil si at for at Autopay skal fungere mot Visma Business må denne tunnelen være åpen.

Mvh
Ruben

[Terjes1]

Hei,

Og takk for svar.

Ut fra dokumentasjonen du har sendt så ser det ikke ut som det er noen begrensinger på SSH tunellen, slik at det då finnes en bakdør fra serveren hos dere og inn i våre systemer.

At Visma systemene hos oss kan sende data til dere via denne tunellen er OK, problemet ligger i at dere kan bruke den samme tunellen til å nå systemene hos oss.

Denne kan då potensielt misbrukes til å hoppe videre inn til andre systemer hos oss.

Stemmer dette?

[Ruben_Auren]

Hei!

Informasjonen som går via denne tunnelen er svært begrenset, det er oppdateringer fra ulike Visma.net applikasjoner. All kommunikasjon er dessuten kraftig kryptert. 😊

Det er nok mye enklere å opprette en egen SSH tunnel mot vår eller deres server direkte enn å prøve å komme inn til deres server via denne tunnelen.

Ellers kan jeg trygge deg med at vi har svært høyt fokus på sikkerhet i våre skyløsninger, som du kan lese mer om her https://www.visma.com/trust-centre/security

Ellers tilbyr vi også ISAE 3402 type ll rapport utført av Deloitte, dette kan forespørres av vårt kundesenter. Vi har også ISO 27001 sertifikat du kan laste ned her: https://www.visma.com/trust-centre/vismaclouddelivery

[Terjes1]

Då er det som jeg mistenkte satt opp en bakdør.
At dere fra den visma serveren hos dere kan bruke denne tunellen til å komme inn til kundene sine lokale systemer.

Så hvis dere får noen uønskede inn på dåkes systemer eller har en ansatt med uærlige hensikter så kan de ramme systemene til kundene også.

Hva er grunnen til at det er valgt å sette det opp slik i stedet for en kryptert API tjeneste der en slipper denne bakdøren?

Systemene hos kunden bør hente eller sende data, leverandøren bør ikke kunde sende data til kunden sine interne systemer.

En programleverandør bør aldri ha tilgang til å kunne nå systemene til kundene uten at kunden slipper inn leverandøren. Denne SSH tunellen gir dere muligheter til å rute trafikken til hvilken som helst port på serveren eller annet utstyr som står på det samme nettverket til serveren.

Dess flere tilganger inn dess større er sannsynligheten for å bli rammet.

SSH tunnelen åpner opp for veldig mange muligheter som vi som kunde ikke ønsker skal være mulig.

https://www.ssh.com/academy/ssh/tunneling-example

[Ruben_Auren]

Hei!

Hvorfor denne løsningen er valgt fremfor API skyldes kost/nytte og mengde data i noen tilfeller. Synk av masterdata blir for risikabelt med API eller Webhooks f.eks.
Uønskede personer vil få svært store vanskeligheter med å bruke denne tunnelen, det er derfor mye større risiko for at det opprettes en ny tunnel, og det får de ikke gjort ut mot dere kunder via våre servere, da må de ha klart å opprette tilgang til deres egne. 

SSH i seg selv er ikke en usikker måte å sende data på, hovedproblemet med SSH er at det er så enkelt å opprette en slik tunnel, selv for personer uten noen særlig kompetanse innenfor data. Men å bryte seg inn på en eksisterende tunnel blir noe helt annet, interne ressurser mener det er tilnærmet umulig. 

Visma kunne jo selvsagt ha misbrukt denne tunnelen, men det ville ha vært såppas ødeleggende for vårt omdømme at vi må sikre disse også mot eventuelle interne trusler hos oss, ikke bare eksterne. ISAE 3402-rapporten vil si en god del om hvordan vi jobber med sikkerhet internt. 😊

[Terjes1]

Å opprette en ny SSH tunell i vårt miljø er umulig ettersom vi følger Zero trust prinsippet der vi kun åpner opp for applikasjoner og IP adresser som er nødvendig.

Årsaken til at dette fungere mot dere at IP adressen, porten og applikasjonen som brukes er tillatt.

Det er det siste avsnittet ditt jeg er bekymret for, om dere har en uærlig ansatt eller noen greier å bryte seg inn på serverne hos dere så vil de kunne bruke denne SSH tunellen til å nå kundene dåkes.

Problemet er at denne tunellen er oppe 24/7, som øker faren for misbruk.

Så hvis dere blir rammet av en hacker som kommer seg inn å kryptere systemene hos dere (som dere mener er lite sannsynlig), så er det stor sannsynlighet for at de kan komme seg videre til kunden via denne ssh tunellen hvis den er aktiv.

Du skriver at dere har god sikkerhet, men jeg får ikke det inntrykket når jeg oppdager opplagte sikkerhetshull som dette.

For å redusere sannsynligheten så vil jeg anbefale alle som leser dette til å sette opp en task Scheduler til å starte og stoppe servicen «Visma Cloud Gateway», slik at den kun er aktiv når en trenger å bruke denne.

Takk for god info. Då har jeg fått svar på det jeg lurte på og vet hva vi må gjøre for å redusere risikoen.

Etter min mening så er fortsatt risikoen unødvendig stor.

[Terjes1]

Hvis SSH prosessen fjernes så stopper Visma Autopay å fungere.

Finnes det en annen måte å bruke Autopay uten at det må åpnes opp for SSH tunnel?

https://www.ssh.com/academy/ssh/tunneling-example