10 tips för att undvika brist på programvara

Innehåll

Vad är säker design?
10 tips för att undvika brist på programvara
Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv
Ett intressant beslut om varför programvara fortfarande är osäker

Källa: Kentoh / Dreamstime.com

Hämtmat:

När det gäller mjukvaruutveckling förändras fokus från att eliminera buggar till att fixa brister, av vilka många händer om och om igen.

All programvara har fel, särskilt i dagens komplexa kod med tusentals rader som måste formuleras just så. Institute of Electrical and Electronics Engineers (IEEE) känner till detta dilemma. Från och med 2014 lanserade IEEE ett nytt initiativ: Computer Society Center for Secure Design (CSD). Dess uppdrag? Att ge vägledning om att känna igen mjukvarusystem som är sårbara för kompromisser, och utforma och bygga programvarusystem med starka, identifierbara säkerhetsegenskaper

Man kan säga att det har gjorts tidigare. Det är sant. CSD avser dock att ta ett annat tillvägagångssätt genom att flytta en del av säkerhetsfokus från att hitta buggar till att identifiera vanliga designfel i hopp om att mjukvaruarkitekter kan lära av varandra.

För att få den typen av information sökte CSD hjälp av veteraner inom programvarusäkerhet - mer eller mindre de som antingen har gjort de nämnda misstagen eller haft en hand att fixa dem. Efter mycket övervägande samlade gruppen sina tankar i ett papper, "Undvika de 10 bristerna i programvarusäkerhetsdesign." IEEE nämnde att många av de brister som gjorde listan har varit välkända i decennier, men fortsätter att vara ett problem. Här kan du ta en titt på dessa brister - och hur du fixar dem.

Vad är säker design?

Det kan vara till hjälp att först definiera vad CSD anser som en säker design: "Målet med en säker design är att möjliggöra ett system som stöder och upprätthåller nödvändig autentisering, auktorisation, konfidentialitet, dataintegritet, ansvar, tillgänglighet och icke-avvisande krav. "

Ytterligare ett företag måste tas om hand innan du kommer till listan. Kommer du ihåg att CSD flyttade fokus från buggar till brister? Det är viktigt att alla är på samma sida med hur CSD definierar buggar och brister. Båda är programvarufel, om än olika. Så hur skiljer de sig exakt? Bugs är mjukvaruproblem på implementeringsnivå som kan finnas i koden, men kanske aldrig körs. Brister, å andra sidan, är problem som ligger på en djupare nivå; de är mer subtila och kan vara instanserade som programkod. Nedersta raden: Fel är resultatet av misstag eller översyn på designnivå.

Med definitionerna på plats, låt oss titta på de vanligaste bristerna i programvaran idag.

Tjäna eller ge - men antag aldrig - förtroende
Programvarusystem behöver ofta information från andra programvarupaket eller användare. Till exempel server- och klientapplikationer. Systemprogramvaran kan till en början vara säker, men om någon komponent är osäker kommer systemprogramvaran att ärva den osäkerheten. CSD betonade vikten av att inventera alla komponenter som kommunicerar med den aktuella programvaran. Då måste metoder utformas för att validera de upptäckta komponenterna.

Använd en autentiseringsmekanism som inte kan förbikopplas eller manipuleras med
Hela syftet med autentisering är besegrat om kontrollerade användare eller programvara kan kringgå eller manipulera processen. CSD erbjöd tre förslag: utforma autentiseringssystemet så att det fungerar som en choke-punkt, ger referenser en begränsad livslängd och använder flerfaktorsautentisering.

Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv

Du kan inte förbättra dina programmeringsfärdigheter när ingen bryr sig om mjukvarukvalitet.

Auktorisera efter verifiering
Autorisera skiljer sig från autentiseringen. Till exempel verifierar betalkort och PIN-koder ATM-användare. Autentiserade ATM-användare har dock endast rätt att ta ut pengar från sina konton. CSD anser att godkännande bör betraktas som en uttrycklig kontroll med hjälp av en gemensam infrastruktur (systembibliotek eller backend) som definierar de tillåtna privilegierna och tjänsterna.

Strikt separata data- och kontrollinstruktioner och behandla aldrig kontrollinstruktioner från otillförlitliga källor
För att förhindra injektionssårbarheter är det viktigt att undvika att samverka data och kontrollinstruktioner. Att ignorera principen om separering minskar säkerheten genom att undergräva säkerhetsmekanismer på låg nivå. CSD erbjuder följande råd:

Designa kompilatorer, analysatorer och relaterade infrastrukturdelar för att kontrollera kontrollflödesintegritet och segregering av kontroll och opålitliga data.
Skapa API: er som undviker att exponera metoder eller slutpunkter som konsumerar språksträngar.
Utveckla applikationer för att undvika API: er som blandar data och kontrollinformation i sina parametrar.

Definiera en metod som säkerställer att data uttryckligen valideras
Programvarusystem och komponenter gör antaganden om de data de kör. Det måste säkerställas att antagandena gäller. Sårbarheter uppstår genom fel antaganden. CSD rekommenderar:

Utformning eller användning av centraliserade valideringsmekanismer.
Omvandlingen av data till en kanonisk form.
Användning av vanliga bibliotek med valideringsprimitiv.
Att utforma implementeringens inputvalidering för att vara medveten om staten.

Använd kryptografi korrekt
CSD medger att det är svårt att få kryptografi rätt. Att inte göra det rätt leder dock till:

Missbruk av bibliotek och algoritmer
Dålig nyckelhantering
Slumpmässighet som inte är slumpmässig
Underlåtenhet att centralisera kryptografi
Underlåtenhet att möjliggöra algoritmanpassning och utveckling

På grund av denna svårighet förespråkar CSD att konsultera en expert. CSD noterade också att expertfältet bör tillämpas kryptografi.

Hantera identitetskänsliga uppgifter med försiktighet
Två saker händer; formgivare misslyckas med att identifiera data som känsliga, eller designers bestämmer inte alla sätt på vilka data kan exponeras eller manipuleras. CSD föreslår att man skapar en datasensitivitetspolicy som hanterar alla företagsspecifika faktorer. Politiken bör innehålla:

Information om myndigheter och branschregler som gäller för organisationen
Huruvida datasekretess gäller eller inte
Hur data hanteras när de är i övergång

Tänk alltid på användarna
Utvecklare som inte överväger användare kan leda till många problem, inklusive:

Privilegieupptrappning
Användare avslöjar känslig information
Komplicerade säkerhetsförfaranden som förbättrar oddsen för felaktig eller bristande användning.

CSD är medveten om att säkerhet kontra bekvämlighet är ett problem. Att använda en riskbedömningsmetod (göra avvägningar) är kanske inte perfekt, men det är bättre än att ignorera användare helt.

Förstå hur integrering av externa komponenter förändrar din attackyta
I likhet med den första konstruktionsfelen ärver mjukvarusystem också säkerhetsbrister från externa komponenter som integreras i moderprogramvaran. CSD råder:

Planera tillräckligt med tid för att studera extern komponent säkerhet.
Undvika förtroende för externa komponenter tills säkerhetskontroller har tillämpats.
Dokumentera allt. Förklara till exempel varför standardinställningarna ändrades.

Var flexibel när du överväger framtida förändringar av objekt och aktörer
Om man antar att programmets kod är statisk ber det om problem. Notens programvara är under ständig revidering. Att veta att den viktiga frågan blir då hur programvaruförändringar påverkar säkerheten. För detta ändamål föreslår CSD att ha följande i åtanke. Design för: