Blackboard har et robust sikkerhetsprogram som ikke bare griper inn for å hindre at sikkerhetsproblemer forekommer, men også fjerner dem. Blackboard utfører kontinuerlig intern sikkerhetstesting på kodenivå (statisk analyse) og appnivå (dynamisk analyse) for å sikre at alt oppfyller både Blackboards og kundenes forventninger. I tillegg ber vi jevnlig eksterne sikkerhetsleverandører om å utføre penetreringstesting av sikkerheten for å få nye øyne på appene våre. Eventuelle problemer som oppdages, blir raskt reparert.

Det er viktig å være klar over at Blackboards sikkerhetsprogram stadig vokser og modnes. Vi prøver hele tiden å bli bedre, for å flytte grensene når det gjelder sikkerhetsfunksjoner og robusthet i Blackboard-produktene.


Utviklet med sikkerhet i tankene

Blackboard har som fokus å levere kundene sikre apper. Alle produkter vi utvikler, er bygget på et sett med retningslinjer for sikkerhetsutvikling som er avledet fra en rekke organisasjoner, for eksempel Open Web Application Security Project (OWASP), inkludert spesifikke mottiltak for OWASPs ti viktigste sårbarheter. Blackboard inkorporerer disse sikkerhetspraksisene i alle faser av programvarens utviklingssyklus (SDLC – Software Development Lifecycle).

Vi bruker flere metoder til å beskytte appene våre, deriblant sikkerhetsvurderinger «ovenfra og ned» ved hjelp av trusselsmodellering og analyse samt trusselsoppdagelse «nedenfra og opp» ved hjelp av statisk analyse, dynamisk analyse og manuell penetreringstesting.

Blackboard følger retningslinjer for gode fremgangsmåter fra mange organisasjoner for å få bedre sikkerhet for produktene og programmene våre. Her er noen slike organisasjoner:

  • 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)

Trusselsmodellering

Når nye funksjoner utvikles, vurderer sikkerhetsteamet kravene og systemdesignet, for å bidra til å redusere risikoene ved å utføre trusselsmodellering. Trusselsmodellering er en strukturert prosess hvor det blir identifisert sikkerhetstrusler som er relevante for funksjonen som gjennomgås, slik at det kan identifiseres og tas i bruk egnede sikkerhetsrelaterte mottiltak.


Sikker koding og OWASPs ti viktigste sårbarheter

Alle Blackboard-produkter utvikles i samsvar med et sett retningslinjer for utvikling som er avledet fra OWASP, deriblant spesifikke mottiltak for OWASPs ti viktigste sårbarheter for 2013.

A1: Injeksjon (SQL-/DOM-/LDAP-injeksjon)Kodestandarden vår er å bruke bind-variabler og unngå å litteraler som er transkribert i SQL-uttrykk. LDAP-funksjonalitet brukes bare til autentisering.
A2: Infiltrering av autentiserings- og øktadministreringAlle Blackboard-produkter bruker utelukkende TLS, så alle informasjonskapsler krypteres.
A3: Skriptangrep på tvers av områder (XSS)Risikoen for skriptangrep på tvers av områder reduseres ved å bruke delte biblioteker som ESAPI og utviklingsstandarder. Det forventes at all tekst som legges inn av sluttbrukere, går gjennom rensingsmetoder. Det forventes at andre verdier (datoer, alternativer og valgverdier) genereres fra innskrevne domeneobjekter, og at de ikke transkriberes direkte fra brukerinnlagte verdier.
A4: Usikre direkte objektreferanserDet refereres til alle appobjekter via «ID-er», som vanligvis er tilordnet hovednøkkelen. Alle objekter er imidlertid tilordnet og alle sikkerhetskontroller kjøres mot en «kontekst». En forespørsel kan for eksempel referere til en «meldings-ID» som er et innlegg på en diskusjonstavle for et emne. Blackboard-standarden er å utføre autoriseringskontrollen for rettigheten som er tilknyttet en brukers rolle.
Hvis standarden ikke overholdes, er det lett å løse det, siden alle beskyttede dataenheter i systemet er tilordnet en sikkerhetskontekst (et emne eller et domene).
A5: Feilkonfigurert sikkerhetBlackboard følger en «sikker som standard»-policy med versjonsmerknader og dokumentasjon som kan brukes når det er nødvendig for systemadministratoren å se nærmere på ting. Blackboard oppfordrer kunder til å følge veiledningen om gode fremgangsmåter for sikker konfigurasjon når dette er tilgjengelig og relevant for Blackboard-produktene deres.

