Europol: overheid moet eisen stellen aan beveiliging software

Er moet regelgeving komen om de beveiliging van software te verbeteren; uit zichzelf gaan softwaremakers de beveiliging namelijk niet naar een hoger niveau schroeven. Dat zegt Troels Oerting, hoofd cybercrime bij Europol, in een interview met Tweakers.

"Ik ben geen fan van te veel regulering, maar ik vrees dat je security by design niet kunt implementeren door het bedrijven op een aardige toon te vragen", zegt het cybercrime-hoofd van de Europese politieorganisatie Europol tegenover Tweakers. Security by design betekent dat er bij het bouwen van software al afdoende wordt nagedacht over de beveiliging.

"Er moeten criteria komen en die moeten worden nageleefd", aldus Troels Oerting. "Als je een auto bouwt, zijn er nu strenge veiligheidsregels, maar nog niet als je software op de markt brengt." Overigens zijn er wel al bepaalde certificeringen, bijvoorbeeld voor gebruik in de medische sector of door overheden, maar het is niet verplicht om een certificering aan te vragen.

Volgens Oerting doen de meeste softwarebouwers grotendeels goed werk, maar op het vlak van beveiliging is volgens hem nog veel te verbeteren. "Op dit moment is beveiliging geen argument waarmee je klanten wint", stelt hij. "Bedrijven doen enkel iets als ze er voordeel uit kunnen halen, niet omdat ze zulke goede mensen zijn", aldus Oerting. Daarom moet de samenleving beveiliging eisen van de softwaremakers. Zo moet veilige software een 'stempel' van de overheid kunnen krijgen waarmee de veiligheid is gegarandeerd, stelt Oerting voor.

Oerting vindt verder dat de voorlichting over gevaren op internet, zoals privacy- en beveiligingsrisico's, beter zou moeten. "We lichten kinderen voor over gevaren op de weg en veilige seks, maar we schieten te kort als het gaat om digitale risico's", meent de cybercrime-chef. "Je zou kinderen vanaf een jaar of tien, twaalf de werking van Twitter, Facebook en Gmail moeten uitleggen", meent Oerting. "We moeten ze uitleggen dat niks gratis is en dat Google je persoonlijke informatie gebruikt."

Een probleem daarbij is volgens Oerting dat leraren vaak veel minder digitaal vaardig zijn dan de leerlingen die ze moeten onderwijzen. "Misschien moeten we een app maken om kinderen te onderwijzen", denkt Oerting. "De meeste jonge kinderen zitten ook op tablets en smartphones. Misschien kunnen we ze op die manier bereiken." Oerting benadrukt dat ook andere doelgroepen, zoals ouderen, baat kunnen hebben bij betere voorlichting.

Reacties (62)

[MAX3400]

Ik zit al enige tijd bij verschillende overheden (nationaal en regionaal) en zie nog steeds door de bomen het bos niet meer. Basale security is op veel vlakken niet geregeld en ik vind het dan ook erg vreemd dat we ons nu moeten gaan toeleggen op een veiligere software-omgeving.

Ten eerste is bij een aantal gebouwen de toegang van mensen al niet goed geregeld. Zonder in detail te treden, zijn er 2 ministeries waar je met een beetje inlevingsvermogen al voorbij de receptie/bewaking komt en in ieder geval de eerste draaipoortjes kan passeren. Daarna is het eigenlijk nogmaal dat niemand je nog eens een keer vraagt voor wie je komt of op welke afdeling je moet zijn.

Verder is het beginnende security-beleid zoals inlognamen, wachtwoorden en mogelijk inlog-tokens vaak ook een lachtertje. De uitspraak dat de Post-It notes met user/ww op een monitor hangen, gebeurt nog steeds. En is het niet op de monitor, dan is het wel in het laatje van de secretaresses (want de belangrijke baas is vaker niet op kantoor). En dit geldt gewoon van top to bottom in het spectrum van verantwoording in de organisatie.

En dan komen we eindelijk bij het applicatie-landschap; overheden maken veelvuldig gebruik van onderlinge sites, sites van leveranciers en van software die specifiek door een derde partij is ontwikkeld voor de overheid. Het is hierin ontzettend lastig om een lijn te vinden qua beveiliging; de ene site met gegevens is beveiligd met plain-text, de volgende met een self-signed SSL en de volgende is alleen te bereiken via een VPN ofzo. Ook een aantal externe leveranciers lopen al jaren achter op "best practice"; zo wordt er nog steeds veelvuldig software gebruikt die leunt op JAVA 1.5 en 1.6; beiden zijn door SUN/Oracle allang als onveilig bestempeld en opgevolgd. Ook het gebruik van oudere Windows-versies bijvoorbeeld, zoals XP, wordt volgend jaar echt een uitdaging van geen standaard-support meer van Microsoft maar een vervanging voor deze legacy spullen is nog lang niet geregeld.

Europol weet een mooie stelling te poneren maar de uitvoerbaarheid is bij lange na niet inzichtelijk laat staan te begroten.

[The Zep Man]

Zo moet veilige software een 'stempel' van de overheid kunnen krijgen waarmee de veiligheid is gegarandeerd, stelt Oerting voor.

Veiligheid in software kan je niet (volledig) garanderen. Hierdoor worden onterechte verwachtingen geschept. Verwacht verontwaardigde reacties zodra de eerste 'veilige' software wordt misbruikt door een veiligheidsfout, waarna de reputatie van het stempel ook een duik zal nemen.

