Transcript Slide 1 - McGraw Hill Higher Education

Information Assurance for the Enterprise: A Roadmap to Information Security, by Schou and Shoemaker
Chapter 14
Ensuring the Secure Use of
Software
McGraw-Hill/Irwin
Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.
Objectives
Define the requirements of application and
system software security
 Use processes for securing operating systems
 Structure and execute an operational process to
secure applications
 Describe software assurance methods

14-2
Software Assurance

Software is the weakest link in electronic
security process because it is both intangible
and complex


Most successful attacks result from the
exploitation of defects in commercial software
Important user actions include:
Securing operating system configuration
 Securing network management
 Ensuring that applications software does not
breach security and integrity
 Securing management of databases
 Data transmission services and encryption

14-3
Configuring the Operating System for
Security

Architectural design of the operating system
determines the effectiveness of its security

Most commercially available operating systems
offer
• Basic preprogrammed functions
• Capability to adapt functions provided by the system

Operating systems allow security administrators
to embed trust relationships into the system
processes

14-4
Involves establishing and maintaining access
rights of every user and process
Types: Assigning the Proper Label

Access control at the system level requires the
definition of access types
Label may apply to a structure, class, module,
defined interface, or user
 Types serve as the basis for making the
automated decisions about:

• The form of the access
• The permissions that will be assigned to each request
Type is determined based on attributes, roles,
and relationships that each object possesses
within the system
 Establishing types is an ongoing function for
system administrators

14-5
Types: Assigning the Proper Label
Reference monitor is software that is interposed
between all subjects and objects within the
system
 Reference monitors provide four types of
services:

Link access control to a set of specified policies
 Monitor and regulate access based on policies
 Allow policies to be updated easily
 Log the degree of conformance of the
accumulated requests

14-6
Types: Assigning the Proper Label

14-7
Access process
Rights: Ensuring the Proper Access

Rights are the specific controls, restrictions, and
rules granted to a given subject upon access or
which apply to a particular object
Assigned and managed for each access attempt
 Granted by the administrator
 Administrator pre-establishes the actions through
internal access control tables

• May be part of the reference monitor and is similar to
the access control lists (ACL)

14-8
Assignment of rights determines the access
privileges granted to an object at a particular time
Policies and Operating System
Configuration

Policies establish the access control
requirements implemented and enforced by the
operating system at its interfaces

Complete and correct set of policies:
• Ensures a high degree of organizational control at the
automatic or system level
• Guarantees that system operations will be aligned with
the security requirements of the organization
14-9
Application Management Software and
Security

Application security includes the measures
installed to secure:
The applications themselves
 The practices to configure and manage securely
subsequent application use


Application assurance – increasingly critical
because Internet applications no longer load
and operate in isolation

Gained by identifying threats and ensuring
against application vulnerabilities by
• Patching them
• Reconfiguring the system to prevent exploitation
14-10
Scope of Application Security

Ensuring application: necessity of secure use

Secure use – actions to ensure software security
while it is in the operational environment
• Provides assurance that software will continue to
achieve its confidentiality, integrity, and availability
goals
• Establishes the appropriate level of confidence in the
entire portfolio of software items because they are
inter-connected
14-11
Scope of Application Security

Forms of secure use

Proactive
• Identification of threats and vulnerabilities
• Creation, assessment, and optimization of security solutions
• Implementation of controls to protect software and information

Reactive
• Threat response
• Detection of and reaction to intrusions or security violations
• Disaster recovery

14-12
Ensured by operational assurance, operational
analysis, and problem-resolution processes
Scope of Application Security

Types of response:

Proactive assurance response can be:
• Preventive
• Perfective
• Adaptive

Reactive assurance responses include:
• Corrective
• Emergency
14-13
Scope of Application Security

Types of response

14-14
The way the software receives, processes, or
transmits data must be a matter of certainty
Operational Assurance

Operational assurance is a proactive function
Uses defined policies, procedures, tools, and
standards to monitor, test, and review the
software to detect vulnerabilities or violations
 Identifies and resolves latent security and control
weaknesses present within the software
 Requires periodic performance reviews


14-15
Assurance is accomplished by monitoring the
ongoing function of the software
Ensuring Operational Effectiveness:
Making the Assurance Case

