BITS College

IT646 – IT Security Management

Chapter 3 – Management Controls

By
Girum Ketema (PhD)
Girum.ketema@bitscollege.edu.et
Outline

Security Policy

Security Strategy

Security Risk Management

Assurance
Outline

Security Policy

Security Strategy

Security Risk Management

Assurance
Security Policy
• Security Policy
• Clear, comprehensive, and well-defined plans, rules, and practices that
regulate access to an organization's system and the information included in
it.
• Security Policy – multiple aspects
• Senior management's directives to create a computer security program,
establish its goals, and assign responsibilities.
• The specific security rules for particular systems.
• Managerial decisions on specific issues (e.g., setting email privacy policy)
Security Policy
• Objectives of security policy
• Reduced risk
• Compliance with laws and regulations
• Assurance of operational continuity, information integrity, and confidentiality
• Policies are the least expensive means of control and often the most
difficult to implement
• Basic rules for shaping a policy
• Policy should never conflict with law
• Policy must be able to stand up in court if challenged
• Policy must be properly supported and administered
Policies …
• Are key to make important decisions
• Resource allocation
• Prioritizing competing objectives
• Guiding employee behavior
• The scope of a policy may vary based on the scope of the manager’s
authority
Policies are important reference documents
• For internal audits
• For the resolution of legal disputes about management's due diligence
• Policy documents can act as a clear statement of management's intent
Categories of Security Policies
• Three Categories of Security Policies
• Organizational Program policy - used to create an organization's computer
security program.
• Issue-specific policies - address specific issues of concern to the organization.
• System-specific policies - focus on decisions taken by management to protect
a particular system.
• Procedures, standards, and guidelines are used to describe how
these policies will be implemented within an organization.
Security Policy
Program Policy
Program Policy
• Program policy is issued to establish (or restructure) the
organization's computer security program and its basic
structure.
• Program Policies are issued by a top level management
official.
• Program policy sets organizational strategic directions for
security and assigns resources for its implementation.
Program Policy …
• Program policies are high-level policies and define
• the purpose of the security program and its scope within
the organization;
• assigns responsibilities (to the computer security
organization) for direct program implementation
• assign other responsibilities to related offices
• addresses compliance issues
Components of Program Policy - Purpose
• Includes a statement describing why the program is being
established.
• Defines the goals of the program.
• Security-related needs, such as integrity, availability, and confidentiality
• Security related needs may vary from organization to organization
• For instance, in an organization responsible for maintaining large mission-
critical databases, reduction in errors, data loss, data corruption, and
recovery might be specifically stressed.
• In an organization responsible for maintaining confidential personal data,
goals might emphasize stronger protection against unauthorized disclosure
Components of Program Policy – Scope
• Program policy should be clear as to which resources the computer
security program covers
• Facilities
• hardware
• Software
• Information
• Personnel
• In most cases, the program will encompass all systems and
organizational personnel, but this is not always true.
• In some instances, it may be appropriate for an organization's
computer security program to be more limited in scope.
Components of Program Policy - Responsibilities
• Management of the security program might be given to a new office or to
already existing office. But it should be indicated in the program policy
• The responsibilities of officials and offices throughout the organization need to
be addressed: line managers, applications owners, users,...
• This section of the policy statement would distinguish between the
responsibilities of different units
• Example: computer services providers and those of the managers of applications using the
provided services.
• The policy could also establish operational security offices for major systems,
particularly those at high risk or most critical to organizational operations.
• It also can serve as the basis for establishing employee accountability.
• At the program level, responsibilities should be specifically assigned to those
organizational elements and officials responsible for the implementation and
continuity of the computer security policy.
Components of Program Policy - Compliance
• General compliance
• to ensure meeting the requirements to establish a program and the
responsibilities assigned to various organizational components.
• An oversight office is assigned responsibility for monitoring compliance,
including how well the organization is implementing management's priorities
for the program.
• Penalties and disciplinary actions.
• the policy may authorize the creation of compliance structures that include
violations and specific disciplinary action(s).
• Specific penalties for various security violations are normally not detailed in
the document since it is high level document
Security Policy
Issue-Specific Policy
Issue-Specific Policy
• Provides detailed, targeted guidance
• Instruction for secure use of a technology systems
• Begins with introduction to fundamental technological philosophy of the
organization
• Protects organization from inefficiency and ambiguity
• Documents how the technology-based system is controlled
• Identifies the processes and authorities that provide this control
• Protects the organization against liability for an employee’s
inappropriate or illegal system use
Topics of Issue Specific Policy
• Email Privacy
• Internet use
• Minimum system configurations
• Prohibitions against hacking
• Home use of company-owned computer equipment
• Use of personal equipment on company networks (e.g., USB Disks)
• Use of telecommunications technologies
• Bring Your Own Device (BYOD)
• Social Media
Components of Issue-Specific Policy
• Issue Statement
• Statement of the Organization's Position
• Applicability
• Roles and Responsibilities
• Compliance
• Points of Contact and Supplementary Information.
Components of Issue-Specific Policy - Issue
Statement
• Defining the issue with any relevant terms, distinctions, and
conditions included.
• Specify the goal or justification for the policy - which can be helpful in
gaining compliance with the policy.
• Example: Use of "unofficial software,"
• Any software not approved, purchased, screened, managed, and owned by
the organization.
• The applicable distinctions and conditions might need to be included
Components of Issue-Specific Policy -
Statement of the Organization's Position
• Clearly states Management’s Decision on the issue.
• Example (continued): Use of "unofficial software,"
• Whether use of unofficial software is prohibited
• Are there further guidelines for approval and use
• Whether case-by-case exceptions will be granted, by whom, and on what
basis.
Components of Issue-Specific Policy -
Applicability
• Clarifying where, how, when, to whom, and to what a particular
policy applies.
• Example (Continued): Use of "unofficial software,"
• Whether the policy applies only to the organization's own on-site resources
and employees and not to contractors with offices at other locations
• The policy's applicability to employees travelling among different sites
• Employees Working at home who need to transport and use disks at multiple
sites
Components of Issue-Specific Policy - Roles
and Responsibilities
• Specifies the roles and responsibilities of different actors
• Example (Continued): Use of "unofficial software,"
• Who would be responsible for ensuring only approved (official) software are
in use
• Approval authority on use of own software (if the policy permits exceptions)
• Specify positions (not names of individuals)
Components of Issue-Specific Policy -
Compliance
• States Violations that are unacceptable, and the consequences of
such behavior.
• Penalties may be explicitly stated here
• Penalties should be consistent with organizational personnel policies
and practices.
• Use of Penalties should be coordinated with appropriate officials and
offices.
• A specific office might be designated to monitor compliance.
Components of Issue-Specific Policy - Points
of Contact
• The appropriate individuals in the organization to contact for further
information, guidance, and compliance should be indicated.
• Specific positions are preferable as the point of contact
• The policy should state that whether the point of contact for
questions and procedural information would be their immediate
superior, a system administrator, or a computer security official
Security Policy
System-Specific Policy
System-Specific Policy
• System-specific policies provide information and direction on what
actions are permitted on a particular system.
• Program and issue-specific policies are broad, high-level policies written to
encompass the entire organization
• system-specific policies dictate the appropriate security
configurations to the personnel responsible for implementing the
required security controls in order to meet the organization’s
information security needs.
• Two-level model for system security policy
• Security Objectives
• Operational Security Rules
System-Specific Policy – Security Objectives
• Start with an analysis of the need for integrity, availability, and
confidentiality requirements of the organization
• Security Objectives needs to be specific and well defined
• Security objectives consist of a series of statements that describe
meaningful actions about explicit resources.
• These objectives should be based on system functional or mission
requirements but should state the security actions that support the
requirements.
System-Specific Policy – Security Objectives
• Development of system-specific policy will require management to
make trade-offs
• Management will face cost, operational, technical, and other
constraints.
• Example Security Objective
• Only individuals in the accounting and personnel departments are authorized
to provide or modify information used in payroll processing.
System-Specific Policy – Operational Security
Rules
• Rules for operating the system
• Example: Define authorized and unauthorized modification.
• Who (by job category, organization placement, or name) can do what to which specific
classes and records of data, and under what conditions.
• The degree of specificity needed for operational security rules varies.
• The more detailed the rules are, the easier it is to know when one has been violated
• More detailed rules are easier to automate policy enforcement.
• Overly detailed rules may make the job of instructing a computer to
implement them difficult or computationally complex.
• Example Operational Security Rules
• Personnel Clerks may update fields for attendance, employee addresses, and salary
information
• No employees may update their own records.
System-Specific Policy – Operational Security
Rules …
• The degree of formality in documenting the system-specific policy shall be
defined.
• The more formal the documentation, the easier it is to enforce and to
follow policy.
• On the other hand, policy at the system level that is too detailed and
formal can also be an administrative burden.
• Best practice:
• A reasonably detailed formal statement of the access privileges for a system.
• Documenting access controls policy will make it substantially easier to follow and to
enforce.
• Assignment of security responsibilities should also be clearly and formally
defined.
• The rules for system usage and the consequences of noncompliance.
System-Specific Security Policy Types
• Sometimes System-Specific Security Policies can be separated into
• Management guidance
• Technical specifications
• Or combined in a single policy document
Managerial Guidance
• Created by management to guide the implementation and
configuration of technology
• Applies to any technology that affects the confidentiality, integrity or
availability of information, e.g. firewall configuration
• Informs technologists of management intent

