The Southern Fried Security Podcast

Join Andy Willingham, Martin Fisher,Steve Ragan, Yvette Johnson, and Joseph Sokoly as they discuss information security, news, and interview interesting people. Get in the discussion at www.southernfriedsecurity.com.

Episode 208 - All Good Things... 01/11/2019

Episode 207 - On the Front Porch with Yvette and Brandon 08/31/2018

Episode 206 - The Front Porch w/@wendynather @securityincite @jwgoerlich 06/24/2018

Episode 205 - LIve from BSides Atlanta! 05/08/2018

Episode 204 - Evaluating Your Security Program: Communications Plan 03/12/2018

Episode 203 - Evaluating Your Security Program: Threat Mapping 02/13/2018

Episode 202: -Evaluating Your Security Program : Awareness & Education 01/29/2018

Episode 201 - Celebration 10/11/2017

Episode 200 - Building a Security Strategy - Part III 09/13/2017

Episode 199 - Building a Security Strategy - Part II 08/09/2017

Episode 198 - Building a Security Strategy Part 1 06/24/2017

Episode 197 - After the Penetration Test 06/08/2017

Episode 197 - After the Penetration Test Episode 197 - After the Penetration Test We've kind of talked about how to choose your vendors, and we’ll get more into services soon, but we wanted to take some time to talk about penetration tests and especially what to do as they wrap up, how they affect the organization, and how you can manage your penetration tests to make sure they're actually effective. Receiving the report First and foremost, you are the customer. The report is not done until you say it is done. That doesn't mean to massage the data, but you need to be sure that the penetration testers actually provided value. If there isn't a solid executive summary, send it back. Period. Your testers should be able to summarize what they did, what they found, and what they think for your executives. A Nessus or Burp scan is not a report. Ever. Always ask “how did we do for this application/organization size” etc. You’re not just paying for someone to run Nessus on your network, you’re paying for their analysis. Ask for that. Triaging the Results Results rarely go to the same place in the organization. You might have findings for different teams, or entirely different parts of your org. Make sure they get to the right people. Results may be inaccurate for your organization. A penetration tester isn't necessarily familiar with your organization’s risk profile, priorities, or anything else. What they mark as a medium may be a high or critical for you, or vice versa. Example: Information disclosure in Healthcare is often rated much higher when triaging than in other types of businesses. Working with the stakeholders Work in systems that make sense to people that need to do the work. Rally, Jira, etc. This can also give you traceability for when things are actually fixed. Don’t dump on people in big group meetings, take the findings to the specific teams That will give them time to develop a plan for the findings that are affecting them Managing upwards No matter how well or poorly the report is written, it’s still going to end up being your job to explain “how bad is this thing you handed me?” Have to manage the findings and their perception upwards Remediate, mitigate, or accept That's an upper management call Dealing with the Re-test Most penetration tests have a clause in there for re-testing findings. Make sure you actually take advantage of that. This looks good from both an actual security posture position and a management position Some penetration testers will let you remediate quickly and have them re-test, which can be reflected in the final report Especially if your report might going to customers, this is incredibly useful. Take advantage of this if at all possible. /episode/index/show/sfspodcast/id/5429268

Episode 196 - WannaCry: Woulda, Coulda, Shoulda 05/25/2017

Episode 195 - Annual Policy Review - Making it Worthwhile 05/11/2017