Een stempel dat alleen staat voor het gebruik van best practices tijdens de ontwikkeling zou meer toegevoegde waarde hebben. De meeste fouten kunnen voorkomen worden door iets meer middelen te besteden aan de beveiliging en kwaliteit van de code. Ook is de drempel om zo'n stempel te hanteren een stuk lager dan een stempel voor het 'volledig veilig' maken van software.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 21:23]

[Verwijderd]

Overheid en ICT is ook nog eens iets dat eigenlijk niet in een zin past. Hoe gaat de overheid controleren of de schrijvers het goed gedaan hebben? Op basis van procedures of op basis van de broncode?
En los daarvan, met een goedkeuringsstempel van de Nederlandse overheid op een programma kunnen klanten in andere landen scheef gaan kijken naar je programma. Goedgekeurd omdat er een backdoor in zit?

[kidde]

Hoe gaat de overheid controleren of de schrijvers het goed gedaan hebben?

Zoals Google en Microsoft het tegenwoordig ook doen: Loof geldprijzen uit aan degenen die een lek vinden.

Een simpel 3-stappenproces is zo gemaakt:
1) Cruciale onderdelen als cryptografie-modules / implementaties moeten altijd open source zijn, anders gebruikt de overheid ze niet meer

2) Degenen die er een lek in vinden kunnen anoniem blijven en 'winnen' een geldbedrag (dan kunnen NSA-werknemers leuk stiekem bijbeunen door lekken die de NSA heeft gevonden te melden zodat ze gedicht kunnen worden; want nu pompt de NSA er miljarden in en de rest van de wereld bijna niets),

3) Kosten voor software prestatie-afhankelijk maken:
De software-fabrikant krijgt een bonus; maar per ongepatchte lek per dag met weegfactor ernstigheid gaat er een bedrag van de bonus af.
Dit om ervoor te zorgen dat luie bedrijven geen dag wachten met het dichten van veiligheidslekken, zoals ze nu onder smoesjes van "patch Tuesday" vaak doen, natuurlijk een idioot gegeven. In de auto-industrie gaat degene die software maakt voor airbags echt niet drie weken fouten verzamelen, ondertussen gewoon doorproduceren en dan in week 4 de fix vrijgeven, dan waren ze al lang kapot geprocedeerd.

Daar geldt productaansprakelijkheid: Op basis van de Productaansprakelijkheidsrichtlijn is de producent aansprakelijk voor schade veroorzaakt door een gebrek in of aan zijn product. Iets dat de politiek wil, maar software-leveranciers al lang uitgesteld hebben met 'dikke boehoe wij zijn zo anders dan andere bedrijven wij kunnen dat niet'.
Software en de kwaliteitsprocessen hoeven niet gelijk perfect te zijn, maar begin er potsamme eens gewoon mee in plaats van inferieure producten te blijven leveren waarvan je weet dat er gebreken inzitten!
Alle bullshit in de EULA's over "Wij zijn niet verantwoordelijk voor fouten in onze software" zou de politiek gewoon een dikke streep doorheen moeten zetten, als jij op je werk niet verantwoordelijk bent voor fouten die je maakt kan je als chirurg ook rustig met een kater een operatie doen terwijl je een bakje koffie drinkt.

Het kan wel degelijk: Als NASA software kan maken voor de bemande ruimtevaart, dan moeten bedrijven met veel meer geld (voor software) als Adobe en Oracle toch ook wel een keer een versie van Flash / Java kunnen opleveren die niet zo lek als een mandje is? Het zit hem vooral in mindset: Van de NASA wordt niet geaccepteerd als ze brakke software leveren, van allerlei andere prutsers - zoals Adobe dus bijvoorbeeld en Sun in het verleden - wel.

Kleine bedrijven / vrijwilligers-projecten hoeven zo niet altijd de dupe van kwaliteits-eisen te zijn, OpenBSD heeft bijvoorbeeld maar 2 veiligheidslekken in de default install gehad die binnen enkele dagen waren gefixt. Het Tor-protocol is kennelijk nog steeds niet gekraakt door de NSA, vandaar dat ze het via de webbrowser proberen. Niet echt twee grote / rijke projecten die het toch prima doen, juist vanwege hun aandacht voor veiligheid. Als zij het beter doen dan Adobe en Sun (nu Oracle), dan leveren die laatsten een wanprestatie van letterlijk Fyra-achtige proporties.

Wat er verder nog gedaan kan worden, is hetzelfde als in de 'fysieke' industrie, namelijk Audits.

• Laat maar zien wat je kwaliteitsproces is.
• Toon maar dat je regelmatig preventief je code bij langs gaat om unsigned ints te vervangen door signed ints (alleen bij low-level spul maar toch).
• Vertel maar hoe je iedere maand je software bij langs gaat en ongebruikte code eruit smijt, en code zoveel mogelijk per groep sorteert en uit-factoriseert.
• Bewijs maar dat je proces er op gericht is de software steeds minder lijnen code te laten zijn, en dat je programmeurs niet betaalt voor het aantal regels dat ze schrijven, maar kwaliteit meeneemt.
• Wijd maar eens uit over hoe je intern een aantal programmeurs betaalt om fouten in de code van andere programmeurs te vinden (en ze daarvoor bonussen geeft?)
• Leg maar eens uit welke interne regels er zijn voor software-documentatie, en dat dit niet slechts een 'nagedachte' is

