Blackboard heeft een robuust beveiligingsprogramma dat niet alleen is ontwikkeld om beveiligingsproblemen te voorkomen, maar ook om ze in een vroeg stadium op te sporen. Blackboard voert doorlopend interne beveiligingstests uit op codeniveau (statische analyse) en toepassingsniveau (dynamische analyse) om er zeker van te zijn dat alles voldoet aan de verwachtingen van zowel Blackboard als onze klanten.

Om tunnelvisie te voorkomen, laten we regelmatig penetratietests uitvoeren door externe bedrijven die hierin zijn gespecialiseerd. Eventuele verbeterpunten worden direct geregistreerd voor aanpassing.

Het is belangrijk om te weten dat het beveiligingsprogramma van Blackboard altijd werk in uitvoering zal blijven. We stellen steeds alles in het werk om de lat nog iets hoger te leggen als het gaat om beveiligingsfuncties en stabiliteit in Blackboard Learn.


Gebouwd met beveiliging in het achterhoofd

Blackboard stelt alles in het werk om veilige toepassingen aan te bieden aan onze klant. Bij de ontwikkeling van Blackboard Learn wordt een set beveiligingsrichtlijnen gehanteerd die is afgeleid van verschillende organisaties, zoals OWASP (Open Web Application Security Project), inclusief specifieke maatregelen voor de tien kwetsbaarste punten die door OWASP zijn opgesteld. Blackboard past deze praktijken toe in alle fasen van de software-ontwikkeling.

Blackboard gebruikt verschillende methoden voor de bescherming van onze toepassingen, waaronder top-down beoordeling van beveiligingsrisico's via het modelleren en analyseren van bedreigingen, evenals bottom-up detectie van bedreigingen op codeniveau door statische analyse, dynamische analyse en handmatige penetratietests.

Blackboard volgt de richtlijnen voor best practices van diverse organisaties om de beveiliging van de de producten en het programma van Blackboard Learn verder te verbeteren. We noemen een paar van deze organisaties:

  • National Institute of Standards and Technology (NIST)
  • Europees Agentschap voor netwerk- en informatiebeveiliging (ENISA)
  • SANS Institute
  • Open Web Application Security Project (OWASP)
  • Cloud Security Alliance (CSA)

Modelleren van bedreigingen

Als er nieuwe functies worden ontwikkeld, beoordeelt het Security Team de vereisten en het systeemontwerp om beveiligingsrisico's op voorhand weg te nemen. Dit doen ze door het modelleren van bedreigingen (Threat Modeling). Dit is een gestructureerd proces waarbij beveiligingsrisico's worden vastgesteld die inherent zijn aan de beoordeelde functie zodat de juiste tegenmaatregelen kunnen worden bepaald en toegepast.


Veilig coderen en de tien kwetsbaarste punten volgens OWASP

Producten van Blackboard worden ontwikkeld volgens een set beveiligingsrichtlijnen die is afgeleid van OWASP, inclusief specifieke maatregelen voor de tien kwetsbaarste punten die zijn opgesteld door OWASP voor 2013. Aangezien de namen van de kwetsbare plekken rechtstreeks zijn overgenomen van de site van OWASP, blijven deze hier onvertaald.

A1: Injection (SQL/DOM/LDAP injection)Onze coderingsnorm is om bindvariabelen te gebruiken en literals te voorkomen die worden getranscribeerd naar SQL-instructies. Xpath wordt nergens in de toepassing gebruikt; LDAP-functionaliteit is beperkt tot verificatie.
A2: Broken Authentication and Session ManagementWe nemen verschillende maatregelen om te voorkomen dat sessiecookies kunnen worden onderschept of anderszins misbruikt. Sinds april 2014 wordt Learn uitsluitend uitgevoerd onder TLS, zodat voor alle cookies de vlag Secure is ingesteld. Daarnaast proberen we om onverwachte veranderingen van de clientstatus te detecteren (bijvoorbeeld een sessie die afkomstig is van onverwachte IP-adressen). Cookies voor sessiebeheer worden ingesteld op HttpOnly (opmerking: JSESSIONID wordt niet gebruikt voor sessiebeheer en heeft daarom niet de vlag HttpOnly).
A3: Cross-site Scripting (XSS)Het uitvoeren van scripts op verschillende sites wordt voorkomen door het gebruik van gedeelde bibliotheken zoals ESAPI en ontwikkelstandaarden. Alle door de gebruiker verzonden tekstinvoer moet worden gecontroleerd door sanitizer-methoden; alle andere invoer (datums, selectie-/optiewaarden) moet worden gegenereerd op basis van domeinobjecten met typeaanduiding in plaats van rechtstreeks te worden getranscribeerd vanuit gebruikersinvoer.
A4: Insecure Direct Object ReferencesVerwijzingen naar toepassingsobjecten vinden allemaal plaats via "id's" die meestal zijn gekoppeld aan de primaire sleutel. Alle objecten worden echter gekoppeld aan een "context" en alle beveiligingscontroles worden ook uitgevoerd in een "context". Stel dat in een aanvraag een verwijzing is opgenomen naar een "bericht-id" die is gekoppeld aan een bericht in een discussieruimte voor een cursus. De standaardprocedure in Blackboard is dan om een autorisatiecontrole uit te voeren voor de bevoegdheid die is gekoppeld aan de rol van een gebruiker in de cursus. In gevallen waarin deze procedure niet juist wordt afgedwongen, is er een eenvoudige oplossing, aangezien alle beveiligde gegevensentiteiten in het systeem zijn gekoppeld aan een beveiligingscontext (cursus of domein).
A5: Security MisconfigurationBlackboard Learn volgt een beleid van 'standaard beveiligen', waarbij de release-opmerkingen en documentatie wordt aangepast wanneer speciale aandacht voor systeembeheerders noodzakelijk is. Blackboard moedigt klanten aan om de handleiding met best practices voor een veilige configuratie te volgen.

