Alliantie bedenkt standaard voor waarschuwing bij bugs

Een aantal technologiebedrijven zijn afgelopen week bij elkaar gekomen op de RSA conferentie in Californie, om samen een alliantie te vormen die een standaard gaat bedenken voor het waarschuwen bij gevaarlijke beveiligingslekken. De door hen gevormde Organization for Internet Security (OIS) wil hiermee het publiek en software leveranciers beschermen tegen het uitbreken van grote virussen, zoals bijvoorbeeld Nimda. Deelnemers aan deze organisatie zijn onder andere: Microsoft, Sun Microsystems, Hewlett Packard, Compaq en Cisco. Het voorstel wat nu op tafel ligt gaat uit van 10 dagen response tijd en 30 dagen om het probleem te verhelpen:

Security bugje A proposal submitted to the Internet Engineering Task Force by researchers at the MITRE Corp. and AtStake Inc., which was released on Wednesday, recommended giving vendors 10 days to respond to reports of vulnerabilities and 30 days to fix them.

For vendors with different versions of their products that work on multiple platforms, writing and testing patches takes time, Chris Wysopal, director of research and development at AtStake and a co-author of the proposal, said on Friday.

Lees verder bij Reuters of bij ZDNet.

Door Gabi Gaasenbeek

24-02-2002 • 11:03

14

Bron: Reuters

Reacties (14)

14
12
9
5
0
0
Wijzig sortering
..recommended giving vendors 10 days to respond to reports of vulnerabilities and 30 days to fix them. ...

Reken maar dat het dan al veels te laat is
zon virus/worm heeft dan al goed om zich heen geslagen .... maarja het is een begin ..
iig komen er dan fixes :)
Nee, je snapt 't niet :)

Bij voorgaane worms waren er al lang patches beschikbaar gesteld door Microsoft, maar die werden gewoonweg niet geinstalleerd door systeembeheerders. Het idee van deze groep is gericht op de tendens die de laatste tijd op beveiligings-mailinglists popupair is.

Wat men daar doet is direct alle details van bugs openbaar maken zonder dat er tijd gegeven wordt aan de maker van het programma om de bugs te fixen. Wat deze groep nu wil is dat er een standaard gesteld wordt: geef de maker 10 dagen om te antwoorden en 30 dagen om het probleem op te lossen. Stuur dan pas, als de fix al te downloaden is, alle details naar een mailinglist.

Geen slecht idee, IMHO
<quote>
Reken maar dat het dan al veels te laat is
zon virus/worm heeft dan al goed om zich heen geslagen .... maarja het is een begin ..
</quote>


Het gaat hier om het oplossen van nieuw ontdekte bugs , een soort ere code tussen bughunters en softwarebedrijven ( die er nu veelal vele maanden er over doen om patches uit te brengen) om zodoende te voorkomen dat worms die gebruik maken van dit gat de kans krijgen zich te verspreiden. In het verleden is gebleken dat virus schrijvers vrijwel altijd gebruik maken van gaten in software die ze niet zelf hebben ontdekt
Wel beetje naief om te denken dat dit de enige alliantie is waarbij Sun en Microsoft samenzitten. Nagenoeg elke open standaard wordt door een consortium beheert en daar zitten meestal erg grote bedrijven zoals Sun en Microsoft in.Dat wil helemaal niet zeggen dat ze daarbuiten geen rechtszaken ofzo tegen elkaar kunnen aanspannen, of meningsverschillen mogen hebben.
plus dat in de groepen welliswaar MS en Sun bij elkaar zitten (vergeet trouwens IBM en SGI niet), maar dat zijn veelal techneuten, niet de pakken / managers. En die techies kunnen veel beter met elkaar opschieten dan Managers dat kunnen. :)
humm... 't moet toch in veel gevallen veel sneller kunnen dan 30 dagen? Het lijkt mij dat als er een flink lek is gevonden, dat ze binnen 3 a 4 dagen een patch kunnen uitbrengen.
Trouwens, hoe wordt zo'n beveiligings lek nou gevonden? Als ze mazzel hebben door iemand die er z'n brood mee verdient, als ze pech hebben door iemand die virussen schrijft en uitbrengt... en in dat geval hebben ze alsnog een probleem.
Probleem met patches is dat je vaak binnen een paar dagen de eerste oplossing hebt, maar je daarna nog een paar weken aan het testen bent of het werkt.
Op een standaard machine, zonder rare fratsen werken veel dingen prima, maar zodra je andere drivers erop hebt staan, een andere architectuur of een net iets andere windows release krijg je al verschillen die de zaken soms nog veel erger kunnen maken.

Programeren is 1, het testen is vaak een heel andere zaak. Anders blijf je elke week een patch uitbrengen voor de patch van de week ervoor.
Tip: baseer die standaard op XML
Deze tip wordt wel wat laag beoordeeld met een overbodig (indien niet veranderd).

Het is namelijk best een idee om eens over de technische aspecten van deze standaard en waarschuwen in het algemeen na te denken.

In de theorie is het zo dat de meeste bugs/gaten snel worden gemeld bij een leverancier, deze een patch uitbrengt en afnemers hun systemen weer up-to-date kunnen maken.

Praktijk is zo dat niet alles de fabrikant (tijdig) bereikt, de fabrikant niet altijd direct het gevaar onderkent, de afnemer niet op de hoogte is van wat wel is onderkent en gepatched kan worden en tot slot van de onderkende te laat of niet een change wordt gemaakt (hopelijk dan ook nog goed uitgevoerd).

Een van de problemen is de techniek achter verspreiden van de bug, tijdelijke work-around, de uiteindelijke patch etc.

In grote bedrijven met een scala aan systemen, verdeelde verantwoordelijkheid is het geen uitzondering dat systemen vol gaten zitten (heb zelf te veel voorbeelden gezien in de bank-wereld, niet dat je zegt onbelangrijke systemen).

Een mogelijke oplossing voor de niet te beheren stroom aan informatie omtrent de systemen die naast de dagelijkse werkzaamheden moet worden verwerkt is eens te kijken naar de techniek hierachter. Dit kan ook een belangrijk onderdeel van de standaard zijn.
't Word gezellig met al die afkortingen:

ISO
OSI
OIS

:z
ze zijn de laatste tijd al zoveel met beveiliging bezig, dat ik denk dat ze daar straks als ze er minder mee bezig zijn toch ook snel op kunnen reageren.

Verder zullen er ook wel voorwaarden zijn om bij dat cluppie te horen, zoals als je niet binnen 10 dagen reageert je buitengezet wordt

Op dit item kan niet meer gereageerd worden.