Management of Information Security, 3rd ed.

Technical Specifications
• System administrators’ directions on implementing managerial policy
• Each type of equipment has its own type of policies
• General methods of implementing technical controls
• Access control lists
• Configuration rules

Management of Information Security, 3rd ed.

Technical Specifications - contd
• Access control lists
• Include the user access lists, matrices, and capability tables that govern the
rights and privileges
• A similar method that specifies which subjects and objects users or groups
can access is called a capability table
• These specifications are frequently complex matrices, rather than simple lists
or tables
• Enable administrations to restrict access according to user, computer, time,
duration, or even a particular file
• Example ACLs
• Routers / Firewalls
• Proxy Servers

Management of Information Security, 3rd ed.

Technical Specifications - contd
• Access control lists regulate
• Who can use the system
• What authorized users can access
• When authorized users can access the system
• Where authorized users can access the system from
• How authorized users can access the system
• Restricting what users can access, e.g. printers, files, communications, and
applications
• Administrators set user privileges
• Read, write, create, modify, delete, compare, copy

Management of Information Security, 3rd ed.

Example: Computer Management …
Technical Specifications - contd
• Configuration rules
• Specific configuration codes entered into security systems
• Guide the execution of the system when information is passing through it
• Many security systems require specific configuration scripts telling the
systems what actions to perform on each set of information they
process
Technical Specifications (cont’d.)

