UNSECURITY Episode 132 Show Notes

Hey Listeners!

Spring is in full bloom (finally) in Minnesota, and life is good. The weather is great, and last week, our Governor (Tim Walz) lifted the mask mandate for people who are vaccinated and maintain some semblance of social distancing. It’s good to see people’s faces again, especially when they’re smiling. 🙂

We’re grateful for the guests who have joined our show the past four weeks! We’ve learned a ton from these conversations.

If you missed any of these shows, you can find them here:

NOTE: We’re looking for people from other walks of life to share their perspectives too, especially men and women of color. Let us know at unsecurity@protonmail.com if you have suggestions.

This week, we’re not planning to have a guest, so you’ll have to put up with Brad and I.

Next week (episode 133) we’re hoping to have Gabriel Friedlander from Wizer on the show!

Let’s get to the episode 132 show notes, shall we?


SHOW NOTES – Episode 132 – Tuesday May 18th, 2021

Opening

[Evan] Welcome listeners! Thanks for tuning into this episode of the UNSECURITY Podcast. This is episode 132, and the date is May 18th, 2021. Joining me is my good friend, highly-skilled information security expert, and all around great guy, Brad Nigh.

Good morning Brad!

There are so many things happening in our world, it’s hard to keep track. One interesting event from the last week (other than the Colonial Pipeline attack) was the announcement of President Biden’s Executive Order (EO) 14028 titled “Improving the Nation’s Cybersecurity”. In today’s episode, Brad and I are going to break this down.

Improving the Nation’s Cybersecurity

  • The EO was announced by the Administration on 5/12/21.
  • There’s a lot of information to unpack here, including:
  • Section 1. Policy, containing:
    • Policy statement.
    • Scope.
  • Section 2. Removing Barriers to Sharing Threat Information, containing:
    • Review existing reporting requirements and procedures.
    • Recommend updates to the Federal Acquisition Regulation (FAR).
    • Update the FAR.
    • Enforce IT/OT provider compliance.
    • Centralize reporting.
    • Provide budget for this section.
  • Section 3. Modernizing Federal Government Cybersecurity
    • Adopt security best practices.
    • Advance toward Zero Trust Architecture.
    • Accelerate movement to secure cloud services.
    • Adopt multi-factor authentication.
    • Encrypt data at rest and in transit.
    • Centralize and streamline access to cybersecurity data.
    • Invest in both technology and personnel to match the modernization goals.
  • Section 4. Enhancing Software Supply Chain Security
    • Develop standards, tools, and best practices for secure software development.
    • Enforce secure software development practices.
    • Define and enforce a “Software Bill of Materials (SBOM)”.
    • Define “critical software” and its protection requirements.
    • Consumer labeling programs for IoT and software.
  • Section 5. Establishing a Cyber Safety Review Board
    • Requirements for a new “Cyber Safety Review Board”.
    • All requirements are for the Secretary of Homeland Security and the (yet to be established) Cyber Safety Review Board (“board”).
  • Section 6. Standardizing the Federal Government’s Playbook for Responding to Cybersecurity Vulnerabilities and Incidents; the playbook:
    • Will Incorporate all appropriate NIST standards.
    • Be used by all Federal Civilian Executive Branch (FCEB) Agencies.
    • Will articulate progress and completion through all phases of an incident response.
    • Will allow flexibility so it may be used in support of various response activities.
    • Establishes a requirement that the Director of CISA reviews and validates FCEB Agencies’ incident response and remediation results upon an agency’s completion of its incident response.
    • Defines key terms and use such terms consistently with any statutory definitions.
  • Section 7. Improving Detection of Cybersecurity Vulnerabilities and Incidents on Federal Government Networks
    • The adoption of a Federal Government-wide Endpoint Detection and Response (EDR) initiative.
    • CISA threat hunting on FCEB networks and systems without agency authorization.
    • Information sharing between the Department of Defense and the Department of Homeland Security
  • Section 8. Improving the Federal Government’s Investigative and Remediation Capabilities
    • Types of logs to be maintained.
    • Time periods to retain the logs and other relevant data.
    • Time periods for agencies to enable recommended logging and security requirements.
    • How to protect logs (logs shall be protected by cryptographic methods to ensure integrity once collected and periodically verified against the hashes throughout their retention)
    • Data shall be retained in a manner consistent with all applicable privacy laws and regulations.
    • Ensure that, upon request, agencies provide logs to the Secretary of Homeland Security through the Director of CISA and to the FBI, consistent with applicable law.
    • Permit agencies to share log information, as needed and appropriate, with other Federal agencies for cyber risks or incidents.
  • Section 9. National Security Systems
  • Section 10. Definitions
  • Section 11. General Provisions

