Sikkerhetsprogram

Et sikkerhetsprogram, sikkerhetstiltak, eller hva enn man vil kalle det, har som mål å håndtere risiko så den blir mindre.

For å klare dette er det flere nødvendige faser:

  1. Autoritet og ansvar – man må først bestemme hvilket ansvar programmet skal ha. I tillegg må det gis tillatelse til at programmet kan gjøre det det trenger å gjøre. Dette inkluderer da også ressursbruk.
  2. Rammeverk – med utgangspunkt i en samling av vedtatte generelle policyer, standarder og veiledninger (f.eks. ISO 27000) kan man bygge et forsvarlig sikkerhetsprogram som også lar seg forsvare overfor andre.
  3. Evaluering – man må vurdere hva som trenger beskyttelse. Dette innebærer risikoanalyse basert på identifiserte trusselvektorer. Her kan man ikke glemme at trusler ofte kommer innenfra. Til slutt bestemmer man hvilke utbedringer som er nødvendige og da må man ha de tre D-er i bakhodet.
  4. Planlegging – hvert initiativ over må gis en prioritet og tidslinje for implementering. Det er veldig viktig å fokusere på de svakeste leddene i kjeden først. Gapende sikkerhetshull må derfor tettes før man øker sikkerheten andre steder. Siden sikkerhet er en kostnadsdriver må man finne en passende balansegang.
  5. Utførelse – med utgangspunkt i det som er avdekket over utarbeider man sikkerhetspolicier, sikkerhetsstandarder, sikkerhetsprosedyrer og sikkerhetsguider som virksomhetens ansatte må følge. Dette inkluderer også handlingsplaner ved sikkerhetsavvik.
  6. Vedlikehold – dette blir mer et evigvarende trinn fordi man over tid må passe på at programmet følges. Derfor må man også gi oppfriskningskurs/opplæringskurs. Programmet må også fornyes hvis det skjer noe som endrer dets opprinnelige forutsetninger.

Omfanget til sikkerhetsprogrammet blir vanligvis så stort at man jobber iterativt og ikke etter fossefallsmetoden.

TBC

Informasjonssikkerhet: Før vs. nå

For bare noen tiår siden handlet det mest om enkle tekniske og fysiske barrierer, når virksomheter flest ønsket å sikre dataene sine og datasystemet. Idag har IT gjennomsyret hele samfunnet. Ansvarsområdet har derfor vokst såpass at det ikke lenger bare er datafolk i virksomheten som må bære byrden.

Den øvre ledelsen i virksomheten må aktivt ta stilling til behovet. Også må de finne noen som kan faget (se f.eks. ISO 27000) så man kan utarbeide sikkerhetsprogram som involverer alle avdelinger. Da får man noe som passer inn med hvordan virksomheten fungerer.

Hvis ting er gjort riktig vil viktig informasjon bare være tilgjengelig for de som trenger den, samtidig som den er helt utilgjengelig for alle andre. Dette krever at man har sikkerhet i alle ledd hvor det flyter informasjon. Har man stålkontroll over dette slipper man pinlige IT-blemmer som fører til tap av omdømme og muligens straff fra det offentlige i form av heftige bøter.

Proffer som jobber med dette må idag både holde seg oppdatert på sikkerhetsteknologi og attpåtil følge vedtatte lover som stiller minstekrav. I tillegg bør man følge beste praksis i bransjen hvis man ønsker å bli tatt seriøst.

ISO 27000

En mye brukt standardserie for informasjonssikkerhetsledelse er ISO 27000. Her gis man rammeverk for å utvikle et fullstendig sikkerhetsopplegg:

  • ISO 27001 handler om ledelse. Man skal etablere et system for informasjonssikkerhetsledelse (ISMS). Standarden tar for seg hva man har ansvar for. Som å definere objektiver og etterhvert måle oppfyllelse av disse. Man vil som regel begynne med en risikoanalyse for å finne ut hvilke sikkerhetskontroller som er passende (etter ISO 27002).
  • ISO 27002 tar for seg detaljerte informasjonssikkerhetskontroller og kan ses på som beste praksis. Hvor mange man trenger å implementere i egen virksomhet vil være avhengig av hva som avdekkes etter ISO 27001.
  • ISO 27003 gir tips og råd for hvordan man skal implementere ISMS-ledelseskontroller.
  • ISO 27004, ISO 27005 og ISO 27006 finnes også, men er mindre brukt.

TBC

Kodemønstre

Innenfor programvareutvikling, også kalt systemutvikling, støter man ofte på kjente problemer som det allerede finnes vedtatte gode løsninger for. Dette er mønstre.

Hovedsaklig er det designmønstre og arkitekturmønstre man forholder seg til.

For designmønstre finnes det tre kategorier: 1) Mønstre for hvordan noe skal opprettes, 2) hvordan noe skal struktureres og 3) hvordan noe skal oppføre seg.

Lærer man seg GRASP og SOLID er man godt i gang.

Manglende sudo

Ved nyinstallasjon av Debian må man kanskje installere sudo på egenhånd:

apt-get install sudo

Denne kommandoen kjøres som root.

Merverdianalyse

Inniblant må man gjøre merverdianalyse, f.eks. ved konserndannelse. Da finner man avvik fra balanseførte verdier ved at noe enten er mer eller mindre verdt, men man vurderer kun eiendeler og gjeld.

Merverdi kommer av at gjeld er lavere eller at en eiendel er mer verdt. Hvis det er motsatt blir det mindreverdi. Om man til slutt får netto merverdi betyr dette midlertidig forskjell og dermed utsatt skatt (se SØMF vs. SRMF) som må trekkes fra igjen fordi man ikke skal betale skatt senere på noe som brukes opp eller avskrives i nåtid. Er det derimot netto mindreverdi blir det SRMF.

Formel for å finne avvik, dvs. merverdi eller mindreverdi:

merverdi\;eller\;mindreverdi=virkelig\,verdi-balansef\o{}rt\;verdi

Alle avvik man finner settes inn i en oversikt sammen med egenkapitalen. Dette er for å beregne sum substanseverdi. Finner man ting som ikke er balanseført må dette også tas med hvis det er relevante opplysninger.

Et eksempel hvor et selskap kjøper aksjemajoritet og finner tre vanlige former for merverdier og en mindreverdi fordi en forpliktelse ikke var balanseført:

Egenkapital kan beregnes direkte ved å ta utgangspunkt i sum egenkapital i balansen, eller ved å beregne manuelt utifra aksjekapital, fond, avsatt utbytte, o.s.v., altså egenkapitalkontoer.

Så gjenstår det bare å finne goodwill:

Her er anskaffelseskost kjøpsprisen for eierandelen. Oppstår det direkte utgifter/kostnader p.g.a. kjøpet skal disse også inkluderes.

Formelen er enkel:

goodwill=anskaffelseskost-sum\,substansverdi

Kjøper kan i første omgang bare beregne goodwill for seg selv, med utgangspunkt i sin egen anskaffelseskost.

TBC

Tilknyttet selskap

Kjøper man såpass med eierandeler i et selskap at man får minst 20% av stemmene blir dette et tilknyttet selskap (rskl. § 1-4). Her er innflytelsen såpass høy at man kan påvirke driften.

Etter rskl. § 5-17 skal man i selskapsregnskap vurdere denne investeringen etter kostmetoden eller egenkapitalmetoden. I konsernregnskap er det kun egenkapitalmetoden som er tillatt.

For å få utøvende kontroll må man kjøpe og eller konspirere så mye at man i stedet danner et konsern.