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 bij onze toepassingen 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-producten.


Gebouwd met beveiliging in het achterhoofd

Blackboard stelt alles in het werk om veilige toepassingen aan te bieden aan onze klanten. Blackboard ontwikkelt onze producten aan de hand van een set beveiligingsrichtlijnen 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-downbeoordeling' van beveiligingsrisico's via het modelleren en analyseren van bedreigingen, evenals 'bottom-updetectie' 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 onze producten en programma's 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 10 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. LDAP-functionaliteit is beperkt tot verificatie.
A2: Broken Authentication en Session ManagementBlackboard-producten worden alleen onder TLS uitgevoerd, dus alle cookies zijn versleuteld.
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 eindgebruiker 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 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 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, wanneer deze beschikbaar en relevant is voor het specifieke Blackboard-product.

Beveiliging controleren
Beveiligingsgebeurtenissen worden vastgelegd in beveiligingslogboeken.

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 mogelijk 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 ExposureWachtwoorden worden bij Blackboard standaard door een hash gehaald en versleuteld met SHA-160.

Blackboard-producten ondersteunen uitvoering onder TLS; het is echter de verantwoordelijkheid van de ontwikkelaar dat TLS goed is geconfigureerd wanneer het product zelfgehost is.

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.
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.
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 vereist dat bij redirects en forwards wordt gecontroleerd of het lokale adressen betreft. Er wordt regelmatig getest op dit beveiligingsrisico.

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.