Unit 7

IT Security Management, Risk Assessment

and Security Auditing
 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 and risk profile
– perform security risk assessment of assets
– select, implement, monitor controls
 IT Security Management
• IT Security Management: a process used to achieve
and maintain appropriate levels of confidentiality,
integrity, availability, accountability, authenticity and
reliability. IT security management functions include:
• organizational IT security objectives, strategies and policies
• determining organizational IT security requirements
• identifying and analyzing security threats to IT assets
• identifying and analyzing risks
• specifying appropriate safeguards
• monitoring the implementation and operation of
safeguards
• developing and implement a security awareness program
• detecting and reacting to incidents
 IT Security
Management
Process
Plan - Do - Check – Act Process Model
(Deming Cycle)
take corrective and
preventative actions
(based on audits)

establish policy; define assess and measure

objectives and processes and report results

implement and operate

policy, controls, processes
 Security Policy
• needs to address:
– scope and purpose including relation of objectives to
business, legal, regulatory requirements
– IT security requirements
– assignment of responsibilities
– risk management approach
– security awareness and training
– general personnel issues and any legal sanctions
– 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
 Management Support
• IT security policy must be supported by senior
management
• need IT security officer
– to provide consistent overall supervision
– manage process
– handle incidents
• large organizations needs IT security officers
on major projects/teams
– manage process within their areas
 Security Risk Assessment
• critical component of process
– else may have vulnerabilities or waste money
• ideally examine every asset vs risk
– not feasible in practice
• choose one of possible alternatives based on
organization’s resources and risk profile
– baseline
– informal
– formal
– combined
 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
• Generally recommended only suitable for small
organizations
 Informal Approach
• conduct informal, pragmatic risk analysis on
organization’s IT systems
• exploits knowledge and expertise of analyst
• fairly quick and cheap
• does address some org specific issues
• some risks may be incorrectly assessed
• skewed by analysts views, varies over time
• suitable for small to medium sized orgs
 Asset Identification
• identify assets
– “anything which needs to be protected”
– of value to organization to meet its objectives
– tangible or intangible
– 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
 Terminology

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.
 Threat Identification
• to identify threats or risks to assets asK
– who or what could cause it harm?
– how could this occur?
• threats are anything that hinders or prevents
an asset providing appropriate levels of the
key security services:
– confidentiality, integrity, availability,
accountability, authenticity and reliability
• assets may have multiple threats
 Threat Identification
• depends on risk assessors experience
• uses variety of sources
– natural threat chance from insurance stats
– lists of potential threats in standards, IT security
surveys, info from governments
– tailored to organization’s environment
– and any vulnerabilities in its IT systems
 Vulnerability Identification
• identify exploitable flaws or weaknesses in
organization’s IT systems or processes
• hence 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
 Analyze Risks
• specify likelihood of occurrence of each identified
threat to asset given existing controls
– management, operational, technical processes and
procedures to reduce exposure of org to some risks
• specify consequence should threat occur
• hence derive overall risk rating for each threat
risk = probability threat occurs x cost to organization
• in practice very hard to determine exactly
• use qualitative not quantitative, ratings for each
• aim to order resulting risks in order to treat them
 Risk Likelihood

Rating Likelihood Expanded Definition

Description
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 Is expected to occur in most circumstances and
Certain certainly sooner or later.
 Risk Consequence
Rating Consequence Expanded Definition
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 weeks
and 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 off.
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 loss of business and failure to meet
organizational objectives is unavoidable.
Risk Level Determination and meaning
Consequences
Likelihood Doomsday Catastrophic Major Moderate Minor Insignificant

Almost E E E E H H
Certain
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

Risk Level Description

Extreme (E) Will require detailed r esearch 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.
 Document in Risk Register
and Evaluate Risks

Asset Threat/ Existing Likelihood Consequence Level of Risk

Vulnerability Controls Risk Priority
Internet Router Outside Hacker Admin Possible Moderate High 1
attack password
only
Destruction of Accidental Fire None (no Unlikely Major High 2
Data Center or Flood disaster
recovery
plan)
 Case Study: Silver Star Mines
• fictional operation of global mining company
• large IT infrastructure
– both common and specific software
– some directly relates to health & safety
– formerly isolated systems now networked
• decided on combined approach
• mining industry less risky end of spectrum
• management accepts moderate or low risk
 Assets
• reliability and integrity of SCADA nodes and net
• integrity of stored file and database information
• availability, integrity of financial system
• availability, integrity of procurement system
• availability, integrity of maintenance/production
system
• availability, integrity and confidentiality of mail
services
 Threats & Vulnerabilities
• unauthorized modification of control system
• corruption, theft, loss of info
• attacks/errors affecting procurement system
• attacks/errors affecting financial system
• attacks/errors affecting mail system
• attacks/errors maintenance/production
affecting system
 Risk Register
