Using the 1,000 Most Common Words to Explain Security Risks

Using the 1,000 Most Common Words to Explain Security Risks

Many employees in the tech industry are required to design secure systems even if they are not security professionals. I decided to conduct a communication experiment after being inspired by Randall Munroe, the author of the webcomic xkcd.

Munroe developed a comic and a book using only the 1,000 most regularly used English words to teach technical topics. The outcomes are both amusing and instructive. Some ideas are just as evident in simple language, while others become amusingly warped. “The vast flat rocks we live on,” for example, are tectonic plates. “The component of air that you need to breathe but not the other things” is oxygen.

As a security engineer, I decided to recreate the OWASP Top 10, a list of ten crucial information security problems, in this manner. (You may check if all of your terms are in the “top ten hundred” on Munroe’s xkcd website.) It started as a joke in our corporate Slack. It surpassed my wildest dreams in terms of popularity. So, to share them with you, the general public, I’ve attempted to clean them up a bit.

The end effect is… a bit of a mishmash. When I try to explain the OWASP Top 10 using the 1,000 (or ten hundred) most common English terms, this is what happens:

1. Injection. A bad guy can answer a computer’s questions with the exact phrases that the machine uses to direct itself. The bad guy can then program the computer to do bad things. 
2. Broken Authentication. If bad guys impersonate other people and nothing stops them, they can access and misuse other people’s information. 
3. You could be vulnerable to a hooded individual with their face hidden, leaning over a laptop, attempting to take data. 
4. Sensitive Data Exposure. If you don’t keep track of sensitive data that you don’t want others to know about, bad guys can take it and use it to harm others. A “wrongdoer”.
5. XML External Entities. Computers may store information about things in the form of words. An evil guy can tell the comments to point to bad words and have the computer do bad things if they point to outside things. 
6. Broken Access Control. If the computer recognizes me but does not prevent me from looking at other people’s stuff, I can steal or alter their data. 
7. Misconfiguration of security. Bad people can break into systems that have been set up incorrectly. 
8. Site-to-Site Scripting. Suppose a computer system saves the text that some users typed on one computer and then shows it to another computer. An evil person can instruct it to keep cruel phrases that cause awful things when other people’s computers view them.
9. Deserialization is insecure. A malicious person can use words to force the system to do bad things. You save the information as words and then have your computer convert it back to lead.
10. Vulnerable Components use. You could be in jeopardy if you obey other people’s computer instructions and evil guys figure out that those instructions allow them to do awful things. They could harm your computer.
11. Monitoring and logging are not enough. Unless you maintain a close eye on your computer system or tell it to log enough information about what it does, you won’t know if something terrible happens.

Because this is the internet, I feel required to add that I am not advocating that everyone write all their technical conversations in this simplified style.

Some of them work

I feel some of these will transfer well. It may appear entertaining and convey the concepts required to understand this security threat.

“Seeing other people’s information and doing horrible things” should not be possible. “Special information that people don’t want others to know about” must be protected. “Systems should prevent me from looking at other people’s material,” says one user. They should keep detailed records so that administrators would “know if something horrible happens” to them. These are all fundamental concepts in information security, so fundamental that we’ve coined names like authentication, sensitive data, access controls, and detection to describe them.

We may communicate rapidly on the underlying concepts we already understand and agree on using specialized words. Unfortunately, this terminology might be intimidating to people who aren’t as knowledgeable about security. It’s not just non-technical people unfamiliar with information security language; software engineers and system administrators with many years of experience are also at risk. That’s fine sometimes because everyone has areas in which they aren’t an expert. Security jargon might deter consumers from implementing essential security safeguards. When it comes to getting everyone on the same page about the necessity of following security best practices, they are more than capable.

