Info

Brakeing Down Security Podcast

A podcast all about the world of Security, 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 the seasoned veterans.
RSS Feed Subscribe in Apple Podcasts
Brakeing Down Security Podcast
2017
October
September
August
July
June
May
April
March
February
January


2016
December
November
October
September
August
July
June
May
April
March
February
January


2015
December
November
October
September
August
July
June
May
April
March
February
January


2014
December
November
October
September
August
July
June
May
April
March
February
January


All Episodes
Archives
Now displaying: Page 1
Aug 31, 2015

Once you find a vulnerability, how do you handle patching it? Especially when devs have their own work to do, there are only so many man hours in a sprint or development cycle, and the patching process could take up a good majority of that if the vuln is particularly nasty.

One method is to triage your patches, and we discuss that this week with Mr. Boettcher. We also talk about how our respective company's handle patching of systems.

We also discuss what happens when compensating controls run out of effectiveness, and if there is a point at which they no longer are 'compensating' for anything any further.

2 Comments
  • over two years ago
    Bryan
    agreed... it truly is dependent on the business' mission. You need to deploy where and how it makes the most sense... Thorough testing, no matter which way you deploy patches is important as well.
  • over two years ago
    MGreen
    Thanks for your podcast - I have really gotten some great info over the last year of listening.

    re: doing PRODUCTION-DR first - our standard is to do PROD first. If we have an issue at our primary site, we want to be able to failover to the DR site to fix or rollback in PROD. We only patch DR first if our business partners insist and accept the risk. There are arguments for and against the order, depending on architecture, stability, robustness of both sides. In some of our cases DR may not mirror the architecture of PROD exactly (less servers, other reduced resources etc). That is what we feel is best practice for us. We also have some x-site High Availability services that mean it really doesn't matter which geographical site goes first since it's all highly available.