Outlook Web App: Ontwerpen Met Beveiligingsinstellingen En Session Management

Voor tal van departementen, uitvoeringsorganisaties en gemeenten is OWA de meest flexibele route naar e-mail omdat medewerkers, ingehuurde specialisten en crisisteams zo direct toegang krijgen zonder te wachten op een volledig ingerichte werkplek. Het ondersteunt Bring Your Own Device-scenario's, reizen tussen locaties, werkzaamheden vanuit de rechtszaal of het klaslokaal en tijdelijke projectorganisaties die slechts enkele weken bestaan. Door de browserinterface kan een medewerker aan de balie snel de lokale agenda raadplegen terwijl een beleidsmedewerker onderweg een spoedbericht goedkeurt. Deze flexibiliteit onderbouwt digitale dienstverlening en verhoogt de veerkracht tijdens verstoringen. Dezelfde flexibiliteit brengt risico's die in klassieke Outlook-configuraties nauwelijks voorkomen. Sessies blijven soms geopend op gedeelde pc's waardoor onbevoegden toegang krijgen tot mailboxen met persoonsgegevens. Onveilige wifi in hotels of treinen maakt het eenvoudiger om sessiecookies te onderscheppen. Browsers downloaden bijlagen rechtstreeks naar lokale mappen zonder de aanvullende scanning die beheerde endpoints uitvoeren. Standaard integraties met commerciële opslagdiensten kunnen ertoe leiden dat documenten buiten het overheidstoezicht belanden. Daarnaast is er beperkte controle over apparaten die geen versleutelde schijven, actuele antivirus of compliance-registratie hebben. Zonder specifieke OWA-beleidsregels vervagen zero trust-principes en wordt het lastig om aantoonbaar te voldoen aan de BIO-paragrafen over communicatieveiligheid en toegangsbeheer. Daarom is een doelgericht ontwerp nodig waarin sessieduur, devicevoorwaarden, data loss prevention en gebruikerservaring in balans worden gebracht. Het waarom van deze maatregel is dus tweeledig: het borgt continuïteit voor medewerkers die altijd en overal moeten kunnen werken en het voorkomt dat deze openheid leidt tot datalekken, reputatieschade of toezichtmaatregelen.

Implementatie

De maatregel beschrijft hoe OWA wordt ingekaderd binnen een holistisch ontwerp dat start met helder sessiebeheer. Idle time-outs van vijftien tot dertig minuten worden per risicoprofiel vastgesteld, waarbij kritieke teams na tien minuten automatisch worden afgemeld en reguliere gebruikers maximaal een half uur inactief mogen blijven. Moderne authenticatie wordt afgedwongen via Conditional Access zodat alleen apparaten met meervoudige authenticatie en een compliant status toegang krijgen. Daarnaast wordt legacy-protocoltoegang uitgezet om POP, IMAP en basisverificatie te blokkeren. Beheer van bijlagen en gegevensuitwisseling vormt de tweede laag. Microsoft Defender voor Office 365 Safe Attachments scant iedere download in een sandbox voordat de gebruiker het bestand ziet, terwijl Safe Links actieve bescherming biedt tegen omgeleide phishing. Ongewenste bestandstypen zoals uitvoerbare bestanden of gecomprimeerde archieven met scripts worden geblokkeerd en de integratie met consumentenopslag wordt verwijderd zodat uitsluitend OneDrive voor Bedrijven en SharePoint worden toegestaan. Offline modus blijft beperkt tot apparaten die via Intune of een ander mobiel devicebeheer zijn gevalideerd, zodat e-mail niet ongemerkt wordt gecachet op onbeheerde hardware. Tot slot worden beleidsregels gedifferentieerd naar doelgroep. Contractanten krijgen een sterk beperkte OWA-ervaring waarin kalenderdeling, externe contactpersonen en mailbox forwarding zijn uitgeschakeld, terwijl bestuurders juist ondersteuning krijgen voor S/MIME-certificaten en geavanceerde zoekfuncties. Logging wordt doorgestuurd naar Microsoft Sentinel of een ander SIEM-platform zodat ongebruikelijke downloads of inloglocaties direct zichtbaar zijn. Door deze combinatie van beleidslagen ontstaat een consistent beveiligingsmodel voor browsergebaseerde e-mail.

Vereisten

