NETWORK SECURITY HOMEWORK 1 Provide a definition of the following terms and expr

ID: 3665957 • Letter: N

Question

NETWORK SECURITY HOMEWORK 1

Provide a definition of the following terms and expression.

Single Sign-On (SSO)

Kerberos

Sesame

Business continuity Planning

Disaster Recovery Planning

What is the difference between Identification and Authentication?

Provide four examples of computer crime.

What are the key principles of Network Security?

Why do we use Access Controls for?

What means the term Defense-in-Depth?

How can you obtain a fairly accurate picture of the level of security awareness in an organization?

What are the Information Systems Security Engineering process?

Provide a definition of Access Controls.

What is Information Systems Security Management?

Explanation / Answer

Provide a definition of the following terms and expression.

Single Sign-On (SSO):

Single sign-on (SSO)is a session/user authentication process that permits a user to enter one name and password in order to access multiple applications. The process authenticates the user for all the applications they have been given rights to and eliminates further prompts when they switch applications during a particular session.

(or)

Single sign-on (SSO) is a property of access control of multiple related, but independent software systems. With this property a user logs in with a single ID and password to gain access to a connected system or systems without using different usernames or passwords, or in some configurations seamlessly sign on at each system. This is typically accomplished using the Lightweight Directory Access Protocol (LDAP) and stored LDAP databases on servers. A simple version of single sign-on can be achieved over IP networks using cookies but only if the sites share a common DNS parent domain.Conversely, single sign-off is the property whereby a single action of signing out terminates access to multiple software systems.

Kerberos:

Kerberos is a computer network authentication protocol which works on the basis of 'tickets' to allow nodescommunicating over a non-secure network to prove their identity to one another in a secure manner. The protocol was named after the character Kerberos (or Cerberus) from Greek mythology, the ferocious three-headed guard dog of Hades (hellhound). Its designers aimed it primarily at a client–server model and it provides mutual authentication—both the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks.Kerberos builds on symmetric key cryptography and requires a trusted third party, and optionally may use public-key cryptography during certain phases of authentication.Kerberos uses UDP port 88 by default.

Sesame:

SESAME (a Secure European System for Applications in a Multi-vendor Environment) is a European research and development project, part funded by the European Commission under its RACEprogramme. It is also the name of the technology that came out of that project.The SESAME technology offers sophisticated single sign-on with added distributed access control features and cryptographic protection of interchanged data.SESAME is a construction kit. It is a set of security infrastructure components for product developers. It provides the underlying bedrock upon which full managed single sign-on products can be built.

Business continuity Planning:

A business continuity plan is a plan to continue operations if a place of business is affected by different levels of disaster which can be localized short term disasters, to days long building wide problems, to a permanent loss of a building. Such a plan typically explains how the business would recover its operations or move operations to another location after damage by events like natural disasters, theft, or flooding. For example, if a fire destroys an office building or data center, the people and business or data center operations would relocate to a recovery site.

Disaster Recovery Planning:

A disaster recovery plan (DRP) is a documented process or set of procedures to recover and protect a business IT infrastructure in the event of a disaster.Such a plan, ordinarily documented in written form, specifies procedures an organization is to follow in the event of a disaster. It is "a comprehensive statement of consistent actions to be taken before, during and after a disaster." The disaster could be natural, environmental or man-made. Man-made disasters could be intentional (for example, an act of a terrorist) or unintentional (that is, accidental, such as the breakage of a man-made dam).

What is the difference between Identification and Authentication?

Identification and authentication are two terms that describe the initial phases of the process of allowing access to a system. The terms are often used synonymously, but authentication is typically a more involved process than identification. Identification is what happens when you profess to have a certain identity in the system, while authentication is what happens when the system determines that you are who you claim to be. Both processes are usually used in tandem, with identification taking place before authorization, but they can stand alone, depending on the nuances of the system.

Identification: Identification is the process of presenting an identity to a system. It is done in the initial stages of gaining access to the system and is what happens when you claim to be a particular system user. The claim can take the form of providing your username during the login process; placing your finger on a scanner; giving your name on a guest list or any other format in which you claim an identity with the aim of gaining access. Identification is not necessary for some systems, such as ATM cards, where anyone with the correct code can gain access to your account without identifying themselves.

