Close
Deze pagina in jouw taal bekijken?
Alle talen
Kies je taal

Hoe wij kwetsbaarheidsbeheer aanpakken

Onze aanpak voor omgang met beveiligingskwetsbaarheden bij Atlassian

Atlassian erkent dat beveiligingskwetsbaarheden op een zeker niveau een inherent onderdeel zijn van elk softwareontwikkelingsproces. We streven er echter voortdurend naar om de ernst en frequentie waarmee deze kwetsbaarheden voorkomen in onze eigen producten en diensten te verminderen.

Om dat te bereiken beschikken we over een veelzijdige aanpak van kwetsbaarheidsbeheer die gebaseerd is op een combinatie van geautomatiseerde en handmatige processen. We geloven dat dit de effectiefste manier is om de kans dat kwetsbaarheden langere tijd onopgemerkt blijven te beperken.

In dit paper geven we een overzicht van hoe we kwetsbaarheden beheren in onze producten en infrastructuur en hoe we die aanpak voortdurend ontwikkelen door de nieuwste tools, methoden en denkwijzen op te nemen, zodat we er zeker van zijn dat de manier waarop we omgaan met kwetsbaarheden ook in de toekomst effectief blijft.

Een overzicht van ons proces voor het identificeren en verhelpen van kwetsbaarheden

We hebben een methodisch concept om kwetsbaarheden te identificeren, bij te houden en op te lossen, ongeacht het type.

Voortdurende detectie en toewijzing van assets

Voortdurende detectie van interne assets: We gebruiken een intern systeem om al onze EC2- en Load Balancer AWS-assets te inventariseren met behulp van AWSConfig, en deze assets toe te wijzen aan de juiste eigenaar. Zo behouden we elk jaar zo'n 50-60 miljoen assets.

Kwetsbaarheden vaststellen

We use a range of best-of-breed vulnerability detection tools that are run regularly across our products and infrastructure to automatically scan for and identify vulnerabilities. This includes Atlassian Cloud & Data Center products, Docker application images, internal, mobile and third party applications, as well as our infrastructure both on premises and in our cloud. These tools automatically scan for and identify vulnerabilities that exist, and include:

  • Host-gebaseerde scans – We maken momenteel gebruik van Assetnote om continue beveiligingsscans van onze externe perimeter uit te voeren, en Tenable.io om zowel intern als extern continu te scannen. Deze tools worden gebruikt om open poorten, services en applicaties te identificeren die in onze omgeving worden uitgevoerd, evenals kwetsbaarheden op netwerkhosts.
  • Scans van container images – we gebruiken Docker-containers om veel van onze applicaties te implementeren. We voeren een beveiligingsscan uit van container images wanneer ze worden geïmplementeerd in onze productie- of pre-productieomgevingen. Dit doen we met een tool die Snyk heet. Meer informatie is later op deze pagina te vinden.
  • Open source afhankelijkheidsscans - we gebruiken Snyk om kwetsbaarheden te identificeren die mogelijk aanwezig zijn in open-source-code of code van externe partijen. Meer informatie is verder op deze pagina te vinden.
  • AWS configuration monitoring - We deploy and integrate Lacework in the Atlassian AWS Cloud environment to provide continuous configuration monitoring against established baselines for our AWS environments.

We houden altijd de nieuwste beschikbare tools in de gaten en voegen deze toe aan ons assortiment als we geloven dat ze onze mogelijkheden voor kwetsbaarheidsdetectie verbeteren.

We hebben ook allerlei aanvullende mogelijkheden die we gebruiken om kwetsbaarheden vast te stellen, naast de geautomatiseerde scans die we uitvoeren. Dit zijn onder andere:

Ons Bug Bounty-programma – we gebruiken Bugcrowd om ons Bug Bounty-programma uit te voeren. Bugcrowd biedt ons toegang tot een betrouwbare community van experts, bestaande uit tienduizenden onderzoekers op het gebied van cyberbeveiliging die onze producten continu testen en alle kwetsbaarheden die ze vinden rapporteren. Ons Bug Bounty-programma is in 2018 en 2019 erkend als beste in de sector.

