Secure Coding Secure Coding, intro, kap 1-2 Secure Coding, kap 3-6 Secure coding, slutsats

Secure Coding, Intro, kap. 1-2

När jag såg "Secure Coding" hoppades jag att även denna skulle vara likadan, en bok med idéer, tankar, lösningar och principer man bör ha i bakhuvudet för att kunna skriva säker och fungerande kod. Boken är skriven av Mark G. Graff och Kenneth R. van Wyk, två inte helt okända personer inom säkerhetsbranschen och utgiven av O'Reilly som inte är bara är kända för att ge ut böcker av god klass utan även för att de flesta böcker har ett specifikt djur på framsidan. Dock har denna bok inte fått nåt djur utan istället byggandet av en gammaldags stenbro. Som en sidonot kan ju nämnas att det påstås att romerska brobyggaringejörer fick stå under sina nybyggda broar medans man testade att fara över den med vagnar och soldater. Lite mer sånt inom programmeringsområdet skulle inte alltid vara helt fel. De har även en website som ackompanjerar boken med uppdateringar och nyheter inom området för den som vill hålla sig up-to-date eller bara ta en titt på exempelkapitlet.

Boken är på 200 sidor och indelad i 6 st större kapitel med olika inriktning:

• 1. "No Straight Thing"
• 2. "Architecture"
• 3. "Design"
• 4. "Implementation"
• 5. "Operations"
• 6. "Automation and Testing"

Kapitel 1 - "No Straight Thing" går igenom och funderar över varför inget någonsin funkar. Varför dyker alla dessa problem upp? Vilka typer av problem finns det och varför sker olika typer av attacker? Varför skriver bra programmerare dålig kod? De tar upp ett par exempel på olika typer av problem för att senare kunna återkomma till dem i respektive kapitel beroende på om problemet låg i designen eller i implementationen osv.
(T.ex SYN-floodarna från 95-96 som återkommer om och om igen i boken. En kortare förklaring och kommentar från mig finns i slutet av denna recension för de som inte var med då det begav sig)
De går också igenom i inledningen vad boken inte täcker, och det är bland annat ymniga kodexempel och "hur skriver jag bättre nätverksdemoner" och liknande. Det är en mer övergripande bok om kod i allmänhet och i viss mån om nätverk eftersom så mycket problem, attacker och virus kommer den vägen.

Kapitel 2 - "Architecture" tar upp hur man ska se över säkerhetens arkitektur, dvs före man sätter igång med designen och definitivt före man implementerar sin lösning. Här dyker en av bokens svagheter upp. De lyckas inte riktigt hålla ner saker till en hanterbar mängd. Alla skribenter måste ju se upp med sitt skrivande så att läsaren får en textmiljö som fäster i sinnet. De har skapat en komihåg-lista för den som ska vara säkerhetsarkitekt, och gudarna ska veta att det hade behövts under de senaste åren med allt strul som varit på nätet. Men de tar med allt som man kan tänkas behöva vilket leder till att listan är på hela 30 punkter!

Därefter tar de punkt för punkt och förklarar dem på ett bra sätt, men man kan omöjligen minnas 30 punkter, så det borde förmodligen krympts ner till ett mycket mindre antal genom att gruppera ihop saker under en gemensam punkt eller nåt. Dock är inga av punkterna dåliga eller överflödiga, det är fullt av sanningar alltihopa, men 30 punkter är lite väl magstarkt.

Kapitlet slutar med att de tar en titt på lite olika problem och ett par olika program för att få en bättre bild av vad man tänkt och vilka problem de löser. Även här tar de upp SYN-floodarna igen som en del av hur TCP/IP utvecklades för att fungera i en helt annan miljö än den vi har nu.

Secure Coding, kap. 3-6

För de som inte följt WLan-historien så står WEP för Wireless Equivalent Privacy, dvs det ska vara lika säkert som om man kört på koppartråd. Tyvärr hade de lite problem i själva designen som gjorde att det inte alls blev lika säkert som tråd. Och inte bara ett problem, de hade fyra. (Bortsett från "problemet" med att krypteringen inte ens är påslaget som default!)

Numera finns det WEP2, WPA och andra efterföljare som rättar till en del av problemen men inte alla. Det är alltså inte ett problem i koden, det är inte felskrivningar eller slarviga programmerare, det är själva designen som gör en säker implementation omöjlig. Ska man göra ett WLan-kort enligt den specen så kan man inte göra den säker just på grund av de fyra missarna. Illa.