Authentication: Authentication is the process of validating an identity provided to a system. This entails checking the validity of the identity prior to the authorization phase. The process of checking the validity of the evidence provided to support the claimed identity must be sufficiently robust to detect impostors. Authentication usually occurs after identification is complete, such as when you supply a password to support a username during the login process. It can happen, however, at the same time as the identification process.

Difference: Identification and authentication are not easily distinguished, especially when both occur in one transaction. They may appear synonymous, but they are two different processes. The primary difference between them is that identification relates to the provision of an identity, while authentication relates to the checks made to ensure the validity of a claimed identity. Simply put, the identification process involves making a claim to an identity, whereas the authentication process involves proving that identity.

Provide four examples of computer crime.

1.Malware: Malware, refers to viruses, trojans worms and other software that gets onto your computer without you being aware it’s there.

2.Identity Theft: The concept is simple: someone gains access to your personal information and uses it for their own benefit. This could range from a black-hat hacker stealing your online banking account login and password to getting access to your social security number and using it to pretend to be you.

3.Cyberstalking: People leave a lot of information about themselves online. Such information can leave you vulnerable to cyberstalking, a term that essentially refers to using the Internet to stalk someone in the traditional sense.Cyber stalking is essentially using the Internet to repeatedly harrass another person.

4.Child Pornography: Child Pornography is a criminal offense and is defined as any visual depiction involving the use of a minor, or one appearing to be a minor, engaging in sexually explicit conduct.

What are the key principles of Network Security?

Network Security Principles involve around three key principles ofConfidentiality, Integrity and Availability.

Confidentiality:Confidentiality is concerned with preventing unauthorized disclosure of sensitive information. This disclosure could be intentional, such as breaking a cipher and reading the information, or it could be unintentional due to the carelessness or incompetence of individuals handling the information.

Integrity:There are three goals of integrity.

-Preventing the modification of information by unauthorized users

-Preventing the unauthorized or unintentional modification of information by unauthorized users

-Preserving the internal and external consistency

Internal consistency: Ensures that internal data is consistent. For example, in an organizational database, the total number of items owned by an organization must be equal to the sum of the same items shown in the database as being held by each element of the organization.

External Consistency: Ensures that the data stored in the database is consistent with the real world. Relative to the above example, the total number of items physically sitting on the shelf must equal the total number of items indicated by the database.

Availability

Availability assures that a system’s authorized users have timely and uninterrupted access to the information in the system and to the network.

Other important terms include:

Identification: The act of a user professing an identity to the system, such as login ID

Authentication: Verification that the user’s claimed identity is valid, such as through the use of password.

Accountability: Determination of the actions and behavior of a single individual within a system and holding the individual responsible for his/her actions.

Authorization: The privileges allocated to an individual or process that enable access to a computer resource.

These are some of the Network Security Principles which help in formulating the best possible Network Security measures which protect the integrity of a organizational network.

Why do we use Access Controls for?

Access control is a security technique that can be used to regulate who or what can view or use resources in a computing environment.There are two main types of access control: physical and logical. Physical access control limits access to campuses, buildings, rooms and physical IT assets. Logical access limits connections to computer networks, system files and data.

The four main categories of access control are:

Access control systems perform authorizationidentification, authentication, access approval, and accountability of entities through login credentials including passwords, personal identification numbers (PINs), biometric scans, and physical or electronic keys.

What means the term Defense-in-Depth?

Defense in depth is the concept of protecting a computer network with a series of defensive mechanisms such that if one mechanism fails, another will already be in place to thwart an attack. Because there are so many potential attackers with such a wide variety of attack methods available, there is no single method for successfully protecting a computer network. Utilizing the strategy of defense in depth will reduce the risk of having a successful and likely very costly attack on a network.

How can you obtain a fairly accurate picture of the level of security awareness in an organization?

Information Security Awareness Techniques

No.

Technique Description

A formally documented security policy has been published outlining security safeguards.

Intranet site provides guidance on information security matters.

Security requirements are covered in staff handbook or procedures manuals.

Security awareness training is built into the induction process when new staff joins the organization

Security responsibilities are included in contract or letter of appointment for new staff.

A specific document/leaflet (that covers information security policy) is distributed to staff.

Poster campaigns on information security topics.

Formai communication plan (Le. how you will communicate with staff on information security awareness).

