Embed Size (px)
DESCRIPTION
This presentation offers insight on defining appsec policies, highlighting the differences from InfoSec policy, attributes of effective policy and how to make policies actionable so they map to an organization's overall security and business processes.
Citation preview
Managing Software Security Risk Streamlining AppSec Policy Definition and Implementation
Tom Bain Director, Product Marke4ng Security Innova4on
For Chicago Security Meetup
April 18, 2013
Who Am I?
• Director, Product Marke0ng, Security Innova0on
• Formerly with Q1 Labs (an IBM Company) and Applica0on Security, Inc.
• Ac0ve blogger, presenter
• BA, Communica0ons, RIC; MS, Interna0onal Rela0ons/Public Affairs, UMASS
Thomas Bain
Tonight’s Agenda ① Why SoOware Security?
Ø Stats/Trends
Ø Biz vs IT Sec Need
Ø Importance of Priori0zing AppSec
② Differences Between App & IT Sec Policy
Ø Incremental policy construc0on
Ø Real-‐world policy improvement
Ø Prescrip0ve mapping to compliance
③ Map AppSec to Compliance Ac0vity ④ Recommenda0ons
Ø Steps you should consider
Who We Are Application Security Experts • 10+ Years vulnerability research • Security Tes0ng Methodology adopted by SAP, MicrosoO, Symantec
• Authors of 8+ books Products and Services • Standards -‐ Best Prac0ces • Educa0on -‐ CBT & Instructor-‐Led • Assessment -‐ SoOware and SDLC
Reducing Application Security Risk • Cri0cal Vulnerability Discovery • Secure SDLC Rollout • Internal Competency Development
I. Why Software Security
The Application Security Ecosystem���
Secure at the Source
Protect in Production Find and Fix
Ø Education Ø Remediation Ø Secure Coding���
Standards
Ø Firewalls Ø Whitelisting Ø “Band Aid”
Ø Vulnerability Scanning Ø Manual Assessments Ø “Whack-A-Mole”
Data Breach Intelligence
• 97% of breaches were avoidable through the use of simple controls.
• 2012: 174M records breached.
• Cost of a breach: $214/record, and $7.2M average overall cost to organization.
We Still Need to Bridge this Gap
* The Ponemon Institute, “Application Security Maturity” 2012
0%
10%
20%
30%
40%
50%
60%
70%
80%
Process in place for building security into applications
Little or no collaboration between the two groups
Have no formal mandate in place for fixing vulnerable code
36%
57%
71%
21%
41%
53% Security Development
Software Apps Are Vulnerable
Stated their company has experienced between 1-10 data breaches over the past 24 months as the result of an application(s) being compromised.
Business Need vs. Security Need • Users lose autonomy with security policies that aren’t well-‐defined.
• Performance + capabili0es oOen trump security = IT headache.
• Users expect an always-‐on, secure connec0on and func0onality
• Time to market pressures hurt security: But good architecture and backend systems can help.
• New frameworks can help you get to market quickly can introduce new vulnerabili0es
II. AppSec vs InfoSec Policy
The CIA Triad • Both have policies, standards, procedures • Informa0on Security revolves around the famous CIA triad
Ø Maintain the confiden0ality, integrity, and availability of informa0on stored in networks and data communica0ons infrastructure
For any so.ware to be considered secure it must conform to these these broad and high level characteris7cs
Ø Vague industry standards that integrate these three security characteris0cs in an iden0fiable and auditable manner for soOware
Ø SoOware applica0ons access informa0on unencrypted, so policy around protec0on has to be even more prescrip0ve
InfoSec vs. AppSec Policy Information Security Application Security
Role Based Receptionist, IT Manager, etc
• Architect, Developer, Tester • Application Roles and Privileges
How to Implement
Rollout and configuration of servers, databases, anti-virus, communications, certificates, etc.
Rollout of web application firewall and secure development best practices • Application Authentication checks • Secure Design components • Attack surface reduction • Code hardening • Data Encryption • Input validation
Expertise Needed to Implement
IT networking, database and computer/OS configuration skills
• How applications interact with environment • How applications function and fail with respect to security
• Software development skills w/ security overlay
Good, Better, Best: ���SQL Injection Policy
✔ MINIMUM Build web applica0ons that defend against SQL injec0on agacks.
✔✔ BETTER Build web applica0ons that defend against SQL injec0on agacks by sani4zing all user input.
✔✔✔ GOOD Build web applica0ons that defend against SQL injec0on agacks by sani0zing all user input using this approved sani4za4on rou4ne.
✔✔✔✔ EXCELLENT …..plus
• SoOware Developers do X • SoOware Testers do Y
Good, Better, Best: ���Protect Sensitive Data
✔ MINIMUM Protect sensi0ve data.
✔✔ BETTER Protect sensi0ve data by using this approved encryp4on.
✔✔✔ GOOD Protect sensi0ve data by using this approved encryp0on in databases that store and during transmission of sensi4ve data.
✔✔✔✔ EXCELLENT ….plus
• Architects define algorithms.
• Developers never write their own crypto.
• Test/QA verifies XYZ.
Good, Better, Best: ���Cross-Site Forgery
✔ MINIMUM Create applica0ons that are resilient to Cross-‐Site Request Forgery.
✔✔ BETTER Create soOware applica0ons that are resilient to CSRF agacks by using the OWASP Top 10 “CSRF Cheat Sheet.”
✔✔✔ GOOD Create soOware applica0ons that are resilient to CSRF agacks by using the OWASP Top 10 “CSRF Cheat Sheet” and implement a language-‐appropriate framework.
✔✔✔✔ EXCELLENT ….plus
• Use challenge-‐response. • QA check reference headers.
Inadequate Example: ���App Pen Testing
• Policy: • “Conduct annual tests of internet facing applica0ons.”
• How to improve it
• Specify the type of test, e.g., web vulnerability scan, source code review, paper audit, etc.
• How deep should it go / What should be tested? Ø OWASP Top 10 vulnerabili0es
• Define the key assets you are trying to protect.
• Specify which agacks should be conducted. Ø Threat modeling in advance can guide you here.
Inadequate Example: Authentication • Policy
Ø “Ensure applica0ons processing data properly authen0cate users through central authen0ca0on systems where possible.”
Ø “If addi0onal func0onality is needed, coordinate development with Informa0on Technology Services.”
• How to improve it Ø Here is our approved authen0ca0on library <URL>. Ø Remove ambiguity.
• “Coordinate with ITS.” Rather, obtain wrigen excep0on for using any authen0ca0on mechanism not explicitly approved by InfoSec Office
Ø “where possible”
Inadequate Example: SQL Injection • Policy
Ø “SQL Injec0on vulnerabili0es must be prevented.”
Ø See OWASP SQL_Injec0on_Preven0on_Cheat_Sheet for recommenda0ons.
• How to improve it Ø Use Parameterized SQL statements and stored procedures.
Ø Use white-‐lis0ng to constrain user input. Ø Use company-‐approved sanita0on library, found here <URL>.
III. Map AppSec to Compliance Initiatives
Compliance Framework
What’s Management Care About? • Enterprise Risk Management, HR, and Legal define the global scope, objec7ves and requirements for corporate governance
Ø Applicable legisla0on (Sarbanes-‐Oxley, HIPAA, California SB 1386)
Ø Industry standards (ISO 2700x, FISMA/NIST standards)
Ø Compliance mandates (PCI DSS)
Ø Legal and human resources requirements (data privacy laws)
Ø Poten0al impacts of security breaches Ø Costs of security breaches and agacks
GRC/Security Teams? • ERM, GRC & Security teams add detail to create policies
Ø High-‐level guidelines for opera0onal security and compliance ac0vi0es
Ø Can be contextualized for specific business units and func0onal roles
• Typical tasks include: Ø Studying the applicable regula0ons and standards
Ø Conduc0ng a threat assessment to determine the security breaches poten0ally most damaging to the enterprise
Ø Classifying data assets to define levels of data sensi0vity
Ø Defining concrete applica0on security objec0ves
Functional Practitioners? • Security & Compliance teams define specific development processes, coding prac7ces, and procedures for compliance documenta7on
Ø Ensures they’re relevant to local requirements and technology, and consistent with corporate security and compliance policies
Ø Address regional and business-‐unit specific regula0ons and the technologies used by each team
• Contextualizing policies for each team can be a labor-‐intensive and deeply technical process Ø Saves a TON of 0me long-‐term
Ø Reduce risk over 0me with specific & prac0cal the guidance
The Compliance Matrix High-Level
Requirement Other Standards
(Partial List) Selected Coding Practices
Confidentiality SOX, HIPAA, ISO 27002,, GLBA, FFIEC, Basel l I, CA SB 1386, FIPS 199, NIST
- Appropriate use of strong encryption for data in databases. - Encrypting confidential data in memory. No custom or untrusted encryption routines - Encrypting data in motion, especially for wireless transmissions. - Masking confidential data that needs to be viewed in part
Data integrity SOX, ISO 27002, HIPAA, GLBA, FIPS 199, NIST
- Robust integrity checks to prevent tampering with data. - Input validation and comprehensive error handling to prevent injection attacks, privilege escalation, and other hacking techniques. - Output encoding. Use of least privileges. - Hashing for confidential data that needs to be validated (e.g. passwords)
Authentication and access control
SOX, ISO 27002, HIPAA, II, NIST SP
- Support for strong passwords & two-factor authentication where appropriate. - Role-based access control and revocation of rights, with clear roles mapped to permissions. - Locked down file access and database roles. No guest accounts. - Passwords and encryption keys encrypted before storage and transmission.
Logging and auditing
SOX, ISO 27002, HIPAA, SB 1386, NIST SP
- Detailed audit trails of users accessing data and resources. - Detailed logging of systems that process sensitive data, including shutdowns, restarts and unusual events. No confidential data exposed in logs. - Event logs and audit trails available only to system admins and protected from unauthorized modifications.
IV. Streamline AppSec Policy Development to Fit Your Business
Where Do I Start? I. Consider risk scenarios. II. Adapt from proven or trustworthy
models.
III. Measure percep0on. IV. Understand roles/privileges.
V. Get granular. VI. Figure out a strategy for tes0ng your
applica0ons.
VII. Consider BYOD. VIII. Policy enforcement. IX. Raise awareness/required training.
Determine Risk Tolerance
• Take an inventory of your high-‐risk applica0ons.
• Determine business cri0cality.
• What’s your agack probability? • How do you define the agack surface?
• Consider overall business impact. • Where does compliance factor in? • What are the security threats?
Trustworthy Sources
• A1 Injec0on • A2 Broken Authen0ca0on and
Session Management • A3 Cross-‐Site Scrip0ng (XSS) (was
formerly A2) • A4 Insecure Direct Object
References • A5 Security Misconfigura0on (was
formerly A6)
• A6 Sensi0ve Data Exposure (merged from former
• A7 Insecure Cryptographic Storage
• A8 Cross-‐Site Request Forgery (CSRF)
• A9 Using Known Vulnerable Components
• A10 Unvalidated Redirects and Forwards
Measure Perception • A|tudes of general popula0on toward security (suppor0ve, antagonis0c, indifferent?)
• A|tudes of general popula0on toward management (suppor0ve, antagonis0c, indifferent?)
• How does management view the func0on of security?
• What’s the percep0on of current policy?
• Have there been related security incidents?
Role-Based Questions • Which departments/groups/individuals have been most ac0ve in developing policies?
• Previous collabora0on between policies and authors?
• Poten0al champion(s) to support? • Areas of agreement in commonly implemented controls re: policies?
• Support docs, materials and related policies should be cited in mobile device policy.
• Start to understand user access and privileges.
Granularity is Good • Which applica0ons would be used? • How will web applica0ons be used? • What will access and levels of privilege look like?
• What informa0on is accessible through web applica0ons? • What informa0on will be stored on web applica0ons?
• How will data be shared to/from web applica0ons? • Who’s ul0mately responsible for applica0on security? • Which applica0ons are acceptable to use?
• Which applica0ons should not be used? • What levels of support are expected?
Understand & Define Your Data • How sensi0ve is your data? • What kind of data is it? PII, customer data, credit card data, proprietary, IP, etc.
• Is it subject to regulatory mandates? Which ones?
• Are you encryp0ng data? At rest? In transit?
• Conduct a threat model: Ø Determine threats Ø Iden0fy poten0al agacks
Ø Understand the frequency & severity with which they are executed.
Rank Your Applications
Threat Rating
Sensitive Data Lifespan
Compliance Stringency
Customer-Facing
Tier 1 Restricted Long High Yes
Tier 2 Private Mid Medium Yes
Tier 3 Public Short N/A No
Application Criteria
Application Testing
Threat Rating
Static Analysis
Dynamic Analysis
Manual Pen Test
Threat Modeling
Complete/Frequency
Complete/Frequency
Complete/Frequency
Complete/Frequency
Tier 1 Required/Major code changes
Required/Major code changes
Required/Per Milestone
Required/Per Release
Tier 2 Suggested/Monthly
Required/Quarterly
Required/Per Release
Suggested/Per Release
Tier 3 Optional/Quarterly
Required/Annually
Optional/As Needed
Optional/As Needed
Depth, Breadth, Frequency
Start Thinking About BYOD • Mobile devices help employees increase produc0vity – staying connected is not really op0onal anymore!
• Usage has experienced a massive up0ck: 60% of today’s workforce is using a smartphone specifically for business use.
• IT is struggling to keep up with device management.
• Mobility by its nature opens up a larger agack surface with more points of entry.
• Difficult to measure business need through IT Security lens.
--Mobility Outlook Report, Mobile Enterprise, 2013
Business Usage Uptick… • 84% use the same smartphone for work and for personal usage.
• 81% of employed adults use at least one personally owned electronic device for business (Harris Interac0ve survey, February 2012)
• 59% of employees surveyed use mobile devices to run line-‐of-‐business applica0ons (Ibid)
• 74% of companies allow BYOD usage in some manner (Aberdeen Group, February 2011)
--Experian Mobile Security Survey, November 2012; Harris Interactive, Feb 2012; Aberdeen Group, Feb., 2011
…Creates New Security Issues • 50% of companies have experienced a data breach due to inadequate device security (Ponemon survey, 2012)
• 47% don’t have a password on their mobile phone.
• 51% stated their companies couldn’t execute a remote wipe if lost or stolen.
• 49% said mobile security has not been addressed with them by IT.
--Experian Mobile Security Survey, November 2012; Harris Interactive, Feb 2012; Aberdeen Group, Feb., 2011
Why is BYOD a Security Problem? • Device turn-‐over: What happens to the old device? • New devices: Default or customized se|ngs? • How can you know everything about every device?
• SoOware updates – user vs IT. • App Stores: Approved apps?
• Applica0ons: Ø What data is on your device? Ø What enterprise applica0ons can you connect to?
Ø Which apps are connected to other apps? EX: Your blog app is connected to your CMS, which feeds to Twiger, etc.
Gartner’s Top 7 Failures in Mobile Device Security
• Inconsistent security policies • Laptop encryp0on bypass mode • Unmanageable devices
• Shared media leakage • Minimal device management
• Readable data on disposed-‐of devices
• Inter-‐applica0on data leakage
-‐-‐Girard, John, Top 7 Failurs in Mobile Device Security,, Gartner, February 2013
Mobile Devices & Data Sources
Mobile Vulnerabilities
Traditional Vulnerabilities
Summary: Policy Attributes • Describes contextual, technical guidelines on how security should be integrated within the SDLC Ø By phase, role, technology, applica0on type Ø Leverages internal secure development champion(s) for input
• Maps to compliance mandates
• Considers cri7cality of applica7on and data Ø Requirements, ac0vi0es and level of detail needed will differ
• Has a clear excep7on policy Ø What if minimum standards can’t be met? What is considered acceptable? Who approves?
• Includes internally built and third party applica7ons
• Reflects current maturity and secure development skills
Policy Enforcement • You need management buy-‐in! • Broad strategy vs Targeted strategy roll-‐out • On-‐boarding:
Ø Require policy training up front • Require training for various departments:
Ø General popula0on receives awareness training Ø Technical employees receive in-‐depth training
• Monitor for effec0veness – EX: Deliver training or reminder when employee is out of compliance.
