Skip to content

Securing Software Systems

Concept · Chapter 11

  • Security is the system’s ability to prevent and protect against malicious attacks and unauthorized use of the application and its data.
  • The asset being protected is information — not only data, but also logs and source code.
  • It is the architect’s and developers’ responsibility to protect the application and its data.
  • Security is a quality attribute; its requirements must be specified, precise, measurable, and testable.
  • It cannot be added on later — it must be considered across requirements, design, development, and testing.
  • Different systems have different needs: a blog and a payroll app do not warrant the same security posture. Understand the system’s actual security needs before deciding controls.

Protected information exists in one of three states, all vulnerable to attack:

StateMeaningExamples
At restStored, not currently accessedDatabase rows, files
In useBeing processed, non-persistedData in memory, CPU cache
In transitBeing movedData crossing a network — needs a secure channel

Primary goals of information security (also called the AIC triad to avoid confusion with the intelligence agency). Architects seek a balance among the three — over-securing hurts usability and availability.

  • Confidentiality — prevent unauthorized individuals from accessing information (especially private/personal data, in all three states). Guards against eavesdropping in transit.
  • Integrity — prevent unauthorized modification or destruction of information; ensure data has not been tampered with, in any state.
  • Availability — authorized users get timely, reliable access. Overly extensive controls reduce usability and availability. Relates directly to Availability: detect, recover from, and prevent faults so data is there when needed.
  • Software Architect’s Handbook (Packt, 2018), Ch.11 “Securing software systems”, pp. 820-825.