Question

1. Enterprise Architecture analysis and design model

2. How to collect the pattern or significant feature of security architecture?

3. How to setup the weighting and rating for security architecture parameters?

Answer 1

1)

Making a model a reference

The main difficulty of an enterprise architecture model is its constant evolution, and consequently its permanent update. Unlike building plans, which we can assume will remain stable over a very long period of time, enterprise architecture models quickly become obsolete if they are not updated. The organization, IS, procedures, business, and goals are constantly evolving, making it essential to rework models in order to reflect changes.

The situation can deteriorate very quickly. If analysts or architects do not trust in the relevance of existing models, the pressure of deadlines may force them into rebuilding models ad hoc, focusing on the requirements of the moment, which are even more short-lived. Worse still, they may decide to do without models altogether, in order to continue on to the actual realization of projects. If this happens, the enterprise is back at square one, where knowledge is neither controlled nor recorded, but rather scattered across detailed realizations.

2)

[SFD1.1: 102] Integrate and deliver security features.

Rather than having each project team implement its own security features (e.g., authentication, role management, key management, logging, cryptography, protocols), the SSG provides proactive guidance by acting as or facilitating a clearinghouse of security features for engineering groups to use. These features might be discovered during SSDL activities, created by the SSG or specialized development teams, or defined in configuration templates (e.g., cloud blueprints) and delivered via mechanisms such as containers, microservices, and APIs. Generic security features often have to be tailored for specific platforms. For example, each mobile and cloud platform will likely need their own means by which users are authenticated and authorized, secrets are managed, and user actions are centrally logged and monitored. Project teams benefit from implementations that come preapproved by the SSG, and the SSG benefits by not having to repeatedly track down the kinds of subtle errors that often creep into security features

[SFD1.2: 76] Engage the SSG with architecture teams.

Security is a regular topic in the organization’s software architecture discussions, with the architecture team taking responsibility for security in the same way that it takes responsibility for performance, availability, scalability, and resiliency. One way to keep security from falling out of these discussions is to have an SSG member participate in architecture discussions. Increasingly, architecture discussions include developers and site reliability engineers governing all types of software components, such as open source, APIs, containers, and cloud services. In other cases, enterprise architecture teams can help the SSG create secure designs that integrate properly into corporate design standards. Proactive engagement by the SSG is key to success here. Moving a well-known system to the cloud means reengaging the SSG, for example. It’s never safe for one team to assume another team has addressed security requirements.