Security is still regularly cited as a blocker to the adoption of cloud services, or other shared services, or anything being delivered "as a service". Assurance of cloud services is famously hard to achieve and archaic security "best practices" are often incompatible with service delivery via the cloud. Of course, accepted best practice is not always right practice for the problem at hand. Taking an architectural approach to security offers a way forward.
There's a common misconception that a system is either secure or it is not. If someone can break your system then it's obviously insecure.
But is it? What does secure actually mean? Does anyone really believe that a system must be purged of all exploitable flaws in order to be considered secure? Practically, I'd argue that you're never going to be certain that a system or service doesn't contain flaws (even if those flaws have yet to be exposed) and so you should build around principles of defence in depth, resiliency and proportionality in terms of acceptance of risk by the business risk owners.
First, identify the business processes and information requirements associated with those business processes and then build your security services so that they adequately protect these business services from realistic threats and attack vectors -- regardless of delivery model.
Say the words "security architecture" to many security professionals and they will automatically start thinking about firewalls and the placement of network intrusion detection sensors. For the purposes of this column, I'm more interested in the security elements of an enterprise architecture. Now, existing enterprise architecture frameworks such as Zachman and TOGAF are notoriously weak in their treatment of security, but that does not mean that the underlying concepts and drivers of enterprise architecture are not equally applicable to security, or that such frameworks are worthless from a security perspective.
The ability to build a security architecture that is demonstrably traceable to both requirements and architecture principles that have been agreed by the business is extremely valuable. It also neatly avoids the issue of building a system that is 'secure'.
If you have built a system that meets the security requirements (sourced from the business through standard requirements analysis and an agreed risk analysis), and that abides by all applicable principles and service contracts, then the system is adequately 'secure' almost by definition -- subject to appropriate assurance activities.
Does that mean that the system can't be hacked? No. But it should mean that if it is hacked, this is a risk that has been factored into the architecture and accepted by the business.
The challenge then is to identify appropriate technologies and processes to meet these architectural requirements in the implementation across various delivery models to ensure a consistent level of control. It is equally important to ascertain the levels of assurance required of these identified controls, as this may rule out certain delivery models, subject to business risk tolerances. The other challenge is to use a lightweight approach that does not stifle the flexibility and speed of implementation associated with delivery "as a service".
For too long security has been seen as a blocker and detached from the business, security architecture is the means to bridge this gap and help organisations to take advantage of new technologies within risk tolerances that the business understands and accepts.
Lee Newcombe is a managing consultant at Capgemini
Security Zone is a regular series in Computer Weekly covering all aspects of IT security management. Each article is written by a member of the International Information Systems Security Certification Consortium (ISC)².