D. Best Practices D.1. Assurance The 5 th A

Best Practices I&C School Prof. P. Janson September 2014 D. Best Practices D.1. Assurance The 5 th A 1 of 36

IT systems are insecure for two main reasons: People are fallible and systems are complex and brittle If architects built buildings the way programmers build IT systems the first woodpecker would cause civilization to collapse Software products hold promises but no liability like religious preaches 2 of 36

Technology cannot do much about human fallibility but it can do more and more about systems brittleness 3 of 36

How can we built more secure systems? SD 3 systems Emerging security engineering code books Recommended security engineering practices 4 of 36

SD 3 systems Most disciplines, also in engineering, are regulated and subject to heavy malpractice fines But anyone can claim to be a computer engineer without any license or liability This cannot and will not go on for ever Users increasingly demand secure systems Regulators increasingly mandate secure systems Just as the government eventually stepped in to mandate seat belts for cars and safety standards for aircraft, the time has come for software => (Self-)regulation and liability are coming IT engineering codes and practices Security as competitive differentiator NB: Hardware security engineering is not a focus of this course 5 of 36

SD 3 systems Systems increasingly need to be Secure by Design, by Deployment, and by Default Security by default is a direct application of the fail-safe & built-in principles Security by deployment is a matter of operations engineering (next chapter) Security by design is a matter of systems engineering (this chapter) 6 of 36

Emerging security design code books SANS Application Security Procurement Language Building-Security-In Maturity Model (BSIMM) OWASP guides and Comprehensive Lightweight Application Security Process (CLASP) Microsoft s Secure Development Lifecycle (SDL) IBM s SDLC NIST Guidelines Etc. 7 of 36

The SANS (SysAdmin, Audit, Network, Security) Institute Application Security Procurement Language http://www.sans.org/appseccontract/ Software vendors have little incentive to produce secure software but a big incentive to game assurance process Mitre & SANS agreed on standard contract language between software buyers & vendors = First step for vendors to assume liability for quality of software 8 of 36

Building-Security-In Maturity Model (BSIMM) http://www.bsi-mm.com/ Governance Intelligence SSDL Touchpoints* Deployment Strategy and Metrics Attack Models Architecture Analysis Penetration Testing Compliance and Policy Training ~ Construction ~ Verification Security Features and Design Standards and Requirements Code Review Security Testing * SSDL = Secure Software Development Lifecycle Software Environment Configuration Management and Vulnerability Management 9 of 36

Open Web Application Security Project (OWASP) Software Assurance Maturity Model (SAMM) http://www.owasp.org/index.php/category:software_assurance_maturity_model 3 guides Development Code review Testing http://www.owasp.org/index.php/category:owasp_guide_project http://www.owasp.org/index.php/category:owasp_code_review_project http://www.owasp.org/index.php/category:owasp_testing_project + Application Security Verification Standard (ASVS) https://www.owasp.org/index.php/asvs 10 of 36

Microsoft s Secure Development Lifecycle (SDL) http://www.microsoft.com/security/sdl/ Time-based explains what to do at what stage of development Analyzing and minimizing attack surface Analyzing cost of attacks and defenses Includes framework with 4 maturity levels in 5 capability areas Training, Policy & Organizational capabilities Requirements & Design Implementation Verification Release & Response 11 of 36

IBM SDLC overview Source: IBM Rational Application Security Security strategy & metrics Requirements Design Code Test Deploy Security requirements Secure design principles Secure coding Risk analysis Vulnerability management Secure deployment Abuse cases & anti requirements Architectural risk analysis Code review Security testing Operational enablement Security testing Security education & guidance Reprinted by courtesy of International Business Machines Corporation, (2008-2009) International Business Machines Corporation 12 of 36

Recommended security design practices Cursory inspection of main secure coding guidebooks reveals many common recommendations 1. Strategy and education 2. Requirements and standards 3. Architecture / design & review 4. Implementation & review 5. Testing and vulnerability assessment 6. Deployment and response 13 of 36

1. Strategy and education a. Define secure development methodology b. Provide security awareness & education c. Ensure security certification & compliance 14 of 36

1.a. Secure development methodology Must define + publish / adopt secure development methodology Include and enforce gating security decision points in software development process Monitor behavior and enforce compliance with methodology Publish project security data internally Hold developers accountable for security of their deliverables 15 of 36

1.b. Security awareness and education of software developers (Repetition of observations listed on white-box scanning chart in lesson 20) Require that programmers display a sniper / spy mindset Being ego-conscious, determined, confident, motivated, having fun, breaking rules Require very sharp skills and broad expertise Programming languages, common frameworks and libraries Operating systems Middleware databases systems and network protocols System administration Vulnerabilities and attack techniques Knowing classification systems like CVSS, CVE, CWE, OWASP, CAPEC, etc. Tracking e-mail lists like bugtraq, webappsec Attending conferences like BlackHat and DefCon 16 of 36