This will be a great conversation as Brad and I share our summary, thoughts and opinions on all this!

News

Just time for one news story this week. This one is from Brian Krebs, “Try This One Weird Trick Russian Hackers Hate“.

Wrapping Up – Shout Outs

Who’s getting shout outs this week?

Thank you to all our listeners! Thank you Brad for a great conversation! If you have something you’d like to tell us, feel free to email the show at unsecurity@protonmail.com. If you’re the social type, socialize with us on Twitter, I’m @evanfrancen, and Brad’s @BradNigh.

Other Twitter handles where you can find some of the stuff we do, UNSECURITY is @unsecurityP, SecurityStudio is @studiosecurity, and FRSecure is @FRSecure.

That’s it. Talk to you all again next week!

…and we’re done.

UNSECURITY Episode 131 Show Notes

Apologies for not posting something about last week’s show, episode 130. We were honored and pleased to welcome John Strand from Black Hills Information Security as our guest. John, Brad and talked openly about John’s path through information security, what Black Hills is working on, the different pockets of security people, why it’s important to work together as information security vendors to improve the community, and John’s latest Pay What You Can (PWYC) Series.

It was a GREAT talk and we’re VERY grateful that John stopped by. Check out episode 130 here; https://podcasts.apple.com/us/podcast/unsecurity-episode-130-john-strand-black-hills-information/id1442520920?i=1000520139261

Episode 131

Pumped about this week’s show!

My good friend, Security Shit Show co-host, hacker extraordinaire, and all around great guy Chris Roberts is stopping in for a chat.

Special Guest – Chris Roberts

Chris and I (Evan) were introduced to each other by our mutual friend Tony Cole maybe three years ago, but we didn’t get to know each other well until the last 13, 14 months. We’re both REALLY busy guys, so our circles just didn’t cross much. In the past year, we’ve gotten to know each other quite well which is no surprise seeing that we spend more than two hours together each week on the Security Shit Show with Ryan Cloutier (another great guy).

Things about Chris:

From his LinkedIn Profile:

  • Currently the Chief Security Strategist for Cynet Security (among many other things)
  • Currently an Executive Committee Member at the CyberEdBoard Community
  • Currently an Advisor, Researcher, Hacker, Etc. at HillBilly Hit Squad
  • Currently co-host of The Security Shit Show
  • Former Chief Security Strategist at Attivo Networks, Inc.
  • Former Chief of Adversarial Research and Engineering at LARES Consulting
  • Former Chief Security Architect at Acalvio Technologies
  • Former Senior Consultant at Sentinel Global LLC
  • Founder of One World Labs
  • Former Managing Director Electronic Intelligence/Principal Investigator at Cyopsis, LLC
  • Former President/CEO at CCi5, Inc.
  • Former Director of Coalfire Labs at Coalfire Systems, Inc.
  • and on and on…

Chris has been all over the world and all over the United States doing crazy cool hacker stuff at every stop.

He is truly on of my favorite people on the planet to talk to! Always a good time.

Other Guests – Past, Present, and Future

Lots of GREAT conversations with lots of GREAT information security folks!


SHOW NOTES – Episode 131 – Tuesday May 11th, 2021

Opening

[Evan] Welcome listeners! Thanks for tuning into this episode of the UNSECURITY Podcast. This is episode 131, and the date is May 11th, 2021. Joining me is my good friend, infosec buddy and partner in crime.

Also joining the UNSECURITY Podcast is our special guest, Mr. Chris Roberts! Welcome my friend. It’s an honor to have you on our show!