To ensure that operational assurance is done
correctly the organization should:
Assess and audit the policies, procedures, tools,
and standards used for operational assurance
 Document those assessments and audits and
make recommendations for improvement

• Standard procedure manual – steps for every activity
in the process
• Set of sanctioned actions, procedures, or protocols
that can be invoked:
• When an anticipated threat occurs
• When an unforeseen hazard occurs
14-16
Ensuring Operational Effectiveness:
Making the Assurance Case

Documented evidence (cont’d)
• Specific method for incident reporting or requesting change and
the procedures for responding to each report
• A process to ensure Business Continuity Plan
• Awareness of members with respect to secure use and time
requirement to perform them
• Precise steps taken to build awareness of correct practice
• Each employee’s specific education, training, and awareness
activities
• Explicit enforcement requirements and consequences for noncompliance
• Specification and evidence of personal agreement to the
consequences for non-compliance
• Enforcement practiced on a continuous basis
14-17
Operational Analysis

Operational analysis directly supports
operational assurance
Evaluates the consequences of vulnerabilities or
violations identified
 Goal – to understand the effect of identified
threats along with the impact of recommended
responses
 To produce valid results, all software, systems,
policies, processes, or objectives affected by that
threat must be included in the evaluation
 Wide range of considerations is necessary to
ensure a coordinated response

14-18
Operational Analysis

Areas of consideration in the development of a response
strategy might include:
• Effect of any response on the assurance case
• Type of violation, exposure, or vulnerability, and the threat that
might exploit it
• Scope of the impact and criticality of violation, exposure, or
vulnerability
• Feasible options for response
• Likelihood and feasibility of occurrence
• Safety and security impacts if a response is not implemented
• Implications of any proposed responses as they affect the
organization’s procedural infrastructure
• Resource requirements and staff capability required to implement
the response
• Feasibility and timelines for implementation
14-19
Problem Resolution

Ensures the integrity of the system or software
product is maintained throughout its life cycle
Associated activities revolve around establishing
and maintaining control mechanisms
 Guarantees the satisfactory resolution of
reported threats or violations brought to its
attention
 Confirm the long-term effectiveness of the
proposed solution
 Maintain a full set of documentation items
sufficient to warrant that the integrity of the
software has been satisfactorily assured

14-20
Problem Resolution

Importance of problem resolution in application
assurance

Sometimes established by contract
• To ensure that concerns involving threats arising from
the operational use of software do not persist
• Each reported problem is resolved quickly and that
participants know what that resolution was
It is normally conducted as a closed-loop activity
 It ensures coordination and assurance of the
chosen remediation option

14-21
Problem Resolution

Responsibilities of the process when resolution
is not required

Operational justification for not resolving a
problem or for not resolving it as soon as
possible
• Reasons might be established by factors such as the
amount of time and resources required to implement
the resolution
• Lack of current resources, difficulty, or infeasibility of
the repair, or an unwillingness to take down a critical
operational system
14-22
Problem Resolution

Ensuring the effectiveness of the resolution





14-23
Identify the appropriate change agent
Develop and document a statement of work (SOW) and
communicate it to the selected change agent
Develop and document the criteria that will be used to
test and evaluate the software to ensure that the
remediation was successful
Communicate these criteria to the change agent prior to
institution of the change process
Develop and document criteria for ensuring that the
elements and requirements of the software that must not
be modified remain unaffected
Problem Resolution

Reintegration: operationalizing the solution

Solution must be reintegrated into the array of day-to-day
functioning applications
• Decision maker who authorized the resolution must provide
approval to perform the reintegration
• Approval must be accompanied by proof of issue resolution

Reintegration is supported by comprehensive testing
programs
• It must be designed at the beginning of the resolution process
• It must certify satisfactory resolution and accurate functionality

Update and fully document the new software baseline
configuration
• Maintained under strict configuration management control
14-24
Problem Resolution

Ensuring the integrity of the solution post-change is
often continuous because changes are complex



Changes to software may eliminate vulnerabilities or
create new ones
Monitoring and evaluation must continue to understand
the long-term consequences of changes
Ensure an in-depth examination of the changed code
• Examination can include: penetration-testing, load-testing, or
other stress-testing methods
• This process continues until the designated decision maker
determines that the resolution is satisfactory