Sikkerhetsrevisjon
Sikkerhetsaktiviteter loggføres i sikkerhetsspesifikke logger.

Informasjonslekkasje og håndtering av feil
Standard håndtering av feil brukes på alle sider (via et standardbibliotek for sidemaler og tagger). Dette resulterer i standardutdata for alle feil og spesielt ukjente feil. Standardutdataene kan inkludere stakksporing (mindre informasjonslekkasje), men ingen av dataene som ble behandlet da forespørselen mislyktes, og er bare synlig for brukere med tilgang på administratornivå. Brukere uten slike rettigheter (for eksempel studenter) kan ikke se detaljert stakksporing.

A6: Eksponering av sensitive dataBlackboards standard er å behandle brukerpassord med SHA-160 som hash- og salt-algoritme.

Blackboard-produkter kan kjøres under TLS, men det er utviklerens ansvar å konfigurere TLS skikkelig når produktet deres er lagret på egne tjenere.

A7: Manglende tilgangskontroll på funksjonsnivåDette administreres på to nivåer: ved å kreve at forretningslogikken håndhever autoriseringskontroller, og ved å sikre at QA-testtilfeller dekker autoriseringskrav for ulike skjermer.
A8: Forfalskning av forespørsler på tvers av nettsteder (CSRF)Sikkerhetsrammeverket vårt følger OWASPs anbefalinger per-forespørsel-verdier for engangsnøkler og bare POST-semantikk. AJAX-forespørsler bruker per-økt-verdier for engangsnøkler.
A9: Bruk av komponenter med kjente sårbarheterDette kan unngås ved å utføre regelmessige søk etter sårbarheter både i infrastrukturen vår og i programvarepakker fra tredjeparter, for å identifisere komponenter med kjente sårbarheter og utvikle et veikart for å oppgradere dem med tilgjengelige feilrettinger.
A10: Ikke-validerte viderekoblingerBlackboards standard for sikker koding krever viderekoblinger for å verifisere at de er lokale adresser. Denne sårbarheten testes regelmessig.

Tidligere sårbarhetskategorier nevnt i OWASPs ti viktigste

Ondsinnet filkjøringFiler som er lastet opp av sluttbrukere uten rettigheter, blir aldri brukt som kjørbar fil. Brukere med rettigheter (dvs. Systemadministratorer), kan imidlertid laste opp kjørbare pakker som kalles Building Blocks, som utvider funksjonaliteten til systemet. Det antas at systemadministratorer forstår risikoene og følger lyd-leverandørens gjennomgang, og endrer administrasjonspraksiser rundt installasjonen av eventuelle tredjeparts Building Blocks.

Eventuelle erklæringer om Blackboard sine fremtidige forventninger, planer og muligheter representerer selskapets nåværende synspunkter. De faktiske resultatene kan avvike kraftig som følge av ulike viktige faktorer. Selskapet forventer at senere aktiviteter og utviklinger kommer til å få selskapets synspunkter til å endre seg. Men selv om selskapet kan velge å oppdatere disse erklæringene på et senere tidspunkt, frasier selskapet seg spesifikt alle forpliktelser til å gjøre det.


Løfte om sårbarhetsstyring og retningslinjer for utlevering av informasjon

Blackboards program for sårbarhetsstyring er underlagt dette felles løftet om sårbarhetsstyring, og rettningslinjer for utlevering av informasjon som nevnt nedenfor. Ingen programvareleverandør er perfekt, når en sårbarhet identifiseres i et utgitt produkt vil sikkerhetsgruppen for Blackboard være klar til å håndtere det.

