CIOREVIEW >> Security >>

Probing Architecture Security Model Development Approaches

By CIOReview | Monday, September 19, 2016

Hacking, breaching and similar cyber based illicit activities have turned into a mundane state of affair. It has become critical that organizations overexert a strong security model and substantiate associated governance and compliance requirements. Moreover, security experts express that the most vital issue security faces is that companies tend to glue it on their framework instead of designing it from the inside.

‘Top-down’ and ‘bottom-up’ are two different proposed models of architecture security that organizations can pick, based on their situation and requirements. In order to select wisely, enterprises need to evaluate the pros and cons of both models on their current state and assess the impact of these models on their application and middleware evolution.  There exists a presumption with regard to top-down security and compliance design asserting that the governance and security requirements of applications can be decided from the business framework in which they will be employed in. However, it’s fairly evident that developed or acquired data during the business process doesn’t convey how secure it should be or how to track the changes made on it. This issue has been a major driving factor in transforming utile business input into a security and governance model.

One approach to deal with the issue is to exploit enterprise architecture (EA) outcomes to map governance and security requirements to applications. This approach is currently a feature of popular EA frameworks and has garnered prolific outcomes. A connection to EA entails that the EA modeling can set security requirements which can be satisfied by governance products because these products support the models in use. There needs to be a complete commitment to EA, if the company wants to apply this approach–which is most suited description for a top-down model. The open security architecture framework–a different approach but easy to adopt–is a problem-driven model that deduces per se that there exists  IT organizations with applications in place and the security issues are induced by the business drivers. Currently, along with this approach, trending approaches from IBM and Microsoft also aim at crafting a superstructure on the current applications, practices and services, and consorting them within the framework. Organizations can introduce different elements of IT without revisiting EA from scratch by means of concentrating on the model of security and harmonizing practices to adapt.

This approach assumes the recognition of the problems an organization faces, which is a core setback of this model. A true and reliable EA-driven model educes governance and security from business practices which reduces the probability of missing any particulars. Problem-driven approaches don’t consider the recognition of upcoming risks. With the range of technical tools and specially middleware involved in this approach, creating the superstructure becomes a daunting task. Problem-driven top-down models might be a good option in cases where governance and security are convoluted by integration of applications with those of suppliers and customers. Reconciling EA practices across several organizations is a complex task, and problem-directed models don’t really need that. Nevertheless, implantation can pose challenges which can be complicated if cross-company integration is involved.

Bottom-up approaches deal with the situation of a simple unified implementation first. Subsequently, it presumes that a pliable approach can be conceived to governance and security requirements as they are exposed en route. Few bottom-up approaches will implement state-of-the-art support for governance and security to encompass the exposure of a good amount of companies. The most vigorous and comprehensive of bottom-up approaches are anchored on enterprise service buses (ESBs). ESBs link components and application into business process flows by means of business rules and interface discipline. Resultantly, they deliver an efficient architecture in which they impose compliance and security standards.

On a surface level, both top-down and bottom-up security model look tough to apply on an existing IT environment. For top-down approach, the questions that emerge are whether an EA framework is in place and whether present applications employ a specific number of workflow and interlace tools for connections. The question for bottom-up approach would be the repose in adoption of ESB, which would depend whether existing applications use SOA. If the existing applications are both service and SOA based, then feasible option and easier to adopt would be a bottom-up model. It will be easier to build a governance and security superstructure. If the existing applications are more RESTful (REST–representational state transfer) it would be daunting to move to an ESB approach, and a top-down model would be beneficial. In such scenarios, companies should choose an EA or problem-directed approach based on whether formal EA practices have been established.

Based on the architecture level, governance and security are backed either by (i) a model that controls the flow of information or (ii) a model that controls the access to resources.  SOA frameworks suit the first one, whereas RESTful and web frameworks correspond the second. Until an organization is ready to previse future actions with cloud computing, microservers, and containers, it will be critical to make a choice based on either of the principles. The best approach for such scenarios would be the problem-driven model since work will be directed towards areas of control of resource access and information flows.

Compliance and security architectures address such issues but fail to bring upon standards for implementation; instead consumers have to create this link themselves. Major market players like Oracle, Microsoft and IBM are able to provide the tools required, but their influence in providing the required guidance to use the tools differs from one case to another. Users will have to tackle the issues of self-integration or get professional help until a comprehensible implementation model for the problem-directed approach comes forth.