14-25
Update the range of countermeasures deployed to
enforce security status and requirements of the software
Problem Resolution

Management responsibilities for problem resolution
must certify that:



Non-concurrences identified in the testing and review
process were addressed
The problem-resolution process was properly managed
They may need to provide documentary evidence
proving:
• Resource considerations were factored into the initial
authorizations
• The resolution was authorized by the proper authority and
documentation of an approved schedule or timetable
• A capable status-accounting function involved the use of
established baselines for each software item and the ability to
document the current state of the software at all times
14-26
Certification and Accreditation of
Applications

Critical applications need to verify:
Assessment and identification are secured by an
appropriate agent
 Done using a commonly accepted process
 Findings of that process are accredited by formal
certification
 Re-accreditation of the initial results will be
confirmed on a periodic basis
 Intervals for re-accreditation are specified by
organizational policy and/or external regulation

• Good practice: Conduct audits using a legitimate thirdparty agency
14-27
Certification and Accreditation of
Applications

Role of audit in certifying applications
 Principal condition required for the audit process
is the independence of the auditing agent
• Entity must be empowered and able to operate
independent of the group undergoing the audit
• Must be guaranteed that an audit is based on
objective evidence and is conducted without bias
• Agents must be situated sufficiently far enough from
the group to ensure impartial execution
14-28
Certification and Accreditation of
Applications

Common Criteria has established a formal
certification infrastructure of trusted independent
evaluation labs for the universal certification of
the security levels of application software
• National Information Assurance Partnership (NIAP)
conducted under the sponsorship of the National
Security Agency (NSA)
• Third-party agencies are accredited through the
National Voluntary Laboratory Accreditation Program
(NVLAP)
• NVLAP serves as the accreditation body for certification of
NIAP Common Criteria Testing Laboratories (CCTLs)
14-29
Certification and Accreditation of
Applications

Organizing the audit process for security

Audit must be based on accepted auditing standard
• Accepted standard is the Common Criteria, but this varies based
on the situation
• Audit planning must be done in accordance with the applicable
audit standard and must address the specified audit objectives
• Auditor should gather reliable, pertinent, and practical evidence to
demonstrate that the audit objectives can be achieved

When the audit is completed
• Objective data and conclusions must be authenticated by suitable
analysis and justified
• Auditing agent’s report should describe the scope, objectives, and
duration of the examination, as well as the particulars of the work
performed
14-30
Certification and Accreditation of
Applications

Common Criteria: ensuring confidence in commercial
software

ISO 15408 standard, dubbed the Common Criteria
• They provide a catalogue of attributes that should be present in
any secure application
• They can serve as the basis for assessment and formal
certification of any software product
• They are a set of commonly recognized characteristics found in
trusted systems
• Their aim is to provide a rigorous examination of the security
capabilities of software by testing for an exhaustive set of useful
attributes employed to benchmark the required security behaviors
• They enumerate known security attributes that can be confirmed
through direct observation
14-31
Certification and Accreditation of
Applications

What does the common criteria do for application
security?


Provides an encyclopedic collection of standardized
security properties
Eleven generic areas of security in the standard are:
•
•
•
•
•
•
•
•
•
•
•
14-32
Security audit
Data communication
Cryptographic support
User data protection
Identification and authentication
Security management
Privacy
Protection of the security function
Resource utilization
Access
Trusted path/channels
Ensuring the Effective Security
Architecture

Security architecture
Presentation of security requirements
 Description of the discrete, formal process that
assures the development of a tangible structure
from a set of intangible requirements

14-33
Ensuring the Effective Security
Architecture

Purpose of security architecture is to ensure that
the software assets are protected by an effective
defense

14-34
Develop a defense in depth
Database Security


Due to the issues of access and interoperability,
databases are a major source of risk
Ensuring security of databases requires:


Development of a system architecture that implements
robust security functions within the database software
Development of security functions based on risk and
vulnerability assessment; refined by installation of realtime detection capabilities within DBMS
• Established based on a predefined set of rules
• Implemented by software utilities capable of discriminating
between various types of data and selectively exercising the
controls assigned

14-35
Definitions of data to be controlled are set using modeling
techniques