Met andere woorden: Er valt zat te doen.

Consumenten zijn verder echt niet dom, die snappen ook best wel dat je in een 5-sterren EuroNCAP test een dodelijk ongeval kan krijgen als je zonder gordel met 90 per uur tegen een betonnen muur van een tunnel rijdt. Als je alle voorschriften echter naleeft, is het gemiddeld genomen echter veel veiliger en de kans dat het misgaat kleiner: Daar moet zo'n stempel om gaan!

[Reactie gewijzigd door kidde op 24 juli 2024 21:23]

[H!GHGuY]

Mooi verhaal. Je mist maar 1 ding: zin voor realiteit.

De reden waarom de NASA zoveel uitgeeft aan kwaliteit (en niet aan security, trouwens) is omdat, wat ze doen:
- zeer duur is voor zichzelf. Elke fout kost de NASA miljoenen
- high-profile. Iedereen ziet hun fouten
- over mensenlevens gaat
De kwaliteit voor de lancering van een 13-in-een-dozijn satteliet is dan ook een stuk minder dan die voor een bemande vlucht.

Bij pakweg Adobe/Oracle producten:
- wordt de kost van fouten nauwelijks door hen gedragen
- zijn slechts een fractie van de fouten high-profile en überhaupt gekend
- hangen er meestal niet rechtstreeks mensenlevens vanaf

Software is trouwens craftsmanship. Hoe je het ook draait of keert, het is en blijft maatwerk. In het goede geval heb je een API die je uitvoerig kan testen, in het beste geval heb je een gestandaardiseerde API die je kan testen.
En net zoals in de auto-industrie is je kwaliteit maar zo goed als je testen.

Ik kan hier nog wel even doorgaan met argumenteren op jouw betoog, maar de tijd ontbreekt me helaas.

[LopendeVogel]

Nou nou, overheid en ICT gaat wel degelijk samen hoor. Dit in tegenstelling tot veel andere bedrijven waar de ICT 9 van de 10 keer op een laag pitje staat, zie je dat bij de overheid de budget vergrotingen steeds verder worden uitgebreid. En de automatisering een steeds belangrijker punt word bij overheid instellingen.

Uiteraard dien je ook rekening ermee te houden dat de overheid de meeste aanvallen te verduren heeft.

Verder ben ik het weleens met de reactie van The Zep Man, het is moeilijk om de veiligheid te garanderen, dat hebben we vaak genoeg gezien de laatste jaren.

[TheCapK]

Vergroten van budgeten is niet per se een positief punt. Zeker als je ziet dat er weinig kritisch wordt gekeken naar wat er voor het geld wordt geleverd.
Dat er in de bedrijfssector meer in mag worden geinvesteerd kan wel kloppen mar domweg meer geld erin pompen omdat het dan beter zou worden is ook onzin. Zeker bij de overheid mag er wel eens veel kritischer worden gekeken naar de randvoorwaarden die worden gesteld aan de ICT oplossingen, denk hierbij maar aan het EPD en alle schandaaltjes die hiermee naar voren kwamen. Is ook miljoenen in gepompt en niet ingevoerd. Jammer van al dat geld!

[xleeuwx]

Grootste probleem van EPD was niet de software maar dat diegene die het moest presenteren er weinig tot niks van af wist en de vragen over de beveiliging niet kon beantwoorden. Daarnaast is het door meerdere bedrijven gemaakt en zaten er daardoor gewoon te veel lagen in het project. Oftewel de software was niet het probleem maar de communicatie.

[Reactie gewijzigd door xleeuwx op 24 juli 2024 21:23]

[kramer65]

zie je dat bij de overheid de budget vergrotingen steeds verder worden uitgebreid.

Probleem is dat budgetvergroting niet per se sucesvollere IT tot gevolg heeft. Niet alleen kunnen overheden moeilijk inschatten welke van de bedrijven nou daadwerkelijk beter is ("wij doen de security héél goed, vandaar de hoge prijs" , "jamaar wij doen de security nóg beter, vandaar de nog hogere prijs" ), het grootste probleem is dat een overheid niet afgestraft kan worden door de markt. Wanneer een marktpartij zijn zaakjes niet op orde heeft kan hij failliet gaan en verdwijnen (zie DigiNotar), wanneer een overheid zo lek als een mandje is, komt er gewoon een ander IT-bedrijf voor in de p'aats: "jamaar wij doen de security perfect, vandaar de superhoge prijs!").

Beter kan de overheid zich bezighouden met het geven van incentives aan het publiek om lekken te vinden. Dan krijgen partijen namelijk pas betaald naar prestatie. Meer lekken oplossen => meer geld verdienen. Als je het IT-bedrijf dat ingehuurd wordt door de overheid dan (grotendeels) verantwoordelijk maakt voor het geld wat gegeven moet worden aan vinders van publieke lekken, dan zul je eens zien hoe hard ze gaan zoeken..

[tweaknico]

Het is niet moeilijker om beveiling te implementeren als welke andere functie binnen een project.
MAAR: het moet niet achteraf!!!!!!

Functionele wijzigingen aan het eind van een ontwikkeltraject kosten nu eenmaal meer dan zaken waarmee wel rekening gehouden is.