Introducing Chris Roberts

  • Let’s start with trying to figure out how Chris first got into the information security industry.
  • Next, we’ll see how far we can get down his career path before 1) we start chasing squirrels (we’re both ADD) or 2) we run out of time (because there’s A LOT there).
  • The Colonial Pipeline Attack and global security tensions/consequences.
  • Current projects.
  • Current events.

We’ll see if we get to his plane hacking antics too, but I’m not sure we’ll have the time.

News

We’ll probably skip news in this show. Guessing that Brad, Ron, and myself will have no problem filling the entire show with good discussion.

Wrapping Up – Shout Outs

Who’s getting shout outs this week?

Thank you to all our listeners! HUGE thank you to Chris for joining us. If you have something you’d like to tell us, feel free to email the show at unsecurity@protonmail.com. If you’re the social type, socialize with us on Twitter, I’m @evanfrancen, and Brad’s @BradNigh.

Chris is easy to find, but can be reached on LinkedIn and Twitter (@Sidragon1).

Other Twitter handles where you can find some of the stuff we do, UNSECURITY is @unsecurityP, SecurityStudio is @studiosecurity, and FRSecure is @FRSecure.

That’s it. Talk to you all again next week!

…and we’re done.

Operationally Cumbersome?

The leading cause of death in the workplace is falls. 36.5% of all fatalities are due to falls, followed by 10.1% caused by being struck with an object. Recognizing the problem, OSHA created requirements to protect workers from falls, including:

  • guardrail systems
  • safety net systems
  • personal fall arrest systems
  • covers
  • positioning device systems
  • fences
  • barricades
  • controlled access zones

All these controls, when used properly, save lives.

Hypothetical Scenario

A successful construction company is working on a 30-story office building. Timelines were already tight, but a series of material delivery delays has put them way behind schedule. In a rush to complete the project, it’s easy overlook certain things. In this case, a properly configured personal fall arrest system was overlooked. They bought the system, the system was onsite, but the system wasn’t installed correctly. Nobody noticed until one day a worker, twenty stories up, slipped and fell to his death.

As you can imagine, there was a serious investigation. In the end, the company admitted their oversight, received a fine, settled a lawsuit with the worker’s family, and continued operations.

A few weeks later, same thing happens. Another investigation, another slap on the wrist, another settled lawsuit, and back to business as usual.

A few months go by, and there’s another incident! The investigation cited the same cause as the others, a poorly configured/installed personal fall arrest system. This time, OSHA wants a public hearing and invites company representatives to answer questions before their panel. At the hearing, company representatives were asked the following question:

If a properly deployed personal fall arrest system had been used, would these lives have been saved?

A company representative responds:

It depends. In theory, it’s a sound thing, but it’s academic. In practice it is operationally cumbersome.

Seems reasonable, right?. We certainly don’t want to get in the way of company production!

Or, wait a second. This doesn’t seem right. Poor safety because good safety is “operationally cumbersome” doesn’t sit well with you. Good, it shouldn’t!

Sadly, a similar analogy plays out all over the information security industry every day.

Hearing on the Hack of U.S. Networks by a Foreign Adversary

The construction analogy hit home while watching recent testimony in front of the U.S. Select Committee on Intelligence.

On February 23rd, 2021, Kevin Mandia (FireEye CEO), Sudhakar Ramakrishna (SolarWinds CEO), Brad Smith (Microsoft President), and George Kurtz (CrowdStrike President and CEO) were invited to give their testimony about the attacks on SolarWinds Orion last year (and ongoing). These are four very powerful men in our industry, and I appreciate what they’ve accomplished. In general, I have a great amount of respect for these men, but I’m not comfortable in their representation of our industry without also considering (many) others. Some of the reasons I’m not comfortable, include these facts:

  • They run billion and multi-billion dollar companies that sell products and services to protect things.
    • If people were already protected, they’d have nothing to sell. There is incentive to keep people insecure.
    • Companies must continue to produce new products (See: product life cycle diagram below). Without new products, sales decline. As long as people keep buying (regardless of need), they’ll keep making.

  • They have significant personal financial interests in the performance (sales, profit, etc.) of their companies.
  • They represent shareholders who have significant financial interests in the performance of their companies.
  • They may lack clear perspective of what most Americans and American companies are struggling with due to where they sit.