Regular email or newsletter distributed to staff.

Formai analysis of target groups (Le. which staff it is important to ensue have good information securityawareness).

Other promotional material (e.g. screensavers, pens, mouse mats).

Security messages are integrated into existing business training courses that staff attends.

Optional computer-based security awareness training.

Mandatory computer-based security awareness training.

Optional classroom security awareness training.

Quizzes on security matters (e.g. offering prizes) in staff magazines.

Use of external/outsourced expertise (e.g. security awareness training vendors).

Mandatory classroom security awareness training.

What are the Information Systems Security Engineering process?

The ISSE process section covers six activities that correspond to a generic SE process:

• Discover Information Protection Needs (Discover Needs).

• Define System Security Requirements (Define System Requirements).

• Design System Security Architecture (Design System Architecture).

• Develop Detailed Security Design (Develop Detailed Design).

• Implement System Security (Implement System).

• Assess Information Protection Effectiveness (Assess Effectiveness).

The ISSE process and its SE context are described in detail below.

3.3.1 Discover Information Protection Needs

Discover Information Protection Needs is the first activity of the ISSE process. The corresponding SE activity is Discover Needs (see Figure 3-1). If the Discover Needs activity is not being performed or is incomplete, the information systems security engineer must complete the following SE tasks:

• Develop an understanding of the customer’s mission or business.

• Help the customer determine what information management is needed to support the mission or business.

• Create a model of that information management, with customer concurrence.

• Document the results as the basis for defining information systems that will satisfy the customer’s needs.

To understand the customer’s mission or business, information systems security engineers must take advantage of all available source material, such as operational doctrine,[1] Web pages, annual reports, and proprietary documentation. The mission or business may be summarized in documents such as a mission needs statement (MNS) or a high-level version of a Concept of Operations (CONOPS), but the most important source of information is direct contact with the customer.

Underlying the customer’s mission or business is the information management that supports operations. The first operational elements a customer will think of are the products and services the operation provides, but systems engineers must also seek other important support functions, such as command and control, logistics, human resources, finance, research and development, management, marketing, and manufacturing.

To define information management needs, a model is developed that identifies processes, the information being processed, and the users of the information and the processes. This modeling is in effect a structured analysis that decomposes user roles, processes, and information until ambiguity is reduced to a satisfactory degree. An important step in this modeling is to apply “least privilege” rules, by which users are limited to the processes and information they need to do their jobs. The model should also include the requirements of any information management policies, regulations, and agreements that apply to the information being managed. The main components of the model are information domains, each of which identifies three elements:

• Users or members of the information domain.

• Rules, privileges, roles, and responsibilities that apply to the users in managing all the information.

• Information objects being managed, including processes.

The model, then, is a collection of information domains. The resulting document, the IMM, is usually a very detailed representation of information management needs. The information systems security engineer may support the systems engineer in developing the IMM. This part of the Discover Information Protection Needs activity is presented in detail in the protection needs elicitation (PNE) appendix to this IATF. See Figure 3-2 for an illustration of Discover Information Protection Needs.

Once the IMM is complete, the information systems security engineer can use this knowledge to identify applicable protection policies, security regulations, directives, laws, etc. These documents may identify required levels of security (for example National Security Agency [NSA] approved cryptography for classified information), or C&A procedures that must be followed.

A critical part of the Discover Information Protection Needs activity is defining threats to the information. With the customer as the best source of knowledge, and informed by the information systems security engineer’s expertise, each information domain is assigned metrics for harm to information (HTI) and potentially harmful events (PHE). HTI considers the value of the information and the degree of harm to the mission if the information were disclosed, modified, destroyed, or unavailable when needed. PHE considers the existence of malicious adversaries, their degree of motivation, and the potential for accidents and natural disasters. Each information domain then has an HTI and a PHE assigned for disclosure, modification, destruction, and unavailability. The HTIs and PHEs are then combined to produce a single information threat metric, such as 3, 2, 1, and 0, with 0 representing no threat. The actual choice of metrics and the method of combining them must be understandable and acceptable to the customer. One recommendation for choosing and combining these metrics is given in the PNE appendix to the IATF.