1.b. Security awareness and education of software developers Educate new hires + Annual refresher courses Encourage professional certifications, e.g. SANS Global Information Assurance Certification (GIAC) for Secure Software Programmer (GSSP) International Information Systems Security Certification Consortium (ISC) 2 Certified Information Systems Security Professional (CISSP) Certified Secure Software Lifecycle Professional (CSSLP) Provide differentiated career recognition for security skills & practice 17 of 36

1.c. Certification of software security and compliance Understand applicable software certification requirements (see later) + align development process accordingly Ensure and monitor compliance of internal practices with adopted guidelines Document evidence of compliance Require executive sign-off on exceptions (known vulnerabilities, process non-compliance) Assess compliance of external components + document exceptions 18 of 36

2. Security requirements and standards Ensure that security is factored in from the start not added on as an afterthought Assess potential risks Threat and attack modeling Define security requirements to contain such risks Identify applicable standards (see next section) 19 of 36

Beware of poor excuses for dismissing certain attack paths That s not a user scenario Purpose is to look at intruder scenarios, not user scenarios It s hidden the user can t even see it Security by obscurity never worked They d have to know the file name/format/protocol/source code/directory structure (which is not public knowledge) Security by obscurity never worked That feature is changing (or has been removed) in the next version Some users will cling to old versions for ever The UI prevents them from doing that Intruders will always look at ways to circumvent the official UI We re using SSL, that protects us SSL can be attacked and has been Users cannot get to the back end Never forget Murphy s Law - test everything before claiming anything No one can ever be interested in hacking into this product Never say never This product may be integrated in a bigger application that someone will try to hack 20 of 36

3.a. Security architecture and design ~50% of security problems come from design flaws Design flaws cannot be found by staring at code => Need higher-level architectural perspective (forest vs. trees view) => Assign security professionals into architecture team => Identify and plan to use proven solutions + existing implementations 21 of 36

Towards a reusable, componentized security services architecture amenable to cloud computing & managed security services (Mgmt API e.g. KMIP) ( GSS API / CAPI ) Federated Security Mgmt Security Enforcement PI PI Community Identity, Role, Reputation governance Policy & trust languages & management Data discovery, classification, assurance, entitlement, bkup Crypto key management UTM Configuration, patching, intrusion / fraud, content filtering Risk management, monitoring, audit and compliance Authentication Access Control DLP, DRM Encryption Signature Content Filtering Logging & Reporting Data Appl. Appl. VM Container Box Box Facility Physical Network Management Enforcement policies mechanisms Central control Modular components Interoperable interfaces VS Library VA Domain VDC, VPN Cluster Organization 22 of 36

Towards a reusable, componentized security services architecture amenable to cloud computing & managed security services There are a number of readily available interfaces for many security services PKCS#11, JavaCard, etc. GSS-API Generalized Security Services API (can use PKCS#11) SASL Simple Authentication and Security Layer Java security ESAPI OWASP Enterprise Security API KMIP Key Management Interoperability Protocol 23 of 36

PKCS#11 Cryptographic Token Interface (Cryptoki) RSA Labs de facto standard Vendor neutral, cross-platform, industry-standard API to generic crypto tokens & HSMs Cryptographic services manipulating Security objects and attributes (keys, certs) Along life cycles as part of Extensible architecture that is Secure by design 24 of 36

PKCS#11 Cryptographic Token Interface (Cryptoki) Cryptographic services ENCRYPT, DECRYPT, SIGN, VERIFY, DERIVE (a key), ALLOWED_MECHANISMS, etc. Cryptographic objects Symmetric and asymmetric keys and certificates Functions to CRUD / import / export objects + manage lifecycles Used by Mozilla Firefox, DNSSEC, SSL/TLS, Truecrypt, etc. (among others) NB: Microsoft supports Windows-specific MS-CAPI instead 25 of 36

GSS-API IETF RFC 2743 (supersedes RFC 2078) Authentication and crypto API no authorization function Mechanism-, protocol-, and connection-independence through manipulation of opaque tokens exchanged as TCP data Standard bindings for C and Java GSS- API GSS- API GSS App App GSS Sockets API TCP/IP Opaque GSS tokens TCP/IP Sockets API 26 of 36

