1. Chapter 2

2. The first chapter focused on threats
The rest of the book focuses on defense
In this chapter, we will see that defensive thinking is build around the plan-protect- respond cycle
In this chapter, we will focus on planning
Chapters 3 to 8 focus on protection (day-by- day defense)
Chapter 9 focuses on response
Security management = plan – protect – respond
Bullet-proof glass protects but does not disturb the organization 2
Copyright Pearson Prentice-Hall 2009 2

3. Introduction: what does security planning mean?
Identify assets
Evaluate risks
Check compliance requirements/legislation
Set up security processes/policies and their evaluation practices
Vision
Driving forces: legislation
Organization
Security management = plan – protect – respond
Vision = avoid disasters. Must lead to policies/guidelines. 3
Copyright Pearson Prentice-Hall 2009 3

4. Technical security architectures Policy-driven implementation
Risk analysis
Technical security architectures
Policy-driven implementation
Policies and their implementation
Oversight
Governance frameworks 4
Copyright Pearson Prentice-Hall 2009 4

5. Technology Is Concrete
Can visualize devices and transmission lines
Can understand device and software operation
Management Is Abstract
Management Is More Important
Security is a process, not a product (Bruce Schneier)
Bullet-proof glass protects but does not disturb the organization
Management harder than tech? One-off solutions then deteriorate.
Cannot be informal. 5
Copyright Pearson Prentice-Hall 2009 5

6. 6 Copyright Pearson Prentice-Hall 2009
Comprehensive security = closing all routes to attack requires security management
1 defense appears good does not mean that security is good 6
Copyright Pearson Prentice-Hall 2009 6

7. Weakest link failure. Security management: must ask “what happens if x fails”
Many resources problem: some simple like a database, others complex like financial reporting.
A failure in any component will lead to failure for the entire system 7
Copyright Pearson Prentice-Hall 2009 7

8. Complex Need Formal Processes Cannot be managed informally
Planned series of actions in security management
Annual planning
Processes for planning and developing individual countermeasures …
Processes are planned series of actions. Security management process has to be a process, otherwise no compliance.
Vision -> policies/guidelines. Not in vacuum: cycle 8
Copyright Pearson Prentice-Hall 2009 8

9. Dominates security management thinking
Protection: plan-based creation and operation of countermeasures.
Lots of the contents of the rest of the course.
Dominates security management thinking 9
Copyright Pearson Prentice-Hall 2009 9

10. Like training doctors to pre-natal care only.
The systems life cycle goes beyond the SDLC, to include operational use. SLC thinking is critical in security 10
Copyright Pearson Prentice-Hall 2009 10

11. Vision
Your understanding about your role with respect to your company, its employees, and the outside world drives everything else
Vision: security’s role in the company 11
Copyright Pearson Prentice-Hall 2009 11

12. Security as an Enabler Security is often thought of as a preventer
But security is also an enabler
If have good security, can do things otherwise impossible
Engage in interorganizational systems with other firms
Can use SNMP SET commands to manage their systems remotely
Must get in early on projects to reduce inconvenience
..or: poor security means that the firm is too much in risk to innovate
SNMP: set is off if you have no security. Saves time if you can have it on.
Face your chicken test early.
Remember: cost/benefit 12
Copyright Pearson Prentice-Hall 2009 12

13. Positive Vision of Users
Must not view users as malicious or stupid
Stupid means poorly trained, and that is security’s fault
Must have zero tolerance for negative views of users
Users as resources: train to be front line security defenders. 13
Copyright Pearson Prentice-Hall 2009 13

14. Should Not View Security as Police or Military Force
Creates a negative view of users
Police merely punish; do not prevent crime; security must prevent attacks
Military can use fatal force; security cannot even punish (HR does that)
This is not efficient. Cops are not usually crime preventers. 14
Copyright Pearson Prentice-Hall 2009 14