Du må kontakte institusjonens IT-avdeling for hjelp med pålogging. Blackboard har ikke tilgang til institusjonens kontoinformasjon, nettsider, eller innhold. Hvis du ikke vet hvordan du får kontakt med IT-avdelingen, kan du søke etternavnet på institusjonen din + «help desk» på nettet eller se om det finnes en lenke eller kontaktinformasjon til brukerstøtten på påloggingssiden.

Blackboard er forpliktet til å fikse sårbarheter raskt og forsiktig. Slike løsninger kan føre til at det utgis en sikkerhetsveiledning og/eller eventuelle nødvendige produktoppdateringer for kundene våre. For å beskytte kundene våre og dataene deres ber vi deg om at sårbarheter blir rapportert på en ansvarlig og konfidensiell måte, slik at vi kan undersøke og håndtere det. Sårbarheter skal ikke meldes før vi har utviklet og testet en produktoppdatering og gjort den tilgjengelig for kunder med lisens.

Blackboard sine produkter er komplekse. De kjører på forskjellige konfigurasjoner for maskinvare og programvare, og er koblet til mange tredjeparts applikasjoner. Alle endringer av programvarer – store eller små – krever grundig analyse, i tillegg til utvikling og implementering på tvers av flere produktlinjer og versjoner. Programvaren må også gjennom lokalisering, tilgjengelighet, og testing som er gjeldende for dens rekkevidde, kompleksitet, og alvorlighet. På grunn av hvor viktig våre produkter og kunder er, må Blackboard forsikre at det kjøres riktig uten problemer i kundemiljøer og ikke bare i våre testfasiliteter. På grunn av dette kan ikke Blackboard gi produktoppdateringer i henhold til en angitt tidslinje, men vi er forpliktet til å jobbe hurtig med det.

Ondsinnede parter utnytter ofte programvarens sårbarhet ved omvendt utvikling av utgitte sikkerhetsveiledninger og produktoppdateringer. Det er viktig at kunder oppdaterer programvaren og bruker vårt system for alvorlighetsgrad til å planlegge oppgraderinger bedre. Derfor er det kun egnet å diskutere en sårbarhet offentlig etter at kunden har hatt mulighet til å motta produktoppdateringen.

Teste etter sårbarhet i sikkerhet

For å redusere risikoen for data og tjenester, bør du gjennomføre alle sårbarhetstester mot ikke-produksjonsforekomster av produktene våre.


Hvordan du rapporterer en sårbarhet

Dele detaljer av den potensielle sårbarheten konfidensielt ved å fylle ut et skjema for innsending av sårbarheter.

Oppgi detaljer om den potensielle sårbarheten, slik at sikkerhetsgruppen for Blackboard kan validere og reprodusere problemet raskt. Uten informasjonen påpekt ovenfor, kan det være vanskelig å adressere den potensielle sårbarheten. Rapporter som viser en rekke potensielle sårbarheter uten at detaljene blir adressert, kan ikke behandles. Detaljer bør inneholde:

  • Typen sårbarhet;
  • Om informasjonen er publisert eller delt med andre parter;
  • Berørte produkter og versjoner;
  • Berørte konfigurasjoner; og
  • Trinnvis instruksjon eller konseptutprøvingskode for å gjenskape problemet.

Blackboards sikkerhetsforpliktelse

For de som rapporterer sårbarhet og som følger denne retningslinjen, vil Blackboard prøve å utgjøre følgende:

  • Bekrefte mottak av rapporten din.
  • Når det er mulig, bekrefte muligheten for potensiell sårbarhet;
  • Oppgi en plan og tidsperiode for å adressere sårbarheten; og
  • Sende bekreftelse til rapportinnsender når sårbarheten er løst.

Bekrefte bidrag

Blackboard har ikke noe sårbarhet for Bounty-program. Som et resultat av dette vil ikke Blackboard anerkjenne eller kompensere for rapportering av sårbarhet.