
BrakeSec Education Podcast
A podcast about the world of Cybersecurity, Privacy, Compliance, and Regulatory issues that arise in today's workplace. Co-hosts Bryan Brake, Brian Boettcher, and Amanda Berlin teach concepts that aspiring Information Security professionals need to know, or refresh the memories of seasoned veterans.
Latest episodes

Oct 22, 2017 • 48min
2017-SPECIAL004- SOURCE Conference Seattle 2017
After last year's SOURCE Conference, I knew I needed to go again, not just because it was a local (Seattle) infosec conference, but because of the caliber of speakers and the range of topics that were going to be covered. I got audio from two of the speakers at the SOURCE conference (@sourceconf) on Twitter Lee Fisher and Paul English from PreOS Security about UEFI security and methods to secure your devices https://preossec.com/ Joe Basirico discusses the proper environment to get the best out of your bug bounty program. points from his abstract: Bug Bounty Programs - Why you want to invite security researchers to hack your products Marketing your Security Program - How and why to market your security program. What to say, how to say it, and where to say it for maximum effectiveness. How to Communicate with Security Researchers - What are security researchers expecting in communication, responsiveness, transparency, and time to fix. Source conference YouTube Channel: https://www.youtube.com/channel/UCAPQk1fH2A4pzYjwTCt5-dw/videos (2017 is not available yet, but all talk from 2008-2015 is available) agenda of the talks that occurred at Source Seattle 2017 https://www.sourceconference.com/seattle-2017-agenda https://www.sourceconference.com/copy-of-seattle-2016-agenda-details RSS: http://www.brakeingsecurity.com/rss Youtube Channel: http://www.youtube.com/c/BDSPodcast #iTunes Store Link: https://itunes.apple.com/us/podcast/brakeing-down-security-podcast/id799131292?mt=2 #Google Play Store: https://play.google.com/music/m/Ifp5boyverbo4yywxnbydtzljcy?t=Brakeing_Down_Security_podcast Join our #Slack Channel! Sign up at https://brakesec.signup.team #iHeartRadio App: https://www.iheart.com/show/263-Brakeing-Down-Securi/ #SoundCloud: https://www.soundcloud.com/bryan-brake Comments, Questions, Feedback: bds.podcast@gmail.com Support Brakeing Down Security Podcast on #Patreon: https://www.patreon.com/bds_podcast #Twitter: @brakesec @boettcherpwned @bryanbrake @infosystir #Player.FM : https://player.fm/series/brakeing-down-security-podcast #Stitcher Network: http://www.stitcher.com/s?fid=80546&refid=stpr #TuneIn Radio App: http://tunein.com/radio/Brakeing-Down-Security-Podcast-p801582/