Episode 195 - Annual Policy Review - Making it Worthwhile Episode 195 - Annual Policy Review - Making It Worthwhile Define policy vs. standards vs. procedures What is a Policy? It is a guiding principle to set the direction of an organization. High level, governing, statements. Do not include technical details. Example: Policy statement = Users must authenticate with a unique ID and password Standard: User passwords must be: # of characters, include one uppercase letter, one special character, be at least 10 characters in length. This type of information would go into an Access Control Standard. What is a Standard? Standards support the policy, make it more meaningful and effective. What is a Procedure? A procedure is a step by step, how to guide to which is consistent with the end result being the same. These are the steps for configuring your firewalls, setting up a new user, building a server, etc. Every policy guide everywhere says you need to review your policies regularly which almost always means annually. Failure to do the annual review can get you in hot water with your regulator and/or auditor. It just Makes Sense. Why review your policies? It’s the one time a year you can nudge the organization where it needs to go Past Problems Current Issues Future Challenges Killing off/modifying policies that get in the way of people doing work will Make Friends And Influence People There is no better way to ensure your team is working on what needs to be worked on than aligning with stated policy. Making Sense of Policy Review Alert The Approvers Line Them Up Divide and Conquer Bring The Business Into The Process Internal Audit Legal Risk Corporate Security IT Marketing / Public Relations As Needed Bring In Change Crosswalks FTW Communicate, Communicate, Communicate. The Review Process Have a process to deal with questions. Route questions to the authoritative source for an answer - don’t answer stuff you can’t/shouldn’t Questions? Resources? More Notes Make sure what is being added is enforceable. This is a legal document and can be used in court. Statements support what is being done today, not what you would like to do or wish the program would do in the future. Go back to those “parking lot” statements that were not added or removed from a draft because you couldn’t enforce them at the time. Can they be added? Don’t lose sight of them if they are important to your security program Does the corporate culture / C levels support statements in the policy? As a security practitioner you may firmly believe that your security program must abide by certain policy statements but the corporate culture or your CEO/CFO even CISO may not support it. They may become “parking lot” items for a future version or you may be able to successfully display that the program can support that statement without affecting the culture. Legal is an important reviewer. It feels nitpicky during the review but Legal knows when “should” and “must” are appropriate. Don’t reinvent the wheel. ISO 27001 is a good framework for your policy. Use it. Don’t try to come up with statements because you think you have to appear to be an Info Sec Policy God. KISS! Don’t write standards and procedures in your policy! We’ve reviewed countless policies that had what we’d consider a standard or “step by step instructions for making firewall changes. That’s a procedure! Keep it out of your policy. /episode/index/show/sfspodcast/id/5345675

Episode 194 - Evaluating Security Product Vendors 04/27/2017

Episode 194 - Evaluating Security Product Vendors Evaluating Security Product Vendors In light of recent news about “Vendors Behaving Badly” we want to talk about how a security professional should evaluate vendors and their products. Recent News: Tanium exposed hospital’s IT while using its network in sales demos: Lawyers, malware, and money: The antivirus market’s nasty fight over Cylance: There are so many different sources of information about vendors and their products. You owe it to yourself to evaluate not just the vendor but also each source of information. Analyst Firms: Gartner/Forrester/etc Always remember they take a very generic view using a notional enterprise as the standard. Current customer interviews are important but, remember, those customer contacts likely came from the vendor. The perception of “Pay for Play” is there no matter how much the firms want to squelch that. These tests presume a lot so make sure you understand what the conditions of the test were. The “Pay for Play” perception exists here too…. The results of the testing aren’t specific but can help show outliers in a group 3rd Party Testing: NSS Labs, etc. Obviously your best and most relevant source of information. :-) Podcasts If you have developed a reliable network of peers you can reach out and ask folks. But, remember, buy them a beer for their troubles… Always remember perspective is everything. Some people just don’t like Company_Z and will always hate their products. Networking Information Sources Start with 3rd party data and demos. This will determine if your requirements (you did write out your requirements, right?) are met by the product Do not allow the vendor to drive the definition of “success” in a PoC Try to break it. I mean REALLY try to break it. Remember during the PoC is going to be the best support and interaction you will ever get. If that sucks you might want to move along. Test *all* of your use cases. (you do have documented use cases, right?) Do a PoC (Proof of Concept). Product Evaluation Rules Service providers such as penetration testers and MSSPs Edge Cases /episode/index/show/sfspodcast/id/5303251