Addis Ababa University
Faculty of Science
Department of Computer Science
COSC 6301 – Computer Security
Chapter 3 – Management Controls
By
Girum Ketema (PhD)
Girumk@gmail.com
Girum.ketema@ju.edu.et
Outline
Computer Security Policy
Computer Security Strategy
Computer Security Risk Management
Assurance
Outline
Computer Security Policy
Computer Security Strategy
Computer 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 missioncritical 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 as defined 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
Computer Security Policy
Computer Security Strategy
Computer Security Risk Management
Assurance
Strategy
• Strategy
• Is a plan of action designed to achieve a long-term or overall aim
• Computer Security Strategy
• plan that integrates the organization's major Computer (Information System
security goals, policies, and action sequences into a cohesive whole
• Comprehensive security strategy involves three aspects:
• Policy: What is the security scheme supposed to do?
• Implementation/mechanisms: How does it do it?
• 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 Action:
• Prevention - Make sure that no attack is successful
• Practically impossible
• We can make reasonable goals. Example: Encryption of Transmitted Data
• Detection – Determine if an attack is going on or about to happen
• Intrusion detection systems detect unauthorized access
• Detection of DoS Attack
• Response – action to stop or deter the attack
• When attacks are detected, the system responds in a way to stop the attack
• Recovery – getting back to where we were before the attack
• Usually through backup systems
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
Initiation
• Need
Specification
• Purpose
Documentation
Development/
Acquisition
• Design
• Purchase
• develop
Implementation
• Testing
• Installation
Operation/
Maintenance
• Performing
phase
• A series of
modification
Disposal
• Replaced by a
new system
Security and Planning – In System Life Cycle
Initiation
• Sensitivity
Assessment
Development/
Acquisition
• Determine security
requirement
• Incorporate Security
Into Spec
• Build/Buy
Implementation
• Install Security
Controls
• Security Testing
• Accreditation
Operation/
Maintenance
• Sec Op & Admin
• Operational
Assurance (Audit)
• Change Mgt
• Reaccreditation
Disposal
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: Jan 21, 2022
Outline
Computer Security Policy
Computer Security Strategy
Computer Security Risk Management
Assurance
Risk Management
• Risk is the possibility of something adverse happening.
• 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
• People recognize various threats to their best interests and take
precautions to guard against them or to minimize their effects
• Organizations are concerned with many types of risk.
Risk Management
• Computer 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 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 system under consideration,
• the part of the system that will be analyzed,
• the analytical method including its level of detail.
• The risk assessment may focus on different areas
•
•
•
•
New applications
Use of communications
Data center
The entire organization
• Focus could be on areas with unknown risk or known high-risks
Risk Assessment – Step 1 – determining 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
• High vs Low level
• Qualitative vs Quantitative
Risk Assessment – Step 2 - Collecting and
Analyzing Data
• Risk has many different components:
•
•
•
•
•
•
Assets
Threats
Vulnerabilities
Safeguards
Consequences
Likelihoods
• The examination includes gathering data about the threatened area
and synthesizing and analyzing the information to make it useful.
• Documentation of assessments makes risk mitigation less time
consuming and helps answer questions regarding security 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 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 nearterm 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
Computer Security Policy
Computer Security Strategy
Computer 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