Shadowing Practice: Cybersecurity Architecture: Five Principles to Follow (and One to Avoid) - Learn English Speaking with Video

בחר מצב תרגול

כל מצב פותח חדר תרגול במסך מלא.

228 משפטים

אם המשפטים קצרים או ארוכים מדי, לחץ על ערוך כדי להתאים אותם.

With the rise of cyber attacks and data breaches, it's never been more important to make sure that your organization is protected against hackers.

This series is about cybersecurity architecture, and we're going to talk about two different areas: fundamentals, where we're going to go through

and discover what some of the principles of cybersecurity are that need to be applied to everything that you do.

And then the second part is on various cybersecurity domains.

Here, we're going to explore how to identify vulnerabilities implement best practices,

and defend against a wide range of cyber threats through an all -encompassing cybersecurity architecture.

By the way, I'm an adjunct professor at NC State University, and there I teach a 400 level course on enterprise security architecture.

This video series is based upon that course.

The bad news is you won't get college credit for watching these videos.

The good news is-- No homework and no exams, so yay.

All right.

Let's get started with cybersecurity fundamentals.

All right, we want to start with five security principles that you absolutely should do and one that you never should do.

So stay tuned to the end to find out what that one is.

The first one we're going to talk about is this notion of defense in depth.

Defense in depth is trying to create an obstacle course, a difficulty for the bad guy.

So if we take a look at an old security model, The castle.

Well, the castle was designed with thick tall walls to keep the good guys on the inside

and the bad guys on the outside.

And it worked pretty well until you realize the good guys sometimes needed to come out.

And therefore we needed to put a door on this thing.

Well, the door then became a vulnerability and so we would try to reinforce it and then maybe put a moat.

around the whole thing because that made it even harder.

And then the door with a drawbridge.

So now we've got a moat which is harder to cross.

We've got the thick tall walls.

And maybe we even added an angry dog here on this side.

Something to give a system of security mechanisms because defense in depth is all about not relying on any single security mechanism.

to keep the system safe.

Now let's move and transition into a modern security example.

Here we've got a user who is on a workstation, who's going to go across a network to get to a web server, which is going to hit an app server,

which is ultimately going to hit a database.

Now what would we do for defense in depth in this example?

Well, one thing I might do here is I might add multi -factor authentication.

That is a system where I make sure

that this user is who they are because I'm asking them for something they have, something they are, something they know, some combination of those kinds of things.

Now how about over here?

I might do, if it's a mobile device or an endpoint of some sort,

mobile device management, endpoint device management software, things like that.

We might also add something like an EDR, which is sort of a next generation antivirus,

an endpoint detection and response capability to make sure that this platform is secure.

Then from a network standpoint, well, I'm going to add in firewalls.

to keep the web server secure from the outside

and also allows only traffic that I choose to allow to get back to these more sensitive zones.

And then for the app server and the web server, I might do some testing,

some vulnerability testing on those so that I make sure that those systems are not vulnerable to attack.

And then ultimately, I'm going to take the data back here and I'm going to encrypt it.

lock it up, put access controls around it.

So you can see what I've done here is there's no single security mechanism that is protecting this thing.

If any one of these fails, the rest of the system still works.

And that's the idea that we're after here.

So if you think about it this way, we've got no single point of failure.

We're trying to avoid single points of failure.

And we want a system that ultimately, if it fails, it fails safe.

That's what we're trying to get and that's what the old model and the new model of securities were designed to do.

The second principle we're going to review is the principle of least privilege.

Principle of least privilege basically says I'm only going to give access rights to people that need that,

that are authorized and needed in order to do their job and can justify it, and for only as long as they need that access right.

For instance, in this example, I've got three users This guy is not really have a business need, so we don't give it to him.

The other guys get the access right.

They can prove their need.

And the other thing is, even for these guys, the clock is ticking.

I'm not going to give them this access right in perpetuity forever.

we're going to constantly be going back and making sure that they still need that capability.

If they don't, we're going to remove it from them as well.

Now another notion in the principle of least privilege is hardening a system.

Let's say we've got a web server like this.

