Reading Hackable Without a Background in Security

Reading Hackable Without a Background in Security

Summary

I’m new to security, and Hackable was a suggested read to understand the space. I thought it would be way over my head. But it turned out that the book is not only for seasoned pros; I could really grasp the concepts, too!

Here is my journey; I hope it helps other newbies or lesser technical readers.

Expectation

Application security is a topic that I didn’t think I would be able to understand, being that I do not have a background in technology, cybersecurity, or related fields. Prior to reading Hackable, I was very skeptical about my ability to comprehend the book’s contents as I expected it to be written with strong technical language that could only be understood by readers with coding knowledge and hacking expertise.

When I think of ethical hacking, or hacking a system in order to find its vulnerabilities, I immediately think the first thing to do is to find the virus that has infected the application, figure out a way to decode it and remove it, and then set the system back to the way it was originally running. I assumed Hackable would explain just that. I expected it to be a difficult read, diving deep into the technical instructions of how to fix system vulnerabilities with specific codes. I didn’t think I would be able to grasp any concept mentioned within the bestseller. I thought that maybe I would read it and reflect, and still have no idea what I had just read.

I decided to give it a try, be open-minded, and attempt to understand ethical hacking to the best of my ability. I thought that if I were to learn one thing from this read, it would be better than not reading the book at all. After reading Hackable from start to finish, I will proudly declare that I was able to grasp the general idea and best practices behind application security and how to do it right.

Reality

The introduction of the book clearly defines what the book is and what it is not. Author Ted Harrington states that Hackable is not a code-level technical deep dive, theoretical, or hard to read. Instead, it is filled with strategies and tactics, proven, and simple. This immediately made me more open to reading the publication because I realized that it was not written only for readers with a relative background to programming and cybersecurity; it was written for anyone interested in learning about application security, whether they have prior knowledge of the subject or not.

The first chapter addresses why one should always seek to improve on the security of their system. This includes learning how to think like a hacker, and then combining in-house experts with a security partner in order to heighten the effectiveness and efficiency of securing your vulnerabilities. As author Ted Harrington teaches readers how to think like a hacker, he uses numerous metaphors and analogies. This makes it easier for readers with zero cybersecurity knowledge like myself, to understand. Through learning to think like a hacker, I didn’t expect to be reading about how to exploit the system at a cocktail bar in order to avoid the cover charge. But, that analogy made the light bulb go off in my head. I then understood that the idea behind hacking a system doesn’t need to be technical at all. Whether they pertain to a web-based application, or something more simple such as a bar, a hacker is still a hacker. After gaining a better general idea of what a hacker is, I was able to understand the thought process behind one, and the mindset they must have in order to develop tricks and shortcuts to exploit any type of system.

Choosing the right assessment methodology:

Next, Harrington covers assessment methodologies. When thinking about testing your software, there are two types of assessment methodologies; white-box and black-box. I thought to myself, “Now is the time that the book gets slightly theoretical.” Software testing, white-box, and black-box all sounded like overwhelming terms that I wouldn’t be able to comprehend. Maybe the author, a cybersecurity guru, thought that these are concepts that the average person is familiar with? But after continuing the read, I found myself with a much deeper understanding of these assessment methodologies. This was due to an analogy used by the author that makes comparisons between testing your software and a medieval king testing his castle defenses and vulnerabilities that could allow for a break-in. I grasped these concepts well enough to be able to explain them here. Black-box testing attempts to model real situations, and therefore limits the information that one would give to their security partner. But attackers can access all of your information, so why not give it to your security partner as they try to hack your system? Failure to do this results in wasted time and money, essentially paying your partner to look for information that you could have provided. On the other hand, white-box testing allows you to teach your security partner about your business and your system. Your partner can then use that information to search for and determine your system’s vulnerabilities. This incurs less time, less money, and a more accurate testing result.

Following assessment methodologies, the book transitions into covering different areas of application security such as hacking your system, fixing vulnerabilities, spending wisely on a security partner, establishing a threat model, building security into your system, and how to gain a competitive advantage and turn it into sales. As I read through these chapters, many analogies were made in a successful effort to help non-tech readers, like myself, understand. Although I won’t cover each topic since I encourage you to read the book and grow your own understanding of application security, I will elaborate on one subject that I initially felt would be too technical for me to understand, even when written in its simplest terms.

What is a threat model?

Establishing a threat model. What does this mean? I had no clue, but it sounded intimidating. The author mentions his involvement in the annual Running of the Bulls event in Spain, and compares his experience and the threat from the bull potentially hurting him, to application security and the threats that can potentially harm a web system. A threat model can be developed for any system or situation, technical or not. There are three components to a threat model. These include assets that require protection, attackers that need to be defended against, and the attack surface that the attack will occur. The first step is to figure out who your attackers are by determining their motivations. Next, decide what your assets are that need protecting. Last, implement your threat model. This includes creating a list of assets, recognizing your biggest threats, and realizing your system’s weak points and areas that are easiest to be attacked. Once these components are identified, it’s time to share your findings with your team and security partner in order to act upon your threat model and better secure your system. I realized the concept behind a threat model wasn’t as threatening to learn as I had initially thought.

Would I have been able to explain a threat model in my own words prior to reading Hackable? Absolutely not. Although I briefly covered a few key topics that are discussed in more detail within Hackable, I highly recommend reading the book from start to finish. Whether you have strong technical knowledge of cyber security, or zero knowledge but a heavy interest in or desire to learn about ethical hacking, this will be an enjoyable read for you.

Get your copy at https://www.hackablebook.com/

Jenn Alberts is the Administrative & Marketing Assistant for Independent Security Evaluators, a firm of security specialists that provide a wide range of services including custom security assessments and software development. ISE also runs IoT Village, which hosts talks by expert security researchers who dissect real-world exploits and hacking contests consisting of off-the-shelf IoT devices.