Certification of Open Source Software Tomas Gustavsson PrimeKey Solutions AB www.ejbca.org www.cesecore.eu
Agenda Common Criteria Vad Varför Open Source Hur fungerar de ihop? Hur påverkas ett projekt? Avbryt gärna med frågor!
Vad är det? Kort för o Common Criteria for Information Technology Security Evaluation En standard o För IT-säkerhetscertifiering definierad av ISO/IEC 15408 Tillhandahåller o Tillit att processer för specifikation, implementation och utvärdering har utförts på ett rigoröst och standardiserat sätt. Contents based on Wikipedia, Common Criteria, http://en.wikipedia.org/wiki/common_criteria
Används av Användare o Specificera krav på säkerhet och tillit. Leverantörer o Att marknadsföra säkerhetsaspekter hos sina produkter. Testlaboratorier o Att utvärdera om produkter uppfyller sina anspråk. Contents based on Wikipedia, Common Criteria, http://en.wikipedia.org/wiki/common_criteria
Varför? Myndigheter, banker och större företag kräver säkerhetscertifierad mjukvara. Som open source-leverantör gäller samma regler som för proprietära leverantörer. Inne eller ute! Statisk certifiering. En granskad version, i en viss miljö, är certifierad. Ej andra versioner i andra miljöer.
Hur fungerar det? Hur fungerar common criteriacertifiering? Sponsor - betalar Developer - utvecklar Labb - granskar Certification body skriver på pappret
Testar Dokumentation Dokumentation av säkerhetsfunktionalitet är fullständig Implementation Att säkerhetsfunktionerna gör det de påstås göra Utvecklingsmiljö Att utvecklingsmiljön är säker Utvecklingsprocess Att utvecklingen sker på ett säkert sätt
Vad är common criteria? PP ST FSP, TDS, IMP PRE, OPE ARC, ALC ATE Common Criteria TLAs TOE, TSF, TSFI, EAL En process i sig att lära sig alla termer.
Färdiga dokument? CC standard: En hög med tjocka dokument som beskriver förutbestämda krav. Främst avsedda för granskare. Protection Profile: förutbestämda krav på en viss typ av mjukvara, tex CA, smartkort, OS. Skapas oftast av en myndighet tex NIST, DoD, EU Utifrån detta påbörjas certifieringen av mjukvaran.
Vad skall skapas (1)? Security Target (ST): Beskriver vilka säkerhetsfunktioner mjukvaran har och vilka hot de skyddar mot. I princip en kopia av PP. Functional Specification (FSP): Beskriver alla säkerhetsfunktioner i detalj. Design Specification (TDS): Beskriver alla säkerhetsmoduler och interaktioner. Implementation Representation (IMP): Doxygen dokumentation över alla filer.
Vad skall skapas (2)? Preparative Procedures (PRE): Hur man konfigurerar systemet. Operational User Guidance (OPE): Hur man använder systemet. Test plan (ATE): Tester och protokoll för alla säkerhetsfunktioner. Security Architechure (ARC): Säkerhetsarkitektur Life Cycle Support (ALC): Processer för utveckling och release. Configuration List: Lista över alla filer och beroenden.
ST (Security Target) - TOE (Target of Evaluation) - TSF (TOE Security Functions) Abstract machine Application server HSM TOE Boundary CESeCore Configuration DB Applications
FSP (Functional Specification) (1)
FSP (Functional Specification) (2)
FSP (Functional Specification) (3)
TDS (TOE Design Specification)
Hur hänger dokumenten ihop? TOE har TSF, TSF har TSFI Fullständiga mappningar mellan alla dokument. Man kan ej beskriva en TSF i FSP som inte motsvaras av en test i ATE...
Några fördommar om Common Criteria? Dyrt? Slöseri med tid? Bara papper, inte tekniskt? Certifierade produkter är bara gamla versioner? Certifierade produkter är inte bättre än andra?...
Sanningen om Common criteria Tar mycket tid. Kostar mycket pengar. Är tekniskt. Gamla versioner är certifierade, ej senaste. Ger produktförbättringar, om använt på rätt sätt. Ger säkrare produkter, om använt på rätt sätt....
Vanliga missuppfattningar: - CC certifiering garanterar säker mjukvara - CC certifiering är ingenting värt En CC certifiering säkerställer, med en viss säkerhetsgrad (EAL) att den certifierade mjukvaran fungerar som det är dokumenterat att det skall fungera. Därför är Protection Profile och Security Target viktiga.
För användaren? Protection ProfileProtection Profile och Security Target viktiga. Det är meningen att användaren/inköparen av mjukvara skall kunna läsa en ST och förstå vad som är certifierat. I praktiken omöjligt Av det följer: Användare tittar bara på EAL4+. Leverantörer påpekar andras produkter certifierar bara....
Väldigt svårt och omständigt att hålla reda på alla detaljer i alla dokument och hålla kopplingarna korrekta. Man skriver bara den typen, och mängden, av dokument om man får betalt. Anlitar ofta konsult för att göra det Kan hindra viss refactoring, men även medföra nödvändig refactoring. Bra input och säkerhetstestning från testlabbet. Seg process... Common Criteria För utvecklaren?
Vad kostar det? - Tid, 2 år varav minst 3 pers heltid under ca 1 år - Pengar, >500.000 bara för labbet
Nej Samma krav för OSS och Proprietär sw. CC bryr sig inte om koden är öppen eller sluten. Finns inga krav som OSS inte kan uppfylla. Ja CC och Open Source Diskrimineras open source? Strikt kontroll över repo och comitters är inte en perfekt match för communitydrivna projekt. Life cycle-krav kräver kontroll av issues. Kostnad kräver företag med goda finanser, ROI
CC och Open Source Vattenfall vs agile De flesta Open Source-projekt utvecklas ej enligt en sådan extrem vattenfallsprocess som CC är. CC ej skapat med tanke på snabb utveckling och flexibilitet. Statisk certifiering. En granskad version, i en viss miljö, är certifierad. Ej andra versioner i andra miljöer. Impact assessment kan göras för releaser efter certifiering Omcertifiering iallafall billigare när man kan alla processer och har de flesta dokument någorlunda i ordning.
Resultat? Få Open Source-produkter är certifierade Från större företag RedHat, IBM, PrimeKey,... Ännu färre fritt nedladdningsbara Desto fler kommersiella produkter som bygger på open source. Apache etc
CESeCore och EJBCA Vad har vi certifierat? CeSecore.eu EJBCA.org
Assurance Level o EAL 4+ (augmented with ALC_FLR.2) Protection Profile o Uppfyller Security Level 3 i CIMC (Certificate Issuing and Managements Components) PP CC Version o CESeCore och EJBCA Conformance claims Compliance med CC version 3.1. CIMC skapades ursprungligen för CC version 2.1, men anpassades för CC version 3.1.
CESeCore och EJBCA Vad skiljer OSS från proprietär sw? Publikt repository Kontroll över utvecklingsdatorer Varifrån görs utveckling Vem utvecklar, juridisk kontroll över utvecklare
CESeCore och EJBCA Hur stödjer CC open source? Kontroll över utvecklingsdatorer policy/kontrakt Varifrån görs utveckling publikt svn/git, wiki, HTTPS och autentisering Vem utvecklar, juridisk kontroll över utvecklare - kontrakt
CESeCore och EJBCA Hur påverkar det open source-projektet? ALC Life Cycle och CC krav Kontrollerad access till repositoryt Logiskt och fysiskt Inget sf.net Processer för: Ärendehantering Code review Testning Release
CESeCore och EJBCA Hur påverkar det open source-projektet? ALC Life Cycle och CC krav All personal Skriva på user responsibility policy Accesslistor vem som har åtkomst till vad Externa comitters: Logiskt och fysiskt Samma user responsibilty policy Granskningsprocess
CESeCore och EJBCA Påverkan på EJBCA.org? Vi hade redan Jira, Fisheye, Hudson, Clover,... Flyttade repository till egen hosting Införde access listor och user responsibility policy för alla committers Mer administration Lite mer QA för varje issue, mergning och extra dokumentation. Lite långsammare utveckling per issue Dock bättre kvalitetsäkring per issue
Certification of Open Source Software Tomas Gustavsson PrimeKey Solutions AB tomas@primekey.se www.ejbca.org www.cesecore.eu