And the web server out of the box, default configuration is that it runs HTTP of course because we need that in order to do web traffic.

But let's say it also turns on an FTP server.

and SSH service so that I can log in remotely.

Well, there's some things that I might look at and say, "Okay, do I really need this FTP server?

If it turns out I'm not going to use it, I should remove that service entirely.

In the SSH, if I'm not planning to use it, remove it entirely.

because every single one of these services is potentially expanding our attack surface and making us more vulnerable.

Another example of hardening is to remove all of the unnecessary IDs

that are on the system and change the names of the IDs that we do keep from their defaults.

So for instance, if the administrator ID on this system out of the box as it's configured is admin, Let's change that.

Let's make it something more specific.

and I'll name it after me or give it some other name, change all the default passwords.

We don't want this thing in just a vanilla configuration

because the bad guys will know what that is and they'll know how to break in.

Another example is this idea of privilege creep.

Let me illustrate that.

Let's say there's two people that work for the company and each one of these are access rights that they have.

So this guy is able to do these things, he can do the same things because they perform essentially the same role.

Now this guy gets a promotion and a new job and new responsibilities.

Well, he goes to the administrator and says, "Okay, now I'm doing my new job.

I need you to add to my capabilities." and these are the things I need.

The administrator gives him those and then also says, "You know what?

Just in case, I think you're going to probably need this, let me give you that as well.

That way you won't have to come back and ask again.

or "come back and bother me" is what he really means.

The problem with this is, just in case is just the opposite of principle of least privilege.

In fact, what we should be doing is running an annual recertification campaign. at least annual.

Some organizations do it more frequently than that.

And in research, I go back and look at all of my users

and all of their access rights and make sure they still have a justified need.

So this person still doing the same job, still needs all of that, great, they keep it.

This guy, though, no longer needs this capability because his new job doesn't require it, so we're taking it away.

100

And this thing that he got just in case, we're taking that away too.

101

So what we're trying to do with the principle of least

102

privilege is to give only the access rights you need for as long as you need them hardened systems, we're going to eliminate privilege creep,

103

and we're going to eliminate the just -in -case principle.

104

Our third principle to keep in mind with cybersecurity is this notion of separation of duties.

105

That is, we won't have any single point of control.

106

In fact, what we're trying to do is force collusion by two bad actors

107

or more than two bad actors in order to compromise the system.

108

But no single person can create the compromise.

109

So an example in the physical world would be

110

if I had two people here and I've got a door with two locks on it.

111

and this guy has a key to this lock, And this guy has a key to this lock.

112

and What it is is now if he uses his key to open the door, He still can't open the door.

113

He can't open the door alone.

114

But the two of them together cooperating can in fact open the door.

115

So there's no single point of control.

116

Therefore, we have a separation of duties.

117

Now, taking a look at another example here, let's say in an IT case, here's a requester and this user wants access to this database.

118

So he's going to ask for that.

119

He's going to send in his request, but then there's an approver who's going to have to take action on it and say yes or no, based upon whether we think they should have it or not.

120

Then if they get the approval, then they're given the action that they want.

121

You know, whatever it is, the funds transfer, the access to the database, the package delivered, whatever it happens to be.

122

But notice the point here.

123

This person, The requester is not the same as the approver.

124

they cannot be the same person because if it was, if I could request and approve my own request, then there is no separation of duties.

125

So again, what we're trying to do with this is create

126

a necessary case for collusion which is hard to do

127

because it's hard for lots of people to work together and keep a good secret.

128

And what we're trying to avoid is this single point of control.

129

The fourth security principle that we're going to talk about is secure by design.

130

In other words, it shouldn't be an afterthought that we put security in.

131

Think of it this way.

132

If you were designing a building in an earthquake zone, you want to make this building able to stand the pressure.

133

So, you don't go build the building and then after it's all done, go back and say, "Now let's make it earthquake proof." No,

134

you want to do that from start to finish all the way from design through completion.

135

So let's take a look at an IT example.

136

So when we have a project, you know, we will tend to start off with requirements stage.

137

We'll go then into design.

138

We'll code the thing, then we'll install whatever it is that we've written.

139

