Friday, July 24, 2009

Security in the scope of Software Architecture

Security must be addressed in the development very early. Taken existing and well-defined security requirements for granted, the system and software architecture (an artifact called “Architecture Specification”) must consider and reflect security. I do favor an approach based on a set of essential building blocks in order to achieve the expected level of security. Parts of the building set are:
  • Secure Components
  • Secure Infrastructure and Services
  • Secure Execution Environment
  • Secure Network Environment (zones, compartments, sandboxes)
  • End-to-End Security (supported by services like identity, authentication, authorization, auditing)
  • Secure Operation (Logging, Import/Export, Backup/Restore) and Security Appliances

The approach addresses common security paradigms like “Layered Defense”, “Security in Depth” as well as general design objectives (modularity, consistency, extensibility, robustness). These building blocks are the foundation for a security architecture where security controls can be applied. Just to drill a little bit down. Secure components can be characterized as in the following:

Design and composition of components are essential steps to meet the requirement for a sustainable architecture. Components must be secured in accordance with recommended practices. Design and implementation must adhere to security principles, design patterns and coding rules. They must be configured according to the security policies of the organization. Remember the weakest link paradigm; one weak component could compromise the security of the whole architecture. Components that expose interfaces to the “outside world”, like user or communication interfaces are especially under attack or even the entry point for an intruder. This must be considered when specifying, designing and developing these entities. And, interfaces must be well-defined to support an integrative approach in order to achieve end-to-end security. The overall security requirements for the component design should be derived from general security objectives such confidentiality, integrity, availability, and accountability.


Chai said...

My view of the ground reality on supporting good software architectural principles by the moolah holders (the so-called line managers) is mirrored in one of many Joseph Heller's Catch-22 moments: "....Don't worry about the men. They'll be easy enough to discipline and control when you've gone. It's only while you're still here that they may prove troublesome. You know, one good apple can spoil the rest..."

Maik G. Seewald said...

We should add REALITY as another import Quality Attribute.