GSS-API verbs Credential initialization & termination GSS_Acquire_cred Name, ltime, mechs => cred_handle GSS_Inquire_cred Cred_handle => Name, ltime, mechs GSS_Add_cred Cred_handle, Name, ltime, mechs GSS_Release_cred Cred_handle => Secure context initialization and termination GSS_Init_sec_context GSS_Process_context_token GSS_Accept_sec_context GSS_Inquire_sec_context GSS_Delete_sec_context GSS_Export_sec_context (to other process) GSS_Import_sec_context (from other process) Message integrity and signature GSS_GetMIC or GSS_Sign GSS_VerifyMIC or GSS_Verify with symmetric or asymmetric crypto Message encryption and decryption GSS_Wrap or GSS_Seal GSS_Unwrap or GSS_Unseal with symmetric or asymmetric crypto Total ca. 45 calls incl. calls for name, mechanism, OID mgt 27 of 36

SASL Simple Authentication and Security Layer over BEEP Block Extensible Exchange Protocol BEEP multiplexes TCP / TLS or any other transport connection into up to 257 MIME channels Channel profiles are negotiated at set-up and may be linked to any channel TLS profile for transport (http://iana.org/beep/tls) SASL profile for security SASL can flow over any transport connection but typically uses a BEEP channel to negotiate SASL-approved network confidentiality, integrity, and authentication functions SASL API SASL BEEP App BEEP Options: ANONYMOUS PLAIN (userid-password) CRAM-MD5 (password digest challenge-response) OTP (one-time nonce derived from password DIGEST-MD5 (password digest + optional C&I) KERBEROS SECURID TLS+PLAIN (TLS + PLAIN SASL) TLS+EXTERNAL (TLS + client-side certificate) App BEEP SASL BEEP SASL API TCP/IP Tokens in SASL/BEEP headers TCP/IP 28 of 36

Java security Extensible, standards-based, interoperable security architecture including Platform Security = Built-in language security enforced by Java compiler and JVM Strong data typing Automatic memory management Bytecode verification Secure class loading Cryptography API (JCA / now incl. JCE) = algorithm- & implementation-independent Confidentiality Integrity Digital signature Key management 29 of 36

Java security Authentication & Authorization(JAAS) Authentication API Single sign-on to multiple pluggable mechanisms Authorization API Fine-grained role-based access control policy management Secure communication (confidentiality & integrity) JSSE over HTTPS / SSL / TLS JGSS over GSS-API with Kerberos SASL 30 of 36

OWASP ESAPI http://www.owasp.org/index.php/esapi Free, open source, web application security control APIs & libraries Reference implementations in multiple languages Solid foundation for new development Allows retrofitting security into existing software 31 of 36

OWASP ESAPI https://www.owasp.org/index.php/esapi_specification Authenticator User AccessController AccessReferenceMap Validator Encoder HTTPUtilities Encryptor EncryptedProperties Randomizer Exception Handling Logger IntrusionDetector SecurityConfiguration Authentication Access control / authorization Input validation Output encoding HTTP security Cryptography Error handling Logging Intrusion detection Security configuration 32 of 36

OWASP ESAPI coverage of OWASP Top Ten vulnerabilities OWASP Top Ten OWASP ESAPI A1. Cross Site Scripting (XSS) A2. Injection Flaws A3. Malicious File Execution A4. Insecure Direct Object Reference A5. Cross Site Request Forgery (CSRF) A6. Leakage and Improper Error Handling A7. Broken Authentication and Sessions A8. Insecure Cryptographic Storage A9. Insecure Communications A10. Failure to Restrict URL Access Validator, Encoder Encoder HTTPUtilities (Safe Upload) AccessReferenceMap, AccessController User (CSRF Token) EnterpriseSecurityException, HTTPUtils Authenticator, User, HTTPUtils Encryptor HTTPUtilities (Secure Cookie, Channel) AccessController Copyright The OWASP Foundation Permission 2014 P. is Janson granted to copy, distribute and/or modify this document under the terms of the OWASP License. 33 of 36

Key Management Interoperability Protocol (KMIP) Manages crypto objects (keys, certificates) and their attributes across their lifecycle 34 of 36

KMIP objects Objects Certificates & keys (private, public, symmetric + split keys) Secret data, opaque objects Verbs On keys Create, Destroy Activate, Revoke Re-key Archive, Recover Get, Put On certificates Certify Re-certify Validate Managing attributes Add / Delete / Get / Modify Attribute Managing events Notify (e.g. key expiration and replacement need) 35 of 36

3.b. Reviews Perform security analysis and review at every software development step Architecture Design Implementation Test The earlier the better (http://www.nist.gov/director/prog-ofc/report02-3.pdf) Errors \ Found Design Coding Integration Beta GA Design 1x 5x 10x 15x 30x Coding 1x 10x 20x 30x Integration 1x 10x 20x And NIST is conservative others claim it could cost 100X 36 of 36