Infrastructuur

Klanten worden aangemoedigd om Apache™ 2.x te gebruiken met gedocumenteerde aanbevelingen voor het uitsluitend toestaan van krachtige ciphers voor beveiliging van de transportlaag. Blackboard past regelmatig Security Advisories aan die te maken hebben met de infrastructuur van Blackboard Learn om ervoor te zorgen dat deze goed beveiligd is tegen beveiligingsrisico's.

Beveiliging controleren

Beveiligingsgebeurtenissen worden vastgelegd in een van de drie beveiligingslogboeken. Het Security Event Framework biedt een set standaardgebeurteniscodes, een standaardlogboekindeling, detailniveau van velden en verantwoording. De set gebeurtenissen die wordt vastgelegd in elke gebeurteniscode wordt voortdurend uitgebreid.

Referenties

Tijdens de installatie moeten systeembeheerders verplicht wachtwoorden instellen.

Gegevenslekken en foutafhandeling

Er worden op alle pagina's standaardprocedures voor foutafhandeling gehanteerd (via een standaardpaginasjabloon en een tagbibliotheek), met als resultaat een standaarduitvoer voor alle fouten, met name niet-herkende fouten. De standaarduitvoer bevat een stacktrace (klein gegevenslek), maar geen van de gegevens die werden verwerkt op het moment van mislukken van de aanvraag en is alleen zichtbaar voor gebruikers met toegang op beheerdersniveau. Onbevoegde gebruikers (zoals studenten) kunnen geen gedetailleerde stacktraces zien.
A6: Sensitive Data ExposureGebruikerswachtwoorden worden door een hash gehaald, niet gecodeerd. Vanaf Blackboard Learn release 9.1 Service Pack 12 worden gebruikerswachtwoorden door een hash gehaald en standaard versleuteld met SHA-512. De Product Security Roadmap van Blackboard Learn bevat plannen voor het afhandelen van systeemwachtwoorden die worden gebruikt voor het starten van toepassingen die standaard zijn beveiligd door toegangscontrole van het besturingssysteem en bestandssysteem. Blackboard Learn ondersteunt uitvoering onder SSL. Het is echter de verantwoordelijkheid van de ontwikkelaar dat SSL goed is geconfigureerd. SSL Offloading wordt ook ondersteund door Blackboard Learn release 9.1 Service Pack 8 en hoger.
A7: Missing Function Level Access ControlDit wordt beheerd op twee niveaus: door te vereisen dat bedrijfslogica autorisatiecontroles afdwingt en door ervoor te zorgen dat QA-testscenario's autorisatievereisten voor verschillende schermen omvatten. Alle schermen/koppelingen worden potentieel weergegeven; er zijn geen "verborgen" URL's die handmatige invoer vereisen. Als gevolg hiervan wordt van de toepassing verwacht dat deze de toegang tot URL's screent voordat er wordt geprobeerd om deze weer te geven.
A8: Cross-site Request Forgery (CSRF)Ons beveiligings-framework volgt de aanbevelingen van OWASP voor per-aanvraag nonce-waarden en alleen semantiek voor POST. AJAX-aanvragen gebruiken per-sessie nonce-waarden. DWR gebruikt dubbele cookie-verzending van een per-sessie nonce-waarde.
A9: Using Components with Known VulnerabilitiesDit probleem wordt voorkomen door regelmatig kwetsbaarheidsscans uit te voeren van zowel onze infrastructuur als de softwarepakketten van derden om componenten te identificeren met bekende zwakke plekken en om een roadmap te ontwikkelen om die componenten bij te werken met beschikbare patches.
A10: Unvalidated Redirects and ForwardsDe norm voor veilig coderen van Blackboard Learn vereist dat bij redirects en forwards wordt gecontroleerd of het lokale adressen betreft. Er wordt regelmatig getest op dit beveiligingsrisico.

Eerdere categorie in de top tien van OWASP

Malicious File ExecutionBestanden die worden geüpload door eindgebruikers zonder bevoegdheden worden nooit gebruikt als uitvoerbare bestanden. Bevoegde gebruikers (zoals systeembeheerders) kunnen echter wel uitvoerbare pakketten (zogenaamde Building Blocks) uploaden om de functionaliteit van het systeem uit te breiden. Er wordt vanuit gegaan dat systeembeheerders de risico's hiervan begrijpen en de aanbevelingen van de leverancier en aanbevolen procedures voor change-management volgen bij de installatie van Building Blocks van derden.

Uitspraken over toekomstige verwachtingen, plannen en vooruitzichten voor Blackboard vertegenwoordigen de huidige standpunten van het bedrijf. De werkelijke resultaten kunnen als gevolg van diverse belangrijke factoren wezenlijk verschillen. Het bedrijf verwacht dat toekomstige gebeurtenissen en ontwikkelingen van invloed zullen zijn op de standpunten van het bedrijf. Hoewel het bedrijf zich het recht voorbehoudt om deze uitspraken in de toekomst aan te passen, kan dit nooit als verplichting jegens het bedrijf worden ingebracht.