The ISSE process defines the security services and the strengths of service using the information threat as a guideline for setting protection priorities. The information systems security engineer and the customer apply confidentiality, integrity, availability, access control, identification and authentication (I&A), nonrepudiation, and security management services, as appropriate to each information threat. The strengths of the services are proportional to the information threat metrics.

Documentation is crucial in all stages of SE and ISSE. In this activity, the information systems security engineer documents information threats; security services, strengths, and priorities; and roles and responsibilities. The information threats and the corresponding security services in the system or systems used to support the customer’s mission or business are documented in an IPP. When customer concurrence is obtained, the IPP is assumed to be part of the customer’s information management policy. This policy will be the basis for assessing the effectiveness of the information protection throughout the remainder of the process activities. Figure 3-2 illustrates the flow from mission or business to the IPP.

Early in the engineering process, the information systems security engineer also should begin documenting design constraints. These may be found in the legal and regulatory requirements identified earlier or they may be inherited from legacy systems that must interface with the target system. In either case, they must be documented and tracked throughout the SE/ISSE process.

The information systems security engineer is responsible for presenting the process, summarizing the information model, identifying the threats and security services, and determining the threats’ and services’ relative strengths and priorities to the customer. Since this documents the customer’s information management and protection needs, on which all further development efforts will be based, customer agreement on the conclusions reached in this activity is essential and is the measure of the effectiveness of the information systems security engineer’s efforts. In each activity of the ISSE process, the information systems security engineer will perform activities to support the C&A of the system. In the Discover Information Protection Needs activity, the focus is on identifying the key roles (i.e., Designated Approving Authority [DAA]/Accreditor and Certification Authority/Certifier) and the process to be used for C&A and acquisition of the system, and on obtaining concurrence in the documented results of this activity, as required.

3.3.2 Define System Security Requirements

In this activity, which is part of the Define System Requirements activity of SE, the information systems security engineer considers one or more solution sets that can meet the information protection needs expressed by the customer and documented in the IPP. The mapping of needs to a solution set is illustrated in Figure 3-3. Each solution set includes a system concept for the target system, which defines the following:

• System context.

• Preliminary CONOPS.

• System requirements (what the system is to accomplish).

With customer involvement, one solution set is chosen and its system context, CONOPS, and requirements are documented. This activity can result in the need to modify existing systems or to develop more than one target system. Figure 33 also illustrates the allocation of needs to systems other than the target system. Examples of external systems include a system that provides a Public Key Infrastructure (PKI) and a system for security clearances of users.

Developing the system security context involves defining system boundaries and interfaces with SE, allocating security functions to target or external systems, and identifying data flows between the target and external systems and protection needs associated with those flows. Information management needs (per the IMM) and information protection needs (per the IPP) are allocated to the target system and to external systems; allocations to external systems are assumptions that must be accepted by these systems’ owners. The system security context documents those allocations and specifies data flows between the system and external systems and how they are controlled.

A preliminary security CONOPS describes, from a user perspective, what information management and information protection functions the system will perform in support of the mission, but falls short of defining step-by-step procedures. The CONOPS will define the reliance of mission or business needs on other systems and the products and services they deliver. The system security context and CONOPS are coordinated with the systems engineer, the customer, and owners of external systems.

The information systems security engineer works with the systems engineers to define system security requirements, system security modes of operation, and system security performance measures. Good system requirements specify what a system must do, without specifying its design or implementation. The systems engineer and the information systems security engineer must ensure that the requirements are understandable, unambiguous, comprehensive, complete, and concise. Requirements analysis must clarify and define functional requirements and design constraints. Functional requirements define quantity (how many), quality (how good), coverage (how far), timelines (when and how long), and availability (how often). Any performance requirements and residual design constraints are carried forward as part of the system requirements document. Design constraints are not independent of implementation but represent design decisions or partial system design. In system requirements documents, design constraints should be identified separately from system interface requirements, which must be documented, including any that are imposed by external systems. Design constraints define factors that limit design flexibility, such as environmental conditions or limits; defense against internal or external threats; and contract, customer, or regulatory standards. When the system requirements are approved, they are documented to give designers a baseline for system development.

In analyzing requirements, the systems engineer reviews the traceability documentation to ensure that all of the needs discovered have been allocated either to the target system or to external systems and that the context for the target system describes all external interfaces and flows. The systems engineer also ensures that the preliminary system CONOPS covers all of the functionality, missions, or business needs and addresses the inherent risk in operating the system.

