1. Why Evaluate Your Program
   1. Part of annual policy review
   2. If you don’t evaluate you will never improve
   3. Continual review will help protect your budget
2. Start At The Outside and Move Your Way In
   1. Awareness and Education is how most people in your org know the program
   2. Threat Mapping maps the outside threats to your inside controls & tech
   3. Communications is that final turn from the inside out
3. What is “Threat Mapping”?
   1. How is this different from threat modeling?
   2. Threat modeling is listing what could happen to you.
   3. Threat mapping is mapping the holes in your program.
4. How To Get Started
   1. Must have a assessment management program
      1. You can’t protect what you don’t know about
      2. This isn’t “I have a CMDB”. It’s actually taking actions based on what you know about what you have
   2. Understand what your “real” threats are
      1. Map assets to known threats
      2. What are you doing to know this?
         1. industry
         2. entry points
         3. technology
         4. Online threat maps
      3. What controls do you currently have in place to mitigate or reduce the risk?
   3. Scope and prioritize - break down into areas to tackle
      1. Apps
      2. Infrastructure
      3. 3rd parties
      4. etc
5. How To Measure
   1. Scorecard (KRI)
      1. What is important and helpful
   2. Risk Registry
6. How To Improve/Modify
   1. Use your risk registry or GRC tool to track progress and keep management updated. You need them onboard to improve.
   2. Once you have some areas mapped don’t ignore them
   3. Implement solid change control and change management processes
   4. Keep risk scores updated so you aren’t focusing on unimportant things

1. Why Evaluate Your Program
   1. Part of annual policy review
   2. If you don’t evaluate you will never improve
   3. Continual review will help protect your budget
2. Start At The Outside and Move Your Way In
   1. Awareness and Education is how most people in your org know the program
   2. Threat Mapping maps the outside threats to your inside controls & tech
   3. Communications is that final turn from the inside out
3. Measuring Awareness & Education
   1. What do you think you do?
      1. Mandatory CBLs
      2. CyberCyberCyberStuff (Posters, Email, Swag)
      3. Briefings and Classes
      4. Phishing Awareness
      5. $NOVEL_IDEA
   2. How do you measure it?
      1. How many people is it designed to engage?
      2. How many people were actually engaged?
         1. Not how many people took the awareness, how many people were ENGAGED?
      3. How did they do? (CBL completions, % phished, reviews, etc)
      4. Are you being honest with yourself?
         1. If CBL_Completion = 15(clicks) then you may want to rethink that
         2. 0% phished is not a sign of a great security program...more likely a sign of a bad phishing program
         3. If there is no way to allow for anonymous reviews of training/briefings/etc then you’re not likely to get fully honest reviews (Who wants to piss off security?)
4. Adjusting The Program
   1. Don’t change the measurement...change the program
      1. The key to long term success is consistently measuring the same thing over time
      2. You may want to update goals (up or down) but be able to explain why especially if you are making the test easier
   2. Don’t make drastic changes until Year 3 unless you have to make drastic changes
      1. Big changes in delivery will skew the numbers in ways you likely will not like
      2. Constant large turmoil is counter to most corporate cultures
      3. Small changes take advantage of previous investments best
      4. “Iterate small and grow larger” - doing too much too fast almost always ends is highly suboptimal results over time
   3. Clearly failing components should be axed and replaced and not tweaked around the edges - especially if there’s a compliance or safety aspect
5. If this feels like “Wash, Rinse, Repeat” it’s because is it “Wash, Rinse, Repeat”

We're going to use this episode to allow the cast to talk about reaching 200 episodes and you'll hear what really happened on the Lost Episode.

We will be back in 2018 with more episodes. Until then be well and stay secure!

Episode 200 - Building A Security Strategy - Part III

1. Recap
   1. Strategy vs Policy
2. The Question is “How do I make one?”
   1. Understand the business of your Business
   2. Know who your stakeholders really are
   3. Capability = (Tech + Service) * Process
   4. Crawl, Walk, Run
   5. It Takes A Village