Een robuust OWA-implementatieproject begint met een bijgewerkte Exchange Online-tenant waarin alle productiepostvakken al gebruikmaken van moderne authenticatie en waarin het licentiemodel voldoende capaciteiten voor Microsoft Defender voor Office 365 bevat. Zorg dat tenants op het juiste Microsoft 365-plan zijn ingericht zodat functies als Advanced Threat Protection, Intune en Azure AD Premium beschikbaar zijn. Basale hygiëne zoals het uitschakelen van POP en IMAP en het verwijderen van oude serviceaccounts vormt de noodzakelijke fundering voordat OWA-beleid effect kan hebben.

Identiteitsbeheer is de volgende voorwaarde. Azure AD moet zijn gekoppeld aan een betrouwbaar identiteitsregister met sterke wachtwoordbeleid, selfservice reset en meervoudige authenticatie. Conditional Access moet beleidssets bevatten die apparaatcompliance controleren, sessiecontext registreren en toegang blokkeren vanaf landen of netwerken die niet door de organisatie worden gebruikt. Ook is een werkende koppeling met Privileged Identity Management wenselijk zodat beheerders hun sessies tijdelijk kunnen verheffen zonder permanente rechten.

Device- en netwerkhygiëne bepalen of OWA veilig kan draaien. Er moeten richtlijnen zijn voor het gebruik van beheerde laptops, tablets en mobiele telefoons waarbij BitLocker, Secure Boot en actuele antivirus verplicht zijn. Voor situaties waarin persoonlijke apparaten worden toegestaan is een aparte risicobeoordeling nodig, inclusief duidelijke instructies over het wissen van downloads en het voorkomen van lokale synchronisatie. Daarnaast is een segmentatieplan nodig waarmee publieke werkstations of kiosken na elke sessie worden opgeschoond.

Een vierde vereiste betreft gegevensbescherming. Microsoft Defender voor Office 365, Purview Data Loss Prevention en Purview Information Protection moeten al zijn ingericht zodat e-mail automatisch wordt geclassificeerd en gevoelige bestanden niet onbeperkt kunnen worden doorgestuurd. Logische beheergroepen moeten klaarstaan in het Exchange Admin Center om mailbox policies per doelgroep toe te wijzen. Daarbij horen standaardconfiguraties voor bijlagebeperkingen, integratie met OneDrive voor Bedrijven en het afdwingen van S/MIME of TLS 1.2 plus wanneer dat nodig is.

Ook leveranciers en ketenpartners moeten in het ontwerp zijn meegenomen. Contracten met externe dienstverleners horen bepalingen te bevatten over het gebruik van OWA, logging en meldplichten bij incidenten. Richtlijnen voor uitwisseling met andere overheden of beveiligde mailoplossingen moeten duidelijk maken hoe OWA zich verhoudt tot bestaande afspraken. Dit voorkomt dat gevoelige berichten alsnog buiten de bedoelde veiligheidszone terechtkomen.

Gedegen governance maakt het verschil tussen beleid op papier en beleid in gebruik. Er moet een multidisciplinair team zijn met vertegenwoordigers van informatiebeveiliging, functioneel beheer, juristen en communicatie. Dit team definieert de boodschap aan eindgebruikers, legt procedures vast voor het melden van verdachte downloads en stelt richtlijnen op voor het gebruik van openbare computers. Training en bewustwording moeten in de planning zijn opgenomen voordat de technische wijzigingen live gaan.

Tot slot zijn test- en beheerprocessen noodzakelijk. Zorg voor een acceptatieomgeving waarin verschillende scenario's kunnen worden nagebootst, inclusief contractanten, bestuurders en medewerkers met gevoelige mailboxen. Monitoringcapaciteit moet beschikbaar zijn zodat wijzigingen snel worden geëvalueerd. Documentatie van configuraties, wijzigingen en goedkeuringen moet up-to-date zijn om aan auditvereisten te voldoen. Leg eveneens vast hoe incidentmeldingen vanuit gebruikers worden beoordeeld, automatiseer rapportages over bevindingen en beschrijf welke draaiboeken worden bijgewerkt na elke wijziging. Pas wanneer deze randvoorwaarden zijn ingevuld kan de organisatie starten met het daadwerkelijk configureren van OWA-beleid.

Implementatie