15. Cannot Be Effective Unless Users Will Work with You
Need New Vision
Mother nurturing inexperienced offspring
Cannot Be Effective Unless Users Will Work with You
Consultation, consultation, consultation
Quote from a security head 15
Copyright Pearson Prentice-Hall 2009 15

16. Identify Current IT Security Gaps Identify Driving Forces
The threat environment
Compliance laws and regulations
Corporate structure changes, such as mergers
Identify Corporate Resources Needing Protection
Enumerate all resources
Rate each by sensitivity
The practice of security planning
Current security
What do we have that needs to protected: databases, web sites, spreadsheets.. How sensitive? 16
Copyright Pearson Prentice-Hall 2009 16

17. 17 Source: Benson et al: Security Planning, Microsoft
Copyright Pearson Prentice-Hall 2009 17

18. Compliance Laws and Regulations
Compliance laws and regulations create requirements for corporate security
Documentation requirements are strong
Identity management requirements tend to be strong
Compliance can be expensive
There are many compliance laws and regulations, and the number is increasing rapidly
Driving force = require a firm to change its security planning, protections and response.
Compliance laws create requirements to which corporate security must respond. But they are against generic/financial fraud.
IT must be used to detect 18
Copyright Pearson Prentice-Hall 2009 18

19. Sarbanes–Oxley Act of 2002 Massive corporate financial frauds in 2002
Act requires firm to report material deficiencies in financial reporting processes
Material deficiency a significant deficiency, or combination of significant deficiencies, that results in more than a remote likelihood that a material misstatement of the annual or interim financial statements will not be prevented or detected
SOX is about financial reporting to prevent fraud
Material deficiency = misleading financial reporting = possible deception = CEO jailtime 19
Copyright Pearson Prentice-Hall 2009 19

20. Sarbanes–Oxley Act of 2002
Note that it does not matter whether a material misstatement actually occurs—merely that there is more than a remote likelihood that it could occur and not be detected
A material deviation is a mere 5% deviation
Companies that report material deficiencies typically find that their stock loses value, and the chief financial officer may lose his or her job
Material deficiency <> material deviation 20
Copyright Pearson Prentice-Hall 2009 20

21. Privacy Protection Laws
The European Union (E.U.) Data Protection Directive of 2002
Many other nations have strong commercial data privacy laws
The U.S. Gramm–Leach–Bliley Act (GLBA)
The U.S. Health Information Portability and Accountability Act (HIPAA) for private data in health care organizations
Protect personal information 21
Copyright Pearson Prentice-Hall 2009 21

22. Data Breach Notification Laws
California’s SB 1386
Requires notification of any California citizen whose private information is exposed
Companies cannot hide data breaches anymore
Federal Trade Commission (FTC)
Can punish companies that fail to protect private information
Fines and required external auditing for several years 22
Copyright Pearson Prentice-Hall 2009

23. Industry Accreditation
For hospitals, etc.
Often have to security requirements
PCS-DSS
Payment Card Industry–Data Security Standards
Applies to all firms that accept credit cards
Has 12 general requirements, each with specific subrequirements 23
Copyright Pearson Prentice-Hall 2009

24. 24 The PCI DSS 12 requirements:
1. Install and maintain a firewall configuration to protect cardholder data.
2. Do not use vendor-supplied defaults for system passwords and other security parameters.
3. Protect stored cardholder data.
4. Encrypt transmission of cardholder data across open, public networks.
5. Use and regularly update antivirus software.
6. Develop and maintain secure systems and applications.
7. Restrict access to cardholder data by business need-to-know.
8. Assign a unique ID to each person with computer access.
9. Restrict physical access to cardholder data.
10. Track and monitor all access to network resources and cardholder data.
11. Regularly test security systems and processes.
12. Maintain a policy that addresses information security. 24
Copyright Pearson Prentice-Hall 2009