Men det är en väldigt bra pekpinne för att visa på att designen betyder så mycket mer än vad man först kan tro. Igen får SYN-floodarna i TCP/IP-stackarna en känga, denna gång för dålig design.

Kapitel 4 - "Implementation" tar upp de specifika detaljerna om hur programmen ska kodas, vad som är viktigt i den delen av utvecklingen och vanliga fel. Den börjar med ett stycke om SYN-floodarna (igen), fast denna gång om felen i själva koden. Den förklarar lite om buffer overflows, tar upp detaljer att ta hänsyn till som att man alltid måste se upp med data som kommer från användaren och listar ett antal misstag som folk gjort.

Exempel på det sistnämnda innefattar bl.a. att referera till en fil flera gånger i samma program via dess filnamn så att den skulle kunnat byts ut under programmets gång, att inte förutsätta att din användare är godhjärtad och att inte förutsätta att allt jämt lyckas. Den har ett antal exempel på program och implementationer som varnande exempel på olika sätt som folk lyckats lura programmen att bugga ur på de mest oväntade sätt.

Kapitel 5 - "Operations" tar upp mycket om driften runt program och datorer, och här kommer mesta delen av nätverksproblemen in. Det finns en hel del "politiska" tips här också, med exempel på hur stora nät slagits av virus som hittat in till labbmaskiner som inte alls var under IT-gruppens kontroll. De patchades inte för de "var ju bara labbmaskiner". Väl på insidan kunde virusen sprida död och elände för fullt. Sådana saker bör inte kunna hända om man har en organisation som ser till att patchning av samtliga datorer och program är en grupps ansvar och inte delat mellan ett flertal olika grupper och personer. Speciellt inte om de inte ens talar med varandra. Det är i viss mån ett kapitel med listor på saker man ska och inte ska göra i olika situationer, fast med fokus på drift och inte på kodning så mycket. Dock ska man inte glömma att ett bra program är ju tänkt att gå i drift och fungera länge och väl, så den sidan ska man inte åsidose heller.

Kapitel 6 - "Automation and Testing" avslutar det hela med att gå igenom vad man kan göra mot/med sitt program för att hjälpa till att finna problem i koden, säkerhetsmässigt sett då. Det är inte så mycket om debuggning i sig, men mer om vilka verktyg och metoder man kan använda för att se om ens program möter de krav man ställt på det. Mycket av boken har varit ganska Unix-orienterad, och detta kapitel är ännu lite mer så. Varje gång det listas program för att testa en typ av fel, mäta ens nätverk eller nåt så är det ett par alternativa program men aldrig mer än en för Windows i varje lista. Jag har inget emot det själv, men det bör påpekas för potentiella köpare att när det väl kommer till kritan så är det 75% Unix och 25% Windows.

Secure coding, slutsats

Det är också ett evigt tjat om dessa SYN-floodar och trots att de skärskådar alla detaljer om hur felen uppstod, vart felen fanns och varför det kunde ske, så spenderar de på tok för lite tid med att prata om lösningen på problemet tycker jag. En bok med den målsättning som den här har, borde faktiskt kunnat ge sig på att beskriva olika lösningar med, eftersom de tar upp problemet så mycket. Att ha en bok som enbart inriktar sig på att prata om problem utan att nämna lösningarna leder inte så långt.

Det betyder inte att den är värdelös eller så, och jag kan gott och väl tänka mig att t.ex kurser och skolor skulle kunna ha gott utbyte av den här typen av sammanfattande böcker. Däremot så är jag tveksam till att rekommendera den till aspirerande säkerhetstekniker. Antingen så kan man lite och då är den inget bra som introduktion, eller så kan man mycket och kan ta till sig exemplen, men då är den nästan för simpel och uppenbar. Jag har lite svårt att placera den i nivå för vem den vänder sig till, och det tror jag inte är bra för en bok som är så seriös.

Man vet direkt till vem böcker i stil med "Nätverkskablar för Dummies" vänder sig, och vem som får ut nåt av "21 sätt att optimera rekursiva anrop under Oracle SQL" men jag vet inte riktigt vem som har nytta av den här. Det kanske är en bra bok att falla tillbaka mot om man provar ett par böcker och finner dem på för djup nivå och behöver nåt som täcker ett större område och som inte gräver ner sig för djupt på varje del.

Jag tror att det är en bra bok att låna, men inte att köpa. Hittar ni den på ert bibliotek, så läs gärna igenom den, den är inte så fasligt tjock och den är inte svårläst på nåt annat vis än att bra-att-ha-listorna är på 30 punkter som jag nämnde ovan.

Om någon har missat alla länkar till den förklarande texten om SYN-floodarna så finns den här.