Maatwerksoftware testen is een ander soort opdracht dan een website scannen. Een op maat gebouwde applicatie heeft geen gemeenschap die fouten voor je vindt, leunt op externe componenten die stilletjes verouderen, en heeft vaak een verbinding met je interne netwerk. Daarmee is het bij veel organisaties het grootste risico dat het minst wordt getest.
Kort samengevat
- Niemand anders vindt de fouten in jouw maatwerk; jij bent de enige gebruiker.
- Externe bibliotheken verouderen zonder dat iemand kijkt, en hun kwetsbaarheden staan in openbare lijsten.
- De verbinding naar binnen is het probleem, niet de applicatie zelf.
- Maatwerksoftware testen betekent logica, componentenlijst en de lijn naar binnen; dat doet geen scanner.
Vraag een organisatie waar ze het bangst voor zijn, en het antwoord is “de website” of “het netwerk”. Vraag door in een scopegesprek, en er komt met regelmaat iets anders boven: een applicatie die ooit op maat is gebouwd, inmiddels bedrijfskritiek is, die niemand van buiten ooit heeft bekeken, en die een verbinding heeft met het interne netwerk. Dat is meestal het echte risico. Niet omdat de bouwers slecht werk leverden, maar omdat er drie dingen tegelijk spelen die je bij standaardsoftware niet hebt.
Waarom is maatwerk anders?
- Niemand anders vindt de fouten voor je. Bij een standaardpakket zoeken duizenden organisaties, beveiligingsonderzoekers en de leverancier zelf naar problemen. Wordt er iets gevonden, dan komt er een update. Bij jouw maatwerkapplicatie ben jij de enige gebruiker. Een fout zit erin tot iemand hem zoekt.
- De bibliotheken eronder verouderen stilletjes. Vrijwel elke applicatie leunt op tientallen externe componenten. Die zijn ooit gekozen en daarna zelden opnieuw bekeken. In een applicatie die vijf jaar draait zonder verbouwing zitten al snel componenten met bekende, publiek gedocumenteerde kwetsbaarheden, met handleiding erbij.
- De verbinding naar binnen is het probleem. Een applicatie die alleen zichzelf is, is te overzien. Een applicatie die gegevens ophaalt uit je ERP, schrijft naar een interne database of draait op een server die ook andere dingen doet, is een brug. En bruggen zijn wat een aanvaller zoekt.
Wat moet maatwerksoftware testen omvatten?
Een gewone externe scan kijkt naar je applicatie zoals een bezoeker hem ziet. Nuttig, maar het raakt de kern niet. Drie dingen die een scanner niet doet:
- De logica, niet de techniek. De interessante fouten in maatwerk zijn zelden technisch. Kan ik met mijn eigen account gegevens van een ander opvragen door een nummer in de URL te veranderen? Kan ik een stap in een proces overslaan? Kan ik iets goedkeuren waar ik niet bevoegd voor ben? Die vragen stelt alleen een mens.
- De componentenlijst. Welke externe bibliotheken zitten erin, in welke versie, en zijn daar bekende problemen mee? Snel te controleren, vaak direct resultaat. Vraag je ontwikkelaar om die lijst; kan hij die niet leveren, dan is dát de eerste bevinding.
- De lijn naar binnen. Als de applicatie gecompromitteerd is, waar kom je dan? Dit interesseert je directie het meest, en het valt in een applicatietest standaard buiten scope. Zet het er expliciet in.
Hoe voer je het gesprek met je ontwikkelaar?
Dit is vaak het gevoelige deel, zeker als de bouwer al jaren voor je werkt.
- Vraag de componentenlijst op vóór de test. Niet om af te rekenen, maar omdat de test er efficiënter van wordt en je zelf leert hoe je applicatie in elkaar zit.
- Betrek de ontwikkelaar bij de rapportage. Hij moet het straks repareren. Hoe eerder hij de bevindingen begrijpt, hoe sneller dat gaat.
- Maak afspraken voor daarna. De meeste waarde zit in de afspraak die volgt: wie houdt de componenten bij, hoe vaak, wie merkt het als er een probleem wordt gepubliceerd. Zonder die afspraak sta je over twee jaar op hetzelfde punt.
Als de applicatie nieuw is
Staat er een nieuwe maatwerkapplicatie op het punt om live te gaan, dan is dat het goedkoopste moment voor maatwerksoftware testen. Een fout vóór livegang kost een aanpassing. Dezelfde fout erna kost een aanpassing plus een migratie plus mogelijk een melding. Organisaties die software leveren aan anderen hebben een tweede reden: klanten vragen er steeds vaker naar. Een onafhankelijk testrapport bij oplevering is inmiddels een verkoopargument.
Heb je een applicatie die niemand van buiten ooit heeft bekeken? In een scopegesprek bepalen we of daar je grootste risico zit en wat maatwerksoftware testen in jouw geval moet omvatten.
BOEM voert pentesten uit met EHGI, het bedrijf achter de EHGN-community van 2.500+ ethische hackers, waaronder specialisten van Politie, Defensie en DIVD. Welke tester bij jouw omgeving past, bepalen we in het scopegesprek.
Veelgestelde vragen
Waarom is maatwerksoftware een groter risico dan standaardsoftware?
Bij een standaardpakket zoeken duizenden organisaties en de leverancier naar fouten en komt er een update. Bij jouw maatwerkapplicatie ben jij de enige gebruiker. Een fout zit erin tot iemand hem zoekt: een tester die jij inhuurt, of een aanvaller.
Wat moet een test van maatwerksoftware omvatten?
Drie dingen die een scanner niet doet: de logica (kan ik gegevens van een ander opvragen door een nummer te wijzigen, een stap overslaan, iets goedkeuren zonder bevoegdheid), de componentenlijst met versies, en de lijn naar je interne netwerk als de applicatie is gecompromitteerd.
Mijn ontwikkelaar kan geen componentenlijst leveren. Wat betekent dat?
Dat is de eerste bevinding. Zonder lijst weet niemand welke externe bibliotheken erin zitten en of daar bekende kwetsbaarheden in zijn gepubliceerd. Vraag hem vóór de test op; de test wordt er efficiënter van.
Wanneer is het beste moment om maatwerksoftware te testen?
Vóór livegang. Een fout die je dan vindt, kost een aanpassing. Dezelfde fout erna kost een aanpassing plus migratie plus mogelijk een melding. Voor softwareleveranciers is een onafhankelijk rapport bij oplevering bovendien een verkoopargument.