Oct 16, 2017 • 59min
2017-035-Business_Continuity-After_the_disaster
Direct Link: http://traffic.libsyn.com/brakeingsecurity/2017-035-business_continuity-After_the_disaster.mp3 We are back this week after a bit of time off, and we getting right back into it... What happens after you enact your business continuity plan? Many times, it can cause you to have to change processes, procedures... you may not even be doing business in the same country or datacenter, and you may be needing to change the way business is done. We also talk a bit about 3rd party vendor reviews, and what would happen if your 3rd party doesn't have a proper plan in place. Finally, we discuss the upcoming #reverseEngineering course starting on 30 October 2017 with Tyler Hudak, as well some upcoming appearances for Ms. Berlin at SecureWV, GrrCon, and Bsides Wellington, #newZealand RSS: http://www.brakeingsecurity.com/rss Youtube Channel: http://www.youtube.com/c/BDSPodcast #iTunes Store Link: https://itunes.apple.com/us/podcast/brakeing-down-security-podcast/id799131292?mt=2 #Google Play Store: https://play.google.com/music/m/Ifp5boyverbo4yywxnbydtzljcy?t=Brakeing_Down_Security_podcast Join our #Slack Channel! Sign up at https://brakesec.signup.team #iHeartRadio App: https://www.iheart.com/show/263-Brakeing-Down-Securi/ #SoundCloud: https://www.soundcloud.com/bryan-brake Comments, Questions, Feedback: bds.podcast@gmail.com Support Brakeing Down Security Podcast on #Patreon: https://www.patreon.com/bds_podcast #Twitter: @brakesec @boettcherpwned @bryanbrake @infosystir #Player.FM : https://player.fm/series/brakeing-down-security-podcast #Stitcher Network: http://www.stitcher.com/s?fid=80546&refid=stpr #TuneIn Radio App: http://tunein.com/radio/Brakeing-Down-Security-Podcast-p801582/ ---SHOW NOTES--- You have enacted your BC/DR plan Step 1. Panic Step 2. Panic more, or let your management panic Step 3. Follow the plan… you do have a plan, right? Enacting a BC/DR plan RPO/RTO - https://www.druva.com/blog/understanding-rpo-and-rto/ Recovery Point Objective (RPO) describes the interval of time that might pass during a disruption before the quantity of data lost during that period exceeds the Business Continuity Plan’s maximum allowable threshold or “tolerance.” https://en.wikipedia.org/wiki/Recovery_point_objective Recovery Time Objective (RTO) is the duration of time and a service level within which a business process must be restored after a disaster in order to avoid unacceptable consequences associated with a break in continuity. https://en.wikipedia.org/wiki/Recovery_time_objective https://uptime.is/99.99 Excerpt from "Defensive Security Handbook" - Buy from Amazon (sponsored link): http://amzn.to/2zcmWBY Recovery Point Objective The recovery point objective (RPO) is the point in time that you wish to recover to. That is, determining if you need to be able to recover data right up until seconds before the disaster strikes, or whether the night before is acceptable, or the week before, for example. This does not take into account of how long it takes to make this recovery, only the point in time from which you will be resuming once recovery has been made. There is a tendency to jump straight to seconds before the incident; however, the shorter the RPO, the more the costs and complexity will invariably move upwards. Recovery Time Objective The recovery time objective (RTO) is how long it takes to recover, taken irrespective of the RPO. That is, after the disaster, how long until you have recovered to the point determined by the RPO. To illustrate with an example, if you operate a server that hosts your brochureware website, the primary goal is probably going to be rapidly returning the server to operational use. If the content is a day old it is probably not as much of a problem as if the system held financial transactions whereby the availability of recent transactions is important. In this case an outage of an hour may be tolerable, with data no older than one day once recovered. In this case the RPO would be one day, and the RTO would be one hour. There is often a temptation for someone from a technology department to set these times; however, it should be driven by the business owners of systems. This is for multiple reasons: It is often hard to justify the cost of DR solutions. Allowing the business to set requirements, and potentially reset requirements if costs are too high, not only enables informed decisions regarding targets, but also reduces the chances of unrealistic expectations on recovery times. IT people may understand the technologies involved, but do not always have the correct perspective to make a determination as to what the business’ priorities are in such a situation. The involvement of the business in the DR and BCP plans eases the process of discussing budget and expectations for these solutions. RPO should be determined when working through a Business impact analysis (BIA) https://www.ready.gov/business-impact-analysis https://www.fema.gov/media-library/assets/documents/89526 There is always a gap between the actuals (RTA/RPA) and objectives After an incident or disaster, a ‘Lessons Learned’ should identify shortcomings and adjust accordingly. This may also affect contracts, or customers may require re-negotiation of their RTO/RPO requirements If something happens 4 hours after a backup, and you have an hour until the next backup, you have to reconcile the lost information, or take it as a loss Loss = profits lost, fines for SLAs You may not be doing the same after the disaster. New processes, procedures https://www.bleepingcomputer.com/news/security/fedex-says-some-damage-from-notpetya-ransomware-may-be-permanent/ Ms. Berlin’s appearances Grrcon - http://grrcon.com/ Hack3rcon/SecureWV - http://securewv.com/ Oreilly Conference - https://conferences.oreilly.com/security/sec-ny/public/schedule/detail/61290 Experts Table? Bsides Wellington (sold-out) ---- CLASS INFORMATION Introduction to Reverse Engineering with Tyler Hudak Starts on 30 October - 20 November 4 Mondays Sign up on our Patreon (charged twice, half when you sign up, half again when 1 November happens

