CISSP - Security Engineering Tutorial

1 Domain 03—Security Engineering

Hello and welcome to Domain 3 of the CISSP certification course offered by Simplilearn. This domain provides an introduction to Security Engineering. Let us explore the objectives of this domain in the next screen.

2 Objectives

After completing this domain, you will be able to: ?Describe Architecture Frameworks ?Describe Security Models ?List the types of Evaluation Criteria ?Describe System Security Architecture ?List the types of Distributed Systems Let us discuss a case study on Security Architecture and Design in the next screen.

3 Security Architecture and Design - Case Study

Kevin Butler, Security Administrator in the Network Firewalls division at Nutri Worldwide Inc. read the internal case study on Security Architecture and Design. In the last financial year, Nutri Worldwide Inc. expected a large increase in IT infrastructure requirements. The management felt the need to implement best practices for IT service management. Hilda Jacob, General Manager of IT security was assigned the task of selecting the best framework to help the organization identify, plan, deliver, and support IT services. Hilda decided to select the ITIL framework. Let us discuss the advantages of Security Engineering in the following screen.

4 Security Engineering

Security Engineering helps in: ?building information systems and the related architecture; ?delivering the required functionality with the existence of threats to the information systems; and ?incorporating security controls, capabilities, and behaviors into enterprise architecture and information systems, which in turn address the security principles of confidentiality, integrity, and availability. Let us discuss the concepts of Architecture Framework in the following screen.

5 Architecture Framework

In this screen, we will look at the definition of architecture framework in detail. ISO 42010 defines architecture framework as: “An architecture framework establishes a common practice for creating, interpreting, analyzing, and using architecture descriptions within a particular domain of application or stakeholder community” ( pronounce – I-S-O- 4-2-0-1-0) The role of the security architect is to translate business requirements into security solutions for key assets. Designs are created using standardized methodologies to maintain consistency between different architects. To ease the acceptance of their designs, security architects can take advantage of common architecture frameworks used across multiple industries and disciplines. An architecture framework provides a structure used for developing a broad range of security designs. The common features of an architecture framework are: It describes a method for designing a target state as an integrated set of systems or system components. It provides a set of tools to ease architecture development. It provides a common vocabulary. It also frequently includes a set of recommended standards and operational practices. It may also include information on compliant vendor products, modules, or components that can be used as design elements within the framework. In the subsequent screen, we will talk about the common architecture frameworks.

6 Zachman Framework

The Zachman Framework provides a formal and highly structured way of viewing and defining an enterprise. The Framework is named after its creator John Zachman, who first developed the concept in the 1980s. It has been updated several times since. It consists of a two-dimensional classification matrix based on the intersection of six communication questions; What, Where, When, Why, Who, and How with six rows according to reification transformations. It is a comprehensive representation of an information technology enterprise represented by a logical structure. It allows for multiple categorization and perspectives of business artifacts. It is not a methodology and does not imply any specific method or process for collecting, managing, or using the information that it describes. The Zachman "Framework" is a schema for organizing architectural artifacts or design documents, specifications, and models that takes into account whom the artifact targets (for example, business owner and builder), and what particular issue (for example, data and functionality) is being addressed.


The Open Group Architecture Framework or TOGAF provides a comprehensive approach for designing, planning, implementation, and governance of enterprise architecture. TOGAF is a registered trademark of The Open Group in the United States and other countries. The framework is a high level and holistic approach to design, modeled at four levels: Business, Application, Data, and Technology. It tries to give a well-tested starting model to information architects, which can then be built upon. The Open Group Architecture Framework heavily relies on modularization, standardization, and already existing, proven technologies and products.


The IT Infrastructure Library or ITIL is the widely adopted approach for IT Service Management in the world. It provides a practical, candid framework for identifying, planning, delivering, and supporting IT services to the business. ITIL advocates that IT services must be aligned to the needs of the business and underpin the core business processes. It provides guidance to organizations on how to use IT as a tool to facilitate business change, transformation, and growth. The ITIL best practices are currently detailed within five core publications, which provide a systematic and professional approach to the management of IT services. The five core guides map the entire ITIL Service Lifecycle, beginning with the identification of customer needs and drivers of IT requirements, through to the design and implementation of the service into operation and finally, on to the monitoring and improvement phase of the service. IT contains service strategy, service design, service transition, service operation, and continual service improvement as the five service management practices. Adopting ITIL can offer users a huge range of benefits that include: improved IT services, reduced costs, improved customer satisfaction through a more professional approach to service delivery, improved productivity, improved use of skills and experience, and improved delivery of third party service.

9 Creating a Security Architecture

In this screen, we will look at the steps involved in creating security architecture. Capturing and Analyzing Requirements The security architect needs to determine carefully the business requirements from the key stakeholders and reviewers before the design phase. The architect should start with establishing key principles and guidelines for the design. The security architect will also need to establish detailed requirements in addition to any principles or guidelines. Requirements can be either functional or non-functional. Functional requirements address what the design must do or accomplish. Nonfunctional requirements focus on the qualities of the service. Principles, guidelines, and detailed requirements must be signed off by an appropriate authority such as an executive sponsor or a senior leader. Sign-off is necessary if the principles, guidelines, and requirements are used as a guide in the next phase, which is the creation of security designs. Success or failure of the security design will depend on this stage. Creating and Documenting Security Architecture The architect can start creating suitable designs based on the defined requirements. The architect should be able to provide designs that appeal to a variety of stakeholders. The designs are to be presented as a set of deliverables, including technical specifications, modeling documents, presentations, and executive summaries. Security architects can rely on reference architectures, international standards and best practices, and regulations and legislation mandating good practices for information security as a starting point for their designs. Security architects use COBIT’s core security services and structure for design and implementation. With Control Objects for Information and Related Technology or COBIT, the architect reduces the need for audit support, and allows current control gaps to be addressed as a part of any architecture. COBIT is a framework for IT management, which was created by the Information Systems Audit and Control Association (ISACA), and the IT Governance Institute (ITGI). COBIT (read as KOBIT) provides a set of generally accepted processes to assist in maximizing the benefits derived by Information Technology (IT) and developing appropriate IT governance. Verifying Security Architecture The security architecture should be evaluated to ensure it has effectively addressed the documented requirements. The evaluation can be done through a peer review or a complex series of tests to ensure the design is robust. Vendor products are also evaluated using international standardized product evaluation criteria. It can also be tested in its intended deployment environment and certified before running in production. In the next screen, we will discuss Security Standards.

