Pwned: The Information Security Podcast show

Pwned: The Information Security Podcast

Summary: Pwned is a weekly information security podcast addressing real-world cybersecurity and information security challenges. Each week we cover a new topic from cybersecurity, to information security, to best practices, to security technology, and how-to's. All topics are from Security professionals, and CISOs and security stories from the field.

Join Now to Subscribe to this Podcast
  • Visit Website
  • RSS
  • Artist: Justin Fimlaid
  • Copyright: © Copyright 2018-2019 Justin Fimlaid & Pwned


 Exim Server Vulnerabilities and Exploits | File Type: audio/mpeg | Duration: 6:36

Sponsor: Contact Me: Twitter: @justinfimlaid LinkedIn: All the notes: Interesting Tid-bits: Known C&C: http://173[.]212.214.137/s Firewall Addresses:

 AppSec Authentication Requirements | File Type: audio/mpeg | Duration: 8:51

Sponsor: Contact Me: Twitter: @justinfimlaid LinkedIn:

 Winnti Malware for Linux | File Type: audio/mpeg | Duration: 4:57

Sponsor: Contact Me: Twitter: @justinfimlaid LinkedIn:

 APT10 Update | File Type: audio/mpeg | Duration: 5:57

Sponsor: Contact Me: Twitter: @justinfimlaid LinkedIn: IOCs: APT10/Operation Cloud Hopper - Indicators of Compromise v3.csv  

 Ohio’s Data Protection Act | File Type: audio/mpeg | Duration: 8:34

Important Links: More Info: State of Ohio Data Protection Act Law Text: IAPP Analysis (by Katelyn Burgess): What is the Ohio Data Protection Law (by Jenna Kersten): Sponsor: Contact Me: Twitter: @justinfimlaid LinkedIn:

 SHA-1 Collision Attacks Explained | File Type: audio/mpeg | Duration: 14:42

Important Links: SHA-1 Collision Explanation Page: Malicious Hashing: Eve’s Variant of SHA-1 Finding SHA-1 Characteristics: General Results and Applications: Sponsor: Contact Me: Twitter: @justinfimlaid LinkedIn:

 Vulnerability Management and Patching | File Type: audio/mpeg | Duration: 17:44

Show Notes: Sponsor: Contact Me: Twitter: @justinfimlaid LinkedIn:

 Getting started with NIST Cybersecurity Framework | File Type: audio/mpeg | Duration: 12:44

Show Notes: Sponsor: Contact Me: Twitter: @justinfimlaid LinkedIn:

 Penetration Testing or Red Teaming? | File Type: audio/mpeg | Duration: 8:16

Show Notes: Sponsor: Contact Me: Twitter: @justinfimlaid LinkedIn:

 As Facts Change So Does My Opinion | File Type: audio/mpeg | Duration: 7:14

