Hovedprosjekt i data/informasjonsteknologi 2017 ved Høgskolen i Oslo og Akershus. Forprosjektrapport

Transkript

1 Hovedprosjekt i data/informasjonsteknologi 2017 ved Høgskolen i Oslo og Akershus Forprosjektrapport Hendelsesapp for operatører av industrielle kontrollsystemer GRUPPE 27: Even Nerheim (s199184) Sigrid Riiser Kristiansen (s181090) Amir Yaakoubd (s236367)

2 Innholdsfortegnelse 1 Presentasjon 2 Sammendrag 3 Dagens situasjon 4 Mål og rammebetingelser 4.1 Mål 4.2 Funksjonalitetskrav 4.3 Teknologier 4.4 Utfordringer 5 Løsninger/Alternativer 6 Analyse av virkninger 7 Risikoanalyse

3 1 Presentasjon Oppdragsgiver: Prosjekttittel: Oppgave: NC-Spectrum Hendelsesapp for operatører av industrielle kontrollsystemer Gruppen skal lage en mobil applikasjon som sender brukeren push-varsler når en trussel mot NC-Spectrums datasikkerhet er oppdaget av deres IDS-er. Brukeren skal også kunne se en logg av hendelsene og se mer informasjon om hver individuell hendelse. Periode: Gruppenummer: 27 Gruppemedlemmer: Veileder: Amir Yaakoubd (s236367) Even Nerheim (s199184) Sigrid Riiser Kristiansen (s181090) Terje Gjøsæter Nettside:

4 1.1 Gruppe Prosjektgruppen består av Amir Yaakoubd, Even Nerheim og Sigrid Riiser Kristiansen. Samtlige er studenter på bachelorstudiet Dataingeniør ved Høgskolen i Oslo og Akershus. Alle har tatt Datasikkerhet og Menneske-Maskin Interaksjon som valgfag i høsten Nå tar Even og Amir Effektiv kode med C og C Oppdragsgiver Hovedprosjektet skal utføres i samarbeid med NC-Spectrum. NC-Spectrum AS er et norsk selskap med hovedkontor i Kviteseid. De bistår kundene deres med etablering, rådgivning, drift og tjenester innen nettverk og informasjonssikkerhet i digital infrastruktur. NC-Spectrum har kunder i hele Norge, men utfører det meste av arbeidet fra operasjonssentralen deres for nettverk og sikkerhet (NOC og SOC) i Kviteseid. De tilbyr beredskap 24/7/365. Nettside: Kontaktpersoner Veileder HIOA: Terje Gjøsæter Tlf (Mobil): terjegj@gmail.com Bacheloransvarlig: Silje Aakre Tlf (Kontor): silje.aakre@nc-spectrum.no 1.4 Oppgave I forbindelse med et innovasjonsprosjekt ønsker NC-Spectrum å utvikle et sikkerhetssystem for kritisk infrastruktur ved navn "Syn". I norrøn mytologi var Syn gudinnen som bevoktet dører og sørget for at uvedkommende ikke kom inn. Syn skal ved hjelp av en rekke sensorer hos kunden, inkludert intrusion detection systems (IDS) og annen sikkerhetsteknologi, detektere mulige uønskede hendelser som angrep og feilkonfigurering. NC-Spectrum ønsker at både NC-Spectrums sikkerhetsoperasjonssentral og operatøren hos kunden skal få umiddelbar alarm dersom en hendelse inntreffer. De ønsker at en gruppe studenter designer og utvikler en mobil-app hvor operatøren ute i den kritiske infrastrukturen får varsler og kan merke dem som for eksempel "vanlig