10 Enterprise Security Architecture

Let us move to the next topic Enterprise Security Architecture. This topic describes how to ensure business strategy and IT security are aligned. In this topic, we will define Enterprise Security Architecture (ESA) and list the common security services in ESA. We will also discuss the Sherwood Applied Business Security Architecture Framework and SABSA Matrix. Enterprise Security Architecture or ESA implements the building blocks of information security infrastructure across the entire organization. The primary purpose of creating enterprise security architecture is to ensure that business strategy and IT security are aligned. It focuses on a strategic design for a set of security services that can be leveraged by multiple applications, systems, or business processes. Goals and Objectives of enterprise security architecture are: Long-term view of control—a good architecture must be comprehensive and simple to ensure the organization gets the right level of control to address the most common risks. It must also avoid unnecessary duplication of services or complexities that could compromise the business benefits of the security services. It must be able to address control requirements as they evolve over time. Unified vision for common security controls—by providing this common services model, the architecture looks at security controls from a holistic view, identifying potential gaps in those controls, and providing a long-term plan for improvement. Existing technology investment—by focusing on what the organization has already deployed; the architecture can take full advantage of the internal skill sets and minimize the need for training or staff augmentation. Flexible approach—the implementation of the architecture should be flexible enough to provide safeguards and countermeasures for current and emerging threats. Let us look at some common security services in ESA in the next screen.

11 Common Security Services in ESA

There are a number of security functions that are suitable as foundations for common security services in the enterprise. The following is a sample classification of common security services that may be used as building blocks in Enterprise Security Architecture or ESA Boundary Control Services—These services are concerned with whether information is allowed to flow from one set of systems to another, or from one state to another. Access Control Services—These services focus on the identification, authentication, and authorization of subject entities (whether human or machine) as they are deployed and employed to access the organization’s assets Integrity Services—Integrity services focus on the maintenance of high-integrity systems and data through automated checking to detect and correct corruption Cryptographic Services—Cryptographic services focus on common services that can be deployed and reused by a variety of systems like Public Key Infrastructure or PKI. Audit and Monitoring Services—These services will focus on the secure collection, storage, and analysis of audited events through centralized logging as well as the events themselves through intrusion detection systems and similar services. In the next screen, we will look at Sherwood Applied Business Security Architecture Framework or SABSA.

12 SABSA Framework

Sherwood Applied Business Security Architecture Framework or SABSA is intended to follow the same basic outline provided by Zachman. 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 process analyzes the business requirements at the outset, and creates a chain of traceability through the strategy and concept, design, implementation, and ongoing ‘manage and measure’ phases of the lifecycle to ensure that the business mandate is preserved. Framework tools are created from practical experience to support the whole methodology. We will continue our discussion on SABSA Framework in the next screen.

13 SABSA Matrix

The model is layered, with the top layer being the business requirements definition stage. At each lower layer, a new level of abstraction and detail is developed, from top to bottom the layers define the conceptual architecture, logical architecture, physical architecture, the selection of technologies and products (component architecture) and finally at the lowest layer service management architecture. The SABSA model is generic and can be the starting point for any organization. However, by going through the process of analysis and decision-making implied by its structure, it becomes specific to the enterprise, and is highly customized to a unique business model. It becomes in reality the enterprise security architecture, and it is central to the success of a strategic program of information security management within the organization. The SABSA Matrix: The primary characteristic of the SABSA Model is that everything must be derived from an analysis of the business requirements for security and risk management, especially those in which security has an enabling function through which new business opportunities can be developed and exploited. The risk management focus of SABSA embraces both the notion of opportunity and threat, and the balance that must exist between these two concepts. The model is layered, with the top layer being the business requirements definition stage. At each lower layer a new level of abstraction is developed, from top to bottom the layers define the conceptual architecture, logical architecture, physical architecture, the selection of technologies and products (component architecture) and finally at the lowest layer service management architecture —in other words, the shopping list (in the building trade known as the ‘bill of materials’). In addition, the whole area of security service management, administration, and operations is addressed through the operational or ‘service management’ architecture. In the figure, each of the six horizontal layers of abstraction of the architecture model (contextual, conceptual, logical, physical, component, and service management) has been depicted. Each of the sections has a series of vertical cuts through each of these horizontal layers, answering the questions: What are you trying to do at this layer?—The assets to be protected by your security architecture. Why are you doing it? —The motivation for wanting to apply security, expressed in the terms of risk. How are you trying to do it?—The processes and functions needed to achieve security. Who is involved?—The people and organizational aspects of security. Where are you doing it?—The locations where you apply your security. When are you doing it?—The time-related aspects of security. These six vertical architectural elements are now summarized for all six horizontal layers. This gives a 6 x 6 matrix of cells, which represents the whole model for the enterprise security architecture. It is called the SABSA Matrix (see chart). If you can address the issues raised by each of these cells, then you will have covered the entire range of questions to be answered, and you can have a high level of confidence that your security architecture will be complete. The SABSA process of developing enterprise security architecture is a process of populating all of these thirty-six cells. The SABSA Matrix also provides two-way traceability: Completeness: has every business requirement been met? The layers and matrix allow you to trace every requirement through to the components that provide a solution. Business Justification: is every component of the architecture needed? When someone questions ‘Why are we doing it this way?’ the rationale is plain by tracing the business requirements that drive the specific solution.

