Programvare Sikkerhet Krav

Share

|

I forbindelse med å identifisere beslektede sikkerhetsrisikoer kjent for et bestemt program eller et program sjanger, må utviklere vurdere krav til sikkerhet for anvendelsen. Denne analysen bør komme fram til en balansert måling av sikkerhetsnivået som kreves for et program. Det trenger ikke å tenke de mest ekstreme sikkerheten spekteret. Gitt forståelsen som sant og garantert sikkerhet er ikke-eksisterende, beskytter mot kjente risiko og minimere antall vellykkede angrep og deres effekter er generelt et akseptabelt sikkerhetsnivå. De som er involvert med utviklingen syklus av søknaden må bestemme sin egen "akseptabelt" sikkerhetsnivå, ved å undersøke den kjente risikoer, målene for programmet og metodene som brukes til å implementere ønsket sikkerhetsnivå.

Å komme frem til sikkerhetskrav, forvaltere og utviklere kan finne det nyttig å konsentrere seg om følgende, vanligvis kjent risiko områder:

· Bruker autentisering og tilgangskontroll

· Data lagring av konfidensiell informasjon

· Sikkerhet i eksterne nettverk kommunikasjon

· Sikkerhet av startpunkter for eksterne applikasjoner og operativsystem

Fra disse fire generelle områdene søknad designere og utviklere kan identifisere et minimalt sett med viktige funksjoner til å analysere. Avhengig av funksjonaliteten i programmet, noen risiko områder er mer relevante enn andre.

For å sikre eller ikke sikring

Tillegg av sikkerheten til et program påvirker et program på flere måter. Det umiddelbart blir mer kompleks, som kodebane tar en ny tur til å ta sikkerheten metoder. Utførelsen av et program kan være hindret, spesielt med tillegg av kryptering operasjoner. Disse operasjonene er CPU intensiv på grunn av den komplekse algoritmer involvert. Effektiviteten av en søknad kan også bli ofret hvis sikkerheten er brukt i områder hvor det gir noen fordeler. Dette kan skje hvis sikkerheten metoder blindt brukes på alle komponenter i et program uten tanke med hensyn til deres behov. Avsnittene nedenfor gir et rimelig utgangspunkt for å fastsette et grunnleggende nivå av krav til sikkerhet.

Tips

Det er en god praksis å vurdere sikkerheten for hver modul eller komponent i et program. Motstå trangen til å søke teppe sikkerhet metoder på tvers av flere moduler eller komponenter. I stedet bestemme den mest passende sikkerhetsnivå for hver.

Vurdere Authentication and Access Control Requirements

Brukergodkjenning er ofte håndteres av operativsystemet som programmet kjøres, men flere klasser på programmet trenger for å håndtere autentisering på egen hånd. Embedded programmer, programmer som fungerer uavhengig av operativsystemet, og distribueres webprogrammer ofte behov for å imøtekomme noen grad av brukerautentisering og tilgangskontroll. Vanlige eksempler på applikasjoner som krever disse sikkerhetsoppdateringene metodene er Internett-handel (e-handel) applikasjoner, hvor brukerne foreta kjøp via et webområde, eller kundedatabase tilgang. I begge tilfeller til muligheten for mange forskjellige brukere eller grupper av brukere bruker systemet krever strengere kontroll av tilgjengelige data. Programmene trenger metoder for å skille brukerne tilgang til systemene via en innlogging metode, de må også ha restriksjoner når det gjelder individuelle users'respective økonomiske data.

Å fastslå autentisering og tilgangskontroll krav, bør designere undersøke samspillet i programmet, og med den verden som omgir det. Dette omfatter metoder hvor brukerne får tilgang til program-sitter direkte på en terminal eller tilgang fra nettverket er to metoder som kan kreve annen godkjenning ordninger. Et program som er tilgjengelig bare når du sitter ved skrivebordet effektivt kan sikres via godkjenningsmetoder av operativsystemet som den går. Network programmer som er tilgjengelig for flere brukere samtidig, eller gjennom hvilke brukere tilgang til data fra felles databaser, gir sterk drivkraft for tilgangskontroll og autentisering. Nivået på detaljnivå og fleksibilitet for tilgangskontroll og autentisering evner som tilbys av operativsystemet på å avgjøre om proprietære metoder bør utvikles. Frittstående eller innebygde programmer er ofte utviklet fra bunnen og krever derfor egne spesialiserte metoder.

Krav til datalagring