De implementatie start met een inventarisatie van bestaande OWA mailbox policies en een mapping van gebruikersgroepen naar risicoprofielen. Documenteer welke functies per groep noodzakelijk zijn en bepaal welke policies kunnen worden samengevoegd om beheer eenvoudig te houden. Tijdens deze fase wordt ook vastgesteld welke sessietijd voor elke groep acceptabel is en welke uitzonderingen door de directie zijn goedgekeurd. Vervolgens configureert het team het sessiebeheer. In Exchange Online wordt per policy de instelling voor inactiviteit op vijftien of dertig minuten gezet, aangevuld met een maximale sessieduur zodat langdurige achtergrondsessies worden voorkomen. Conditional Access-regels verplichten meervoudige authenticatie, blokkeren legacy protocolgebruik en eisen een compliant apparaat voor volledige toegang. Voor tijdelijke toegang wordt een beperkt profiel ingericht dat alleen webmail met minimale functionaliteit toestaat. Daarna wordt de gegevensbeschermingslaag aangescherpt. Safe Attachments en Safe Links worden geactiveerd voor OWA en getest met bekende voorbeeldbestanden. Het beheerteam definieert een lijst met verboden bestandstypen en koppelt deze aan de juiste policy. De integratie met consumentenopslag wordt uitgeschakeld zodat gebruikers enkel OneDrive voor Bedrijven en SharePoint kunnen selecteren. Offline modus wordt alleen toegestaan voor apparaten die in Intune als compliant staan, waarna een pilotgroep bevestigt dat de cache automatisch wordt gewist bij afmelden. Na de technische configuratie volgt segmentatie. Voor contractanten en leveranciers wordt een sterk beperkte mailbox policy gemaakt waarin functies zoals agenda-publicatie, mailboxdelegatie en contactpersonen importeren zijn uitgeschakeld. Bestuurders ontvangen juist een uitgebreid profiel met ondersteuning voor S/MIME en archiveringsfuncties. Alle policies worden via PowerShell geëxporteerd om versiebeheer mogelijk te maken en worden in de change-administratie geregistreerd. Vervolgens worden beheerprocessen geautomatiseerd. Het team bouwt scripts of Azure Automation-runbooks die nieuwe gebruikers automatisch aan de juiste policy koppelen, rapporteert maandelijks over afwijkingen en bewaakt dat uitzonderingen een einddatum hebben. Door deze automatisering blijft de configuratie schaalbaar, zelfs wanneer het aantal OWA-gebruikers sterk toeneemt tijdens een crisis of verkiezingsperiode. Tijdens deze fase wordt ook aandacht besteed aan ketentesten. Samen met het SOC worden scenario's geoefend waarin verdachte downloads vanuit OWA aanleiding zijn voor geautomatiseerde respons. De logging wordt gecontroleerd op volledigheid en de export naar Microsoft Sentinel wordt vergeleken met de lokale rapportages. Bevindingen leiden tot optimalisatie van alerts, zodat zowel technische als organisatorische signalen op elkaar aansluiten. Wanneer organisaties meerdere tenants beheren of samenwerken binnen shared services, wordt een gestandaardiseerd sjabloon opgesteld. Dit sjabloon beschrijft welke instellingen minimaal actief moeten zijn, hoe uitzonderingen worden vastgelegd en hoe escalatie verloopt wanneer een partner afwijkt van het gezamenlijke beleid. Door deze harmonisatie blijft de gebruikerservaring consistent, zelfs wanneer medewerkers tussen tenants wisselen. De laatste stap bestaat uit testen, documenteren en communiceren. Een breed samengesteld testteam doorloopt scenario's zoals inloggen vanaf een openbaar werkstation, het openen van grote bijlagen en het wisselen tussen netwerken. Bevindingen worden vastgelegd en aangepast in de configuratie. Plan ook terugvalscenario's voor kritieke processen. Pas daarna volgt de communicatiecampagne die uitlegt waarom sessies sneller aflopen, hoe gebruikers bestanden veilig delen en welke ondersteuning beschikbaar is. Zodra de directie de vrijgave tekent, wordt het beleid gefaseerd uitgerold en blijft het projectteam stand-by om eventuele incidenten direct op te vangen.

Compliance en Auditing