14 Business Scenario

Slide 14: Business Scenario Hilda Jacobs, General Manager IT Security is developing Enterprise security architecture for Nutri Worldwide Inc. The organization has offices located across many countries. They wanted to implement a uniform security control system throughout the enterprise with a business mandate to be preserved by a chain of traceability. Hilda is looking for reference architecture to begin her work. Kevin had been a great contributor in her last project. She assigned this task to Kevin. Which enterprise security architecture (ESA) framework should Kevin suggest in this scenario? SABSA framework will help develop ESA for Nutri Worldwide Inc.

15 ISO/IEC 27001:2013 Security Standards

Information Security Management System or ISMS is defined as the governance structure supporting an information security program. ISO/IEC 27001:2013 is focused on the standardization and certification of an organization’s ISMS. This standard is focused on the following ten key areas: •Scope of the standard •How the document is referenced •Reuse of the terms and definitions in ISO/IEC 27000 •Organizational context and stakeholders •Information security leadership and high-level support for policy •Planning an information security management system, risk assessment, and risk treatment •Supporting an information security management system •Making an information security management system operational •Reviewing the system's performance •Corrective actions In the next screen, we will discuss ISO/IEC 27002 Code of Practice for Information Security Management.

16 ISO/IEC 27002—Code of Practice for Information Security Management

ISO/IEC 27002 provides a “Code of Practice for Information Security Management,” which lists security control objectives and recommends a range of specific security controls according to the industry best-practice. Following are the focus areas of ISO/IEC 27002: •Information security policies which include two controls •Organization of information security which includes seven controls •Human resource security which includes six controls that are applied before, during, or after employment •Asset management which includes 10 controls •Access control which includes 14 controls •Cryptography which includes two controls •Physical and environmental security which includes 15 controls •Operations security which includes 14 controls •Communications security which includes seven controls •System acquisition, development, and maintenance which include 13 controls •Supplier relationships which include five controls •Information security incident management which includes seven controls •Information security aspects of business continuity management which includes four controls •Compliance with internal requirements such as policies and external requirements such as laws which include eight controls Let us discuss the concept of security models in the next screen.

17 Security Models

The next topic is Security Models. Security Models are the rules to be implemented to support and enforce security policy. In this topic, we will define Security Models, discuss Common Security Models, and look at few examples of Security Models. A security model is a specification that describes the rules to be implemented to support and enforce the security policy. A formal security model describes and verifies the ability to enforce security policy in mathematical terms formally. Given the demands of formal verification, most models are focused on system-level security architecture at the component level. In most cases, it would be too difficult or time-consuming to formally verify all aspects of large-scale security architectures. A CISSP candidate is expected to understand the general types of security models as well as some specific examples. It is essential to remember the ultimate goal addressed by the model and how each new model builds on the information provided by earlier models. In the next screen, we will look at the State machine model.

18 State Machine Model

State machine model describes the behavior of a system as it moves between one state and one moment, to another. State describes a system at a point of time. When used in security modeling, the purpose is to define which actions will be permitted at any point of time to ensure that a secure state is preserved. For example, if any component in the OS or firewall fails it must fail to a secure state

19 Multilevel Security Models

Multilevel security models describe the strict layers of subjects and objects and define clear rules that allow or disallow interactions between them, based on the layers they are in. These are often described using lattices, or discrete layers with minimal or no interfaces between them. Higher the secrecy, more constraints on the data, and lower the secrecy, less constraints on the data. These models not only address obvious and intentional interactions between subjects and objects, also deal with the effects of covert channels that may leak information inappropriately. For example, a file server contains documents at three different levels of security: Confidential, Secret, and Top Secret. The users of the system are registered as being in one of the three levels of clearance: Confidential, Secret, and Top Secret. A user with Secret clearance can view documents at Confidential and Secret levels, however not at Top Secret level. A user with confidential clearance can only view confidential documents. A user with Top Secret clearance can view all documents.

20 Matrix-Based Model

Matrix-based model focuses on one-to-one relationships between subjects and objects. Most Matrix-based model provides more than simple binary rules (such as allow or deny). Sometimes it is beneficial to specify how the access will be performed or what capabilities the subject will require. Some subjects are allowed read only, while others can read and write. The list of access methods relevant to the organization for content are read, write, edit, and delete. The best-known example is the organization of subjects and objects into an access control matrix. An access matrix security model consists of a two-dimensional matrix that defines subject to object access permission. An example of access matrix is shown in the table.

21 Non-Interference Model

Non-interference model’s goal is to ensure high-level actions (inputs) do not determine what low-level users can see (outputs). The model helps to cover ways to prevent subjects operating in one domain from affecting each other in violation of security policy. The non-interference model states that low inputs and outputs will not be altered by any high inputs or outputs. In other words, a user with low clearance cannot gain any knowledge of any activities performed by high-clearance users. The term non-interference means activities performed by a user with high clearance will not interfere with any activities performed by a user with low clearance.For example, if a low clearance user is working on the machine, it will respond in exactly the same manner irrespective of whether a high clearance user is working with sensitive data. The low user will not be able to acquire any information about the activities (if any) of the high user.

22 Information flow model

Information flow model focuses on how information is allowed or not allowed between individual objects. Information flow model is used to determine if information is appropriately protected throughout a given process. They are based on the flow of information than on access controls. Objects are assigned to a class or level of security, and the flow of these objects is controlled by a security policy that specifies where objects of various levels are permitted to flow. For example, Information flows within the system during memory swapping, paging, from memory to hard-drive, pen drive, etc. This model checks the presence of any covert channel within the code.

