Dave Wichers
Cofounder and board member OWASP
In iedere organisatie waar veel softwareontwikkeling plaatsvindt op verschillende platformen, heeft men hetzelfde probleem. In applicaties wordt er door ontwikkelaars functionaliteit gebouwd voor beveiliging, zoals authenticatie, autorisatie, encryptie en sessie management of andere kritische functionaliteit, zoals input validatie, error handling en logging. Voor iedere applicatie worden andere oplossingen bedacht en vaak bestaan er zelfs verschillende oplossingen binnen één applicatie. Voor wie het nog niet beseft: deze functionaliteit is veel complexer dan het lijkt! Functioneel is het goed te bouwen, maar is het dan ook veilig? Uit de praktijk blijkt dat er enorme hoeveelheden fouten worden gemaakt en dat talloze websites kwetsbaar zijn.
Wat kunnen we hieraan doen? Om te beginnen met de ontwikkelaar. Ze moeten leren wanneer en hoe beveiligingsfunctionaliteit te gebruiken. Voor de beeldvorming is het 'waarom', uitgedrukt in risico's, ook goed om te weten. Met nadruk op 'gebruiken', want zelfs ontwikkelaars zouden deze functionaliteit niet zelf moeten bouwen!
De grote leveranciers van ontwikkelplatformen, zoals Microsoft en Sun, hebben veel energie gestoken in het inbouwen van beveiligingsfunctionaliteit. Daarnaast zijn er diverse leveranciers die complete oplossingen kunnen leveren voor beveiligingsfunctionaliteit. Het enige probleem is de weerbarstige praktijk, waarin er verschillende platformen door elkaar worden gebruikt, door verschillende ontwikkelaars en flexibiliteit gewenst is. Het invoeren van een bedrijfsstandaard is moeilijk, vanwege deze diversiteit en de aan verandering onderhevige omgeving. Gebonden zijn aan een oplossing van 1 leverancier is voor veel organisaties niet haalbaar.
Maar wat als we 1 overkoepelende en gestandaardiseerde interface maken, die gekoppeld is aan de bestaande beveiligingsfunctionaliteit van de onderliggende platformen en de ontbrekende functionaliteit verder aanvult. En dat deze interface voor de meest voorkomende platformen, zoals Java, .NET en PHP, hetzelfde er uitziet. En dat de interface ruimte biedt om eigen beveiligingsfunctionaliteit 'onder de motorkap' eraan te koppelen. Dan hebben we een uitgangspunt waar we wél goed een bedrijfsstandaard voor kunnen schrijven, waarin het 'wanneer' en 'hoe' te gebruiken wordt vastgelegd. Training van ontwikkelaars kan dan veel eenduidiger en niet op ieder ontwikkelplatform of met iedere versie verschillend. Het uiteindelijke resultaat: eenduidiger en veiliger gebruik van beveiligingsfunctionaliteit, betere mogelijkheden voor bedrijfsstandaarden en uiteindelijk dus een veiliger eindresultaat.
Dit is in het kort wat er bedoeld wordt met het Enterprise Security API van OWASP. OWASP is de ideale partij voor een dergelijke interface. Veel specialisten in de community die meewerken, onafhankelijk van leveranciers, gecombineerd met veel documentatie over de wanneer en hoe. Zelfs kant en klare documenten om op te nemen in de bedrijfsstandaard.
Er moet wel aan een aantal randvoorwaarden worden voldaan, om het project in praktijk werkbaar te maken. Als eerste, duidelijke releases maken en niet teveel wijzigen aan de interface, anders wordt het standaardisatie voordeel weer teniet gedaan. Zeer snel reageren op veiligheidslekken, want als het veel gebruikt wordt, hebben ook veel bedrijven tegelijk een probleem. Duidelijke communicatie over veiligheidslekken en de commitment van OWASP om de ESAPI te blijven ondersteunen in de komende pakweg 10 jaar, ook de oudere versies. Bijpassende documenten die rechtstreeks kunnen worden opgenomen in de bedrijfsstandaarden.
Mis ik nog kritische punten? Graag uw reactie!
Abonneren op:
Reacties posten (Atom)
Geen opmerkingen:
Een reactie posten