2 Defining the problem

 

This chapter covers

  • Defining the security tenants that software must adhere to
  • Identifying and understanding risk that impacts software
  • Exploring security in the software development life cycle

In the previous chapter, I used the example of building a house without the locks on the doors and windows. A house is a great example, as it allows you to think about the controls you use to limit your risk of the house being compromised due to break-in, fire, flooding, and so forth. We spend most of our time in security attempting to limit risk and counter threats, not eliminate them. A risk is the potential for loss of an asset or damage to an asset, whereas a threat is the activity that takes advantage of a weakness in an asset. Risk and threats can never be eliminated. Similar to a house, we can’t eliminate the risk of fire, flood, or a break-in; we can only detect and respond while attempting to limit the risk and impact. To be clear, risk can never be eliminated, only reduced.

NOTE

In the case of a house fire, the fire is the threat, while the house burning down is the risk.

Whereas fire, flood, and break-in are risks that impact a house, our software has a different set of threats and risks. These range from the physical to the digital. Yes, physical threats exist that impact our software; a flood in a data center would be a physical risk to our running application.

2.1 The CIA triad

2.2 Confidentiality

2.2.1 Data protection policy

2.2.2 Data at rest

2.2.3 Applying encryption

2.2.4 Data in transit

2.2.5 Encryption prior to transmission

2.2.6 Data in use

2.2.7 Not so confidential

2.2.8 Do I even need this?

2.3 Availability

2.3.1 DoS and DDoS

2.3.2 Accidental outage