En het gebruik van externe libraries moet natuurlijk ook meegenomen worden.

[Ayporos]

JeroenC wat een prachtige post is dat toch die je daar plaatst!

Je weet in 1 post precies en duidelijk vorm te geven aan de onbekwaamheid van de Nederlandse Overheid!

"bij de overheid de budget vergrotingen steeds verder worden uitgebreid."
Iets niet goed? smijt er meer geld tegen aan!
"de automatisering een steeds belangrijker punt word bij overheid instellingen."
Je bedoelt zoals de opdracht een informatieuitwisselingsprogramma te maken wat vervolgens na vele jaren 'ontwikkeling' als onacceptabel geacht wordt (omdat er tijdens ontwikkeling geen sturing was) en ze het hele ding schrappen? (maar al het geld is uiteraard al weg)

Of je doelt wellicht op dat schandaal wat een tijdje terug naar buiten kwam dat ze bij het OM miljoenen voor onderhoud van workstations betaalden terwijl dat allemaal accounts van ex-medewerkers waren????

Dàt is hoe de overheid ons land runt.
De overheid werkt met geld en budgetten, nìet met problemen en oplossingen.
Hun 'oplossing' voor een probleemsector is er meer geld heen smijten en hopen dat het zichzelf daarmee oplost. Heel hun wereld draait om geld en als jij Mark Rutte zou vertellen dat je sommige problemen niet met geld/budgettering kunt oplossen zou hij je aankijken met een nog stommere blik dan die kerel doorgaans al heeft.

Het ergste is nog wel dat de efficiency van gespendeerd geld bij de overheid ABOMINABEL slecht is. Tja dat krijg je als je in 'miljarden' en 'miljoenen' werkt.
Dan is het al snel: "Och we hebben een programma nodig om wat gegevensuitwisseling te automatiseren.. hoe klinkt 50 miljoen? prima? ok dan!"
Terwijl zo'n dergelijk programma in de commerciële sector voor 10k tot 100k ontwikkeld zou kunnen worden (afhankelijk van hoe streng je eisen zijn).

Er is geen commerciële druk bij de overheid... ze schuiven gewoon met budgetten en als er niet genoeg geld is dan flikkeren ze gewoon de belasting omhoog. Er is geen urgentie om te 'presteren' omdat wij het volk toch wel moeten slikken wat zij verkopen of we het nou willen of niet.

[Reactie gewijzigd door Ayporos op 24 juli 2024 21:23]

[LopendeVogel]

Ja dankjewel, jij maakt ook een prachtige post hoor!

In de afgelopen jaren, wanneer er hacks vielen en etc bij de Nederlandse overheid hoorde je ELKE tweaker zeggen: Ja moeten ze nog meer bezuinigen op de automatisering of: ja moeten ze nog meer de it afdeling in een donker hoekje zetten.

Het gaat erom, tot ze dat flink aan het verbeteren zijn, en ze niet meer de automatisering weg bezuinigen en de IT afdeling in een donker hoekje plaatsen. Nee hun krijgen steeds meer prioriteit.

Kan jij het met mij oneens zijn, omdat jij vind van niet of dat er teveel geld ineens erin omgaat... Maar dat heeft niks te maken met het punt wat ik aanhaalde.

[Ayporos]

Dat ze het een belangrijk(er) punt vinden kan ik alleen maar toejuichen.

Probleem is echter met IT dat ze niet weten waar ze het over hebben. We hebben het hier over economen en politici die denken in hele andere begrippen dan waar de IT zich mee bezig houdt.

Kijk een rekensommetje om een budget voor de verbreding van een snelweg op te maken welke congestie moet bestrijden daar kunnen zulke mensen nog wel met hun hoofd bij.. automatisering, integratie en veiligheid op IT gebied is iets waar zij niet 1 2 3 een prijskaartje aan kunnen hechten met als gevolg dat ze al snel ja zullen knikken of hun ingehuurde 'expert' nou een kostenplaatje opmaakt van 1 of van 10 miljoen euro.

IT is wellicht een van de minst rendabele investeringen waar de overheid de afgelopen jaren geld aan heeft gespendeerd. Meer geld er tegen aan gooien zou dus enkel betekenen dat het totale rendement van overheidsbudgettering nòg verder zou kelderen... tenzij ze plotsklaps verstand zouden hebben gekregen van IT, wat mij zeer onwaarschijnlijk krijgt als ik zo de gemiddelde leeftijd van die ministers en politici zie.

[kramer65]

Daarbij komt ook nog dat ik aan mag nemen dat een dergelijke stempel geld kost om te krijgen. Veel open source software zal dan wel buiten de boot vallen..

De groten in de open source wereld zullen dat nog wel kunnen bekostigen (Linux, Apache etc.) maar veel kleinere projecten, of zelfs simpele tooltjes zullen dit zeker niet verkrijgen. Krijg je dan de situatie dat een softwareproject alleen maar "gestempelde" software mag gebruiken, en daardoor geen kleine (=overzichtelijke) libraries kan gebruiken?

[Reactie gewijzigd door kramer65 op 24 juli 2024 21:23]

[tweaknico]

Waarom moet bij open source het project deze controle's bekostigen?

Bij closed source draait de producent natuurlijk voor de kosten op dat is de keuze van de producent
Open source zou regelmatig gecontroleerd kunnen worden door onafhankelijke instuten, als tegen prestatie voor het vrijelijk beschikbaar stellen van software...
Van veel projecten zou een LTS versie van een dergelijk stempel voorzien kunnen worden.