Oct 7, 2017 • 1h 15min
2017-SPECIAL003-Audio from Derbycon 2017!
Direct Link: http://traffic.libsyn.com/brakeingsecurity/2017-SPECIAL003-Derbycon_audio.mp3 Mr. Boettcher, Ms. Berlin, and I went to Derbycon. In addition to the podcast with podcasters we did during the 3 days, I managed to grab another whole hour of audio from various people at the conference, just to give you an idea of the vibe of the conference, in case you were unable to attend. We talked to the FOOOLs (http://www.bloomingtonfools.org/), and how they have done the lockpick village for the last 7 years. We talk to Ms. Wynter (@sec_she_lady) about her experiences at her first Derbycon. Mr. Matt Miller (@milhous30) talked about some of his #reverse #engineering challenges that were in the #Derbycon #CTF Lots of great talks happened there this year, check them all out over on @irongeek's site (http://www.irongeek.com/i.php?page=videos/derbycon7/mainlist) RSS: http://www.brakeingsecurity.com/rss Youtube Channel: http://www.youtube.com/c/BDSPodcast #iTunes Store Link: https://itunes.apple.com/us/podcast/brakeing-down-security-podcast/id799131292?mt=2 #Google Play Store: https://play.google.com/music/m/Ifp5boyverbo4yywxnbydtzljcy?t=Brakeing_Down_Security_podcast Join our #Slack Channel! Sign up at https://brakesec.signup.team #iHeartRadio App: https://www.iheart.com/show/263-Brakeing-Down-Securi/ #SoundCloud: https://www.soundcloud.com/bryan-brake Comments, Questions, Feedback: bds.podcast@gmail.com Support Brakeing Down Security Podcast on #Patreon: https://www.patreon.com/bds_podcast #Twitter: @brakesec @boettcherpwned @bryanbrake @infosystir #Player.FM : https://player.fm/series/brakeing-down-security-podcast #Stitcher Network: http://www.stitcher.com/s?fid=80546&refid=stpr #TuneIn Radio App: http://tunein.com/radio/Brakeing-Down-Security-Podcast-p801582/

Oct 2, 2017 • 1h 2min
2017-034-Preston_Pierce, recruiting, job_descriptions
*Apologies for the continuity this was recorded before we went to Derbycon 2017.* Preston Pierce is a recruiter. We wanted to have him on to discuss some issues with our industry. So we had him on to discuss hiring practices, how a recruiter can help a company recruiter better talent, and how to stop companies looking for the 'unicorn' candidate. Preston is a great guy and we learned a lot about how the recruiting process works, and how Preston's company work differently from other, less reputable companies. We also discuss job descriptions, getting management buy in for a good candidate, and more. Direct Link: http://traffic.libsyn.com/brakeingsecurity/2017-034-Preston_Pierce_recruiting_job_descriptions.mp3 RSS: http://www.brakeingsecurity.com/rss Youtube Channel: http://www.youtube.com/c/BDSPodcast #iTunes Store Link: https://itunes.apple.com/us/podcast/brakeing-down-security-podcast/id799131292?mt=2 #Google Play Store: https://play.google.com/music/m/Ifp5boyverbo4yywxnbydtzljcy?t=Brakeing_Down_Security_podcast Join our #Slack Channel! Sign up at https://brakesec.signup.team #iHeartRadio App: https://www.iheart.com/show/263-Brakeing-Down-Securi/ #SoundCloud: https://www.soundcloud.com/bryan-brake Comments, Questions, Feedback: bds.podcast@gmail.com Support Brakeing Down Security Podcast on #Patreon: https://www.patreon.com/bds_podcast #Twitter: @brakesec @boettcherpwned @bryanbrake @infosystir #Player.FM : https://player.fm/series/brakeing-down-security-podcast #Stitcher Network: http://www.stitcher.com/s?fid=80546&refid=stpr #TuneIn Radio App: http://tunein.com/radio/Brakeing-Down-Security-Podcast-p801582/ Show Notes: https://news.slashdot.org/story/17/09/01/1729237/us-employers-struggle-to-match-workers-with-open-jobs Blueteamers Looking at job descriptions, Fix if outdated or unnecessary Managers Be realistic about expectations Recruiters Better research of people Discuss realistic demands from customers You Update your LinkedIn removing overly generalized terms (healthcare, for example) When should you reach out to a recruiter? Right away? After you’ve already completed some leg work? Companies do a poor job of marketing for their current openings.