5 oppførsel", "forårsaket av endring", "mistenkt dataangrep", etc. Appen må oppfylle visse sikkerhetsmessige forutsetninger. I tillegg skal appen formidle «svaret» til NC-Spectrums konsulenter slik at hendelsen håndteres etter behov. 2. Sammendrag Vi skal under våren 2017 utvikle et varselsprogram i form av en mobilapplikasjon, i samarbeid med NC-Spectrum. Mobilapplikasjonen skal være brukervennlig og nyttig for NC-Spectrum og deres kunder for å bli varslet når mistenkelig oppførsel er oppdaget av bedriftens systemer. Vi diskuterte med NC-Spectrum på deres kontor i Kviteseid funksjonalitetene som applikasjonen måtte og kunne hatt i form av en idédugnad. Vår veileder fra HIOA vil være Terje Gjøseter. Vår kontaktperson hos NC-Spectrum i Kviteseid er Silje Aakre som er bacheloransvarlig og siviløkonom. Vi utvikler applikasjonen gjennom Android Studios og velger de teknologier og løsninger vi ønsker å jobbe med. Teknologier vi har planlagt å bruke foreløpig er hovedsakelig Java, XML og SQL. Andre verktøy som vi kommer til å bruke er Photoshop for front-end elementer, GitHub for deling av oppgaven mellom medlemmene, Trello for planlegging og Google Drive for redigering av rapporten. 3. Dagens situasjon NC-Spectrum sender pr. dags dato SMS med varsler, men dette er ikke automatisk og oppleves som en ineffektiv og lite god løsning. Oppgaven er basert på behovet for en bedre tjeneste. En mobilapplikasjon vil både kunne fylle flere funksjoner og gi mer utfyllende informasjon om hendelser, i tillegg til å gjøre tjenesten sikrere. Den vil også kunne varsle automatisk, noe dagens tjeneste ikke gjør. 4 Mål og rammebetingelser 4.1 Mål Hovedmålet med arbeidet vårt er å tilby NC-Spectrum en god mobilapplikasjon som skal sende push-varsler når mistenkelig oppførsel er oppdaget i bedriftens systemer. Applikasjonen skal gjøre det mulig for NC-Spectrum og deres kunder til å se en logg om de relevante trusselhendelsene med tilsvarende informasjon.

6 4.2 Funksjonalitetskrav Disse kravene ble avtalt mellom NC-Spectrum og gruppen. - Applikasjonen skal være tilpasset for Android systemer. - Applikasjonen skal ha en innloggingsmekanisme hvor telefonnummeret til brukeren er brukt som ID og passordet skal hashes for å sikre seg mot ulovlig innbrudd på en brukers konto. - Brukeren skal kunne se kun relevant info om sin bedrift eller sitt område (f.eks: bruker i Bø skal kun ha tilgang til informasjon om mistenkelige hendelser i Bø-området). NC-Spectrum skal ha en admin profil hvor de kan hente informasjon om alle hendelser. - Hendelsene skal hentes fra en MySQL database hvor NC-Spectrum sine IDS-er (som oppdager mistenkelig oppførsel) overfører sine hendelser. - Brukeren skal kunne se en logg i en form av en tabell med informasjon om hendelsens risikonivå (høy, middels eller lav), navn/type hendelse, dato og tid. - Mer info om hendelsene skal bli tilgjengelig (som source IP, destination IP, tekst som forklarer mer om hendelsen) når man trykker på en av kolonnene i tabellen. - En mulighet for å sortere tabellen ved hjelp av en filter knapp hvor brukeren kan velge om å kun se høy-, middels- eller lav-risiko hendelser ville vært anbefalt. - En innstillinger knapp som fører brukeren til et nytt vindu eller en fane hvor han/hun kan velge hvilket risikonivå han/hun ønsker å få push varsler for ( høy er standard) hadde også vært satt pris på. Brukeren burde også kunne logge seg ut her. 4.3 Teknologier For koding av applikasjonen tenkte vi å bruke XML og Java ved hjelp av Android Studios som plattform. Vi tenker å benytte GitHub gjennom Android Studios for å kunne synkronisere arbeidet vårt. Photoshop kan brukes til tegning av ikoner som kan brukes for å forbedre estetikken og brukervennlighet. Sql skal brukes for opphenting av hendelses info som ligger i en MySQL database. For organisering, kommunisering mellom studentene og redigering av rapport tenker vi å bruke Google Drive og Trello. For kommunisering med NC-Spectrum ville konferanse video-samtaler via WebEx vært benyttet. 4.4 Utfordringer