3. Capability = (Tech + Service) * Process
   1. Tech
      1. Tech, by itself, only consumes electricity and turns cool air into warm air
      2. So many choices….
      3. The tech selection is the least critical one for developing a capability
      4. http://www.southernfriedsecurity.com/episode-192-security-waste/
   2. Service
      1. This is the “Stuff You Have To Do”
      2. Usually determined by regulation, policy, or corporate edict
      3. Describes a desired outcome - not how to get there
      4. Examples include “Malware Detection”, “Email Security”
   3. Process
      1. How you do the crazy things you do
      2. Security is not a One-Off - things must be repeatable and consistent
   4. Capability
      1. Describes value team brings to org
      2. While tech and service selection is important the biggest improvement usually comes from better process
4. Crawl, Walk, Run
   1. Armorguy’s Maxim of Life: “Start small and iterate larger”
   2. Try to do to much out of the gate and you WILL fail
   3. Define success criteria for each stage that allows for error and learning
5. It Takes A Village
   1. Security cannot exist as an island
   2. Interdependence with business units is key - if you don’t you are the foreigner and will be rejected
   3. The relationship with IT Operations is going to be wonky at first
6. Strategy - It’s What CISOs Do…
   1. Where do you look for more info?

Episode 199 - Building A Security Strategy - Part II

1. Recap
   1. Strategy vs Policy
   2. Understand the business of your Business
   3. Know who your stakeholders really are
   4. Capability = (Tech + Service) * Process
   5. Crawl, Walk, Run
   6. It Takes A Village
2. The Question is “How do I make one?”
   1. Almost no business is in the business of information security
   2. Follow The Money
   3. Understand The Decisioning Process
   4. “Culture Eats Strategy For Breakfast”
   5. Vocabulary Matters
3. Understand the Business of Your Business
   1. Know the Formal and Informal Org Charts
   2. Influencers are as important as Deciders
   3. Beware the Spoiler
   4. “Culture Eats Strategy For Breakfast”
   5. Don’t Give a Vote or Veto Unnecessarily
4. Know Who Your Stakeholders Really Are
   1. We will keep discussing this.
   2. Underestimating the power of culture WILL result in your plan faling
   3. That’s a majority of the reason that Strategy Is Hard
5. Culture Is The Key

Strategy is the hardest thing a CISO will do in their career...except if they have to explain a massive breach…

1. What is a Strategy?
   1. What's the difference between a strategy and a policy?
   1. A policy is binding statements
   2. A strategy is thought out planning

2. What a strategy isn't…
  1. A list of tech you want to buy
  2. A remediation plan that follows an audit/assessment
  3. A continued justification for the way you've always done things
  4. The stuff your favorite vendor told you needs doing
3. A strategy is…
  1. Based on the needs and desires of the org and its senior leaders
  2. Culturally relevant
  3. A guide to where investment (money and people) need to be made
  4. Balanced between boldness and reassurance
  5. Built on a set of capabilities that map to business success criteria

2. Why do you want one?
   1. Creates a consistent frame of reference for talking about the program
   2. Helps senior leaders understand the where/why of the investments
   3. Lays out a connected story for CFOrg to make budget less hard
   4. Provides a decision-making framework that enables effective choices
3. How do I make one?
   1. Understand the business of your Business
   2. Know who your stakeholders really are
   3. Capability = (Tech + Service) * Process
   4. Crawl, Walk, Run
   5. It Takes A Village

In our next episodes we'll break down each of the steps and talk more about strategy…

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.

Wannacry: Woulda, Coulda, Shoulda

First and foremost: Why was medical hit so hard by WannaCry? See Episode 189 - Medical Device Security and Risky Business 455 - https://risky.biz/RB455/