23 Examples of Security Models: Bell–LaPadula Confidentiality Model

In the next few screens, we will discuss examples of security models. Let us start with Bell–LaPadula Confidentiality Model. Bell–LaPadula Confidentiality Model is focused on maintaining the confidentiality of objects. Its primary goal is to prevent disclosure as the model system moves from one state (one point of time) to another. Bell-LaPadula includes the following rules and properties: The Simple Security rule states that a subject cannot read data at a higher security level than they are cleared for. A subject can read all documents at or below the level of specified security; however, the subject cannot read any documents above the specified level of security. This is called No Read-Up, or NRU (read as N-R-U). The rule prevents subjects from learning secrets at a higher level than their own. For example, a diplomat can read documents intended for common citizens, however, cannot read documents intended for the President. The Star Property rule states that a subject cannot write data to an object at a lower security level. The subjects can write (create/modify) (read as “create-or-modify”) documents at or above their level of security, however, cannot write documents below their level. This is called No Write-Down, or NWD (read as N-W-D). This rule prevents subjects from accidentally leaking secrets at their level, into a document at a lower level. For example, a diplomat can write documents intended for the President, however, cannot write documents for common citizens, out of concern that the diplomat may accidentally leak sensitive information to the common citizens. The Strong Star Property rule states that a subject can perform read and write functions only to the objects at its same security level. Some of the limitations of this model are the following: It only considers confidentiality and does not mention other properties (such as integrity and availability), or more sophisticated modes of access. It does not address important confidentiality goals such as need-to-know, and the ability to restrict access to individual objects based on a subject’s need to access them. It does not provide a mechanism for a one-to-one mapping of individual subjects and objects.

24 Examples of Security Models: Biba Integrity Model

We will talk about another example, Biba Integrity Model, in this screen. Biba integrity model protects the integrity of the information within a system and the activities that take place. It addresses the first goal of integrity. Biba is often considered as the first formal integrity model as it prevents modifications of data by unauthorized persons. It is also known as data integrity model. Biba addresses a shortcoming in the Bell—LaPadula model whereby a subject at a lower security level is able to overwrite, and potentially destroy secret information at a higher level. Using the invocation property, Biba also addresses the problem of one subject getting a more privileged subject to work on their behalf. The following are the axioms of Biba integrity model: The Simple Integrity Axiom states that a subject cannot read data at a lower integrity level. The subjects cannot read documents below their level. This is called No Read Down, or NRD. For example, a diplomat can read documents written by the President but cannot read documents written by common citizens. The Star Integrity Axiom states that a subject cannot modify an object at a higher integrity level. This is called No Write-Up, or NWU. For example, a diplomat can write procedures to be read by common citizens but cannot write procedures to be read by the President.

25 Examples of Security Models: Clark–Wilson integrity model

In this screen, we will discuss another example of security models, Clark–Wilson integrity model. The Clark–Wilson model addresses the shortcomings in the Biba model by focusing on integrity at the transaction level and addressing three major goals of integrity in a commercial environment. The Clark–Wilson integrity model provides a foundation for specifying and analyzing an integrity policy for a computing system. The model is primarily concerned with formalizing the notion of information integrity. Information integrity is maintained by preventing corruption of data items in a system due to either error or malicious intent. An integrity policy describes how the data items in the system should be kept valid from one state of the system to the next and specifies the capabilities of various principals in the system. The model defines enforcement rules and certification rules. It addresses three goals of integrity, which are: Subjects can access objects only through authorized programs or access triple, Separation of duties is enforced, and Auditing is required. We will talk about the last examples of security models, Brewer–Nash, Graham–Denning, and Harrison–Ruzzo–Ullman models in the next screen.

26 Brewer–Nash, Graham–Denning, and Harrison–Ruzzo–Ullman models

Following are other important security models: The Brewer and Nash model was constructed to provide information security access controls that can change dynamically. This security model is also known as the Chinese Wall model. It was designed to provide controls that mitigate conflict of interest in commercial organizations. The Brewer and Nash Model is built upon an information flow model. In this model, no information can flow between the subjects and objects in a way that would create a conflict of interest. The Graham-Denning Model is a computer security model that shows how subjects and objects should be securely created, deleted, assigned rights or privileges, and how ownership of objects is managed. It also addresses how to assign specific access rights. This model is mainly used in access control mechanisms for distributed systems. The Harrison–Ruzzo–Ullman Model is similar to the Graham–Denning model. This model is composed of a set of generic rights and a finite set of commands. It is also concerned with situations where a subject should be prevented from ever gaining particular privileges. To do so, subjects are prevented from accessing programs or subroutines that can execute a particular command (for example, to grant read access).

27 Business Scenario

Kevin Butler, the security administrator at Nutri Worldwide Inc. wants to setup different accesses to a set of folders on a network. The access should be such that some of his colleagues will have read and write access, while others are allowed read only access to the files in the folder. Kevin starts the process of selecting a security model. Which security model should Kevin Butler implement in the given scenario? The one-to-one relationship among subjects and objects is the focus of Matrix-based model. Kevin should choose the Matrix-based model.

28 Evaluation Criteria

Let us move on to our next topic that is evaluation criteria, which are established for the purpose of objectively evaluating the security of a system. In this topic, we will, describe Evaluation Criteria and its uses, list the types of evaluation criteria, and discuss certification and accreditation. We will also look at SEI—CMMI in this topic as well. Evaluation methods and criteria are designed to gauge the real-world security of systems and products. The following are the uses of evaluation criteria: Evaluation methods and criteria are designed to measure the real-world security of products and systems. It provides a common mechanism to evaluate vendor products by certified third-party evaluation labs. The products are tested against a set of security requirements and the findings (rating) are published. The primary use of evaluation criteria is it gives a level of security assurance attached to the product. Customers can select products based on the evaluation rating. Let us look into the various types of evaluation criteria.