Figure 4-6 Firewall configuration rules

Source: Course Technology/Cengage Learning

System-Specific Policy Implementation
• Technology plays an important role in enforcing system-specific
policies.
• But Technology is not the sole enforcer
• We should consider non-technology- based methods too.
• Example:
• Technical system-based controls could be used to limit the printing of confidential
reports to a particular printer.
• Corresponding physical security measures would also have to be in place to limit access
to the printer output
System-Specific Policy Implementation …
• Access controls are commonly used technical methods to implement
system-security policy
• There are also other automated means of enforcing or supporting
security policy that typically supplement logical access controls.
• Example:
• Access Controls can be used to block telephone users from calling certain
numbers.
• Intrusion detection software can alert system administrators to suspicious
activity or can take action to stop the activity.
Security Policy
Development and Best Practices
Development steps
• Investigation (goals, support, participation)
• Analysis (risk assessment)
• Design (components, dissemination)
• Implement (detailed specification)
• Maintenance
• Distribution

42
Guidelines for Effective Policy
• policies must be properly:
• Developed using industry-accepted practices
• Distributed or disseminated using all appropriate methods
• Reviewed or read by all employees
• Understood by all employees
• Formally agreed to by act or assertion
• Uniformly applied and enforced

Management of Information Security, 3rd ed.

Outline

Security Policy

Security Strategy

Security Risk Management

Assurance
Strategy

Is a plan of action designed to achieve a

Strategy long-term or overall aim

plan that integrates the organization's

major Information System security goals,
Information Security Strategy policies, and action sequences into a
cohesive whole

Policy: What is the security scheme supposed to do?

Comprehensive security strategy Implementation/mechanisms: How does it do it?
involves three aspects: Correctness/assurance: Does it really work?
 Strategy – Aspect 1 - Policy

The first aspect of a strategy is Policy. The policy must address, among others:

• The value of the assets being protected

• The vulnerabilities of the system
• Potential threats and the likelihood of attacks

There are trade-offs to be considered

• Ease of use versus security

