Nieuws
image

Experts: Het is de hoogste tijd voor veilige code

vrijdag 24 februari 2006, 13:05 door Redactie, 6 reacties

Bij software security denken de meeste mensen aan "lapmiddelen" zoals anti-virus, IPS en firewall software. Musicus, wetenschapper, schrijver en techie Gary McGraw is van plan dit te veranderen. Ontwikkelaars moeten zich namelijk bezighouden met het schrijven van betrouwbare en veilige code. Programmeurs moeten daarnaast standaard security maatregelen in hun applicaties verwerken, en er niet op rekenen dat gebruikers de beveiliging regelen nadat de software is uitgerold.

In dit proces is ook voor IT managers en CIOs een rol weggelegd. Zij moeten hun aanbieders duidelijk maken dat ze voortaan geen "lekke code" meer kopen. McGraw heeft een boek geschreven, "Software Security: Building Security In", waarin stap voor stap het proces van veilig programmeren besproken wordt.

McGraw is niet alleen in zijn kruistocht voor veiligere software. Steeds meer experts maken duidelijk dat veilig programmeren een veel betere manier is om security problemen te voorkomen. Het kost echter tijd om dit te bewerkstelligen, en vereist ook inzet van het management. Toch blijft het breken van code makkelijker dan het schrijven van onbreekbare code. "Elke idioot kan een hek omver trappen, maar alleen een goede timmerman kan er één bouwen."

Reacties (6)
24-02-2006, 13:25 door Anoniem
"voortaan geen "lekke code" meer kopen"

Nou, dat was dan het einde van Microsoft.
AS
24-02-2006, 16:13 door Anoniem
Ja hoor: een correctheidsbewijs voor elke regel code.
'Ietsje' duurder, maar och.

SvU
25-02-2006, 13:28 door gmlk
Ja hoor: een correctheidsbewijs voor elke regel code.
'Ietsje' duurder, maar och.
SvU
Ongeveer 99% van de fouten die tot beveiligingsgaten leiden
zijn [url=http://en.wikipedia.org/wiki/Buffer_overrun]buffer overruns[/url] met voorspelbare gevolgen.

Door over te stappen op talen/platformen die [url=http://en.wikipedia.org/wiki/
Datatype#Type_checking]tijdens run-time strong en safe type-checking[/url] ondersteunen kan men deze bugs heel goedkoop voorkomen.

Je moet een heel goede programmeur zijn die foutloos in C of een verwante
taal kan schrijven en ik ken maar weinig goede programmeurs die lange tijd
willen werken in een van deze talen. De meeste goede programmeurs die ik
ken schrijven in een hogere taal zoals python, ruby of lisp.
25-02-2006, 22:47 door Anoniem
Veel programmeerfouten zijn te wijten aan de
compatibiliteitswensen van de gebruikers.

Hoe meer er word geprogrammeerd naar gebruiksvriendelijkheid
i.p.v. veiligheid zal het vrijwel onmogelijk zijn om 100%
veilig te programmeren. Mede door actieve interactie van de
gebruiker (gebruiker bewust maken voor ingebruikname), kan
het internetgebruik er een stuk "leuker" op worden.

Dit is een belangrijke reden dat ook OSS in steeds grotere
mate te maken heeft met dit soort programmeerfouten, deze
worden echter snel ontdekt en geupdate door de grote OSS
gemeenschap.
26-02-2006, 16:59 door Constant
IT beveiliging start mijn inziens bij het kiezen van het juiste hardware
platform. Daarna veilig programmeren. Zo ken ik verhalen over
Tandems/HP NonStops die toch crashten omdat de failsafe software
routines in het OS niet waren benut in de software.

De meeste financiële fraudes worden trouwens gepleegd door personen
met rechtmatige toegang tot het financiele systeem zonder het gebruik van enige hack methode
maar door middel van het betere fraudewerk zoals slepen met bedragen,
het verzinnen van niet-staande werknemers, valse facturen van spook
leveranciers, etc.

In dit proces is ook voor IT managers en CIOs een rol weggelegd.
Zij moeten hun aanbieders duidelijk maken dat ze voortaan geen "lekke
code" meer kopen.
Geen enkele software leverancier wil/kan
garanderen dat zijn software geen lekken bevat. Hooguit kan men iets
verklaren over de Quality Assurance procedures mbt de software
ontwikkeling. Is geen zekerheid, maar geeft wel een bruikbare indicatie.
01-03-2006, 20:42 door gmlk
We need to move beyond the complexity, limitations and weaknesses of Smalltalk and Lisp but seek a language with at least as simple a syntax and more expressiveness. We have the benefit of considerable research on advanced type systems which can used to work with the developer as opposed to against him.(bron: [url=http://www.jot.fm/issues/issue_2006_03/
column1]jot[/url])
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.

Zoeken
search