The Trusted Computer System Evaluation Criteria or TCSEC sets the basic standard for the implementation of security protection in computing systems. It was strongly focused on enforcing confidentiality with no focus on other aspects of security such as integrity or availability. TCSEC was used to evaluate, classify, and select computer systems being considered for the processing, storage, and retrieval of sensitive or classified information on military and government systems. To assist with the evaluation of secure products, TCSEC introduced the idea of the Trusted Computing Base (TCB) into product evaluation. The TCB comprises all the protection mechanisms within a system (software, hardware, and firmware). All of these mechanisms need to work in an orchestrated way to enforce all the requirements of a security policy. When evaluated, these mechanisms are tested, their designs are inspected, and their supporting documentation is reviewed and evaluated. Each of the TCSEC levels describes a different set of fundamental functions that must be in place to be certified to that level. The Assurance ratings defined are used to rate products. The main ratings are displayed on the screen. Importantly, it is the move from DAC to MAC between the C levels and B levels. Most commercial, general-purpose computing systems, were never intended for MAC and could only achieve a C2 rating. The more rigid requirements for the higher B and A levels also had the effect of limiting the size and scope of the systems being evaluated, and made it highly impractical for them to be used in the development of highly complex, distributed systems. The Trusted Network Interpretation (TNI) brings TCSEC concepts into the network systems. It is often called the Red Book due to the color of its cover. Note that TCSEC (Orange Book) does not address network issues. In the next screen, we will discuss the information technology security evaluation criteria.

30 Information Technology Security Evaluation Criteria

Information Technology Security Evaluation Criteria or ITSEC addresses confidentiality, integrity, and availability, whereas TCSEC evaluates only confidentiality. Security requirements are not prescribed in ITSEC; the consumer or the vendor has the ability to define a set of requirements from a menu of possible requirements into a Security Target or ST. Vendors develop products which are referred as Target of Evaluation or TOE and evaluate them against the target. ITSEC provides two sets of levels that are evaluated separately. They are: functional and assurance. Functionality implies whether the system is capable of serving a purpose well. Assurance implies the confidence the organization has in their security methods and the capability to perform consistently. It is tested by examining development practices, documentation, configuration management, and testing. In ITSEC, the Functional levels range from F1 to F10 and the Assurance levels range from E1 to E6. Let us discuss the common criteria for information technology security evaluation in the next screen.

31 Common Criteria

One of the most important evaluation criteria is Common Criteria (CC) for Information Technology Security Evaluation. It is the official name for the international standard ISO/IEC 15408. The International Common Criteria represent an international set of specifications and guidelines developed for evaluation of information security products, especially to ensure that the agreed-upon security standard for government deployments are met. The thorough evaluation of computer security product is assured by rigorous evaluation of process of implementation, specification, and testing of computer security products. This standard is designed to avoid requirements beyond the current state of the art; it presents a hierarchy of requirements for a range of classifications and systems. The Common Criteria are the result of the second major international information security criteria effort, following ITSEC. They use ITSEC terms such as Target of Evaluation and Security Target. CC supersedes TCSEC and ITSEC. Let us look into the evaluation process of common criteria.

32 Common Criteria Evaluation Process

The Common Criteria use the following specific terms when defining specific portions of the testing process: Protection Profile (PP): It is an independent set of security requirements and objectives for a specific category of products or systems, such as firewalls and intrusion detection systems. Target of Evaluation (ToE): It is the system or product, which is being evaluated. Security Target (ST): It is the documentation describing the Target of Evaluation TOE, including security requirements and operational environment. Evaluation Assurance Level (EAL): It is the evaluation score of the tested product or system. In the next slide, we will discuss the common criteria levels.

33 Common Criteria Levels

Target of Evaluation or TOE is evaluated against one of seven Evaluation Assurance Levels (EALs). The EAL level is intended to provide the consumer or the vendor with some idea of how confident they should be in the results of the evaluation, based on how much information was available to the evaluation lab, and how carefully was the system examined. The EALs are as follows: EAL 1: Functionally tested EAL 2: Structurally tested EAL 3: Methodically tested and checked EAL 4: Methodically designed, tested, and reviewed EAL 5: Semiformally designed and tested EAL 6: Semiformally verified, designed, and tested EAL 7: Formally verified, designed, and tested EALs are frequently misunderstood to provide a simple means to compare security products with similar levels. Even if assigned the same EAL, products may be different, since the functionality may have little in common. We have covered three types of evaluation criteria so far. Let us now discuss the last type, i.e., the Payment Card Industry Data Security Standard.

34 Payment Card Industry Data Security Standard

The Payment Card Industry Data Security Standard or PCI-DSS was created by the Payment Card Industry Security Standards Council or PCI-SSC. PCI-SSC is made up of American Express, Discover, Master Card, Visa, and others. It is intended to help organizations proactively protect customer account data. It seeks to protect credit cards by requiring vendors using them to take specific security precautions. PCI-DSS includes requirements for security management, policies, procedures, network architecture, software design, and other critical protective measures. With this, we have covered all the four types of evaluation criteria. Let us now move on to the certification and accreditation process to evaluate the system.

35 Certification and Accreditation

Certification and accreditation or C&A (read as C and A), is the process used to evaluate and approve a system for use. These activities are usually found in government and military environments, and in highly regulated industries such as pharmaceuticals and aeronautics. Certification and accreditation is a two-step process: Certification— It is the process of evaluation of a system’s architecture, design, and controls, according to the established evaluation criteria. Accreditation— It is the formal management decision to approve the use of a certified system.

