All of the above?

Leuk, maarre, wat is dan beter/veiliger: veel patches of weinig patches?
Veel of weinig exploits? Veel of weinig lekken (maar hoe weet je dat)?

Wat mij betreft maar 1 goed criterium: hoe meer code hoe meer
(mogelijke) lekken.

Aantal centjes,

hoe meer je voor software betaalt, hoe veiliger het is :P

Gebruikte ontwikkelmethode, want je kunt bijna nooit weten hoeveel
lekken er is een software-pakket zitten. De fout ligt altijd in de manier
van programmeren, want anders maken ze er geen patch voor.

Dit kun je preventief voorkomen door een goede ontwikkelmethode te
gebruiken.

e.e.a. ook nog afhankelijk van de prijs van je support contract?

Ik mis een paar belangrijke, het gebruikte security model,
en gebruik van een programeertaal die dit model ondersteunt.
Gebruikt de code pointers (C en slecht geprogrameerde C++
etc), dan is dat een groot minpunt. Gebruikt de code vooral
references, maar is de taal hybride, dan is dat ietjes
beter. Een memory safe taal nog iets beter. Het volgende
stapje is daarna direct een mega stap, gebruik van ee
capability secure taal zoals e of joe-e, tel daar bij op het
programeren volgens het ABAC security model, en je moet als
ontwikkelaar echt een enorme sukkel zijn om het nog te
verkloten.

Ik neem aan dat je dit niet serieus meent.

Het pakket met de beste SLA, is bedrijfstechnisch gezien idd het meest
"veilig"

Zo gek is de stelling " Hoe meer je voor software betaalt, hoe veiliger het is"
dan ook niet.

Daadwerkelijke veiligheid van het produkt zelf, heeft echter absoluut geen
relatie met de prijs.

Ik heb gekozen voor Anders.

Het gaat volgens mij om de schade die wordt aangericht.

Onkraakbaar voor een applicatie die niet of nauwelijks wordt
gebruikt en waarvan toch kraken geen tot nauwelijks schade
aanricht, is een verspilling van geld, talent en moeite.

Schade in deze context is zowel materiele als immateriele
schade.

Wat mij betreft is het enige criterium (al hoe wel moeilijk te berekenen)
de toegebrachte schade per computer.

Manager! :-)

Kortom Impact van beveiligingslekken?

Ben het er wel mee eens.
Als je weet dat je financiele pakket zo lek als een mandje is is dat toch
echt belangrijker dan de mediaplayer die je gebruikt om je
bedrijfspodcast mee af te spelen. (niet dat dat zo is, maar als gaar
voorbeeld)
Jammer genoeg zijn die lekker nooit bekend alvorens men zo'z pakket
koopt.
Dus je kan het eigenlijk niet als meetpunt gebruiken.

[quote][i]Door e.r.[/i]
[quote]
Kortom Impact van beveiligingslekken?

Ben het er wel mee eens.
Als je weet dat je financiele pakket zo lek als een mandje
is is dat toch
echt belangrijker dan de mediaplayer die je gebruikt om je
bedrijfspodcast mee af te spelen. (niet dat dat zo is, maar
als gaar
voorbeeld)
Jammer genoeg zijn die lekker nooit bekend alvorens men zo'z
pakket
koopt.
Dus je kan het eigenlijk niet als meetpunt gebruiken.[/quote]

Wanneer ik het woordenboek erbij pak, dan wordt schade
vertaalt met damage, en niet met impact :-). Daarom kies ik
voor schade.

En het kan wel als meetpunt, mits je vooraf een risico
analyse maakt. Daar waar de meeste risico op schade zit,
daar tref je de meeste maatregelen.

Nee, geen manager. Lekken die niet tot schade leiden zijn geen probleem.
Zoiets als een bug in software waar de gebruiker geen last van heeft. Wel
storend voor een nette programmeur, niet voor het gebruik. Zo telt een lek
dat niet tot problemen ("schade") leidt wat mij betreft niet mee.

Mooi allemaal, maar kenmerk van de meeste bugs is dat je ze
pas opmerkt als het te laat is. Als de schade al geweest is.
Geen schade wil niet zeggen dat er geen risico is.
Het gaat dus helaas niet om schade, maar om risico, de kans
op schade zou je kunnen zeggen. En de enige objectieve
indicator daarvoor is de omvang van een programma. Hoe
groter, hoe meer waarschijnlijk het is dat er een foutje in
de code zit. En een foutje in de code zou een kans op schade
kunnen betekenen.

Hier een interessant artikel (en let wel: wat mij betreft is
dit geen aanval op MS, immers we weten niet hoeveel bugs per
regel code XP bevat, de aanname van de auteur is op dit punt
dus niet valide): http://opsamericas.com/?p=565

ik heb gekozen voor anders omdat het een combinatie van ongeveer
alle aangegeven punten moet zijn waaraan je kan opmaken of iets veilig
is of niet. met bovenaan de impact van de lekken

daarnaast heeft het ook voor een groot gedeelte te maken door wie het
geschreven is en of dat er door meerdere mensen naar gekeken is.

Mijn manager opmerking was omdat dit alleen een reactieve
benadering is.

Ik heb ooit een developper horen zeggen dat ze pas aan
beviliging gingen doen als de klant hierom ging vragen.

Is het niet kortzichtig om alleen uit te gaan van de schade
(of impact)? Zeker in een praktijk waar software soms meer
dan 10 jaar mee moet kunnen gaan. Zou er niet gekeken moeten
worden naar mogelijke toekomstige ontwikkelingen?

ik vind de snelheid waarmee gepatcht wordt belangrijk, dat
er in het verleden nagenoeg geen ernstige lekken geweest
zijn geeft opzich wel een fijn gevoel,
maar mocht er toch een lek opduiken dan zie ik het liefst
dat dat zo snel mogelijk gepatcht wordt
Bij bedrijfs software zou ik waarschijnlijk kijken tussen
het aantal lekken en op welke manier die misbruikt kunnen worden

all of the above, plus o.a. nog het feit of de ontwikkelaar
de neiging heeft bekende exploits voor zich te houden ipv
meteen een patch uit te brengen en zijn gebruikers te
informeren.

over gebruikte taal, c/c++ etc zijn alleen maar
'gevaarlijker' in dat je zelf na moet denken over het
geheugengebruik. Maar juist daarom vaak de ideale taal om
bepaalde software mee te maken. Maar ipc biedt een
specifieke taal niet per definitie meer of minder
beveiliging. Integendeel, sommige talen die 'veel voor je
doen' doen specifieke dingetjes juist weer net niet, en dat
moet je dan weer weten (null-terminated strings zijn
bijvoorbeeld altijd een potentieel probleem).