7 De eventuelle store utfordringene gjennom prosjektet som vi allerede ser for oss ville vært: - Koding av mobilapplikasjonen siden ingen av oss har hatt tidligere erfaring med å programmere mobilapplikasjoner. Så, forståelse av koden som skal til for å programmere i Android vil nok være tidkrevende. - Overføring av data fra MySQL databasen til mobilapplikasjonen på en kontinuerlig måte. 5. Løsninger/alternativer Vår oppgave er å utvikle en mobilapplikasjon; for å gjøre dette har vi besluttet å anvende Android-plattformen Android Studio. Dette er et gratis program brukt i Apputvikling-faget på HiOA og et godt anbefalt verktøy for å utvikle app-er. AS kan også synkroniseres opp mot GitHub. Android Studio bruker i hovedsak Java som kodespråk, som vi skal sette opp mot å kommunisere med en SQL-database med SQL kommandoer i tillegg. NC-Spectrum skal dele med oss en MySQL database hvor informasjon om noen oppdagede hendelser av IDSene deres skal dumpes. Android Studio kan dessverre ikke brukes til å utvikle app til IOS, kun til Android. Koden kan overføres til en annen utviklingsplattform, men det er ikke den vi har valgt å bruke. Det finnes andre app-utviklingsplattformer for Android, men vi har ingen kjennskap foreløpig til andre enn Android Studio. GitHub er en nettside viden kjent og brukt av kodere til å vise frem sitt arbeid og for lagring av prosjektene sine. Den sikrer at uønskede endringer ikke skjer med dine dokumenter ved at du selv må godkjenne endringer på dem. Her ønsker vi å lagre koden vi bruker i dette prosjektet, så det ikke blir kluss og så alle kan jobbe med den samme versjonen av koden. Photoshop er et fotoredigeringsprogram og vil kun bli anvendt til å lage app-ikonet og eventuelle ikoner nødvendig i app-en, i tillegg til profesjonelle skisser av produktet. Ulempen med Photoshop er at programmet i seg selv ikke er gratis, men vi har mulighet til å bruke en prøveversjon i en begrenset periode. Trello er en nettside for å holde orden på nødvendige gjøremål og punkter. Her legger man inn lister med oppgaver som skal fullføres i bokser som minner om post-it-lapper. Dette vil fungere bra ettersom nettsiden er laget nettopp for å holde struktur på gjøremål, selv om post-it-lapper på en vegg også kan ha samme effekt. Eneste synlige ulempen med denne

8 nettsiden er at ingen i gruppa har tidligere erfaring med den, så det å bruke Trello vil være noe uvant. Google Drive er en skylagringstjeneste utviklet av Google hvor vi kan lagre og samskrive på dokumenter uten at det krasjer. Endringer blir lagret automatisk fortløpende, som gjør Google Drive til en bedre løsning for parallell skriving på dokumentasjon enn f.eks. GitHub, hvor endringer må godkjennes av eieren av dokumentet før endringer blir satt inn. Vi planlegger å bruke WebEx til å ha videokonferanser med NC-Spectrum gjennom utviklingen for å holde kommunikasjonen oppe og forsikre oss om at vi er på rett spor om hva klienten ønsker. Alternativt kan vi bruke Skype eller bare , selv om vil bli tregere kommunikasjon enn å ha live-video. 6. Analyse av virkninger Ved å velge Android Studio har vi besluttet at applikasjonen som vi utvikler kun vil være tilgjengelig på android-telefoner. Dette vil ekskludere en stor del av telefonmarkedet som ikke er android-kjørt (hovedsakelig Apple-produkter) og kan like lett ekskludere ansatte hos NC-Spectrum som ellers hadde ønsket å bruke appen. Men Android Studio er et verktøy anbefalt for dem som ikke har all verdens bakgrunn med apputvikling, så det vil hjelpe oss stort. Android Studio har en innebygget simulator som viser hvordan appen vil fungere på en simulert telefon, så vi kan se hvor godt det har passet til forskjellige modeller og størrelser på telefoner. I tillegg er det hyppig brukt av andre, så det er ikke vanskelig å finne råd på nettet hvor noen bruker Android Studio som plattform selv. Ved å velge GitHub til oppbevaring av koden og Google Drive til holding av dokumentasjonen blir vi nødt til å forholde oss til to forskjellige steder for å hente vår egen fremgang i prosjektet, noe som kan bli noe irriterende over tid, men som tidligere nevnt vil GitHub holde koden til appen mer sikker for medlemmene enn på Google Drive når det kommer til øyeblikkelige endringer. Google Drive vil gi bedre flyt når det kommer til endringer i rapporter og dokumentasjon siden flere medlemmer, eller alle, kan redigere det samme dokumentet uten at det kommer opp noen store problemer eller krasj. Å ha en lokal MySQL database blir nyttig for testing av selve applikasjonen. Tidligere erfaring med SQL databaser gjør dette til en idéel løsning for oss. Ved å velge Photoshop, som noen i gruppa allerede har erfaring med, sparer vi tid vi ellers hadde brukt på å lære et annet, lignende fotoprogram. I tillegg er Photoshop et av de mest brukte verktøyene i design av modeller og logoer fordi det er blant de aller beste programmene til den jobben. Dette vil sikre at logoen til appen blir pen og representerer appen på en verdig måte.