Asset Threat/ Existing Likelihood Consequence Level of Risk Priority
Vulnerability Controls Risk
Reliability and integrity Unauthorized layered Rare Major High 1
of the SCADA nodes and modification of firewalls
network control system & servers
Integrity of stored file Corruption, firewall, Possible Major Extreme 2
and database theft, loss of policies
information info
Availability and Attacks/errors firewall, Possible Moderate High 3
integrity of Financial affecting system policies
System
Availability and Attacks/errors firewall, Possible Moderate High 4
integrity of affecting system policies
Procurement System
Availability and Attacks/errors firewall, Possible Minor Medium 5
integrity of affecting system policies
Maintenance/
Production System
Availability, integrity Attacks/errors firewall, Almost Minor High 6
and confidentiality of affecting system ext mail Certain
mail services gateway
 Summary
• detailed 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
– analyse and evaluate risks
• Silver Star Mines case study
Security Auditing
Security Audit Architecture
(X.816)
Distributed Audit Trail Model
 Security
Auditing
Functions
 Security Audit Functions
• Data generation: Identifies the level of auditing, enumerates the
types of auditable events
• Event selection: Inclusion or exclusion of events from the auditable
set
• Event storage: Creation and maintenance of the secure audit trail
• Automatic response: reactions taken if detect a possible security
violation event
• Audit analysis: automated mechanisms to analyze audit data in
search of security violations
• Audit review: available to authorized users to assist in audit data
review
 Event Definition: Requirement
• Must define what are auditable events
• Common Criteria suggests:
– introduction of objects
– 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/export of data from/to removable media
 Other Audit Requirements
• Event detection hooks in software and
monitoring software to capture activity
• Event recording function with secure storage
• Event and audit trail analysis software, tools,
and interfaces
• Security of the auditing function: data but also
software and storage must be protected

• Minimal effect on functionality

 Auditable
Items
Suggested
in X.816
 Examples of System-Level Audit Trails
• Useful to categorize audit trails
• System-level audit trails:
– 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:46:53 host1 su: 'su root' succeeded for user1 on /dev/ttyp0
Jan 28 09:47:35 host1 shutdown: reboot by user1
 Example of Application-Level Audit Trails
• To detect security violations within an application
• To detect flaws in application's system interaction
• For critical/sensitive applications, e.g. email, DB
– email: sender, receiver, email size
– database: queries, table insertion and removal
• 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
 User-Level Audit Trails
• Trace activity of individual users over time
– to hold user accountable for actions taken
– 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
 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: NT AUTHORITY
• Primary Logon ID: (0x0,0x3F7)
• Client User Name: userk
• Client Domain: KENT
• Client Logon ID: (0x0,0x28BFD)
 Windows Event Categories
• Account logon events: acceptance/rejection of authentication
• Account management: account creation/deletion
• Directory service access: user access to active dir (that has a
system access control defined)
• Logon events: user log in/log off, bad password
• Object access: same as DSL but to registry and similar
• Policy changes: admin changes to access policies
• Privilege use: user right changes
• Process tracking: start and termination
• System events: start, reboot, shut down
UNIX Syslog
 Syslog Examples
Mar 1 06:25:43 server1 sshd[23170]: Accepted publickey for
server2 from 172.30.128.115 port 21011 ssh2
Mar 1 07:16:42 server1 sshd[9326]: Accepted password for
murugiah from 10.20.30.108 port 1070 ssh2
Mar 1 07:16:53 server1 sshd[22938]: reverse mapping checking
getaddrinfo for ip10.165.nist.gov failed - POSSIBLE
BREAKIN ATTEMPT!
Mar 1 07:26:28 server1 sshd[22572]: Accepted publickey for
server2 from 172.30.128.115 port 30606 ssh2
Mar 1 07:28:33 server1 su: BAD SU kkent to root on /dev/ttyp2
Mar 1 07:28:41 server1 su: kkent to root on /dev/ttyp2
Interposable
Libraries
Intercept calls to shared
100s of library functions;
can carry out audit
related functions
Dynamic Binary Rewriting
 Audit Trail Analysis
• Analysis programs/procedures vary widely
– cf. NIST SP 800-92 provide guidelines
• Must understand context of log entries
– relevant info in same / other logs, config
– possibility f unreliable entries
• Audit file formats mix of plain text / codes
– hence must decipher manually / automatically
• Ideally regularly review entries to gain
understanding of baseline
 Types of Audit Trail Analysis
• Audit trails can be used in multiple ways
• 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 a pattern that suggests
problem
– Real-time audit analysis
• as part of an intrusion detection function
 Audit Review: Specific Purpose
• Audit review capability provides admin with
information from selected audit records
– actions of one or more users
– 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 / freq etc
 Approaches to Data Analysis
• Basic alerting (simplest)
– indicates interesting type of event has occurred
• Baselining (anomaly detection)
– define normal vs unusual events/patterns
– anomaly detection
– thresholding (e.g., # of refused connections)
• Windowing
– of events within a set of parameters (e.g., time)
• Correlation
– seek relationships among events
 Example: Cisco MARS
• More elaborate than syslog
• Support 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
 Summary
• Introduced need for security auditing
• Audit model, functions, requirements
• Security audit trails
• Implementing logging
• Audit trail analysis
• Integrated SIEM products