Zwakke plekken vinden. Vóór de aanval.

Een SaaS-product bestaat niet alleen uit publiek bereikbare endpoints. Verschillende rollen, uitnodigingen, exports, achtergrondtaken en beheerfuncties vormen samen de bedrijfslogica. Vóór de test bepalen wij daarom welke processen een bijzonder hoge beschermingsbehoefte hebben en welke grenzen de applicatie moet afdwingen. Deze invalshoek vult klassieke technische controles aan. Een functie kan formeel correct reageren en toch een handeling toestaan die niet bedoeld is voor de aangemelde persoon of diens tenant.

Op deze basis ontstaat een afgestemde testscope. Black-box-, grey-box- of white-boxonderdelen worden gekozen op basis van het doel en de beschikbare informatie. Wanneer broncode of architectuurdocumentatie beschikbaar wordt gesteld, zijn waarnemingen gerichter te duiden. De controle richt zich op de geautoriseerde applicatie en gebruikt de overeengekomen accounts en gegevens. Een bevinding van een tool wordt niet zonder beoordeling overgenomen als bevestigde kwetsbaarheid; impact en voorwaarden moeten voor uw team duidelijk zijn.

Bij SaaS en PaaS is de verantwoordelijkheidsgrens beslissend. De controle van uw applicatie of configuratie is niet automatisch een toestemming om de infrastructuur van een platformaanbieder aan te vallen. Samen worden doelen, toegestane methoden en vereiste goedkeuringen vastgelegd. API's en integraties worden getoetst aan de beoogde gegevens- en autorisatieomvang. Bijzondere aandacht gaat naar de vraag of verschillende rollen en tenants in de daadwerkelijke gebruikspaden betrouwbaar gescheiden blijven.

Legacysoftware vraagt vaak om een andere aanpak. Documentatie kan onvolledig zijn, testomgevingen geven de productieomgeving maar deels weer en afzonderlijke componenten reageren gevoelig op belasting. Deze omstandigheden horen vóór de start in de planning. Wij stemmen testvenster, bereikbare contactpersonen en stopcriteria af. Waar een controle niet verantwoord kan worden uitgevoerd, wordt die grens zichtbaar gemaakt in het resultaat. Zo blijft duidelijk welke uitspraak de test mogelijk maakt en waar extra onderzoek nodig zou zijn.

Een rapport moet een beslissing mogelijk maken en het ontwikkelteam helpen bij de correctie. Een bevestigde bevinding beschrijft daarom de betrokken versie, de benodigde voorwaarden, het overeengekomen bewijs en de mogelijke impact. Management en techniek hebben daarbij elk een ander detailniveau nodig. De prioritering houdt rekening met de toepassingscontext, in plaats van alleen een lange lijst even zwaar wegende meldingen op te leveren. Bewijs wordt beperkt tot het noodzakelijke en via afgesproken kanalen gedeeld met de bevoegde contactpersonen.

Het herstel wordt besproken met uw team; een overeengekomen retest beoordeelt de concrete wijziging. Een verholpen bevinding betekent echter niet automatisch dat de gehele applicatie vrij is van kwetsbaarheden. Nieuwe releases en configuratiewijzigingen kunnen de uitgangssituatie veranderen. Op verzoek kan hieruit een periodieke controle van belangrijke wijzigingen worden ontwikkeld. Voor geschikte, duidelijk afgebakende doelen kan daarnaast Result as a Service worden overeengekomen: de vergoeding hangt dan af van het vooraf gedefinieerde en aangetoonde resultaat.