Sep 27, 2017 • 1h 19min
2017-SPECIAL002-Derbycon-podcast with podcasters (NSF Kids/Work)
Direct Link: http://traffic.libsyn.com/brakeingsecurity/2017-SPECIAL002-Derbycon-Podcast_with_podcasters.mp3 SUPER NOT SAFE for kids (and probably adults, come to think of it). Really this is just us riffing about derbycon (and I really love @oncee, and wished I'd gone to his stable talk (which you can listen/watch here: http://www.irongeek.com/i.php?page=videos/derbycon7/s07-the-skills-gap-how-can-we-fix-it-bill-gardner) We actually did talk about the skills gap, resume workshop held at Derbycon, and so much else. If you haven't been to Derbycon, you should definitely make plans now to attend... RSS: http://www.brakeingsecurity.com/rss Youtube Channel: http://www.youtube.com/c/BDSPodcast #iTunes Store Link: https://itunes.apple.com/us/podcast/brakeing-down-security-podcast/id799131292?mt=2 #Google Play Store: https://play.google.com/music/m/Ifp5boyverbo4yywxnbydtzljcy?t=Brakeing_Down_Security_podcast Join our #Slack Channel! Sign up at https://brakesec.signup.team #iHeartRadio App: https://www.iheart.com/show/263-Brakeing-Down-Securi/ #SoundCloud: https://www.soundcloud.com/bryan-brake Comments, Questions, Feedback: bds.podcast@gmail.com Support Brakeing Down Security Podcast on #Patreon: https://www.patreon.com/bds_podcast #Twitter: @brakesec @boettcherpwned @bryanbrake @infosystir #Player.FM : https://player.fm/series/brakeing-down-security-podcast #Stitcher Network: http://www.stitcher.com/s?fid=80546&refid=stpr #TuneIn Radio App: http://tunein.com/radio/Brakeing-Down-Security-Podcast-p801582/