[SirBlade]

Ik denk zelfs dat de grotere OS projecten een probleem gaan krijgen bij verplichte certificering. Zodra de code wordt aangepast zal er een nieuwe certificering plaats moeten vinden. Dus alle projecten die vaak updates uitbrengen zoals chrome, Firefox en de Linux kernel zullen enorme kosten gaan maken voor de verplichte certificering.

[veltnet]

Het is uiteindelijk altijd de opdrachtgever die hier voor moet betalen omdat testen uitgevoerd moeten worden op de infrastructuur van de opdrachtgever.

[MSalters]

Wie zijn de opdrachtgevers van Windows, Linux, of Google Search ? Jouw model gaat alleen over software op bestelling, en dat is sowieso een aparte markt.

[veltnet]

De gebruiker is de opdrachtgever. Als jij garanties wil dan zul je dat zelf moeten regelen/betalen. De leverancier kan niet instaan voor de inrichting van jouw infrastructuur, daar blijf je altijd zelf verantwoordelijk voor.

Ook al is de software goed en getest. Je kun altijd een configuratiefout maken waardoor de boel zo lek is als een mandje.

[Reactie gewijzigd door veltnet op 24 juli 2024 21:23]

[MSalters]

Dus jij denkt dat 200 miljoen consumenten in Europa de opdrachtgevers van Microsoft zijn, en zelf verantwoordelijk? Dat is geen werkbaar model.

[veltnet]

Dat is de praktijk. Lees de licentievoorwaarden maar door. Microsoft is niet verantwoordelijk. Hetzelfde geldt voor open source software, de leverancier is niet verantwoordelijk voor schade die veroorzaakt wordt door de software.

[kramer65]

Ik vertel dit nieuws zojuist aan mijn Russische collega hier op t werk.

Hij: "Yes, I totally agree. Software should be certified by the government, especially by the people who know about it; the AIVD, GHCQ, NSA, etc. This stamp should also include a chip so that the certificate cannot be forged."

[pibara]

"EURO"pol != "Nederlandse" overheid

[bonus]

Een foutje in een beveiliging is ook zo gemaakt, je kunt gewoon weg niet alle mogelijke scenario's testen. Als je dat wilt doen komt er geen stukje software meer uit. Hoeveel patches zijn er niet nodig geweest om b.v. Explorer dicht te timmeren en hoe vaak horen we niet dat er toch weer een exploit is gevonden. Hoe ingewikkelder de software hoe moeilijker het is om alle mogelijkheden voor "fout" gebruik te vinden. En zeker als die software dan ook nog eens op een systeem staat dat toegang heeft tot een extern netwerk dan is het nagenoeg onmogelijk om 100% te garanderen.

[tweaknico]

Je hoeft niet alle scenario's te testen als van van de grond af aan goed ontwerpt.

bv.
a) Een string is een reeks tekens van een bepaalde lengte die ergens in het geheugen begint....
b) of een string is een reeks van tekens die in het geheugen begint en met een verboden teken eindigd.

Welke van de bovenstaande geeft minder kans op "missers"...
a is inherent veiliger, maar vereist het bijhouden van wat extra info (lengte) bij een string t.o.v. b. Maar bij a is de kans op een string overflow kleiner.
bij b is het uitgangspunt dat content een bepaald teken bevat dat niet als content kan worden verzonden, helaas blijkt dat een lastig oplosbaar probleem.

Dus laten we de C-runtime library eens beginnen op te ruimen... Alle strcpy etc. weg, en uitsluitend nog strncpy..., zelf functies schrijven die ook zo werken en ALLE parameters die aangeleverd worden zorgvuldig controleren. Of beter, alle strings beschrijven met startadres + lengte in een structure.
Op dat moment heb je een fundament + mindset om zaken goed aan te pakken...

O wacht we hebben zo'n OS & Runtime al, sinds 1978 bestaat OpenVMS dat op die leest geschoeid is... Vrijwel alle bugs die gevonden zijn op het vlak van beveiliging kwamen uit de IP tooling (finger, ntpd etc) hoek, en dat zijn stukken software die uit Tru64 overgenomen zijn.

[MSalters]

En de feitelijke opvolger van OpenVMW, Windows NT gebruikt dezelfde strings. Niet zo geweldig overtuigend.

Wat betreft het "weghalen" van strcpy, dan breekt vrijwel alle bestaande C code en is dus volkomen onhaalbaar. Niet dat het veel zou uitmaken: je introduceert in feite een nieuwe taal op basis van C, met een stringtype gelijk aan C++. Waarom zou iemand jouw nieuwe taal kiezen en niet C++? Tenslotte is C++ na 15 jaar behoorlijk volwassen.

[D-Three]

Dat was wat ik ook dacht toen ik het artikel las.

De vergelijking met auto's door mijnheer Oerting gaat volgens mij dan ook niet op. Je kan bepaalde eisen stellen aan het ontwerp van een wagen maar dat zie je tenminste. Testen kan je ook gemakkelijk, denk maar aan crashtesten. Bij software liggen zo'n zaken volgens mij iets moeilijker? De broncode ontleden?