25. FISMA Federal Information Security Management Act of 2002
Processes for all information systems used or operated by a U.S. government federal agencies
Also by any contractor or other organization on behalf of a U.S. government agency
Certification, followed by accreditation
Continuous monitoring
Criticized for focusing on documentation instead of protection
Yearly audits
Certification of the system by an outside party
Accredition = an accr official reads the security documentation package, if satisfied gives authorization to operate (ATO) 25
Copyright Pearson Prentice-Hall 2009 25

26. Chief Security Officer (CSO) Where to Locate IT Security?
Also called chief information security officer (CISO)
Where to Locate IT Security?
Within IT
Compatible technical skills
CIO will be responsible for security
Outside of IT
Gives independence
Hard to blow the whistle on IT and the CIO
This is the most commonly advised choice
CIO likely to back the security dept’s efforts to create safe IT infrastructure 26
Copyright Pearson Prentice-Hall 2009 26

27. 27
Copyright Pearson Prentice-Hall 2009

28. Where to Locate IT Security?
Hybrid
Place planning, policy making, and auditing outside of IT
Place operational aspects such as firewall operation within IT 28
Copyright Pearson Prentice-Hall 2009

29. Top Management Support
Budget
Support in conflicts
Setting personal examples
If management does not ensure the security budget, the CISO cannot do anything
Conflict: “we need this now” “it is not secure”
Top managers have to follow the security guidelines 29
Copyright Pearson Prentice-Hall 2009 29

30. Relationships with Other Departments
Special relationships
Ethics, compliance, and privacy officers
Human resources (training, hiring, terminations, sanction violators)
Legal department
IT must work with HR on hiring and termination to check that security issues are taken into account
Legal: gets involved on major security incidents. Security policies must be legally sound. 30
Copyright Pearson Prentice-Hall 2009 30

31. Relationships with Other Departments
Special relationships
Auditing departments
IT auditing, internal auditing, financial auditing
Might place security auditing under one of these
This would give independence from the security function
Facilities (buildings) management
Uniformed security
Facilities: security cameras, access control
Uniformed staff: will seize computers in case of a crime 31
Copyright Pearson Prentice-Hall 2009 31

32. Relationships with Other Departments
All corporate departments
Cannot merely toss policies over the wall
Business partners
Must link IT corporate systems together
Before doing so, must exercise due diligence in assessing their security
IT sec is always mistrusted because of security’s potential to make life harder
Diligence with external companies 32
Copyright Pearson Prentice-Hall 2009 32

33. Outsourcing IT Security
Only or webservice (Figure 2-11)
Managed Security Service Providers (MSSPs) (Figure 2-12)
Outsource most IT security functions to the MSSP
But usually not policy
Complete outsourcing? Not popular, companies afraid of losing control of their security. 33
Copyright Pearson Prentice-Hall 2009 33

34. 34 Copyright Pearson Prentice-Hall 2009
Note: need to observe outgoing mail too 34
Copyright Pearson Prentice-Hall 2009 34

35. 35 Copyright Pearson Prentice-Hall 2009
Fire department: it would be idle most of the time
Bad contract: “can see logs” -> MSSP will sometimes look at logs, just send automated reports 35
Copyright Pearson Prentice-Hall 2009 35

36. 36 Semi-automated security log system, utilized by a MSSP
Copyright Pearson Prentice-Hall 2009

37. Realities Risk Analysis Can never eliminate risk
Total “Information assurance” is impossible
Risk Analysis
Goal is reasonable risk
Risk analysis weighs the probable cost of compromises against the costs of countermeasures
Also, security has negative side effects that must be weighed
You must manage when you cannot eliminate risks
Inf assurance = ensuring all goals of computer security [CIA] = “complete protection against robbery” impossible
Risk analysis compares probable losses with costs of security protection 37
Copyright Pearson Prentice-Hall 2009 37

