Speaker 1: I have to admit, when I first think about computer security,
Speaker 1: my brain is definitely still stuck in the movies. You
Speaker 1: know the exact scene.
Speaker 2: I mean, a guy in a dark room wearing a hoodie.
Speaker 1: Yes, exactly, the hoodie, and there's green tech scrolling impossibly
Speaker 1: fast across the monitors, and he's furiously typing to beat
Speaker 1: some giant red progress bar.
Speaker 2: Right, and it's always over in thirty seconds.
Speaker 1: It's high stakes, it's traumatic. But after going through our
Speaker 1: sources for this deep dive into computer security principles and practice,
Speaker 1: the reality feels weirdly different.
Speaker 2: It is entirely different. In the real world. The biggest
Speaker 2: threat to your data often isn't some master criminal typing
Speaker 2: at light speed. Yeah, Sometimes it's literally just the humidity
Speaker 2: level in your server.
Speaker 1: Room, or as we found out, something is boring as
Speaker 1: a semiquon.
Speaker 2: Oh yeah, a well placed semicolon can bring down an
Speaker 2: empire exactly.
Speaker 1: So today we are doing a comprehensive walkthrough of the
Speaker 1: invisible war happening inside our machines. Our primary source is
Speaker 1: Stallings and Browns, fifth edition, and the mission today is
Speaker 1: to peel back all the layers of security.
Speaker 2: From the math of encryption all the way to the
Speaker 2: physical temperature where a hard drive just melts into slag.
Speaker 1: But before we get into the melting metal, we need
Speaker 1: to set the stage because the reading makes this huge
Speaker 1: distinction right off the bat, which is that security isn't
Speaker 1: a product, right.
Speaker 2: You can't just go to the store and say I'll
Speaker 2: take one security please. It is a process. It's a
Speaker 2: constant balancing act.
Speaker 1: And they call it the CIA triad, right.
Speaker 2: Yeah, Confidentiality, integrity, and availability. You are constantly trying to
Speaker 2: keep data secret, keep it accurate, and make sure people
Speaker 2: can actually get to it when they need it. It's
Speaker 2: a tug of war.
Speaker 1: And usually for you listening, the first geek keeper for
Speaker 1: that confidentiality piece is your password. Now, I consider myself
Speaker 1: a relatively smart person, but I read this study in
Speaker 1: the notes about one hundred and thirty permutations, and I
Speaker 1: realized I have been doing it wrong for my entire life, you.
Speaker 2: And everyone else. Honestly, that study is a classic because
Speaker 2: it exposes just how predictable human beings are. Attackers know,
Speaker 2: you aren't going to pick a random string of characters.
Speaker 1: Right, I'm going to pick my name, or my kid's name,
Speaker 1: or my company's name. And then I'll add a number
Speaker 1: at the end or capitalize the first letter and think, Wow,
Speaker 1: I am a security genius.
Speaker 2: And that right there is what the one hundred and
Speaker 2: thirty permutations are. Attackers take your name and they run
Speaker 2: it through a script that automatically tries the wonder and
Speaker 2: thirty most common.
Speaker 1: Variations backwards, all caps toggled, case appended dates.
Speaker 2: Yep, they aren't guessing. They are running a highly efficient checklist.
Speaker 1: So if I think I'm being clever by writing the
Speaker 1: word password backwards, the computer has already guessed that in
Speaker 1: a millisecond.
Speaker 2: Before you even take your finger off the enerkey. But
Speaker 2: it actually gets much more difficult for you. When we
Speaker 2: talk about rainbow tables. This is where the attackers stop
Speaker 2: guessing and start doing math, or rather they stop doing math.
Speaker 1: Okay, wait, walk me through this, because the phrase trading
Speaker 1: space for time kept coming up in the reading, and
Speaker 1: I want to make sure we get this right.
Speaker 2: Sure, So when a system it saves your password, it
Speaker 2: doesn't just save the word apple. It runs Apple through
Speaker 2: a mathematical formula called a hash function and saves a
Speaker 2: scrambled string of nonsense characters.
Speaker 1: Right, so when you log in, it scrambles your input
Speaker 1: and compares the two strings to see if they match exactly.
Speaker 2: So normally the hacker has to guess the word, scramble
Speaker 2: it and see if it matches. That takes processing power,
Speaker 2: that takes time.
Speaker 1: But with a rainbow table, they cheat.
Speaker 2: Majorly cheat. They pre calculate the scrambled strings for millions
Speaker 2: and millions of possible passwords before they ever attack you.
Speaker 2: They store those results in a massive table, and that
Speaker 2: is the space part of the equation I see.
Speaker 1: So when they steal the password file, they aren't actually
Speaker 1: trying to crack it at all. They were just looking
Speaker 1: it up in a dictionary they already wrote.
Speaker 2: Precisely, they traded the time it takes to do the
Speaker 2: math for the storage space on their hard drive. One
Speaker 2: source mentioned a table that was one point four gigabytes,
Speaker 2: which isn't even that big, not by modern standards. No,
Speaker 2: but that one point four gigs contained enough pre computed
Speaker 2: hashes to crack ninety nine point nine percent of standard
Speaker 2: alphin Americ Windows passwords in seconds.
Speaker 1: That really puts relying on a password like one, two, three, four,
Speaker 1: five six into terrifying perspective. So, since the machines are
Speaker 1: clearly smarter and faster than us. What is the actual
Speaker 1: actionable defense here? The source was pretty specific about passphrases.
Speaker 2: Yeah, length is the key. The math gets exponentially harder
Speaker 2: the longer the password is. The recommendation is to take
Speaker 2: a sentence that actually means something to you and just
Speaker 2: use the first letter of each word.
Speaker 1: The example in the text was my dog's first name
Speaker 1: is Rex.
Speaker 2: Right, so you just type mdfni hika to a computer
Speaker 2: that looks like total gibberish. It doesn't appear in a dictionary,
Speaker 2: it definitely doesn't appear in a rainbow table.
Speaker 1: But for you, it's literally just a sentence about your dog.
Speaker 1: You don't have to memorize a random string exactly.
Speaker 2: It's simple but highly effective. But even the best password
Speaker 2: is still just what you know, and if you know it,
Speaker 2: someone can beat it out of you or spearfish it
Speaker 2: out of you, which is why we're seeing this massive
Speaker 2: shift in the industry toward what you have.
Speaker 1: The physical token. But the authors are very careful here
Speaker 1: because not all tokens are created equal. We see smart
Speaker 1: cards everywhere, but a lot of them are actually quite dumb.
Speaker 2: Yeah, you mean, like the key card you get for
Speaker 2: a hotel room.
Speaker 1: Exactly. It's not just a smart card.
Speaker 2: It's usually just a memory card. It has a magnetic
Speaker 2: stripe or a very simple chip that literally just holds
Speaker 2: a number. If I have a basic card reader, which
Speaker 2: I can buy online for twenty bucks, I can read
Speaker 2: that number and then just copy it. I can clone
Speaker 2: your key in seconds.
Speaker 1: So it's basically a post it note with a password
Speaker 1: written on it that you happen to carry in your wallet.
Speaker 2: Pretty much. The real security comes from cards that have
Speaker 2: an actual microprocessor built in. It has a CPU RAM
Speaker 2: and an operating system right there on the plastic.
Speaker 1: The German EID card was the example they used, right,
Speaker 1: the Neuer Personal Loss spice.
Speaker 2: Yes, it is a great example of this done right.
Speaker 2: It's active, not passive.
Speaker 1: How does that differ from the hotel key?
Speaker 2: Practically speaking, it has a card access number or can
Speaker 2: printed right on the front. If a hacker walks past
Speaker 2: you in a cafe with the scanner hidden in their pocket,
Speaker 2: they can't just skim your data wirelessly.
Speaker 1: Because the card stops them.
Speaker 2: The card literally refuses to talk to the reader unless
Speaker 2: that physical six digit number is entered first to authorize
Speaker 2: the handshake. It validates the reader before it gives up
Speaker 2: a single bite to data. It also uses a machine
Speaker 2: readable zone for even higher security tasks.
Speaker 1: That is a huge structural difference. So let's take it
Speaker 1: one step further. Because we've done what you know and
Speaker 1: what you have. The final frontier, according to the text,
Speaker 1: is what you are biometrics. Yeah, and the scale of
Speaker 1: the UA project mentioned in the notes is just massive.
Speaker 2: It's one of the most comprehensive biometric systems in the world.
Speaker 2: Right now, they are scanning irises at seventeen different AirLand
Speaker 2: and seaports.
Speaker 1: And we should clarify this isn't a retinal scan and
Speaker 1: it's not fingerprints. This is the surface of the eye.
Speaker 2: It's the texture of the iris. They use a near
Speaker 2: infrared camera, which is totally safe. It's just like the
Speaker 2: light from a TV remote to capture the incredibly complex
Speaker 2: pattern your iris.
Speaker 1: But here's the cool part. They don't just save a
Speaker 1: picture of your eye. They convert that texture into a
Speaker 1: phase code.
Speaker 2: Think of the phase code like a digital fingerprint or
Speaker 2: a hash, but for your physical anatomy. It turns the
Speaker 2: chaotic organic patterns of your eye into a clean, searchable
Speaker 2: string of binary code. Similar to a DNA.
Speaker 1: Sequence, and that allows them to match a traveler against
Speaker 1: a massive central database in real time, which you just
Speaker 1: couldn't do if you were trying to compare high res
Speaker 1: JPEG images of eyeballs.
Speaker 2: Exactly. It makes the exhaustive search practically instant.
Speaker 1: So that's the defense side. We lock the doors with
Speaker 1: math and smart cards and eyeballs. But let's pivot to
Speaker 1: the offense, because when things go wrong in cybersecurity, they
Speaker 1: happen fast, and looking at the history of malware in
Speaker 1: this book, the scariest thing isn't even the complexity of
Speaker 1: the code, it's the acceleration.
Speaker 2: It really is a story of terrifying speed. If you
Speaker 2: go back to the Brain virus in the nineteen eighties,
Speaker 2: it spread via floppy.
Speaker 1: Disks, literally moving at the speed of a human walking.
Speaker 2: Right, walking a disc from one physical computer to another.
Speaker 2: It took months to infect a few thousand machines.
Speaker 1: Artisanal small batch malware.
Speaker 2: Yeah, exactly, small batch.
Speaker 1: Yeah.
Speaker 2: But then you compare that to the Melissa virus in
Speaker 2: nineteen ninety nine email. Suddenly you aren't walking, you are
Speaker 2: driving on the highway. Melissa hit one hundred thousand computers
Speaker 2: in just three days.
Speaker 1: Which felt completely catastrophic at the time. I remember the
Speaker 1: news coverage.
Speaker 2: It was a huge deal. But fast forward just five
Speaker 2: years to My Doom in two thousand and four. My
Speaker 2: Doom didn't just infect computers, It flooded the entire Internet
Speaker 2: with one hundred million infected messages in thirty.
Speaker 1: Six hours, from months to day's to hours, and.
Speaker 2: Today it's milliseconds. And the tactics have evolved too. It's
Speaker 2: not just about writing a clever virus anymore. It's about
Speaker 2: the supply chain.
Speaker 1: The excode ghost attack from twenty fifteen that blew my mind.
Speaker 2: It's brilliant in an evil way. The attackers didn't target
Speaker 2: the users directly. They targeted the developers. They created a
Speaker 2: compromised version of Apple's xcode, which is the tool developers
Speaker 2: used to build iosps.
Speaker 1: So the developers unwittingly bake the malware right into their
Speaker 1: legitimate apps.
Speaker 2: Exactly millions of users downloaded totally normal apps that were
Speaker 2: secretly infected at the factory.
Speaker 1: And then there's the social engineering side of it. The
Speaker 1: book mentioned that fake Twitter weight loss campaign.
Speaker 2: Oh yeah, that's a perfect example of modern tactics.
Speaker 1: It wasn't even about hacking passwords. It was thousands of
Speaker 1: fake bot accounts all talking to each other, reinforcing each
Speaker 1: other's messages to build credibility so human users would trust
Speaker 1: the malicious links.
Speaker 2: It's hacking human psychology instead of code. But going back
Speaker 2: to the sheer volume of traffic, the goal of attack
Speaker 2: has changed a lot too. My doom was about spreading.
Speaker 2: Now a lot of tacks are purely about exhaustion Denial
Speaker 2: of service.
Speaker 1: Right DOS attacks. I wanted to ask about this actually
Speaker 1: because the syn cookie defense mechanism mentioned in the notes
Speaker 1: is honestly brilliant, But I need you to explain it
Speaker 1: because the technical jargon got pretty thick there.
Speaker 2: Sure, okay. Imagine a web server is like a receptionist
Speaker 2: at a very busy office. When you want to connect
Speaker 2: that as a YAN request, the receptionist opens a physical
Speaker 2: file folder, writes down your name, and waits for you.
Speaker 1: To reply, and that folder takes up space on the desk,
Speaker 1: which is server memory.
Speaker 2: Right, So a denial service attack works by sending a
Speaker 2: million faith people to the desk all at once. The
Speaker 2: receptionist opens a million folders, runs out of desk space,
Speaker 2: and the whole office just crashes. Valid users can't get in.
Speaker 1: So how does the s Y and cookie actually fix that?
Speaker 2: The receptionist just stops opening folders entirely. When you show up,
Speaker 2: they write the connection details, the secret handshake, essentially a
Speaker 2: little sticker to take it on your jacket and send
Speaker 2: you away. They just say come back with this sticker.
Speaker 1: So the server doesn't remember anything at all.
Speaker 2: Zero, It is completely stateless. If you're a real user,
Speaker 2: you come back with a sticker, which is the cookie.
Speaker 2: The server reads, it verifies the secret handshake, and then
Speaker 2: lets you in.
Speaker 1: And if you're a fake bought from a doss attack, you.
Speaker 2: Never come back and the server hasn't wasted a single
Speaker 2: bite of memory trying to remember you.
Speaker 1: That is incredibly smart. It puts the entire burden of
Speaker 1: memory back on the user exactly.
Speaker 2: It's just really robust engineering.
Speaker 1: Speaking of engineering, or I guess broken engineering, we really
Speaker 1: have to look under the hood. We talk about software
Speaker 1: vulnerabilities all the time, but I think most people visualize
Speaker 1: like a loose wire or a physical crack, but it's
Speaker 1: actually usually a confusion of language.
Speaker 2: It's a confusion between data and instructions. The buffer overflow
Speaker 2: is the absolute classic example of this.
Speaker 1: This was my favorite deep tech moment in the reading
Speaker 1: the pint glass analogy.
Speaker 2: Yeah, so, imagine a program has a designated space in memory,
Speaker 2: a pint glass to hold your input. Let's say it's
Speaker 2: asking for your user name. Okay, but the programmer used
Speaker 2: an older traditional C library function like gets, and gets
Speaker 2: doesn't actually check if the input fits the glass. So
Speaker 2: if you pour a gallon of water into that pint glass,
Speaker 2: it spills, right.
Speaker 1: The water has to go somewhere, so it spills over
Speaker 1: into the neighbor's yard.
Speaker 2: It spills into the adjacent memory addresses. And this is
Speaker 2: the critical part. The memory right next to your data
Speaker 2: often holds something called the return.
Speaker 1: Address, which tells the computer where to go next when
Speaker 1: it finishes the current task.
Speaker 2: Precisely, so, the attacker deliberately spills their malicious data over
Speaker 2: the edge, specifically to overwrite that return address. They replace
Speaker 2: the instruction go back to the main program with go
Speaker 2: to this malicious code I just injected into.
Speaker 1: The spell, and the computer just does it. It doesn't
Speaker 1: know the difference.
Speaker 2: The computer just blindly follows instructions. It doesn't know that
Speaker 2: the instruction came from a spell. And this isn't just theory.
Speaker 2: This exact vulnerability was what powered the famous Morris Internet
Speaker 2: warm way back in nineteen eighty eight, and we are
Speaker 2: still dealing with it today.
Speaker 1: Because it's the exact same logic with.
Speaker 2: SQL injection right, very similar.
Speaker 1: Yes, the example in the book was the Boston semi
Speaker 1: colon drop t table.
Speaker 2: Right. So you have a database script expecting a city name.
Speaker 2: If I tie Boston, it finds Boston. But if I
Speaker 2: tie Boston followed by a semicolon and then the words
Speaker 2: d dropped table order stable high hyphen.
Speaker 1: To the database. A semi colon is basically a period
Speaker 1: at the end of a sentence.
Speaker 2: Exactly the database is the semi coolon thinks, okay, the
Speaker 2: first command to find the city is finished. Then it
Speaker 2: reads the next part. It thinks, oh, a new command
Speaker 2: from the boss. I need to delete the entire order's table.
Speaker 1: It's so carefully literal, it's like a gollum. It does
Speaker 1: exactly what you say, even if you say destroy yourself.
Speaker 2: That is exactly why sanitize your inputs is the golden
Speaker 2: rule of secure coding. You can never ever trust what
Speaker 2: the user types into a box.
Speaker 1: But sometimes the problem isn't actually the code itself. Sometimes
Speaker 1: it's the logic of the access system. We touched on
Speaker 1: the difference between RBAC and ABAC in the notes, role
Speaker 1: based versus attribute based access control.
Speaker 2: Yeah, RBAC is the traditional old school way. It says
Speaker 2: you have the role of manager. Therefore you can see
Speaker 2: all the manager files, like being classified as an adult
Speaker 2: so you can see R rated movies.
Speaker 1: It's static, simple, but very rigid.
Speaker 2: Well. ABAC is much more fluid and flexible. It looks
Speaker 2: at specific attributes. It asks who is the subject, what
Speaker 2: is the object, and.
Speaker 1: What is the environment the context?
Speaker 2: Right, you might be a manager, but ABAC says you
Speaker 2: cannot access the highly sensitive payroll file from an insecure
Speaker 2: public Wi Fi network at two am in a foreign country.
Speaker 1: It adds nuance, but even with perfectly designed access control,
Speaker 1: you still run into the inference problem. The cargo plane
Speaker 1: scenario in the textbook was hands down my favorite puzzle
Speaker 1: in the whole Deep Dick.
Speaker 2: It's a fantastic logic problem. It perfectly illustrates how incredibly
Speaker 2: hard it is to actually keep a secret in a database.
Speaker 1: So, for you listening, the scenario goes like this, you
Speaker 1: have a cargo plane flight twelve fifty four I am
Speaker 1: a low level employee looking at the database, I can
Speaker 1: see that the plane is carrying two shipments. I can
Speaker 1: see a crate of boots and a crate of guns,
Speaker 1: both of.
Speaker 2: Which are classified as unclassified items, so you are allowed
Speaker 2: to see them.
Speaker 1: But I am definitely not allowed to know about the
Speaker 1: third crate, which contains an atomic bond.
Speaker 2: Right that is top secret. So the database successfully hides
Speaker 2: that speci row from your view. The system is working perfectly.
Speaker 1: But then I query the database and I ask what
Speaker 1: is the total overall weight of flight twelve fifty four,
Speaker 1: And the database tells me the total weight is fifty
Speaker 1: thousand pounds.
Speaker 2: And that right there is the leak. Because you can
Speaker 2: look at the boots and the guns and calculate that
Speaker 2: together they only weigh ten thousand pounds.
Speaker 1: So I just do some very basic math fifty thousand
Speaker 1: minus ten thousand. I now know for a fact that
Speaker 1: there is forty thousand pounds of something on that plane
Speaker 1: that I am not allowed to see. I have inferred
Speaker 1: the existence of a massive secret payload just by looking
Speaker 1: at the gaps in the public data.
Speaker 2: And the authors highlight this as a major persistent challenge
Speaker 2: keeping secrets when the mere absence of data gives the
Speaker 2: secret away is a nightmare. You either have to lie
Speaker 2: to the user about the total weight, which completely ruins
Speaker 2: the integrity of your.
Speaker 1: Data, or you have to hide the existence of the
Speaker 1: entire flight, which ruins availability.
Speaker 2: Exactly, it's a structural paradox.
Speaker 1: So we've covered the math, the code, and the logic,
Speaker 1: but we really can't finish this deep dive without talking
Speaker 1: about the physical world, because at the end of the day,
Speaker 1: the cloud is just someone else's computer, and that computer
Speaker 1: is made of metal and plastic and metal melts.
Speaker 2: It really does. We spend so much time obsessing over
Speaker 2: software we often ignore physical threats. But fire and water
Speaker 2: are just as dangerous as hackers. The temperature thresholds listed
Speaker 2: in the book are sobering.
Speaker 1: It wasn't just a generic fire as bad warning either.
Speaker 1: It was incredibly specific.
Speaker 2: Very specific. At two hundred and sixty degrees celsius, which
Speaker 2: is about five hundred fahrenheit, wood ignites, but your server
Speaker 2: data might actually survive that ambient temperature for a little bit.
Speaker 2: The real danger zone starts at four hundred and eighty
Speaker 2: degrees celsius.
Speaker 1: That's where the uninsulated steel files start to buckle.
Speaker 2: Right, Yes, the steel warps, and if the case warps,
Speaker 2: the hard drives inside are physically crushed. Game over. And
Speaker 2: if the fire gets hotter, aluminum melts at sixteen hundred
Speaker 2: and twenty five celsius. Hard steel melts at fourteen ten.
Speaker 1: So you obviously need rigorous fire suppression. But then you
Speaker 1: have the threat I mentioned in the intro humidity.
Speaker 2: The silent killer of data centers. If the humidity is
Speaker 2: too high, you obviously get corrosion, but you also get
Speaker 2: this incredibly creepy phenomenon called silver migration.
Speaker 1: Which sounds like a beautiful bird migration, but it is
Speaker 1: definitely not.
Speaker 2: No, not at all. Under high humidity conditions, the actual
Speaker 2: silver in the solder of the circuit boards can literally
Speaker 2: migrate across the surface of the board. It moves, yes,
Speaker 2: it grows these tiny metallic tendrils that reach out and
Speaker 2: physically touch other connectors.
Speaker 1: So it basically grows its own short circuits.
Speaker 2: It does. It's like the motherboard is being slowly eaten
Speaker 2: from the inside out.
Speaker 1: Okay, so just keep the room super dry then, but
Speaker 1: you can't keep it too dry.
Speaker 2: If the relative humidity drops too low, you get static electricity,
Speaker 2: and human beings are essentially walking lightning bolts. You can
Speaker 2: generate thousands of volts of static charge just by walking
Speaker 2: across a carpeted floor.
Speaker 1: But the microchicks are sensitive, incredibly sensitive.
Speaker 2: It only takes a static discharge of ten volts to
Speaker 2: completely fry a modern sensitive circuit.
Speaker 1: Ten volts.
Speaker 2: Ten volts. You wouldn't even feel the spark, you wouldn't
Speaker 2: hear a pop. You would just reach out touch the
Speaker 2: server rack and thousands of dollars of equipment would die instantly.
Speaker 1: That is just such a fragile balance to maintain. We
Speaker 1: are fighting hackers, we are fighting humidity, static electricity, and
Speaker 1: basic physics. So how do network admins even sleep at night?
Speaker 1: What is the safety net when things inevitably go wrong?
Speaker 2: Well, the text points toward intrusion detection systems or IDs
Speaker 2: as the primary net and the core foundational concept.
Speaker 1: There is baselining, meaning the system has to know what
Speaker 1: normal actually looks like exactly.
Speaker 2: You can't spot an anomaly if you don't know the
Speaker 2: daily pattern. The system spends time learning, it learns okay.
Speaker 2: Usually we have fifty people requesting DHCP leases at nine am.
Speaker 1: So if suddenly five thousand people log in at three
Speaker 1: am on a Sunday.
Speaker 2: That triggers an alert. It's what they call an NBS,
Speaker 2: an event driven by never before seeing drivers. It's the
Speaker 2: digital equivalent of a guard dog barking because the wind
Speaker 2: changed around. It might be nothing, it might be a glitch,
Speaker 2: but you absolutely need to check it out.
Speaker 1: Because the legal and ethical frameworks around this are still
Speaker 1: so messy.
Speaker 2: Oh yeah. The book touches on the Convention on Cybercrime
Speaker 2: and how difficult it is internationally to even legally define
Speaker 2: things like computer related forgery and fraud across borders.
Speaker 1: It really feels like we're constantly just playing defense, trying
Speaker 1: to plug holes in a sinking ship. But I want
Speaker 1: to end on this final provocative thought that the reading
Speaker 1: inspired because it loops all the way back to the
Speaker 1: concept of trust.
Speaker 2: You're thinking about the supply chain risk again.
Speaker 1: Yes, exactly. We talked about the ex coode ghost attack earlier,
Speaker 1: the malware that was baked into the actual app building tools.
Speaker 1: The developers didn't write the malware, They just used a
Speaker 1: trusted tool provided by a trusted vendor, and that tool
Speaker 1: was secretly compromised.
Speaker 2: It forces us as an industry to ask a genuinely
Speaker 2: terrifying question. If the foundational tools we use to build
Speaker 2: our software are themselves compromised, can we ever truly trust
Speaker 2: the final product.
Speaker 1: It's like buying a heavy duty vault door, but the
Speaker 1: factory that forged the steel secretly kept a master key.
Speaker 2: Exactly For decades, the entire philosophy was protect a perimeter,
Speaker 2: build a giant firewall around your corporate castle, and trust
Speaker 2: everyone inside.
Speaker 1: But if the bricks you used to build the wall
Speaker 1: are bug from the factory, the perimeter.
Speaker 2: Is useless, Which is why the cutting edge of the
Speaker 2: industry is moving toward a philosophy called zero trust. You
Speaker 2: trust nothing, You verify everything continuously trust nothing.
Speaker 1: That is a slightly paranoid but probably very necessary place
Speaker 1: to leave things.
Speaker 2: For today in this business, paranoid is definitely a virtue.
Speaker 1: While on that happy note, thank you for guiding us
Speaker 1: through the minefield of the CIA.
Speaker 2: Triad today, always happy to do.
Speaker 1: It, and to you, the learner, thank you for joining us.
Speaker 1: Go check your password manager today. If your password is
Speaker 1: password one, two three or your own name, please, for
Speaker 1: the love of data integrity, change it immediately. Make it
Speaker 1: a random sentence about your dog.
Speaker 2: Just maybe don't use the name Rex. Now that we've
Speaker 2: broadcast that specific trick to the entire Internet.
Speaker 1: Fairpoint, pick a different dog. Thanks for listening to the
Speaker 1: Deep Dive, and we'll catch you next time.