Datalagring reflekterer metoden brukes til å lagre privat og sensitiv informasjon. Dette inkluderer riktig bruk av filen beskyttelse metoder av det underliggende operativsystemet (for eksempel re stricted filrettigheter) og sterkere metoder for å beskytte enkelte dataelementer (for eksempel kryptering). I mange tilfeller er bruk av operativsystemet tillatelse metoder tilstrekkelig til å gi den nødvendige grad av sikkerhet. Kryptering kan brukes til å beskytte ekstremt sensitive data som brukernavn legitimasjon og kredittkort informasjon.

Nivået som programmet trenger for å lagre data, og arten av at data stasjonen kravene til lagring av data sikkerhet. Oppbevaring av sensitiv informasjon er ofte gating faktor avgjøre om høy sikkerhet kryptering er nødvendig. Bruker legitimasjon, for eksempel passord, adresser, telefonnumre og økonomiske data, skal betraktes som sensitiv og også behandles med høy sikkerhet. Informasjonen kan ofte være sikret tilstrekkelig med standard fil tillatelse metoder.

Da danner det krav til lagring av data, kan designere bli fristet til å standardisere på ett nivå av sikkerhet. For eksempel, hvis et passord som er lagret i en konfigurasjonsfil sammen med andre ikke-sensitiv informasjon, fristelsen kan være sterk for å bruke kryptering på hele filen som et teppe sikkerhet metode. Å fastslå datalagring krav, undersøke behovene til alle komponenter som er involvert. I dette eksempelet kan bruke kryptering til nonsensitive data bli vurdert ineffektivt på grunn av beregningsorientert bekostning av kryptering operasjoner, samt mangel på detaljert kontroll av den andre informasjonen i filen. En enkelt element kan ikke nås lett hvis hele filen er kryptert. Kompleksiteten involvert for å få tilgang til andre elementer er da økt dramatisk.

Nettverk og Entry Point Security Requirements

Programmer kommunisere til brukerne, operativsystemet og andre programmer gjennom startpunkter. Disse kan være på samme maskin som programmet eller i et nettverk, ofte er de på begge. Metodene for å gi innfallsporten til søknaden og støtte for nettverk kommunikasjon er ofte en og samme, og derfor er de gruppert sammen her.

Sikkerhet på nett kommunikasjon er best løses ved å undersøke innholdet i meldingene som sendes. Programmer som bruker nettverket kommunikasjon for informasjonsformål meldinger eller passerer statiske data kanskje ikke forlange noe sterkere pålitelighet enn protokollen støtter. Igjen, som i tilfelle av Internett handel, et program som sender og mottar sensitiv brukerinformasjon sannsynlig garanterer tillegg av en høyere sikkerhet metode. Inngangspunktene også fastsette krav til sikkerhet for programmer som kommuniserer i et nettverksmiljø.

Oppføringen peker til et program krever en høy grad av analysen fordi de omfatter, og gi nettverket kommunikasjon. Andre også samhandle med programmet gjennom startpunkter. Disse funksjonelle områder kan beskyttes gjennom en kombinasjon av tilgjengelig operativsystem metoder og de definerte tilgangskontroll og autentisering ordninger som brukes i programmet. Analyse av interaksjoner som et program har med omverdenen lar designerne for å finne den mest egnede sikkerhetsnivå nødvendig. Disse interaksjoner og påfølgende inngangspunkter er kategorisert som

· Network interaksjon

· Interaksjon med andre programmer

· Samspill med sine respektive operativsystem

Disse kategoriene er velkjente funksjonelle områder, og designere sannsynligvis allerede vet om sin søknad samhandler i noen av disse manerer. Det neste trinnet er å vurdere hvert område sikkerhet.

Nettverk, Application, og System Interactions

Populariteten til Internett gir opphav til mange nye programmer som samhandler med andre komponenter innen lokale systemer og med eksterne systemer. Programmer som fungerer uavhengig av andre programmer og samhandle bare med seg selv åpenbart ikke krever nettverk risikoanalyse.

Nettverk interaksjon kan være tilstede på flere nivåer. Et program kan være helt klient / server-orientert, til bruk på eksterne systemer spredt over Internett. Behovet for sikkerhet i disse programmene blir vesentlig mer komplisert enn den er i frittstående applikasjoner.

