Sikker programmering

Sikker programmering er en softwareudviklingsteknik  , der forhindrer utilsigtet introduktion af sårbarheder og giver modstand mod malware og uautoriseret adgang . Bugs og logiske fejl er hovedårsagen til softwaresårbarheder.

Sikker software er software udviklet ved hjælp af en række foranstaltninger, der sigter mod at forhindre fremkomsten og elimineringen af ​​programmers sårbarheder [1] .

Opgaven med sikker programmering er at beskytte brugerdata mod tyveri og beskadigelse, for at bevare kontrollen over systemet. Et usikkert program er et potentielt mål for en hacker, der kan bruge eksisterende sårbarheder til at se, ændre eller slette eksisterende information, påvirke driften af ​​programmer og tjenester (start eller stop) og injicere ondsindet kode i systemet [2] .

Terminologi

I engelsk litteratur er der to udtryk, der kan oversættes til sikker programmering.

Defensiv programmering er et softwareudviklingsprincip, hvor udviklere forsøger at tage højde for alle mulige fejl og fejl, isolere dem så meget som muligt og om muligt genoprette programmets ydeevne i tilfælde af funktionsfejl. Dette skulle gøre softwaren mere stabil og mindre sårbar. For eksempel er en hardwareimplementering af dette princip en watchdog-timer , checksum -beregning  - for at opdage fejl i pakkedatatransmission [3] .

Sikker kodning er en teknik til at skrive programmer , der er modstandsdygtige over for angreb fra malware og ubudne gæster. Sikker programmering hjælper med at beskytte brugerdata mod tyveri eller korruption. Derudover kan et usikkert program give en angriber adgang til at kontrollere brugerens server eller computer; Konsekvenserne kan variere fra denial of service til en enkelt bruger til kompromittering af følsomme oplysninger, tab af service eller skade på tusindvis af brugeres systemer [2] .

Vigtigt

Spørgsmålene om at sikre systemets sikkerhed og funktion er en integreret del af dets designfase ( systemdesign) [4] . Sikkerhedskrav til specifikke it- produkter og -systemer fastlægges på baggrund af eksisterende og forudsagte sikkerhedstrusler, den sikkerhedspolitik , der føres , og også under hensyntagen til betingelserne for deres anvendelse [5] . Implementering af sikkerhedsløsninger efter et system er blevet udviklet er komplekst og dyrt. Derfor bør der tages hensyn til sikkerhedskrav fra begyndelsen gennem hele systemets livscyklus [4] .

Informationssystemet er opdelt i fysiske og logiske niveauer. At forstå, hvad der præcist skal beskyttes mod eksterne faktorer, hjælper med det mest effektive valg og anvendelse af beskyttelsesforanstaltninger. En klar grænse mellem niveauer bør fastlægges af den sikkerhedspolitik, der regulerer et bestemt sæt informations- og informationsteknologier, der har fysiske grænser. En yderligere komplikation er, at den samme computer eller server kan være vært for både offentlige og private oplysninger. Som et resultat kan flere sikkerhedspolitikker anvendes på den samme maskine eller inden for det samme system. Når der udvikles et informationssystem, bør sikkerhedsgrænser derfor tages i betragtning og beskrives i den relevante dokumentation og systemsikkerhedspolitikker [4] . Dets udviklere skal være i stand til at sikre systemets sikkerhed, når de designer , udvikler , administrerer og konfigurerer , integrerer, korrekt test [6] .

Analyse (manuel eller automatisk) og sikkerhed er en dyr procedure, der øger de samlede omkostninger ved et softwareprodukt . Tidligere var fuldstændig eliminering af risici et fælles mål for sikkerhed. I dag er det anerkendt, at det ikke er omkostningseffektivt at eliminere alle risici. For hvert foreslået kontrolsystem bør der udføres en cost-benefit-analyse. I nogle tilfælde retfærdiggør fordelene ved et mere sikkert system muligvis ikke de direkte og indirekte omkostninger. Fordelene omfatter ikke kun forebyggelse af monetære tab; Det er værd at overveje, for eksempel omdømmetab. Direkte omkostninger omfatter omkostningerne ved at anskaffe og installere denne teknologi; indirekte omkostninger omfatter reduceret systemydelse og yderligere medarbejderuddannelse [7] .

