1 Computer Security Principles and Practices Security Audit IT Security Management & Risk Assessment IT Security Controls, Plans & Procedures Gregory (Greg)

1

Computer Security Principles and Practices

Security Audit

IT Security Management & Risk Assessment

IT Security Controls, Plans & Procedures

Gregory (Greg) Maltby, PMP, BSCSOctober 11, 2010EECS 710

Technical Security Controls

2

IT Security Management Controlsand Implementa-tion

3

4


Security Audit



5

Security Audit

• Security auditing architecture• Security audit trail• Implementing the logging function• Audit trail analysis• Example: an integrated approach

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 Guidelines1. Agree on audit requirements with management2. Scope of the checks should be agreed and controlled3. Checks limited to read-only access to software & data4. Other access only for isolated copies of system files, then erased or

given appropriate protection5. Resources for performing the checks should be explicitly identified

and made available6. Identify / agreed on special or additional requirements7. All access should be monitored & logged, produce a reference trail 8. Document procedures, requirements, responsibilities9. 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 ExampleEvent Type: Success AuditEvent Source: Security Event Category: (1)Event ID: 517Date: 3/6/2006Time: 2:56:40 PMUser: NT AUTHORITY\SYSTEMComputer: KENTDescription: The audit log was clearedPrimary User Name: SYSTEM Primary Domain: NT AUTHORITYPrimary Logon ID: (0x0,0x3F7) Client User Name: userkClient Domain: KENT Client Logon ID: (0x0,0x28BFD)

20

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

36


Security Audit



37


• IT Security Management• Organizational context and Security Policy• Security Risk Assessment• Detailed Security Risk Analysis

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 Manange-ment

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 TopicsNeeds 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)

64

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 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 MeaningRisk 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

Existing Controls

Likelihood Consequence

Level of Risk

Risk Priority

Internet router

Outside hacker attack

Admin password only

Possible Moderate High 1

Destruction of data center

Accidental fire or flood

None (no disaster recovery plan)

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

71


Security Audit



72


• IT Security management implementation• Security controls or safeguards• IT security plan• Implementation of controls• Implementation follow-up

IT Security Management Controlsand Implementa-tion

73

• 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

Controls or Safeguards

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

79

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

NSIT Security Controls (cont)

80

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

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

- Set policy for strong admin passwords

- Set backup strategy for router configuration files

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

10/29- 10/30

Look into replacing Telenet

86

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 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

Security Implementation Follow-Up

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

Documents

1 Computer Security Principles and Practices Security Audit IT Security Management & Risk Assessment IT Security Controls, Plans & Procedures Gregory (Greg)