Building Security In Through a Secure Development Community

Building Security In Through a Secure Development Community Shirley Ann SternSr. Principal Security Program Manager Oracle Global Product Security

Program Agenda Builders, Breakers, Defenders The Oracle Software Security Assurance (OSSA) SDLC Building a Secure Development Community Developer Community Growth and Expansion Developer Community Relationships

Builders, Breakers, Defenders OWASP.org Builders - advance the state of security in the area of application development Breakers - advance the state of security in the area of security testing Defenders - advance the state of security in the area of application defense Definitions

Builders, Breakers, Defenders Oracle Builders - Product Development and the Security Point of Contact (SPOC) Community Breakers – Ethical Hacking Team and Product QA Testers Defenders – Internal Users and Information Security Managers (ISM) Community Definitions

Security Within the Corporate Structure CEO Chief Corporate Architect reports to the CEO ALL Security rolls up to the Chief Corporate Architect For Product Security, makes it much easier to “build security in” Oracle’s Hierarchy Chief Corporate Architect Physical Security Corporate Security Architecture Global Product Security Global Information Security

The Oracle Software Security Assurance (OSSA) SDLC Security is Built In to Every Oracle Product

What Is OSSA? Software must be designed securely Security must be built in at the lowest level Adequate security controls are provided (e.g. reflecting the data it will store, the threat environment it will operate in, etc.) Software must be developed securely Secure design and coding principles must be followed Software must be developed in a secure environment under a securely designed development process Software must provide a reasonably secure state by default Hardening instructions must be documented and available

OSSA Activities by Phase Definition – requirements gathering, design reviews, customer validation, core security modules Development – code reviews, security testing, standard security tools, security checklists, security assessments Ongoing Assurance - secure configuration, security evaluations, security training, security vulnerability handling and remediation Activities

Examples of OSSA at Work Product Definition Product Development Ongoing Assurance Security requirements must bedocumented in design and functional specifications Must use approved code for complex security functions (authentication, crypto etc.) Architectural risk analysis – “some bugs can never be patched” Ongoing code reviews against Secure Development Standards, originalspecifications, etc. Extensive use of static, dynamic analyzers (Fortify, Parfait, Coverity, WebInspect, Various fuzzers) Mandatory use of security checklists Secure configuration checks from internal/external users Ethical hacking - product assessments IT pen testing results (Qualys, etc.) SecAlert reports, metrics, and vulnerability analysis Examples of OSSA Requirements by Phase

Secure Development Standards The Heart of the Matter Secure design, coding, and testing guidelines Secure principles in each of these areas Examples of what to do – and not to do Requirements to use “Oracle approved” security code, third party libraries, etc. Minimum secure design requirements (e.g., weak/old crypt algorithms are banned) Practical - Good/bad examples, suggested techniques Incorporate process and role definitions to achieve compliance

The Community is Key Security Points of Contact (SPOC) Community Security Assurance Training Security Tools/Testing Secure Coding Standards Code Reviews Secure Configuration Core Security Modules Ethical Hacking Security Alerts Security Checklists

Decentralized, Virtual Security Community Security Points of Contact (SPOC) Community Dev. Group D Dev. Group A Security Assurance Training Security Tools/Testing Secure Coding Standards Dev. Group E Dev. Group B Code Reviews Secure Configuration Core Security Modules Ethical Hacking Security Alerts Dev. Group F Dev. Group C Security Checklists …Others

Each Development Group has Local Security Leadership The Security Lead Function Primary overseer for OSSA activities and compliance for the product family Four major responsibility areas Ongoing Security Community activity leadership at Technical expert for the product family security OSSA process implementation Security compliance for the product family Leadership and communication skills extending from executive management to individual development teams

Each Development Group has a SPOC Community What is a SPOC? Key role to achieve “building security in” bottom up Security experts within each product component team In-depth knowledge of component(s) represented Liaison between the Security Lead and Global Product Security Participate in all activities within the OSSA SDLC Primary principle: SPOC is responsible for the security assurance of the component overall Required SPOC duties vary by product family Can be delegated to other team members

What The SPOC Does…. The SPOC Ensures Security for the Component Address questions from other SPOCs about the represented component security Share security practices across the family Juggle tasks ranging from implementing better security in new releases to coping with security bugs in existing versions Carries out OSSA compliance activities across the lifecycle Proactive to improve component security Improve response time to newly reported security bugs Prioritize and reduce open security bug backlog

