Rush for å opprette iOS -apper kan etterlate bedriftsdata utsatt og sårbar

Mange IT -avdelinger er under intens press for å utvikle og implementere en rekke mobilitetsinitiativer. Disse initiativene spenner ofte over en rekke IT -disipliner. Det er forsøk på å utvikle interne apper, gi tilgang til nye og eldre systemer fra mobile enheter som iPhone og iPad, behovet for administrere og støtte brukerenheter som en del av BYOD-programmer, og behovet for å utvikle kundevendte løsninger som mobilorienterte nettsteder og native apper.

Med så mange press på IT -organisasjoner samtidig, blir det inngått kompromisser på grunn av stramme frister og budsjetter. Ifølge sikkerhetsekspert Jeff Williams kan det presset for å få løsninger ut så raskt som mulig resultere i løsninger som har store sikkerhetsfeil.

I et intervju med GovInfoSecurity, Fokuserer Williams diskusjonen rundt mobilapputvikling. Mange organisasjoner ser potensielle produktivitetsgevinster mobilappene kan tilby dem. I rush med å produsere disse appene, får mange av dem ikke den strenge sikkerhetstesten de trenger.

Selv om mobiladministrasjonsløsninger kan hjelpe til med å sikre enheter, bemerker Williams at selskapets interne apper kan være enkle vektorer for angrep hvis en enhet går tapt eller kompromitteres, og at enhetsadministrasjonsløsninger kan gi liten beskyttelse i slike saker..

De fleste mobilapper har en serverside og deretter flere forskjellige klienter, og klientene kan være HTML5, iPhone, Android, Blackberry eller hva som helst. La meg prøve å male et bilde for deg. Tenk deg en slags boble som strekker seg fra selskapets datasenter over en hel haug med nettverk -kanskje noen Wi-Fi og på tvers av langdistanse nettverk og så videre-og havner inne i mobilen enhet. Når du utvider virksomheten din og dataene dine gjennom denne boblen, er det nå din jobb å beskytte boblen.

Her er noen av måtene det er eksponering på. Når angriperen stjeler telefonen din eller får en ondsinnet app på enheten din, må du spørre deg selv om de på en eller annen måte kan komme inn i boblen. Du vil sørge for at dataene dine er beskyttet når de er på en enhet; du vil sørge for at dataene dine er beskyttet når de overføres mellom datasenteret og enheten; og så må du sørge for at selve søknaden din er herdet. Det må være robust kode.

Williams bemerker også at noen av sikkerhetsutfordringene egentlig ikke er nye problemer.

Dessverre ser vi mange av de samme typene feil som vi så i webapplikasjonskoden fra ti år tilbake. Mange organisasjoner er så opptatt av å kjempe med BYOD og MBM. Og de prøver å være de første til å markedsføre, så de håndterer uansett forretningspress... for å få appen sin til appen lagre veldig raskt, og de gir egentlig ikke utviklingen de ressursene de trenger for å bygge sikker kode for mobil.

Williams for å ta opp applikasjonssikkerhetsproblemer, tilbyr noen råd fra sunn fornuft, som å lagre så lite bedriftsdata på en iPhone eller iPad -appen på enheten som mulig og krypterer alle data på enheten (funksjonalitet som Apple tilbyr for å utvikle gjennom forskjellige iOS APIer).

Nå for applikasjonene dine, er det første at de virkelig bør minimere de sensitive dataene du vil la lagre på telefonen. Det er dataene som kommer til å forårsake eksponering. Det beste du kan gjøre er ikke å sette det på telefonen. Kanskje du kan beholde den i minnet eller beholde den i skyen, men ikke la den lagres på telefonen. Hvis du må lagre krypterte data, tror jeg organisasjoner bør gi utviklerne sine en kryptert beholder - en slags løsning som vil sørge for at alle dataene som lander på telefonen ender opp med kryptering, så selv om telefonen går seg vill, blir stjålet eller blir kompromittert, er dataene fortsatt beskyttet.

Han gjør også en sak for herding og overvåking av backend -servere som faktisk leverer innhold og data til selskapets mobilapper.

Selv om Williams ikke nevner det eksplisitt i intervjuet, som er vel verdt å lese i det helhet, er det viktig å huske på at interne iOS -apper ikke gjennomgår samme type inspeksjons- og godkjenningsprosess som Apple implementerer for apper som selges via iOS App Store. Det betyr at hvis utviklere gjør feil eller etterlater sårbarheter i koden, og apper ikke blir satt gjennom en grundig sikkerhetskontrollprosess kan det hende at et selskap ikke innser at det er en risiko før det også er det sent.

Kilde: GovInfoSecurity