38. = Single Loss Expectancy (SLE) SLE
Asset Value (AV)
X Exposure Factor (EF)
Percentage loss in asset value if a compromise occurs
= Single Loss Expectancy (SLE)
Expected loss in case of a compromise
SLE
X Annualized Rate of Occurrence (ARO)
Annual probability of a compromise
= Annualized Loss Expectancy (ALE)
Expected loss per year from this type of compromise
Classic risk analysis AV value of asset to be protected, e.g. server computer Exposure: say 80% of the AV is lost in case of a compromise.
SLE = AV * EF =
ARO 50%, someone will manage to compromise the computer one in 2 years: ALE = SLE * ARO =
Single Loss Expectancy (SLE)
Annualized Loss Expectancy (ALE)
Copyright Pearson Prentice-Hall 2009 38 38

39. Countermeasure A should reduce the exposure factor by 75%
Base Case
Countermeasure A
Asset Value (AV)
$100,000
Exposure Factor (EF)
80%
20%
Single Loss Expectancy (SLE): = AV*EF
$80,000
$20,000
Annualized Rate of Occurrence (ARO)
50%
Annualized Loss Expectancy (ALE): = SLE*ARO
$40,000
$10,000
ALE Reduction for Countermeasure NA
$30,000
Annualized Countermeasure Cost
$17,000
Annualized Net Countermeasure Value
$13,000
Eg. Strict defense in front of the computer
Countermeasure A should reduce the exposure factor by 75% 39
Copyright Pearson Prentice-Hall 2009 39

40. Counter measure B should cut the frequency of compromises in half
Base Case
Countermeasure B
Asset Value (AV)
$100,000
Exposure Factor (EF)
80%
Single Loss Expectancy (SLE): = AV*EF
$80,000
Annualized Rate of Occurrence (ARO)
50%
25%
Annualized Loss Expectancy (ALE): = SLE*ARO
$40,000
$20,000
ALE Reduction for Countermeasure NA
Annualized Countermeasure Cost
$4,000
Annualized Net Countermeasure Value
$16,000
E.g. better firewall to prevent external access
Counter measure B should cut the frequency of compromises in half 40
Copyright Pearson Prentice-Hall 2009 40

41. 41 Although Countermeasure A reduces the ALE more,
Countermeasure B is much less expensive.
The annualized net countermeasure value for B is larger.
The company should select countermeasure B.
Base Case
Countermeasure A B
Asset Value (AV)
$100,000
Exposure Factor (EF)
80%
20%
Single Loss Expectancy (SLE): = AV*EF
$80,000
$20,000
Annualized Rate of Occurrence (ARO)
50%
25%
Annualized Loss Expectancy (ALE): = SLE*ARO
$40,000
$10,000
ALE Reduction for Countermeasure NA
$30,000
Annualized Countermeasure Cost
$17,000
$4,000
Annualized Net Countermeasure Value
$13,000
$16,000
Cost should include losses on productivity 41
Copyright Pearson Prentice-Hall 2009 41

42. Uneven Multiyear Cash Flows
For both attack costs and defense costs
Must compute the return on investment (ROI) using discounted cash flows
In classic risk analysis: assume countermeasure costs and benefits will be same each year. In reality cm cost high on first year, lower later. Benefits often increase. 42
Copyright Pearson Prentice-Hall 2009 42

43. Total Cost of Incident (TCI)
Exposure factor in classic risk analysis assumes that a percentage of the asset is lost
In most cases, damage does not come from asset loss
For instance, if personally identifiable information is stolen, the cost is enormous but the asset remains
Must compute the total cost of incident (TCI)
Include the cost of repairs, lawsuits, and many other factors
“Loss of asset value” can be absurd in IT: customer data is stolen and later used in identity theft, the value is not reduced at all, but the cost can be enormous. 43
Copyright Pearson Prentice-Hall 2009 43

44. Many-to-Many Relationships between Countermeasures and Resources
Classic risk analysis assumes that one countermeasure protects one resource
Single countermeasures, such as a firewall, often protect many resources
Single resources, such as data on a server, are often protected by multiple countermeasures
Extending classic risk analysis is difficult 44
Copyright Pearson Prentice-Hall 2009