Sep 17, 2017 • 1h 1min
2017-033- Zane Lackey, Inserting security into your DevOps environment
Zane Lackey (@zanelackey on Twitter) loves discussing how to make the DevOps, and the DevSecOps (or is it 'SecDevOps'... 'DevOpsSec'?) So we talk to him about the best places to get the most bang for your buck getting security into your new DevOps environment. What is the best way to do that? Have a listen... Direct Link: http://traffic.libsyn.com/brakeingsecurity/2017-033-Zane_Lackey_inserting_security_into_your_DevOps.mp3 RSS: http://www.brakeingsecurity.com/rss Youtube Channel: https://www.youtube.com/channel/UCZFjAqFb4A60M1TMa0t1KXw #iTunes Store Link: https://itunes.apple.com/us/podcast/brakeing-down-security-podcast/id799131292?mt=2 #Google Play Store: https://play.google.com/music/m/Ifp5boyverbo4yywxnbydtzljcy?t=Brakeing_Down_Security_podcast Join our #Slack Channel! Sign up at https://brakesec.signup.team #iHeartRadio App: https://www.iheart.com/show/263-Brakeing-Down-Securi/ #SoundCloud: https://www.soundcloud.com/bryan-brake Comments, Questions, Feedback: bds.podcast@gmail.com Support Brakeing Down Security Podcast on #Patreon: https://www.patreon.com/bds_podcast #Twitter: @brakesec @boettcherpwned @bryanbrake @infosystir #Player.FM : https://player.fm/series/brakeing-down-security-podcast #Stitcher Network: http://www.stitcher.com/s?fid=80546&refid=stpr #TuneIn Radio App: http://tunein.com/radio/Brakeing-Down-Security-Podcast-p801582/ --SHOW NOTES-- Security shifts from being a gatekeeper to enabling teams to be secure by default Require a culture shift Should that be implemented before the shift to CI/CD, or are we talking ‘indiana jones and the rock in the temple’? How? Secure coding? Hardening boxes/Systems? If it’s just dev -> prod, where does security have the chance to find issues (i.e. test and QA belong there)? We used to have the ability for a lot of security injection points, but no longer Lowers the number of people we have to harangue to be secure…? Security success = baked in to DevOps Shift from a ‘top down’ to ‘bottom up’ Eliminate FPs, and forward on real issues to devs Concentrate on one or two types of vulnerabilities Triage vulns from most important to least important Go for ‘quick wins’, or things that don’t take a lot of time for devs to fix. Grepping for ‘system(), or execve()’ Primitives (hashing, encryption, file system operations) How do you stop a build going to production if it’s going out like that? Do we allow insecurity to go to Production? Or would it be too late to ‘stop the presses’? “We’ll fix it in post…” Instead of the ‘guardrail not speedbump’ you are the driving instructor... But where does security get in to be able to talk to devs about data flow, documentation of processes? 5 Y’s - Why are you doing that? Setup things like alerting on git repos, especially for sensitive code Changing a sensitive bit of code or file may notify people Will make people think before making changes Put controls in terms of how they enable velocity You like you some bug bounties, why? Continuous feedback Learn to find/detect attackers as early in the attack chain Refine your vuln triage/response Use bug reports as IR/DFIR... https://www.youtube.com/watch?v=ORtYTDSmi4U https://www.slideshare.net/zanelackey/how-to-adapt-the-sdlc-to-the-era-of-devsecops http://www.slideshare.net/zanelackey/building-a-modern-security-engineering-organization In SAST, a modern way to decide what to test is start with a small critical vuln, like OS command injection. Find those and get people to fix it. BUT don’t developers or project teams get unhappy [sic] if you keep "moving the goal post" as you add in the next SAST test and the next SAST test. How do you do that and not piss people off? [15:16] How do you make development teams self sufficient when it comes to writing a secure application? Security is a road block during a 3 month release schedule….getting "security approval" in a 3 day release cycle is impossible. [15:17] But then…what is the job for the security team? If DevOps with security is done right, do you still need a security team, if so what do they do???? Do they write more code??? I don't think your Dev'ops'ing security out of a job...but where does security see itself in 5 years? Last one if there is time and interest. If Zane Lackey was a _maintainer_ of an open source project, what dev ops sec lessons would he apply to that dev model…to the OpenSource model? (We've got internal projects managed with the open source model...so im interested in this one) Even with out any of those questions the topics he covered in his black hat talk are FULL of content to talk about. Heck, even bug bounties are a topic of conversation. The idea of a feedback loop to dev...where an application under attack in a pen test can do fixes live....how that is possible is loads of content.

