CHAPTER 1
Security Fundamentals

Before learning how to create secure software, you need to understand several key security concepts. There is no point in memorizing how to implement a concept if you don't understand when or why you need it. Learning these principles will ensure you make secure project decisions and are able to argue for better security when you face opposition. Also, knowing the reason behind security rules makes them a lot easier to live with.

The Security Mandate: CIA

The mandate and purpose of every IT security team is to protect the confidentiality, integrity, and availability of the systems and data of the company, government, or organization that they work for. That is why the security team hassles you about having unnecessary administrator rights on your work machine, won't let you plug unknown devices into the network, and wants you to do all the other things that feel inconvenient; they want to protect these three things. We call it the "CIA Triad" for short (Figure 1-1).

Let's examine this with our friends Alice and Bob. Alice has type 1 diabetes and uses a tiny device implanted in her arm to check her insulin several times a day, while Bob has a "smart" pacemaker that regulates his heart, which he accesses via a mobile app on this phone. Both of these devices are referred to as IoT medical device implants in our industry.

Figure 1-1: The CIA Triad is the reason IT Security teams exist.

NOTE IoT stands for Internet of Things, physical products that are internet connected. A smart toaster or a fridge that talks to the internet are IoT devices.

Confidentiality

Alice is the CEO of a large Fortune 500 company, and although she is not ashamed that she is a type 1 diabetic, she does not want this information to become public. She is often interviewed by the media and does public speaking, serving as a role model for many other women in her industry. Alice works hard to keep her personal life private, and this includes her health condition. She believes that some people within her organization are after her job and would do anything to try to portray her as "weak" in an effort to undermine her authority. If her device were to accidentally leak her information, showing itself on public networks, or if her account information became part of a breach, this would be highly embarrassing for her and potentially damaging to her career. Keeping her personal life private is important to Alice.

Bob, on the other hand, is open about his heart condition and happy to tell anyone that he has a pacemaker. He has a great insurance plan with the federal government and is grateful that when he retires he can continue with his plan, despite his pre-existing condition. Confidentiality is not a priority for Bob in this respect (Figure 1-2).

Figure 1-2: Confidentiality: keeping things safe

NOTE Confidentiality is often undervalued in our personal lives. Many people tell me they "have nothing to hide." Then I ask, "Do you have curtains on your windows at home? Why? I thought that you had nothing to hide?" I'm a blast at parties.

Integrity

Integrity in data (Figure 1-3) means that the data is current, correct, and accurate. Integrity also means that your data has not been altered during transmission; the correct value must be maintained during transit. Integrity in a computer system means that the results it gives are precise and factual. For Bob and Alice, this may be the most crucial of the CIA factors: if either of their systems gives them incorrect treatment, it could result in death. For a human being (as opposed to a company or nation-state), there does not exist a more serious repercussion than end of life. The integrity of their health systems is crucial to ensuring they both remain in good health.

Figure 1-3: Integrity means accuracy.

CIA is the very core of our entire industry. Without understanding this from the beginning, and how it affects your teammates, your software, and most significantly, your users, you cannot build secure software.

Availability

If Alice's insulin measuring device was unavailable due to malfunction, tampering, or dead batteries, her device would not be "available." Since Alice usually checks her insulin levels several times a day, but she is able to do manual testing of her insulin (by pricking her finger and using a medical kit designed for this purpose) if she needs to, it is somewhat important to her that this service is available. A lack of availability of this system would be quite inconvenient for her, but not life-threatening.

Bob, on the other hand, has irregular heartbeats from time to time and never knows when his arrhythmia will strike. If Bob's pacemaker was not available when his heart was behaving erratically, this could be a life-or-death situation if enough time elapsed. It is vital that his pacemaker is available and that it reacts in real time (immediately) when an emergency happens.

Bob works for the federal government as a clerk managing secret and top-secret documents, and has for many years. He is a proud grandfather and has been trying hard to live a healthy life since his pacemaker was installed.

NOTE Medical devices are generally "real-time" software systems. Real-time means the system must respond to changes in the fastest amount of time possible, generally in milliseconds. It cannot have delays-the responses must be as close as possible to instantaneous or immediate. When Bob's arrhythmia starts, his pacemaker must act immediately; there cannot be a delay. Most applications are not real-time. If there is a 10-millisecond delay in the purchase of new running shoes, or in predicting traffic changes, it is not truly critical.

Figure 1-4: Resilience improves availability.

NOTE Many customers move to "the cloud" for the sole reason that it is extremely reliable (almost always available) when compared to more traditional in-house data center service levels. As you can see in Figure 1-4, resilience improves availability, making public cloud an attractive option from a security perspective.

The following are security concepts that are well known within the information security industry. It is essential to have a good grasp of these foundational ideas in order to understand how the rest of the topics in this book apply to them. If you are already a security practitioner, you may not need to read this chapter.

Assume Breach

"There are two types of companies: those that have been breached and those that don't know they've been breached yet."2 It's such a famous saying in the information security industry that we don't even know who to attribute it to anymore. It may sound pessimistic, but for those of us who work in incident response, forensics, or other areas of investigation, we know this is all too true.

The concept of assume breach means preparation and design considerations to ensure that if someone were to gain unapproved access to your network, application, data, or other systems, it would prove difficult, time-consuming, expensive, and risky, and you would be able to detect and respond to the situation quickly. It also means monitoring and logging your systems to ensure that if you don't notice until after a breach occurs, at least you can find out what did happen. Many systems also monitor for behavioral changes or anomalies to detect potential breaches. It means preparing for the worst, in advance, to minimize damage, time to detect, and remediation efforts.

Let's look at two examples of how we can apply this principle: a consumer example and a professional example.

As a consumer, Alice opens an online document-sharing account. If she were to "assume breach," she wouldn't upload anything sensitive or valuable there (for instance, unregistered intellectual property, photos of a personal nature that could damage her professional or personal life, business secrets, government secrets, etc.). She would also set up monitoring of the account as well as have a plan if the documents were stolen, changed, removed, shared publicly, or otherwise accessed in an unapproved manner. Lastly, she would monitor the entire internet in case they were leaked somewhere. This would be an unrealistic amount of responsibility to expect from a regular consumer; this book does not advise average consumers to "assume breach" in their lives, although doing occasional online searches on yourself is a good idea and not uploading sensitive documents online is definitely advisable.

As a professional, Bob manages secret and top-secret documents. The department Bob works at would never consider the idea of using an online file-sharing service to share their documents; they control every aspect of this valuable information. When they were creating the network and the software systems that manage these documents, they designed them, and their processes, assuming breach. They hunt for threats on their network, designed their network using zero trust, monitor the internet for signs of data leakage, authenticate to APIs before connecting, verify data from the database...