Computer Security
Principles and Practices
Security Audit
IT Security Management & Risk Assessment
IT Security Controls, Plans & Procedures
Gregory (Greg) Maltby, PMP, BSCS
October 11, 2010
EECS 710
1
Technical Security Controls
2
IT Security
Management
Controls
and
Implementation
3
Computer Security
Principles and Practices
Security Audit
IT Security Management & Risk Assessment
IT Security Controls, Plans & Procedures
4
Security Audit
•
•
•
•
•
Security auditing architecture
Security audit trail
Implementing the logging function
Audit trail analysis
Example: an integrated approach
5
Security Auditing Architecture
• Security Audit:
An independent review and examination of a system's records
and activities to determine the adequacy of system controls,
ensure compliance with established security policy and
procedures, detect breaches in security services, and
recommend any changes that are indicated for
countermeasures.
The basic audit objective is to establish accountability for system
entities that initiate or participate in security-relevant events
and actions. Thus, means are needed to generate and record a
security audit trail and to review and analyze the audit trail to
discover and investigate attacks and security compromises.”
6
Security Auditing Architecture
• Security Audit Trail:
A chronological record of system activities that is sufficient to
enable the reconstruction and examination of the sequence
of environments and activities surrounding or leading to an
operation, procedure, or event in a security-relevant
transaction from inception to final results”
7
Security Audit and Alarms Model
8
Distributed Audit Trail Model
9
Security
Auditing
Functions
10
Security Auditing Requirements – Event
Definition
• Event definition - must define what are
auditable events
– Common Criteria suggests:
• introduction of objects within the security-related portion of the software
into a subject’s address space
• deletion of objects
• distribution or revocation of access rights or capabilities
• changes to (subject or object) security attributes
• policy checks performed by the security software
• use of access rights to bypass a policy check
• use of identification and authentication functions
• security-related actions taken by an operator/user
• import or export of data from or to removable media
11
Additional Security Auditing Requirements
• Event detection: hooks created in the
application & monitoring software to capture
activity
• Event recording: secure storage resistant to
tampering or deletion.
• Event and audit trail analysis: software, tools,
and interfaces
• Security of the auditing function
• Minimal effect / impact on functionality
12
Security Audit – Implementation
Guidelines
1.
2.
3.
4.
5.
6.
7.
8.
9.
Agree on audit requirements with management
Scope of the checks should be agreed and controlled
Checks limited to read-only access to software & data
Other access only for isolated copies of system files, then erased
or given appropriate protection
Resources for performing the checks should be explicitly identified
and made available
Identify / agreed on special or additional requirements
All access should be monitored & logged, produce a reference trail
Document procedures, requirements, responsibilities
Person(s) doing audit independent of activities
13
Security Audit Trail – What to collect
• Issue of amount of data generated
– tradeoff quantity vs. efficiency
• Data items captured may include:
–
–
–
–
–
–
–
events related to the use of auditing software
events related to (the use of) system security mechanisms
events from IDS and firewall systems
system management / operation events
operating system access (e.g. system calls)
access to selected applications
remote access
14
Security Audit Trail – What to collect
• Auditable items suggested in X.816 (Table 15.2)
– events related to a specific connection
– events related to the use of security services
– events related to management operations or
notifications
– Auditable events (some examples)
• Deny access
• Authenticate
• Object: Creation, Deletion or Modification
15
Implementing (Audit Trail) Logging
• The foundation of a security auditing facility is
the initial capture of the audit data.
• Software must include hooks (capture points)
that trigger data collection and storage of
data as preselected events occur.
• Operating system / application dependent
– system-level logging can use existing means
16
Implementing the Logging Function
• Useful to categorize audit trails
–
–
–
–
system-level audit trails
application-level audit trail
user-Level audit trail
physical access control (equipment)
17
Auto Trail Category : System-Level
• System-level audit trails:
– are generally used to monitor and optimize system
performance
– can also serve a security audit function
– captures logins, device use, O/S functions, e.g.
• Jan 27 17:18:38 host1 login: ROOT LOGIN console
• Jan 27 17:19:37 host1 reboot: rebooted by root
• Jan 28 09:47:35 host1 shutdown: reboot by user1
18
System Level : Windows Event Log
• Each event is an entity that describes some
interesting occurrence
– each event record contains:
• numeric id, set of attributes, optional user data
– presented as XML or binary data
• Have three types of event logs:
– System event log – applications running under system
service accounts and drivers
– Application event log - user-level applications
– Security event log - Windows Local Security Authority
19
Windows Event Log Example
Event Type:
Success Audit
Event Source:
Security
Event Category: (1)
Event ID:
517
Date:
3/6/2006
Time:
2:56:40 PM
User:
NT AUTHORITY\SYSTEM
Computer:
KENT
Description:
The audit log was cleared
Primary User Name:
SYSTEM
Primary Domain:
Primary Logon ID:
(0x0,0x3F7) Client User Name:
Client Domain:
KENT
Client Logon ID:
20
NT AUTHORITY
userk
(0x0,0x28BFD)
Windows Event Categories
•
•
•
•
•
•
•
•
•
Account logon events
Account management
Directory service access
Logon events
Object access
Policy changes
Privilege use
Process tracking
System events
21
Auto Trail Category : Application-Level
• To detect security violations within an application
• To detect flaws in application's system interaction
• Record appropriate security related details, e.g.
– Apr 911:20:22 host1 AA06370: from=<user2@host2>, size=3355, class=0
– Apr 911:20:23 host1 AA06370: to=<user1@host1>, delay=00:00:02,
stat=Sent
– Apr 911:59:51 host1 AA06436: from=<user4@host3>, size=1424, class=0
– Apr 911:59:52 host1 AA06436: to=<user1@host1>, delay=00:00:02,
stat=Sent
22
Logging at Application Level
• Privileged applications present security issues
– audit data may not be captured by system or user-level
audit logs
– a large percentage of reported vulnerabilities
– e.g. failure to adequately check input data or application
logic errors
• Need to capture detailed behavior
• Applications can be written to create audit data
• If not done, consider two approaches to auditing:
– interposable libraries
– dynamic binary rewriting
23
Interposable
Libraries
24
Auto Trail Category : User-Level
• Trace activity of individual users over time
– documents user’s actions
– can be used as input to an analysis program that attempts
to define normal versus anomalous behavior
• May capture
– user interactions with system (e.g.)
•
•
•
•
commands issued
identification and authentication attempts
files and resources accessed.
may also log use of applications
25
Auto Trail Category : Physical Access
• Generated by physical access control
(equipment)
– e.g. card-key systems, alarm systems
• Sent to central host for analysis / storage
• Can log
– date/time/location/user of access attempt
– both invalid and valid access attempts
– attempts to change access privileges
– may send violation messages to personnel
26
Protecting Audit Trail Data: 3 alternatives
• Read/write file on host
– easy to implement, least resource use, fast access
– vulnerable to attack by intruder
• Write-once device (e.g. CD/DVD-ROM)
– more secure but less convenient
– need media supply and have delayed access
• Write-only device (e.g. printer)
– paper-trail but impractical for analysis
• Must protect both integrity and confidentiality
– using encryption, digital signatures, access controls
27
Audit Trail Analysis
• Analysis programs/procedures vary widely
– cf. NIST SP 800-92 offers some useful advice on this topic
• Security Admin must understand context of log
entries
– relevant info may reside in same / other logs, or non log
sources (e.g. configuration management entries)
– possibility for unreliable entries (e.g. “false positives”)
• Audit file formats contain a mix of plain text / codes
– hence must decipher manually / automatically
• To gain an understanding of log data - regularly
review log entries
28
Audit Analysis – Develop an Understanding of
• Organizations policies regarding acceptable use
• Security software (used)
– security-related events that can be detected
– general detection profile of each program
• Operating Systems and major applications used
• Characteristics of common attack techniques
– esp. how the use of these techniques might be recorded on
each system
• Software needed to perform analysis
– Log viewers, log reduction scripts, database query tools
29
Types of Audit Trail Analysis
• Audit trails can be used in multiple ways
• This depends in part on when analysis is done
• Possibilities include:
– audit trail review after an event
• triggered by event to diagnose cause & remediate
– periodic review of audit trail data
• review bulk data to identify problems & behavior
– real-time audit analysis
• as part of an intrusion detection function
30
Audit Review
• Audit review capability provides administrator
with information from selected audit records
– actions of one or more users (e.g. identification)
– actions on a specific object or resource
– all or a specified set of audited exceptions
– actions on a specific system / security attribute
• May be filtered by time / source / frequency
• Used to provide system activity baseline
• To gauge level of security related activity
31
Approaches to Data Analysis
• Basic alerting
– indicate interesting type of event has occurred
• Baselining
– define normal vs. unusual events / patterns
– compare with new data to detect changes
• Windowing
– detection of events within a given set of parameters
• Correlation
– seek relationships among events
32
Integrated Approaches
• Large volume of audit data means manual analysis
and manual baselining is impractical
• Need a Security Information and Event Management
(SIEM) system
–
–
–
–
–
–
–
a centralized logging and analysis package
agentless or agent-based
normalizes a variety of log formats
analyzes combined data
correlates events among the log entries
identifies and prioritizes significant events
can initiate responses
33
SIEM Example: Cisco MARS
•
•
•
•
•
•
Example of SIEM product
Supports a wide variety of systems
Agentless with central dedicated server
Wide array of analysis packages
An effective GUI
Server collects, parses, normalizes, correlates
and assesses events to then check for false
positives, vulnerabilities, and profiling
34
Security Audit : Summary
• Introduced need for security auditing
• Audit model, functions, requirements
• Security audit trails
– system Level
– application Level
– user Level
• Implementing logging – “What to collect”
• Audit trail analysis
• Integrated SIEM products
35
Computer Security
Principles and Practices
Security Audit
IT Security Management & Risk Assessment
IT Security Controls, Plans & Procedures
36
IT Security Management & Risk
Assessment
•
•
•
•
IT Security Management
Organizational context and Security Policy
Security Risk Assessment
Detailed Security Risk Analysis
37
IT Risk Assessment Overview
• Security requirements means asking
– What assets do we need to protect?
– How are those assets threatened?
– What can we do to counter those threats?
• IT security management answers these
– determining security objectives & creating a risk
profile
– perform security risk assessment of assets
– select, implement, monitor controls
– iterate process
38
IT Security Management
IT Security Management: a process used to
achieve and maintain appropriate levels of
confidentiality, integrity, availability,
accountability, authenticity and reliability.
39
IT Security Management Functions
• Determining organizational IT security
objectives, strategies and policies
• Determining organizational IT security
requirements
• Identifying and analyzing security threats to IT
assets
• Identifying and analyzing risks
40
IT Security Management Functions (2)
• Specifying appropriate safeguards
• Monitoring the implementation and operation
of safeguards (providing cost effective
protection)
• Developing and implementing a security
awareness program
• Detecting and reacting to incidents
41
Overview
of IT
Security
Manangement
42
Plan – Do – Check - Act Process Model
43
Organizational Context and
Security Policy
• First examine organization’s IT security:
– objectives - wanted IT security outcomes
– strategies - how to meet objectives
– policies - identify what needs to be done
• Maintained and updated regularly
– using periodic security reviews
– reflect changing technical / risk environments
• Examine role of IT systems in organization
44
Security Policy Topics
Needs to address:
• scope and purpose of the policy
• the relationship of the security objectives to legal
& regulatory obligations & business objectives
• IT security requirements
• assignment of responsibilities
• risk management approach
• security awareness and training
45
Security Policy Topics (2)
Need to address (cont)
• general personnel issues
• any legal sanctions that may be imposed on staff
• integration of security into systems development
• information classification scheme
• contingency and business continuity planning
• incident detection and handling processes
• how when policy reviewed, and change control to it
46
IT Security Needs Management Support
• IT security policy must be supported by senior
management
• Need IT security officer
– to provide consistent overall supervision
– liaison with senior management
– coordinate the Security Response Team efforts
– manage process (including security awareness)
• Large organizations needs IT security officers
on major projects / teams
47
Security Risk Assessment
• Critical component of process
– else may have vulnerabilities or waste money
• Ideally examine every asset versus risk
– not feasible in practice
• Choose one of possible alternatives based on
organization’s resources and risk profile
– baseline
– informal
– detailed (formal)
– combined
48
Risk Assessment – Baseline Approach
• Use “industry best practice ”
– easy, cheap, can be replicated
– but gives no special consideration to org
– may give too much or too little security
• Implement safeguards against most common
threats
• Baseline recommendations and checklist
documents available from various bodies
• (usually) Only suitable for small organizations
49
Risk Assessment – Informal Approach
• Conduct informal, practical risk analysis on
organization’s IT systems
• Exploits knowledge and expertise of analyst
• Fairly quick and cheap
• Does address some organization’s specific issues
• Some risks may be incorrectly assessed
• Skewed by analysts views, varies over time
• Suitable for small to medium sized organizations
50
Risk Assessment – Detailed Approach
• Most comprehensive approach
• Assessment uses a formal structured process
– with a number of stages
– identify likelihood of risk and consequences
– analysis provides confidence controls appropriate
• Costly and slow, requires expert analysts
• May be a legal requirement to use
• Suitable for large organizations with IT systems
critical to their business objectives
51
Risk Assessment – Combined Approach
• Combines elements of other approaches
– initial (suitable) baseline on all systems
– informal analysis to identify critical risks
– formal assessment on these systems
– iterated and extended over time
•
•
•
•
Better use of time and money resources
Better security earlier, evolves over time
May miss some risks early
Recommended alternative for most organizations
52
Risk
Assessment
Methodology
53
Risk Assessment Context
• Determine broad risk exposure of organization
– related to wider political / social environment
– identify legal and regulatory constraints
– provide baseline for organization’s risk exposure
• Specify organization’s risk appetite
• Set boundaries of risk assessment
– depend in part on the risk assessment approach used
• Decide on risk assessment criteria used
54
Risk Assessment Asset Identification
• Identify assets
– “anything which needs to be protected”
– of value to organization to meet its objectives
– tangible or intangible (assets)
– in practice try to identify significant assets
• Draw on expertise of people in relevant areas
of organization to identify key assets
– identify and interview such personnel
– see checklists in various standards
55
Risk Related Terms
• Asset: anything that has value to the organization.
• Threat: a potential cause of an unwanted incident
which may result in harm to a system or
organization.
• Vulnerability: a weakness in an asset or group of
assets which can be exploited by a threat
• Risk: the potential that a given threat will exploit
vulnerabilities of an asset or group of assets to cause
loss or damage to the assets.
56
Threat identification
• To identify threats or risks to assets ask:
– 1. Who or what could cause it harm?
– 2. How could this occur?
• Threats are anything that hinders or prevents an
asset (providing appropriate levels of the key
security services) from functioning properly:
– confidentiality, integrity, availability, accountability,
authenticity and reliability
• Assets may have multiple threats
57
Threat Sources
• Threats may be
– natural “acts of god”
– man-made and either accidental or deliberate
• Should consider human attackers:
– motivation
– capability
– resources
– probability of attack
– Deterrence
• Any previous history of attack on organization
58
“Threat identification” - Sources
• Depends on risk assessors experience
• Uses variety of sources
– natural threat chance from insurance (industry)
statistics
– lists of potential threats in standards, IT security
surveys, information from government security
agencies (e.g. CERT)
– needs to be tailored to organization’s environment
– consider any vulnerabilities in its IT systems
59
Vulnerability Identification
• Identify exploitable flaws or weaknesses in
organization’s IT systems or processes
• Determine applicability and significance of
threat to organization
• Need combination of threat and vulnerability
to create a risk to an asset
• (again) Can use lists of potential vulnerabilities
in standards etc.
60
Analyze Existing Controls and Risks
• Specify likelihood of occurrence of each identified
threat to an asset given existing controls
– management, operational, technical processes and
procedures to reduce exposure of organization to
some risks
• Specify consequence should threat occur
• Derive overall risk rating for each threat
– risk = probability threat occurs x cost to organization
61
Analyze Risks (cont)
• In practice, risks are very hard to determine
exactly / estimate
• Use qualitative not quantitative, ratings for
each risk (probability, cost)
• Goal : order / prioritize resulting risks, to help
determine which risks to address first (i.e.
which risks to focus resources on)
62
Determine Likelihood (table 16.2, pg. 525)
Rating
Likelihood
Description
Expanded Definition
1
Rare
May occur only in exceptional circumstances and may
deemed as “unlucky” or very unlikely.
2
Unlikely
Could occur at some time but not expected given current
controls, circumstances, and recent events.
3
Possible
Might occur at some time, but just as likely as not. It may be
difficult to control its occurrence due to external influences.
4
Likely
Will probably occur in some circumstance and one should
not be surprised if it occurred.
5
Almost
Certain
Is expected to occur in most circumstances and certainly
sooner or later.
63
Risk Consequences
(Table 16.3, pg. 526)
Rating Consequence
1
Insignificant
Generally a result of a minor security breach in a single area. Impact is likely to
last less than several days and requires only minor expenditure to rectify
2
Minor
Result of a security breach in one or two areas. Impact is likely to last less than
a week, but can be dealt with at the segment or project level without
management intervention. Can generally be rectified within project or team
resources.
3
Moderate
Limited systemic (and possibly ongoing) security breaches. Impact is likely to
last up to 2 weeks and generally requires management intervention. Will have
ongoing compliance costs to overcome
4
Major
Ongoing systemic security breach. Impact will likely last 4-8 week sand require
significant management intervention and resources to overcome, and
compliance costs are expected to be substantial. Loss of business or
organizational outcomes is possible, but not expected, especially if this is a
once
5
Catastrophic
Major systemic security breach. Impact will last for 3 months or more and
senior management will be required to intervene for the duration of the event
to overcome shortcomings. Compliance costs are expected to be very
substantial. Substantial public or political debate about, and loss of confidence
in, the organization is likely. Possible criminal or disciplinary action is likely
6
Doomsday
Multiple instances of major systemic security breaches. Impact duration
cannot be determined and senior management will be required to place the
company under voluntary administration or other form of major restructuring.
Criminal proceedings against senior management is expected, and substantial
64
loss of business and failure to meet organizational objectives is unavoidable
Risk Level Determination
Consequences
Likelihood
Doomsday
Catastrophic
Major
Moderate
Minor
Insignificant
Almost
Certain
E
E
E
E
H
H
Likely
E
E
E
H
H
M
Possible
E
E
E
H
M
L
Unlikely
E
E
H
M
L
L
Rare
E
H
H
M
L
L
65
Risk Level Meaning
Risk Level
Description
Extreme
(E)
Will require detailed research and management planning at an
executive/director level. Ongoing planning and monitoring will be
required with regular reviews. Substantial adjustment of controls to
manage the risk are expected, with costs possibly exceeding original
forecasts.
High (H)
Requires management attention, but management and planning can be
left to senior project or team leaders. Ongoing planning and monitoring
with regular reviews are likely, though adjustment of controls are likely to
be met from within existing resources.
Medium
(M)
Can be managed by existing specific monitoring and response
procedures. Management by employees is suitable with appropriate
monitoring and reviews.
Low (L)
Can be managed through routine procedures.
66
Risk Register
Asset
Threat /
Vulnerability
Internet
router
Outside
Admin
hacker attack password
only
Destruction Accidental
of data
fire or flood
center
Existing
Controls
None (no
disaster
recovery
plan)
Likelihood
Consequence Level
of Risk
Risk
Priority
Possible
Moderate
High
1
Unlikely
Major
High
2
67
Risk Treatment Alternatives
•
•
•
•
•
Risk acceptance
Risk avoidance
Risk transferal
Reduce the consequence
Reduce likelihood
68
Risk Register Exercise
69
IT Security Management & Risk
Assessment : Summary
• Need to perform risk assessment as part of IT
security management process
• Relevant security standards
• Presented risk assessment alternatives
• Detailed risk assessment process involves:
– context including asset identification
– identify threats, vulnerabilities, risks
– analyze and evaluate risks
70
Computer Security
Principles and Practices
Security Audit
IT Security Management & Risk Assessment
IT Security Controls, Plans & Procedures
71
IT Security Controls, Plans & Procedures
•
•
•
•
•
IT Security management implementation
Security controls or safeguards
IT security plan
Implementation of controls
Implementation follow-up
72
IT Security
Management
Controls
and
Implementation
73
Controls or Safeguards
• Controls or Safeguards are
– practices, procedures or mechanisms which may
protect against a threat, reduce a vulnerability,
limit the impact of an unwanted incident, detect
unwanted incidents and facilitate recovery
74
Controls or Safeguards: Classes
• Management
– focus on security policies, planning guidelines, and
standards that influence the selection of
operational and technical controls to reduce the
risk of loss and to protect the organization’s
mission
– refer to issues that management needs to address
• Technical
– involve the correct use of hardware and software
security capabilities in systems
75
Controls or Safeguards: Classes
• Operational
– address the correct implementation and use of
security policies and standards, ensuring
consistency in security operations and correcting
identified operational deficiencies
– relate to mechanisms and procedures that are
primarily implemented by people rather than
systems
76
Additional Types of Controls
• Supportive: pervasive, generic, underlying technical
IT Security capabilities, used by many other controls
• Preventative: focus on preventing security breaches
from occurring by inhibiting attempts to violate
security policies of exploit a vulnerability
• Detection and Recovery: focus on the response to a
security breach by warning of violations and provide
means to restore the resulting lost computing
resources
77
Technical Security Controls
78
NSIT Security Controls
Class
Management
Risk Assessment
Management
Planning
Management
System and Services Acquisition
Management
Certification, Accreditation,& Security
Assessments
Technical
Identification and Authentication
Technical
Access Control
Technical
Audit and Accountability
Technical
System and Communication Protection
79
NSIT Security Controls (cont)
Class
Operational
Personnel Security
Operational
Physical and Environmental Protection
Operational
Contingency Planning
Operational
Configuration Management
Operational
Maintenance
Operational
Systems and Information Integrity
Operational
Media Protection
Operational
Incident Response
Operational
Awareness and Training
80
Potential Adjustments to Controls
•
•
•
•
•
•
Technology
Common controls
Public access systems
Infrastructure controls
Scalability issues
Risk assessment
81
Residual Risk
82
Cost-Benefit Analysis
• Perform C-B A to identify appropriate controls
– greatest benefit given resources available
•
•
•
•
Qualitative or quantitative
Show cost justified by reduction in risk
Contrast impact of implementing it or not
Management chooses selection of controls
– considers if it reduces risk too much or not enough, is
too costly or appropriate
83
IT Security Plan
• Provides details of
– what will be done
– what resources are needed
– who is responsible
• Goal is to detail the actions needed to
improve the identified deficiencies in the
organization’s risk profile in a timely manner.
84
IT Security Plan (2)
• IT Security Plan should include
– risks (asset/threat/vulnerability combinations)
– recommended controls (from risk assessment)
– action priority for each risk
– selected controls (based on Cost-Benefit Analysis)
– required resources
– responsible personnel
– implementation dates (start and end dates)
– maintenance requirements
– other comments (as needed)
85
IT Security Controls
– Implementation Plan Table
Risk (Asset
/ Threat)
Level
of
Risk
Recommended
Controls
Priority
Selected
Controls
Required
Resources
Responsible
Persons
Start –
End
Date
Other
Comments
Hacker
attack on
Internet
Router
High
- Disable
external
Telenet access
High
- Install
intrusion
detection
software
- 1 day of
network
admin
time to
install
and test
software
- 2 days
of
training
for
network
admin
staff
Bob,
Network
Admin
10/28
–
10/28
Look into
replacing
Telenet
- Set policy for
strong admin
passwords
- Set backup
strategy for
router
configuration
files
86
10/29
10/30
Security Plan Implementation
• IT security plan documents what needs to be
done for each control
• Identifies personnel to perform needed tasks
– implement new or enhanced controls
– system configuration changes, software upgrades
or new system / software installation(s)
– development of new / extended procedures
• Monitor implementation to ensure it done
correctly (…test controls)
87
Security Training / Awareness
• Personnel need training
– on details of design and implementation
– awareness of operational procedures
• Also need general awareness for all
– all levels (personnel) in organization
– essential to meet security objectives
– aim to convince personnel that risks exist and
breaches may have significant consequences
88
Security Implementation Follow-Up
• Security management is cyclic, should be repeated
• Need to monitor implemented controls
• Evaluate changes for security implications
– if not done, may increase chance of security breach
• Follow-up includes
– maintenance of security controls
– security compliance checking
– change and configuration management
– incident handling
89
Maintenance of Implemented Controls
• Need continued maintenance and monitoring
of implemented controls to ensure continued
correct functioning and appropriateness
• Tasks include:
– periodic review of controls
– upgrade of controls to meet new requirements
– checking system changes to ensure they do not
impact controls
– address new threats or vulnerabilities
• Goal - ensure controls perform as intended
90
Security Compliance
•
•
•
•
Audit process to review security processes
To verify compliance with security plan
May use internal or external personnel
Usually based on checklists
– verify suitable policies and plans were created
– verify suitable selection of controls were chosen
– verify controls are maintained and used correctly
• Process often as part of wider general audit
91
Change Control / Management
• Change management is the process to review
proposed changes to systems
– evaluate security and wider impact of changes
– part of general systems administration process
– management of bug / patch testing and installation
– may be informal or formal
92
Configuration Management
• Configuration management is keeping track of
configuration and changes to each system
– information needed to help restore systems
following a failure
– to know what patches or upgrades might be
relevant to particular systems
– part of general systems administration process
93
Incident Handling
• Need procedures specifying how to respond to a
security incident(s)
– an incident will most likely occur sometime
• Response needs to reflect the range of
consequences of an incident on the organization
– procedures identify a suitable response
• Classify types of action to avoid panic
94
Incident Handling (2)
• Benefits of having incident response capability
– ability to respond systematically, taking
appropriate action
– helps personnel recover quickly, minimizing loss
– captured information can be used
• to better prepare for future incidents
• to properly deal with legal issues that may arise
95
Types of Security Incidents
• Any action threatening classic security services
• Unauthorized modification of info on a system
– corrupting information
– changing information without authorization
– unauthorized processing of information
• Unauthorized access to a system
– unauthorized viewing by information
– bypassing access controls
– denying access to another user
96
Incident Response Lifecycle
97
Detecting Incidents
• Reports from users or admin staff
– encourage such reporting
• Detected by automated tools
– e.g. system integrity verification tools, log analysis tools,
network and host intrusion detection systems, intrusion
prevention systems
– updated to reflect new attacks or vulnerabilities
– have costs – justified by benefits gained
• Security Admins must monitor vulnerability reports
98
Responding to Incidents
• Need documented response procedures
– how to identify cause of the security incident
– describe action taken to recover from it
• Procedures should
– identify typical categories of incidents and
approach taken to respond
– identify management personnel responsible for
making critical decisions and their contacts
– identify whether to report incident to police /
CERT etc.
99
Documenting Incidents
• Need to identify vulnerability used
– record details for future reference
– (purpose) how to prevent it occurring in future
• Consider impact on organization and it’s risk
profile
– was this a one-time isolated occurrence
– should the risk profile be reevaluated and
(possibly) changed
100
IT Security Controls, Plans &
Procedures : Summary
• Security controls also called safeguards
– management, operational, technical
– supportive, preventative, detection / recovery
• IT security plan
• Implementation of controls
– implement plan, training and awareness
• Implementation follow-up
– maintenance, compliance, change / config
management, incident handling
101
Real World / Industrial Strength
Security Plan
102