Information systems architecture It is a set of rules and standards for the construction of computers, communications networks and the

distributed business systems. Information systems architecture must therefore take account of: The goals that we want to achieve through the systems The environment in which the systems will be built and used The technical capabilities needed to construct and operate the systems and their component sub-systems Information systems architecture is concerned with many more than mere technical factors. It is concerned with what the enterprise wants to achieve and with the environmental factors that will influence those achievements. Technical factors are often the main ones that influence the architecture.

The Concept of Enterprise The concept of enterprise carries the meaning that the organisation is perceived as a single entity rather than as a collection of cooperating units.

Managing Complexity One of the key functions of architecture as is to provide a framework within which complexity can be managed successfully. As the size and complexity of a project grows, many designers are needed, all working as a team to create something that has the appearance of being designed by a single design authority. The role of architecture is to provide the framework that breaks down complexity into apparent simplicity. This is achieved by layering techniques focusing attention on specific conceptual levels of thinking, and by modularization breaking the overall design into manageable pieces that have defined functionality and defined interfaces. This process is also known as systems engineering.

Enterprise Security Architecture Enterprise security architecture is business-driven and it describes a structured inter-relationship between the technical and procedural solutions to support the long-term needs of the business. The must provide a rational framework within which decisions can be made upon the selection of security solutions. The decision criteria should be derived from a thorough understanding of the business requirements, including: The need for cost reduction Modularity Scalability Ease of component reuse Operability Usability

 Inter-operability both internally and externally Integration with the enterprise IT architecture and its legacy systems. Information systems security is only a small part of information security which is one part of a wider topic: business security. Business security embraces three major areas: information security; business continuity; physical and environmental security.

The Wider Business Requirements The primary business requirements for information security are business-specific. They are expressed in terms of protecting the availability, integrity, authenticity and confidentiality of business information, and providing accountability and auditability in information systems. The generic business requirements for an information security solution often include the following: Usability The solution should be in-line/match with the technical competence of the intended users and the usage of the solution should not affect the individual Inter-Operability The solution should provide long-term requirements for inter-operability between communicating information systems and applications Integration The solution should integrate with the wide range of computer applications and platforms which might be required in the long term Supportability The solution should be capable to support the environment within which it has been designed to be used Low Cost Development The solution should be of modular design and hence capable of being integrated into a development programme at minimal cost? Fast Time to Market The solution should be capable of being integrated into a development programme with minimal delay so that business opportunity is not lost? Scalability of Platforms The solution should fit with the range of computing platforms with which it might be integrated. Scalability of Cost The entry-level cost should be appropriate to the range of business applications for which the solution is intended Scalability of Security Level The solution should support the range of cryptographic and other techniques that will be needed to implement the required range of security strengths and assurance levels. Re-Usability The solution should be re-usable in a wide variety of similar situations to get the best return on the investment Operations Costs The solution should minimize the impact of cost on systems operations Administration Costs The solution should provide an efficient means for security administration to minimise the costs

SABSA Model SABSA (Sherwood Applied Business Security Architecture) is a framework and methodology for Enterprise Security Architecture and Service Management. SABSA is a model and a methodology for developing risk-driven enterprise information security architectures and for delivering security infrastructure solutions that support critical business initiatives. The primary characteristic of the SABSA model is that everything must be derived from an analysis of the business requirements for security. The model is made up of six layers, and each layer represents a different view of the organization and the types of security controls that need to be put into place. SABSA Model for Security Architecture (Diagram) Contextual security architecture: It is deals with 1) Defining the business needs for information security and the assets to be protected. Assets are the business assets like brand name, reputation, etc. and not the technology assets. Business needs are dependent on the goals and objectives (Business Driver) of an organization. 2) Identifying the risks to the business assets defined and the opportunities with the business assets defined. 3) Identifying business processes that require security 4) Defining a high level organizational structure including relationships with external entities like customers, suppliers, outsourcing partners, etc. i.e. identifying the different functional units / departments in the organization along with the external business units like customers, suppliers, etc. 5) Determining the business security needs with respect to geography of the business. E.g. securing remote access, compliance to different laws in different countries, securing communication and data transfer between different site locations. 6)