Sponsor: Contact Me: Twitter: @justinfimlaid LinkedIn: My opinion of security has changed. We are not keeping up.  Companies keep getting breached. First things first, the idea and concepts of security have been around for a while.  In the most general terms, truth is we have senior industry and junior skill set.  Our collective industry is not helping us be better.  Security product companies are coming to the market with new half solutions and big marketing budgets.  Advisory companies are coming to the table with new buzzwords and hollow concepts.  And "thought leaders" and "trusted advisors" are still trying to figure this out, and probably not giving the best advice yet.  All these things take our collective eye off the ball, cause us to loose focus, and distract us from doing well at security fundamentals. For those listening to this unfamiliar with our space, here's some examples what we're dealing with: People failing to understand that IT Operations and security are completely different disciplines.  It's like building a house, you need someone to lay out the blueprint, someone to pour the foundation, someone frame house, someone to do the electricity, someone to the plumbing.  These are not the same people.  IT Operations and IT Security professionals are not the same people.  If you want your house built to code like you want good security hygiene you should hire a security professional.Accounting firms pretending internal controls translates to good security operations.  This is a problem.  Internal control is destination, but you need a map and relevant mechanism of transport to get to you destination.  While I'm sure there are some accountants who play in security, articulating the map and which vehicle to use can be a problem and due to CPA independence rules they are sometimes prohibited from providing tactical guidance.Value added resellers (VAR's) being incentivized to push one product over another. I'm pretty sure I'm going to get some hate mail from this, but I don't think anyone would disagree that vendors and resellers push products to maximize their fiscal standing versus seeking best of breed when it might not be the companies best interest.  This creates a ton of confusion in security and really muddies the water, when this happens the only objective measure is price…which is always a bad space to be. Those are some examples, but it's not all bad.  We need stay focused though. In order for our security industry to get better we need get back to basics of good security hygiene.  I admit this is easier said than done, its going to take time to get there.  Until we do this we can’t start to think about automation because if you do crappy security and automate it, security automation will allow you just do crappy security faster.  You don't need blockchain, if you don't believe it do some research in European Election Security…they use good old-fashion asymmetric encryption.  If you're getting started, or need a realignment go back the fundamentals, good policy, good security architecture, good security hygiene of accounts, etc.  When you've done this, then hopefully you have a good handle on requirements for security technology and you have the expertise on how the technology should work in your environment.

 The Open Banking Directive and Application Security | File Type: audio/mpeg | Duration: 7:10

Show Notes: Sponsor: Contact Me: Twitter: @justinfimlaid LinkedIn: Application Security Checklist for Web Applications and API's. Also @ NuHarbor Security. I have not seen an Open Banking Web Application Checklist, so hopefully this is a good starting point for some. 1.Ensure HTTPS: This one is pretty simple but HTTPS protects authentication credentials in transit for example passwords, API keys, or JSON Web Tokens. It also allows clients to authenticate the service and guarantees integrity of the transmitted data. 2. Security Tokens:  There seems to be a convergence toward using JSON web tokens as the format for security tokens. JSON web tokens are JSON data structure containing a set of claims that can be used for access control decisions. If you are looking for more on JSON formats, here's a good starting point. 3. Access Control: Non-public rest services must perform access control at each API endpoint. Web services in monolithic applications implement this by means of user authentication, authorization of logic in session management.  To this right at scale, user authentication should be through a centralized Identity Provider which issues their own tokens. 4. Input Validation: Anyone developing for a while knows this is a requirement.  If you don't sanitize inputs your application days are numbered.  Contact me if you want the full-list on this one. 5. Restrict HTTP Methods: Apply a whitelist of permitted HTTP Methods (e.g. GET, POST, PUT) and make sure the caller is authorized to use the incoming HTTP method on the resource collection, action, and record.  Leverage 405's when rejecting all requests not matching the whitelist. 6. API Keys: API Keys can reduce the impact of denial of service attacks. However, when their issue to third-party clients, they are easy to compromise.  There are a couple things you can do to mitigate security risks including require API keys for every request to the protected endpoint. You can also returning a 429 message "too many requests" if the volume of requests are to high. Do not rely solely on API keys to protect high-value resources. 7. Validate Content Types: A rest request a response body should match the intended content type in the header. Otherwise this can cause misinterpretation at the consumer/producer side lead to code injection/execution.  Some additional things to think about: Validate Request Content TypesSend Safe Response Content Types 8. Manage Endpoints: There is a couple things you can do to securely manage your end points. Avoid exposing your management and points by way of the Internet. If your management and points must be accessible to the Internet, make sure that all users authenticate using strong authentication mechanisms such as multi factor authentication. Security by obscurity is not always a good strategy, but exposing management endpoints by way of different HTTP ports or host on different/restricted subnets can also reduce some risk.  Lastly restrict access to these endpoints by firewall ACL's. 9. Error Handling:

 Election Security and Estonia’s e-Voting System | File Type: audio/mpeg | Duration: 10:30

Show Notes: Sponsor: Contact Me: Twitter: @justinfimlaid LinkedIn:

 Why People, Process, Technology is Not Enough | File Type: audio/mpeg | Duration: 7:58

Show Notes: Sponsor: Contact Me: Twitter: @justinfimlaid LinkedIn:

 Quick Brief on PCI-DSS 4.0 | File Type: audio/mpeg | Duration: 5:03

Show Notes: Sponsor: Contact Me: Twitter: @justinfimlaid LinkedIn:

 Application Security Authentication Requirements | File Type: audio/mpeg | Duration: 8:51

Show Notes: Sponsor: Contact Me: Twitter: @justinfimlaid LinkedIn:


Login or signup comment.