RFC voorstel over 'vulnerability disclosure'
Steve Christey van Mitre en Chris Wysopal van @stake publiceerden deze week een zogenaamde 'internet draft' over het vrijgeven van software lekken richting producenten. In dit voorstel gaat men ondere andere in op redelijke tijden die een producent aan dient te houden bij het vrijgeven van informatie over software lekken. De auteurs zijn van plan nog een apart document te ontwikkelen waarin beschreven wordt wat leveranciers en ontdekkers van software fouten precies dienen te vermelden in hun correspondentie.
De komende 6 maanden mag de internet community commentaar leveren op dit document, indien het voorstel deze kritiek overleeft loopt het kans een 'officiele' RFC te worden.
Reacties (21)
Tja......
Nu enkele onderdelen van de grondwetten van -veel al westerse- democratieën op de tocht staat.
En men na 11 september daar met een steviger tempo aan het afbouwen is.
Was het wel te verwachten dat men RFC's zouden ontstaan die "common practise" ter discussie stellen.
Partially disclosure, non-disclosure, responsible disclosure etc.. zijn leuk termen, maar als je de lijn door trekt, ondermijnt het vrijheid van meningsuiting en openbaarheid van informatie.
De schade die hierdoor geleden wordt, is vele malen groter dan de schade die aangericht zou kunnen worden, immers het is op termijn niet zonder meer terug te draaien.
Ook is het maar de vraag of men het geheel -waar men het voor denkt te doen- hierdoor daadwerkelijk veiliger wordt.
Je moet er toch niet aan denken dat je een patent op een exploit/bug/patch mag/kan aanvragen.
Net zomin dat de remedie tegen ziektes 'onder de pet' gehouden wordt, ten bate van een paar belanghebbenden.
In de afgelopen jaren zijn de black/white/grey hat hackers al meer en meer hun 'research' aan het verbergen, onder het mom: non-disclosure levert me meer op dan een ego boost bij full-disclosure.
Als dit door het security wereldje ook zo wordt gezien, is de hek van de dam.
"If you hire us, then we tell you which bugs we know about"
Degene die deze achtelijke ideeën verzinnen zullen op den duur aan het kortste eind trekken, ongeacht dat er structureel minder schade aangericht wordt door scriptkiddies, zullen er vroeg of laat criminelen opstaan met de -financieële- middelen.
Tijd zal uitwijzen of we wellicht niet beter uit waren met onnozele defacers, waardoor op termijn de schade beperkter zou zijn geweest, dan die door georganiseerde misdaad gepleegt zou kunnen worden.
mvg,
[email]anonymouse@securitydatabase.net[/email]
Nu enkele onderdelen van de grondwetten van -veel al westerse- democratieën op de tocht staat.
En men na 11 september daar met een steviger tempo aan het afbouwen is.
Was het wel te verwachten dat men RFC's zouden ontstaan die "common practise" ter discussie stellen.
Partially disclosure, non-disclosure, responsible disclosure etc.. zijn leuk termen, maar als je de lijn door trekt, ondermijnt het vrijheid van meningsuiting en openbaarheid van informatie.
De schade die hierdoor geleden wordt, is vele malen groter dan de schade die aangericht zou kunnen worden, immers het is op termijn niet zonder meer terug te draaien.
Ook is het maar de vraag of men het geheel -waar men het voor denkt te doen- hierdoor daadwerkelijk veiliger wordt.
Je moet er toch niet aan denken dat je een patent op een exploit/bug/patch mag/kan aanvragen.
Net zomin dat de remedie tegen ziektes 'onder de pet' gehouden wordt, ten bate van een paar belanghebbenden.
In de afgelopen jaren zijn de black/white/grey hat hackers al meer en meer hun 'research' aan het verbergen, onder het mom: non-disclosure levert me meer op dan een ego boost bij full-disclosure.
Als dit door het security wereldje ook zo wordt gezien, is de hek van de dam.
"If you hire us, then we tell you which bugs we know about"
Degene die deze achtelijke ideeën verzinnen zullen op den duur aan het kortste eind trekken, ongeacht dat er structureel minder schade aangericht wordt door scriptkiddies, zullen er vroeg of laat criminelen opstaan met de -financieële- middelen.
Tijd zal uitwijzen of we wellicht niet beter uit waren met onnozele defacers, waardoor op termijn de schade beperkter zou zijn geweest, dan die door georganiseerde misdaad gepleegt zou kunnen worden.
mvg,
[email]anonymouse@securitydatabase.net[/email]
Originally posted by
Tja......
Nu enkele onderdelen van de grondwetten van -veel al westerse- democratieën op de tocht staat.
En men na 11 september daar met een steviger tempo aan het afbouwen is.
Was het wel te verwachten dat men RFC's zouden ontstaan die "common practise" ter discussie stellen.
Partially disclosure, non-disclosure, responsible disclosure etc.. zijn leuk termen, maar als je de lijn door trekt, ondermijnt het vrijheid van meningsuiting en openbaarheid van informatie.
De schade die hierdoor geleden wordt, is vele malen groter dan de schade die aangericht zou kunnen worden, immers het is op termijn niet zonder meer terug te draaien.
Tja......
Nu enkele onderdelen van de grondwetten van -veel al westerse- democratieën op de tocht staat.
En men na 11 september daar met een steviger tempo aan het afbouwen is.
Was het wel te verwachten dat men RFC's zouden ontstaan die "common practise" ter discussie stellen.
Partially disclosure, non-disclosure, responsible disclosure etc.. zijn leuk termen, maar als je de lijn door trekt, ondermijnt het vrijheid van meningsuiting en openbaarheid van informatie.
De schade die hierdoor geleden wordt, is vele malen groter dan de schade die aangericht zou kunnen worden, immers het is op termijn niet zonder meer terug te draaien.
Hoezo geen vrijheid van menings uiting? Heb je het voorstel voor de RFC gelezen?
uit de RFC:
1 Introduction and Purpose
This document provides guidance and recommendations for the community
of developers, vendors, end users, researchers and security
professionals who wish to perform responsible vulnerability
disclosure within the information technology arena.
1 Introduction and Purpose
This document provides guidance and recommendations for the community
of developers, vendors, end users, researchers and security
professionals who wish to perform responsible vulnerability
disclosure within the information technology arena.
Het is dus alleen voor diegene die een verantwoordelijke 'disclosure' willen. Wil je dat niet, dan doe je dat niet.....
En als de georganiseerde misdaad aan de slag wil met allerlei buffer overflows en andere vulnerabilities, doen ze dat toch wel, of er nou een rfc is of niet.
Dus waarom zo'n ophef??
Originally posted by
Het is dus alleen voor diegene die een verantwoordelijke 'disclosure' willen. Wil je dat niet, dan doe je dat niet.....
Het is dus alleen voor diegene die een verantwoordelijke 'disclosure' willen. Wil je dat niet, dan doe je dat niet.....
Hm.. interessant.
Dus als een bedrijf zegt verantwoordelijk te zijn zullen zij zich aan de "RFC" moeten houden. En zichzelf daarmee vrijheid van meningsuiting ontzeggen.
Immers hoe kun je jezelf als bedrijf serieus nemen als je zegt verantwoordelijk te zijn en toch onverantwoordelijk (in wiens ogen?!?!?!?) publiceert.
Originally posted by VortexXx
Hm.. interessant.
Dus als een bedrijf zegt verantwoordelijk te zijn zullen zij zich aan de "RFC" moeten houden. En zichzelf daarmee vrijheid van meningsuiting ontzeggen.
Immers hoe kun je jezelf als bedrijf serieus nemen als je zegt verantwoordelijk te zijn en toch onverantwoordelijk (in wiens ogen?!?!?!?) publiceert.
Hm.. interessant.
Dus als een bedrijf zegt verantwoordelijk te zijn zullen zij zich aan de "RFC" moeten houden. En zichzelf daarmee vrijheid van meningsuiting ontzeggen.
Immers hoe kun je jezelf als bedrijf serieus nemen als je zegt verantwoordelijk te zijn en toch onverantwoordelijk (in wiens ogen?!?!?!?) publiceert.
Als je als bedrijf serieus genomen wil worden is het juist handig als je kunt zeggen dat je voldoet aan bepaalde standaarden (BS7799, ISO 9001, enz.) Bijv: Een bedrijf zal zich graag houden aan de RFC's voor de TCP/IP stack, doen ze dat niet dan lopen ze het risco dat hun producten niet verkocht worden omdat ze niet kunnen communiceren met producten van andere leveranciers.
Als je aan een bepaalde standaard houd, wil dat toch niet zeggen dat je daarmee vrijheid van meningsuiting ontzegt?? Je mening is dan dat je vind dat je je aan die standaard moet houden.
Vrijheid van meningsuiting gaat om meningen, daar heeft een commerciele bedrijfsvoering weinig mee te maken.....
Originally posted by
Vrijheid van meningsuiting gaat om meningen, daar heeft een commerciele bedrijfsvoering weinig mee te maken.....
Vrijheid van meningsuiting gaat om meningen, daar heeft een commerciele bedrijfsvoering weinig mee te maken.....
Het gaat hier niet om meningen maar om publicaties van informatie. Op het moment dat je publicaties aan banden legt, door bijv. volgens "standaarden" te werken, ben je toch bezig om je vrijheid te beperken.
Ik vind de vergelijking met standaarden en certificeringen ver gezocht.
Het later of juist niet publiceren van gevonden lekken is toch security by obscurity.
Als ik me niet vergis had RFP het hier ook al over in het msadc-stuk. Wil jij dat er bedrijven zijn die lekken weten en dit voor hunzelf houden (al is het maar voor een aantal dagen) ??
Ik denk het niet. Het feit dat er na publicatie al na enkele uren werkende exploits zijn heeft te maken met de verotte geest van de mens maar ik weet tenminste wel wat ik kan verwachten... en een gewaarschuwd mens telt voor twee.
btw. met wie heb ik het genoegen??
Originally posted by VortexXx
Het gaat hier niet om meningen maar om publicaties van informatie. Op het moment dat je publicaties aan banden legt, door bijv. volgens "standaarden" te werken, ben je toch bezig om je vrijheid te beperken.
Ik vind de vergelijking met standaarden en certificeringen ver gezocht.
Het later of juist niet publiceren van gevonden lekken is toch security by obscurity.
Als ik me niet vergis had RFP het hier ook al over in het msadc-stuk. Wil jij dat er bedrijven zijn die lekken weten en dit voor hunzelf houden (al is het maar voor een aantal dagen) ??
Ik denk het niet. Het feit dat er na publicatie al na enkele uren werkende exploits zijn heeft te maken met de verotte geest van de mens maar ik weet tenminste wel wat ik kan verwachten... en een gewaarschuwd mens telt voor twee.
btw. met wie heb ik het genoegen??
Het gaat hier niet om meningen maar om publicaties van informatie. Op het moment dat je publicaties aan banden legt, door bijv. volgens "standaarden" te werken, ben je toch bezig om je vrijheid te beperken.
Ik vind de vergelijking met standaarden en certificeringen ver gezocht.
Het later of juist niet publiceren van gevonden lekken is toch security by obscurity.
Als ik me niet vergis had RFP het hier ook al over in het msadc-stuk. Wil jij dat er bedrijven zijn die lekken weten en dit voor hunzelf houden (al is het maar voor een aantal dagen) ??
Ik denk het niet. Het feit dat er na publicatie al na enkele uren werkende exploits zijn heeft te maken met de verotte geest van de mens maar ik weet tenminste wel wat ik kan verwachten... en een gewaarschuwd mens telt voor twee.
btw. met wie heb ik het genoegen??
Ja je beperkt je vrijheid.... Dat doe je ook als je je rijbewijs haalt want dan moet je je aan de regels houden.
Het gaat er niet om in de RFC dat bedrijven express informatie achterhouden, het gaat erom dat reporters informatie netjes aan het getroffen bedrijf melden. Zodat zij patches kunnen maken voordat allerlei anderen er exploits voor kunnen maken.
Want wat moet je anders als je weet dat er een lek zit in je e-commerce omgeving en je mag van de business de machine niet uit de lucht halen?
Als je wil weten wie ik ben stuur je maar een mailtje naar [email]highs013@yahoo.com[/email], dan zal ik je mijn directe e-mail geven.
Originally posted by
Ja je beperkt je vrijheid.... Dat doe je ook als je je rijbewijs haalt want dan moet je je aan de regels houden.
[/QUOTE]
Sla de vele discussies over internet rijbewijs er eens op na.
Ondanks dat men geacht wordt dat men doormiddels van een rijbewijs zich aan de wet en verkeersregels dient te houden -en over voldoende verkeers inzicht beschikt- wil dat niet zeggen dat het nageleefd zal worden. (anders was het niet zo een melkkoe van justitie geworden).
Maar wie garandeert mij dat een beveiligingsbedrijf, een 'RFC' hacker en een producent mij ten alle tijden bijtijds gaan informeren?
Immers research & development kosten tijd en geld, dus het is voor Microsoft makkelijker & goedkoper om in een volgende release een bepaald probleem op te lossen, dan ad-hoc een lapmiddel te leveren. (met alle gevolgen van dien in de tussen tijd, tenzij je er vanuit gaat dat elke bug maar door 1 persoon op aarde gevonden kan worden)
Zodat zij patches kunnen maken voordat allerlei anderen er exploits voor kunnen maken.
Vaak worden expoits gebouwd aan de hand van de patch, immers dat bevat de handleiding van waar het probleem nu eigenlijk zit.
Aangezien dat in vele gevallen in uren gedaan kan worden, en de patch distributie in het verleden van een exploit gerust maanden op zich kan laten wachten -tenzij je autoupdate van Microsoft vertrouwd in je productie omgeving-, zie ik er geen voordeel in.
Immers, als je meteen weet waar je aan toe bent, kan je een patch/workaround engineeren die voor jouw omgeving op dat moment het beste uitkomt. (tenzij je van mening bent dat alleen leveranciers met oplossingen mogen komen)
Want wat moet je anders als je weet dat er een lek zit in je e-commerce omgeving en je mag van de business de machine niet uit de lucht halen?
Als je volgens ITIL werkt of enige andere structurele beheer methodiek, zul je in een productie omgeving toch niet meteen een patch kunnen gebruiken, dus de kans dat je tussen releasen van patch en service windows gecracked wordt, blijft.
mvg &
idem:
[email]anonymouse@securitydatabase.net[/email]
btw: Cisco en Microsoft komen met een anti-terrorisme stack, dan hebben we bovenstaande RFC toch al niet nodig.
http://www.securitydatabase.net/forum/viewtopic.php?TopicID=3548
Ja je beperkt je vrijheid.... Dat doe je ook als je je rijbewijs haalt want dan moet je je aan de regels houden.
[/QUOTE]
Sla de vele discussies over internet rijbewijs er eens op na.
Ondanks dat men geacht wordt dat men doormiddels van een rijbewijs zich aan de wet en verkeersregels dient te houden -en over voldoende verkeers inzicht beschikt- wil dat niet zeggen dat het nageleefd zal worden. (anders was het niet zo een melkkoe van justitie geworden).
Maar wie garandeert mij dat een beveiligingsbedrijf, een 'RFC' hacker en een producent mij ten alle tijden bijtijds gaan informeren?
Immers research & development kosten tijd en geld, dus het is voor Microsoft makkelijker & goedkoper om in een volgende release een bepaald probleem op te lossen, dan ad-hoc een lapmiddel te leveren. (met alle gevolgen van dien in de tussen tijd, tenzij je er vanuit gaat dat elke bug maar door 1 persoon op aarde gevonden kan worden)
Zodat zij patches kunnen maken voordat allerlei anderen er exploits voor kunnen maken.
Vaak worden expoits gebouwd aan de hand van de patch, immers dat bevat de handleiding van waar het probleem nu eigenlijk zit.
Aangezien dat in vele gevallen in uren gedaan kan worden, en de patch distributie in het verleden van een exploit gerust maanden op zich kan laten wachten -tenzij je autoupdate van Microsoft vertrouwd in je productie omgeving-, zie ik er geen voordeel in.
Immers, als je meteen weet waar je aan toe bent, kan je een patch/workaround engineeren die voor jouw omgeving op dat moment het beste uitkomt. (tenzij je van mening bent dat alleen leveranciers met oplossingen mogen komen)
Want wat moet je anders als je weet dat er een lek zit in je e-commerce omgeving en je mag van de business de machine niet uit de lucht halen?
Als je volgens ITIL werkt of enige andere structurele beheer methodiek, zul je in een productie omgeving toch niet meteen een patch kunnen gebruiken, dus de kans dat je tussen releasen van patch en service windows gecracked wordt, blijft.
mvg &
idem:
[email]anonymouse@securitydatabase.net[/email]
btw: Cisco en Microsoft komen met een anti-terrorisme stack, dan hebben we bovenstaande RFC toch al niet nodig.
http://www.securitydatabase.net/forum/viewtopic.php?TopicID=3548
Originally posted by
Ja je beperkt je vrijheid.... Dat doe je ook als je je rijbewijs haalt want dan moet je je aan de regels houden.
Het gaat er niet om in de RFC dat bedrijven express informatie achterhouden, het gaat erom dat reporters informatie netjes aan het getroffen bedrijf melden. Zodat zij patches kunnen maken voordat allerlei anderen er exploits voor kunnen maken.
Want wat moet je anders als je weet dat er een lek zit in je e-commerce omgeving en je mag van de business de machine niet uit de lucht halen?
Als je wil weten wie ik ben stuur je maar een mailtje naar [email]highs013@yahoo.com[/email], dan zal ik je mijn directe e-mail geven.
Ja je beperkt je vrijheid.... Dat doe je ook als je je rijbewijs haalt want dan moet je je aan de regels houden.
Het gaat er niet om in de RFC dat bedrijven express informatie achterhouden, het gaat erom dat reporters informatie netjes aan het getroffen bedrijf melden. Zodat zij patches kunnen maken voordat allerlei anderen er exploits voor kunnen maken.
Want wat moet je anders als je weet dat er een lek zit in je e-commerce omgeving en je mag van de business de machine niet uit de lucht halen?
Als je wil weten wie ik ben stuur je maar een mailtje naar [email]highs013@yahoo.com[/email], dan zal ik je mijn directe e-mail geven.
Ik begrijp wat je wil zeggen en ben het gedeeltelijk met je eens.
De kern van de discussie is of we blij moeten zijn met de ontwikkeling dat de manier van publiceren bepaald gaan worden.
Ik vind zeker dat richtlijnen nodig zijn. Maar de ontwikkelingen waar Anony. over sprak zijn kwalijk. Research 'verbergen'is niet ver van research verkopen aan de hoogste bieder. Dit kan dan een organisatie zijn die kwalijke bedoelingen heeft maar ook een organisatie waarbij het kopen van zulke informatie 'goedkoper' is dan naam- en omzetverlies voor een bepaald product.
Originally posted by
Ik begrijp wat je wil zeggen en ben het gedeeltelijk met je eens.
De kern van de discussie is of we blij moeten zijn met de ontwikkeling dat de manier van publiceren bepaald gaan worden.
Ik vind zeker dat richtlijnen nodig zijn. Maar de ontwikkelingen waar Anony. over sprak zijn kwalijk. Research 'verbergen'is niet ver van research verkopen aan de hoogste bieder. Dit kan dan een organisatie zijn die kwalijke bedoelingen heeft maar ook een organisatie waarbij het kopen van zulke informatie 'goedkoper' is dan naam- en omzetverlies voor een bepaald product.
Ik begrijp wat je wil zeggen en ben het gedeeltelijk met je eens.
De kern van de discussie is of we blij moeten zijn met de ontwikkeling dat de manier van publiceren bepaald gaan worden.
Ik vind zeker dat richtlijnen nodig zijn. Maar de ontwikkelingen waar Anony. over sprak zijn kwalijk. Research 'verbergen'is niet ver van research verkopen aan de hoogste bieder. Dit kan dan een organisatie zijn die kwalijke bedoelingen heeft maar ook een organisatie waarbij het kopen van zulke informatie 'goedkoper' is dan naam- en omzetverlies voor een bepaald product.
Maar research kan nu toch ook? zonder dat er iets gerefeld is? tuurlijk is dat gevaarlijk, maar dat heeft niks met het originele bericht te maken.
Originally posted by
Maar research kan nu toch ook? zonder dat er iets gerefeld is? tuurlijk is dat gevaarlijk, maar dat heeft niks met het originele bericht te maken.
Maar research kan nu toch ook? zonder dat er iets gerefeld is? tuurlijk is dat gevaarlijk, maar dat heeft niks met het originele bericht te maken.
ik bedoel reserch verkopen kan nu toch ook
Ik probeer te mailen naar [email]anonymous@securitydatabase.net[/email]
maar dat wil niet lukken:
<anonymouse@securitydatabase.net>:
80.247.207.67 does not like recipient.
Remote host said: 554 <anonymouse@securitydatabase.net>: Recipient
address rejected: Relay access denied
Giving up on 80.247.207.67.
suggesties?
maar dat wil niet lukken:
<anonymouse@securitydatabase.net>:
80.247.207.67 does not like recipient.
Remote host said: 554 <anonymouse@securitydatabase.net>: Recipient
address rejected: Relay access denied
Giving up on 80.247.207.67.
suggesties?
Originally posted by
Ik probeer te mailen naar [email]anonymous@securitydatabase.net[/email]
maar dat wil niet lukken:
<anonymouse@securitydatabase.net>:
80.247.207.67 does not like recipient.
Remote host said: 554 <anonymouse@securitydatabase.net>: Recipient
address rejected: Relay access denied
Giving up on 80.247.207.67.
suggesties?
Ik probeer te mailen naar [email]anonymous@securitydatabase.net[/email]
maar dat wil niet lukken:
<anonymouse@securitydatabase.net>:
80.247.207.67 does not like recipient.
Remote host said: 554 <anonymouse@securitydatabase.net>: Recipient
address rejected: Relay access denied
Giving up on 80.247.207.67.
suggesties?
Als je het om 16:30 probeert zal het wel lukken.
Originally posted by
De kern van de discussie is of we blij moeten zijn met de ontwikkeling dat de manier van publiceren bepaald gaan worden.
De kern van de discussie is of we blij moeten zijn met de ontwikkeling dat de manier van publiceren bepaald gaan worden.
Laten we eerst eens kijken hoe de 'erkende' partijen er mee omgaat.
Zomaar een dag in Februari....
Geruchten gaan over SNMP bug, niemand weet iets, SNMP scans nemen toe, zonder dat iemand iets weet.
Beetje bij beetje druppelt iets uit....
Tjakkaa..... CERT announcement!!!!
Je leest dat, je leest wat je vendors te vertellen hebben, uurtje later lees je weer wat je vendors te vertellen hebben, en een dag later weereens, omdat ze maar niet tot een eenduidige conclusie kan komen.
Ondertussen ren je als een kip zonder kop met een CERT advisory naar je baas, je sprokkelt je collega's bij elkaar, en met de laatste -final?- advies van je vendor, ga je maar SNMP uitzetten, en firmware patchen, updaten etc..
Een ander scenario, je leest een posting op bugtraq, er wordt verwezen naar een SNMP audit tooltje.
Je -en vele anderen- downloaden het, je pakt de JAR file uit -hoeveel zullen dat gedaan hebben?- je ziet dat er 50.000 SNMP string op gequeried wordt, je bedenkt je op eens.... hé die snmpwalk loopjes die ik maakte, en dat artikel dat ik 5 jaar al geleden gelezen gaat over het zelfde, en je bedenkt je dat je om die reden al had gezorgt dat men niet zomaar SNMP queries kan doen.
Tevens heb je geregeld met stress en performance testen SNMWALK loopjes gemaakt, om te zien hoe devices daarop reageren, en wist je al dat load op vrijwel elk device onaanvaardbaar om hoog schiet, en je om die reden SNMP alleen gericht en zinvol wilt gebruiken.
Je baas komt naar jouw toe, en vraagt bezorgt "Moeten we geen actie ondernemen" waarop jij kan antwoorden, nee het is bullshit om dit prioriteit te geven.
Waarna je een schouderklopje krijgt.
bron: phrack
http://www.securitydatabase.net/forum/viewtopic.php?TopicID=3443#7378
Moraal van het verhaal, als je zelf verstand hebt om iets te kunnen begrijpen, te doorzien, naar eigen inzicht interpreteren, waarom zou je je dan afhankelijk willen maken van een handje vol leveranciers?
Die weten toch niet hoe jouw specifieke omgeving/klanten geconfigureerd zijn?
Of gaan we binnenkort met ze allen zonder meer upgraden omdat CERT en je vendor roepen dat het verstandig is, maar niet de technische details willen vertellen?
Want als er iets meer kost -op globale schaal- dan incidenten, zijn het wel onnodige patch sessies, zeker als patches instabiel blijken te zijn dan wel om bepaalde redenen niet in jouw omgeving geïmplementeerd kunnen worden.
Je gaat dan toch EISEN dat je de details MOET weten, om jouw omgeving het best van dienst te kunnen zijn?
Ja, grote partijen zullen graag iedereen afschepen met patches, zonder details te vertellen, maar als ze in eerste instantie veilige software zouden maken, deze uitkristalliseren voordat ze het gaan verkopen, en default configuraties dummy proof maken, dan zouden zij uberhaupt niet geregelt voor schut worden gezet.
Hoe zou de wereld eruit gezien hebben online indien default overal uRFP aan had gestaan?
Originally posted by
Als dit door het security wereldje ook zo wordt gezien, is de hek van de dam.
"If you hire us, then we tell you which bugs we know about"
Degene die deze achtelijke ideeën verzinnen zullen op den duur aan het kortste eind trekken, ongeacht dat er structureel minder schade aangericht wordt door scriptkiddies, zullen er vroeg of laat criminelen opstaan met de -financieële- middelen.
Tijd zal uitwijzen of we wellicht niet beter uit waren met onnozele defacers, waardoor op termijn de schade beperkter zou zijn geweest, dan die door georganiseerde misdaad gepleegt zou kunnen worden.
mvg,
[email]anonymouse@securitydatabase.net[/email]
Als dit door het security wereldje ook zo wordt gezien, is de hek van de dam.
"If you hire us, then we tell you which bugs we know about"
Degene die deze achtelijke ideeën verzinnen zullen op den duur aan het kortste eind trekken, ongeacht dat er structureel minder schade aangericht wordt door scriptkiddies, zullen er vroeg of laat criminelen opstaan met de -financieële- middelen.
Tijd zal uitwijzen of we wellicht niet beter uit waren met onnozele defacers, waardoor op termijn de schade beperkter zou zijn geweest, dan die door georganiseerde misdaad gepleegt zou kunnen worden.
mvg,
[email]anonymouse@securitydatabase.net[/email]
gerrie, je vindt het zeker jammer dat je daardoor niet meer zo makkelijk aan je 0days kan komen
Originally posted by
gerrie, je vindt het zeker jammer dat je daardoor niet meer zo makkelijk aan je 0days kan komen
gerrie, je vindt het zeker jammer dat je daardoor niet meer zo makkelijk aan je 0days kan komen
0days zijn over het algemeen niet bekend bij security bedrijven en vendors.
Dus daarin verandert toch niets.
Maar men zal zich toch wel zorgen moeten gaan maken over het aantal mensen die door RFC over 'after 0day' informatie beschikken.
mvg,
anonymouse
Originally posted by
bla bla bla.....
Dat lange verhaal met al die fouten in het Nederlandse taalgebruik.
bla bla bla.....
Dat lange verhaal met al die fouten in het Nederlandse taalgebruik.
Tuurlijk moet je zelf proberen om je netwerk te verdedigen en nooit blindelings vertrouwen op wat leveranciers zeggen zonder zelf na te denken.
Daar gaat de RFC niet over....
Ik denk dat meer als de helft van de lui die hier zo hard schreeuwen dat gaten eerst openbaar gemaakt moeten worden en er daarna leveranciers pas met patches moeten komen onder de groep 'hackers, crackers en scriptkiddies' geschaart kunnen worden.
Hier volgt de inhoud van een mailtje wat ik vorige week probeerde te sturen naar anonymouse (zie verder terug in de discussie).
###################################
Misschien is het handig om de discussie even wat gestructureerder te houden. Nu zijn het argumenten op argumenten en dat houdt nooit op natuurlijk ;-)
De eerste vraag is denk ik of het in principe fout is om te proberen om best practises te regelen in een standaard, gedragdscode of wat dan ook.
Mij lijkt dat dit op zich geen verkeerd streven is.
Zover mij bekend is het nu toch ook gebruikelijk als een goedgezinde hacker een bug of gat ontdekt, dit eerst meld aan de fabrikant en de fabrikant minimaal enige dagen de tijd krijgt om een patch of workaround te bouwen en pas daarna de bug meldt op (bijv.) bugtraq. De fabrikant zal waarschijnlijk gelijktijdig het bestaan van de patch bekend maken. Dit is ook globaal wat er in het voorstel voor de RFC wordt gemeld.
Ben je een oplettende systeembeheerder of security officer, dan zul zorgen dat de kans dat je door een evt. exploit 'geraakt' wordt a) inschatten (risk management) en b) proberen zo klein mogelijk te houden. Bijvoorbeeld door zo snel mogelijk de patch te gaan testen of bepaalde functionaliteit tijdelijk uit te schakelen. In veel organisaties (die evt. ook volgens ITIL werken) is het toegestaan om emergency patches met slechts beperkt testen door te voeren in productie, gevolgd door een 'after-change' traject.
Loopt het proces op deze manier dan is er dus niet zoveel aan de hand. Hebben we echter te maken met een kwaadwillige cracker die een bug of gat vind, dan zal die dit waarschijnlijk of 1) zelf gaan uitbuiten of 2) bekend maken aan de hele wereld. Nu heb je het als systeembeheerder wat moeilijker. Situatie 1 kun je niks tegen doen, want dit weet je dus niet. Pas als je systeem gecomprimeerd wordt, of hopelijk net daarvoor zullen misschien je IDS systemen iets waarnemen en alerts afgeven en de hack blokkeren of moet je zelf de cracker blokkeren. In het ergste geval merken zelfs de IDS systemen het niet op en kom je er te laat achter (als je erachter komt). Of in situatie 1 worden systemen van anderen gekraakt en komt het nieuws op die wijze in de wereld, maar dat komt eigenlijk neer op situatie 2. Bij situatie 2 zul je weer goed risk management moeten toepassen: Hoe groot is de kans dat jouw systemen worden gecompromiteert? Moet je er gelijk wat tegen doen of heb je de tijd om op een patch te wachten?
Hier mis ik toch niks? Volgens mij heb ik elke situatie die kan ontstaan (en zal ontstaan) afgedekt.
Zoals je misschien is opgevallen heb ik het nog niet gehad over 'vrijheid van meningsuiting'. Iedereen is mijn verhaal vrij om te doen wat hij of zij wil. Maar zo werkt het niet binnen een commerciele organisatie. De organisatie verlangt van haar systeembeheerder of security officer dat ze die maatregelen treffen die kost-effectief zijn. Vervolgens zoeken ze leveranciers die het beste product voor de beste prijs leveren met daarbij de beste support en voor de beste kwaliteit (hierbij hoort ook het voldoen aan allerlei ISO en RFC standaarden).
Groeten
Originally posted by
Hier mis ik toch niks? Volgens mij heb ik elke situatie die kan ontstaan (en zal ontstaan) afgedekt.
Hier mis ik toch niks? Volgens mij heb ik elke situatie die kan ontstaan (en zal ontstaan) afgedekt.
Je sluit -net als de wetgever- zaken uit met deze stelling.
Iets wat op zich al een risico is.
Originally posted by
Je sluit -net als de wetgever- zaken uit met deze stelling.
Iets wat op zich al een risico is.
Je sluit -net als de wetgever- zaken uit met deze stelling.
Iets wat op zich al een risico is.
Geef maar aan welke situatie ik dan uitgesloten heb.....
Kom eens met een gedegen argumentatie in plaats van een hoop geschreeuw en weinig wol!
Originally posted by
Geef maar aan welke situatie ik dan uitgesloten heb.....
Kom eens met een gedegen argumentatie in plaats van een hoop geschreeuw en weinig wol!
Geef maar aan welke situatie ik dan uitgesloten heb.....
Kom eens met een gedegen argumentatie in plaats van een hoop geschreeuw en weinig wol!
Ten eerste op basis van wat wil jij je security analyse doen?
Op een vage melding van Cert dat SNMP lek is?
Of op basis van feitelijke technische gegevens, waarmee je daadwerkelijk de risico's voor je organisatie in kaart hebt?
Ten tweede in gevallen van onverziene situaties, zoals gevallen dat je verbinding plat ligt. (zonder duidelijk te weten waarom)
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
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?