A system should have certain properties (but not others). It should do certain things (but not others). It should be handled (or interacted with) in certain ways by certain parties (who should not be allowed to do things differently) while an authoritative party enforces this state of affairs by means of policy.
All this is subject to change without notice due to changing factors such as regulations, architecture or risk.
Functional, non functional or derived - no wonder security requirements are elusive.
2014-11-24
2014-11-03
question the cook book
Security is a process. It keeps the bits and pieces together over time - risk, requirements and testing. Case closed? Maybe not.
Legacy systems, management priorities and sourcing are three examples of circumstances that challenge our theories and force us to question the cook book.
What do you do when the terrain simply doesn't match the map? Be flexible. Don't lose the process - you will be needing it more than ever! - but identify hurdles, prioritize which ones to confront, mitigate and adapt.
Legacy systems, management priorities and sourcing are three examples of circumstances that challenge our theories and force us to question the cook book.
What do you do when the terrain simply doesn't match the map? Be flexible. Don't lose the process - you will be needing it more than ever! - but identify hurdles, prioritize which ones to confront, mitigate and adapt.
Subscribe to:
Posts (Atom)