You are under no obligation to warn others about “evil people.” Also, remind them to “keep a tight eye on their computer systems.” However, consider which words will make your audience feel the most welcome. Technical communication might become more approachable on occasion. It can also assist in using analogies or metaphors that your audience is familiar with and using more straightforward language. External definitions of terms you use in an online document can be linked. Alternatively, you might begin a presentation by providing brief descriptions of some of the main terms you’ll use during the presentation. (Having someone who isn’t as knowledgeable about the subject read your manuscript or listen to your practice presentation can assist!)

Some of them don’t

Some subjects are impossible to convey without technical jargon, or at the very least without phrases that are so specialized that they don’t appear in the top ten hundred. Consider the following example, which was one of my favorites to write:

External Entities in XML: Computers may store information about things in the form of words. An evil guy can say the words to point to bad words and have the computer do bad things if they point to outside things.

On only one side, figuring out what to do this made me think about the underlying security issue with XML. I know I meant “objects” when I said “things.” I meant “data in a defined text format” when I stated “words.” I also understand that “point to external words” refers to file references.

On the other hand, someone who can’t travel inside my thoughts and hunt up definitions for all of these phrases will find the result completely incomprehensible. “Words about things” obscures the meaning of “object” in object-oriented programming and the differences between serialization formats and human language. “A terrible guy can train them to point to harmful words”—what makes the phrases “bad,” and how is the bad guy “teaching” the seemingly harmless words to point to places they shouldn’t? What kind of evil could program into the computer? It’s an oversimplification even to address these questions. You don’t have a solid enough comprehension of what they’re trying to say to know where to start asking technical questions if you’re looking at sentences like this and attempting to figure out what they’re trying to convey beyond the entertainment value.

So reading these sentences and then proclaiming yourself an expert on XML External Entities and why they’re wrong is pointless. It’s forcing me to evaluate any assumptions I may have about how many of these threats I fully understand and look into the complexities I may have overlooked. I’m coming at the problem from a new angle.

It lets me notice details that I may have missed the first time around. Because it is so powerful, why is XML so appealing to application developers? When compared to other types of data serialization? What ways would an attacker use to take control of XML and execute malicious commands? How can we defend ourselves against them? Trying and failing to describe a subject more straightforwardly might sometimes reveal concepts you wouldn’t have thought of otherwise or drive you to discuss attack vectors more completely, which you assumed your audience already knew. However, this technique does not imply that it is a successful means of communicating such ideas to others.

How do we communicate?

There are numerous examples of people attempting to make technical subjects more understandable. Consider Julia Evans and Amy Wibowo of Bubblesort Zines. They create cartoons that clarify technical issues and projects like Simple English Wikipedia and programming tools like Scratch and Glitch.

Intentionally vulnerable applications, such as OWASP Juice Shop, help highlight security weaknesses. These apps are beneficial to students of all levels, assisting them in overcoming the barrier of technology that appears to be insurmountable. Many people who work in technology need to be able to design secure systems without being security experts when it comes to information security.

At the same time, there’s a danger of oversimplifying things. Reading the phrase “the computer [should] stop me from looking at other people’s stuff” is not the same as having the experience needed to implement access controls in a complex program. Furthermore, constructing a statement out of “simple” words does not always result in a sentence that is easier to comprehend; language does not operate that way.

You must be able to establish domain-specific terminology at the very least. First, those names were designed for a reason (“object” in object-oriented programming has a specific meaning, and translating it to “thing” does not convey the same meaning). Furthermore, repeating definitional phrases is tiresome and irritating.

It’s not easy to choose the right words to express an idea to people who need to understand it. One method that can help us think about it differently is to limit ourselves to the top ten hundred English words. Best practices can apply to everyone who uses or designs computer systems. In terms of information security, it must prevent evil persons from stealing their data. I believe we can all seek methods to improve our users’, developers’, and administrators’ understanding.

About Enteros

Enteros offers a patented database performance management SaaS platform. It proactively identifies root causes of complex business-impacting database scalability and performance issues across a growing number of RDBMS, NoSQL, and machine learning database platforms.