45. Impossibility of Knowing the Annualized Rate of Occurrence
There simply is no way to estimate this
This is the worst problem with classic risk analysis
As a consequence, firms often merely rate their resources by risk level 45
Copyright Pearson Prentice-Hall 2009

46. Problems with “Hard-Headed Thinking”
Security benefits are difficult to quantify
If only support “hard numbers” may underinvest in security
Papa Lopez Mex food. Maria took over. Got proposals for 3 projects: Cust Relations Management App, WIFI and improved IT security. Asked for ROI. Security project’s ROI was impossible to estimate -> rejected.
Got hacked, lost everything, including the recipe. 46
Copyright Pearson Prentice-Hall 2009 46

47. Perspective Impossible to do perfectly
Must be done as well as possible
Identifies key considerations
Works if countermeasure value is very large or very negative
But never take classic risk analysis seriously
But there has to be some way of evaluating security solutions. Insurance company? 47
Copyright Pearson Prentice-Hall 2009 47

48. Risk Reduction Risk Acceptance The approach most people consider
Install countermeasures to reduce harm
Makes sense only if risk analysis justifies the countermeasure
Risk Acceptance
If protecting against a loss would be too expensive, accept losses when they occur
Good for small, unlikely losses
Good for large but rare losses
Risk reduction is the focus of the book
Risk acceptance = not armoring your roof against meteor strikes 48
Copyright Pearson Prentice-Hall 2009 48

49. Risk Transference Buy insurance against security-related losses
Especially good for rare but extremely damaging attacks
Does not mean a company can avoid working on IT security
If bad security, will not be insurable
With better security, will pay lower premiums
Like fire and flood insurance for homeowners
Insurance companies require customers to install reasonable countermeasures. Higher premiums if bad security. 49
Copyright Pearson Prentice-Hall 2009 49

50. Risk Avoidance Not to take a risky action
Lose the benefits of the action
May cause anger against IT security
“Do not outsource” 50
Copyright Pearson Prentice-Hall 2009 50

51. Technical Security Architectures
Definition
All of the company’s technical countermeasures
And how these countermeasures are organized
Into a complete system of protection
Architectural decisions
Based on the big picture
Must be well planned to provide strong security with few weaknesses
Broad design of the parts and how they will interact.
Tech countermeasures: firewalls, hardened hosts, IDS etc and how they are integrated into a complete system of protection.
Remember: weakest link. 51
Copyright Pearson Prentice-Hall 2009 51

52. Technical Security Architectures
Dealing with legacy security technologies
Legacy technologies are technologies put in place previously, now somewhat ineffective
Too expensive to upgrade all legacy technologies immediately
Must upgrade if seriously impairs security
Upgrades must justify their costs
Add strengths to other areas to compensate. 52
Copyright Pearson Prentice-Hall 2009 52

53. Principles Defense in depth
Resource is guarded by several countermeasures in series
Attacker must breach them all, in series, to succeed
If one countermeasure fails, the resource remains safe 53
Copyright Pearson Prentice-Hall 2009

54. Principles Defense in depth versus weakest links
Defense in depth: multiple independent countermeasures that must be defeated in series
Weakest link: a single countermeasure with multiple interdependent components that must all succeed for the countermeasure to succeed
Interdependence: if one fails, all fail 54
Copyright Pearson Prentice-Hall 2009 54

55. Principles Avoiding single points of vulnerability
Failure at a single point can have drastic consequences
DNS servers, central security management servers, etc.
Most NY telecom companies brought their transmission lines together at WTC.
Not all SPF’s can be eliminated. Multiple IPS’s? 55
Copyright Pearson Prentice-Hall 2009 55

56. Principles Minimizing security burdens Realistic goals
Cannot change a company’s protection level overnight
Mature as quickly as possible
Single Sign-On
Realistic goals: NASA ratio of vulnerabilities. Gradually hardened the computers over 3 years. Cost $30 per computer. 56
Copyright Pearson Prentice-Hall 2009 56