Sep 12, 2017 • 48min
2017-032-incident response tabletops, equifax breach
Everyone should be doing incident response tabletops, even if it's not a dedicated task in your organization. It allows you to find out what you might be lacking in terms of processes, manpower, requirements, etc. This week, we discuss what you need to do to get ready for one, and how those should go in terms of helping your organization understand how to handle the aftermath. And in case you've been under a rock, #equifax was breached. 143 million credit records are in the ether. We discuss the facts as of 9 September 2017, and what this means to the average user. Direct Link: http://traffic.libsyn.com/brakeingsecurity/2017-032-incident_response-equifax-done2.mp3 RSS: http://www.brakeingsecurity.com/rss Youtube Channel: https://www.youtube.com/channel/UCZFjAqFb4A60M1TMa0t1KXw #iTunes Store Link: https://itunes.apple.com/us/podcast/brakeing-down-security-podcast/id799131292?mt=2 #Google Play Store: https://play.google.com/music/m/Ifp5boyverbo4yywxnbydtzljcy?t=Brakeing_Down_Security_podcast Join our #Slack Channel! Sign up at https://brakesec.signup.team #iHeartRadio App: https://www.iheart.com/show/263-Brakeing-Down-Securi/ #SoundCloud: https://www.soundcloud.com/bryan-brake Comments, Questions, Feedback: bds.podcast@gmail.com Support Brakeing Down Security Podcast on #Patreon: https://www.patreon.com/bds_podcast #Twitter: @brakesec @boettcherpwned @bryanbrake @infosystir #Player.FM : https://player.fm/series/brakeing-down-security-podcast #Stitcher Network: http://www.stitcher.com/s?fid=80546&refid=stpr #TuneIn Radio App: http://tunein.com/radio/Brakeing-Down-Security-Podcast-p801582/ ---SHOW NOTES--- Incident response Must go beyond ‘threats’. What is in your environment Struts aren’t a threat, or are they? Equifax didn’t think so at the time… Insider threat External entities Libraries plugins/themes used (Wordpress) Risk analysis Qualitative Quantitative What makes a good incident response exercise ( Following the creation and implementation of security controls around use cases, can be the testing of tabletop exercises and drills as a proof of concept. A tabletop exercise is a meeting of key stakeholders and staff that walk step by step through the mitigation of some type of disaster, malfunction, attack, or other emergency in a low stress situation. A drill is when staff carries out as many of the processes, procedures, and mitigations that would be performed during one of the emergencies as possible.While drills are limited in scope, they can be very useful to test specific controls for gaps and possible improvements. A disaster recovery plan can be carried out to some length, backups can be tested with the restoration of files, and services can be failed over to secondary cluster members.Tabletop exercises are composed of several key groups or members. During a tabletop exercise there should be a moderator or facilitator that will deliver the scenario to be played out. This moderator can answer “what if ” questions about the imaginary emergency as well as lead discussion, pull in additional resources, and control the pace of the exercise. Inform the participants that it is perfectly acceptable to not have answers to questions during this exercise. The entire purpose of tabletops is to find the weaknesses in current processes to mitigate them prior to an actual incident.• A member of the exercise should also evaluate the overall performance of the exercise as well as create an after-action report. This evaluator should take meticulous notes as well as follow along any runbook to ensure accuracy. While the evaluator will be the main notetaker, other groups and individuals may have specific knowledge and understanding of situations. In this case having each member provide the evaluator with their own notes at the conclusion of the tabletop is a good step.• Participants make up the majority of this exercise. Included should be groups such as Finance, HR, Legal, Security (both physical and information), Management, Marketing, and any other key group that may be required. Participants should be willing to engage in the conversation, challenge themselves and others politely, and work within the parameters of the exercise. What to include in the tabletop:• A handout to participants with the scenario and room for notes.• Current runbook of how security situations are handled.• Any policy and procedure manuals.• List of tools and external services. Post-exercise actions and questions:• What went well?• What could have gone better?• Are any services or processes missing that would have improved resolution time or accuracy?• Are any steps unneeded or irrelevant?• Identify and document issues for corrective action.• Change the plan appropriately for next time. Tabletop TemplateThe Federal Emergency Management Agency (FEMA) has a collection of different scenarios, presentations, and tabletops that can be used as templates. Derbycon channel on Slack Intro to RE class https://blogs.apache.org/foundation/entry/apache-struts-statement-on-equifax https://hackernoon.com/a-series-of-unfortunate-events-or-how-equifax-fire-eye-threw-oil-on-the-fire-c19285f866ed