• Access control mechanisms force users to remember passwords
• Firewall rules may reduce throughput
• Antivirus may reduce performance of computers (CPU + Memory Usage)
• Cost of security versus cost of failure and recovery
• Direct monetary costs
 Strategy – Aspect 2: Security Implementation
Security Implementation involves Four Course of Actions:
Prevention - Make Detection – Response – action Recovery – getting
Determine if an attack back to where we
sure that no attack is to stop or deter the
is going on or about to were before the
successful attack
happen attack

• Practically • Intrusion • When attacks are • Usually through

impossible detection detected, the backup systems
• We can make systems detect system responds
reasonable goals. unauthorized in a way to stop
Example: access the attack
Encryption of • Detection of DoS
Transmitted Data Attack
Strategy – Aspect 3 - Assurance and Evaluation
• Consumers of the Computer Security Services desire to believe the
security measures in place work as intended
• Assurance
• Provides grounds for having confidence that the system operates such that
the system’s security policy is enforced.
• Addresses Design and Implementation Issues
• Does the security system design meet its requirements>
• Does the security System Implementation Meet its specifications?
• Is expressed as a degree of confidence
• Evaluation
• Is the process of examining a computer product or system with respect to
certain criteria
System Life Cycle and Security Planning

Development/ Operation/
Initiation Implementation Disposal
Acquisition Maintenance

• Need • Design • Testing • Performing • Replaced by a

Specification • Purchase • Installation phase new system
• Purpose • develop • A series of
Documentation modification
 Security and Planning – In System Life Cycle

Development/ Operation/
Initiation Implementation Disposal
Acquisition Maintenance

• Sensitivity • Determine security • Install Security • Sec Op & Admin

Assessment requirement Controls • Operational
• Incorporate Security • Security Testing Assurance (Audit)
Into Spec • Change Mgt
• Build/Buy • Accreditation
• Reaccreditation
Security Implementation – Operational Phase
Group Assignment
• Description
• Evaluate the Draft National Cybersecurity Policy and Strategy
• Describe its focus Areas and main elements
• Criticize the content based on the discussions in class
• Presentation for 10 minutes per group
• Grouping
• Make a group of 4
• Due Date: TBD
Outline

Security Policy

Security Strategy

Security Risk Management

Assurance
Risk Management

• Risk is the possibility of something adverse happening.

• People recognize various threats to their best interests and take precautions to guard
against them or to minimize their effects
• Risk management is the process of assessing risk, taking steps to reduce risk to an
acceptable level and maintaining that level of risk.
• Examples (in everyday life)
• Buckling a car safety belt,
• Carrying an umbrella when rain is forecast,
• Writing down a list of things to do rather than trusting to
• Organizations are concerned with many types of risk.
Information Security Risk Management

• Information Security risk management addresses risks which arise from an organization's
use of information technology.
• Most fundamental assumption
• COMPUTERS CANNOT EVER BE FULLY SECURED.
• There is always risk
• Risk Management activities
• Risk assessment (Primary activity)
• Risk mitigation (Primary activity)
• Uncertainty analysis (underlying activity)
Risk Assessment

• Risk assessment is the process of analyzing and interpreting risk

• Consists of 3 basic steps
• Step 1 - Determining the assessment's scope and methodology
• Step 2 - Collecting and analyzing data
• Step 3 - Interpreting the risk analysis results.
• In-depth knowledge of an organization and a system are side benefits of Risk Assessment
 Risk Assessment – Step 1

The first step in assessing risk is to identify

the analytical method including its level of
the system under consideration, the part of the system that will be analyzed,
detail.

The risk assessment may focus on different areas

New applications Use of communications Data center The entire organization

Main Focus could be on areas with unknown risk or known high-risks

 Risk Assessment – Step 1 – determining scope

Considerations to determine Scope

The phase of the system in
the system life cycle
New system to be developed –
detailed risk assessment
Existing System upgrade – less
detailed
Relative importance of the
system
Essential / Critical system – detailed
risk assessment
Non-essential – less detailed
Magnitude of change since
last risk assessment
Major changes – more detailed
 Risk Assessment – Step 1 - Methodologies

Formal Vs Informal Detailed Vs Simplified Qualitative vs Quantitative

Formal – Follow Detailed – Goes into each and every Qualitative - based on descriptions
standardized/structured approach system into great details or rankings
Informal – Follow unstructured Simplified – perform high level Quantitative – Computational based
approach analysis