The information systems security engineer ensures that the selected solution set meets the mission or business security needs, coordinates the system boundaries, and ensures that the security risks are acceptable. The information systems security engineer will present security context, security CONOPS, and system security requirements to the customer and gain concurrence.

All documentation of the system concept and any rationale for choosing that concept are delivered in compliance with the C&A process. The information systems security engineer is responsible for ensuring that Accreditor and Certifier concurrence is obtained as necessary.

3.3.3 Design System Security Architecture

In the Define System Requirements SE activity, requirements were allocated to an entire information system, indicating the functions to be performed without any definition of system components. In Design System Architecture, the SE team now does functional decomposition, choosing the types of components that will perform specific functions. This process is the core of designing an architecture. Figures 3-4a and 3-4b illustrate the contrast between these two SE activities where Define System Requirements treats the target system as a “black box” and Design System Architecture creates the structure within the system. The same contrast occurs in the corresponding ISSE activities—Define System Security Requirements and Design System Security Architecture.

Functions are analyzed by decomposing higher-level functions identified through requirements analysis into lower level functions. The performance requirements associated with the higher level are allocated to lower level functions. The result is a description of the product or item in terms of what it does logically and in terms of the performance required. This analysis includes candidate system architectures, function and process, interfaces (internal and external), elements (components), information transfers, environments, and users/accesses.

This description is often called the functional architecture of the product or item. Functional analysis and allocation allow a better understanding of what the system has to do; the ways in which it can do it; and to some extent, the priorities and conflicts associated with lower level functions. It provides information essential to optimizing physical solutions. Key tools in functional analysis and allocation are Functional Flow Block Diagrams, Timeline Analysis, and the Requirements Allocation Sheet.

During this task, the information systems security engineer works with the systems engineers to ensure that security requirements flow properly to the architecture and that architecture decisions do not impede security.

The information systems security engineer works to allocate security requirements to the target and external systems and to ensure that external systems identified can support what is allocated to them. This is particularly important for security, since services such as key management are often allocated to external systems.

The information systems security engineer will identify high-level security mechanisms during this task (e.g., encryption, digital signature). This is necessary so that dependencies, such as key management for encryption, can be addressed and allocated. The information systems security engineer should match mechanisms to security service strength, apply design constraints, analyze and document shortfalls, perform interdependency analysis, ascertain the feasibility of mechanisms, and assess any residual risk associated with the mechanisms. Specific implementations of the security mechanisms are not identified in the architecture, so detailed vulnerability and attack information is not available to support the formal risk analysis process. However, an experienced information systems security engineer can describe the expected vulnerabilities in potential components and can develop attack scenarios to use in the risk analysis process.

The risk analysis process ensures that the selected security mechanisms provide the required security services and helps explain to the customer how the security architecture meets the security requirements. The effectiveness of the architecture in meeting these requirements is based on the results of the risk analysis and whether the customer concurs with the recommended course of action at this stage of development.

The information systems security engineer supports C&A by coordinating the security architecture and the results of the risk analysis with the Accreditor and the Certifier.

3.3.4 Develop Detailed Security Design

The development of the information protection design is iterative, involving interactions between the SE and ISSE teams and between systems and component engineers within the teams. Decisions leading to the recommended design involve continuous assessments by the ISSE team to compare the expected risk with the system security requirements. The system security requirements set priorities for protection that the ISSE team applies accordingly. The ISSE team produces the design documentation required by the C&A process. That documentation enables independent evaluation of the design by risk analysts who then provide feedback on vulnerabilities.

In Develop Detailed Security Design, the information systems security engineer will ensure compliance with the security architecture, perform trade-off studies, and define system security design elements, including—

• Allocating security mechanisms to system security design elements.

• Identifying candidate commercial off-the-shelf (COTS)/government off-the-shelf (GOTS) security products.

• Identifying custom security products.

• Qualifying element and system interfaces (internal and external).

• Developing specifications (e.g., Common Criteria protection profiles).

The information protection design specifies the system and its components, but does not decide on specific components or vendors. The selection of specific components is part of the Implement System activity.

Some important aspects of the ISSE effort are as follows:

• Components include both technical and nontechnical mechanisms (e.g., doctrine).