1. The Lead-Up

   1. Threat Intelligence is A Thing
   2. Threat Intelligence is Hard
   3. Threat Intelligence Feeds are [REDACTED] for many/most
   4. Do
      1. Stay Calm
         1. You have finite human resources
         2. You have finite time
      2. Prioritize Your Responses
         1. Episode 192 - Security Waste
      3. Know what all your tools can do and be ready to use them
         1. Your Business Continuity Program can inform that
         2. You do have a BCP, right?
      4. Know what area to focus on first
      5. Be willing to cut off an arm to save the body
      6. When you can remember that Herd Immunity is a Thing.
   5. Don’t…
      1. Scare the Children
      2. Waffle in decision making
         1. This is not the time to point out for the millionth time that your patching program is suboptimal
         2. This is not the time to point out that if you’d only gotten that BlinkyBox last capital season this wouldn’t be an issue
      3. Focus on what you can’t do
      4. Overpromise

2. When the Crisis Arrives

   1. Be sure you’re in Aftermath and not still in Crisis
   2. Do a Hot Wash and a full After Action Review/Post-Mortem
   3. Document your lessons learned and distribute them widely
   4. Follow Up, Follow Up, FOLLOW UP!!
      3 The Aftermath

1. Define policy vs. standards vs. procedures
   1. 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.
      1. Example: Policy statement = Users must authenticate with a unique ID and password
      2. 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.
   2. What is a Standard? Standards support the policy, make it more meaningful and effective.
   3. 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.
   4. Every policy guide everywhere says you need to review your policies regularly which almost always means annually.
   5. Failure to do the annual review can get you in hot water with your regulator and/or auditor.
   6. It just Makes Sense.
2. Why review your policies?
   1. It’s the one time a year you can nudge the organization where it needs to go
      1. Past Problems
      2. Current Issues
      3. Future Challenges
   2. Killing off/modifying policies that get in the way of people doing work will Make Friends And Influence People
   3. There is no better way to ensure your team is working on what needs to be worked on than aligning with stated policy.
3. Making Sense of Policy Review
   1. Alert The Approvers
   2. Line Them Up
   3. Divide and Conquer
   4. Bring The Business Into The Process
      1. Internal Audit
      2. Legal
      3. Risk
      4. Corporate Security
      5. IT
      6. Marketing / Public Relations
   5. As Needed Bring In
   6. Change Crosswalks FTW
   7. Communicate, Communicate, Communicate.
4. The Review Process
   1. 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
5. Questions?
6. 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.

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: https://arstechnica.com/security/2017/04/security-vendor-uses-hospitals-network-for-unauthorized-sales-demos/

Lawyers, malware, and money: The antivirus market’s nasty fight over Cylance: https://arstechnica.com/information-technology/2017/04/the-mystery-of-the-malware-that-wasnt/

1. 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.
   1. Analyst Firms: Gartner/Forrester/etc
      1. Always remember they take a very generic view using a notional enterprise as the standard.
      2. Current customer interviews are important but, remember, those customer contacts likely came from the vendor.
      3. The perception of “Pay for Play” is there no matter how much the firms want to squelch that.
      4. These tests presume a lot so make sure you understand what the conditions of the test were.
      5. The “Pay for Play” perception exists here too….
      6. The results of the testing aren’t specific but can help show outliers in a group
   2. 3rd Party Testing: NSS Labs, etc.
      1. Obviously your best and most relevant source of information. :-)
   3. Podcasts
      1. 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…
      2. Always remember perspective is everything. Some people just don’t like Company_Z and will always hate their products.
   4. Networking
2. Information Sources
   1. 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
      1. Do not allow the vendor to drive the definition of “success” in a PoC
      2. Try to break it. I mean REALLY try to break it.
      3. 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.
      4. Test all of your use cases. (you do have documented use cases, right?)
   2. Do a PoC (Proof of Concept).
3. Product Evaluation Rules
   1. Service providers such as penetration testers and MSSPs
4. Edge Cases

http://sfspodcast.libsyn.com/episode-193-chief-information-security-oh-crap

Tonight's episode is all about those learning moments.

CISOs and security orgs find new and interesting way to screw up all the time. Leaving that Any-Any rule in place on the new firewall… Disabling the CEOs account by accident… Not realizing that Shadow IT had just installed a new egress point…