Rapporten van klanten en gebruikers: gebruikers van onze producten kunnen alle bugs die ze vinden op ieder moment rapporteren via de Atlassian-support We werken dan samen met hen om alle nodige informatie te verkrijgen, zodat de kwetsbaarheid intern aangegeven kan worden en opgelost kan worden (onderhevig aan controle om er zeker van te zijn dat de kwetsbaarheid echt is en geen valse positief). Dit omvat ook personeel van Atlassian, die alle issues die ze vinden in onze producten (extern of intern) direct bij het beveiligingsteam kunnen aangeven of een supporticket kunnen indienen.

Externe penetratietests: we gebruiken gespecialiseerde beveiligingsconsultancybedrijven om white box, door code ondersteunde, penetratietests uit te voeren op risicovolle producten en infrastructuren. Zie 'Hoe wij externe beveiligingstests aanpakken' voor meer informatie.

Het productbeveiligingsteam van Atlassian: we voeren doelgerichte codebeoordelingen uit, zowel handmatig als met tools, en werken nauw samen met onze productontwikkelingsteams voor verbetering van hun vermogen om kwetsbaarheden zelf te ontdekken en op te lossen voordat de code ons bereikt.

Het Red Team van Atlassian: we hebben een intern Red Team dat als doel heeft om de rol van vijanden na te bootsen die proberen kwetsbaarheden in onze systemen, processen en omgevingen vast te stellen en er misbruik van te maken, zodat wij er zeker van zijn dat ze zo snel mogelijk gevonden en aangepakt worden.

Kwetsbaarheden bijhouden en verhelpen