Principper

I øjeblikket er der forskellige teknologier til udvikling af sikker software . Men der er et sæt principper, der tages i betragtning i enhver tilgang [8] :

De sidste fire kvaliteter er blevet grundlaget for Trustworthy computing (TwC) ( Eng.  Trustworthy computing ) ("Computations that are trustworthy") - initiativer fra Microsoft Corporation , hvis hovedopgave er at henlede udviklernes opmærksomhed på vigtigheden af at sikre disse krav på hvert trin af softwareudviklingen [9] .

Der er mange softwaresikkerhedsprincipper, hvoraf de fleste ligner hinanden. Deres generalisering kan betragtes som ovenstående principper [10] .

Klassificering og typer af sårbarheder

Klassifikatorer

Brugen af ​​standardiserede sårbarhedsbeskrivelser forenkler arbejdet for informationssikkerhedsspecialister. I øjeblikket er der flere populære klassifikatorer [11] :

Moderne kodeanalysatorer og automatiserede auditører kan udnytte lignende sårbarhedsbaser. Dette øger tilliden til produktet og kan også være vigtigt, når der rapporteres om sårbarheder i softwareproduktet [13] .

Der er også andre klassifikatorer. Når man arbejder med dem, bør man være opmærksom på forfatterne, da hvert klassifikationssystem skal oprettes af eksperter på dette område [14] .

Metrics

Hvert program er et potentielt mål for angribere. Efter at have fundet sårbarheder i applikationer eller tjenester, vil de forsøge at bruge dem til at stjæle fortrolige oplysninger, korrupte data, kontrollere computersystemer og netværk [15] . Til at beskrive egenskaberne ved en sårbarhed bruger eksperter CVSS- sårbarhedsrisikoscoringssystemet . Det er en skala, der tager udgangspunkt i, hvilke karakterer der gives. Metric-systemet er designet til at prioritere udbedring af sårbarheder. Hver skala refererer til en specifik semantisk sektion, som kaldes en metrik. Der er tre sådanne metrics [16] [17] [11] :

De sidste to metrikker er af hjælpekarakter og bruges kun til at justere indikatorerne for den grundlæggende metriske under hensyntagen til forskellige detaljer [18] .

Typer af sårbarheder

Liste over almindelige fejl, der kompromitterer sikkerheden i moderne programmer [19] :

Det er umuligt at liste alle kendte sårbarheder , da nye dukker op hver dag. Denne liste indeholder almindelige sårbarheder, som er nemme at begå, men hvis konsekvenser kan være katastrofale. For eksempel var spredningen af ​​Blaster-ormen forårsaget af en fejl i kun to linjer kode [22] .

Forsvar

Den korrekte strategi til at beskytte mod fejl og sårbarheder er at forhindre og forhindre dem. Dette kræver, at udvikleren konstant kontrollerer inputdataene. For eksempel er den bedste måde at beskytte mod bufferoverløbsangreb på at sikre, at inputdataene ikke overstiger størrelsen på bufferen, hvori de er gemt. Data beregnet til at blive sendt til databasen kræver validering for at beskytte mod et angreb såsom SQL-injektion. Hvis data sendes til en webside, skal de valideres mod XSS . Et for stort antal kontroller komplicerer imidlertid udviklingen af ​​programmets kildekode og kan igen føre til, at der opstår nye fejl, så denne strategi bør kombineres med andre [23] .