then we'll test it out and then we'll promote it to production.

140

And then in theory, we should feed that loop back and continue the continuous development process that way.

141

Well, what we don't want to do

142

is what too many people do in these cases and they wait until really about this phase to do security.

143

Once it's already out there, security can't just be a bolt on that you do at the end.

144

In fact, It needs to be something that we're doing throughout pervasively.

145

We look at the security aspects of the requirements, we build security into the design, We're thinking about secure coding principles all along the path.

146

When we install, we do it on a secure system.

147

We're testing and guarding that test data and then in production obviously we keep testing.

148

So security is something we do throughout But it doesn't begin here.

149

It begins in these phases.

150

That's what we're really looking for here.

151

Now if you think about another example, let's say Whose job is security?

152

Well, it's really everyone.

153

Here we have a designer, an administrator, and a user.

154

So really, all of them are responsible for security in one way or another.

155

But who does the job begin with?

156

Well, it begins with this guy right here.

157

We need to make sure that he is designing security in.

158

In other words, what we're trying to do is make security start to finish, And we want secure by design means it's secure out of the box.

159

That's the way we'd like it to be.

160

Now sometimes we're going to have to do some configuration changes to make it more secure, but This is the goal that we're trying to shoot for.

161

Secure by design, secure out of the box.

162

Our fifth security principle is the KISS principle.

163

It stands for Keep It Simple Stupid.

164

In other words, we don't want to make it harder than necessary

165

because that will make it easier for the bad guys and harder for the good guys.

166

To give you an example, we're trying to create some level of complexity so that it's not easy for the bad guy to get in.

167

But a lot of times the security department will create this complex maze of things

168

that the good guys essentially have to go through.

169

And what happens in that case is I start in here, okay, I log in, now I have to traverse and eventually I'm like,

170

"I'm at a dead end." Okay, maybe let's try this again.

171

You know what?

172

It's too much trouble to do what the security department has asked me to do.

173

I'm just going to subvert this and I'm going to end up doing it that way, which is of course not what we're after.

174

So the lesson here is if we make it harder to do the right thing than it is to do the

175

the wrong thing, People are going to do the wrong thing.

176

So we need to be able to make the system secure, but also as simple as possible.

177

So keep it simple stupid.

178

Here's an example of how we do this in security departments for real.

179

We'll come up with password rules.

180

So we'll say, "This is your password." and it equals this.

181

And it's this because we created a complex set of rules that say, you have to start with an upper case, then you follow with a lower case, then you need a special character,

182

then you need to throw in some numbers, and then you have to have some mixture of upper and lower case and special characters and all this kind of stuff, and it has to be really long.

183

And by the way, We need lots of these.

184

You're going to have a different one on every system and I'm going to make you change it on a frequent basis.

185

That's this.

186

That's what the user sees, is a complex maze.

187

And they're going to find a way to do this.

188

And what they're going to do is find one password

189

and write it down and set all their systems equal to the same thing, which is again, not what we were after.

190

So what we want to do is Understand complexity is the enemy of security.

191

So we want to make the system just complex enough to keep the bad guys out, but not so complex that it's hard for the good guys to do what they need to do.

192

For instance, you might have noticed, well, what about defense in depth, which I talked about up here?

193

There might be some conflict in that

194

because there we're trying to set a system of security mechanisms in place to put an obstacle course for the bad guy.

195

We want that obstacle course to be for the bad guy, not for the good guy.

196

All right, now we've gone over five security principles that you should always observe.

197

And now the big reveal the security principle you should never observe and that is security by obscurity.

198

that is relying on some sort of secret knowledge in order to make the system safe.

199

It turns out that secrecy and security are not the same thing.

200

In fact, what we want is a system that is open and observable

201

And this guy called Kirchhoff came up with what's now known as Kirchhoff's principle, which basically describes that.

202

He was specifically talking about a crypto system

203

and he said basically a crypto system should be secure if you know every single thing about it except for the key.

204

In other words, the key is the only secret in the whole system.

205

Now, why would this be an issue?

206

Well, it turns out a lot of people, and you should, whenever you hear this, you should run, not walk, but run away.

