1
00:00:00,000 --> 00:00:04,840
Alright, ready to dive in. Today, it's security control testing and we're going well.

2
00:00:05,180 --> 00:00:09,620
Deep. Thanks for sending over that 002 Chris Domain 6 excerpt.

3
00:00:09,780 --> 00:00:11,000
That's some serious stuff.

4
00:00:11,400 --> 00:00:16,520
Let's make sure by the end of this. It's not just interesting, but whoa, I can actually use this knowledge.

5
00:00:16,520 --> 00:00:20,840
And you hit the nail on the head. It's bigger than just, you know, checking your app for a bug or two.

6
00:00:20,840 --> 00:00:24,760
It's almost like back in the day how you'd plan a whole fortress's defenses right.

7
00:00:24,760 --> 00:00:29,760
You have a strong wall sure, but also guards on watch ways to spot if someone's

8
00:00:29,760 --> 00:00:34,320
tunneling in from below. Digital physical. I think like those weaknesses are already there.

9
00:00:34,320 --> 00:00:39,360
Just waiting to be found. Okay. I'm already picturing modes and draw bridges, but for like my laptop.

10
00:00:39,720 --> 00:00:42,960
If we're going full on fortress defense mode, where do we even start?

11
00:00:42,960 --> 00:00:45,960
Your ex-surpt mentioned assessments vulnerabilities.

12
00:00:46,320 --> 00:00:47,280
Is that the first line?

13
00:00:47,280 --> 00:00:51,520
Exactly. Imagine sending scouts out mapping the terrain. That's a vulnerability assessment.

14
00:00:51,520 --> 00:00:55,840
But instead of hills and valleys, it's cracks in the software or even just like having all the

15
00:00:55,840 --> 00:01:00,400
important data in one easily accessible spot, bad design is a weakness too.

16
00:01:00,400 --> 00:01:05,120
S-sky, C-B-E, CVSS, oval, those are our tools for this mapping.

17
00:01:05,120 --> 00:01:08,160
Accranim alert. Break those down for me a bit, please.

18
00:01:08,160 --> 00:01:13,280
It's like if you had a bunch of security tools, but they're all from different companies, right?

19
00:01:13,280 --> 00:01:18,640
Chaos. S-K-P is the universal adapter making them play nice, Sharon Foe.

20
00:01:18,640 --> 00:01:24,720
Then C-B-E, that's a public database, but think, like security flaws most wanted poster

21
00:01:24,720 --> 00:01:30,080
collection. We know these exist. CVSS then tells us how bad each one is, kind of like threat

22
00:01:30,080 --> 00:01:35,120
level, you know, and oval, that's just making sure everyone's speaking the same language when

23
00:01:35,120 --> 00:01:38,000
describing those weaknesses standardization is key.

24
00:01:38,240 --> 00:01:42,400
So common language, shared understanding of the bad guys playbook makes sense.

25
00:01:42,400 --> 00:01:46,080
But I'm guessing now things get fun penetration testing, right?

26
00:01:46,080 --> 00:01:48,240
That's where we try to actually use these exploits.

27
00:01:48,240 --> 00:01:52,240
You got it. Time to put those vulnerabilities to the test. See if there's real as they seem.

28
00:01:52,240 --> 00:01:55,840
Just like a real attacker would. This gives us a nice framework to follow.

29
00:01:55,840 --> 00:01:59,840
Start with planning what are we testing, what's off limits, setting the rules of the game,

30
00:01:59,840 --> 00:02:04,160
then it's recon-gathering Intel on the target, their defenses, any potential weak points.

31
00:02:04,160 --> 00:02:08,640
So Intel gathering, scoping out the weak spots, and then boom attack.

32
00:02:08,640 --> 00:02:12,640
Exactly. That's where the rubber meets the road, trying to break in,

33
00:02:12,640 --> 00:02:16,720
exploiting those vulnerabilities. This is the key difference between a vulnerability assessment

34
00:02:16,720 --> 00:02:21,600
and penetration testing. Think of it like a guard patrolling the walls. That's your assessment.

35
00:02:21,600 --> 00:02:25,040
Penetration testing is someone actually trying to climb those walls and get in.

36
00:02:25,040 --> 00:02:30,880
Love that analogy. But your material mentioned different shades of penetration testing.

37
00:02:30,880 --> 00:02:33,920
White gray black box. What's the difference?

38
00:02:33,920 --> 00:02:39,200
It's all about how much the tester knows going in. Imagine trying to crack a safe.

39
00:02:39,200 --> 00:02:42,800
White box, you've got the blueprints, you know every gear, every tumbler.