Uiteraard heeft hij wel een punt, veiligheid zal van ondergeschikt belang blijven zolang het niet verplicht wordt. Enkele algemene richtlijnen/verplichtingen kunnen daarbij helpen. Maar het maakt daarmee de software nog niet veilig.

[Reactie gewijzigd door D-Three op 24 juli 2024 21:23]

[VisionMaster]

Software crashtesten heet in de beveiligingswereld pentesten. En dat kan op verschillende niveaus, met verschillende diepgang. En hier kan je regeltjes omheen bouwen. Verplichte pentest (lees: niet een papieren audit).

[Verwijderd]

Je pakt één ding uit het bericht en geeft terecht je kritiek. Een garantie kan er nooit zijn. Hoe kan een overheid garantie bieden terwijl haat eigen geheime dienst zichzelf wel de mogelijkheid geeft te hacken?

Maar de rest van wat de man zegt vind ik terecht. Met name: ""Bedrijven doen enkel iets als ze er voordeel uit kunnen halen, niet omdat ze zulke goede mensen zijn", aldus Oerting.

Wie denkt het daarmee oneens te zijn mag reageren.

[elmuerte]

Ik heb het idee dat Oerting geen idee heeft wat het in houd om software te ontwikkelen.
"Security by design betekent dat er bij het bouwen van software al afdoende wordt nagedacht over de beveiliging."

Dat is echt zo'n enorm onzin statement. Wat is "voldoende"? Wat is uberhaupt "security"? Gaat het om autorisatie? authenticatie? over software fouten? of gaat het over data security?

Als de overheid eisen gaat stellen aan software heeft dat 3 effecten:
- software wordt substantieel duurder
- kleine software bedrijven verdwijnen wat die hebben niet het kapitaal om "veilige" software de produceren
- allen grote open source projecten (die ondersteuning vanuit bedrijven hebben) zullen overblijven

[Verwijderd]