Step 1 is important to determine the amount of effort and type of report

Risk Assessment – Step 2 - Collecting and Analyzing Data

Risk Assessment includes Documentation of assessments

gathering data about the makes risk mitigation less time
threatened area and synthesizing consuming and helps answer
and analyzing the information to questions regarding security
make it useful. decisions
Risk Assessment – Step 2 - Collecting and Analyzing Data …

Screening steps need to be taken to limit information gathering and analysis.

Ranking threats and assets should be done during screening.

• A risk management effort should focus on those areas that result in the greatest consequence to the
organization (i.e., can cause the most harm).

Some risk components can be assessed together

• Assets/consequences
• Threats/likelihoods
Risk Components

Assets Threats Vulnerabilities

Safeguards Consequences Likelihoods

 Risk Assessment – Step 2 - Collecting and Analyzing Data

• Asset Valuation.
• Assets include the information, software, personnel, hardware, and physical assets (such as the
computer facility).
• The value of an asset consists of its intrinsic value and the near-term impacts and long-term
consequences of its compromise.
• Consequence Assessment.
• estimates the degree of harm or loss that could occur.
• Consequences refers to the overall, aggregate harm that occurs, not just to the near-term or
immediate impacts.
• Impacts: disclosure, modification, destruction, or denial of service
• Consequences: more significant long-term effects, such as lost business, failure to perform the
system's mission, loss of reputation, violation of privacy, injury, or loss of life.
• The more severe the consequences of a threat, the greater the risk to the system (and, therefore,
the organization).
 Risk Assessment – Step 2 - Collecting and Analyzing Data

• Threat Identification.
• A threat is an entity or event with the potential to harm the system.
• Typical threats
• Errors
• Fraud
• Unhappy employees
• Fires
• Water damage
• Hackers
• Viruses.
• Threats should be identified and analyzed to determine the likelihood of their occurrence
and their potential to harm assets
• Focus on less understood or new areas
• Concentrate on threats that have more likely to occur and/or have more severe
consequences
 Risk Assessment – Step 2 - Collecting and Analyzing Data
…
• Safeguard Analysis.
• A safeguard is any action, device, procedure, technique, or other measure that reduces a
system's vulnerability to a threat.
• Safeguard analysis includes an examination of the effectiveness of the existing security
measures.
• Safeguard analysis may Identify new safeguards that could be implemented in the
system
• this can also be performed later in the risk management process.
• Vulnerability Analysis.
• A vulnerability is a condition or weakness in (or absence of) security procedures,
technical controls, physical controls, or other controls that could be exploited by a threat.
• Vulnerabilities are analyzed in terms of missing safeguards.
• Vulnerabilities contribute to risk because they may "allow" a threat to harm the system.
 Risk Assessment – Step 2 - Collecting and Analyzing Data
…

• Likelihood Assessment.
• Likelihood is an estimation of the frequency or chance of a threat
happening.
• Likelihood assessment considers the presence, persistence, and
strengths of threats
• Likelihood assessment also considers the effectiveness of safeguards
(or presence of vulnerabilities).
• Experience is important in determining likelihood of threats if
historical information is not available
• Higher likelihood means higher risk
Risk Assessment – Step 3 – Interpreting Risk Analysis Result

• Risk analysis results are represented quantitatively and/or

