"Architecture security" has been proposed both as a "top-down" and "bottom-up" model. To make the right choice, organizations should assess the difficulty in applying either security model to their own situation, and consider the impact of the two models on application and middleware evolution.
Maintaining a strong security model and the related compliance and governance requirements are becoming critical in an age when hacking and breaches are almost routine events. The biggest problem with security, according to security planners, is the tendency of companies to glue it on rather than design it in.
Top-down security and compliance design is based on the presumption that the security and governance needs of applications can be determined from the business framework in which they are to be used. Obviously, there's nothing about data per se that communicates how secure it has to be or how changes to it have to be tracked. The challenge has been in translating useful business input into a security and governance model.
One way to approach this is to draw on enterprise architecture (EA) results to map security and governance needs to applications. The capability is a part of all the currently popular EA frameworks, and there are a number of success stories available from users for each of the models. An EA linkage means that EA modeling can define security requirements, which governance products can fulfill because they support the models in use. This is the most truly top-down of all the options, but it's almost impossible to apply unless there's a full commitment to EA.
A slightly different approach may be easier to adopt. The open security architecture framework is a problem-driven model that presumes a company has an IT organization, has applications in place, and has business drivers that are creating security issues. This approach -- along with other emerging approaches from vendors like IBM and Microsoft -- aims at building a superstructure over the current applications, services and practices, and harmonizing them within that framework. By focusing on the model of security and harmonizing practices to conform, organizations can bring in disparate elements of IT without going back to the EA beginning.
The challenge with this approach is that it assumes recognition of the problems an organization faces. A true EA-driven model derives security and governance from business practices, making it less likely to miss something. Problem-driven approaches don't address the risk yet to be acknowledged. Creating the superstructure needed for these approaches also can be a challenge because of the variety of technical tools, particularly, middleware, that might be involved.
Problem-driven top-down models may be a strong option in situations where security and governance are complicated by integration of applications with those of customers and suppliers. Harmonizing EA practices across multiple organizations (even presuming everyone has them) is difficult, and problem-directed models don't require that. However, the challenges of implementation can be complicated by the need for cross-company integration.
Bottom-up approaches address the problem of a simple unified implementation first, and then presume that a flexible approach can be adapted to security and governance needs as they are exposed. Some will also enforce state-of-the-art support for security and governance, enough to cover the exposure of many if not most companies.
The most aggressive (and therefore comprehensive) of these are based on enterprise service buses (ESBs). Because ESBs link applications and components into business process flows through the application of both interface discipline and business rules they provide a very strong architecture in which to enforce security and compliance standards.
On the surface, it appears that neither the top-down nor the bottom-up security model would be easy to apply to an existing IT environment. The relevant questions for the top-down approach are whether there is an EA framework in place and whether current applications use a contained number of workflow and interface tools to connect. For the bottom-up approach, the question will be the ease of adoption of ESB, which likely will depend on whether current applications use SOA.
It's this last question that's the most important. If the current applications are both service and SOA based, then a bottom-up model is feasible, and may be easier to adopt. Even if teams want to take a problem-directed top-down approach, the consistency of interfaces will make it easier to build a security and governance superstructure. If current applications are more RESTful, it would probably be difficult to shift to an ESB approach, and a top-down model will be better. In that case, organizations should pick an EA or problem-directed path depending on whether they've established formal EA practices.
At the architecture level, security and governance are supported either by a model that controls information flows or controls access to resources. SOA frameworks fit the first of these, and Web and RESTful frameworks support the second. Architecture security based on one or the other principle will be easier, but unless an organization is prepared to anticipate future directions with microservices, cloud computing, containers, and the Web, it may be difficult to make a choice.
For that reason, the "best" approach for most users is likely to be the problem-driven model, with the expectation that the work will focus on the areas of control of information flows and resource access. Today, security and compliance architectures address these points but don't reflect a single standard for implementation, which means that users will have to develop this link on their own. The major software vendors (IBM, Microsoft and Oracle) are all capable of delivering the tools needed for this, but their effectiveness in articulating the best way to use them varies from account to account. Until a clear implementation model for the problem-directed approach emerges, users will face the challenges of self-integration or depend on professional services. But start now -- it's not going to get easier.
Learn how to maintain app security during the merger and acquisition process
Discover more information critical to cloud provider security issues
Discover the three steps to better mobile app security