Fejlbeskyttelsesmekanismer kan leveres af compileren eller operativsystemet . GCC-kompileren gør det muligt at bruge funktionen _builtin_object_size () til at få størrelsen på et objekt ved hjælp af en pointer til dette objekt, så brugen af ​​det gør kopieringsproceduren mere sikker. MSVC tillader , når du bruger /RTCs -flaget, kompileringstidskontrol for lokale variabeloverløb, brug af uinitialiserede variabler, stak-pointer-korruption forårsaget af uoverensstemmende opkaldskonventioner. Brugen af ​​CRED (C range error detector) teknologi og specielle indsatser foran den beskyttede sektion af stakken ( StackGuard , SSP ) tillader delvist at detektere og forhindre angreb forbundet med array overflow og stakødelæggelse [24] .

Operativsystemet kan også styre programmets udførelse. Denne strategi kan være nyttig, hvis kildekoden til dette program er ukendt. ASLR (Address Space Schema Randomization) er en sikkerhedsfunktion i operativsystemet designet til at forhindre vilkårlig kode i at køre. ASLR er i øjeblikket understøttet på både Linux og Windows . Forøgelse af sikkerhedsniveauet opnås ved at bruge ikke-eksekverbare stakteknologier: W^X, PaX [24] .

Typiske angreb på webtjenester er SQL-injektion, XSS, CSRF , clickjacking . Moderne rammer hjælper udviklere med at skabe sikre webapplikationer. Brug af færdige løsninger giver dig mulighed for ikke at håndtere adskillige kontroller af indgående data: fra HTTP - anmodningsheadere til deres indhold. Det giver også en mere sikker metode til at arbejde med databasen  - ORM [25] [26] .

Skader

Oplysninger om sårbarheder kan bruges af angribere til at skrive virus . For eksempel udnyttede en af ​​de første kendte netværksorme ( Morris-virussen ) i 1988 sårbarheder såsom et bufferoverløb i Unix -fingerdæmonen til at sprede sig mellem maskiner. Så var antallet af inficerede biler omkring 6 tusinde [27] , og de økonomiske skader varierede ifølge US Accounts Chamber fra 10 til 100 millioner dollars [28] .

I 2016 forårsagede computervirus 450 milliarder dollars i skade på den globale økonomi [29] [30] .

I 2017 blev skaden fra WannaCry -virussen anslået til 1 mia. Infektioner er blevet rapporteret i mindst 150 lande [31] [32] [33] . Virussen brugte EternalBlue til at udnytte en bufferoverløbssårbarhed i SMB -protokollen [34] [35] [36] [37] .