qualitatively.
• Quantitative measures:
• reduced expected monetary losses, such as annualized loss expectancies
• Single occurrences of loss.
• Qualitative measures
• are descriptive, expressed in terms such as high, medium, or low, or rankings
on a scale of 1 to 10.
Risk Assessment – Step 3 – Interpreting Risk
Analysis Result …
• The risk assessment is used to support two related functions
• Acceptance of risk
• Selection of cost-effective controls
• Risk assessment results must focus on most significant risks to the
organizations
Risk Mitigation
• Risk mitigation involves the selection and implementation of security
controls to reduce risk to a level acceptable to management, within
applicable constraints.
• The process of risk mitigation has greater flexibility,
• The sequence of risk mitigation will differ depending on
organizational culture and the purpose of the risk management
activity
• Risk mitigation steps may have to be followed in some sequence.
Risk Mitigation – Selecting Safeguards
• A primary function of computer security risk management is the
identification of appropriate controls.
• We may have to decide the appropriate and cost-effective security control
to be added
• Locking a Door vs Posting a Security Guard to a LAN equipment room
• Factors to be considered to select security controls
• organizational policy, legislation, and regulation;
• safety, reliability, and quality requirements;
• system performance requirements
• timeliness, accuracy, and completeness requirements;
• the life cycle costs of security measures;
• technical requirements;
• cultural constraints.
Risk Mitigation – Accept Residual Risk
• Residual risk is the risk that remains after efforts to identify and
eliminate some or all types of risk have been made.
• Risk acceptance should consider various factors besides those
addressed in the risk assessment.
• Risk acceptance is linked to the selection of safeguards since, in some cases,
risk may have to be accepted because safeguards are too expensive.
• Risk acceptance shall consider limitation of the risk assessment
• Risk acceptance is closely related to accreditation
Risk Mitigation - Implementing Controls and
Monitoring Effectiveness
• Selecting appropriate safeguards does not reduce risk;
• safeguards need to be effectively implemented.
• Risk management needs to be an ongoing process to be effective
• Periodic assessment and improvement of safeguards and reanalysis
of risks is required.
Uncertainty Analysis
• Uncertainty analysis documents speculations, best guesses,
incomplete data, and many unproven assumptions.
• Sources of uncertainty in risk management process
• lack of confidence or precision in the risk management model or
methodology
• lack of sufficient information to determine the exact value of the elements of
the risk model, such as threat frequency, safeguard effectiveness, or
consequences.
• Collected data is also source of uncertainty
• Statistical data – small sample size, unaccounted parameter, misleading
results
• Expert analysis – projections are subjective
Outline

Security Policy

Security Strategy

Security Risk Management