40
00:02:42,800 --> 00:02:47,440
Gray box, you've got some insider info. Maybe you know it's an old model with the loose handle.

41
00:02:47,440 --> 00:02:50,000
Black box. That's going in blind. The true test.

42
00:02:50,000 --> 00:02:54,080
Okay. So we've mapped our weaknesses, poked and prodded them to see if they're real.

43
00:02:54,080 --> 00:02:58,000
Yeah. Fortress is secure right. Hold on, not so fast. We still need to talk about the

44
00:02:58,000 --> 00:03:02,960
less glamorous but equally crucial detective work of security, log reviews.

45
00:03:02,960 --> 00:03:07,280
Log reviews huh. So if pen testing is our action movie highs,

46
00:03:07,280 --> 00:03:11,920
log reviews more like what meticulously combing through security footage afterward.

47
00:03:11,920 --> 00:03:17,520
Still looking for clues. Just different kind. You got it. Logs tell the story, but it's not

48
00:03:17,520 --> 00:03:21,520
always a thrilling one. Every login, every file open, it's all in there. Like a security

49
00:03:21,520 --> 00:03:27,920
can that records everything. Trick is, got to look for two things. The obvious we're being robbed

50
00:03:27,920 --> 00:03:34,640
stuff like tons of failed logins from some weird address. But T also, and this is sneaky,

51
00:03:34,640 --> 00:03:40,320
abuse of privileges. Someone with access, they shouldn't have data being looked at at 3 a.m.

52
00:03:40,320 --> 00:03:45,520
Might not set off sirens, but it's fishy. Ah, so that's where those sim packages. The NTP,

53
00:03:45,520 --> 00:03:51,760
all that comes in, making sense of the data deluge. Exactly. Imagine your security analyst, right?

54
00:03:51,760 --> 00:03:55,920
Now, give them superpowers to read through mountains of logs in real time, connecting the dots,

55
00:03:55,920 --> 00:04:01,120
spawning patterns that sim your super power threat detection, and NTP. That's making sure

56
00:04:01,120 --> 00:04:05,040
everyone clocks are synced up because good luck figuring out what happened when if your logs are

57
00:04:05,040 --> 00:04:10,160
all timestamp wonky. Time is of the essence in these situations for sure. So we've got our

58
00:04:10,160 --> 00:04:14,400
assessments, pen testing with its shades of gray and black and white. No, what for you? And our

59
00:04:14,400 --> 00:04:18,640
trusty log detectives, we covered it all. You'd think so, wouldn't you? But the world of

60
00:04:18,640 --> 00:04:23,680
security, it's like that arms race. You know, good guys, bad guys, constantly upping their game,

61
00:04:23,680 --> 00:04:29,200
that's where things get even more interesting synthetic transactions. Sust versus dast,

62
00:04:29,200 --> 00:04:34,800
even misuse case testing. Whole new bag of tricks. Whoa, slow down, slow down, unpack some of those

63
00:04:35,680 --> 00:04:40,320
for me synthetic transactions. That sounds kind of like creating a fake user or something. That's

64
00:04:40,320 --> 00:04:45,840
it. Imagine you've got, say, an online store synthetic transaction is like a simulated user

65
00:04:45,840 --> 00:04:51,040
going through the motions, browsing, adding to cart, the whole shabang, but it's all controlled,

66
00:04:51,040 --> 00:04:55,920
helps you spot those hidden bottlenecks, points of failure. Maybe the checkout process crashes

67
00:04:55,920 --> 00:05:01,360
at some critical point or there's a data leak we got to plug valuable intel. Catching the stuff

68
00:05:01,360 --> 00:05:06,640
that might not trip the normal alarms. What about sast and dast, then? They seem to be more about

69
00:05:06,640 --> 00:05:11,920
the nitty-gritty of the code itself, right? You got it. Think of sast that static application

70
00:05:11,920 --> 00:05:16,720
security testing, like getting your car engine checked, but it's parked. We can pop the hood,

71
00:05:16,720 --> 00:05:22,160
look for loose wires, potential issues right there in the code, find those SQL injection risks,

72
00:05:22,160 --> 00:05:27,200
cross-site scripting, that kind of stuff. Dast, base dynamic that's taking the car for a spin.

73
00:05:27,840 --> 00:05:32,640
See how it handles on the open road under pressure. So, blue prints versus road test,

74
00:05:32,640 --> 00:05:38,400
both important for different reasons. And this misuse case testing sounds kind of misgivious,

75
00:05:38,400 --> 00:05:42,640
got to be honest. It's all about thinking like the bad guy, you know. Positive testing,

