image

VS zoekt informatie over oplossen veelvoorkomende kwetsbaarheden

maandag 8 januari 2024, 10:14 door Redactie, 11 reacties
Laatst bijgewerkt: 08-01-2024, 12:07

De Amerikaanse overheid zoekt informatie over en feedback op het oplossen van veelvoorkomende kwetsbaarheden zoals SQL injection, path traversal en hardcoded wachtwoorden. Ook wordt gezocht naar antwoorden op hoe leveranciers veiligere software kunnen maken en hoe organisaties die software afnemen omgaan met de veiligheid hiervan. Vorig jaar publiceerden internationale cyberagentschappen, waaronder het Nationaal Cyber Security Centrum (NCSC), een rapport genaamd "Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software" (pdf).

Daarin worden softwareleveranciers opgeroepen om principes voor veilige softwareontwikkeling te volgen. Het Cybersecurity and Infrastructure Security Agency (CISA) van het Amerikaanse ministerie van Homeland Security heeft nu om reacties op het document gevraagd, maar ook om informatie over en feedback op aanvullende onderwerpen. Het gaat dan bijvoorbeeld om het oplossen van veelvoorkomende kwetsbaarheden. "In het nieuws zien we geregeld voorbeelden van kwetsbaarheden waarvoor al jarenlang, of zelfs decennia, effectieve oplossingen bestaan."

Het CISA noemt als voorbeeld SQL injection, path traversal en hardcoded wachtwoorden. De overheidsinstantie wil weten wat de obstakels zijn om dit soort kwetsbaarheden te verhelpen, hoe potentiële klanten kunnen beoordelen welke softwareleveranciers deze beveiligingslekken niet in hun software hebben zitten en welke aanpassingen er aan het Common Vulnerabilities and Exposures (CVE) moet worden doorgevoerd om ervoor te zorgen dat meer bedrijven veelvoorkomende kwetsbaarheden identificeren en onderzoek doen om ze te verhelpen. Daarnaast wil het CISA ook weten wat de financiële impact van softwarelekken op leveranciers is en hoe softwareleveranciers bepalen welke kwetsbaarheden ze verhelpen.

Een ander onderwerp dat op de lijst staat is de tegenzin van bedrijven om te upgraden naar nieuwe veiligheidsfeatures of netwerkprotocollen die softwareleveranciers hebben ontwikkeld. Dergelijke upgrades vereisen acties van de klant, maar die blijken de beveiligingsverbeteringen niet door te voeren omdat het tijd of geld kost. Het CISA wil nu weten wat de primaire obstakels zijn waarom klanten geen upgrades uitvoeren die hun risico verminderen en wanneer klanten besluiten upgrades wel uit te voeren. De feedback die het CISA ontvangt kan als aanvulling aan gepubliceerde rapport worden toegevoegd.

Reacties (11)
08-01-2024, 10:23 door Anoniem
Of ze zoeken oplossingen om deze oplossingen "op te lossen"...
08-01-2024, 10:25 door Anoniem
Uogrades is en blijft het paard achter de wagen spannen. Maak het gewoon in 1x goed. En ja, dat zal zo hier en daar wat functionaliteit kosten.
Elke update of upgrade die gedrag verandert (en dat doen ze, anders is het uitbrengen ervan zinloos) kost tijd en moeite om aan de gang te krijgen en levert bij gebruikers irritatie op - wat ook weer tijd en moeite kost.
Ik zie het al gebeuren dat ik elke maand mijn voordeurslot moet vervangen en een sleutel onder een andere hoek moet insteken. Accepteert ook geen hond.
08-01-2024, 11:10 door Anoniem
Een hele belangrijke stap in de verbetering van softwarekwaliteit is nmm. het aansprakelijk stellen van de softwareleveranciers voor schade veroorzaakt door fouten in hun software, tenzij die leverancier kan aantonen "best practices" te hebben gebruikt gedurende het ontwikkelproces.
08-01-2024, 11:48 door Anoniem
Er zijn met name open source ontwikkel frameworks die je helpen om dit soort fouten te voorkomen. Bv: https://docs.djangoproject.com/en/5.0/topics/security/
08-01-2024, 12:50 door Erik van Straten
Door Anoniem: Een hele belangrijke stap in de verbetering van softwarekwaliteit is nmm. het aansprakelijk stellen van de softwareleveranciers voor schade veroorzaakt door fouten in hun software, tenzij die leverancier kan aantonen "best practices" te hebben gebruikt gedurende het ontwikkelproces.
Volstrekt mee eens. Alle reeds geprobeerde maatregelen hebben gefaald, terwijl we weten dat boetes bedrijven en hun aandeelhouders risico's van klanten ook als hun risico gaan zien.

En veel bedrijven zijn enorm hardleers. Als je ziet hoe vaak en hoe lang al Cisco moet melden dat er sprake was van een "geheim" beheeraccount met hardcoded wachtwoord in hun firmware, en veel klanten ondanks dat bij spullen van Cisco blijven zweren, gaat het initiatief van de US gov. heus geen zoden aan de dijk zetten.