Sep 4, 2017 • 1h 4min
2017-031-Robert_Sell-Defcon_SE_CTF-OSINT_source
This week, we met up with Robert Sell to discuss competing in the DefCon Social Engineering CTF. You're gonna learn how he prepared for the competition, and learn about some of the tactics you could use to compete in future SE CTF events. Direct Link: http://traffic.libsyn.com/brakeingsecurity/2017-031-Robert_Sell-Defcon-SE-CTF.mp3 RSS: http://www.brakeingsecurity.com/rss Youtube Channel: https://www.youtube.com/channel/UCZFjAqFb4A60M1TMa0t1KXw #iTunes Store Link: https://itunes.apple.com/us/podcast/brakeing-down-security-podcast/id799131292?mt=2 #Google Play Store: https://play.google.com/music/m/Ifp5boyverbo4yywxnbydtzljcy?t=Brakeing_Down_Security_podcast Join our #Slack Channel! Sign up at https://brakesec.signup.team #iHeartRadio App: https://www.iheart.com/show/263-Brakeing-Down-Securi/ #SoundCloud: https://www.soundcloud.com/bryan-brake Comments, Questions, Feedback: bds.podcast@gmail.com Support Brakeing Down Security Podcast on #Patreon: https://www.patreon.com/bds_podcast #Twitter: @brakesec @boettcherpwned @bryanbrake @infosystir #Player.FM : https://player.fm/series/brakeing-down-security-podcast #Stitcher Network: http://www.stitcher.com/s?fid=80546&refid=stpr #TuneIn Radio App: http://tunein.com/radio/Brakeing-Down-Security-Podcast-p801582/

Aug 29, 2017 • 53min
2017-030-Vulnerability OSINT, derbycon CTF walkthrough, and bsides Wellington!
This week, we discuss the lack of information and where you might find more information about certain vulnerabilities. Seems like many companies fail to give out necessary and actionable information without paying an arm and a leg. We also go over our DerbyCon CTF walkthrough, and discuss the steps to solve it. Direct Link: http://traffic.libsyn.com/brakeingsecurity/2017-030-vulnerability_OSINT-derbycon_CTF_walkthrough.mp3 Ms. Berlin is going to be at Bsides Wellington! Get your Tickets NOW! https://twitter.com/bsideswlg https://www.bsides.nz/ RSS: http://www.brakeingsecurity.com/rss Youtube Channel: https://www.youtube.com/channel/UCZFjAqFb4A60M1TMa0t1KXw #iTunes Store Link: https://itunes.apple.com/us/podcast/brakeing-down-security-podcast/id799131292?mt=2 #Google Play Store: https://play.google.com/music/m/Ifp5boyverbo4yywxnbydtzljcy?t=Brakeing_Down_Security_podcast Join our #Slack Channel! Sign up at https://brakesec.signup.team #iHeartRadio App: https://www.iheart.com/show/263-Brakeing-Down-Securi/ #SoundCloud: https://www.soundcloud.com/bryan-brake Comments, Questions, Feedback: bds.podcast@gmail.com Support Brakeing Down Security Podcast on #Patreon: https://www.patreon.com/bds_podcast #Twitter: @brakesec @boettcherpwned @bryanbrake @infosystir #Player.FM : https://player.fm/series/brakeing-down-security-podcast #Stitcher Network: http://www.stitcher.com/s?fid=80546&refid=stpr #TuneIn Radio App: http://tunein.com/radio/Brakeing-Down-Security-Podcast-p801582/ --show notes-- NCC group talks in Seattle NIST guidelines - no security questions, no SMS based 2fa Vuln OSINT Sites have information like Spokeo… Breadcrumbs Take Java for example (CVE-2017-10102): info is sparse Other sites have more https://tools.cisco.com/security/center/viewAlert.x?alertId=54521 - worse than Oracle’s site (impressive crappery) Some are better: RHEL is fairly decent https://access.redhat.com/errata/RHSA-2017:2424 Ubuntu has some different tidbits https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-10102.html Arch has info https://security.archlinux.org/CVE-2017-10102 Point is, just because you use a specific OS, don’t limit yourself… other OSes may contain more technical info. Some maintainers like to dig, like you. https://vuldb.com/ - gives value of finding such a PoC for a vuln (5-25K USD for 2017-10102) Derbycon CTF walkthrough Looking for an instructor for an ‘intro to RE’ course. Dr. Pulaski = Diana Maldaur Dr. Crusher = Gates McFadden