• Design must satisfy customer-specified design constraints.

• Trade-offs must consider priorities, cost, schedule, performance, and residual security risks.

• Risk analysis must consider the interdependency of security mechanisms.

• Design documents should be under strong configuration control.

• Failures to satisfy security requirements must be reported to C&A authorities.

• Design should be traceable to the security requirements.

• Design should project the schedule and cost of long-lead items and life-cycle support.

• Design should include a revised security CONOPS.

In Develop Detailed Security Design, the information systems security engineer also reviews how well the selected security services and mechanisms counter the threats identified in the IPP by performing an interdependency analysis to compare desired to effective security service strengths. Once completed, the risk assessment results, particularly any identified mitigation needs and residual risk, are documented and shared with the customer to obtain concurrence.

3.3.5 Implement System Security

The objective of the Implement System SE activity is to acquire, integrate, configure, test, document, and train. Implement System moves the system from design to operations. This activity concludes with a final system effectiveness assessment in which evidence is presented that the system complies with the requirements and satisfies the mission needs. Issues across all SE primary functions must be considered and any interdependency or trade-off issues resolved.

During Implement Systems Security, the information systems security engineer provides—

• Inputs to C&A process activities.

• Verification that the system as implemented does protect against the threats identified in the original threat assessment.

• Tracking of, or participation in, application of information protection assurance mechanisms related to system implementation and testing practices.

• Inputs to and review of evolving system life cycle support plans, operational procedures, and maintenance training materials.

• A formal information protection assessment in preparation for the final system effectiveness assessment.

• Participation in the multidisciplinary examination of all system issues.

These efforts and the information each produces support the final system effectiveness assessment. Security accreditation approval typically occurs shortly after the conclusion of the final system effectiveness assessment.

Selecting specific products for integration into the security solution is part of the Implement System Security activity. These products can be acquired by purchase, lease, or borrowing. Selection will be based on factors such as cost of the component, availability, form, and fit. Other factors may include components affect on reliability of the particular system, risk to system performance if component performance is marginal, and future availability of the component or substitutes. Components that cannot be procured must be built. Whether software, hardware, or firmware, components should be verified as corresponding to the design specifications, and the verification must be formally documented. Any deviation must be evaluated for impact on the achievement of design and mission or business objectives, including security.

Components, whether procured or built, must be integrated into the system as designed, and any incompatibility with existing components resolved. Systems are often a hybrid of procured and built components that may need “glue,” such as software or interface cabling. During installation and configuration, functions that are needed should be implemented and functions that are not needed for the mission should be restricted.

The information systems security engineer must verify that the evaluation criteria for the security components measure the desired level of security and that the security components meet those criteria. Products may have been evaluated against Commercial COMSEC Evaluation Program (CCEP), National Information Assurance Partnership (NIAP), Federal Information Processing Standards (FIPS), or other NSA and National Institute of Standards and Technology (NIST) criteria.

The ISSE team helps configure the components to ensure that the security features are enabled and the security parameters are set to provide the required security services. Once the system is ready to be configured, any differences in settings that are necessary must be recorded and approved following configuration management procedures.

The systems and design engineers will write test procedures reflecting the results expected as the design solution becomes defined. As components are acquired, they should be unit tested. Verification of the design and interfaces ensures that the produced component operates correctly. Procedures must test all of the interfaces. If the system is unique or is to be operated in an environment that is difficult to model, however, it may not be possible to fully test all interfaces until the system is installed.

Integration testing verifies subsystem and system performance. Planning for testing should consider the people, tools, facilities, schedule, and capital resources required to test both individual components and the entire system. As components are integrated into the system and tested to ensure that the subsystems and the system are functional, some components may have to be changed. Test reports should document both positive and negative results of the testing.

Design documentation and experience in implementing a system are sources of material for training users and administrators. All documentation should be under strict version control. Training materials and instruction should address operational policy as it pertains to the system and should deal with system limitations as well as functions.

As the system is integrated and tested, it is important to document installation, operation, maintenance, and support procedures. These procedures will be based on the requirements, architecture, design, and test results of the system “as-built” configuration. As installation proceeds, it is important to document defects in the procedures and to note how changes may affect function and mission objectives. The impact of installation changes on the residual risk associated with operating, supporting, and maintaining the system should also be assessed.

