Appraise the Various Types of Security Architecture & Design Models

calendar Oct 25, 2025 / · 7 min read · security architecture information security security models access control integrity models confidentiality enterprise architecture security policy  ·
Share on: linkedin copy

Appraise the Various Types of Security Architecture & Design Models

Security Architecture Overview

Security architecture is the view of the overall system architecture from a security perspective. Security architecture provides insight into the security services, mechanisms, technologies, and features that can be used to satisfy system security requirements as described by Tipton & Krause (2003). The security architecture offers recommendations in the context of the overall system architecture, and security mechanisms should be placed. The security view of a system architecture emphases the system security services and mechanisms, implementation of security related functionality, and identifies interdependencies among security-related components, services, mechanisms, and technologies, and at the same time reconciling any conflict between them. The security architecture is one aspect of an enterprise or system architecture, and can also include network architecture or connectivity architecture.

Security Architecture Design and Requirements

A security architecture depicts how the system is put together to satisfy the security requirements as Tipton & Krause (2003) points out. It is not a description of the functions of the system but a design overview that describes and the relationships amongst important features of the hardware, operating systems, applications, network, and other vital components to guard the organization interests. The security architecture should describe the functions that are part of the system development process follow security requirements. The security requirements are not added steps to the development process, but instead, are incorporated in the specifications or guidelines of the security architecture providing an impact during all development projects as described by Tipton & Krause (2003). At the beginning stages of the project(s), the security architecture outline high-level security concerns, such as the system security policy, the level of assurance required, and any possible effects security could have in the design process. As the project progresses, the security architecture would evolve in parallel and could require to be a little ahead of the development process, so the security requirements guide the development project process.

Organizational Asset Protection

The security architecture is relevant and important to a company because it protects the organization's valuable resources. A few examples of organization assets to protect are computer hardware, applications code, legal documents and physical security of the organization office as Peltier (2013) discusses. The information architecture, developed by the security team in the organization must pick and implement the appropriate safeguards that assist the company's mission by defending financial and physical resources, their reputation, the employees and any other tangible or intangible assets. Security is believed by some employees, as Peltier (2013) points out as preventing organization goals to be reached by putting in place poorly selected, rules and procedures on members of the organization and systems. Part of the security architecture is a set of well-written policies, standards, and procedures are put in place to protect assets to support all of the business objectives.

Security Architecture Components

The information security architecture put in place and maintained by the security team needs to follow the all principles of security which enable the business to build an effective security program as Peltier (2013) discusses. The author goes on to describe four parts of the security architecture, which are continually revisited by the security team. The first is are exploring and assessing the information security risks to business operations. The second is the analysis and then understanding any policies, standards, or controls that are identified as important to implement and reduce risks. The third is to promote company information security awareness and understanding among the employees. The last piece of information security architecture is to continually assess the compliance and effectiveness of what policies, standards, or controls implemented at the company. Just like auditing and other controls in an organization once put in place their aim is to improve them and keep them up to date, so there is beginning at the implementation but no real end and continuously improving and tweaking what policies, standards, and procedures the team implemented.

Foundation for Security Implementation

The Information Security professional needs to have a good foundation to implement a strong security architecture. Committing to a strong security architecture requires a clear understanding of the issues involving technology, environment, and software as described by Tipton & Krause (2003). The security architecture referred to as the virtual foundation that security profession must know about each and the interactive effects of each as Tipton & Krause (2003) points out. If these three things are all implemented there should be many successfully implemented security architectures. The reason it is difficult is when one considers that the architecture involves the manner in which components of a computer system are organized and integrated. Security involves the synergy or interacting with software, technology, and the environment. A computer cannot be secured unless it is unplugged. Security includes various software such as anti-virus and firewalls and includes people and policy that needs to be factored in as well. If a policy is too strict, does not integrate into the organization seamlessly, or not transparent to its end users, then the security policy will be circumvented, ignored or not supported.

Bell-LaPadula Security Model

There are many types of security models. The most common security models, as discussed by Tipton & Krause (2003) are Bell-LaPadula, Biba, and Clark-Wilson security models. The Bell-LaPadula Model security model developed by Dr. Bell and LaPaula for the United States Department of Defense as described by Tipton & Krause (2003). The model controls information flow. The training literature for the model discusses the access rights to objects and resources. The different read, write, delete and modify access privileges from a woven lattice. The concept of the security model dictates that a user cannot read an object of a higher classification than they are granted or cleared to access. If one has a secret security clearance, one can view documents that are secret and lower, but no access provided to top secret documents. The Bell-LaPadula security model is know as the confidentiality model.

Biba Security Model

The Biba security model developed about the same time as the Bell-LPadula model. The Biba model is an integrity model as Tipton & Krause (2003) points out, and the Bell-LaPadula model focused on protecting the release of information to unauthorized users. The Biba security model was developed specifically for the developing computer systems. The Biba security model unauthorized objects are blocked from making modifications. The property is used to block subjects from writing to objects of higher integrity. The read property keeps subjects from corruption by objects of lower integrity and subjects cannot request services from objects that have a higher integrity level in the model.

Clark-Wilson Security Model

The Clark-Wilison security model is the last model and developed to address integrity and users a broader approach than the Biba model that addresses only subjects and objects as described by Tipton & Krause (2003). The well-formed transaction is what the Clark-Wilson security model addresses. Changes to a process or data can only be made through the trusted program because the subject can access the object. The concepts bind the subject to the program and the program to the object which creates a triple instead of a subject-object tuple which gets used in the Biba security model. The trusted program is created only to make authorized changes. Think of it as incorporating a program to handle the transaction and one that integrates the policies of the separation of duties too. Separation of duty is used in this security model. The separation of duty means the model breaks a task into operations into parts that will not allow one person to complete a process.

References

Posts in this series