https://www.schneier.com/blog/archives/2023/10/cisco-cant-stop-using-hard-coded-passwords.html
08-01-2024, 12:57 door Anoniem
Sql injectie zou op zich voor het grootste gedeelte makkelijk op te lossen zijn als databases verbieden om parameters in de query mee te zenden.
Dus alles stored procedure achtig, waarbij alleen paramters gevuld mogen worden met wat verwacht wordt (bv getal en dus niet quote etc)
08-01-2024, 13:10 door Anoniem
Door Erik van Straten:
Door Anoniem: Een hele belangrijke stap in de verbetering van softwarekwaliteit is nmm. het aansprakelijk stellen van de softwareleveranciers voor schade veroorzaakt door fouten in hun software, tenzij die leverancier kan aantonen "best practices" te hebben gebruikt gedurende het ontwikkelproces.
Volstrekt mee eens. Alle reeds geprobeerde maatregelen hebben gefaald, terwijl we weten dat boetes bedrijven en hun aandeelhouders risico's van klanten ook als hun risico gaan zien.

En veel bedrijven zijn enorm hardleers. Als je ziet hoe vaak en hoe lang al Cisco moet melden dat er sprake was van een "geheim" beheeraccount met hardcoded wachtwoord in hun firmware, en veel klanten ondanks dat bij spullen van Cisco blijven zweren, gaat het initiatief van de US gov. heus geen zoden aan de dijk zetten.

https://www.schneier.com/blog/archives/2023/10/cisco-cant-stop-using-hard-coded-passwords.html
En Microsoft gaat de EULA echt niet aanpassen.
08-01-2024, 15:33 door Anoniem
Door Anoniem: Sql injectie zou op zich voor het grootste gedeelte makkelijk op te lossen zijn als databases verbieden om parameters in de query mee te zenden.
Dus alles stored procedure achtig, waarbij alleen paramters gevuld mogen worden met wat verwacht wordt (bv getal en dus niet quote etc)
Je hebt het niet begrepen. Als je (al je) invoerwaarden als SQL parameters doorgeeft, heb je juist geen last van SQL injectie. Het risico ontstaat bij het samenstellen van een SQL statement uit invoerstrings.
08-01-2024, 17:07 door Erik van Straten
Door Anoniem: En Microsoft gaat de EULA echt niet aanpassen.
Precies. Na het ActiveX/OCX drama met "trusted" code vanaf het web, "veilig want digitaal ondertekend" [1], heeft Microsoft in 2022 weer iets nieuws bedacht waarmee je, via de webbrouwser, automatisch code vanaf websites kon downloaden en buiten de (sandbox van de) browser kon uitvoeren - "veilig want digitaal ondertekend".

[1] https://en.wikipedia.org/wiki/ActiveX#History

Surprise! Opnieuw geen goed idee, zie (Engelstalig) https://www.theregister.com/2024/01/04/microsoft_windows_app_installation/.

"Autorun" kon overigens met:
"ms-appinstaller:?source=http://example.com/installation.msix"
Bron (Duitstalig): https://www.heise.de/news/Von-Malware-missbraucht-Microsoft-deaktiviert-App-Installationen-per-Website-9584964.html
09-01-2024, 17:24 door Anoniem
Door Anoniem:
Door Anoniem: Sql injectie zou op zich voor het grootste gedeelte makkelijk op te lossen zijn als databases verbieden om parameters in de query mee te zenden.
Dus alles stored procedure achtig, waarbij alleen paramters gevuld mogen worden met wat verwacht wordt (bv getal en dus niet quote etc)
Je hebt het niet begrepen. Als je (al je) invoerwaarden als SQL parameters doorgeeft, heb je juist geen last van SQL injectie. Het risico ontstaat bij het samenstellen van een SQL statement uit invoerstrings.

We zeggen hetzelfde.

Geen "SELECT 1 FROM tabel where (en dan hier lekker zelf alles opbouwen in jouw eigen code)"
Maar echt "SELECT 1 FROM tabel where x = ?" en dat alleen ? aan de kant van de database mag worden samengevoegd.
En dat vaste stuk ook aan de kant van de database vast ligt (want anders kan een aanvaller alsnog wel z'n eigen query samenstellen).

Het lost het niet helemaal op, maar het verhelpt wel al vele vergissingen.
10-01-2024, 19:10 door Anoniem
Door Anoniem: Sql injectie zou op zich voor het grootste gedeelte makkelijk op te lossen zijn als databases verbieden om parameters in de query mee te zenden.
Dus alles stored procedure achtig, waarbij alleen paramters gevuld mogen worden met wat verwacht wordt (bv getal en dus niet quote etc)
sql injection is niet een probleem van databases maar het probleem van programmeurs die wat lui zijn...
en hun werk maar half doen.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.