Daar zijn al wel evaluatie methoden voor ontwikkeld en die worden ook wel gebruikt, bijv. de common criteria (http://www.commoncriteriaportal.org/). In feite stel je security functional requirements (welke veliigingsfuncties zitten er in) op en assurarance requirements (hoe zeker wil je weten dat de functies ook doen wat ze zouden moeten doen). En er worden 7 levels van assurace (EAL) onderscheiden Op zich werkt dat best aardig. Iig weet je redelijk wat je krijgt qua functionaliteit en het heeft een zeer degelijke systematiek. Nadeel is wel een duur en langdurig proces is vooral als je ontwikkelingsproces niet is afgestemd met de CC systematiek. Verder is de evaluatie t/m 4 vooral een papieren exercitie, op zich wel nuttig. Let wel Redhat Linux en een aantal Windows varianten zijn ook EAL 4, maar veelal onder zeer strikte gebruikscondities. Maar pas bij >= 5 wordt het echt waardevol voor de afnemende klanten. Vooralsnog is het vooral gebruikt voor compacte systemen zoals smartcards en sommige specifieke security producten als VPN's enzo. Voor complexe producten, en zeker als er ook veel legacy is, is het zeer complex om dit uit te voeren en >= level 5 vrijwel ondoenlijk.

Maar op zich heeft die Oerting wel een punt, voor vele producten worden allerlei veiligheids (safety) eisen gesteld, maar voor software kan elke prutser wat in elkaar kleien en voor je het weet is het zo maar bedrijfskritisch geworden. En de afnemer die geen ICT specialist en al helemaal geen Security specialist kan het niet of nauwelijks beoordelen of inschatten. Eenvoudig beginnen lijkt me het credo hier met wat eenvoudig te toetsen eisen. Er zijn bijv helaas nog ontzetten veel systemen die wachtwoorden e.d. gewoon als platte tekst opslaan.

[tweaknico]

Nu is het ruim onvoldoende.
ALS beveiliging ter sprake komst is het vrijwel overal dat regelen we op een ander niveau...
maar dat "andere niveau" weet vaak helemaal niet dat er iets beveiligd moet worden.

Kijk naar PLC's ... die hangen NOOIT aan het internet dus beveiliging HOEFT NIET....
alleen hangen er veel polder pompstations WEL aan het internet omdat het op die manier GOEDKOPER is om ze OP AFSTAND te beheren. [ huurlijnen zijn zo duur ].
Ik geloof dat er een kern centrale/opwerkings fabriek in iran ook al problemen had met PLC's...

Dus aandacht voor details VANAF het begin zullen uiteindelijk voor minder problemen gaan zorgen maar voordat de ICT zo volwassen is .. dat zal nog even duren vrees ik.

[BoringDay]

Dan komt men er snel achter dat software 2 tot 3x zo duur gaat worden.
Het OS hoort zelf te zorgen voor veilig verbinding met internet en niet als lapmiddelen per losse applicaties.

[xFeverr]

Het os moet helemaal niks regelen. Het moet slechts een goed platform zijn. zelf je beveiliging opzetten, dan weet je ook precies hoe het in elkaar steekt

[BoringDay]

Ik deel de mening dus niet.
Als de beveiliging probleem op OS niveau ligt dan is daar de kern waar het probleem aangepakt moet worden en niet bij derden.

Ze verkopen ook het OS met de stempel als veilig dan mag het niet zo zijn de consument nog eens een Firewall en antivirus pakket moet kopen. Ook dient dit probleem niet naar derden worden afgeschoven.

Plus het feit dat pleisters niet de wonden helen. Een probleem los je op bij de kern en niet 5 a 10 lagen verder op dan ben je verkeerd bezig met ontwikkeling.

[xFeverr]

je hebt het over firewall, antivirus, etc.

Dit is denk ik niet het type beveiliging of beveiligingsissues die ze bedoelen. Deze zaken moet je als applicatie ontwikkelaar idd niet zelf bouwen voor je applicatie.

ps. Windows firewall en Windows Defender(win8) zitten in het OS als firewall en virusbescherming. (Microsoft Security Essentials voor win7, winXP als gratis download)

[Reactie gewijzigd door xFeverr op 24 juli 2024 21:23]

[BoringDay]

Je hebt gelijk maar in feite is een virusscanner geen antwoord voor een oplossing tegen virussen. De aanpak is te ouderwets en al bewezen dat het ineffectief is.

Maar ook problemen als SQL injecties die problemen horen opgelost te worden in de SQL server en niet in software van derden wat onnodig extra tijd vergt maar ook veiligheidsrisico's verhoogd.

Maar versleutelingen, in feite horen hiervoor gewoon standaard API's in het OS te zitten dat een ontwikkelaar dat eenvoudig kan integreren i.p.v. allerlei extra onnodige handelingen.

Zo zijn er nog wel tal van dingen die bij de kern aangepakt kunnen worden.
En hoe dichter je een probleem bij de kern oplost hoe minder het risico's dat ontwikkelaars fouten maken.

[Reactie gewijzigd door BoringDay op 24 juli 2024 21:23]

[bonus]

Een OS is alleen maar een operating system om je computer te bedienen en als mensen onveilige dingen daarmee gaan (misschien wel onbedoeld, pure onkunde) doen ja dan wordt het lastig. Er zijn tenslotte niet voor niks jaren 3th party software oplossingen geweest voor safe browising en viruskillen. Ik denk niet dat je alles op het OS kunt gooien.

[tweaknico]

Maar een OS dat goed ontwikkeld en gebouwd wordt (en daarna goed geinstaleerd en beheerd) maakt met name dat laatste traject (beheer) een stuk makkelijker.
Kijk eens naar OpenBSD of OpenVMS en zoek een op beveiligings problemen...

[ari3]

Niet alleen moet de overheid veiligheidseisen stellen, maar ook eisen dat bedrijven en particulieren alleen als veilig gecertificeerde software mogen gebruiken.

Het is eigenlijk hetzelfde als met auto's: je mag alleen gecertificeerde auto's verkopen en je mag alleen in als veilig gecertificeerde auto's rijden. Zowel producent als consument hebben een verantwoordelijkheid voor de veiligheid.

[Verwijderd]

Zo zou er ook voor internet een soort van "rijbewijs" in het leven geroepen kunnen worden. Niet dat iemand zonder zo'n vergunning het net niet op zou mogen, maar wanneer je aanspraak wil maken op vergoedingen bij bijvoorbeeld online fraude je geen vergoeding krijgt zonder zo'n vergunning.

Voor het behalen van zo'n vergunning zou iemand "acceptabele" kennis moeten hebben wat betreft updaten van het OS en 3th party software, werking van AV en FW, herkennen van phishing aanvallen (aka klik-vee) en paswoord beheer.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 21:23]

[BoringDay]

Ja dan moet iedereen ook maar zelfverdediging leren voor het geval iemand degene aanvalt op straat en anders ben je gewoon niet verzekerd.

Dat is complete onzin natuurlijk want zelfs de beste kan erin worden getuimeld.
Een verplichte certificering helpt je er niet tegen, kost onnodig extra geld en uit eindlijk kan je niks aantonen. En werkingen van AV? kom op ik werk niet eens op een Windows computer waarom zou ik die rommel moeten installeren die me niet eens beschermen?

Nee met dat soort onzin moet je niet beginnen, want het gaat totaal niet werken en roept meer irritaties en onrecht gevoelens bij slachtoffers op. Niet te vergeten dat vaak degenen die er over dienen te oordelen er zelf ook bar weinig van snappen ... dan komen ze niet verder dan 'heeft u wel een virusscanner geinstallerd?', 'welke browser gebruikt u', 'Linux? sorry we ondersteunen dat niet u krijgt niks vergoed' .... forget it.

[Reactie gewijzigd door BoringDay op 24 juli 2024 21:23]

[Verwijderd]

Een rijbewijs behoed je ook niet voor het maken van een ongeluk en een cursus zelfverdediging is geen garantie dat je nooit ongeschonden uit een gevecht komt. Het is risico-verkleining...

[BoringDay]

Een verplichte certificering voor computers?
Als men het toch niet behoed dan is het nutteloos en 'waste of money'.

Wanneer iemand iets op bijv. marktplaats iets wil kopen en wordt opgelicht.
Dan kan je bazelen over computers en veiligheid tot je een ons weegt, echter zit oplichting niet in de computer maar in de persoon in kwestie.

We weten ook wel dat banken en bedrijven nooit om wachtwoorden vragen via mail of per telefoon. Moet je daarvoor cursussen gaan geven?

Steek liever dat geld in de zorg en waar het werkelijk nodig is.

[-Tom]

Het probleem wat ik echter zie, wat doen we met uitheemse software? Die hoeven immers niet te voldoen aan de Europese wetgeving en hebben daarmee een zeker concurrentievoordeel ten opzichte van Europese bedrijven - en we weten allemaal dat je niet simpelweg een blokkade kunt opleggen op het internet.

[Batiatus]

In plaats van de software alleen te laten valideren en by design veilig laten zijn, de bedrijven een beloning geven voor het gebruiken van zogenaamde 'certified' software. Software dat veilig is een label geven, waardoor het aantrekkelijker wordt voor de bedrijven om dit aan te schaffen.

Wanneer dit niet zou aanslaan, de bedrijven op een manier verplichten om software aan te schaffen die veilig is, in plaats van goedkoop.

Jammer genoeg heeft de veiligheid van software nog niet echt prioriteit. Performance en design blijken nog altijd hoger in het vaandel te staan. Naar mijn mening moet security in ieder geval meer prioriteit krijgen dan design, maarja.. dat is natuurlijk niet iets zichtbaars waardoor het minder aantrekkelijk is voor de softwaremakers.

[clkndk]

Open Source zou dit stempel niet nodig moeten hebben.
Als er procedures en methodes zijn om de beveiliging te controleren dan kan de overheid deze procedures op de source los laten.
Waarbij ook de gebruikte compiler een aspect kan zijn overigens.
En vervolgens kan de overheid een eigen repository opzetten van goedgekeurde (open source) software, die ook weer aan burgers verstrekt kan worden om Nederland, België en de rest van internet weer een stukje veiliger te maken

[exorbitex]

"Misschien moeten we een app maken om kinderen te onderwijzen"
Of je stuurt de leraar naar een verplichte opfriscursus. Eerst wel even een leraren-APK om te checken waar het aan schort. Hoogstwaarschijnlijk kan dan de oude generatie de internetcursus doen en de jonge generatie de rekencursus.
Sowieso wel een goed idee een leraren-APK.

[massareal]

wel fijn dat iedereen .apk (android) aanbeveelt

[Keypunchie]

Dit lijkt me een goed idee. Gewoon in de wet vastleggen dat bijvoorbeeld persoonsgegevens minimaal met een 1024-bits sleutel beveiligd moeten zijn en meer van dat soort criteria. Natuurlijk maakt dat de boel niet waterdicht, maar regelmatig lees je over de meest simpele hacks van websites door middel van SQL-injectie en dan blijken de passwords alleen maar met MD5 gehasht te zijn. Dan ga je wel nadenken.

Om in EU-verband strenge standaarden voor dataveiligheid neer te leggen en daar civiele of zelfs strafrechterlijke maatregelen aan te verbinden zal ervoor zorgen dat er wat minder belangrijke databases door "een handige jongen" opgezet worden en de hele beveiliging van software professionaliseert.

[pibara]

Zonder extra voorzieningen van het OS (of van low-level additions op het OS) is het voor software zowel onmogelijk om :

1) Zichzelf (en haar data) te beschermen van andere software.
2) Het systeem te beschermen tegen de impact van haar bugs.
3) Zichzelf en het systeem te beschermen tegen buggy of mallicious 3th party libt tools en plugins
die het nodig heeft.

