Blackboard har ett robust säkerhetsprogram som inte enbart verkar för att förhindra uppkomsten av säkerhetsproblemen, utan som också kan hitta och utrota dem. Blackboard utför kontinuerligt interna säkerhetstester på kodnivå (statisk analys) och programnivå (dynamisk analys) för att säkerställa att det uppfyller både Blackboards och våra kunders förväntningar. I syfte att regelbundet få nya perspektiv på våra program genomför Blackboard säkerhetspenetreringstester med hjälp av utomstående säkerhetsleverantörer. Eventuella problem som upptäcks åtgärdas snabbt.

Det är viktigt att tänka på att Blackboards säkerhetsprogram är en process under utveckling. Vi strävar efter kontinuerlig förbättring och höjer hela tiden ribban för säkerhetsfunktionerna och robustheten i Blackboards produkter.


Utformat med fokus på säkerhet

Vi på Blackboard har som mål att våra kunder ska arbeta i säkra program. Vi utvecklar våra produkter i enlighet med riktlinjer för säkerhetsteknik från flera olika organisationer, till exempel Open Web Application Security Project (OWASP), inklusive specifika motåtgärder för OWASP:s tio vanligaste sårbarheter. Blackboard inkorporerar dessa säkerhetsrutiner i alla faser av programvarans utvecklingslivscykel (SLDC).

Blackboard utnyttjar flera olika metoder för att skydda sina program, inklusive top-down-säkerhetsutvärdering via hotmodeller och analys samt bottom-up-detektering av hot på kodnivå genom statisk analys, dynamisk analys och manuella penetreringsförsök.

För att stärka säkerheten i våra produkter och program följer vi på Blackboard riktlinjer för bästa praxis från flera olika organisationer. Några av dessa organisationer är:

  • National Institute of Standards and Technology (NIST)
  • European Network and Information Security Agency (ENISA)
  • SANS Institute
  • Open Web Application Security Project (OWASP)
  • Cloud Security Alliance (CSA).

Hotmodeller

I takt med att nya funktioner utvecklas utvärderar säkerhetsteamet kraven och systemutformningen för att bidra till att minska riskerna genom att ta fram hotmodeller. Utvecklingen av hotmodeller är en strukturerad process där säkerhetshot söm rör den granskade funktionen identifieras, så att lämpliga säkerhetsmotåtgärder kan fastställas och tillämpas.


Säker kodning och OWASP:s tio vanligaste sårbarheter

Blackboards produkter utvecklas enligt en uppsättning utvecklingsriktlinjer från OWASP, inklusive specifika motåtgärder för OWASP:s tio vanligaste sårbarheter för 2013.

A1: Injektion (SQL-/DOM-/LDAP-injektion)Vår kodningsstandard består i att använda bundna variabler och undvika litteraler som transkriberas till SQL-påståenden. LDAP-funktionaliteten är begränsad till autentisering.
A2: Ej fungerande autentisering och sessionshanteringBlackboards produkter körs enbart under TLS, så alla cookies krypteras.
A3: Webbkodinjektion (XSS)Webbkodinjektion minskas genom användning av delade bibliotek, som ESAPI och utvecklingsstandarder. All textinmatning som görs av slutanvändare förväntas skickas vidare via rensningsmetoder. Alla andra typer av inmatning (datum, värden för val/alternativ) förväntas genereras från angivna domänobjekt, snarare än transkriberas direkt från användarens inmatning.
A4: Osäkra direkta objektreferenserAlla programobjekt hänvisas via ”id:n” som vanligtvis är kopplade till den primära nyckeln. Alla objekt kopplas däremot till, och alla säkerhetskontroller utförs mot, en ”kontext”. En begäran kan till exempel hänvisa till ett ”meddelande-id” som är ett anslag i diskussionsforumet för en kurs. Blackboards standard är att utföra auktoriseringskontrollen efter den behörighet som är kopplad till en användares roll.
I de fall då denna standard inte tillämpas på korrekt sätt är det enkelt att vidta en åtgärd eftersom alla skyddade dataenheter i systemet är kopplade till en säkerhetskontext (kurs eller domän).
A5: Felkonfigurering av säkerhetBlackboard följer en ”säker som standard”-policy, där versionsinformation och dokumentation utnyttjas när ett särskilt övervägande från systemadministratören krävs. Blackboard uppmuntrar kunderna att följa dess bästa praxis för säker konfiguration om en sådan finns tillgänglig och är relevant för kundens specifika Blackboard-produkt.

Säkerhetsgranskning
Säkerhetshändelser loggas i säkerhetsspecifika loggar.

Informationsläckage och felhantering
Standardhantering av fel används för alla sidor (via en mall för standardsida och ett taggbibliotek), vilket resulterar i standardutdata för alla fel, särskilt okända fel. Dessa standarddata kan innehålla en stackspårning (mindre informationsläckage), men inga av de data som bearbetades när begäran misslyckades, och de är endast synliga för personer med åtkomst på administratörsnivå. Användare som saknar behörigheter (som deltagare) kan inte se detaljerade stackspårningar.

A6: Exponering av känsliga uppgifterBlackboards standard är att hasha och salta användarlösenord med SHA-160.

Blackboards produkter har stöd för att köras under TLS. Det är dock distributörernas ansvar att konfigurera TLS på rätt sätt när deras produkt har sin egen server.