76
00:05:42,640 --> 00:05:46,320
we're making sure the system does what it's supposed to. Negative testing is like okay,

77
00:05:46,320 --> 00:05:52,000
but what if someone plugs in garbage data? How's it hold up? Misuse case is taking it further,

78
00:05:52,000 --> 00:05:56,880
intentionally trying to break it. So, if positive is using the website normally,

79
00:05:56,880 --> 00:06:02,320
negative is putting in gibberish. Misuse is figuring out if you can use that gibberish field to inject

80
00:06:02,320 --> 00:06:07,760
code or gain access somehow, thinking like an attacker. Your source material mentions boundary

81
00:06:07,760 --> 00:06:12,400
value analysis and equivalence, partitioning those are ways to get systematic about it,

82
00:06:12,400 --> 00:06:16,640
testing the edges of what's allowed, seeing where things break down. Security folks must have

83
00:06:16,640 --> 00:06:22,240
some wild imaginations always thinking of the worst case scenario, but with all this testing,

84
00:06:22,240 --> 00:06:28,960
simulating. Misuse realize how crucial it is to have people who really know their stuff,

85
00:06:28,960 --> 00:06:34,560
looking at the code itself. That's code review and testing. You know, it's funny you say that

86
00:06:34,560 --> 00:06:38,720
about thinking the worst almost like the security professional super power right? Because when we

87
00:06:38,720 --> 00:06:43,760
get down to it, it's the code itself that makes or breaks everything and that's got to be where

88
00:06:43,760 --> 00:06:49,280
this real expertise shines code review. Am I right? 100%. I always say you wouldn't just write a book

89
00:06:49,280 --> 00:06:53,360
and publish it without an editor or someone really going over it. Right? Code review, it's like that,

90
00:06:53,360 --> 00:06:58,720
but a whole team of editors all laser focused on spotting not just typos, but security gaps

91
00:06:58,720 --> 00:07:03,440
bad logic, the works. And just like we were saying about pen testing, there's the black box,

92
00:07:03,440 --> 00:07:08,240
where you're just seeing the code does its job output's good, that's that. But then white box

93
00:07:08,240 --> 00:07:12,480
were down in the weeds, line by line, figuring out how it works, because that's how you catch

94
00:07:12,480 --> 00:07:17,520
the really sneaky stuff. So extra sets of eyes, or maybe whole extra brains, focus on this

95
00:07:17,520 --> 00:07:22,320
critical stuff. Now, your document mentioned, Fage and Inspections, that sounds intense. What makes

96
00:07:22,320 --> 00:07:27,840
them different? Fage and oh yeah, that's like top tier code review, the gold standard, six steps, very

97
00:07:27,840 --> 00:07:33,920
meticulous, planning it out, overview, prep, then the actual inspection, rework if needed,

98
00:07:33,920 --> 00:07:38,480
and follow up to make sure it's solid. What's great is it's not just the security folks,

99
00:07:38,480 --> 00:07:43,520
it's the whole dev team involved, everyone understanding the code, the risks, how to fix those

100
00:07:43,520 --> 00:07:48,320
risks. That's how you catch those tiny errors that would otherwise slip through. So careful planning,

101
00:07:48,320 --> 00:07:52,400
thorough checking, and teamwork on the fixes, no wonder it's the gold standard. But even with the

102
00:07:52,400 --> 00:07:57,120
best code in the world, we still got to put it through the ringer, right? Is that where coverage analysis

103
00:07:57,120 --> 00:08:01,840
comes in, making sure every nook and cranny is tested? Precisely, imagine you're testing a car,

104
00:08:01,840 --> 00:08:06,480
right? You didn't just start the engine and say, good enough, you got to check brakes, steering,

105
00:08:06,480 --> 00:08:11,360
lights, everything. That's what coverage analysis is all about, ensuring we're not just testing

106
00:08:11,360 --> 00:08:16,240
the obvious parts of the system. We're talking branch coverage, like testing all the different paths

107
00:08:16,240 --> 00:08:22,800
the code could take. Condition coverage, so if x happens, then y, but what if z happens instead?

108
00:08:22,800 --> 00:08:27,120
And of course, functional coverage, making sure each part of the code does what it's supposed to.

109
00:08:27,840 --> 00:08:34,000
Aim for that 100% coverage, leave no stone and turn. Okay, so we're basically creating a heat map

110
00:08:34,000 --> 00:08:38,080
of our entire system, showing what's been tested, what needs more tension. And boss smart.

111
00:08:38,080 --> 00:08:42,480
But we talked about individual pieces, right? Yeah. What about how those pieces talk to each other

112
00:08:42,480 --> 00:08:46,880
into the outside world? That's interface testing, right? APIs, UIs, all that jazz.

