16,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Secure your applications with help from your favorite Jedi masters In Threats: What Every Engineer Should Learn From Star Wars, accomplished security expert and educator Adam Shostack delivers an easy-to-read and engaging discussion of security threats and how to develop secure systems. The book will prepare you to take on the Dark Side as you learn--in a structured and memorable way--about the threats to your systems. You'll move from thinking of security issues as clever one-offs and learn to see the patterns they follow. This book brings to light the burning questions software developers should be asking about securing systems, and answers them in a fun and entertaining way, incorporating cybersecurity lessons from the much-loved Star Wars series. You don't need to be fluent in over 6 million forms of exploitation to face these threats with the steely calm of a Jedi master. You'll also find: * Understandable and memorable introductions to the most important threats that every engineer should know * Straightforward software security frameworks that will help engineers bake security directly into their systems * Strategies to align large teams to achieve application security in today's fast-moving and agile world * Strategies attackers use, like tampering, to interfere with the integrity of applications and systems, and the kill chains that combine these threats into fully executed campaigns An indispensable resource for software developers and security engineers, Threats: What Every Engineer Should Learn From Star Wars belongs on the bookshelves of everyone delivering or operating technology: from engineers to executives responsible for shipping secure code.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 504
Veröffentlichungsjahr: 2023
Ähnliche
Table of Contents
Cover
Title Page
Preface
Introduction
Who This Book Is For
What You'll Gain from This Book
A Few Words for the Nonengineer
Security Terminology
How This Book Is Organized
Note
1 Spoofing and Authenticity
Identifiers and Authentication
Spoofing Attacks
Spoofing in Specific Scenarios
Mechanisms for Spoofing Attacks
Defenses
Conclusion
Note
2 Tampering and Integrity
Introduction
Targets of Tampering
Tampering in Specific Technologies
Mechanisms for Tampering
Defenses
Conclusion
Notes
3 Repudiation and Proof
Introduction
The Threat: Repudiation
Repudiation in Specific Technologies
Defenses
Conclusion
4 Information Disclosure and Confidentiality
Threats to Confidentiality
Information Disclosure Mechanisms
Information Disclosure with Specific Scenarios
Defenses
Conclusion
Notes
5 Denial of Service and Availability
Resources Consumed by Denial-of-Service Threats
Denial-of-Service Properties
Denial of Service in Specific Technologies
Defenses
Conclusion
6 Expansion of Authority and Isolation
Expansion Mechanisms and Effects
Authority in Specific Scenarios
Defenses
Authority and Privilege
Conclusion
Notes
7 Predictability and Randomness
Predictability Threats
Time and Timing Threats
Predictability in Specific Scenarios
Defenses
Conclusion
Note
8 Parsing and Corruption
What Is Parsing?
Threats to Parsers
Specific Parsing Scenario Threats
Defenses
Conclusion
Notes
9 Kill Chains
Threats: Kill Chains
Kill Chains for Specific Scenarios
History
Defenses
Conclusion
Epilogue
Glossary
Bibliography
Story Index
Episode I: The Phantom Menace
Episode III: Revenge of the Sith
Obi-Wan
(Television Series)
Rogue One
Star Wars: A New Hope
The Empire Strikes Back
Return of the Jedi
Index
Copyright
Dedication
About the Authors
Acknowledgments
End User License Agreement
List of Tables
Chapter 1
TABLE 1.1 Actions and Threats
Chapter 6
TABLE 6.1 Common Authority Expansions
TABLE 6.2 Authority in a Cloud System
Chapter 7
TABLE 7.1 Passwords and Salts
Chapter 8
TABLE 8.1 Sanitization Rule Results
Chapter 9
TABLE 9.1 The Four Defensive Scenarios
List of Illustrations
Chapter 1
FIGURE 1.1 Ways of authenticating
FIGURE 1.2 Difficulty of authenticating
FIGURE 1.3 A simple model of communication
FIGURE 1.4 Many connections to support a request
FIGURE 1.5 Packet encapsulation, hops
FIGURE 1.6 Spoofing Yoda
Chapter 2
FIGURE 2.1 Channels and messages
Chapter 6
FIGURE 6.1 Authority levels
FIGURE 6.2 Authority grants
FIGURE 6.3 Major qmail processes
FIGURE 6.4 A file picker architecture
Chapter 9
FIGURE 9.1 Network listening daemon (server) kill chain
FIGURE 9.2 Client software kill chain (excerpt)
FIGURE 9.3 Messaging kill chain
FIGURE 9.4 Chains assembled into a tree
FIGURE 9.5 Adam's “sandcrawler” model
FIGURE 9.6 Account takeover chain
FIGURE 9.7 An attack tree
Guide
Cover
Table of Contents
Title Page
Copyright
Dedication
About the Authors
Acknowledgments
Preface
Introduction
Begin Reading
Epilogue
Glossary
Bibliography
Story Index
Index
End User License Agreement
Pages
i
xi
xii
xiii
xiv
xv
xvi
xvii
xviii
xix
xx
xxi
xxii
xxiii
xxiv
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
291
292
293
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
323
324
325
326
327
ii
iii
iv
v
vi
vii
328
THREATS
What Every Engineer Should Learn from Star Wars
Adam Shostack
Preface
How does R2-D2 know who Ben Kenobi is? How does he decide to play the recording of Princess Leia for Ben, but not Luke? How does Princess Leia tell R2 her intentions? These three questions touch on fundamental issues of security: authentication, authorization, and usability. (Star Wars geeks have an answer to the first from the prequels, but Leia does not know that answer.) What's more, the way the world of Star Wars engages with technology and computers gives us a familiar base from which to learn about how technology works in our world.
I was a Star Wars fan before I ever wrote a line of code and long before I broke my first system. As I became an expert in computer security, it became clear to me that we in the field are much better at code than with stories, and while it's tempting to say “That is why you fail,” telling better stories is not our only hope. As I reflected on Star Wars, I realized that as the crawl fades, the camera descends onto Princess Leia's ship being pursued over…a stolen data tape! I realized Star Wars is not only the story of Luke's hero's journey and growth into adulthood but also a story of information disclosure and its consequences. Over the last decade, I've used Star Wars to tell the story of computer security because the epic stories give us reference points and illustrations of important issues.
In this book, almost every reference is to the original trilogy. There is material I could use in Rogue One, in the prequels and sequels, and in the TV shows, the books, and more. But I'll assume that most readers have only watched and rewatched the core three: Star Wars, Empire, and Jedi.
Like the Force is a property of all living things, security is a property of all technological systems. And like the Force has a light side and a dark side, security has defenses and attacks. This book is focused primarily on the attacks, the threats, the problems. You need to understand the threats to select appropriate defenses. It's dramatic to watch the Emperor unleash purple force lightning on Luke Skywalker, but better training could have alerted Luke to the threat and how to defend against it. Neither a firewall nor a checklist will block force lightning.
If you want to make a home secure, you need to think through the many things that might go wrong. Some are natural (floods), some can be natural or manmade (fire), and some (theft) are the acts of intelligent beings.
We have implicit models of what a home is, the types of homes, and the common types of problems. Those problems vary somewhat: the central plain of the United States has tornados, southeast Asia has monsoons, and the Middle East has sandstorms. But you can go to your insurer and get a list. (It's split across “optional coverage” and “exclusions.”)
Our implicit models of how technical systems are set up are weaker. Technology has more variety and more rapid change than our homes or office buildings. Three-tier architectures are unlike microservices. Microservice cloud deployments differ from the virtual machines deployed a mere decade ago.
Technological builders and defenders have a disadvantage: it's hard to get away from thinking about making the system work. We all know it's hard to make a system work. That there are trade-offs and compromises made to get the code to work, to get it to customers, and even to deploy it.
Security's traditional response to this has been an exhortation to “Think like an attacker!” That's hard. In response I encourage people to think like a professional chef, planning for hundreds of diners to sit down tonight. Most of us wouldn't know where to start. But we don't have to “think like an attacker” to get different perspectives on the systems we're working on.
Security also differs from other potential problems because we have intelligent attackers who can learn and adapt. If we think about a person wanting to steal your stereo, then they can come through the front door in many ways: they can kick it in, jimmy the latch, pick the lock, or steal a key. Some attacks exploit vulnerabilities: the lock has a weak front plate that's easily drilled because of a defect in the casting. Some exploit design flaws: the lock has only a few pins, making it easy to pick. They can bypass our defense, walking over to a window. And in technological systems, the range of attacks seems endless and perhaps unknowable—a problem this book solves.
One of the reasons that we fail at making secure systems is attackers have a great many advantages. They can study their target, plan their attacks, and launch them only when they feel confident. They can do what they will to take control of a system, make it misbehave, or embarrass its creator. And some of what attackers do is really very clever, and all of it is unexpected. That's tremendously important. In a great little video The Death Star Architect Speaks Out, the architect says, “The shot was literally not possible unless you had magic powers. Maybe if someone would have told me to account for space wizards when designing the exhaust ports, we would still have a Death Star!”
He has a good point. Too often, security researchers get publicity for taking a completed system and pointing out flaws…like engineers not knowing a torpedo could fly through miles of piping without turbulence deflecting it. It can feel like security experts are judging you and answering every question by rolling their eyes and saying “Search your feelings.” This book focuses on the important threats.
Security expert and author Bruce Schneier once wrote, “When I visited the National Security Agency, I asked to see the ‘big book of attacks.’ They told me there's no single place where it's all written down.” This book aims to fix that. It's important because understanding “the attacks” is easier if there is a defined set of “the attacks.” This is not an attempt to categorize every attack or to be comprehensive. That last is probably surprising and may even worry you. But the reality is that security issues are violations of security requirements. The requirements for different systems are different. Should I include violations of the requirements for nuclear bombs or currency printing? (“Fewer than two people can activate the system” or “Another customer can obtain the same paper stock.”) Completeness would obscure the more common attacks and make it hard to quickly reference threats that may inspire and enable you to reason by analogy and discover attacks on your own systems. Understanding the threats is the crux, and until now they've been hard to understand.
Someone else wrote “All interesting systems surprise their creator.” That's the property that takes them from useful to interesting. And security issues are often issues of surprise. They rely not only on mistakes in what's there, but in the failure of architects to develop defenses.
Human attention is a harsh master. It is hard to perceive what is missing. My intent in cataloging common issues is to say: these matter. These must be considered and, by collecting, organizing, and presenting them, provide some clarity about what is in the set of things “you must consider.” If what's in this book is ignored, maybe it's reasonable to claim that is a failure of the engineer. That's not to say “You can ignore anything else.” Just as a pilot must land the plane beyond the checklist or a surgeon must treat the patient, what must be addressed is not limited to what's in the pages of this book.
Human attention is really a harsh master. Daniel Kahneman is a Nobel Prize–winning founder of behavioral economics. In his lovely book, Thinking Fast and Slow, he uses only a single acronym: WYSIATI. What You See Is All There Is. The importance of what's in front of you is so great, it crowds out our efforts to “remain aware” and to “keep in mind.” Yet as an engineer you must do exactly that—keep in mind reliability, performance, usability, maintainability, and a great many other properties. We have many tools for managing such things, including automation, checklists, and the judgment of diverse teams.
For this book, I am making a design trade-off and assuming that defenses are known and understood, or at least understandable once you understand the threats. So I focus on the threats and touch briefly on the defenses. That's a conscious trade-off to make the book shorter and more approachable.
Introduction
My students teach me so much. As I hear the questions they ask and read the assignments they submit, I learn where they face challenges in securing their systems. I learned about threats over a decades-long career, from a few wise teachers and from many mistakes. As I mention in the acknowledgments, this book really was catalyzed by a simple question: “Where do I go to learn about the threats?”
A bit like “There's good in him, I've felt it,” I've felt that question in so many conversations. The word security subsumes a great deal of complexity and nuance. I was going to say we tend to learn about threats by osmosis, but that's not true. We tend to learn about threats when something blows up. Even when that something is smaller than a Death Star, the lessons are often traumatic, sometimes career-changing. Tragedy is a bad teacher.
If we want to be systematic in our search for threats to our products, we must be structured in how we learn and teach about those threats.
Who This Book Is For
This book is for every engineer.
It will be most useful to those who build or operate complex software-rich systems. There are hard trade-offs in engineering, which are made harder when security goals are obscure or vague. The book is focused on systems that incorporate code, but these days, what doesn't? Engineers who work in more traditional parts of the field (aerospace, chemical, civil, mechanical) are finding that these more elegant systems from a more mechanical time are being supplanted. Your systems must now interface with code, and you must address its security properties.
Over the last few decades, the job of software development and systems operation has changed. We've learned that our hopes of retrofitting properties from accessibility to reliability to usability have cost us dearly and that we need to incorporate each from the start. We are learning that security is much the same way. Choices made during system development have consequences. We see the need to address security earlier and more holistically.
This book is also for security professionals and enthusiasts. There are many pathways into many fields focused on security and hacking. Few of them provide a broad framework that will serve to organize the flood of information about threats, vulnerabilities, and exploits that you'll encounter. My hope is that this book serves all of them.
This book is for every engineer, even if they're not a science-fiction fan, and if you are, whatever world you love. As I spoke about this book, Star Trek fans came out of the nebulas to ask “Why?” And I love Trek. I love the optimistic view of the future, how the series reveres competence and science, and the writing and character development. I turned in the manuscript with the dedication: “to boldly secure what no one has secured before,” as an attempt at a loving homage. My team told me that it was too jarring for the opening, and they were right.
What You'll Gain from This Book
Security.
More specifically, you'll gain the understanding of security in ways that enables you to build and operate systems that perform despite the efforts of adversaries. Much like understanding force (the mass times acceleration kind) allows us to think about many different parts of the world and bring it to bear on our projects, this book provides you with an enduring framework to anticipate threats.
It's traditional to include a breathless list of security flaws here, in the hopes of motivating readers. It hasn't seemed to work, so I'm not going to bother. In 2023, the issue with security is no longer why. It's what and how.
A Few Words for the Nonengineer
This book is written for engineers: people who build or operate complex technical systems, especially the algorithms, chips, sensors, and actuator parts of those systems. It's written to be as clear as reasonably possible, and if you're a nontechnologist looking for advice, I want to include the three things you should do.
First, turn on automatic update on everything, most especially devices, operating systems, and web browsers. The updates that engineers ship often address security problems that can be exploited automatically. If your vendor mixes functionality changes with security fixes, complain loudly. But this step is a crucial defense against those exploitable problems.
Second, use a password manager, and have it create long, random passwords for you. One of the ways security fails is when websites leak your email address and password. Attackers gather and trade those lists, and they test the combinations on every website they can. They also test variants. They know that my Amazon password might be “adamamazon” or “amazonas1?” and computers are very good at testing those sorts of combinations, along with amazon-feb and the others you've thought of. Use a long, random password. If I expect I'll need to type it in regularly, I'll use the feature that gives me three or four random words as a password. By the way, I use 1Password from Agilebits as my password manager and recommend it. (We have no business relationship.)
Third, trust your feelings. If you feel a website isn't safe, leave. Find the company by searching or with a bookmark. If you think an email is suspicious, call the person or entity that claimed to have sent it. Use the number on the back of your card to call your bank. In each of these cases, you're taking control, and you're using resources that an attacker can't influence.
Maybe an attacker can replace the card in your wallet, and if you have attackers like that, seek professional help. I'm not saying that sarcastically. If you're up against a spy agency who will spend the time and energy to create a card and put it in your wallet, this advice isn't going to save you.
Two more optional steps if you want extra safety. First, craft special email addresses for special relationships. Set up something like [email protected] and use it for either one bank or all your banks. This protects you if an attacker takes over your main email account, and it helps you sort out phishing emails. If you only use that for your bank, then any mail from “your bank” in your main account is automatically suspicious. See above about trusting your feelings.
Lastly, I use a different browser and browser profile for online banking. Browser software is pretty solid these days, but with all the attacks, I feel more comfortable having a low-use browser for that. (These days, one is Firefox, the other is Chrome. At other times, it was two different Firefox profiles, with two dramatically different visual themes.)
That's it. That's my advice. Thank you for buying this book. You're welcome to read it or pass it on to a technologist or budding technologist who you know. Either way, I'm going to assume a technical reader, so we start speaking the binary languages that underpin both a galaxy far, far away and our own world.
Let me draw your attention to a principle that underlies the advice: isolation. A password manager isolates sites from each other, as does using two email accounts or two browsers. Leaving a site or calling your bank leaves the locus of an attack. That isolation, separating parts of a system from each other, is also the reason we have different computer accounts, firewalls, and a host of other defensive techniques.
Of course, each layer of isolation comes at a cost of convenience. Not allowing software to seamlessly work together means you have to do the things that make them work together, because that way attackers have to trick you into doing those things.
This advice is sadly not the advice you'll get from everyone. We lack information on the root causes and history of incidents that would help us prioritize, which is a problem I write about elsewhere and don't dwell on much in this book.1
Security Terminology
This book is about threats. We all know a threat when we hear one—“Give me your money, or else!” “I have altered the terms of the deal. Pray I do not alter them…any further.” I use threat to mean a future problem and one that can often be averted if we take preventative action.
Security folks use the word threat in a variety of ways. We call an attacker a threat, or sometimes a threat agent. The anti-malware part of the industry calls each virus or bit of malware a threat.
Carrying out a threat is an attack. Each of the threat, its manifestation, and its impact can be a concern. The law considers a credible threat as assault; the act of hitting someone is the battery in “assault and battery.” These can result in injury. In cybersecurity, we often worry about both the threat and its result. If someone breaks in by spoofing a legitimate user, they can quickly chain other threats, such as tampering or information disclosure. Especially as you are learning, being specific about the relationship between mechanism and impact can be helpful. A risk is the quantified refinement of a threat, and those quantifications often involve probability of success and the magnitude of the impact in dollars or lives.
An attacker uses an exploit to take advantage of a vulnerability. An exploit (as a noun) is a bit of software that allows its user to do something that the system owner would like to prevent. To exploit (as a verb) is to use that software against a target. A vulnerability is either a specific code issue (a bug), a flaw where design requirements have been overlooked, or the result of a trade-off made by designers or operators. Sometimes specificity helps with clarity; other times it descends into pedantry.
The word trust is used a lot in computer security and can be trusted to trip up the unwary. In normal English, trust means “a firm belief in someone's reliability, honesty, or ability.” Trustworthy means someone who lives up to that trust. In computer security, trusted means something with the ability to break your security. Cambridge University professor Ross Anderson provides an example: “The spy caught selling secrets was trusted but not trustworthy.” Others have pointed out that the word is often used in a passive or Orwellian voice. A “trusted system” fails to specify who trusts it. The Galactic Empire often labeled systems as “trusted” to bypass any discussion of their impact on the people it touches.
Aphorisms
There are a few bits of pithy wisdom I'd like to share because they can broadly inform your work as it touches on security.
“Attacks only get better; they never get worse.” Bruce Schneier attributes this as a saying at the American National Security Agency (NSA). While defenses do get deployed, the lesson of an attack is never lost. The tools developed to execute it don't go away. They're honed and refined.
“Theories of security come from theories of insecurity,” said Rick Proto of the NSA. Those attacks get better, and the collection of attacks inform how we think about what security is.
“All models are wrong; some models are useful.” British statistician George Box said this.
“Computer security is perverse. When you want something to be difficult, it's easy, and when you want it to be easy, it's hard.” (Me.) Consider file deletion. When you want to make a file really disappear, it's difficult, and when you want to recover it, it is surprisingly hard. It's hard to really make a file disappear because deletion usually just removes the pointers within the file system. If you try to overwrite the bits on a magnetic disk, it turns out that the physical records on the disk vary in size and so can be read after overwriting. And flash drives make it tough to ever write to the same locations. Similarly, randomness is easy to find when you want predictability. Computers seem unpredictable and heisenbugs are common, but just try writing a safe random number generator.
“Attackers will spend their budget how they want, not how you hope.” (Me again.) You may hope that attackers will behave in very specific ways, but then they wouldn't be attackers.
“Security is a systems property.” It's unclear who first said this. This is a true claim, and what it means is that system security is often limited by weak links. This book helps you remove the obviously weak links.
“Shipping is a feature.” This is a common saying at Microsoft. All the new features that have been built do no good until they're being used by your customers, so delaying to add a few more is often unwise. Similarly, delaying delivery in the hopes of achieving perfect security means no one can use your new features. I'm making that same call in shipping this book now: I hope its virtues outweigh its flaws.
“The devil is in the details.” Whoever said this wasn't thinking of security, but they could well have been. A great many things turn out to be less secure as one delves in, and security experts have great respect for talented reverse engineers who pry systems apart to understand their inner workings and in doing so discover unexpected properties of the system.
How This Book Is Organized
This book starts with STRIDE, a classic way of thinking about threats. STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Expansion of Authority. STRIDE is a mnemonic that helps us remember six major groups of threats, covered in the first six chapters. Those are followed by chapters on predictability, parsing, and kill chains.
Most chapters in this book follow the same general plan: start with an explanation of the threat, then how it manifests in specific technologies, the mechanisms that attackers use, and finally a short section on defenses.
There are many organizational choices to make writing a book like this. I grappled with the different ways computing now works and the way various threats impact them. Those ways include the Internet of Things, mobile, the cloud, and AI/ML. The specifics in these sections are in addition to the broader points made in the chapter, not a replacement for them—the fact that a computer has the shape of an internet of things teddy bear doesn't mean the rest of the chapter doesn't apply. A few of these sections in other chapters have additional sections because the nature of the threat has interesting properties in a specific scenario that's worth discussing.
The sole emergent technology not treated in this way is quantum computing. Most of the STRIDE threats will work on the systems that surround a quantum core, and probably work on that core. For example, the power draw of the mirrors in quantum cryptography leads to important information disclosure attacks. (Quantum crypto uses spin information to distribute cryptographic key information in ways that are hard to eavesdrop on, often relying on fiber between sites. It is very different from the use of quantum mechanics for computing.) The primary early impact of quantum computing seems to be breaking most classical asymmetric cryptography by discovering the keys, an information disclosure threat. If you're curious about quantum, Law and Policy for the Quantum Age (Hoofnagle and Garfinkel, 2021) is an excellent primer.
Another crucial organizational choice is to revisit threats. I've learned from teaching the first time someone encounters some information, it may not sink in. Coming back to it from a different angle often helps.
Style and Conventions
Many organizations and products are named. Product names are used to make examples concrete, and no malice is meant toward the creator or trademark owner. The passe convention of including a “for example” with each one wastes the time of most readers for the possible benefit of a few particularly literal-minded ones, who might be confused however many clarifiers are included.
A Few Words from a Jedi Master
Yoda:…a Jedi's strength flows from the Force. But beware of the Dark Side. Anger, fear, aggression; the Dark Side of the Force are they. Easily they flow, quick to join you in a fight. If once you start down the dark path, forever will it dominate your destiny, consume you it will, as it did Obi-Wan's apprentice.
Luke: Vader…Is the Dark Side stronger?
Yoda: No, no, no. Quicker, easier, more seductive.
Luke: But how am I to know the good side from the bad?
Yoda: You will know…when you are calm, at peace, passive. A Jedi uses the Force for knowledge and defense,
never
for attack.
The dark path is the path of ignoring security. Easily, the code flows. But once you start down that path, forever will it dominate your destiny. The easy choice is to ignore security and focus entirely on features that are more visible to customers. Modern languages make complete static analysis feasible by constraining some of the seductive power of pointers. There's a cost: the dark side of C is faster code, but forever will it dominate your security advisories. And 20 years ago, when security mattered less, that was a choice many companies made, often thoughtlessly. It was the choice that Microsoft made in its heyday.
But Yoda was right: “Consume you it will.” I worked at Microsoft for most of a decade, and I have tremendous respect for my colleagues who have been bolting security onto Office and Windows and replacing parts of their guts. They have achieved far more than I would have thought possible. But the very different innards of IoS and ChromeOS allow those competitors to move faster today.
Lastly, there is a security career path open to you, a path of attack. It's flashy. It's powerful: “Let me show you how I can pwn your system.” And if you want to follow that path, my only request is that you do so ethically, using your skills and knowledge to conduct authorized attacks to build stronger defenses. My own path started with vulnerability discovery but lately has been focused on delivering stronger systems. It's a harder path, but the impact long term can be much greater.
Note
1
You can find more on that at
shostack.org/resources/lessons
.