Aug 20, 2017 • 1h 18min
2017-029-CIS benchmarks, Windows Update reverts changes used to detect malware
This week was one heck of a show. If you are a blueteamer and make use of the "Windows Logging Cheat Sheet", you are no doubt aware of how important it is to log certain events, and to set hostile conditions to make malware/Trojans/virus have a harder time avoiding detection. What if I told you the same updates we suggested last week to NEVER delay actually undoes all your hardening on your system and leaves your logfiles set to defaults, all file associations for suspect files like pif, bat, scr, bin, are set back to defaults, allow your users to be victims again, even after you've assured them they are safe to update? After a sequence of tweets from Michael Gough about just this exact thing, we laid out all the information, how and what get reverted that will open you back up to possible infections, as well as how some hardening standards actually make it harder to be secure. Finally, we discuss the CIS benchmarks, and how many of the settings in them are largely outdated and why they need to be updated. Direct Download: http://traffic.libsyn.com/brakeingsecurity/2017-029-windows_updates_clobbers_security__settings_CIS_hardening_needs_an_update.mp3 RSS: http://www.brakeingsecurity.com/rss Youtube Channel: https://www.youtube.com/channel/UCZFjAqFb4A60M1TMa0t1KXw #iTunes Store Link: https://itunes.apple.com/us/podcast/brakeing-down-security-podcast/id799131292?mt=2 #Google Play Store: https://play.google.com/music/m/Ifp5boyverbo4yywxnbydtzljcy?t=Brakeing_Down_Security_podcast Join our #Slack Channel! Sign up at https://brakesec.signup.team #iHeartRadio App: https://www.iheart.com/show/263-Brakeing-Down-Securi/ #SoundCloud: https://www.soundcloud.com/bryan-brake Comments, Questions, Feedback: bds.podcast@gmail.com Support Brakeing Down Security Podcast on #Patreon: https://www.patreon.com/bds_podcast #Twitter: @brakesec @boettcherpwned @bryanbrake @infosystir #Player.FM : https://player.fm/series/brakeing-down-security-podcast #Stitcher Network: http://www.stitcher.com/s?fid=80546&refid=stpr #TuneIn Radio App: http://tunein.com/radio/Brakeing-Down-Security-Podcast-p801582/ --SHOW NOTES-- Gough says ‘something is bad about CIS’ CIS benchmarks need revamping -- BrBr /var, /var/log in separate partitions? Password to access grub? Disable root login to serial pty? Many cloud instances and VMs don’t have serial ports (not in a traditional sense) What’s the use case for using them? What problem will they solve? Misconfiguration? Proper logging? NTP sources? So many, dilution possible SCAP OVAL STIG (complex as well) CIS Infosec: how do we get IT past the “that’s good enough”, as many customers and compliance frameworks want to see ‘hardening’ done. What is a good baseline? Write your own? How do we tell them that it’s not going to stop ‘bad guys’ ( or anyone really)? It’s not ‘security’, and it’s technically not even ‘best practices’ anymore (not all of it, anyway) On windows, they are needlessly complicated and cause more problems Roles have to be created “backup admin” Can cause unintended issues https://twitter.com/HackerHurricane/status/898629567056797696 https://twitter.com/HackerHurricane/status/892838553528479745 Category Sub Category 7/2008 8.1 2012 Win-7 Win-8.1 WLCS ThisPC Notes Detailed Tracking Process Termination NA NA NA NA NA S/F S Object Access File Share NA NA NA NA NA S/F S/F Object Access File System NA NA NA F NA S S/F Object Access Filtering Platform Connection NA NA NA NA NA S S Object Access Filtering Platform Packet Drop NA NA NA NA NA NA NA Log Sizes: ------------- Security - 1 GB Application – 256MB System – 256MB PowerShell/Operational – 512MB – 1 GB v5 Windows PowerShell – 256MB TaskScheduler – 256MB Log Process Command Line (5) (5) (5) (5) (5) Yes Yes ------------------------------------------------------------------------------------------------------------------------- PowerShell Logging v5 (5) (5) (5) (5) (5) Yes Yes ------------------------------------------------------------------------------------------------------------------------- TaskScheduler Log (5) (5) (5) (5) (5) (1) Yes ----------------------------------------------------------------------------------------------------------------- (5) - CIS Benchmarks, USGCB, and AU ACSC do not cover this critical auditing item