Flere avhengigheter bør settes opp. Nivået som utviklerne ønsker å gi sikkerhetsmekanismer i søknaden bør vurderes. Designerne kan bestemme seg for ikke å gi noen interne sikkerhetsmekanismer. Sikkerheten i den nettverksbaserte programmet avhenger da av sikkerheten i nettverk som er i bruk og kommuniserer; nettverket Topol forstå informasjonsteknologi og brannmur finne høyeste sikkerhetsnivå som et program kan oppleve. Designeren kan velge å eschew avhengigheter og gi den høyeste grad av sikkerhet mulig innenfor programmet. Dette er de to ytterpunktene-de fleste programmer fall et sted i midten.

Søknader kan også bruke nettverket anlegg for lokaliserte kommunikasjon som ikke er skjebnebestemt til å gå utover rammen av systemet som er i bruk. Det bør vurderes av naturen er dette kommunikasjon for å fastslå om gjennomføringen skaper unødig risiko.

Behovet for samhandling mellom applikasjoner eller operativsystemet innebærer ikke et krav for nettverk kommunikasjon. Designere bør undersøke implementeringen metoder som gir ønsket funksjonalitet. Programmer bruker ofte stikkontakter-basert kommunikasjon metoder for å yte inngangspunkter fordi de er raskt og enkelt implementeres. Bruken av støpslene kan tilby mer funksjonalitet enn det som er nødvendig, men. Programmer som trenger å bare kommunisere med andre programmer på det lokale systemet, eller med sine egne operativsystemer har mange kommunikasjon metoder til rådighet, for eksempel Internet-stikkontakter, IPC mekanismer.

Commonly, UNIX-systemer bruker socket kommunikasjon på grunn av sin brukervennlighet og mengde dokumentasjon. UNIX støtter flere varianter av stikkontakter-basert kommunikasjon, to av dem er den populære IP socket-og UNIX-domene stikkontakter.

IP-kontakter, som navnet tilsier, bruker IP-protokollen for kommunikasjon, og støtte eksterne nettverket kommunikasjon, som gir lokale og eksterne prosesser å kommunisere med programmet. Mange programmer som kommuniserer bare med prosesser på et lokalt system og som ikke krever nettverk kommunikasjon evner bruke IP-sokler som et standard grensesnitt. IP stikkontakter er ikke ideelt i denne situasjonen fordi de automatisk gir tilgang til lokale og eksterne kunder.

Domene stikkontakter bruke en intern UNIX protokoll for kommunikasjon og ikke støtte nettverket kommunikasjon, de oppgir en forbindelsesorientert kommunikasjonskanal. Domene stikkontakter har sin andel av risiko hvis de brukes feil. UNIX domain sockets støtte bestått av filen beskrivelsene i tillegg til informative data. Dette betyr at pekere eller referanser til andre deler av systemet kan sendes fra ett program til et annet. Denne funksjonaliteten er bare tilgjengelig i UNIX domain sockets. Hvis denne funksjonen ikke er ønskelig eller rettferdiggjøres, avledning fra stikkontakter-basert kommunikasjon til en annen IPC mekanisme kan være et bedre valg.

Tatt i betraktning den type informasjon som sendes til og fra programmet bidrar til å definere kravene for sin kommunikasjon metode. Designere bør vurdere samspillet mulighetene i programmet før innlemme en standard funksjon. I dette eksemplet er programmet som bruker IP-sokler i faresonen fordi den tillater eksterne systemer for å koble til programmet når de ikke bør tillates. En bedre design dokumenterer behovet for samhandling med bare lokale programmer. Denne omfattende kravet fører utvikleren å bruke noe annet enn IP stikkontakter.

Operativsystem Interaksjon

Interaksjon med operativsystemet skaper ofte et annet nivå sikkerhetsspørsmål. Mange nivåer av interaksjon kan skje med et operativsystem-nettverket interaksjon, Inter-Process Commu nication og manipulering av filer er allerede nevnt. To andre typer interaksjon også krever oppmerksomhet: Henrettelsen av eksterne programmer og bruk av systemet og andre eksternt definerte samtaler er vanlige kilder til utnyttelse. Viktige spørsmål som tillatelser, autentisering, tilgangskontroll, og validering av inndata bør vurderes i sammenheng med operativsystemet interaksjoner.

System samtaler og eksterne applikasjoner presentere en høy grad av risiko når de brukes feil på grunn av deres natur. Disse funksjonene ofte finnes i bibliotekene som brukes av mange programmer samtidig, og som ofte gir direkte tilgang til operativsystemet komponenter og ressurser. Utnyttelsen av et enkelt program gjennom disse funksjonene kan påvirke flere programmer og systemet.