De inrichting van OWA moet aantoonbaar aansluiten op BIO 13.02 en 12.04 waarin eisen voor communicatieveiligheid en toegangsbeheer zijn vastgelegd. Door sessiebeperkingen en apparaatvoorwaarden strikt te documenteren kan tijdens een audit worden aangetoond dat vertrouwelijke informatie niet onbeperkt toegankelijk blijft op onbeheerde apparatuur. De maatregel draagt daarnaast bij aan BIO 2.02 doordat functiescheiding wordt ondersteund: hoogrisicogebruikers krijgen immers een andere policy dan standaardmedewerkers. De aanpak sluit tevens aan op ISO 27001 Annex A.13 en A.9. Toegangscontrole wordt geborgd door Conditional Access, terwijl informatieoverdracht wordt beschermd via versleutelde kanalen en gecontroleerde bijlageverwerking. AVG-artikel 32 schrijft passende technische en organisatorische maatregelen voor; het combineren van Safe Attachments, data loss prevention en beperking van offline caching vormt een concreet antwoord op die eis. Ook artikel 25 (privacy by design) wordt ondersteund omdat de beveiligingsinstellingen standaard zijn ingeschakeld en pas na risicobeoordeling versoepeld mogen worden. Voor auditors is het essentieel dat alle configuratiestappen traceerbaar zijn. Documenteer daarom per mailbox policy de verantwoordelijke eigenaar, change-referentie, datum van goedkeuring en de reden voor eventuele afwijkingen. Exporteer instellingen regelmatig via PowerShell en sla deze op in een controleerbaar archief zodat inspecties eenvoudig kunnen aantonen dat instellingen niet ongezien zijn aangepast. Compliance betekent daarnaast dat logging en monitoring voldoen aan bewaartermijnen. Koppel OWA-activiteit aan Microsoft Sentinel of een ander SIEM zodat verdachte downloads, mislukte inlogpogingen en beleidswijzigingen automatisch worden gerapporteerd. Zorg dat logboeken minimaal drie jaar beschikbaar blijven, conform de eisen die veel toezichthouders stellen. Rapporteer periodiek aan de Chief Information Security Officer zodat bestuurders inzicht hebben in trendanalyses en verbeteracties. Een aanvullend aandachtspunt is de koppeling met gegevensbescherming en DPIA's. Bij projecten waarbij nieuwe user journeys worden toegevoegd, moet worden beoordeeld of aanvullende privacyrisico's ontstaan door het tijdelijk cachen van gegevens of het delen met derden. Documenteer de uitkomsten in het verwerkingsregister en verwijs naar de relevante OWA-maatregelen zodat de nalevingsketen sluitend is. Een ander speerpunt is ketenregie. Veel overheidsorganisaties werken in samenwerkingsverbanden waarbij meerdere partijen dezelfde tenant gebruiken. Leg contractueel vast dat partners dezelfde sessietijden, DLP-regels en opslagbeperkingen hanteren en spreek af hoe bewijs wordt geleverd. Richt een gezamenlijke auditkalender in zodat verificaties gelijktijdig plaatsvinden en resultaten met alle betrokken partijen worden gedeeld. Documenteer bovendien welke risicoacceptaties zijn gedaan, wie deze heeft ondertekend en welke compenserende maatregelen gelden. Dit voorkomt discussie tijdens externe audits en maakt duidelijk dat eventuele afwijkingen bewust zijn gekozen en periodiek worden heroverwogen. Naast de beleidsdocumentatie moeten medewerkers structureel worden getraind in het herkennen van OWA-beperkingen. Plan jaarlijkse awareness-sessies waarin uitgelegd wordt waarom offline caching niet altijd beschikbaar is, hoe gebruikers veilig documenten delen en op welke manier zij beveiligingsincidenten melden. Koppel deze opleiding aan het reguliere BIO-continu verbeterproces zodat naleving aantoonbaar blijft. Tot slot moeten gebruikers geïnformeerd worden over de beperkingen rond offline opslag, extern delen en sessieduur. Neem deze instructies op in privacyverklaringen en gebruikersreglementen zodat aan de transparantieverplichtingen wordt voldaan. Door juridische, security- en operations-teams samen te werken ontstaat een consistent verhaal waarmee organisaties bij controles kunnen aantonen dat OWA niet slechts technisch maar ook procedureel onder controle is. Daarmee wordt aangetoond dat deze maatregel onderdeel is van de bredere kwaliteitscyclus rond informatiebeveiliging.

Monitoring

