Sharks in the Moat
Page 2
Figure 53: Types of Electronic Social Engineering
Figure 54: Unnormalized Form
Figure 55: First Normal Form (1NF)
Figure 56: Second Normal Form (2NF)
Figure 57: SalesReps table
Figure 58: Third Normal Form (3NF)
Figure 59: Union Table
Figure 60: Computer Architecture
Figure 61: Memory Layout
Figure 62: How the CPU Executes Instructions
Figure 63: LIFO
Figure 64: Programming Language Levels
Figure 65: The Build Process
Figure 66: Types of Linking
Figure 67: Types of Languages
Figure 68: Integer data type sizes and ranges
Figure 69: A Widening Conversion
Figure 70: A Narrowing Conversion
Figure 71: Conversion of data types without loss
Figure 72: Java Virtual Machine Activities
Figure 73: How an Overflow Canary Works
Figure 74: The Relationship Between Cohesiveness, Coupling and Quality
Figure 75: The OWASP Top 10
Figure 76: The CWE/SANS Top 25 Most Dangerous Programming Errors
Figure 77: CWE Top 25 - Insecure interaction between components
Figure 78: CWE Top 25 - Risky resource management
Figure 79:CWE Top 25 - Porous defenses
Figure 80: The Four Categories of Development Vulnerabilities
Figure 81: Client-side Session Token Storage Possibilities
Figure 82: Man-in-the-Middle Attack
Figure 83: Improper and correct encryption of connection strings
Figure 84: Example of Tokenization
Figure 85: LDAP Character Escaping
Figure 86: The Samy Virus
Figure 87: CSRF Attack Requiring No User Action
Figure 88: The Result of Not Encrypting a Path End-to-End
Figure 89: Examples of leaving too much information in commented code
Figure 90: The Result of an Unhandled Exception (credit troyhunt.com)
Figure 91: Declarative Code Access Security
Figure 92: Imperative Code Access Security
Figure 93: Declarative vs. Imperative Security Syntax
Figure 94: CAS in Action
Figure 95: Banned and Acceptable Algorithms
Figure 96: Threat Modeling Phases
Figure 97: Data Access Control Matrix
Figure 98: A Data Flow Diagram
Figure 99: Using an Attack Tree to Model the Attacker's Objective
Figure 100: Using an Attack Tree to Model the Type of Attack
Figure 101: STRIDE Categories
Figure 102: DREAD Categories
Figure 103: Average Ranking Example
Figure 104: P x I Example
Figure 105: Threat Documentation
Figure 106: Sample Data Classification Labeling Scheme
Figure 107: Characteristics of CMMI Maturity Levels
Figure 108: Operating System Architecture
Figure 109: TCSE Criteria
Figure 110: Enterprise Service Bus
Figure 111: Virtualization
Figure 112: Cloud Computing Deployment Models
Figure 113: Classic Architecture vs. Cloud Computing
Figure 114: 'as a Service' Offerings
Figure 115: Cloud Computing Risk Map
Figure 116: The IDM Life Cycle
Figure 117: Software Lifecycle Stakeholders
Figure 118: Quality Assurance Attributes
Figure 119: Testing Artifacts
Figure 120: Software Quality Assurance Testing Types
Figure 121: Software Defects
Figure 122: Defect Categorization (Types)
Figure 123: An Example Defect Life Cycle
Figure 124: Corrective Actions
Figure 125: Various Deployment Environments
Figure 126: Security Testing Tools
Figure 127: PNE Techniques
Figure 128: The Policy Decomposition Process
Figure 129: Data Classification Labeling
Figure 130: Example of Use & Misuse Cases
Figure 131: Software Acceptance Considerations
Figure 132: Typical Types of Documentation
Figure 133: Verification and Validation Activities
Figure 134: Security Standard Categories
Figure 135: PCI DSS Requirements
Figure 136: Risk Mitigation Action Points
Figure 137: White Box Security Testing Flow
Figure 138: White Box Testing Vs. Black Box Testing
Figure 139: Motives, Opportunities, and Means
Figure 140: Banner Grabbing a Web Server Version
Figure 141: Example of a Vulnerability Scan Report
Figure 142: Penetration Testing Steps
Figure 143: Software-Related Intellectual Property
Figure 144: License Types
Figure 145: IDS Components
Figure 146: Distracting the Bad Guy
Figure 147: Data Leakage Protection
Figure 148: Anti-Malware Engine Components
Figure 149: Risk Acceptance Template Elements
Figure 150: Business Continuity Concept Summary
Figure 151: The Relationship Between BIA, BCP and DRP
Figure 152: Forward Locking
Figure 153: How DRM Works
Figure 154: A Supply Chain
Figure 155: Acquisition Models
Figure 156: Software Supply Chain Staircase
Figure 157: Software Supply Chain Risk Management Goals
Figure 158: Potential Software Supply Chain Paths
Figure 159: Supply Chain Components
Figure 160: Supply Chain Threats
Figure 161: SCRM Steps
Figure 162: Protecting the Supply Chain
Figure 163: Supply Chain Phases
Figure 164: Software Supply Chain Risk Management Processes
Figure 165: Types of Relationships Between Acquirer and Supplier
Figure 166: Requirements and SLAs
Figure 167: SLA Metric Categories and Coverage
Figure 168: Acceptance Steps
Figure 169: Code Escrow
Figure 170: Code Escrow Validation
Figure 171: Operational Readiness Review Components
Figure 172: Post-Deployment Activities
About This Book
This book is divided into four sections:
Castle Warfare, which takes an entertaining trip back in time to see how medieval castle-dwellers defended themselves against well-armed invaders. This section introduces most of the security concepts covered in this book through the eyes of middle-age combat, including moat sharks!
Core Security Concepts, which covers security basics and sets the stage for the next section.
Secure Software Development, which introduces the 12 roles involved in the software development world as it relates to security. Under each role, we will discuss the various duties and responsibilities that role must deliver for us to achieve secure software.
Secure Supply Chain Management, which is focused on delivering secure software when it is partially or wholly outsourced to external contractors. It is a rare company that does not use contractors in some capacity, so this is a must-read section.
I have used several formatting conventions in this book to help you make sense of the content.
This is normal text.
This is a crucial word that helps make the text make sense.
This is a definition you should try and remember.
This is a topic that a previous sentence promised to cover.
This is a previously-mentioned topic AND a definition you should try and remember.
Introduction
What Exactly is a ‘Moat Shark’?
It’s amazing how the technology of the medieval ages – built primarily with wood and stone – mirrors our modern struggles to keep hackers out of networks and databases
. Could it be that we could learn a thing or two from our ancestors from centuries ago? After researching castle warfare at-length, my answer is a resounding ‘YES!’ Not only do defensive measures line up with modern tactics, the ways in which attackers attempted to penetrate deep into the heart of a castle closely reflects the latest attempts at identify theft, ransomware and back doors. Just as hackers increase the sophistication of each attack, and in response we must deploy new technologies to defeat them, castle builders faced the exact same problem as newer technologies emerged such as better siege engines and the introduction of gunpowder. Most of us believe that encryption technologies, such as TLS, are a modern invention, but the truth is that cryptography started many millennia ago and medieval residents employed it with great success, albeit in a much weaker form. After all, it’s pretty hard to construct a proper computer out of wood and stone! Nevertheless, there is a great deal of alignment between the threats and countermeasures deployed over a millennium ago and today’s world that is wholly dependent on the big, bad Internet.
The premise of this book is two-fold:
1) To illustrate how the bulk of contemporary struggles have already been faced by our ancestors and gain some insight into how to protect our own modern valuables.
2) Discuss the dizzying array of options available to us in terms of securing data, systems and networks, and show how to implement each.
In truth, I was surprised to discover the close alignment between our 21st century approaches to defense and how the castle owners of England and France protected their kingdoms. But, there are certain areas of castle attack and defense in which there is no corollary (yet) with modern technologies, and it is within those areas that we perhaps can learn a lesson or two from our distant relatives. Of course, the reverse is true as well – we citizens of the 21st century have access to technology that medieval warriors could not possibly have dreamed of. Imagine an invading army attempting to cross a watery moat, only to be devoured by a pack of ravenous sharks. The idea of ‘moat sharks’ would have been so far out of line with reality as medieval soldiers understood it, that it would represent a fusion of the mundane and the impossible. Yet, that is exactly where we currently live in the modern, always-connected world – facing impossible threats from hackers on a daily basis, and we are expected to somehow keep our data and systems safe. In short, we in the software development world have to continuously invent and deploy new moat sharks as quickly as hackers can get around the old ones. If we can surprise a hacker who encounters a moat shark of our own device, then we deserve a huge pat on the back. How to roll out these lurking sharks is the whole point of this book.
In the first section of this book, we’re going to explore castle construction and how warfare was carried out in the medieval ages. Beyond being a fascinating subject, this approach provides a natural way to understand modern network and software defenses and how best to apply current security controls. As we discuss ancient warfare tactics, I will immediately show you how it applies to modern approaches along with best practices to combat the latest threats.
But before we start, there are a few things we need to discuss…
What Does ‘Secure Software’ Mean?
The phrase ‘secure software’ means different things to various people. If you are a developer, then code snippets might start dancing around in your head. If you are an architect, visions of design patterns and technology platforms will probably begin to form. For product people, aligning to various security standards might come to mind, while infrastructure folks start dreaming of patches and intrusion detection systems.
The real answer is that all of those responses are correct – from each person’s point of view. Making software secure requires good code, implementing the right standards, hardening infrastructure and employing the best enterprise security patterns, plus a whole lot more. Slinging good code is just a part of the puzzle, albeit a major part.
So, what will this book do for you?
It will teach you how to document, design, implement, test, deploy, maintain and retire software in a secure manner.
In fact, it breaks content up into 12 different areas, because that is how many different roles are required to come together to roll out secure software.
Who Is the Typical Attacker?
Let’s explore the statistical attributes of your average attacker – after all, the better you understand your opponent, the better equipped you will be to defeat them. Of course, I have a hidden agenda to this conversation that I will reveal at the end of this discussion.
In 2016 a fairly exhaustive effort was carried out by HackerOne to identify the makeup of hackers across the world. HackerOne helps to connect companies with hackers who can help expose vulnerabilities in the company’s systems. The average hacker is a gray-hat – someone who helps out companies and people for good, called white hats, and those who sometimes walk on the dark side for fun and profit, commonly called black hats. The color of each hat is based on early westerns from the 1930’s in which the good guy normally dressed in white while the bad guys wore black. The ‘gray hat’ reflects a combination of the two – when you mix white with black you get a shade of gray. In short, gray hats are more than willing to help companies find weaknesses, as long as there is some profit or fame to be gained. At other times, you would not want to meet this same character walking down a back alley in the Dark Net. It all depends on what color of hat he is currently wearing.
Here are some interesting details from that report about hackers:
The vast majority are under the age of 34
72% hack for money
70% also hack for fun
66% thrive on the challenge alone
50% claim to do good in the world through their hacking activities
The United States and Russia have the highest concentration of free-lance hackers
17% use hacking as their sole source of income
26% generate ¾ of their income from bug bounty programs (companies willing to pay for hackers to discover vulnerabilities in their software)
Hackers make anywhere from $20K to $350K from a single bug bounty program
98% are male
While all of this is interesting, take special note of that last statistic – 98% of all hackers are male. As in ‘he’, not ‘she’. Why am I bringing this up? Because no one would ever accuse me of being a politically-correct individual, and I am not going to follow the socially popular trend of equally representing attackers as both genders in this book. Until you write a book you will not appreciate how difficult it is to do such a thing. Therefore, when we discuss an attacker, it will always be a ‘he’, because that is what the facts overwhelmingly support. This book will focus on how to implement secure systems, and I will leave the social crusading to others.
Does this offend you? As that timeless philosopher once noted, ‘Haters are going to hate.’ Besides, my end goal is to really tick off hackers, anyway – after all the whole point of this book to beat them at their own game!
TLS vs. SSL
Secure sockets layer, or SSL, is no longer considered to be secure, so we will only mention the use of transport layer security, or TLS in this book. Many books use the phrase ‘TLS/SSL’ to refer to both, but there is absolutely no scenario in which SSL should be in use. Furthermore, when TLS is mentioned, I am referring to TLS 1.2 or better, as both TLS 1.0 and 1.1 have proven to be insecure.
Section 1: Castle Warfare
Before we dig into how defenders kept their castle secure, let’s talk about the keep. Castle defense was focused on maintaining the safety of the most central portion of a castle, called the keep, where you would find the king and queen, nobles, and various treasures. The capture of the king or noble – whomever was at the top of the food chain within the castle - was considered to be the ultimate win during any castle battle, as can be evidenced by the rules of chess. This classic game is over only when the opposing king has been captured or can no longer escape an attac
k. In modern terms, our most valued treasure is the content housed inside of a database, and this is in fact the holy grail for any attacker. Keeping our data safe and available to those who need it, which also means keeping operational the systems required to serve the data, is the goal of any modern ‘castle’ defense. Once our database has been compromised, it is ‘game over’.
Now that we know the end game of any castle battle, let’s talk defenses.
Chapter 1: Outer Defenses
Exactly how did our ancestors ‘keep the keep’ safe? By building very strong walls. When we normally think of walls, we imagine something perhaps a few feet in thickness, but the best castle walls were anywhere from 15 to 20 feet thick on average – these weren’t just walls, they were WALLS.
Concentric Walls
Walls were made out of wood at first, and as they became larger over time, castle builders even started to build mini-towers, so they could rain down hurt on the attackers from above. Unfortunately, while wood is great for making trees and buildings, it also seems to disappear when set on fire. Eventually attackers began to shoot flaming arrows at the wooden walls and simply waited for them to burn down. This left the defenders very sad as their lives were snuffed out once the walls fell.
To combat this fiery menace, castle builders began to use stone instead. While it was much more difficult to source and cut, stone would not burn and made much stronger walls. It also allowed walls to rise higher, providing even more protection. In some areas of Europe, trees were not easily accessible, but stone was, so this approach made even more sense. Additionally, the building location of castles became a major concern, as a castle that backed into a tall cliff or water had one less wall to worry about.
While early castles had a single wall to protect the keep, later designs used concentric walls. Created by placing one wall inside of another with an average of 40 or 50 yards in between, builders implemented defense-in-depth, which is a core concept in our modern security architecture. Figure 1 illustrates the defensive layout of a typical castle.