Best Practices for a Mature Application Security Program Webinar - February 2016
Download as PPTX, PDF3 likes1,420 views
The document discusses best practices for establishing a mature application security program, highlighting the disconnect between security executives and practitioners regarding application security maturity. It emphasizes the importance of integrating application security in the software development lifecycle (SDLC), understanding application risks, and the need for formal training programs to improve developers' security awareness. It also addresses the increasing vulnerabilities in applications due to poor coding practices and the necessity for organizations to adopt a risk-based approach to application security assessments.
Best Practices for a Mature Application Security Program Webinar - February 2016
- 1. Best Practices for a Mature Application Security Program
- 2. About the Presenters • Dr. Larry Ponemon, Founder of the Ponemon Institute – Leads privacy and data protection research practices – Pioneer in privacy auditing and the Responsible Information Management (RIM) Framework • Ed Adams, CEO of Security Innovation – Ponemon Institute Fellow – Privacy by Design Ambassador – CEO by trade; engineer by heart
- 3. Agenda • Application Security Trends • Emerging Challenges, Technologies & Threats • Threat Modeling & Risk Rating Your Applications • Optimization Your Secure Software Development Lifecycle (SDLC)
- 4. Where Were We a Few Years Ago? • No Defined Software Development Process – Policies, Requirements, and Standards are often ad-hoc and not integrated into SDLC • Lack of formal AppSec training program – Most organizations do not identify, measure, or understand application security risks – Significant disconnect between executives and practitioners regarding application security maturity • Half are not testing for application security – 2/3 of mobile apps weren’t being tested at all *Findings from Application Security Maturity Research
- 5. Organizations Don’t Have a Defined SDLC • SDLC Still Lacking – Tools aren’t integrated into the SDLC – Security automation often used after deployment (too late?) – Policies and standards are still rare • Forrester – “Organizations implementing an SDLC showed better ROI than the overall population” • Aberdeen – Adopting a formal SDLC process increases security and reduces severity and cost of vulnerability incidents while generating a 4x ROI than other application security approaches
- 6. Building Security In • Department of Homeland Security (DHS) – “Regardless of which statistic is used, there is a substantial cost savings for fixing security flaws during requirements gathering than deployment”* • Gartner – “Finding bugs at operations time costs you up to 100 percent effort” Source: IBM Systems Sciences Institute Relative cost of fixing security flaws during the different development phases Implementation 6.5 Testing 15 Post Release 60 Design 1 0 10 20 30 40 50 60 70 Time Cost Source: National Institute of Standards & Technology (NIST) *DHS: Estimating Benefits from Investing in Secure Development
- 7. Most Organizations Don’t Understand AppSec Risk • Hackers are going after the easy pickings: applications (various sources) – 90%+ of vulnerabilities are in application, not network layer – 92% of attacks are not difficult and exploit KNOWN vulnerabilities • Applications are often not risk-ranked – How do you know which to test? How deep? • Web application firewalls (WAFs), application whitelisting (AWLs), and run-time application self protection (RASP) not widely adopted and often misconfigured • Organizations focus on vulnerabilities, not risk – Most vulnerabilities are treated equal and not traced back to business risk, which is contextual to YOUR organization – Many vulnerabilities can be mitigated with compensating controls… important to trace it back to business risk • Mature organizations aware of effectiveness of standards – Enables audits and understanding of the threats against an organization – Improve security, architecture and coding practices
- 8. Significant Disconnect Between Execs and Practitioners • Cisco* report indicates that top product categories exploited were Applications (32.6%) and Infrastructure (41.9%) – “We do a good job of building security into systems and applications” – 90% of the SecOps people agree or strongly agree with that statement – 96% of the CISOs agree or strongly agree with that statement • Ponemon Application Security Maturity Study 36% 40% 41% 42% 46% 48% 50% 53% 54% 58% 34% 35% 35% 31% 33% 41% 39% 37% 44% 38% 0% 10% 20% 30% 40% 50% 60% 70% There are ample resources to ensure all IT security requirements are accomplished IT security can hire and retain knowledgeable and experienced security practitioners The IT security leader is a member of the executive team IT security responds quickly to new challenges and issues The IT security function is able to prevent serious cyber attacks such as advanced persistent threats Appropriate steps are taken to comply with the leading IT security standards IT security strategy is fully aligned with the business strategy Security & data protection policies are well-defined and fully understood by employees Security technologies are adequate in protecting our information assets and IT infrastructure Application security is a top priority in my organization Developers Security *Cisco 2015 Annual Security Report
- 9. Disconnect between Management and Practitioners 75% 56% 54% 42% 23% 35% 0% 20% 40% 60% 80% Exec (28) Director (105) Mgr (135) Sup (83) Tech (226) Staff (65) Existence of defined secure architecture standards 71% 66% 56% 47% 19% 20% 0% 20% 40% 60% 80% Exec (28) Director (105) Mgr (135) Sup (83) Tech (226) Staff (65) Your organization keeps training programs up to date for development teams >3X opinion difference between Tech and Exec staff >3X opinion difference between Tech and Exec staff
- 10. Aligning Management and Staff – implications • Developers don’t always understand InfoSec and security policies – “Ensure applications are coded so as not to be susceptible to OWASP Top 10” what does this mean to a an objectiveC iOS developer? • Policy may be “in place”, but lack of enforcements renders mandate invisible • Management, security, engineers speak different languages – “Confidential data must be protected” • Protected from what? • How do I protect it? – Architecture guidance? – Coding standards? – Remediation specifics once vulnerabilities are found? » e.g., user input sanitation…. how do I do that in ASP.NET 3.5?
- 11. No Formal AppSec Training Program • Ponemon research: 19% of developers believe their organizations keep training programs up to date for development teams • Mature organizations have application security training programs in place for their developers that focus on: – Specific role-based responsibilities – Offensive and defensive tactics – Application security policies – Areas of vulnerability – Best practices and standards to be followed – Various platforms and languages they are developing in/on • Forrester – “Effective developer education program can reduce vulnerabilities by ~25%” • Veracode – “30% fix rate improvement compared to those that don’t have an elearning program
- 12. Robert Half IT Security Survey 54% of CIOs plan enhance IT Security training in 2015 *promising if this includes AppSec
- 13. Agenda • Application Security Trends • Emerging Challenges, Technologies & Threats • Threat Modeling & Risk Rating Your Applications • Optimization Your Secure Software Development Lifecycle (SDLC)
- 14. Implications for Application Security • IoT dependent on software – Software engineers not trained/confident regarding security • IDC – By 2018, fully 75 percent of chief security officers (CSO) and chief information security officers (CISOs) will report directly to the CEO, not the CIO • Execs and practitioners still out of alignment – ~70% of executives (misinformed?) think their AppSec program is mature or very mature compared to 20% of practitioners (the ones actually doing the work) • Rise of nation state attacks – 74% of organizations rate their ability to recognize a nation state attack as poor or very poor; yet, 81 percent are concerned or very concerned – 75% say their organization lacks expertise to detect or prevent a nation-state attack. This points to a substantial lack of effective technology. – The “missiles and bombs” being used are software • More regulatory and legal involvement
- 15. Threats Vary for Every Platform, Technology, Language • Web, embedded, mobile attacked in different ways – You cannot implement effective design and coding countermeasures without knowing these specific attacks – Adobe Flash vulnerabilities exploited numerous times – PHP is widely known as being insecure – Java frameworks littered with security flaws • Applications written in web scripting languages have higher prevalence of SQL injection and Cross-Site Scripting than applications written in .NET or Java. • Each Technology has different security features and vulnerabilities • .NET and J2EE protect against buffer overflows but objectiveC does not • Heartbleed, Shellshock, POODLE, GotoFail, Stuxnet – All software born exploits
- 16. Mobile Application Security • Ponemon Institute – 2013 - 65% of developers do not test mobile applications – 2015 - 33% of companies still not testing their applications • $34m spent developing mobile apps – 5% allocated to securing mobile apps – 50% of companies devote zero budget to mobile app security – 40% of companies surveyed are Fortune 500 • Gartner – Claimed in 2014 that more than 75 Percent of Mobile Applications will Fail Basic Security Tests Through 2015 – They likely got it right (see above) • Veracode – Mobile applications have the highest rate of cryptographic issues, at 87 percent for Android and 80 percent for iOS – Developers don’t understand how to properly implement crypto for the various mobile platforms they are developing for
- 17. Why Are 90% of Attacks STILL at Application Layer? Application Security 5% More than 80% of IT security spending continues to be at the network layer, primarily focused on perimeter security Source Information Security – Wave 17
- 18. Applications Will Continue to be Targets • Department of Homeland Security (DHS) – “90 percent of security incidents result from exploits against defects in software” • Tim Clark, Head of Brand Journalism at SAP, in a recent Forbes blog – “Many organizations have significant network security in place but it’s not enough as 84 percent of all cyber-attacks are happening on the application layer” • Cisco 2015 Annual Security Report – “Intruders are increasingly targeting the application stack for exploitation” – “Rise of cloud apps and the ubiquity of do-it-yourself (DIY) open-source content management systems (CMS) has created vulnerable websites and SaaS offerings. – Underlying systems/networking layers may withstand malicious attacks, but application-level components built by developers are often riddled with vulnerabilities.” • CNET – “Programmers are copying security flaws in to your software – “Programmers don’t write all of their code. They routinely borrow code from others, and they’re not checking the code for security flaws.” • Wall Street – “Most developers have not been trained on secure coding practices”
- 19. Financial Services & Retail Under Attack Sources: Imperva Web APPLICATION ATTACK REPORT #5 and CAST’s Biennial CRASH Report (2015) • Poor code quality exposed more than two-thirds of financial services applications to cyber-attacks similar to the Heartbleed bug • 70% of retail and 69% of financial services applications featured data input validation violations, a form of coding error central to the Heartbleed bug – There are known, best practices for sanitizing input • Financial services industry has highest number of input validation violations per application (224)
- 20. Industry Regulation - NY Dept of Financial Services • Conducted risk assessments and found more needs to be done to secure financial systems • Highlights of proposed mandates – Implement and maintain written cyber security policies – Designate a CISO and submit annual report assessing cybersecurity program – Application Security: maintain and implement written procedures, guidelines, and standards reasonably designed to ensure the security of all applications utilized by the entity. – Mandatory training to cyber security personnel and require key personnel to stay abreast of changing threats and countermeasures – Conduct annual pen testing and quarterly vulnerability assessments Bottom Line: Rollout AppSec program and you’ll meet most industry and compliance regulatory mandates
- 21. Agenda • Application Security Trends • Emerging Challenges, Technologies & Threats • Threat Modeling & Risk Rating Your Applications • Optimization Your Secure Software Development Lifecycle (SDLC)
- 22. Managing Risk – Tracing Vulnerabilities to Exposure • Vulnerability - a weakness in some aspect/feature of system that makes an exploit possible • Threat - undesired or negative occurrence that might damage or compromise an asset or objective. May/may not be malicious in nature • Attack/Exploit - an action or set of actions taken against a system that utilizes one or more vulnerabilities to realize a threat • Probability - likelihood of a specific attack being realized. Takes into account discoverability and difficulty of exploitation • Exposure - amount of damage to an organization if a specific threat is realized • Risk - exposure and probability weighted ranking of a given threat • Countermeasures - address vulnerabilities to reduce the probability of attacks or the impacts of threats. Do not directly address threats
- 23. Taking a Risk-Based Approach to Assessments • Conventional approaches to application security not risk-based – Typically no more than automated vulnerability scanning that look for some pre-determined set of common vulnerabilities – Frequently fail to address each application’s unique code-, system- and workflow-level vulnerabilities – Provides little practical guidance on prioritizing defect remediation – Does not enable the creation of a roadmap to guide enterprise application security posture improvements • The majority of application security programs focus on:* – Automated security testing during development (41%) – Secure coding standards that are adhered to (32%) – A secure SDLC process improvement plan (30%) *”The State of Application Security Maturity” – Ponemon Institue & Security Innovation
- 24. • Provides more leverage than any other security activity • Aligns technical and management teams on threat areas • Makes EVERY engineering activity more impactful • We threat model every day in our personal lives – Apply the same approach to software applications Threat Mitigation Vulnerability Attacker Threat Modeling “To know your enemy, you must become your enemy.” - Sun Tzu
- 25. Threat Modeling – Value Across the Whole IT Team • Architects – Shape your application design to meet security objectives – Understand and prioritize assets to protect – Build security architecture to protect critical assets • Developers – Build countermeasures based on key threats – Use secure coding best practices to protect against attack • Testers – Drive test plans to ensure attacks focus on high threat areas • IT/DevOps – Conduct a deployment review against the threat model to ensure server configurations are appropriates – Threat Model a portfolio of applicaitons
- 26. Application Risk Rating • Helps Ensure: – Assessment and mitigation activities are done cost effectively – Prioritization is based on real business risk – The business doesn't get distracted by minor risks while ignoring more serious risks that are less well understood • Inappropriate security assessments are costly – Deep inspection on all applications is neither feasible nor necessary – Running an automated scan on critical application will lead to trouble • Allows you to understand risk-based options – Remove, replace, take off-line, or implement compensating controls Business Criticality is driving factor when determining which applications to secure and level of regular assessment needed
- 27. Framework for Application Security Risk Rating • Risk = Likelihood * Impact • Remember that threats can be inherited from system dependencies and connectivity – Attackers can leverage non-critical apps to get to critical apps • There is no standard formula – Risk tolerance and data classification are contextual to each organization • Make sure risk-rating framework is: – Transparent so decisions and calculations can be easily explained – Adaptable so each group can apply unique drivers, goals, resources – Practical so you end up with something that works
- 28. Defining Tiers: 3 Tier Approach * Customer-facing applications would include internet-facing applications as well as applications that reside on mobile or in-home devices • Assign a score for each category, e.g., 0 to 3 – This gives you a scale of 0 to 12 for each application using the 4 categories above • Define risk thresholds that qualify an application to fall into a tier – Score of 0-3 is Tier 3 – 4-8 is Tier 2 – 9 or higher is Tier 1
- 29. Aligning Test Efforts with Application Risk Security Testing Depth and Frequency Threat Rating Static Analysis (Source Code) Dynamic Analysis (Live Application) Manual (Penetration) Testing Threat Modeling Complete Frequency Complete Frequency Complete Frequency Complete Frequency Tier 1 (critical) Required Major code changes Required Major code changes Required Per- Milestone Required Per- Release Tier 2 (high) Suggested Monthly Required Quarterly Required Per- Release Suggested Per- Release Tier 3 (low) Optional Quarterly Required Annually Optional As-Needed Optional As Needed • Calibrate the frequency and depth of testing according to risk rating – Also contextual to your organization – Driven by your risk tolerance and disaster recovery plans
- 30. Remediation Prioritization • Determine what to fix – Are there compensating controls that can be implemented to mitigate? – Can your organization live with the risk? – Some loss is to be expected, justifiable based upon remediation cost • The model should evolve over time – Choose factors that represent what's important for your organization • military application might add impact factors related to loss of human life • window of opportunity for an attacker or encryption algorithm strength – Weight factors to emphasize more significance for business operations – Fine-tune the model by matching it against risk ratings that the business agrees are accurate
- 31. Agenda • Application Security Trends • Emerging Challenges, Technologies & Threats • Threat Modeling & Risk Rating Your Applications • Optimization Your Secure Software Development Lifecycle (SDLC)
- 32. Security Engineering Doesn’t Require Changing Your Process Just augment it with a set of high-impact security activities
- 33. Different Activities Yield Different Values • Threat Modeling – Ensures key threats are considered during coding and testing, but is only a framework • Code Reviews – Critical activity to prevent vulnerabilities from propagating but doesn’t consider the as-deployed state or flaws introduced by environment – Often more important than • Manual penetration testing – Finds the most elusive and deeply rooted vulnerabilities, but is time consuming and requires skill • Scanner find common vulnerabilities faster than humans but – Can’t detect business logic and compound vulnerabilities – Are prone to time-wasting false positives
- 34. 1. Review Org Structure and Team Roles 2. Analyze Policies & Standards Requirements 3. Analyze & Aggregate Data 4. Refine via Focused Interviews (usually team leads) 5. Create Gap Analysis Report with Recommendations SDLC Process Assessment – Graphical View Best Practices
- 35. Five Maturity Levels from SI-Ponemon Research • Level 1 (Initial) – Lack of discipline and maturity in the SDLC; no focus on security • Level 2 (Repeatable) – Disciplined and repeatable SDLC but security is purely reactive – Security is addressed by patching issues based on penetration testing results and public incidents • Level 3 (Defined) – Security in the SDLC is standardized and defined – Corporate application security policies are defined – Formal security requirements are defined during development process – Secure coding standards are in place and the code is reviewed to these standards – Security testing is part of the normal testing cycle “The State of Application Security” https://www.securityinnovation.com/uploads/ponemon-state-of-application-security-maturity.pdf
- 36. Five Maturity Levels – Cont’d • Level 4 (Managed) – Predictable process that is measurable and managed – Threat modeling used to assess and prioritize risk in each phase – Secure architecture standards in place and design is reviewed to these standards – Development teams (and the code they produce) are measured against compliance security requirements as well as secure architecture and coding standards – Application security risk is measured and well understood across the application portfolio – Third party security audits are conducted for all high-risk applications • Level 5 (Optimized) – Continuously improving process that is mature and optimizing – Risk metrics are used to guide application security decision making – Vulnerability discoveries are used to update requirements and standards – Security activities are analyzed and improved based on assessments of vulnerabilities in the code
- 37. Rolling out a Secure SDLC • A mature SDLC has formal requirements, designs, implementation and testing procedures in place – Mature organizations also have security procedures defined at each phase – Organizations are not adequately emphasizing process, let alone security, during development • View security as yet another aspect of software quality – Treat vulnerabilities as bugs • just a different kind of one – Integrate security bugs with your defect triage and management process
- 38. Application Security Policy – Key Components • Describes contextual, technical guidelines on how security should be integrated within the SDLC – By phase, role, technology, application type – Leverages internal secure development champion(s) for input • Maps to compliance mandates • Considers criticality of application and data – Requirements, activities and level of detail needed will differ • Has clear exception policy – What if minimum standards can’t be met? What is considered acceptable? Who approves? • Includes internally built and third party applications • Reflects current maturity and secure development skills – The more skilled, the less explicit you need to be with policies
- 39. Secure, Repeatable Development Works: the Microsoft SDL • Major Challenges: • Needed to roll out the Microsoft Security Development Lifecycle (SDL) to hundreds of development teams • Internal instructor-led training was effective, but not scalable and couldn’t be re-purposed for new employees • Needed a way to train vendors on the Microsoft SDL to ensure software consumed by Microsoft had security considered • Security Innovation Solution: • Customized 14 eLearning courses specific to the Microsoft SDL • Same content base as current courses in our eLearning library In 24 months, Microsoft was able to go from having 30% of its product teams trained on the SDL to 70% (over 3,000 users)
- 40. Investing in Your SDLC Works! Consistent application of sound security practices during all phases of development will facilitate compliance and result in fewer vulnerabilities http://www.microsoft.com/security/sdl/about/benefits.aspx
- 41. Best Practices for Enterprise Assessments • Use automated tools for heavy lifting – Find known vulnerabilities faster than humans – Adopt when you have the skills to use properly – Be sure tools are integrated into SDLC and used at key checkpoints • Complement with manual efforts – Necessary to find deeply rooted, business logic, and other vulnerabilities that tools can not find – Be sure to leverage a threat model to focus on high-risk areas • Support vulnerability remediation – Problem isn’t solved when found, only when corrected properly – Match test efforts with your organization’s ability to remediate • Measure effectiveness
- 42. The Application Security Conundrum Secure at the Source Protect in Play Assess/Test InfoSec Standards Secure Coding Standards Secure SDLC Training Web Application Firewalls Application Whitelisting RASP DLP Vulnerability Scanning Penetration Testing Manual or Automated Code or in Production These strategies should not be mutually exclusive – leveraging all three will have an exponential effect in risk reduction
- 43. Conclusion • Application risk rating is a critical step in managing security efforts across a large number of applications – Needs to be contextual to your organization's risk tolerance • Be sure tools are integrated into SDLC and used at key checkpoints • Build the skills needed to get more out of tools and find vulnerabilities that tools can not • Leverage a threat model throughout your SDLC – Match test efforts with application criticality and your ability to remediate • Measure effectiveness
- 44. Who is Security Innovation & How Can We Help? • Pioneer in Application Security – 15+ years research on threats and vulnerabilities – Security testing methodology adopted by SAP, Symantec, Microsoft, and McAfee – Authors of 18 books, 10 with Microsoft • Help clients navigate application security risk ASSESSMENT - Show me the Gaps! STANDARDS - Set goals and make it easy EDUCATION - Enable me to make the right decisions
- 45. Assess Your Application Security Maturity • Defined an effective software development process? • Are automated tools integrated into your SDLC? • Defined a set of corporate application security policies? • Defined secure coding and architecture standards? • Measuring testing applications against compliance requirements? Find Out How You Stack Up! http://securityinnovation.com/uploads/asm-questionnaire/start.html
- 46. Questions?
- 47. Thank You! • All attendees will receive a recording of today’s session • Email us at marketing@securityinnovation.com for a copy of the presentation • All On-Demand Webinars can be found at www.securityinnovation.com/security-lab/webcasts Connect With Us!