Nazira Omuralieva - Susan Kaufman - Improving Application Security - Vulnerability Response in the ISV World

1,610 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,610
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
27
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Now that we have spent the entire day learning about the important elements to consider to improve application security like secure design and secure coding principles – lets clearly establish the fact that no matter how secure your processes and practices, security vulnerabilities are a reality. So, lets turn our focus towards the reactive side of application security and the need to pay attention to this as well as how it ties back to the proactive side. One important element of the proactive side is also to make sure that the development teams consider having a well established vulnerability response plan and process and identify the functions and people who will respond to these vulnerabilities. I will not focus on techniques to find security flaws/ vulnerabilities which have been previously covered today, but would rather focus on the importance of having a well defined vulnerability response process, what the most important components are of this process and what types of questions to consider in order to put a process like this in place.
  • The 4 main entities involved in the vulnerability response ecosystem are : the vendors who are developing products and applications and in a way responsible for the vulnerabilities in their apps, the security researchers who find these vulnerabilities, either on their own or via customers of vendors who purchase these products from the vendors and the public organizations (CERT, Mitre with their CVE etc.) that publish information on vulnerabilities and aid with making sure the right information on these vulnerabilities is made available to all concerned. It is important to have a seamless process between all these concerned parties to provide a comprehensive and complete vulnerability response ecosystem. In a perfect world, all of these entities work in perfect harmony but we are well aware that we do not live in a perfect world. I will talk to you about the vendor view primarily and the role they play in this ecosystem. At the same time I will touch upon the other entities and their roles as well, but as this session is about improving application security, my focus will be on vendors. I will use examples from EMC and our own vulnerability response process to help give some real world and practical use cases and hopefully that will give you a good understanding of how to put some of these examples to good use. Give EMC’s background.
  • In EMC’s case – we established the EMC Product Security Response Center which is part of the larger EMC Product Security Office that also has the responsibility for the proactive activities and building products with the right processes and following the right security practices – everything that you have heard about today.
  • Title Month Year EMC PSRC leverages ind standards such as: CVE, CVSS to score the vulns, CWE to map the issues/ vulns against a common definition EMC PSRC also manages relationships with researchers and reporting orgs such as: CERT, iDefense Labs, Tipping Point etc.
  • I want to give you a look into the how a typical vulnerability response flow works starting with Discovery………….
  • A very important step that needs to be considered as part of the response process is what do the vendors do after the remedy release. It is important to do a root cause analysis of the issue to figure out if such issues can exist in other parts of the code. One of the mistakes that vendors do is to look at an issue in isolation and try and fix it without considering the other parts of the code in which the same issue can exist. We have seen multiple XSS issues be reported and fixed and then another XSS crop up in other parts of the code. The other important aspect to cover is to figure out what could have been done during the development practices to prevent similar vulnerabilities. Talk about design, development, testing etc., Also, important is to make sure vulnerability regression testing is built into the testing cycle. It is very embarrassing to have the vulnerability creep in into the next version of the product. Do not do a patch work fix – do a holistic fix.
  • As part of your vulnerability response program, it is important to also make information available on your public website for customers/ researchers on resources your company has made available for them to report security vulnerabilities. This should not be hidden somewhere on the site. Instead make it prominent and one of the best practices is to have a URL companyname.com/security where people can find out how to access these resources.
  • Have a monitored mailbox and post your public a PGP key for folks to use
  • As part of the security advisories or whatever your company calls them, consider these as the important elements to cover in the advisory from a best practices perspective – giving an EMC example: 1. CVE Identifier – getting a CVE for the advisories makes them available in a public database for your customers to search for them or even scanners to pick them up 2. Severity rating – can roughly be translated to how quickly your customers should pay attention to the advisory 3. Details 4. Resolution/ Mitigation steps
  • Nazira Omuralieva - Susan Kaufman - Improving Application Security - Vulnerability Response in the ISV World

    1. 1. Nazira Omuralieva Susan Kaufman RSA, The Security Division of EMC Improving Application Security – Vulnerability Response in the ISV World SourceBoston 2011
    2. 2. Session Objectives <ul><li>Vulnerability response ecosystem and guiding principles for effective vulnerability response </li></ul><ul><li>Important roles & responsibilities in a software vendor organization for vulnerability response </li></ul><ul><li>Typical vulnerability response process </li></ul><ul><li>Tips on how you can create an effective vulnerability response program in your organizations including resources in the public domain </li></ul>
    3. 3. Vulnerability Response Ecosystem
    4. 4. Critical Components of a Successful Vulnerability Management Approach Source: Counterpane time risk Vulnerability discovered Vulnerability reported Vendor patches vulnerability Users install patch Minimize time between patch availability and patch installation (Customer) Minimize time between vulnerability report and patch availability (Vendor & Finder) <ul><li>Key actors: </li></ul><ul><ul><li>Finder </li></ul></ul><ul><ul><li>Vendor </li></ul></ul><ul><ul><li>Customer </li></ul></ul>
    5. 5. Vulnerability Response: Guiding Principles <ul><li>Drive towards simultaneously publishing the vulnerability and the remedy </li></ul><ul><ul><li>Maintain a good relationship with the finder </li></ul></ul><ul><ul><li>Ensure prompt response, updates and resolution </li></ul></ul><ul><li>Protect company’s reputation & shareholders </li></ul><ul><ul><li>Avoid bad press </li></ul></ul><ul><ul><li>Enforce legal review </li></ul></ul><ul><li>Align with customer best practices </li></ul><ul><ul><li>Proactive notification of security patch availability </li></ul></ul><ul><ul><li>Continuous evaluation of public vulnerability impact on products </li></ul></ul><ul><ul><li>Efficient response to customers’ scan reports </li></ul></ul><ul><li>Enable customers to evaluate related risk </li></ul><ul><ul><li>Provide enough information to evaluate ease of exploitation and impact </li></ul></ul>Product S ecurity R esponse
    6. 6. Vulnerability Response: EMC’s Guiding Principles <ul><li>Drive towards simultaneously publishing the vulnerability and the remedy </li></ul><ul><ul><li>Maintain a good relationship with the finder </li></ul></ul><ul><ul><li>Ensure prompt response, updates and resolution </li></ul></ul><ul><li>Protect company’s reputation & shareholders </li></ul><ul><ul><li>Avoid bad press </li></ul></ul><ul><ul><li>Enforce legal review </li></ul></ul><ul><li>Align with customers best practices </li></ul><ul><ul><li>Proactive notification of security patch availability </li></ul></ul><ul><ul><li>Continuous evaluation of public vulnerability impact on products </li></ul></ul><ul><ul><li>Efficient response to customers’ scan reports </li></ul></ul><ul><li>Enable customers to evaluate related risk </li></ul><ul><ul><li>Provide enough information to evaluate ease of exploitation and impact </li></ul></ul>EMC Product S ecurity R esponse Center* *EMC PSRC is a direct function of the EMC Product Security Office
    7. 7. EMC PSRC Leverages Industry Resources and Relationships <ul><li>Supports industry standards: </li></ul><ul><ul><li>Common Vulnerability & Exposure (CVE) </li></ul></ul><ul><ul><ul><li>Unique definition of vulnerabilities maintained by MITRE </li></ul></ul></ul><ul><ul><li>Common Vulnerability Scoring System (CVSS) </li></ul></ul><ul><ul><ul><li>Severity rating defined by FIRST </li></ul></ul></ul><ul><ul><li>Common Weakness Enumeration (CWE) </li></ul></ul><ul><ul><ul><li>a list of software weakness types maintained by MITRE </li></ul></ul></ul><ul><li>Relationships with researchers, reporting organizations & other industry bodies </li></ul><ul><ul><li>Tipping Point’s Zero Day Initiative (ZDI) </li></ul></ul><ul><ul><li>Computer Emergency Response Team (CERT) </li></ul></ul><ul><ul><li>Fortinet's FortiGuard </li></ul></ul><ul><ul><li>Secunia </li></ul></ul><ul><ul><li>Member of FIRST </li></ul></ul>
    8. 8. Roles & Responsibilities: Vulnerability Response Process
    9. 9. Roles & Responsibilities for an Effective Vulnerability Response Program (EMC example) Finder <ul><ul><li>Disclose vulnerability information to EMC privately </li></ul></ul>Product Engineering <ul><ul><li>Appoint vulnerability response team members </li></ul></ul><ul><ul><li>Create inventory of embedded components and subscribe to security alerts </li></ul></ul><ul><ul><li>Validate vulnerability reports </li></ul></ul><ul><ul><li>Create timeline for response </li></ul></ul>Security Response Taskforce <ul><ul><li>Includes trained members from Engineering, Legal, Marketing, Public Relations, Investor Relations, Customer Service </li></ul></ul><ul><ul><li>Review and approve the remediation and communication plans </li></ul></ul>Customers <ul><ul><li>Receive security advisories and keep up to date with patches </li></ul></ul>
    10. 10. Typical Vulnerability Response Process Flow
    11. 11. <ul><li>Root Cause Analysis </li></ul><ul><ul><li>Analyze the root cause of product vulnerabilities to detect and eliminate similar vulnerabilities that may already exist in the product </li></ul></ul><ul><ul><li>Adjust development practices to prevent similar vulnerabilities in the future </li></ul></ul><ul><li>Vulnerability Regression Testing </li></ul><ul><ul><li>Add tests to the regression test suite to prevent reintroduction of the vulnerability </li></ul></ul>Important Steps After the Remedy Release
    12. 12. Examples of how to publicly share information on your vulnerability response program
    13. 13. www.emc.com/security Make it easy to report a security vulnerability
    14. 14. Detailed Process on Reporting a Security Vulnerability <ul><li>Monitored mailbox </li></ul><ul><li>PGP key for communication </li></ul>
    15. 15. Example of a Security Advisory <ul><li>CVE Identifier </li></ul><ul><li>Severity Rating </li></ul><ul><li>Details </li></ul><ul><li>Resolution steps </li></ul>
    16. 16. EMC Response Examples
    17. 17. No One Size Fits All <ul><li>Coordinated Disclosure – researcher and vendor working in harmony </li></ul><ul><ul><li>EMC Celerra vulnerability publicly disclosed at Black Hat </li></ul></ul><ul><li>Industry wide impact and cooperation on a vulnerability in a widely used protocol </li></ul><ul><ul><li>SSL TLS protocol vulnerability </li></ul></ul><ul><li>Researcher/ customer publicly discloses information about a vulnerability not giving time for the vendor to respond </li></ul><ul><ul><li>Vulnerability in EMC product publicly posted in an industry forum </li></ul></ul>Model your process on industry best practices but expect surprises
    18. 18. Questions to consider and tips
    19. 19. Tricky Questions That The PSRC Comes Across Regularly <ul><li>Responsible disclosure vs. coordinated disclosure vs. full disclosure vs……. </li></ul><ul><li>When to release a security patch vs. remediating the vulnerability in the next maintenance pack? </li></ul><ul><li>When to publicly disclose security vulnerabilities vs. just fixing them in product releases? </li></ul><ul><li>How to coordinate remediation and release of vulnerabilities found in common components developed by your company to take care of internal dependencies? </li></ul><ul><li>How to keep third party/ open source embedded components up to date? </li></ul><ul><li>Many more…. </li></ul>
    20. 20. Steps to Creating a Vulnerability Response Program <ul><li>Create a company wide Vulnerability Response Policy and Process including roles and responsibilities and timelines for response </li></ul><ul><ul><li>Do not wait till a vulnerability gets publicly reported </li></ul></ul><ul><li>Get executive acceptance and buy-in </li></ul><ul><li>Train internal employees on their roles and responsibilities </li></ul><ul><li>Set up a monitored mailbox that researchers can use to send vulnerability reports and make it available on your website </li></ul><ul><li>Create a way to deliver security patches and send security advisories to customers (public facing website, subscribed email lists) </li></ul><ul><li>Establish disclosure practices (choose your poison – responsible/coordinated…) </li></ul><ul><li>Maintain good relationships with finders – give them credit for finding vulnerabilities </li></ul>Do not reinvent the wheel but customize it to your unique needs
    21. 21. <ul><li>Resources in the public domain </li></ul><ul><ul><li>Forum for Incident Response and Security Teams </li></ul></ul><ul><ul><li>Organization for Internet Safety: Security Vulnerability Reporting and Response Guidelines </li></ul></ul><ul><ul><li>National Infrastructure Advisory Council: Disclosing and Managing Vulnerability Guidelines </li></ul></ul><ul><ul><li>Common Vulnerabilities and Exposure (CVE) </li></ul></ul><ul><ul><li>Common Vulnerability Scoring System </li></ul></ul><ul><ul><li>National Vulnerability Database </li></ul></ul>Speaking of Not Reinventing the Wheel…
    22. 22. THANK YOU

    ×