113
00:08:46,880 --> 00:08:51,440
You got it. Interface testing is critical because it's all about communication,

114
00:08:51,440 --> 00:08:56,800
both within the system and with the outside world. APIs, those are the unsung heroes,

115
00:08:56,800 --> 00:09:01,200
letting different systems talk to each other by the scenes, like how your phone can connect to

116
00:09:01,200 --> 00:09:07,760
your bank app seamlessly. Then there's the UI, the part we all see, buttons, screens,

117
00:09:07,760 --> 00:09:11,920
menus, needs to be user friendly, but secure too. And then there are the physical

118
00:09:11,920 --> 00:09:16,160
interfaces, those get really interesting. Physical. Okay, now you've got my attention.

119
00:09:16,160 --> 00:09:21,760
Give me an example. Think about a self-driving car, right? Tons of software in there, obviously,

120
00:09:21,760 --> 00:09:26,880
but it's also got to interact with the real world. Sensors, cameras, mechanical parts,

121
00:09:26,880 --> 00:09:31,680
software glitch there. That's not just a bug report that's potentially a car accident.

122
00:09:31,680 --> 00:09:35,680
High stakes. Okay, that's a great example. Makes you realize how blurry the lines are getting

123
00:09:35,680 --> 00:09:40,080
between the digital and the real and how important it is to test those connections thoroughly.

124
00:09:40,080 --> 00:09:44,480
Speaking of which, your source material mentions something called breech attacks simulations,

125
00:09:44,480 --> 00:09:49,520
BAS, that like pen testing on steroids. That's one way to put it. Traditional pen testing. It's

126
00:09:49,520 --> 00:09:55,040
like a snapshot in time, testing against what we know right now. Basis, that's the 24-7 security

127
00:09:55,040 --> 00:10:00,400
team, but instead of humans, it's software. Simulating attacks, constantly probing, learning

128
00:10:00,400 --> 00:10:05,600
your defenses, trying different tactics. It's proactive, finding those gaps before they become

129
00:10:05,600 --> 00:10:11,440
a headline. So constant vigilance, but automated, and I bet it doesn't just tell you what's wrong,

130
00:10:11,440 --> 00:10:16,880
but also how well you detect your respond, right? Like, did your sim catch it? How long did it take?

131
00:10:16,880 --> 00:10:21,600
What could be better? It's like a continuous feedback loop of improvement. Exactly. And that's

132
00:10:21,600 --> 00:10:25,600
the beauty of it. We're not just identifying vulnerabilities. We're testing the effectiveness of

133
00:10:25,600 --> 00:10:30,640
our defenses as a whole, constantly learning and adapting. Now that is cool, like having a

134
00:10:30,640 --> 00:10:35,280
crystal ball, but for security flaws. But even with all this testing, all this amazing

135
00:10:35,280 --> 00:10:39,600
tech, it's not just about finding the problems, isn't it? We also need to make sure we're

136
00:10:39,600 --> 00:10:43,600
playing by the rules. That's where compliance comes in. Yeah, dotting the eyes and crossing those

137
00:10:43,600 --> 00:10:50,080
tees. Absolutely, especially in regulated industries, compliance is key. Think of it like building a

138
00:10:50,080 --> 00:10:54,640
house. You don't just want to be strong. You want it to meet building codes, right? Making sure

139
00:10:54,640 --> 00:10:59,840
everything's up to snuff, following the rules. That's what compliance is all about. Makes sense.

140
00:10:59,840 --> 00:11:03,760
So it's not just about building fort knocks. It's about building fort knocks by the book.

141
00:11:03,760 --> 00:11:09,280
We've covered so much ground today from basic assessments all the way to this futuristic,

142
00:11:09,280 --> 00:11:14,640
breach simulation stuff. Make sure realize security is a journey, not a destination.

143
00:11:15,040 --> 00:11:19,040
Got a stay vigilant, keep learning, keep adapting. Couldn't have said a better myself.

144
00:11:19,040 --> 00:11:23,280
That's the key takeaway here. Well, on that note, let's leave our listeners with something to ponder.

145
00:11:23,920 --> 00:11:29,680
As tech keeps evolving at this crazy pace, how deal organizations stay ahead. How do we make

146
00:11:29,680 --> 00:11:34,800
sure those security testing methods are sharp enough to handle whatever comes next. That's the

147
00:11:34,800 --> 00:11:39,600
challenge and it's not going away anytime soon. But hey, that's why we love this stuff, right?

148
00:11:39,600 --> 00:12:01,520
Keep learning, keep exploring and we'll see you in the next deep dive.