(without permission) is a criminal act in many countries. Be careful, and when in doubt, always ask before you start.
Defense in Depth
Defense in depth is the idea of having multiple layers of security in case one is not enough (Figure 1-5). Although this may seem obvious when explained so simply, deciding how many layers and which layers to have can be difficult (especially if your security budget is limited).
“Layers” of security can be processes (checking someone’s ID before giving them their mail, having to pass security testing before software can be released), physical, software, or hardware systems (a lock on a door, a network firewall, hardware encryption), built-in design choices (writing separate functions for code that handles more sensitive tasks in an application, ensuring everyone in a building must enter through one door), and so on.
Figure 1-5: Three layers of security for an application; an example of defense in depth
Here are some examples of using multiple layers:
When creating software: Having security requirements, performing threat modeling, ensuring you use secure design concepts, ensuring you use secure coding tactics, security testing, testing in multiple ways with multiple tools, etc. Each one presents another form of defense, making your application more secure.
Network security: Turning on monitoring, having a SIEM (Security information and event management, a dashboard for viewing potential security events, in real time), having IPS/IDS (Intrusion prevention/detection system, tools to find and stop intruders on your network), firewalls, and so much more. Each new item adds to your defenses.
Physical security: Locks, barbed wire, fences, gates, video cameras, security guards, guard dogs, motion sensors, alarms, etc.
Quite often the most difficult thing when advocating for security is convincing someone that one defense is not enough. Use the value of what you are protecting (reputation, monetary value, national security, etc.) when making these decisions. While it makes little business sense to spend one million dollars protecting something with a value of one thousand dollars, the examples our industry sees the most often are usually reversed.
NOTE Threat modeling: Identifying threats to your applications and creating plans for mitigation. More on this in Chapter 3.
SIEM system: Monitoring for your network and applications, a dashboard of potential problems.
Intrusion prevention/detection system (IPS/IDS): Software installed on a network with the intention of detecting and/or preventing network attacks.
Least Privilege
Giving users exactly how much access and control they need to do their jobs, but nothing more, is the concept of least privilege. The reasoning behind least privilege is that if someone were able to take over your account(s), they wouldn’t get very far. If you are a software developer with access to your code and read/write access to the single database that you are working on, that means if someone were able to take over your account they would only be able to access that one database, your code, your email, and whatever else you have access to. However, if you were the database owner on all of the databases, the intruder could potentially wipe out everything. Although it may be unpleasant to give up your superpowers on your desktop, network, or other systems, you are reducing the risk to those systems significantly by doing so.
Examples of least privilege:
Needing extra security approvals to have access to a lab or area of your building with a higher level of security.
Not having administrator privileges on your desktop at work.
Having read-only access to all of your team’s code and write access to your projects, but not having access to other teams’ code repositories.
Creating a service account for your application to access its database and only giving it read/write access, not database owner (DBO). If the application only requires read access, only give it what it requires to function properly. A service account with only read access to a database cannot be used to alter or delete any of the data, even if it could be used to steal a copy of the data. This reduces the risk greatly.
NOTE Software developers and system administrators are attractive targets for most malicious actors, as they have the most privileges. By giving up some of your privileges you will be protecting your organization more than you may realize, and you will earn the respect of the security team at the same time.
Supply Chain Security
Every item you use to create a product is considered to be part of your “supply chain,” with the chain including the entity (supplier) of each item (manufacturer, store, farm, a person, etc.). It’s called a “chain” because each part of it depends on the previous part in order to create the final product. It can include people, companies, natural or manufactured resources, information, licenses, or anything else required to make your end product (which does not need to be physical in nature).
Let’s explain this a bit more clearly with an example. If Bob was building a dollhouse for his grandchildren, he might buy a kit that was made in a factory. That factory would require wood, paper, ink to create color, glue, machines for cutting, workers to run and maintain the machines, and energy to power the machines. To get the wood, the factory would order it from a lumber company, which would cut it down from a forest that it owns or has licensed access to. The paper, ink, and glue are likely all made in different factories. The workers could work directly for the factory or they could be casual contractors. The energy would most likely come from an energy company but could potentially come from solar or wind power, or a generator in case of emergency. Figure 1-6 shows the (hypothetical) supply chain for the kit that Bob has purchased in order to build a doll house for his children for Christmas this year.
Figure 1-6: A possible supply chain for Bob’s doll house
What are the potential security (safety) issues with this situation? The glue provided in this kit could be poisonous, or the ink used to decorate the pieces could be toxic. The dollhouse could be manufactured in a facility that also processes nuts, which could cross-contaminate the boxes, which could cause allergic reactions in some children. Incorrect parts could be included, such as a sharp component, which would not be appropriate for a young child. All of these situations are likely to be unintentional on the part of the factory.
When creating software, we also use a supply chain: the frameworks we use to write our code, the libraries we call in order to write to the screen, do advanced math calculations, or draw a button, the application programming