57. Elements of a Technical Security Architecture
Border management
Internal site management
Management of remote connections
Interorganizational systems with other firms
Centralized security management
Increases the speed of actions
Reduces the cost of actions
Border management: firewalls
Internal site: internal firewalls, hardened clients/servers, IDS
Remote access technologies: VPN, 2-factor authentication
Security management/surveillance consoles: no need to travel 57
Copyright Pearson Prentice-Hall 2009 57

58. Policies Statements of what is to be done
Provides clarity and direction
Does not specify in detail how the policy is to be implemented in specific circumstances
This allows the best possible implementation at any time
Vary widely in length
E.g: require a background check for every new employee 58
Copyright Pearson Prentice-Hall 2009 58

59. Tiers of Security Policies
Brief corporate security policy to drive everything
Major policies
Hiring and firing
Personally identifiable information …
Corporate security policy: states the goals.
what users should/should not do with . 59
Copyright Pearson Prentice-Hall 2009 59

60. Tiers of Security Policies
Acceptable use policy
Summarizes key points of special importance for users
Typically, must be signed by users
Policies for specific countermeasures
Again, separates security goals from implementation 60
Copyright Pearson Prentice-Hall 2009 60

61. Writing Policies For important policies, IT security cannot act alone
There should be policy-writing teams for each policy
For broad policies, teams must include IT security, management in affected departments, the legal department, and so forth
The team approach gives authority to policies
It also prevents mistakes because of IT security’s limited viewpoint
Example: termination of employment due to IT fraud: HR needs to be in the policy writing team 61
Copyright Pearson Prentice-Hall 2009 61

62. 62
Copyright Pearson Prentice-Hall 2009

63. Implementation Guidance
Limits the discretion of implementers, in order to simplify implementation decisions and to avoid bad choices in interpreting policies
None (no guideline)
Implementer is only guided by the policy itself
Standards versus Guidelines
Standards are mandatory directives
Guidelines are not mandatory but must be considered
Policies: what, implementation guidelines: how
Ex: fingerprints required for access but a construction worker has lost a finger 63
Copyright Pearson Prentice-Hall 2009 63

64. Types of Implementation Guidance
Procedures: detailed specifications for how something should be done
Can be either standards or guidelines
Segregation of duties: two people are required to complete sensitive tasks
In movie theaters, one sells tickets and the other takes tickets
No individual can do damage, possibility of collusion 64
Copyright Pearson Prentice-Hall 2009

65. Types of Implementation Guidance
Procedures
Request/authorization control
Limit the number of people who may make requests on sensitive matters
Allow even fewer to be able to authorize requests
Authorizer must never be the requester
Mandatory vacations to uncover schemes that require constant maintenance
Job rotation to uncover schemes that require constant maintenance
Mandatory vacations/job rotations reduce the possibility of collusion between employees 65
Copyright Pearson Prentice-Hall 2009 65

66. Types of Implementation Guidance
Procedures: detailed descriptions of what should be done
Processes: less detailed specifications of what actions should be taken
Necessary in managerial and professional business function
Baselines: checklists of what should be done but not the process or procedures for doing them
Baseline: apply strong password, do not use default password. Different actions based on OS. 66
Copyright Pearson Prentice-Hall 2009 66

67. Types of Implementation Guidance
Best practices: most appropriate actions in other companies
Recommended practices: normative guidance
Accountability
Owner of resource is accountable
Implementing the policy can be delegated to a trustee, but accountability cannot be delegated
Codes of ethics
Best practices: what the best firms are doing about security
Recommended practices: ISO “what companies should do”
Accountability: liability for sanctions if implementation is not done properly. 67
Copyright Pearson Prentice-Hall 2009 67