Voor dat je software dus gaat keuren op de veiligheid, zou je eerst operating systems en distributies moeten gaan keuren op het aanbieden van de juiste voorzieningen om die veiligheid mee te garanderen. Pas zodra je minimaal een besturingssysteem of distro hebt die door zo'n OS keuring heen komt zou je software kunnen gaan keuren die op die OSsen op basis van o.a. het feit dat ze effectief gebruik maken van de geboden voorzieningen.

Als voorbeeld, een programma dat gevoelige user data noodgedwongen in $HOME zet waar andere programma's er bij kunnen is per definitie onveilig. Een programma dat toegang heeft tot een gedeelde $HOME waar gevoelige data staat van andere programma's waar het in beginsel niets in te zoeken heeft is per definitie onveilig. Een programma welke een 3th party library of module gebruikt welke noodgedwongen draait met alle rechten van het programma is per definitie onveilig. En zo kunnen we nog even door gaan. Om het bruut te stellen: programma's in de main stream OSsen hebben gewoon door de tekortkomingen van het OS niet de mogelijkheid om veilig te zijn, ongeacht hoe bekwaam de makers van de programma's ook zijn.

[Verwijderd]

Wanneer het belangrijk is dat andere programma's niet bij data van een programma kan komen is het ook een mogelijkheid om deze informatie versleuteld in de $HOME te zetten. Vervolgens kan middels certificaten de informatie worden ontsleuteld binnen het programma (en deze certificaten staan read-only in de (systeem-)configuratiedir).
Overigens kan een programmamaker (of de systeembeheerder) er ook voor kiezen een extra account aan te maken en de info in de $HOME te plaatsen onder deze account.
Het zijn alletwee geen bijzonder elegante oplossingen, maar wel effectief wanneer dit goed wordt ingezet.

Een 3th party library is niet per definitie onveilig, maar moet wel onderdeel zijn van de security-audit en niet ongecontroleerd op volle rechten worden uitgevoerd, maar een 3th party lib kan ook met minder rechten worden uitgevoerd. Dit is op de OS-en die ik ken mogelijk.

Ofwel het is niet zo dat de OS-en ervoor zorgen dat software niet veilig kan worden gemaakt, je moet alleen weten hoe je ermee omgaat en hoe je je programma het beste kunt ontwikkelen.