Conceptual security architecture: It deals with: 1) Mapping the Business Drivers identified in the contextual level to the SABSA business attributes. For example: Business Driver / Goal and Objective: Maintaining privacy of personal and business information that is stored, processed and communicated by Banks systems. Corresponding Business Attribute: Access controlled, Authenticated, Confidential, Identified, Private 2) Identifying why we need security expressed in terms of control objectives. Control objectives are selected on the basis of risk assessment done for the risks identified in the contextual level against the business attributes. 3) Determining how to protect the business process identified in the contextual level and a process mapping describing the processes. Process mapping is a workflow diagram to bring forth a clearer understanding of a process by breaking it into smaller processes.

It determines when a process starts, when a process ends, what are the steps inside the process. 4) Identifying who is responsible for security management in terms of roles and responsibilities (related to security) of individuals in the functional units / departments identified in the contextual level and type of trust between different entities. E.g. Mutual trust, trust based on SLA, trust based on PKI, etc. 5) Create a security domain model consisting of different security domains. E.g. Network Domain, Application Domain, Middleware Domain, etc. 6)

Logical security architecture: 1) Identify the business information related to the Business Drivers that needs to be secured. e.g. Acquisition Plans, Supplier Information, Customer information, etc. 2) Specifying the security and risk management policy requirements based on the Risk identified and the Control objectives for securing business information. E.g. business continuity policy, acceptable use policy, remote access policy, etc. 3) Specifying the logical security services to be implemented to protect the business processes identified and a logical flow of the security services in terms of process maps. E.g. Entity authentication, confidentiality protection, etc. 4) Specifying the logical entities of the security domains identified in the conceptual level and their authorized roles and privilege profiles. E.g. User, network administrator, etc. 5) Define the security domains identified in the security domain model and inter-domain relationships. E.g. Network Domain: Corporate network, Extranets, Internet 6)

Physical security architecture: 1) Specifying the business data model and security related data structures. A data model explicitly determines the structure of data i.e. how the business data is to be stored. E.g. tables, pointer, file structure, record structure, access control list, certificates, etc. 2) Specifying the rules that drive the logical decision making within the system with respect to polices defined. E.g. Firewall rules, Database rules, file system rules, etc. 3) Specifying the security mechanisms with respect to the logical security services defined. E.g. Entity Authentication: tokens, active directory, etc. 4) Specifying different screens formats for different users i.e. the logical entities defined and access control systems. E.g. In a screen/page an administrator can add, update and delete the data but a normal user on the same page can only update the data. 5) Specifying security technology infrastructure within each domain and between different domains i.e. physical layout of the hardware, software and communication lines. 6)

Component security architecture: 1) Specifying the components and products to store the business information in the structure specified.

E.g. XML, SQL Server, Oracle, Standard data security structures, etc. 2) Risk management-related tools and products for risk analysis, risk monitoring and reporting. E.g. ISO, ISACA, ANSI, Wi-Fi Alliance 3) Tools and protocols required to implement the security mechanisms. E.g. Firewall, Cryptographic tools, IDS, etc. 4) Personal management tools and products to manage the logical entities as well as the physical entities related to it. E.g. Job descriptions, roles, access control list, SAML for exchanging security information between business partners over the internet, XACML for expressing information system access policy. 5) Locator tools to locate nodes, addresses, etc. and standards to be implemented in the security technology infrastructure like SSL, TLS, IPSEC, DNSSec, etc. 6)

Service Management architecture: 1) Assurance that the business attributes are being provided at a level compatible with the performance target set for each one. 2) Operational risk management using the tools and products for risk analysis, risk monitoring and reporting so as to minimize the impact of risks identified. 3) Management and support of the security services, applications and systems. E.g. Security monitoring using IDS, IPS, User security administration using active directory management tools, etc. 4) Personnel management like account provisioning, support for security related needs of the user. 5) Management of the environment including the security technology infrastructure (network), building, sites, etc. 6)