68. Ethics A person’s system of values Needed in complex situations
Different people may make different decisions in the same situation
Companies create codes of ethics to give guidance in ethical decisions
Code of ethics: states what is expected from an employee
Don’t say we did not warn you.
Provides a clear point of reference when enforcing corrective action
Important if the c.o.e has issues that are not strictly illegal, it cannot be used to fire someone. 68
Copyright Pearson Prentice-Hall 2009 68

69. Code of Ethics: Typical Contents (Partial List)
Importance of good ethics to have a good workplace and to avoid damaging a firm’s reputation
The code of ethics applies to everybody
Senior managers usually have additional requirements
Improper ethics can result in sanctions, up to termination
An employee must report observed ethical behavior 69
Copyright Pearson Prentice-Hall 2009

70. Code of Ethics: Typical Contents (Partial List)
An employee may never divulge
Confidential information
Private information
Trade secrets 70
Copyright Pearson Prentice-Hall 2009

71. Exceptions Are Always Required Limiting Exceptions
But they must be managed
Limiting Exceptions
Only some people should be allowed to request exceptions
Fewer people should be allowed to authorize exceptions
The person who requests an exception must never be authorizer
Must be documented 71
Copyright Pearson Prentice-Hall 2009 71

72. Exception Must be Carefully Documented
Specifically what was done and who did each action
Special Attention Should be Given to Exceptions in Periodic Auditing
Exceptions Above a Particular Danger Level
Should be brought to the attention of the IT security department and the authorizer’s direct manager
Exceptions should be exceptional 72
Copyright Pearson Prentice-Hall 2009 72

73. Oversight Promulgation
Oversight is a term for a group of tools for policy enforcement
Policy drives oversight, just as it drives implementation
Promulgation
Communicate vision
Training
Stinging employees?
Promulgation = Formally announcing, publishing or making users aware of policies. 73
Copyright Pearson Prentice-Hall 2009 73

74. Electronic Monitoring
Electronically-collected information on behavior
Widely done in firms and used to terminate employees
Warn subjects and explain the reasons for monitoring
American Management Assoc survey: 66% of the respondent firms monitor internet connections
Over 50% had fired workers for abuse or network abuse. 74
Copyright Pearson Prentice-Hall 2009 74

75. Security Metrics
Indicators of compliance that are measured periodically
Percentage of passwords on a server that are crackable, etc.
Periodic measurement indicates progress in implementing a policy 75
Copyright Pearson Prentice-Hall 2009

76. Auditing
Samples information to develop an opinion about the adequacy of controls
Database information in log files and prose documentation
Extensive recording is required in most performance regimes
Avoidance of compliance is a particularly important finding
All public companies must have financial audit
Purpose is not to find punishable instances of noncompliance
Must document in order to audit
Was there an active avoidance of compliance? 76
Copyright Pearson Prentice-Hall 2009 76

77. Auditing Internal and external auditing may be done
Periodic auditing gives trends
Unscheduled audits trip up people who plan their actions around periodic audits 77
Copyright Pearson Prentice-Hall 2009

78. Anonymous Protected Hotline
Often, employees are the first to detect a serious problem
A hotline allows them to call it in
Must be anonymous and guarantee protection against reprisals
Offer incentives for heavily damaging activities such as fraud?
Required by SOX
HIPAA requires payment in case information leads to.. 78
Copyright Pearson Prentice-Hall 2009 78

79. Behavioral Awareness
Misbehavior often occurs before serious security breaches
The fraud triangle indicates motive. (see Figure 2- 24)
Why do people commit fraud? Can some symptoms be detected? At least by vulnerability testing we can kill the opportunity.
Pressure typically: unrealistic performance expectations. 79
Copyright Pearson Prentice-Hall 2009 79

80. Vulnerability Tests Attack your own systems to find vulnerabilities
Free and commercial software
Never test without a contract specifying the exact tests, signed by your superior
The contract should hold you blameless in case of damage 80
Copyright Pearson Prentice-Hall 2009