Keeping on Track Security Checklists Completion is a key task for SPOCs Covers a product down to lowest component level Automated, customizable Expands to include new technologies Key component to product release Across the SDLC

Keeping on Track The Security Scorecard Key management tool for the product family Grades security compliance in key areas Reviewed at the Executive management level (including the CEO) Product Compliance

Binding the Community Together Across the Enterprise What Works Very successful monthly SPOC newsletter Annual SPOC Summits that grew 2 days at first, now a week Increased attendance, d Delivered in India, Europe as well as US Increased practical, hands on content Specialized mailing lists on various topics SPOC Web Conferences on specific, technical security concepts SPOC identification “tag” in corporate directory for recognition

Binding the Community Together Across the Enterprise “Work in Progress” SPOC experience sharing across product families Comprehensive, centralized security wiki – under reorganization Documented role descriptions – emerging secure development standards, increased upper management support Oracle Connect group “Closed” group for discussions, blogs, etc. Not widely used OraTweet for security-related questions Very limited scope

Program Agenda Builders, Breakers, Defenders The Oracle Software Security Assurance (OSSA) SDLC Building a Secure Development Community Community Growth and Expansion Community Relationships

Here come the Breakers! QA SPOCs, an Expanding Segment Growing interest in empowering QA now that the SPOC model in development is working well QA breakers are closer to the builders to fix vulnerabilities quickly Centralized hacking team can not do all the “breaking” SPOCs themselves have been instrumental as they began applying lessons from the central Ethical Hacking Team Some development organizations are evolving QA to have an ethical hacking function

The QA SPOC Role What is a QA SPOC? Goes beyond the testing phase to encompass the entire development lifecycle Considers effective testing at the design stage and develops strategy Look at the product the way the customer (and/or hacker) will use (misuse) it ! Share security testing practices across the family Address security issues that arise from testing across the family

What a QA SPOC Does…. Far More than Testing Analyze the requirements from the Secure Development Standards (SDS) for mandatory QA practices that apply to the product or product components Identify additional QA practices when appropriate Establish practices in the development and QA procedures of the product team Review reported security bugs to identify and develop appropriate tests

What a QA SPOC Does…. Far More than Testing Determine how to fold security issues into testing validating security checklist items on Review test plans covering functional security tests Determine the appropriate strategy for the testing types needed for the application to be tested. Define test plans and choose tools and procedures for destructive testing as appropriate Define the security test environment(s) used for security test activities

Additional Community Members SPOC Associates - “Friends of SPOCs” Others in development Product architects Managers Security feature developers Release Management – keepers of the security checklist Product Development IT responsible for development system security On Demand hosted services staff Security Certified Group within Support proactive with customer issues

Program Agenda Builders, Breakers, Defenders The Oracle Software Security Assurance (OSSA) SDLC Building a Secure Development Community Community Growth and Expansion Community Relationships

The Information Security Manager (ISM) Program Goal: reduce risk, optimize resource spend, contribute to the bottom line Scope: extend GIS principles throughout Oracle Objective: ensure corporate security and privacy compliance, communicate security awareness Overview

The Information Security Managers Community The Defenders – Oracle is Oracle’s Largest Customer Line of Business Information Security Point of Contact The “expert” – familiar with information security policies, initiatives Drive protection of Oracle information within the line of business Determine risk and state requirements for internal systems Provide SDLC guidance and qualification assistance Promote information security awareness within the line of business Feed back security risks and issues to the development “builders”

Corporate Security Solution Assurance Process (CSSAP) Evaluates security risks for new IT systems, externally hosted service Considers impact on critical infrastructure Focus on deployment issues and risks IS Process Model

Secure Development Community Direction More of the Same…. Roles are becoming more concrete, greater consistency Greater recognition of value of the roles Better metrics Greater emphasis on applied training Overall SPOCs are increasing their efforts, collaboration to making OSSA a better program

Secure Development Community Direction But Change is in the Forecast More deployment platforms Cloud, mobile, embedded, engineered systems Change in attitude and thinking – some examples Component SPOCs are asking: “how can I how help Engineered Systems teams create secure engineered products?” QA SPOCs: “how can I test better for better security in cloud (or mobile) deployment?” Result: closer collaboration between the Secure Development and Information Security communities

Graphic Section Divider

Building Security In Through a Secure Development Community