Gebruik PowerShell-script outlook-web-app.ps1 (functie Invoke-Monitoring) – Effectief toezicht op OWA bestaat uit een combinatie van geautomatiseerde controles en menselijke beoordeling. Dagelijks worden de belangrijkste telemetriebronnen verzameld: Exchange Online-auditlogs, Defender voor Office 365-rapportages en Conditional Access-signalen. Door deze bronnen naast elkaar te leggen ontstaat inzicht in sessieduur, geografische afwijkingen en verdachte downloadpatronen. Monitoring richt zich niet alleen op incidenten, maar ook op trends zoals gebruikers die structureel tegen de sessietijd aanlopen of beleidsupdates die niet zijn uitgerold. Het script code/design/collaboration/outlook-web-app.ps1 met de functie Invoke-Monitoring vormt het hart van de technische controle. Het script leest via PowerShell alle OWA mailbox policies uit, vergelijkt de ingestelde sessietimers, bijlagebeperkingen en opslagopties met de referentiewaarden en levert een rapport in JSON- en CSV-indeling. Afwijkingen worden gemarkeerd met een risicocategorie en een aanbeveling voor herstel. Het script kan vanuit Azure Automation of een beveiligde beheerwerkplek draaien en schrijft zijn resultaten weg naar een centrale SharePoint-bibliotheek voor verdere analyse. Naast de beleidscontrole analyseert het script loggegevens om te zien of gebruikers de beperkingen proberen te omzeilen. Het inventariseert hoeveel downloads vanaf niet-beheerde apparaten plaatsvonden, welke bestandstypen zijn geblokkeerd en of er pogingen waren om externe opslag te gebruiken. Deze cijfers worden gekoppeld aan Microsoft Sentinel, waar dashboards afwijkingen visueel weergeven en waar geautomatiseerde responsplaybooks kunnen worden geactiveerd zodra een drempel wordt overschreden. Zo ontstaat een continu beeld van dreigingen en naleving. De operationele monitoring verloopt via een wekelijks overleg tussen informatiebeveiliging, functioneel beheer en servicedesk. Zij bespreken het scriptresultaat, vergelijken dat met gebruikersmeldingen en bepalen of aanvullende acties nodig zijn. Essentiële prestatie-indicatoren zijn onder meer het aantal incidenten per duizend OWA-gebruikers, de tijd tussen detectie en triage en de mate waarin sessieafmeldingen correct worden gelogd. Door deze governancecyclus te borgen, blijft duidelijk wie verantwoordelijk is voor opvolging. Even belangrijk is het vastleggen van service levels. Bepaal welke responstijd hoort bij kritieke signalen, welk escalatiepad geldt buiten kantooruren en hoe bevindingen worden gedeeld met ketenpartners. De output van het script kan automatisch naar een Teams-kanaal of e-mailgroep worden gestuurd zodat verantwoordelijken zonder vertraging kunnen handelen. Voor compliance-rapportage worden de scriptresultaten per kwartaal geanalyseerd op structurele afwijkingen per organisatieonderdeel. Het team maakt heatmaps waarin zichtbaar wordt welke directies vaker tegen blokkades aanlopen, hoe vaak uitzonderingen zijn aangevraagd en of specifieke voorzieningen (bijvoorbeeld publieke balies) extra begeleiding nodig hebben. Deze inzichten worden gedeeld met de functionaris gegevensbescherming en vormen input voor het jaarlijkse directieverslag over informatiebeveiliging. Door dit vaste ritme kunnen audits sneller worden voorbereid en blijven verbeteracties aantoonbaar traceerbaar. Tot slot wordt monitoring gebruikt om verbeteringen te initiëren. Wanneer bijvoorbeeld blijkt dat veel medewerkers vlak voor de automatische afmelding hun werk verliezen, wordt bekeken of aanvullende communicatie of een iets langere time-out nodig is. Worden er juist veel downloads vanaf onbeheerde apparaten gezien, dan wordt het beleid aangescherpt of wordt een extra verificatiestap toegevoegd. Het monitoringrapport bevat steeds een managementsamenvatting die aan de CISO en proceseigenaren wordt verstuurd zodat besluitvorming snel kan plaatsvinden. Zo blijft OWA niet alleen veilig, maar ook aantoonbaar onder controle, wat verrassingen tijdens steekproeven van toezichthouders voorkomt en tijdige escalatiepaden biedt..

Remediatie

