BEGIN:VCALENDAR VERSION:2.0 PRODID:Data::ICal 0.24 BEGIN:VEVENT DESCRIPTION: 'Title: One Low\, Two Informational: Why Your Pentest Findin gs are so\n Boring\n When: Saturday\, Aug 13\, 16:30 - 17:30 PDT\n W here: Flamingo - Twilight Ballroom - AppSec Village - Main Stage -\n [1] Map\n\n SpeakerBio:Robyn Lundin\n Robyn started working in tech after a coding bootcamp as a developer\n for a small startup. She then discove red her passion for security\,\n pivoted into pentesting for NCC Group\, and now is working as a Senior\n Product Security engineer for Slack.\n \n Description:\n Application Pentests are costly\, sometimes six-figu res costly\, and can\n be very time consuming for the hosting AppSec tea m. Even so\,\n application pentests often yield very few meaningful find ings\, leaving\n potential security bugs in the wild for malicious actor s to find and\n exploit. The goal of a pentest is often to find and reme diate security\n issues before they become an even more expensive proble m. But if the\n hosting company doesn't set pentesters up for success\, the likelihood\n of a worthwhile pentest is abysmally low. While a well- done pentest\n could cost hundreds of thousands of dollars for an applic ation with a\n highly complex attack surface\, a crappy pentest could co st millions in\n ransom payouts & GDPR fines by giving the hosting compa ny a false\n sense of assurance while adding no extra protection against security\n breaches. Avoiding common pitfalls in application pentest pl anning\n will yield better results and ensure broader coverage of the ta rget\n application.\n\n Outline\n\n * Intro\n\n * Cost of an average application pentest: Maybe 10K\, or maybe\n 100K - de pends how big your app is & how much coverage you\n want\n\n * You may just be hosting a webapp pentest to check a compliance\n checkbox. That's fine\, but if you're going to spend the money\,\n make sure you're getting the most bang for your buck.\n\n * There are a number of potential mistakes that could make a\n pentest go sour and waste your company's time and money\n\n * Mistak e 1: Being unrealistic about time budgeting\n\n * How long do you think it takes to conduct a thorough webapp\n pentest? If your a nswer is "3 days"\, you're wrong.\n\n * First couple of days of a pentest\, assume there will be access\n issues that the testers have to work through to even get\n started. Don't expect product ivity until Day 3+\n\n * If you require testers to go through onbo arding or to use your\n company's equipment\, make sure to tack on an extra 2+ days to\n your pentest.\n\n * Time budget ing should account for how many APIs & pages the\n testers will need to touch\, as well as how many different\n roles (admin\, g uest\, regular user\, etc.) your system has.\n Granular Role-Bas ed access controls? That takes a long time to\n properly test.\n \n * Mistake 2: Crappy scope\n\n * Giving a pentester a URL an d telling them to go nuts is\n probably not going to yield the b est results\n\n * What keeps your team up at night? What is your c ompany's\n absolute worst-case scenario? What findings do you ca re about\,\n and what findings would you accept as an OK risk?\n \n * If you have a bug bounty\, or other way for external users to \n report security issues\, leverage that data to identify areas \n pentesters should focus their attention\n\n * With co mplex apps\, consider breaking the test down further\n into indi vidual features\, and test only a few features at a\n time to mi nimize context switching\n\n * Beware of scope creep - Be very cle ar what is and is not a\n part of the pentest\, and don't pile m ore on in the middle of\n the engagement. 3rd party services & l ibraries are generally\n off the table unless you have that 3rd party's written\n permission.\n\n * Mistake 3: Hiring the wr ong company\n\n * Do your diligence: compare & contrast at least 3 -5 pentest\n providers\n\n * Ask them about their area o f expertise. Look at their blog\n posts. If you are scheduling a pentest of an iOS app\, and you\n hire a company that specializ es in cloud security\, your\n results may not be what you expect .\n\n * Ask around - what is the company's reputation like among y our\n peers?\n\n * Ask the company for sample reports an d make sure those reports\n meet your expectations\n\n * Good reports should contain very detailed & clear remediation\n guidance. Super boiler plate-y language is a red flag\n\n * Mistake 4 : Time-wasting & poor communication\n\n * Do everything you can to ensure testers have access to\n everything they need on Day 1. If you have 3 pentesters\n working together\, wasting 1 day coul d cost upwards of 6 grand.\n\n * Be clear with testers about your communication expectations.\n Do you want a status update weekly ? Daily? When do you want to\n be notified of findings (especial ly high & critical risk\n findings)?\n\n * Involve the r ight technical experts from your dev team in the\n communication process - make sure they understand\, agree with\n and know how to fix any findings that come up!\n\n * Set up a designated chann el where testers can ask questions\,\n and devs can answer. Make sure someone is paying close\n attention to that channel. Resol ve blockers ASAP - again\,\n wasted time could cost thousands of dollars.\n\n * Mistake 5: Poor preparation\n\n * If you don't have enough documentation\, testers will not have\n a solid und erstanding of your product\n\n * Provision the right kinds of acco unts for your pentesters.\n Ideally\, having a minimum of 2 diff erent accounts at each\n role/access level will help with findin g authZ and privesc\n issues. Don't expect much if you ask pente sters to hack on\n your product without any legitimate logins.\n \n * Black box testing - not the best! If you trust the company to \n conduct your pentest\, trust them to also look through your\n code.\n\n * Do some internal threat modeling in prepara tion for the test -\n provide the results of your threat modelin g exercises to the\n pentesters.\n\n * If your product/f eature is half-baked and doesn't always work\,\n don't schedule your pentest yet. Wait till you are close\n enough to code-compl ete that pentesters won't run into weird\n error conditions just trying to use the product.\n\n * Mistake 6: No plan for remediation\n \n * Make sure the devs who will be fixing the vulnerabilities are \n on your readout call so they can ask questions\n\n * Make sure you have sufficient information from the pentesters\n to understand & fix issues. Confused? Speak up!\n\n * Are you re-t esting? When are you re-testing?\n\n * Got any SLAs? If not\, what are the expectations for\n remediation timelines\n\n '\n\n 1. https://defcon.outel.org/consolidated_page.html#FlamingoThirdFloor\n\n\ n DTEND:20220814T003000Z DTSTART:20220813T233000Z LOCATION:APV - Flamingo - Twilight Ballroom - AppSec Village - Main Stage SUMMARY:One Low\, Two Informational: Why Your Pentest Findings are so Borin g END:VEVENT END:VCALENDAR