A hearing such as this is a fantastic opportunity for people to tout their accomplishments (which they do), tout their companies accomplishments (which they do),  and sell more stuff as a result. I DO NOT fault the witnesses for doing these things. It’s their job!

Let’s just hope our Senators take the hearing and witnesses in proper context and seek many more perspectives before attempting to draft new policy.

IMPORTANT NOTE: It may appear in this article that I’m critical of the people in this Senate hearing, but this is NOT the point. The people participating in the hearing have done tremendous things for our industry and our country. For all we know, if we were in one of their seats, we would respond in much the same way they did. If anything, I’m critical of us, our industry. We have tools sitting right under our noses that we don’t use correctly. Instead of learning to use our tools correctly, and actually using our tools correctly, we go looking for more tools. This is ILLOGICAL, and might should be negligent.

The point.

At one point during the hearing (1:22:08, if you’re watching the video), Senator Wyden (D-OR) begins a logical and enlightening line of questioning.

Senator Wyden:

The impression that the American people might get from this hearing is that the hackers are such formidable adversaries that there was nothing that the American government or our biggest tech companies could have done to protect themselves. My view is that message leads to privacy violating laws and billions of more taxpayer funds for cybersecurity. Now it might be embarrassing, but the first order of business has to be identifying where well-know cybersecurity measures could have mitigated the damage caused by the breach. For example, there are concrete ways for the government to improve its ability to identify hackers without resorting to warrantless monitoring of the domestic internet. So, my first question is about properly configured firewalls. Now the initial malware in SolarWinds Orion software was basically harmless. It was only after that malware called home that the hackers took control, and this is consistent with what the Internal Revenue Service told me. Which is while the IRS installed Orion, their server was not connected to the Internet, and so the malware couldn’t communicate with the hackers. So, this raises the question of why other agencies didn’t take steps to stop the malware from calling home. So, my question will be for Mr. Ramakrishna, and I indicated to your folks I was going to ask this. You stated that the back door only worked if Orion had access to the internet, which was not required for Orion to operate. In your view, shouldn’t government agencies using Orion have installed it on servers that were either completely disconnected from the internet, or were behind firewalls that blocked access to the outside world?”

To which Mr. Ramakrishna (SolarWinds) responds:

Thanks for the question Senator Wyden. It is true that the Orion platform software does not need connectivity to the internet for it to perform its regular duties, which could be network monitoring, system monitoring, application monitoring on premises of our customers.”

Key points:

  1. SolarWinds Orion did not require Internet connectivity to function.
  2. The IRS had Orion.
  3. The IRS did not permit Orion to communicate with the Internet.
  4. Attackers were not able to control the IRS Orion server (because it couldn’t communicate home).
  5. The attack against the IRS was mitigated.

Senator Wyden continues:

Yeah, it just seems to me what I’m asking about is network security 101, and any responsible organization wouldn’t allow software with this level of access to internal systems to connect to the outside world, and you basically said almost the same thing. My question then, for all of you is, the idea that organizations should use firewalls to control what parts of their networks are connected to the outside world is not exactly brand new. NSA recommends that organizations only allow traffic that is required for operational tasks, all other traffic ought to be denied. And NIST, the standards and technology group recommends that firewall policies should be based on blocking all inbound and outbound traffic with exceptions made for desired traffic. So, I would like to go down the row and ask each one of you for a “yes” or “no” answer whether you agree with the firewall advice that would really offer a measure of protection from the NSA and NIST. Just yes or no, and ah, if I don’t have my glasses on maybe I can’t see all the name tags, but let’s just go down the row.”

Points made by Senator Wyden:

  1. Network security 101 includes blocking high-risk applications from connecting to the Internet when it’s not specifically required for functionality.
  2. Firewalls are designed to block unwanted and unnecessary network traffic.
  3. There is good authoritative guidance for using firewalls properly, including from the NSA and NIST.
  4. None of this is new.
  5. Organizations that don’t follow “network security 101” are irresponsible.

Kevin Mandia responds first:

And I’m gonna give you the “it depends”. The bottom line is this, we do over 6oo red teams a year, firewalls have never stopped one of them. A firewall is like having a gate guard outside a New York City apartment building, and they can recognize if you live there or not, and some attackers are perfectly disguised as someone who lives in the building and walks right by the gate guard. It’s ah, in theory, it’s a sound thing, but it’s academic. In practice it is operationally cumbersome.