36 Certification and Accreditation Standards

The following are the Standards for certification and accreditation: FISMA stands for Federal Information Security Management Act of 2002 (read as Twenty Two). It is a law that requires all United States federal information systems to conform to security standards and processes used to evaluate them. DITSCAP stands for Department of Defense Information Technology Security Certification and Accreditation Process. It is the process used to certify and accredit information systems used by the United States military. DIACAP stands for the Department of Defense Information Assurance Certification and Accreditation Process. It is the successor to Department of Defense Information Technology Security Certification and Accreditation Process, and is used to certify and accredit military information systems. NIACAP stands for National Information Assurance Certification and Accreditation Process. It is the process used to certify and accredit systems that handle U.S. (read as U-S) national security information. DCID 6/3 (read as D-C-I-D six by three) stands for Director of Central intelligence Directive 6/3. It is the process for protecting sensitive compartmented information within information systems at the United States Central Intelligence Agency or CIA. This directive defines security standards, classification levels, and the C&A process for certifying and accrediting information systems.


We will look at Software Engineering Institute Capability Maturity Model Integration in this screen. Security designs are required to be assessed and updated to tackle the continuously evolving and new vulnerabilities. It may start over from the beginning where the business requirements for security have changed. A strong architecture method will need to be in place to gather feedback and manage such changes over time. Examples are CMMI (read as C_M_M_I), ITGI (read as I-T-G-I), etc. The ITGI Information Security Governance Maturity Model is used to rank organizations against both industry best practices and international standard guidelines, from a maturity perspective. SEI–CMMI stands for Software Engineering Institute—Capability Maturity Model Integration. Capability Maturity Model Integration or CMMI is a process improvement approach whose goal is to help organizations improve their performance. It can be used to guide process improvement across a project, a division, or an entire organization. CMMI in software engineering and organizational development is a process improvement approach that provides organizations with the essential elements for effective process improvement. CMMI is registered in the U.S. Patent and Trademark Office, by Carnegie Mellon University. It was developed by a group of experts from industry, government, and the Software Engineering Institute (SEI) at Carnegie Mellon University. CMMI models provide guidance for developing or improving processes that meet the business goals of an organization. A CMMI model may also be used as a framework for appraising the process maturity of the organization.

38 SEI—CMMI Levels

There are five maturity levels defined along the continuum of the CMMI. Level 1—Initiating—It is the starting point for use of a new or undocumented repeat process Level 2—Repeatable—The process is documented sufficiently so that repeating the same steps may be attempted. Level 3—Defined—The process is defined or confirmed as a standard business process, and decomposed to levels 0, 1 and 2, the latter being Work Instructions. Level 4—Managed—The process is quantitatively managed in accordance with agreed-upon metrics. Level 5—Optimizing—The process management includes deliberate process optimization/improvement.

39 Business Scenario

The product release reports for the last year indicated a lag in product releases in comparison to the product releases done by Nutri Worldwide’s competitors in the respective categories. The management felt the need to use SEI-CMMI process improvement model to improve engineering and project management processes. Hilda Jacobs, IT Manager at Nutri Worldwide led this initiative, and Kevin volunteered to be a part of this so that he could apply what he had learned about SEI-CMMI process real time. Kevin worked with the team that listed the engineering process areas. They were Requirements Development, Product Integration, Technical Solution, Requirements Management, Verification, and Validation. They also selected Project Planning, Control, and Monitoring. Hilda identified the processes from the list the processes which require continuous improvement, and important to the organization’s business objectives. How many levels of process improvement would have been followed by the team led by Hilda? There are five levels defined by SEI-CMMI for process improvement.

40 System Security Architecture

We will start with the next topic System Security Architecture, which is designing security services within individual computing systems. In this topic, we will define System Security Architecture, list the Types of Computing Platforms and also identify the System Components. System security architecture is focused on designing security services within individual computing systems. Security components can consume considerable resources; control is frequently sacrificed in favor of improved functionality, usability, or performance. There is a wide variety of computing platforms available and each platform will take a different approach to providing security services. The architecture of these platforms is fundamental to the ways that they approach security requirements. Most computing platforms will offer a wide variety of security controls to help protect sensitive assets being generated, transmitted, or stored by the system. The CISSP candidate should understand the basic building blocks that make up modern computing systems as well as some characteristics that distinguish types of systems from each other. Most importantly, they should be aware of the different ways security can be implemented at the system level and be able to choose which mechanisms would be most appropriate in a given scenario.

41 Mainframes and Other Thin Client Systems

Modern computing systems are comprised of layers of hardware, firmware, and software that work together to provide computing services. There are various computing platforms used and the basic building block is a system. Thus understanding the system security architecture is of prime importance. The different types of Computing Platforms are: Mainframes and Other Thin Client Systems Distributed Systems Middleware Embedded Systems Pervasive Computing and Mobile Computing Devices In mainframes, processing occurs within a large centralized system. The clients are limited to keyboard and mouse emulation, graphics processing, and basic networking functions. This has the benefit of centralizing most functions (including most security functions) while allowing the client to focus on user interaction and networking. In distributed environments, users log into their own computer and data is saved locally or remotely at various sites. There is no central authority to manage user authentications and accounts or data storage. Distributed environments support a wide range of diverse software applications, real-time data access, and varied media formats and data storage. Middleware is connectivity software that enables interaction of multiple processes running on one or more machines. These services are collections of distributed software that are present between the application running on the OS, and the network services which reside on a network node. The main purpose of middleware services is to help solving many application connectivity and interoperability problems.

42 Middleware and Embedded Systems

Embedded systems are used to provide computing services in a small form factor with limited processing power. They embed the necessary hardware, firmware, and software into a single platform that can be used to provide a limited range of computing services. Pervasive Computing and Mobile Computing devices share common security concerns with other resource-constrained devices.