Gebruik PowerShell-script outlook-web-app.ps1 (functie Invoke-Remediation) – Wanneer monitoring een afwijking signaleert, start een gestandaardiseerde remediatieketen. De eerstelijns servicedesk registreert het incident, koppelt het aan het betreffende onderdeel van het OWA-beleid en bepaalt of het gaat om een configuratieafwijking, een gebruikersfout of een dreiging. Het doel is om binnen vier uur een voorlopige classificatie te hebben zodat kritieke situaties direct onderkend worden. Het script code/design/collaboration/outlook-web-app.ps1 ondersteunt dit proces met de functie Invoke-Remediation. Deze functie kan doelgericht een mailbox policy opnieuw toepassen, sessietimers herstellen of ongewenste instellingen terugzetten naar de standaard. Vooraf wordt een export van de huidige configuratie gemaakt zodat rollback mogelijk blijft. De uitvoer toont welke wijzigingen zijn doorgevoerd, door welk account en op welk tijdstip, waardoor het change-proces volledig traceerbaar blijft. Na de technische correctie volgt validatie. Functioneel beheer controleert of de betrokken gebruiker of groep weer de juiste ervaring heeft en of de beveiligingsmaatregel daadwerkelijk actief is. Indien nodig wordt een aanvullende Conditional Access-regel geactiveerd of wordt de gebruiker tijdelijk in quarantaine gezet totdat het apparaat voldoet aan de eisen. Elke stap wordt vastgelegd in het ticketsysteem zodat auditors kunnen volgen hoe het incident is afgehandeld. De remediatieaanpak omvat ook root-causeanalyse. Komt dezelfde afwijking vaker voor, dan wordt onderzocht of documentatie ontbreekt, of er misschien een automatische synchronisatie faalt of dat een beheerder onvoldoende bevoegdheden heeft. De analyse kan leiden tot updates van het script, aanvullende alerting in Sentinel of nieuwe communicatie naar gebruikers. Zo wordt voorkomen dat incidenten zich blijven herhalen. Bij grotere incidenten wordt een apart crisisteam geactiveerd dat naast e-mail ook andere kanalen beoordeelt, zoals mobiele apps en hybride vergaderruimten. Dit team stemt af met privacy officers en communicatie zodat berichtgeving naar burgers en partners zorgvuldig verloopt. Het script helpt hierbij door exact aan te geven welke mailboxen zijn gecorrigeerd en welke nog aandacht nodig hebben. Communicatie richting eindgebruikers en leidinggevenden maakt essentieel onderdeel uit van de remediatie. Zodra een maatregel is genomen, ontvangen betrokkenen een kort statusbericht met uitleg over de oorzaak, impact en eventuele aanvullende acties die zij moeten ondernemen. Deze berichten worden afgestemd met het communicatieteam zodat de toon consistent blijft en zodat dezelfde instructies ook op intranet en in handleidingen worden bijgewerkt. Verslagen worden opgeslagen in het centrale kwaliteitsdossier zodat toezichthouders de opvolging gemakkelijk kunnen volgen. Elke afgesloten casus levert input voor een structurele verbetercyclus. Maandelijks beoordeelt het securityboard alle incidentrapporten, identificeert patronen en koppelt bevindingen aan projecten zoals devicevernieuwing of aanvullende bewustwording. Waar nodig worden acties opgenomen in de roadmap en krijgt een verantwoordelijke eigenaar de opdracht om de opvolging te bewaken. Zo blijft het remediatieproces niet beperkt tot technische herstelacties, maar leidt het aantoonbaar tot organisatorische verankering. Wanneer het incident volledig is opgelost, levert het team een afsluitrapport op met daarin de impact, genomen maatregelen, resterende risico's en eventuele vervolgacties zoals bewustwordingssessies. Het rapport wordt gedeeld met de CISO, de eigenaar van het proces en de lijnmanager van de betrokken afdeling. Door dit ritme consequent vol te houden ontstaat een cultuur waarin afwijkingen snel worden gecorrigeerd en waarin OWA continu wordt verbeterd en auditproof is..

Compliance & Frameworks

• BIO: 13.02.01 - Webmail security
• ISO 27001:2022: A.13.2.1 - Information transfer

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

Configureer OWA met sessietime-outs van 15-30 minuten, blokkeer externe opslag behalve OneDrive voor Bedrijven, schakel Safe Attachments en Safe Links in, beperk offline caching tot compliant apparaten en wijs OWA mailbox policies toe per risicoprofiel. Uitvoering via Exchange Admin Center en PowerShell duurt circa 2-4 uur en vereist geen extra licenties boven Defender Plan 2.

• Implementatietijd: 4 uur
• FTE required: 0.02 FTE