207

When you hear somebody say, I've invented a crypto system that's proprietary, and it will take your clear text, you feed it into my...

208

algorithm along with a key and then it will produce from clear text to ciphertext.

209

Okay, great.

210

The problem is this is a black box.

211

I can't see how it's working.

212

And if the individual says it's unbreakable, I've been hacking at it for weeks, months, years.

213

All that means is the inventor couldn't find a way to break it.

214

But that's not the same thing as the whole world given access would in fact break this.

215

And in fact, given time, they will, even if it is a black box.

216

History has shown that to be the case.

217

So what we want is not black box security, We want class box security.

218

So in this case, what we have is the clear text goes into a crypto algorithm which we understand.

219

It's been published.

220

In fact, if you look at the good crypto algorithms that we rely on today, it's things like AES, the Advanced Encryption Standard, and RSA.

221

These are algorithms that everyone that wants to know how they work can look it up and see.

222

And the secrecy, therefore the security, doesn't come from some secret knowledge of how this thing works.

223

It's able to produce ciphertext from cleartext without having to keep this part secret.

224

The only secret is the key and that's what we want.

225

We do the same kind of things when we talk about secure operating systems or secure applications or things like that,

226

as long as the security is based on secrecy, It's not really something that we can rely on.

227

Before you leave, don't forget to hit subscribe.

228

That way you won't miss the next installment of the Cybersecurity Architecture series.

הורד אפליקציה

כל מה שאתה צריך כדי לדבר בשטף

הגיית AIציון לכל משפט

תרגול IPAשלוט בכל צליל

אוצר מיליםבנה את מאגר המילים שלך

משחק אוצר מיליםלמד תוך כדי משחק

סרוק QR

Download on theApp Store Get it onGoogle Play

אותו ערוץ

FOR YOU

המלץ על סרטון

53 משפטים

Principles for Success: "The Call to Adventure" | Episode 1

Business EnglishUniversity StudentsWorking Adults

47 משפטים

The most interesting "hack" in history...

Business EnglishUniversity StudentsWorking Adults

231 משפטים

5 CSS fouls that I see way too often

Business EnglishUniversity StudentsWorking Adults

164 משפטים

System Design Mock Interview: Design Facebook Messenger

Business EnglishUniversity StudentsWorking Adults

34 משפטים

MITRE ATT&CK® Framework

Business EnglishUniversity StudentsWorking Adults

210 משפטים

What Software Architecture Should Look Like • Dave Farley • GOTO 2022

Business EnglishUniversity StudentsWorking Adults

130 משפטים

Password Storage Tier List: encryption, hashing, salting, bcrypt, and beyond

Business EnglishUniversity StudentsWorking Adults

51 משפטים

Cloud Models - CompTIA Network+ N10-009 - 1.3

Business EnglishUniversity StudentsWorking Adults

134 משפטים

From Zero to SOC Analyst: Complete Roadmap (2026)

Business EnglishUniversity StudentsWorking Adults

69 משפטים

Intellectual Property: Copyrights

Business EnglishUniversity StudentsWorking Adults

אוצר מילים והערות הגייה לשיעור הזה

שיעור הדיבור הזה ברמה C1 מבוסס על הסרטון “Cybersecurity Architecture: Five Principles to Follow”. המילים שחוזרות הכי הרבה: security, principle, secure. בסרטון הזה יש 228 משפטים ו-3227 מילים לתרגול Shadowing. הדיבור נמשך 17:30. הדובר מדבר מהר, כ-184 מילים בדקה, אז צפו לצלילים מחוברים ומקוצרים. 89% מהמילים נמצאות בין 3,000 המילים הנפוצות ביותר באנגלית; כדאי ללמוד את השאר לפני שמתחילים.

אוצר מילים מרכזי בסרטון הזה

15 המילים המתקדמות ביותר בסרטון, עם ההגייה והמשמעות שלהן:

מילה	הגייה	משמעות
algorithm שם עצם	/ˈælɡəɹɪðm̩/	אַלגוֹרִיתְם
password שם עצם	/ˈpæs.wɜɹd/	סִיסְמָה
obstacle שם עצם	/ˈɑbstəkəl/	מִכְשׁוֹל
collusion שם עצם	/kəˈluːʒən/	קנוניה
moat שם עצם	/moʊt/	חֲפִיר
maze שם עצם	/ˈmeɪz/	מָבוֹךְ, לָבִּירִינְת
complexity שם עצם	/kəmˈplɛk.sɪ.ti/	מורכבות
authorize פועל	/ˈɔθəɹaɪz/	הסמיך
encrypt פועל	/ɪnˈkɹɪpt/	הצפין
proprietary שם תואר	/pɹəˈpɹaɪ.ə.tə.ɹi/	קִנְיָנִי
reinforce פועל	/ˌɹiː.ɪnˈfɔːs/	חִזֵּק
illustrate פועל	/ˈɪl.əˌstɹeɪt/	הִמְחִישׁ
cooperate פועל	/kəʊˈɒp.ə.ɹeɪt/	שִׁתֵּף פְּעֻלָּה
tick שם עצם	/tɪk/	קַרְצִיָּה
vanilla שם עצם	/vəˈnɪl.ə/	וניל

Phrasal verbs שתשמעו

מילה	הגייה	משמעות
come back פועל		שָׁב
come out פועל	/ˌkʌm ˈaʊt/	יָצָא
run away פועל		בָּרַח

משפטים שכדאי לחזור עליהם

משפטים קצרים ושלמים מהסרטון שאפשר להשתמש בהם בשיחה יומיומית:

Let's get started with cybersecurity fundamentals.
We've got the thick tall walls.
We're trying to avoid single points of failure.
Let's say we've got a web server like this.
Let's make it something more specific.

דקדוק בסרטון הזה

המבנים שהדובר משתמש בהם הכי הרבה, עם המילים המדויקות מהסרטון:

מבנה	בסרטון
הווה מושלם (Present perfect) have/has + past participle — פעולה שקרתה בעבר ועדיין יש לה חשיבות או השפעה עכשיו	it's never been · I've done · we've written
סביל (Passive voice) be + past participle — הדגש הוא על מה שקורה, לא על מי שעושה את הפעולה	is protected · be applied · is based
משפטי זיקה (Relative clauses) who / which + clause — מידע נוסף על אדם או דבר	moat which is · server, which is · EDR, which is

הגייה ששווה לשים לב אליה

הדובר משתמש ב-91 קיצורים וצורות מקוצרות, כמו we're, I'm, don't. אמרו אותם בצורה הקצרה, כפי שאתם שומעים אותם.

הצלילים של “th”: algorithm /ˈælɡəɹɪðm̩/, afterthought /ˈæft.ɚ.θɔt/, authentication /ɔːˌθɛntɪˈkeɪʃn̩/, authorize /ˈɔθəɹaɪz/
הצלילים של “sh” ו-“zh”: configuration /kənˌfɪɡ.əˈɹeɪ̯.ʃən/, collusion /kəˈluːʒən/, authentication /ɔːˌθɛntɪˈkeɪʃn̩/, workstation /ˈwɝkˌsteɪʃən/, detection /dɪˈtɛk.ʃən/
מילים ארוכות — שימו לב להטעמה: cybersecurity /saɪbəsɪˈkjʊəɹɪtɪ/, capability /ˌkeɪ.pəˈbɪl.ɪ.ti/, administrator /ədˈmɪn.ɪ.stɹeɪ.tɚ/, vulnerability /ˌvʌln(ə)ɹəˈbɪlɪti/, configuration /kənˌfɪɡ.əˈɹeɪ̯.ʃən/

צלילים שדוברי עברית מתקשים בהם:

/w/ — שפתיים מעוגלות, לא /v/: password /ˈpæs.wɜɹd/, firewall /ˈfaɪ(ə)ɹˌwɔl/, workstation /ˈwɝkˌsteɪʃən/
/æ/ — פתוח יותר מה-“אֶ” העברית, לא כמו “a” ב-“cup”: algorithm /ˈælɡəɹɪðm̩/, password /ˈpæs.wɜɹd/, adjunct /ˈæd͡ʒ.ʌŋkt/, afterthought /ˈæft.ɚ.θɔt/, standpoint /ˈstændpɔɪnt/
/r/ — הלשון לא נוגעת בשום מקום, לא ה-“ר” הגרונית: cybersecurity /saɪbəsɪˈkjʊəɹɪtɪ/, crypto /ˈkɹɪptoʊ/, algorithm /ˈælɡəɹɪðm̩/, password /ˈpæs.wɜɹd/, administrator /ədˈmɪn.ɪ.stɹeɪ.tɚ/

איך לתרגל עם הסרטון הזה

הקשיבו לכל הסרטון פעם אחת בלי לדבר, ורשמו את המילים שאתם לא מכירים.
התחילו במהירות 0.75×, תרגלו Shadowing משפט אחר משפט, וחזרו למהירות רגילה כשזה מרגיש קל.
הקליטו את עצמכם והשוו למקור, תוך תשומת לב למילים כמו algorithm, password, obstacle.

מהי טכניקת השאדואינג?

שאדואינג היא טכניקת למידת שפה מבוססת מדע שפותחה במקור להכשרת מתורגמנים מקצועיים ופופולרית על ידי הפוליגלוט ד"ר אלכסנדר ארגואלס. השיטה פשוטה אך עוצמתית: אתה מקשיב לאודיו באנגלית ילידית וחוזר עליו בקול רם מיד — כמו צל העוקב אחרי הדובר עם עיכוב של 1–2 שניות בלבד. בניגוד להאזנה פסיבית או תרגילי דקדוק, שאדואינג מכריח את המוח והשרירים בפה לעבד ולשחזר דפוסי דיבור אמיתיים בו זמנית. מחקרים מראים שזה משפר משמעותית את דיוק ההגייה, האינטונציה, הקצב, הדיבור המחובר, הבנת השמיעה ושטף הדיבור — מה שהופך אותו לאחת השיטות היעילות ביותר להכנה לIELTS Speaking ולתקשורת באנגלית בעולם האמיתי.

טכניקת Shadowing: קרא את המדריך המלא שלב אחר שלב →

Shadowing Practice: Cybersecurity Architecture: Five Principles to Follow (and One to Avoid) - Learn English Speaking with Video

בחר מצב תרגול

הורד אפליקציה

Every Generation Thinks This Time Is Different: The AI Job Myth

What is Event Driven Architecture (EDA)?

Agentic AI Frameworks Explained: Workflows, Multi-Agent, & Production

Spec-Driven Development: AI Assisted Coding Explained

AI Agents vs Business Rules: Which Should Make Decisions?

AI & Education: Generative AI & the Future of Critical Thinking

EDR vs. EPP vs. NGAV

MCP vs ADK: How Modern AI Agents Connect and Work Together

Cybersecurity Architecture: Data Security

The 7 Skills You Need to Build AI Agents

What Is Jev? The AI Model That Doesn't Generate Text

How Smart Organizations Will Use AI: Jevons Paradox & Workforce Impact

What are AI Agents?

AI, Machine Learning, Deep Learning and Generative AI Explained

Zero Trust Explained in 4 mins

What is Responsible AI? A Guide to AI Governance

What is AI Ethics?

Principles for Success: "The Call to Adventure" | Episode 1

The most interesting "hack" in history...

5 CSS fouls that I see way too often

System Design Mock Interview: Design Facebook Messenger

MITRE ATT&CK® Framework

What Software Architecture Should Look Like • Dave Farley • GOTO 2022

Password Storage Tier List: encryption, hashing, salting, bcrypt, and beyond

Cloud Models - CompTIA Network+ N10-009 - 1.3

From Zero to SOC Analyst: Complete Roadmap (2026)

Intellectual Property: Copyrights

אוצר מילים והערות הגייה לשיעור הזה

אוצר מילים מרכזי בסרטון הזה

Phrasal verbs שתשמעו

משפטים שכדאי לחזור עליהם

דקדוק בסרטון הזה

הגייה ששווה לשים לב אליה

איך לתרגל עם הסרטון הזה

מהי טכניקת השאדואינג?