81. Vulnerability Tests
External vulnerability testing firms have expertise and experience
They should have insurance against accidental harm and employee misbehavior
They should not hire hackers or former hackers
Should end with a list of recommended fixes
Follow-up should be done on whether these fixed occurred 81
Copyright Pearson Prentice-Hall 2009

82. Sanctions
If people are not punished when they are caught, nothing else matters
Senior employees seldom face sanctions an Intern of Ohio Department of Admin Serv took home a backup device with a tape. Supervisor had never discussed keeping tapes safe. Device was stolen. Tape had data on state employees, former employees, taxpayers.
Breach cost the state 3M USD. Intern fired, supervisor lost 1 week holiday. 82
Copyright Pearson Prentice-Hall 2009 82

83. 83 Copyright Pearson Prentice-Hall 2009
Recommended guidelines. Many companies use them because people know about them.
SOX requires a company use control framework. 83
Copyright Pearson Prentice-Hall 2009 83

84. Origins
Committee of Sponsoring Organizations of the Treadway Commission (
Ad hoc group to provide guidance on financial controls
Focus
Corporate operations, financial controls, and compliance
Effectively required for Sarbanes–Oxley compliance
Goal is reasonable assurance that goals will be met
“often” used with companies who implement SOX. Origin Has components that work as guidelines.
“Reasonable assurance” = effective control environment = we can assume that goals will be met 84
Copyright Pearson Prentice-Hall 2009 84

85. Components Internal Environment General security culture
Includes “tone at the top”
How risks are viewed and addressed by an entity’s people 85
Copyright Pearson Prentice-Hall 2009

86. Components Risk assessment How risks are analyzed (likelihood, impact)
Ongoing preoccupation
Control activities
Policies and procedures established and implemented to help risk responses are carried out 86
Copyright Pearson Prentice-Hall 2009

87. Components Monitoring
Enterprise risk monitoring: Both human vigilance and technology
Information and communication
Must ensure that the company has the right information for controls
Must ensure communication across all levels in the corporation 87
Copyright Pearson Prentice-Hall 2009

88. CobiT Control Objectives for Information and Related Technologies
CIO-level guidance on IT governance
Offers many documents that help organizations understand how to implement the framework
It Governance Institute 88
Copyright Pearson Prentice-Hall 2009 88

89. The CobiT Framework Four major domains (Figure 2-26) 89
Each box has control objectives to indicate success
Altogether 300 detailed control objectives 89
Copyright Pearson Prentice-Hall 2009 89

90. The CobiT Framework Four major domains (Figure 2-26)
34 high-level control objectives
Planning and organization (11)
Acquisition and implementation (60)
Delivery and support (13)
Monitoring (4)
More than 300 detailed control objectives 90
Copyright Pearson Prentice-Hall 2009

91. Dominance in the United States
Created by the IT governance institute
Which is part of the Information Systems Audit and Control Association (ISACA)
ISACA is the main professional accrediting body of IT auditing
Certified information systems auditor (CISA) certification 91
Copyright Pearson Prentice-Hall 2009

92. ISO/IEC 27000
Family of IT security standards with several individual standards
From the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC)
ISO/IEC 27002
Originally called ISO/IEC 17799
Recommendations in 11 broad areas of security management
Specifically about IT security 92
Copyright Pearson Prentice-Hall 2009 92

93. ISO/IEC 27002: Eleven Broad Areas
Security policy
Access control
Organization of information security
Information systems acquisition, development and maintenance
Asset management
Information security incident management
Human resources security
Business continuity management
Physical and environmental security
Compliance
Communications and operations management 93
Copyright Pearson Prentice-Hall 2009

94. ISO/IEC 27001 Other 27000 Standards
Created in 2005, long after ISO/IEC 27002
Specifies certification by a third party
COSO and CobiT permit only self-certification
Business partners prefer third-party certification
Other Standards
Many more standards documents are under preparation 94
Copyright Pearson Prentice-Hall 2009

95. 95
Copyright Pearson Prentice-Hall 2009