Tuesday, September 26, 2017

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/


Here is a new episode of Brakeing Down Security Podcast!

Sunday, September 17, 2017

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.

 


Here is a new episode of Brakeing Down Security Podcast!

Monday, September 11, 2017

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-done.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 Template
The 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


Here is a new episode of Brakeing Down Security Podcast!

Sunday, September 3, 2017

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/


Here is a new episode of Brakeing Down Security Podcast!