43 Pervasive Computing and Mobile Computing Devices

Common concerns are: Security services are sacrificed to provide richer user interaction when processing power is limited. Another concern is data loss because of transmitting and storing information in ways which are uncontrollable.

44 System Components—Processors

Security functions have been distributed across the following system components which ensure that the system can secure information effectively. The main system components in a computing system are: Processors, Memory, Storage, Trusted Computing Base (TCB), Reference Monitor, Trusted Platform Module, Peripherals and Other Input/Output Devices, Operating System, Ring Model, and System Kernel. Processors. They ensure that the system instructions were performed and the interactions between memory, storage, and input—output devices were controlled. Processors perform the following four main operations: Fetching—The CPU fetches information from memory, i.e., instructions and data. Decoding—It decodes the instructions to decipher next steps. Executing—It executes the instructions, e.g., calculating numbers. Storing—It stores the results of the instruction. This cycle repeats until there are no further instructions to be executed.

45 System Components—Memory

Memory refers to the physical devices used to store programs or sequences of instructions, or data on a temporary or permanent basis. There are two main types of semiconductor memory. They are: volatile and non-volatile. Examples of volatile memory are primary memory which includes static RAM and dynamic RAM, and fast CPU cache memory. Examples of non-volatile memory are flash memory and ROM/PROM/EPROM/EEPROM. Firmware is stored in non-volatile memory. Primary memory stored on secondary memory such as hard drive is called "virtual memory." Virtual memory uses RAM and secondary storages such as hard drive. In the following screen, we will focus on storage.

46 System Components—Storage

The term storage is often used to describe secondary memory such as tape, hard disk, magnetic disks and optical discs (CD-ROM and DVD-ROM). Storage is used to store data for longer time. It is much larger in storage capacity but slower compared to RAM.

47 System Components—Trusted Computing Base (TCB)

Trusted Computing Base or TCB (read as T-C-B). It is defined as the hardware, firmware, operating system, and software that effectively support security policy. All code that runs in the privileged mode of the underlying processor is part of the TCB. For example, in a Linux system, any daemon running as root would be part of the TCB.

48 System Components—Reference Monitor

Reference Monitor. It is a hardware or software component in a system that mediates access to objects according to their security level or clearance. A reference monitor is an auditable access control mechanism. It creates a record of its activities that can be examined at a later time. All sensitive operations are routed through the reference monitor and which in turn decides if the operation should proceed. For example, Most operating systems like Windows and Linux have reference monitors.

49 System Components—Trusted Platform Module (TPM)

Trusted Platform Module or TPM (read as T-P-M). It is the implementation of a secure crypto-processor, a separate microprocessor in the computer that stores and generates cryptographic keys. It generates random numbers for use in cryptographic algorithms. TPM is used for a variety of cryptographic functions such as disk encryption and authentication. For example, Microsoft's operating systems like Windows Vista, Windows 7, and Windows 8 as well as Microsoft Windows Servers like Windows Server 2008, use the chip in conjunction with the included disk encryption software named BitLocker.

50 System Components—Peripherals and Other Input/Output Devices

Peripherals and Other Input/Output Devices. Peripherals are those Input-output devices which are used to enter information and instructions into a computer for storage or processing, and to deliver the processed data to a human operator or, a machine controlled by the computer. An input device converts data and instructions into a pattern of electrical signals in binary code that are comprehensible to a computer. Input devices can be a keyboard, mouse, scanner, etc. An output device translates the digitized signals into a form comprehensible to the user. Output devices may be computer displays, speaker systems, laser printers, etc.

51 System Components—Operating System

Operating System or OS (read as O-S). It is the software that controls the operation of the computer. The OS controls all input and output to and from the peripherals, as well as the operation of other programs. It allows the user to work with and manage files without knowing specifically how the data is stored and retrieved. In multiuser systems, OS manage user access to the processor and peripherals and schedule jobs. Examples of OS are Microsoft Windows, Apple’s Mac OS X, various versions of UNIX and Linux, and mainframe systems commonly using proprietary OS, developed by their manufacturers.

52 System Components—Ring Model

Ring model. It is a form of CPU hardware layering that separates and protects domains such as, kernel mode and user mode from each other. Many CPUs, for example, the Intel x86 family (read as Intel eighty six family) have four rings, ranging from ring 0 (kernel) to ring 3 (user). The innermost ring is the most trusted; each successive outer ring is less trusted. Processes communicate between rings via system calls, which allow the processes to communicate with the kernel and provide a window between rings.

53 System Components—System Kernel

Kernel. It is called as the heart of the operating system, usually runs in ring 0. It provides the interface between hardware and the rest of the operating system, including applications. It supplies the vital services such as loading and running binary programs, scheduling task swapping which allows computer systems to do more than one thing at a time, allocating memory, and tracking the physical location of files on the computer's hard disks. Kernels have two basic designs: monolithic and microkernel. A monolithic kernel is compiled into one static executable and all of it runs in supervisor mode. A microkernel is modular. It is usually smaller and has less native functionality than a typical monolithic kernel, hence micro. However, it can add functionality via loadable kernel modules.

54 Distributed Systems

We will move on to the next topic distributed systems, which is a software system. In this topic, we will, define distributed system and list the various types of distributed systems. Let us start with the definition of distributed systems in the next screen. Distributed Systems can be defined as a software system in which components distributed on networked computers pass messages to communicate and coordinate their actions. Servers, personal computers, workstations, etc., can be a part of distributed system. The goal is to make distributed network components work as a single computer

55 Virtualization

Virtualization is a technology that enables running multiple operating systems side-by-side on the same processing hardware. It adds a software layer between an operating system and the underlying computer hardware. Virtualization’s benefits include efficiency, higher availability, and lower costs. Full virtualization, partial virtualization, and para virtualization are the different types of hardware virtualization.