The information systems security engineer will develop the information protection-related test plans and procedures and may have to develop test cases, tools, hardware, and software to exercise the system adequately. ISSE activities to this end include—

• Participation in the testing of protection mechanisms and functions.

• Tracking and applying information protection assurance mechanisms related to system implementation and testing practices.

• Providing inputs to and review of evolving life-cycle security support plans, including logistics, maintenance, and training.

• Continuing risk management.

• Supporting the C&A processes.

The information systems security engineer monitors the system security aspects of interfaces, integration, configuration, and documentation. System test and evaluation may reveal unexpected vulnerabilities; the risks and possible mission impacts associated with these vulnerabilities must be evaluated. The results are fed back to the design engineers in an iterative process. The information systems security engineer coordinates with the Certifiers and Accreditors to ensure the completeness of the required documentation. The information systems security engineer also monitors tasks to ensure that the security design is implemented correctly. To accomplish this, he or she will observe and participate in testing and analyze test and evaluation results.

During this task, the risk analysis will be initially conducted or updated. Strategies will be developed to mitigate identified risks and the information systems security engineer will identify possible mission impacts and advise the customer and the customer’s Certifiers and Accreditors.

The information systems security engineer ensures that the documentation necessary for C&A is completed and delivered. This documentation will include integration and test reports showing any variations to specifications. The information systems security engineer may contribute to and review these documents.

The ISSE team helps ensure that adequate training material is available for security training. Users must be advised of threats to the operation. Threat information and security responsibilities should be part of the system doctrine and any operational security policy.

3.3.6 Assess Information Protection Effectiveness

The Assess Information Protection Effectiveness activity spans the entire SE/ISSE process. Therefore, it is discussed in each of the preceding activity sections, as appropriate. A summary of the effectiveness assessment tasks related to the various other ISSE activities is provided in Table 3-2.

Table 3-2. Assess Information Protection Effectiveness Tasks by ISSE Activity.

ISSE Activity

Assess Information Protection EffectivenessTask

Discover Information Protection Needs

• Present an overview of the process.

• Summarize the information model

• Describe threats to the mission or business through information attacks

• Establish security services to counter those threats and identify their relative importance to the customer.

• Obtain customer agreement on the conclusions of this activity as a basis for determining system security effectiveness.

Define System Security Requirements

• Ensure that the selected solution set meets the mission or business security needs.

• Coordinate the system boundaries.

• Present security context, security CONOPS, and system security requirements to the customer and gain their concurrence.

• Ensure that the projected security risks are acceptable to the customer.

Design System Security Architecture

• Begin the formal risk analysis process to ensure that the selected security mechanisms provide the required security services and to explain to the customer how the security architecture meets the security requirements.

Develop Detailed Security Design

• Review how well the selected security services and mechanisms counter the threats by performing an interdependency analysis to compare desired to effective security service strengths.

• Once completed, the risk assessment results, particularly any mitigation needs and residual risk, will be documented and shared with the customer to obtain their concurrence.

Implement System Security

• The risk analysis will be conducted/updated.

• Strategies will be developed for the mitigation of identified risks

• Identify possible mission impacts and advise the customer and the customer’s Certifiers and Accreditors.

[1] Operational doctrine, as used here, is a set of documents that describe how an organization conducts its mission. It should not be confused with security doctrine, which is an architectural element that describes secure procedures for systems.

Provide a definition of Access Controls.

Access Control is any mechanism by which a system grants or revokes the right to access some data, or perform some action. Normally, a user must first Login to a system, using some Authentication system. Next, the Access Control mechanism controls what operations the user may or may not make by comparing the User ID to an Access Control database.

Access Control systems include:

What is Information Systems Security Management?

An information security management system (ISMS) is a set of policies and procedures for systematically managing an organization's sensitive data. The goal of an ISMS is to minimize risk and ensure business continuity by pro-actively limiting the impact of a security breach.

An ISMS typically addresses employee behavior and processes as well as data and technology. It can be targeted towards a particular type of data, such as customer data, or it can be implemented in a comprehensive way that becomes part of the company's culture.

ISO 27001 is a specification for creating an ISMS. It does not mandate specific actions, but includes suggestions for documentation, internal audits, continual improvement, and corrective and preventive action.

No.