Noter

  1. ↑ GOST R 56939-2016, 2016 , Begreber og definitioner, s. 2.
  2. ↑ 1 2 Introduktion til Secure Coding Guide .
  3. ↑ Defensiv programmering .
  4. ↑ 1 2 3 Engineering Principles for Information Technology Security, 2004 , Security Foundations.Princip 2, pp. 7.
  5. ↑ Information Technology Security Assessment Criteria, 2002 , Generelle bestemmelser, s. III-IV.
  6. ↑ Engineering Principles for Information Technology Security, 2004 , Security Foundations, s. 6-8.
  7. ↑ Engineering Principles for Information Technology Security, 2004 , Security Foundations. Princip 5, s. otte.
  8. ↑ Moderne teknologier til udvikling af pålidelige og sikre programmer, 2008 , s. 25-26.
  9. ↑ Moderne teknologier til udvikling af pålidelige og sikre programmer, 2008 , s. 26.
  10. ↑ Sikker programmering HOWTO - Oprettelse af sikker software, 2015 , Sikkerhedsprincipper, s. 7-8.
  11. ↑ 1 2 Hacker magazine: We measure vulnerabilities, 2009 , s. 48-51.
  12. ↑ OSVDB: FIN, 2016 .
  13. ↑ Hacker Magazine: Measuring Vulnerabilities, 2009 , Using Classifiers in Scanners, s. 51: “Moderne automatiserede revisorer er normalt skræddersyet til en specifik videnbase. For det første er det prestigefyldt, og for det andet er det nyttigt. For eksempel ved forberedelse til certificering i henhold til en af ​​de moderne standarder (NERC-CIP, PCI , FISMA, GLBA eller HIPAA), får administratoren mulighed for at modtage en skabelonrapport, der svarer til dokumentet udstedt af revisor.
  14. ↑ Hacker Magazine: Measuring Vulnerabilities, 2009 , udvalgte klassifikationer, s. 51: "Nogle gange kan du se absolut selvfremstillede klassifikationer på nettet ... Naturligvis har et sådant system ikke meget vægt, fordi det bør kompileres af rigtige eksperter, der forstår essensen af ​​problemet."
  15. ↑ Introduktion til Secure Coding Guide , et øjeblik.
  16. ↑ Common Vulnerability Scoring System, 2006 , s.86.
  17. ↑ CVSS: Specifikation .
  18. ↑ CVSS:Specifikation , 1.2. Bedømmelse: "Basismetrikken kan forfines ved at beregne tidsmæssige og kontekstuelle metrikker for bedre at afspejle risikoen for brugeren forårsaget af sårbarheden."
  19. ↑ 24 Deadly Sins of Software Security: Programmeringsfejl og hvordan man løser dem, 2009 , Introduktion.
  20. ↑ Søgemetode for formatstrengssårbarhed, 2015 , Introduktion: "Selv i 90'ernes værker blev det vist, at forkert arbejde med formatstrengen kan føre til alvorlige softwaresikkerhedssårbarheder, såsom vilkårlig udførelse af kode, eskalering af privilegier og lækager af følsomme data."
  21. ↑ The Protection of Information in Computer Systems, 1975 , h) Psykologisk accept: “Det er meget vigtigt, at brugergrænsefladen er brugervenlig, så brugerne intuitivt og enkelt anvender beskyttelsesmekanismer på den rigtige måde. Hvis brugerens mentale repræsentationer af beskyttelsesmålene stemmer overens med de mekanismer, han anvender i praksis, vil antallet af fejl blive minimeret. Hvis brugeren skal oversætte sine ideer om beskyttelse til et helt andet specifikationssprog, vil han uundgåeligt begå fejl.
  22. ↑ Sikker kodning i C og C++, 2013 , figur 1.2. Defekt logik udnyttet af W32.Blaster.Worm: "De logiske fejl, der udnyttes af W32.Blaster.Worm-ormen, er vist i fig. 1.2. Fejlen er, at while-løkken på linje 21 og 22 (brugt til at udtrække værtsnavnet fra en lang streng) ikke er afgrænset nok."
  23. ↑ Sikker kodning i C og C++, 2013 , 2.6 Runtime Protection Strategies: Input Validation.
  24. ↑ 1 2 Sikker kodning i C og C++, 2013 , 2.6 Runtime Protection Strategies.
  25. ↑ Django Security .
  26. ↑ Ruby on Rails Security .
  27. ↑ Notes of a Computer Virus Researcher, 2005 , tabel 3.1, s. 90.
  28. ↑ Malware History, 2010 , The NSA versus Morris: $100 Million in Damage, s. 23.
  29. ↑ CNBC International: Cyberkriminalitet koster den globale økonomi 450 milliarder dollars .
  30. ↑ The New Paper: Cyberkriminalitet kostede verdensøkonomien 620 milliarder dollar sidste år .
  31. ↑ RBC: Skaden fra WannaCry-virussen blev anslået til $1 milliard .
  32. ↑ 6abs: Skaden fra WannaCry-virussen oversteg 1 milliard dollars .
  33. ↑ Hi-Tech Mail.ru: Eksperter navngav et rekordstort antal skader fra WannaCry-virussen .
  34. ↑ MS17-010: EternalBlues store ikke-sidede pooloverløb i SRV-driver .
  35. ↑ WannaCry ransomware brugt i udbredte angreb over hele verden .
  36. ↑ CNews: Økonomisk skade fra vira .
  37. ↑ Nettotab: Estimering af de globale omkostninger ved cyberkriminalitet .

Litteratur

Yderligere læsning

Links