Downloaded 11 times
Uploaded bytmbainjr131
Streamlining AppSec Policy Definition.pptx
The document discusses strategies for managing software security risk and streamlining application security policy for organizations, emphasizing the need for collaboration between security and development teams. It outlines best practices for application security, the importance of compliance with legal and industry standards, and methods for integrating security into the software development lifecycle. Additionally, it addresses the challenges posed by Bring Your Own Device (BYOD) policies and the necessity for continuous education and training to enhance security awareness among employees.
More Related Content
![[Webinar] Building a Product Security Incident Response Team: Learnings from ...](https://cdn.slidesharecdn.com/ss_thumbnails/us-16-price-building-a-product-security-incident-response-team-learnings-from-the-hivemind-160812153709-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Streamlining AppSec Policy Definition.pptx
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
Streamlining AppSec Policy Definition.pptx
- 1. Managing Software SecurityRisk treamlining AppSec Policy Definition and Implementati For Chicago Security Meetup April 18, 2013 m Bain ector, Product Marke4ng curity Innova4on
- 2. ector, Product Marke0ng, curity Innova0on merly with Q1 Labs (an IBM Company) d Applica0on Security, Inc. 0ve blogger, presenter , Communica0ons, RIC; MS, Interna0onal a0ons/Public Affairs, UMASS Thomas Ba
- 3. Why SoOware Security? ts/Trends vs IT Sec Need portance of Priori0zing AppSec ifferences Between App & IT Sec olicy remental policy construc0on al-‐world policy improvement escrip0ve mapping to compliance Map AppSec to Compliance Ac0vity ecommenda0ons eps you should consider
- 4. plication Security Experts + Years vulnerability research curity Tes0ng Methodology adopted by SAP, crosoO, Symantec thors of 8+ books ducts and Services andards -‐ Best Prac0ces uca0on -‐ CBT & Instructor-‐Led sessment -‐ SoOware and SDLC ducing Application Security Risk 0cal Vulnerability Discovery cure SDLC Rollout
- 5. I. Why SoftwareSecurity
- 6. Secure at the Protect in Find and Fix Source Production Ø Education Ø Vulnerability Scanning Ø Firewalls Ø Remediation Ø Manual Assessments Ø Whitelisting Ø Secure Coding Ø “Whack-A-Mole” Ø “Band Aid” Standards
- 7. • 97% of breacheswere 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.
- 8. We Still Needto Bridge this Ga 71% 57% 53% Sec 41% Dev 36% 21% Process in place for building Little or no collaboration between Have no formal mandate in place security into applications the two groups for fixing vulnerable code
- 9. Software Apps AreVulnerable d their company has experienced between 1-10 data breaches ove ast 24 months as the result of an application(s) being compromised
- 10. s lose autonomy with rity policies that aren’t well-‐ ned. ormance + capabili0es oOen mp security = IT headache. s expect an always-‐on, re connec0on and 0onality e to market pressures hurt rity: But good architecture backend systems can help. frameworks can help you o market quickly can
- 11. II. AppSec vsInfoSec Policy
- 12. The CIA Triad th have policies, standards, procedures orma0on Security revolves around the mous CIA triad Maintain the confiden0ality, integrity, and vailability of informa0on stored in networks nd data communica0ons infrastructure ny so.ware to be considered secure it must conform to thes e 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
- 13. Information Security Application Security Based Receptionist, IT Manager, • Architect, Developer, Tester etc • Application Roles and Privileges w to Rollout and Rollout of web application firewall and secure ement configuration of servers, development best practices databases, anti-virus, • Application Authentication checks communications, • Secure Design components certificates, etc. • Attack surface reduction • Code hardening • Data Encryption • Input validation ertise IT networking, database • How applications interact with environment ded to and computer/OS • How applications function and fail with respe ement configuration skills security • Software development skills w/ security over
- 14. SQL Injection Policy ✔ MINIMUM uild web applica0ons that defend against SQL injec0on agacks. ✔✔ BETTER uild web applica0ons that defend against SQL injec0on agacks by sani4zing all use put. ✔✔✔ GOOD uild web applica0ons that defend against SQL injec0on agacks by sani0zing all use put using this approved sani4za4on rou4ne. ✔✔✔✔ EXCELLENT …..plus • SoOware Developers do X • SoOware Testers do Y
- 15. Protect Sensitive Data MINIMUM otect sensi0ve data. ✔ BETTER otect sensi0ve data by using this approved encryp4on. ✔✔ GOOD otect sensi0ve data by using this approved encryp0on in databases that store and ring transmission of sensi4ve data. ✔✔✔ EXCELLENT plus • Architects define algorithms. • Developers never write their own crypto. • Test/QA verifies XYZ.
- 16. Cross-Site Forgery MINIMUM ate applica0ons that are resilient to Cross-‐Site Request Forgery. BETTER ate soOware applica0ons that are resilient to CSRF agacks by using the OWASP Top RF Cheat Sheet.” ✔✔ GOOD ate soOware applica0ons that are resilient to CSRF agacks by using the OWASP Top CSRF Cheat Sheet” and implement a language-‐appropriate framework. ✔✔✔ EXCELLENT us Use challenge-‐response. QA check reference headers.
- 17. App Pen Testing icy: Conduct annual tests of internet facing applica0ons.” w to improve it pecify the type of test, e.g., web vulnerability can, source code review, paper audit, etc. ow deep should it go / What should be tested? Ø OWASP Top 10 vulnerabili0es efine the key assets you are trying to protect. pecify which agacks should be conducted. Ø Threat modeling in advance can guide you here.
- 18. icy Ensure applica0ons processing data properly authen0cate sers through central authen0ca0on systems where possible.” If addi0onal func0onality is needed, coordinate development with Informa0on Technology Services.” w to improve it ere is our approved authen0ca0on library URL. emove ambiguity. “Coordinate with ITS.” Rather, obtain wrigen excep0on for using any authen0ca0on mechanism not explicitly approved by InfoSec Office Ø “where possible”
- 19. cy QL Injec0on vulnerabili0es must be evented.” e OWASP QL_Injec0on_Preven0on_Cheat_Sheet for commenda0ons. to improve it e Parameterized SQL statements and stored ocedures. e white-‐lis0ng to constrain user input. e company-‐approved sanita0on library, und here URL.
- 20. III. Map AppSecto Compliance Initiatives
- 22. terprise Risk Management, HR, and Legal define the global pe, objec7ves and requirements for corporate vernance Applicable legisla0on (Sarbanes-‐Oxley, HIPAA, California SB 386) ndustry standards (ISO 2700x, FISMA/NIST standards) ompliance mandates (PCI DSS) egal and human resources requirements (data privacy aws) oten0al impacts of security breaches osts of security breaches and agacks
- 23. M, GRC Security teams add detail to create policies igh-‐level guidelines for opera0onal security and compliance c0vi0es an be contextualized for specific business units and func0onal oles ical tasks include: tudying the applicable regula0ons and standards onduc0ng a threat assessment to determine the security brea oten0ally most damaging to the enterprise lassifying data assets to define levels of data sensi0vity efining concrete applica0on security objec0ves
- 24. curity Compliance teams define specific development ocesses, coding prac7ces, and procedures for compliance ocumenta7on Ensures they’re relevant to local requirements and technology and consistent with corporate security and compliance policie Address regional and business-‐unit specific regula0ons and th technologies used by each team ontextualizing policies for each team can be a labor-‐intensive nd deeply technical process Saves a TON of 0me long-‐term Reduce risk over 0me with specific prac0cal the guidance
- 25. The Compliance Matrix vel Other Standards Selected Coding Practices ent (Partial List) lity SOX, HIPAA, ISO - Appropriate use of strong encryption for data in databases. 27002,, GLBA, - Encrypting confidential data in memory. No custom or untrusted encryption routines FFIEC, Basel l I, - Encrypting data in motion, especially for wireless transmissions. CA SB 1386, FIPS - Masking confidential data that needs to be viewed in part 199, NIST ty SOX, ISO 27002, - Robust integrity checks to prevent tampering with data. HIPAA, GLBA, - Input validation and comprehensive error handling to prevent injection attacks, privil FIPS 199, NIST escalation, and other hacking techniques. - Output encoding. Use of least privileges. - Hashing for confidential data that needs to be validated (e.g. passwords) ion SOX, ISO 27002, - Support for strong passwords two-factor authentication where appropriate. HIPAA, II, NIST - Role-based access control and revocation of rights, with clear roles mapped to perm SP - Locked down file access and database roles. No guest accounts. - Passwords and encryption keys encrypted before storage and transmission. d SOX, ISO 27002, - Detailed audit trails of users accessing data and resources. HIPAA, SB 1386, - Detailed logging of systems that process sensitive data, including shutdowns, restar NIST SP unusual events. No confidential data exposed in logs. - Event logs and audit trails available only to system admins and protected from unau modifications.
- 26. IV. Streamline AppSecPolicy Development to Fit Your Busines
- 27. onsider risk scenarios. dapt from proven or trustworthy models. Measure percep0on. nderstand roles/privileges. et granular. gure out a strategy for tes0ng your pplica0ons. onsider BYOD. olicy enforcement. aise awareness/required training.
- 28. an inventory of your high-‐risk ica0ons. ermine business cri0cality. t’s your agack probability? do you define the agack surface? sider overall business impact. re does compliance factor in? t are the security threats?
- 29. njec0on • A6 Sensi0ve Data Exposure Broken Authen0ca0on and (merged from former ion Management • A7 Insecure Cryptographic Cross-‐Site Scrip0ng (XSS) (was Storage merly A2) • A8 Cross-‐Site Request Forg nsecure Direct Object (CSRF) erences • A9 Using Known Vulnerabl ecurity Misconfigura0on (was Components merly A6) • A10 Unvalidated Redirects Forwards
- 30. tudes of general popula0on toward urity (suppor0ve, antagonis0c, fferent?) tudes of general popula0on toward nagement (suppor0ve, antagonis0c, fferent?) w does management view the c0on of security? at’s the percep0on of current cy? e there been related security dents?
- 31. h departments/groups/individuals been most ac0ve in developing ies? ous collabora0on between policies authors? n0al champion(s) to support? s of agreement in commonly emented controls re: policies? ort docs, materials and related ies should be cited in mobile device y. to understand user access and eges.
- 32. hich applica0ons would be used? w will web applica0ons be used? hat will access and levels of privilege look like? hat informa0on is accessible through web applica0ons? hat informa0on will be stored on web applica0ons? w will data be shared to/from web applica0ons? ho’s ul0mately responsible for applica0on security? hich applica0ons are acceptable to use? hich applica0ons should not be used? hat levels of support are expected?
- 33. sensi0ve is your data? t kind of data is it? PII, customer , credit card data, proprietary, IP, subject to regulatory mandates? ch ones? you encryp0ng data? At rest? In sit? duct a threat model: termine threats en0fy poten0al agacks nderstand the frequency severity th which they are executed.
- 34. Application Criteria hreat Sensitive Compliance Custo Lifespan ating Data Stringency Faci ier 1 Restricted Long High Ye ier 2 Private Mid Medium Ye ier 3 Public Short N/A No
- 35. Depth, Breadth, Frequency reat Static Dynamic Manual Pen Thre ting Analysis Analysis Test Mode Complete/ Complete/ Complete/ Compl Frequency Frequency Frequency Freque Required/Major Required/Major Required/Per Require er 1 code changes code changes Milestone Relea Suggested/ Required/ Required/Per Suggeste er 2 Monthly Quarterly Release Relea Optional/ Required/ Optional/As Option er 3 Quarterly Annually Needed Need
- 36. ile devices help employees increase uc0vity – staying connected is not y op0onal anymore! ge has experienced a massive up0ck: of today’s workforce is using a rtphone specifically for business use. struggling to keep up with device agement. ility by its nature opens up a larger ck surface with more points of entry. cult to measure business need ugh IT Security lens.
- 37. % use the same smartphone for rk and for personal usage. % of employed adults use at st one personally owned ctronic device for business rris Interac0ve survey, ruary 2012) % of employees surveyed use bile devices to run line-‐of-‐ iness applica0ons (Ibid) % of companies allow BYOD ge in some manner (Aberdeen up, February 2011)
- 38. % of companies have experienced ata breach due to inadequate ice security (Ponemon survey, 2) % don’t have a password on their bile phone. % stated their companies couldn’t cute a remote wipe if lost or en. % said mobile security has not n addressed with them by IT.
- 39. Why is BYODa Security Problem evice turn-‐over: What happens to the old device? ew devices: Default or customized se|ngs? ow can you know everything about every device? Oware updates – user vs IT. pp Stores: Approved apps? pplica0ons: 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.
- 40. Device Security consistent security policies ptop encryp0on bypass mode nmanageable devices ared media leakage inimal device management eadable data on disposed-‐of evices ter-‐applica0on data leakage
- 41. bile Traditional nerabilities Vulnerabilities
- 42. scribes contextual, technical guidelines on how security shou integrated within the SDLC y phase, role, technology, applica0on type everages internal secure development champion(s) for input ps to compliance mandates nsiders cri7cality of applica7on and data equirements, ac0vi0es and level of detail needed will differ s a clear excep7on policy What if minimum standards can’t be met? What is considered cceptable? Who approves? ludes internally built and third party applica7ons flects current maturity and secure development skills
- 43. u need management buy-‐in! oad strategy vs Targeted strategy roll-‐out n-‐boarding: Require policy training up front quire training for various departments: General popula0on receives awareness training Technical employees receive in-‐depth training onitor for effec0veness – EX: Deliver training or reminder hen employee is out of compliance.
- 44. Thank You!! tbain@securityinnova4on.com TwiTer: @tmbainjr1