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 med utviklingsretningslinjer 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.

Eventuelle erklæringer om Blackboards fremtidige forventninger, planer og prospekter 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.