We gebruiken een intern ticket- en escalatiesysteem om alle kwetsbaarheden te volgen die we hebben ontdekt en proberen op te lossen. Specifieker: er wordt een speciale ticket aangemaakt voor elke kwetsbaarheid, ongeacht of deze gevonden wordt met een van onze scanhulpmiddelen of via een andere hierboven besproken methoden, en deze ticket wordt toegewezen aan het relevante productteam. De Service Level Objectives (SLO's) voor het herstel van kwetsbaarheden die we in ons Beveiligingsbugfixbeleid hebben gepubliceerd, worden bijgehouden voor elke kwetsbaarheid.

Ons beveiligingsteam houdt toezicht op dit proces en werkt samen met product- en infrastructuurteams om nauwkeurig herstel van kwetsbaarheden te garanderen en vragen over herstel te beantwoorden.

Once a fix for a vulnerability is developed, it is tested thoroughly and then, in the case of our cloud products, incorporated into our CI/CD pipeline for deployment. For Data Center products, fixes are rolled into a new release and deployed with other fixes on a regular basis in accordance with our standard release cadence. Vulnerability tickets from scanning tools are automatically closed when subsequent re-scans do not find the vulnerability. Vulnerability tickets from manual findings are closed by product, infrastructure, or security team members when the fix has been made available to customers.

Kwetsbaarheden tijdens het ontwikkelingsproces voorkomen

Container images scannen

Atlassian implementeert de meeste van onze applicaties met Docker container images. Docker containers bestaan uit een verpakte, op zichzelf staande omgeving die bestaat uit relevante systeemlibrary's, tools, configuratie-instellingen en alle andere afhankelijkheden die nodig zijn zodat onze producten gebruikt kunnen worden met iedere machineconfiguratieparameters. De container biedt effectief een abstractielaag, waardoor de softwarecode losgekoppeld wordt van de onderliggende infrastructuur, zodat onze producten probleemloos werken op verschillende machines.

Containers bieden onze ontwikkelaars en klanten allerlei voordelen, omdat ze code kunnen implementeren die in allerlei omgevingen gebruikt kunnen worden, maar ze kunnen ook beveiligingskwetsbaarheden met zich meebrengen als de inhoud van de images uit verouderde of anderszins onveilige bibliotheken of onderdelen bestaat.

Om dit aan te pakken, integreert Atlassian een gebeurtenisgestuurd scanproces voor containerbeveiliging dat implementaties bewaakt via ons Micros-implementatieplatform voor alle containers die in onze productieomgevingen worden geïmplementeerd. Daarnaast kunnen ontwikkelaars een scanproces integreren in onze CI/CD-pijplijn voor alle containers die in onze ontwikkelingsomgevingen worden geïmplementeerd. Hiervoor gebruiken we de Snyk Container-engine. Snyk levert een set tools om diepe inspectie uit te voeren van alle containerimages die door onze ontwikkelaars worden geïmplementeerd. Dit omvat een gedetailleerde analyse van die afbeeldingen om de verschillende componenten die ze bevatten te identificeren en om te bepalen welke kwetsbaarheden bekend zijn.

Opensource afhankelijkheden

Hoewel het belangrijk is om kwetsbaarheden in onze eigen code te vinden en op te lossen, zijn onze producten en services ook afhankelijk van verscheidene externe library's. Het is daarom net zo essentieel dat we ons bewust zijn van welke library's we gebruiken en dat ze actueel zijn met de nieuwste bugfixes. We gebruiken een tool die Snyk heet om ons hierbij te helpen. Snyk heeft een scanner om afhankelijkheden in onze softwarebuilds te identificeren en deze library's te vergelijken met een database van bekende beveiligingskwetsbaarheden.

Alle gevonden kwetsbaarheden worden daarna automatisch gemeld bij het relevante productteam via een formeel Jira ticket, in navolging van het proces voor kwetsbaarheidsbeheer dat we eerder op deze pagina hebben beschreven.

Andere initiatieven die we gebruiken om kwetsbaarheden te bestrijden

Tot nu toe hebben we in dit paper voornamelijk de stappen besproken die we zetten om kwetsbaarheden in de 'back-end' te beheersen, dat wil zeggen wat we doen om een kwetsbaarheid aan te pakken die gevonden is in onze producten of platformen. We streven er echter voortdurend naar om te zorgen dat ze minder vaak voorkomen. Om dit te bereiken hebben we een aantal unieke initiatieven geïntegreerd in de 'front-end' van ons ontwikkelingsproces om er zeker van te zijn dat onze producten van begin af aan worden opgebouwd met het oog op veiligheid.

Productbeveiligingstechnici

Geen enkele bespreking van kwetsbaarheidsbeheer zou compleet zijn zonder de essentiële rol te noemen die onze productbeveiligingstechnici vervullen, zowel in het wegstrijken van bugs als in het ontwerpen van betere strijkijzers.

Onze productbeveiligingstechnici voeren de eerste triage uit op nieuw gerapporteerde kwetsbaarheden en werken samen met onze productengineeringteams om de beste oplossing voor het probleem te vinden. Onze productbeveiligingstechnici zijn experts op het gebied van applicatiebeveiliging en zijn wereldwijd verspreid, zodat ze op de meest effectieve manier kunnen samenwerken met onze productengineers.

Onze beveiligingstechnici hebben zowel een proactieve als een reactieve rol in beveiliging met betrekking tot hun toegewezen product, waaronder, maar niet beperkt tot:

  • Actuele bedreigingsmodellen voor nieuwe en opkomende risico's beoordelen en analyseren
  • De veiligheid van nieuwe functies beoordelen en analyseren
  • Handmatige codebeoordeling uitvoeren
  • Penetratietests uitvoeren
  • Platform en architectuur beoordelen
  • Belangrijke activiteiten met betrekking tot projecten bijhouden en begeleiding geven waar nodig
  • Gerapporteerde problemen via ons Bug Bounty-programma triageren, archiveren, belonen en zorgen dat ze tijdig opgelost worden
  • Nieuwe automatisering schrijven en bestaande automatisering en tools onderhouden om dekking en efficiëntie te optimaliseren

Beveiligingsscorekaarten

Met de gegevens die we verzamelen met de systemen die in dit paper beschreven zijn kunnen we teams en producten tegen elkaar benchmarken om verbeteringspunten proactief te identificeren.

Samenvatting

Atlassian past een veelzijdige benadering van kwetsbaarheidsbeheer toe op onze producten en platformen en maakt daarbij gebruik van een combinatie van geautomatiseerde scantools, een Bug bounty-programma en allerlei andere mechanismen die constant blijven ontwikkelen om er zeker van te zijn dat we kwetsbaarheden die opkomen zo snel mogelijk vaststellen en oplossen en het aantal keer dat ze voorkomen minimaliseren.

Wil je meer te weten komen?

Wil je meer te weten komen?

Er zijn allerlei andere resources waar we in deze paper naar verwezen hebben of die je anderszins kan raadplegen voor meer informatie over onze aanpak van kwetsbaarheidsmanagement en beveiliging in het algemeen.

Wanneer we op deze pagina verwijzen naar kwetsbaarheden, kan dit gezien worden als synoniem voor 'bugs', de term die we gebruiken in onze aparte paper over Hoe wij beveiligingstests aanpakken.