By Jason Bloomberg
When I first discuss security in our Licensed ZapThink Architect (LZA) SOA course, I ask the class the following question: if a building had 20 exterior doors, and you locked 19 of them, would you be 95 percent secure? The answer to this 20-doors problem, of course, is absolutely not – you’d be 0 percent secure, since the bad guys are generally smart enough to find the unlocked door.
While the 20-doors problem serves to illustrate how important it is to secure your services as part of a comprehensive enterprise IT strategy, the same lesson applies to enterprise cybersecurity in general: applying inconsistent security policies across an organization leads to weaknesses hackers are only too happy to exploit. However, when we’re talking about the entire enterprise, the cybersecurity challenge is vastly more complex than simply securing all your software interfaces. Adequate security involves people, process, information, as well as technology. Getting cybersecurity right, therefore, depends upon enterprise architecture (EA).
Understanding the context for cybersecurity
A fundamental axiom of security is that we can never drive risk to zero. In other words, perfect security is infinitely expensive. We must therefore understand our tolerance for risk and our budget for addressing security, and ensure these two factors are in balance across the organization. Fundamentally, it is essential to build threats into your business model, and do so consistently.
 |
| Bloomberg |
In many organizations, however, the tolerance for risk and the budget for security are not in balance – or to be more precise, the balance is different in different departments or contexts across the enterprise. Part of this problem is due to the lottery fallacy, which we recently discussed in the context of big data. People tend to place an inordinate emphasis on improbable events. This fallacy frequently occurs in the context of risk, which is why we’re more worried about airplane crashes than car accidents, even though car crashes are far, far more likely.
But the lottery fallacy isn’t the only problem. Politics is a much greater issue. Department heads have their own ideas about tolerable risk in their fiefdoms, and the risk tolerance for one division may be very different from another. Furthermore, in most organizations, certain departments are responsible for security while others are not. Now department heads have a much more difficult time evaluating their level of risk and calculating their budget for security, as it’s someone else’s budget and supposedly someone else’s problem.
The solution to these challenges is the effective use of EA. You must think like an insurance company: undertake an objective analysis of the known risks and calculate the average cost of threats over all the activities in your organization. Just as an insurance company must be able to set their premiums high enough to cover losses on average, you must set your security budget high enough to cover your threats. Of course, sometimes a particular threat costs more than you expect, just as a catastrophic loss may cost more than a lifetime of premiums for the affected insurance customer. But the average still generally works out to your advantage.
With risk comes reward, but not all risks have the same promise of reward. In other words, some bets are better than others. Properly applied, EA can inform the organization about which bets have better expected returns than others, so that the organization can place its bets more rationally by distributing the risk across the organization in a fact-based manner.
Cybersecurity: dealing with change
Even organizations with robust EA efforts typically don’t leverage architecture to drive their cybersecurity strategies. The reason for this lack are diverse, and often include political and competence issues, but the most fundamental reason is because traditional EA doesn’t deal well with change. Cybersecurity is an inherently dynamic challenge: hackers keep inventing new attacks, new technologies continually introduce new vulnerabilities, and the interrelationship among the various trends in IT are increasingly convoluted, as we illustrate on our new ZapThink 2020 poster.
In contrast, the agile architecture approach I champion in my book, The Agile Architecture Revolution, calls for EA that focuses on change by explicitly working at the “meta” level: instead of simply architecting the things themselves, focus on architecting how those things change. For example, instead of focusing on the processes in the organization, architect the meta-processes:
The focus shouldn’t be on
threats, but rather on how those threats might change.
processes for how processes change. Similarly, the role
of software development isn’t simply to build to requirements. Instead,
the focus should be on building systems that respond to changing
requirements, what my book calls the meta-requirement of business agility.So too with architecting for security. The focus shouldn’t be on threats, but rather on how those threats might change. At the technology level, this focus on change shifts the focus from a static “locked door” approach to security to the immune system metaphor I discussed last year. But there’s more to architecting for security than the technology. At the organizational level, effective EA will help resolve shadow IT issues which can lead to unmanaged security threats as an example. At the process level, EA will address social engineering challenges like phishing attacks. Securing your technology without applying a comprehensive, best practice approach to organizational and process security is tantamount to leaving some of your doors unlocked.
The ZapThink take
Remember the scene from Apollo 13, where the Flight Director goes around the room, asking each division leader for a go/no-go decision? Essentially, every division leader was a stakeholder in all important decisions, and any one of them had the ability to nix any idea with a thumbs-down. The thinking behind this approach was one of risk mitigation: only if there be a unanimous thumbs-up can the organization make a critical decision to take action.
Just so in the enterprise. Your EA should require the security team to be part of the planning for all systems (both human and technology) across the organization. Without EA, security tends to be an afterthought. Instead, security must be a stakeholder in all critical decisions across the enterprise.
By giving your
enterprise architects the ability to offer thumbs-up or thumbs-down
opinions on critical decisions, you are essentially saying that you mandate
EA.
EA should also have a seat at the table, of course. By giving your enterprise architects the ability to offer thumbs-up or thumbs-down opinions on critical decisions, you are essentially saying that you mandate EA. And without such a mandate, architects find themselves in the proverbial ivory tower, creating artifacts and standards that the rank and file consider optional – which is a recipe for disaster. There’s no surer way to increase your cybersecurity risk than to treat EA as anything but absolutely necessary to the proper functioning of your organization.
This guest post comes courtesy of Jason Bloomberg of ZapThink, a Dovel Technologies company.
You may also be interested in:
- Fighting in the cloud service orchestration wars
- US Department of Energy: Proving the cloud service broker model
- Where cloud computing takes us: Hybrid services delivery of essential information across all types of applications
- Convercent's cloud app aims to help employees implement, measure, and rate corporate values and culture
- Thomas Duryea's journey to the cloud: Part one
- Market confidence in cloud soars, especially among service providers, says North Bridge survey
