Poll
Reacties (19)
28-01-2008, 11:24 door
SirDice
All of the above?
28-01-2008, 13:08 door
meneer
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.
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.
28-01-2008, 13:44 door
root
Aantal centjes,
hoe meer je voor software betaalt, hoe veiliger het is :P
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.
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.
Door root
Aantal centjes,
hoe meer je voor software betaalt, hoe veiliger het is :P
e.e.a. ook nog afhankelijk van de prijs van je support contract?Aantal centjes,
hoe meer je voor software betaalt, hoe veiliger het is :P
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.
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.
28-01-2008, 18:27 door
[Account Verwijderd]
[Verwijderd]
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.
"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.
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.
29-01-2008, 07:18 door
tarunjj
Wat mij betreft is het enige criterium (al hoe wel moeilijk te berekenen)
de toegebrachte schade per computer.
de toegebrachte schade per computer.
Door tarunjj
Wat mij betreft is het enige criterium (al hoe wel moeilijk
te berekenen)
de toegebrachte schade per computer.
Wat mij betreft is het enige criterium (al hoe wel moeilijk
te berekenen)
de toegebrachte schade per computer.
Manager! :-)
29-01-2008, 16:20 door
e.r.
Door Anoniem
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.
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.
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.
Door e.r.
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.
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.
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.
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.
Door Anoniem
Manager! :-)
Nee, geen manager. Lekken die niet tot schade leiden zijn geen probleem. Door tarunjj
Wat mij betreft is het enige criterium (al hoe wel moeilijk
te berekenen)
de toegebrachte schade per computer.
Wat mij betreft is het enige criterium (al hoe wel moeilijk
te berekenen)
de toegebrachte schade per computer.
Manager! :-)
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.
30-01-2008, 12:16 door
meneer
Door Anoniem
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.
Door Anoniem
Manager! :-)
Nee, geen manager. Lekken die niet tot schade leiden zijnDoor tarunjj
Wat mij betreft is het enige criterium (al hoe wel moeilijk
te berekenen)
de toegebrachte schade per computer.
Wat mij betreft is het enige criterium (al hoe wel moeilijk
te berekenen)
de toegebrachte schade per computer.
Manager! :-)
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.
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.
Door Anoniem
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.
Door Anoniem
Manager! :-)
Nee, geen manager. Lekken die niet tot schade leiden zijnDoor tarunjj
Wat mij betreft is het enige criterium (al hoe wel moeilijk
te berekenen)
de toegebrachte schade per computer.
Wat mij betreft is het enige criterium (al hoe wel moeilijk
te berekenen)
de toegebrachte schade per computer.
Manager! :-)
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.
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?
01-02-2008, 22:06 door
[Account Verwijderd]
[Verwijderd]
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).
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).
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