A7: Brist på åtkomstkontroll på funktionsnivåDetta hanteras på två nivåer – genom krav på att affärslogik genomdriver behörighetskontroller och genom att se till att fall med kvalitetstest omfattar behörighetskrav för olika kontroller.
A8: Förfalskning av webbegäran (CSRF)Vårt säkerhetsramverk följer OWASP:s rekommendationer för nonce-värden per begäran samt enbart POST-semantik. AJAX-begäranden använder nonce-värden per session.
A9: Använda komponenter med kända sårbarheterDetta begränsas genom regelbundna sårbarhetsgenomsökningar av både vår infrastruktur och programvarupaketen från tredje part med syfte att identifiera komponenter med kända sårbarheter och för att utveckla en vägkarta för att uppgradera dem med tillgängliga korrigeringsfiler.
A10: Ej validerade omdirigeringar och vidarebefordringarBlackboards säkra kodningsstandard kräver omdirigeringar och vidarebefordringar för att verifiera att de är lokala adresser. Den här sårbarheten testas regelbundet.

Tidigare kategorier i OWASP:s tio vanligaste sårbarheter

Körning av skadlig filFiler som laddats upp av icke-privilegierade slutanvändare används aldrig som körbara filer. Privilegierade användare (dvs. systemadministratörer) kan dock ladda upp körbara paket som kallas Building Blocks och som utökar funktionerna i systemet. Det antas att systemadministratörer förstår riskerna och följer lämplig praxis för leverantörsgranskning och ändringshantering vad gäller installation av alla Building Blocks från tredje part.

Alla påståenden om framtida förväntningar, planer och utsikter för Blackboard representerar företagets aktuella åsikter. De faktiska resultaten kan komma att skilja sig avsevärt till följd av olika viktiga faktorer. Företaget räknar med att framtida händelser och utvecklingar resulterar i att företagets åsikter ändras. Även om företaget kan välja att någon gång i framtiden uppdatera dessa påståenden avsäger det sig dock specifikt all skyldighet att göra det.


Sårbarhetshanteringsförpliktelse och offentlighetspolicy

Blackboards program för sårbarhetshantering regleras av den offentliga Sårbarhetshanteringsförpliktelsen och offentlighetspolicyn nedan. Ingen programvaruleverantör är perfekt – om en sårbarhet identifieras i en lanserad produkt är Blackboards säkerhetsteam redo att ta itu med den.

För hjälp med att logga in måste du kontakta ditt lärosätes IT-support. Blackboard har inte tillgång till ditt lärosätes kontoinformation, webbplatser eller innehåll. Om du inte vet hur man kontaktar helpdesk kan du söka på nätet efter ditt lärosätes namn + helpdesk eller leta efter en supportlänk eller kontaktinformation på din inloggningssida.

Blackboard förpliktar sig att lösa säkerhetsproblem snabbt och noggrant. Sådana lösningar kan leda till att en säkerhetsrekommendation och/eller nödvändig produktuppdatering släpps för våra kunder. För att skydda våra kunder och deras data önskar vi att sårbarheter rapporteras till oss på ett ansvarsfullt och konfidentiellt sätt så att vi kan undersöka dem och agera. Sårbarheter ska inte tillkännages förrän en produktuppdatering har utvecklats, genomgått omfattande tester och gjorts tillgänglig för licensierade kunder.

Blackboard-produkter är komplexa. De körs på olika maskinvaru- och programvarukonfigurationer och är anslutna till många tredjepartsprogram. Alla programvaruändringar, stora som små, kräver noggrann analys, samt utveckling och implementering i flera produktlinjer och versioner. Programvaran måste även genomgå lokalisering, tillgänglighet och testning som är lämplig för dess omfattning, komplexitet och allvarlighetsgrad. Eftersom våra produkter är av avgörande betydelse för våra kunder måste Blackboard se till att de fungerar korrekt, inte bara i våra testanläggningar, utan även i kundmiljöer. Blackboard kan därför inte ange specifika tider då produktuppdateringar offentliggörs, men vi strävar efter att arbeta snabbt.

Illvilliga parter utnyttjar ofta programvarors sårbarheter genom att dekompilera publicerade säkerhetsrekommendationer och produktuppdateringar. Det är viktigt för kunderna att snabbt uppdatera programvaran och använda vår allvarlighetsvärdering som grund för bättre schemaläggning av uppgraderingar. Därför är det endast lämpligt att diskutera sårbarheten offentligt efter att kunderna har möjlighet att erhålla produktuppdateringar.

Test för säkerhetsproblem

Du bör genomföra alla säkerhetstester mot produktversioner som inte är i produktion för att minimera risken för data och tjänster.


Så här rapporterar du en sårbarhet

Dela information om den potentiella sårbarheten konfidentiellt genom att fylla i ett formulär för sårbarhetsinlämning.

Ge information om den potentiella sårbarheten så att Blackboards säkerhetsteam kan bekräfta och återskapa problemet snabbt. Utan ovanstående information kan det vara svårt, eller till och med omöjligt, att lösa den möjliga sårbarheten. Rapporter som pekar på flera möjliga sårbarheter utan information kommer inte att åtgärdas utan ytterligare förtydliganden. Information som ska anges:

  • typ av sårbarhet
  • om informationen har publicerats eller delats med andra parter
  • berörda produkter och versioner
  • berörda konfigurationer och
  • stegvisa instruktioner eller beviskod för att återskapa problemet.

Blackboards säkerhetsförpliktelse

För alla säkerhetsrapportörer som följer den här principen kommer Blackboard att försöka göra följande:

  • bekräfta att rapporten har tagits emot
  • utforska i tid, och bekräfta om möjligt den potentiella sårbarheten
  • ange en plan och tidsram för att lösa sårbarheten om det behövs och
  • meddela den som rapporterat om sårbarheten när problemet är löst.

Erkännande av bidrag

Blackboard har inte något belöningsprogram för sårbarheter. Det innebär att Blackboard inte ger erkännande eller kompensation för rapportering av säkerhetsproblem.