Assurance
Computer Security Assurance
• Computer security assurance is the degree of confidence one has
that the security measures work as intended to protect the system
and the information it processes.
• It is NOT an absolute guarantee that the measures work as intended.
• It is extremely difficult to know how a system is secured.
• Assurance is difficult to describe
Accreditation and Assurance
• Accreditation is a formal acceptance of the adequacy of a system's
security.
• It is as a form of quality control.
• The accreditation process obliges managers to make the critical decision
regarding the adequacy of security safeguards
• The decision should be based on adequate information:
• Technical features (Do they operate as intended?).
• Operational practices (Is the system operated according to stated procedures?).
• Overall security (Are there threats which the technical features and operational
practices do not address?).
• Remaining risks (Are they acceptable?).
Selecting Assurance Methods
• The assurance method can be selected based on
• Risk assessment results
• Certification
• The accrediting official needs to analyze the pros and cons of
• the cost of assurance
• the cost of controls
• the risks to the organization.
• At the end of the accreditation process, the accrediting official will be
the one to accept the remaining risk.
• In selecting assurance methods, the need for assurance should be
weighed against its cost.
Planning and Assurance
• Assurance planning should begin during the planning phase of the
system life cycle
• Planning for assurance helps a manager make decisions about what
kind of assurance will be cost-effective.
• If assurance is planned after implementation, the number of ways to
obtain assurance gets smaller
Design and Implementation Assurance
• Design and implementation assurance addresses
• whether the features of a system, application, or component meets security
requirements and specifications
• Whether they are well designed and well built.
• Design and implementation assurance examines system design,
development, and installation.
• Design and implementation assurance should be examined from
components and systems points of views.
• Component assurance looks at the security of a specific product or system
component (e.g. OS, application, …)
• System assurance looks at the security of the entire system,including the interaction
between products and modules.
Design and Implementation Assurance ..
• Major methods for obtaining design and implementation assurance.
• Testing and Certification
• Standard Conformance Testing and Validation Suites
• Use of Advanced or Trusted Development
• Use of Reliable Architectures
• Use of Reliable Security
• Evaluations
• Assurance Documentation
• Accreditation of Product to Operate in Similar Situation
• Self-certification
• Warranties
• Manufacturer’s published assertions
Methods for D & I assurance
• Testing and Certification
• Testing should be done throughout the life cycle of the system
• Functional testing - to see if a given function works according to its
requirements
• Penetration testing - to see if security can be bypassed.
• Certification is a formal process for testing components or systems against a
specified set of security requirements.
• Certification is normally performed by an independent reviewer, rather
• than one involved in building the system.
• Standard Conformance Testing and Validation Suites
• Some standardization organizations release conformance testing tools
• Using these tools we can validate if a product/system conforms to a standard
Methods for D & I assurance
• Use of Advanced or Trusted Development
• In the development of both commercial off-the-shelf products and more
customized systems, the use of advanced or trusted system architectures,
development methodologies, or software engineering techniques can provide
assurance.
• Use of Reliable Architecture
• Some architectures are more reliable than others
• In-built fault-tolerance
• Redundancy
• Redundant array of inexpensive disks (RAID)
Methods for D & I assurance
• Use of Reliable Security
• ease of safe use - a system that is easier to secure will be more likely to be secure.
• A system is more secure if we use matured solutions (rather than new techs)
• Older and more tested software most likely have fewer bugs
• Evaluations
• A product evaluation normally includes testing.
• Evaluations can be performed by many types of organization
• Government agencies
• Independent organizations (E.g., trade and professional associations)
• Other vendors or commercial groups
• individual users or user consortia.
Methods for D & I assurance
• Assurance Documentation
• Assurance documentation can address the security either for a system or for
specific components.
• System-level documentation describes the system's security requirements
and how they have been implemented, including interrelationships among
applications, the operating system, or
networks.
• Component-level documentation describes each component separately.
• Accreditation of Product to Operate in Similar Situation
• If the system is proved to be effective in a similar situation, we can use it for
assurance
• But we should remember that accreditation is environment specification and
system specification
Methods for D & I assurance
• Self-Certification
• does not rely on an independent agent to perform a technical evaluation of a
system
• A resulting certification report can be read to determine whether the security
requirement was defined and whether a meaningful review was performed
• Warranties, Integrity Statements, and Liabilities
• If a manufacturer, producer, system developer, or integrator is willing to correct
errors within certain time frames or by the next release, this should give the system
manager a sense of commitment to the product and of the product's quality.
• An integrity statement is a formal declaration or certification of the product.
• Warranty – promise to fix the item
• Liability – promise to pay for loses
Methods for D & I assurance
• Manufacturer's Published Assertions
• A manufacturer's or developer's published assertion or formal declaration
provides a limited amount of assurance based exclusively on reputation.
• Distribution Assurance
• It is often important to know that software has arrived unmodified, especially
if it is distributed electronically.
• checkbits or digital signatures can provide high assurance that code
has not been modified.
• Anti-virus software can be used to check software that comes from sources
with unknown reliability
Operational Assurance
• Design and Implementation assurance addresses the quality of
security features built into systems.
• Operational assurance addresses
• the system's technical features are being bypassed
• The system’s technical features have vulnerabilities
• required procedures are being followed.
• It does not address changes in the system's security requirements
• Security tends to degrade during the operational phase of the system
life cycle.
• Users and admins tend to take shortcut
Operational Assurance - Methods
• System audit
• a one-time or periodic event to evaluate security.
• An audit can vary widely in scope:
• it may examine an entire system for the purpose of reaccreditation or
• it may investigate a single anomalous event.
• Can be self-audits or be performed by external/independent auditor
• Monitoring
• an ongoing activity that checks on the system, its users, or the environment.
• More “real-time” than System Audit.
Audit Methods and Tools
• Automated tools
• Manual review is too difficult
• Two types of automated tools
• Active tools – find vulnerabilities by trying to exploit them
• Passive tests - examine the system and infer the existence of problems from the state of
the system.
• These tools are also used by hackers
• Internal Controls Audit
• An auditor can review controls in place and determine whether they are
effective
• Both computer and non-computer-based controls are analyzed
Audit Methods and Tools …
• Security Checklists
• computer security plan provides a checklist against which the system can be
audited.
• Penetration Testing
• Penetration testing can use many methods to attempt a system break-in.
• Both Automated tools and manual methods can be used
• Social Engineering can also be employed
Monitoring Methods and Tools
• Review of System Logs
• Periodically review system logs
• Observe changes on dashboards, …
• Automated Tools
• Virus scanners
• Checksumming
• Password crackers
• Intrusion detectors
• System performance monitoring
• Configuration Management
• configuration management provides assurance that the system in operation is the
correct version
Monitoring Methods and Tools …
• Trade Literature (Publications and Electronic News)
• In addition to monitoring the system, it is useful to monitor external sources
for information.
• The Forum of Incident Response Teams (FIRST) has an electronic mailing list that
receives information on threats, vulnerabilities, and patches