9 7. Risikoanalyse Risiko Sannsynlighet Konsekvens Forebygging/løsning Sykdom Lav/Middels Lav/Middels/Høy Det er lav sannsynlighet for en alvorlig sykdom skulle ramme gruppa, men siden det er våren er det en sjanse for forkjølelse/influensa. Forebygging vil være å fordele oppgavene sine på en effektiv måte slik at en slik hendelse ikke skulle hatt alvorlige konsekvenser. Tap av data Lav Høy Vi bruker GitHub for å lagre felles versjon av koden, og dokumentene lagres på Google Drive. I tillegg har alle sine egne versjoner på sin egen data. Feilslått planlegging Lav/Middels Middels/Høy Vi må jobbe for å holde oss til den fastsatte planen, og i bestefall ta den igjen. Bugs Middels Middels Ved å prøve ut koden underveis og bruke støttesider på nettet hvor andre

10 legger ut løsninger på lignende problemer de har hatt. Kontakt med veileder og NC-Spectrums programmere for hjelp er også tilgjengelig. Manglende kunnskap om språk Høy Middels For å overkomme denne utfordringen har vi besluttet å lese oss opp på flere av disse kodespråkene på egen fritid. Risikoene er satt opp etter hvor store konsekvenser de vil ha og hvor sannsynlig det er at de vil inntreffe. Lav risiko sier at det ikke er veldig sannsynlig at det vil skje, men det kan oppstå. Og at dette vil være svært overkommelig. Middels sier at det er noe sannsynlig det vil skje, og konsekvensene kan godt overkommes med arbeid. Høy, derimot, sier at det vil mest sannsylig skje, og at konsekvensene er svært alvorlige for prosjektet. Sykdom er en risiko i alle prosjekter. Dette prosjektet tar sted på vinteren/våren, som er stor sesong for forkjølelse og influensa. En vanlig forkjølelse vil ikke være noe spesielt stort hinder, men en hard sykdom kan risikere å ta et eller flere gruppemedlemmer ut over lenger tid; dette kan skape fatale konsekvenser for hele prosjektet og utviklingen. Alle gruppemedlemmene har derfor blitt anbefalt å holde seg varme og være på utkikk etter tidlige symptomer på noen form for sykdommer. I tillegg har vi lagt inn noe pusterom i prosjektet, så gruppa ikke skal føle seg overveldet eller overstresset av prosjektet. Tap av data vil ha en fatal konsekvens for prosjektet, om det skulle hende med alle gruppemedlemmene. Ingen i gruppa er i stand til å huske koden eller rapporten ned til hvert enkelt ord, så et slikt tap vil sette en stor stopper for hele prosjektet. Vi bruker derfor både GitHub og Google Drive til å oppbevare dokumenter og kode, men hver for seg. I tillegg har hvert medlem sin egen kopi av dokumentene og koden, så hvis en av tjenestene skulle gå ned så har vi fremdeles det vi trenger for å fortsette. Feilslått planlegging er noe som ofte kan skje uten at man merker det, så vi har satt opp milepæler vi mener er overkommelige. Vi retter oss mot å levere et fullstendig prosjekt, så det er viktig at alle mål blir overholdt. Om det skulle skje at vi faller bak skjema må vi vie mer tid til prosjektet enn først antatt. Men det vil være vesentlig forskjell på å falle bak

11 skjema tidlig i prosessen (hvor det kan innhentes), og å falle bak når det begynner å nærme seg fristen. Derfor er konsekvensnivået her varierende. Bugs er noe enhver utvikler vil støte på en eller annen gang. Siden prosjektet vårt ikke bruker teknologi eller teknikker ukjent for de aller fleste så vil mange av problemene vi støter på allerede ha blitt løst av andre på nettet som har postet sine resultater for andre å se. Om vi skulle støte på en bug som vi selv ikke vet hvordan å takle, og internettet ikke er til hjelp, vil vi henvende oss til Apputviklingslæreren på HiOA om råd. ellers må vi finne en ny løsning, så det er viktig å holde alle datoer satt på planen. Manglende kunnskap om språk er noe som ofte kan skje når man skal jobbe med flere forskjellige typer kodespråk i et prosjekt. Siden ingen i gruppa har studert Apputvikling tidligere, så er denne risikoen til stede ved koding av appen og samarbeidet mellom appen og databasen vi skal hente informasjon fra. Her vil igjen en løsning være å enten konsultere med internettet og hva andre har lagt ut der, eller å ha samtaler med lærere innenfor disse kodespråkene på HiOA.