56 Hypervisor

Hypervisor or Virtual Machine Monitor VMM is a software, which is installed to virtualize a given computer. Host machine is a computer on which a hypervisor is installed and running virtual machines. Each virtual machine is known as guest machine Type 1 or native, bare metal hypervisors run directly on the host machine’s hardware to control the hardware and to manage guest OS. For example, Microsoft Hyper-V hypervisor, VMware ESX/ESXi ,etc. Type 2 or hosted hypervisors run within an existing operating system environment. Examples are VMware Workstation and Virtual Box.

57 Cloud Computing

Cloud Computing is a type of computing that depends on sharing computing resources over the internet instead of personal device or local servers handling applications.

58 Service models

The different types of Service models are: Infrastructure as a Service or IaaS: In this model, an organization outsources the equipment used to support operations, including storage, hardware, servers, and networking components. The service provider owns the equipment and is responsible for housing, running, and maintaining it. The client typically pays on a per-use basis. Example: Amazon EC2, Google Compute Engine, HP Cloud, etc., Platform as a service or PaaS: The provider provides the networks, servers, storage, and other services that are required to host the consumer's application. Examples are, Google App Engine, Windows Azure Cloud Services, etc. Software as a service or SaaS: It is a software delivery model in which software and associated data are centrally hosted on the cloud by Independent Software Vendors or ISVs or Application Service Providers or ASPs. Examples are, Google Apps, Microsoft Office 365 (read as three sixty five), etc.

59 Grid Computing

Grid Computing is the group of computer resources from many locations to achieve a common goal. It is a type of network-distributed parallel processing and large-scale cluster computing system.

60 Peer to Peer Networking (P2P)

Peer to Peer networking or computing (P2P) is a distributed application architecture that distributes workloads or tasks among peers. Peers have equal privileges in the application. The peers can transfer files among one another if they trust each other. Examples are, Gnutella, and BitTorrent.

61 Business Scenario

Hilda Jacobs, General Manager IT Security is under the pressure of bringing the IT infrastructure costs under control due to the increased cost of operations and reduced budgets. She takes a decision that networking components, storage, hardware, and servers that are used to support operations, will be outsourced. Hilda Jacobs requests quotations from various vendors to provide the services required by Nutri Worldwide Inc. She assigned the task of selecting the best service model that would suit this requirement to Kevin. This is a great opportunity for Kevin to apply his understanding of the different service models. Which service model should Kevin select based on the requirements of Nutri Worldwide Inc.? Platform as a Service would be the model Kevin should choose. This service model provides the networks, servers, storage, and other services that are required to host the consumer's application.

62 Security Threats and Countermeasures

The last topic of this domain is Security Threats and Countermeasures, which describes the security architecture and design vulnerabilities, and countermeasures to reduce the associated risk. In this topic, we will discuss the system vulnerabilities and threats and also list the best practices. Let us start with system vulnerabilities and threats in the next screen.

63 Assessing and Mitigating Vulnerabilities and Threats

It is important to assess and mitigate web-based and client-based vulnerabilities and threats. Web-based Vulnerabilities and Threats: Extensible Markup Language or XML is a World Wide Web Consortium or W3C standard for structuring data in a text file so that both the format of the data and the data can be shared on intranets and the Web. XML is vulnerable to injection attacks and thus the security architect must ensure input is validated and “normal” parameters are established in the design phases. Security Assertion Markup Language or SAML is an XML-based standard used to exchange authentication and authorization information. With weak implementation of SAML, an attacker can access a user’s account without authorization. Client-based Vulnerabilities and Threats: There are many threats and vulnerabilities associated with the use of mobile devices in an organization. The concept is known as Bring Your Own Device or BYOD . The security architect can make use of Mobile Device Management (MDM) to mitigate these threats and vulnerabilities. For Desktops, Laptops, and Thin Clients, the security architect must ensure security is designed assuming that the client system is infected. In the next screen, we will continue discussing how to assess and mitigate vulnerabilities and threats.

64 Assessing and Mitigating Vulnerabilities and Threats (contd.)

Server-Based Vulnerabilities: Servers are mostly targeted by attackers as it hosts sensitive information and thus the security architect must ensure a proper server hardening with appropriate access controls. The security architect must get acquainted with Data Flow Diagram (DFD) which indicates how data flows into and out of servers and then apply various security controls accordingly. Open Web Application Security Project: Open Web Application Security Project or OWASP is a non-profit organization which creates a list of globally identified top vulnerabilities in web applications and they provide a number of resources such as research, and security tools and guides. In the next screen, we will continue discussing how to assess and mitigate vulnerabilities and threats.

65 Assessing and Mitigating Vulnerabilities and Threats (contd.)

Network-Enabled Devices: Since the software in network-enabled devices allow the Media Access Control or MAC address to be set, any person with administrative privilege can alter the device MAC address. The security architect must consider employing a proper access control to prevent unauthorized access to the network enabled devices. Internet of Things: Internet of Things or IoT is the convergence of wireless technologies, micro-electromechanical systems (MEMS) and the internet in which unique identifiers will be provided to objects, people, or animals. It will allow data transfer over the network without the requirement of human-to-human or human-to-computer interaction, which increases data security and privacy issues. The security architect must ensure adequate security controls are implemented on various devices, systems, and applications. Let us discuss some of the best practices used to control system vulnerabilities and threats in the next screen.

66 Best Practices

In this screen, we will discuss the best practices, which can be used to control the System Vulnerabilities and Threats. The best practices are: Process isolation Data hiding Abstraction Cryptographic Protections Process isolation is a logical control that attempts to prevent one process from interfering with another. This is a common feature among multiuser op

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Phone Number*
Job Title*