Here are our stories. The name have been changed to protect the culpable.

It's not just a security problem but we often add to our arsenal without fully (or even mostly) utilizing the tools that we do have.

Problems associated with this are:

• Have more complexity in your environment

• Needing more staff or requiring current staff to stretch themselves thin to support differing tools

• Increased cost (capital, operational, support)

• Information overload - even with a SIEM more data requires more analysis

  • Increased chance of missing key events
  • Increased false positives

• What am I missing?

How do we work through this when you're not the decision maker?

• "Operational Excellence" - Martin's story

How do we work with our vendors to ensure that we are leveraging their tools without over dependence on one tool or vendor?

Advantages of security debt

• All eggs not in one basket
• Ability to leverage different technology sets to catch more bad stuff
• In a larger environment what works in one area of the network may not work well in another
• Necessity of increased staff that has experience in other areas that can be leveraged by team

SFS Podcast Episode: 189

Medical Device Security

1. Intro

2. Medical Devices are a broad category

   1. Hospital devices (infusion pumps, CT, MRI, etc)

   2. Personal devices (pacemaker, insulin pumps, etc)

3. This has some of the same threat landscape as the IoVCT, but the consequences can be much more serious.

   3. Discussion of Sentinel Events...

4. Challenges to Fixing The Problem:

   4. Lead times for device approval

   5. Fixed configurations / FDA compliance

   6. Working life of devices

   7. "Well just replace them all!" Cost of devices (esp for small/struggling hospitals)

   8. Sheer number of devices can be overwhelming when looking to upgrade/replace

   9. Vendors that bring in things for a trial w/o involvement of IT/IS

5. How Can it Get Better

   10. Vuln Disclosure

       1. Muddy Waters / St Jude

          1. Problem there wasn’t disclosure it was the look of the profit motive

          2. August 25, 2016 > http://www.muddywatersresearch.com/research/stj/mw-is-short-stj/

          3. SJM sued in early September >> http://www.wsj.com/articles/st-jude-medical-sues-short-seller-over-device-allegations-1473258343

          4. http://www.marketwatch.com/story/short-seller-muddy-waters-renews-claims-of-st-jude-medical-cyber-vulnerabilities-2016-10-19

          5. Goes beyond Vulnerability Disclosure and Muddy Waters claims SJM is attacking their First Amendment - Right to Free Speech - rights >> https://www.bloomberg.com/news/articles/2016-10-24/muddy-waters-fights-st-jude-lawsuit-over-pacemaker-reports

          6. Muddy Waters report from Bishop Fox >> http://www.reuters.com/article/us-st-jude-medical-cyber-muddywaters-idUSKCN12O1O1

       2. Bug Bounties

          7. http://www.csmonitor.com/World/Passcode/2016/0210/FDA-presses-medical-device-makers-to-OK-good-faith-hacking

   11. FDA Task Force - http://www.fda.gov/NewsEvents/Newsroom/PressAnnouncements/ucm481968.htm

   12. Other groups

       3. I Am The Cavalry - https://iamthecavalry.org/oath

       4. Other interest groups

          8. HIMSS Cyber Security Community - http://www.himss.org/get-involved/community/cybersecurity

          9. Archimedes Center for Medical Device Security - https://secure-medicine.blogspot.com

          10. NH-ISAC - http://www.nhisac.org/

          11. MDISS - http://www.mdiss.org

6. What’s the Future?

   13. Sometime, somewhere, somehow something bad is going to happen and somebody is going to die.

   14. There will need to be more market pressure - http://thehill.com/blogs/congress-blog/technology/278712-a-new-narrative-on-cyber-security

   15. What will regulators do? (eg DLink and the FTC)

7. Outro & Credits

Andy and Martin close out 2016 with a quick run through of the major stories of the year and look forward to what's to come in 2017.

Thanks to everyone who came to BSides Atlanta!

Martin, Steve, and Yvette discuss the recent DDoS of the DNS provider Dyn and what information security people should be considering in a world where terabit DDoS is a reality.