System samtaler gir tilgang til mange generelle og system-spesifikke funksjoner. De lar et program for å samhandle med spesifikk maskinvare komponenter samt kjerne-nivå funksjonalitet. Sikkerheten til operativsystemet og komponentene må vurderes ved bruk av systemkall. Hvis et program binder sammen bruker eller nettverk data med operativsystemet via systemet anrop, må designere minimalisere eksponering for farlige, uventede og upassende data.

Henrettelsen av eksterne applikasjoner er en annen vanlig, usikrede interaksjon. Utviklere ofte utforme et program for å påkalle andre programmer ved ulike metoder. Det er sev der flere grunner en utvikler vil kanskje gjøre dette, for eksempel å skille mellom funksjoner eller for å etablere miljøkontroll. Ringe andre programmer lar også utviklerne å bruke eksisterende funksjonalitet og å fremskynde programmets gjennomføring.

Det er en iboende fare i å ringe et annet program fra en program-eksterne programmet kan sjelden bli klarert. Programmet finnes i et dynamisk miljø hvor det er mulig å modifisere eller erstatte alle program. Problemet ligger i de metodene som brukes til å kalle programmet. UNIX-baserte systemer ofte støttefunksjoner kalt system () og exec (), som passerer den medfølgende parameterne som en streng til gjennomføring av standard UNIX shell og delprosess, henholdsvis. Systemet () kaller tilbake til å kalle programmet når du er ferdig, men exec () avslutter kjører programmet og erstatter den med det som kalles programmet. Windows-baserte systemer har exec ()-kallet som tillater kjøring av andre programmer. I motsetning til UNIX, Windows-versjonen av exec () kjører de angitte programmet i en delprosess, og kaller funksjonen ikke si ikke. Uten validering av inndata, kan angriperne satte skall meta-tegn i input stream, tvinge skall kjøre muligens skadelige kommandoer og parametere. Bruken av disse funksjonene er generelt mislikt, og innsatsen bør gjøres for å unngå bruken av dem fordi de tillater utførelse av uklarerte og ukontrollert programmer. Alternativt kan designere innarbeide nødvendige funksjonaliteten direkte i et program. Bruk av fritt tilgjengelig, åpen kildekode-programvare synker sterkt innsatsen som trengs for å gjøre det.

Mange operativsystemer også tillate funksjonaliteten til å kjøre på ulike nivåer privilegium. UNIX har sitt "root" privilegier, har Windows "Administrator" og "SYSTEM" privilegier. Disse spesielle kontoer kan utføre administrative oppgaver og har mer interaksjon med operativsystemet og dets tjenester enn andre kontoer gjør. Programmer kan skrives å heve privilegium nivåer når spesialisert funksjonalitet er nødvendig. Et program og operativsystem som er i bruk kan være kompromittert hvis rettigheter ikke er nøye kontrollert.

Modellen av minst privilegiet tyder på at et program skal kjøre med minimum sett med rettigheter som trengs for å utføre de fleste funksjoner. Funksjonalitet som krever høyere privilegier bør bli isolert i sin egen modul, men det er definert-som en prosess, en klasse, et program, eller til og med et annet system. Selv da sett at funksjonalitet skal også kjøre på minst privilegerte nivået til de utvidede rettigheter er nødvendige. På den tiden skulle høyere privilegier oppnås, og ved ferdigstillelse av funksjonaliteten, bør privilegier bli returnert til minimumsnivå.

Obs!

Meta-tegn er tegn som tar på spesiell betydning i en gitt kontekst. For eksempel innenfor standard UNIX shell, the semikolon (;) er en kommando separator, som kan mange kommandoer bli satt på en enkelt linje når et semikolon er mellom dem. Røret (|) tegnet sender terminalen utgang til hva følger røret, slik at output fra et program som skal mates inn i en annen.

Konklusjon

Noen programutviklere velger å glemme eller ignorere sikkerheten i sine programmer og sette seg på nåde av kundens nettverk eller operativsystem og sikkerhetsfunksjoner. Bruk av dette teppet sikkerhet modellen skyr ansvaret for å gi sikre programmer til offentligheten. Sikkerheten filosofi utgir seg for en sterk og omfattende sikkerhet ideologi som påtar seg ikke noe om sikkerheten til eksterne komponenter til programmet. En søknad bør alltid være så sikker som mulig med hensyn til seg selv og de eksterne komponentene som den kommuniserer. Nivået på utviklingsområder er overlatt til skjønn designeren eller utvikleren, men

---