OK, here the logic falls apart. The answer “it depends”, followed by “firewalls never stopped” a FireEye red team exercise, did NOT answer Senator Wyden’s question. Logically, this (non) answer would only be valid if (at a minimum):

  • The FireEye red team exercises were run against a “network security 101” firewall configuration.
  • The FireEye red team exercises were a variant or emulation of the SolarWinds attack.

The question was whether a “network security 101” (or a properly configured) firewall would have mitigated the SolarWinds attack (meaning a firewall configured to only permit necessary traffic, as per NSA and NIST guidance). The non-answer justification continues by mentioning “in theory, it’s a sound thing, but it’s academic”. Since it’s been brought up, this IS NOT theoretical, it’s factual. If an attacker cannot communicate with a system (either directly or by proxy), the attacker cannot attack or control the system.

The last part of this statement brings us (finally) to our original point. Using a firewall, the way it’s supposed to be used (“network security 101”) is “operationally cumbersome”.

Responses from the others:

  • Mr. RamakrishnaSo my answer Senator is “yes”. Do standards such as NIST 800-53 and others that define specific guidelines and rules. (THE BEST ANSWER)
  • Mr. SmithI’m squarely in the “it depends” camp. (Um, OK. So, a non-answer.)
  • Mr. KurtzYes, and I would say firewalls help, but are insufficient, and as Kevin said, and I would agree with him. There isn’t a breach that we’ve investigated that the company didn’t have a firewall or even legacy antivirus. So, when you look at the capabilities of a firewall, they’re needed, but certainly they’re not be all end goal, and generally they’re a speed bump on the information super highway for the bad guys. (Basically the same statement as the first. DID NOT answer the question.).

So the score is 3 to 1, “it depends” (without answering the question) versus “yes” (the correct answer).

Operationally Cumbersome

If a firewall (or any tool) is effective in preventing harm when it’s used correctly, why aren’t we using it correctly? The reason “because it’s operationally cumbersome” is NOT a valid argument.

It’s like saying “I don’t do things correctly because it’s hard” or “I don’t have time to do things right, so I don’t” or (as in our construction example) “We don’t have time to use a personal fall arrest system correctly, so people die”? Truth is, our infrastructures are so interconnected today, a failure to configure a firewall properly could/will eventually result in someone’s death.

So what do we do today? We do the illogical:

  • Since we don’t have time (or skill or operational bandwidth or whatever) to use an effective tool effectively, we purchase another tool.
  • We won’t have the time (or skill or operational bandwidth or whatever) to use this new tool effectively either, so we purchase another tool.
  • We won’t have time (or skill or operational bandwidth or whatever) to use the new tool and this newer tool effectively, so we purchase yet another tool.
  • The insanity continues…

What we must do (sooner or later):

  • inventory the tools we already have
  • learn how to use the tools we already have properly (knowledge/skill)
  • use the tools we already have properly (in practice)
  • then (and ONLY then) seek additional (or different) tools to address the remaining gaps

As an industry, we must (sooner or later):

  • make this “network security 101” (it’s not new, so we can’t call it the “new network security 101”)
  • hold organizations responsible for “network security 101” (the opposite being, the “new irresponsible” or negligent)

Other facts

Firewalls are NOT the end all, but they are an important part of security strategy. Here we are, many years down the road and we’re still fighting the same fight: the basics.

  • Firewalls have been around for more than 35 years.
  • Firewalls block unwanted and unnecessary network traffic (inbound/ingress and outbound/egress).
  • A properly configured, “network security 101”, “responsible”, “best practice” implementation of a firewall would have mitigated the SolarWinds (or similar) attack.
  • Many (maybe most) U.S. organizations have a firewall that is capable to mitigating the SolarWinds (or similar) attack.
  • There are still ways to bypass a firewall, but if you don’t have your firewall configured properly, what are the chances you’d stop a bypass anyway?
    • application vulnerabilities
    • SQL injection
    • social engineering
    • physical access
    • man-in-the-middle

Operationally cumbersome is not a valid excuse for our failures to understand and follow the basics.