MIS450 1
Information Security and Networking - MIS450
Corporate Computer Security, 4th Edition Randall J. Boyle & Raymond R. Panko
Chapter 2 Planning and Policy
PAGES (80-90) AND (97-136)
• Justify the need for formal management processes.
• Explain the plan–protect–respond security management cycle.
• Describe compliance laws and regulations.
• Describe organizational security issues.
• Describe risk analysis.
• Describe technical security infrastructure.
• Explain policy-driven implementation.
• Know governance frameworks.
Learning Objectives
3
4
• 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 9 focus on protection
• Chapter 10 focuses on response
Orientation
5
What’s Next?
2.1 Introduction & Terminology
2.2 Compliance Laws and Regulations
2.3 Organization
2.4 Risk Analysis
2.5 Technical Security Architecture
2.6 Policy-Driven Implementation
2.7 Governance Frameworks
6
6
• 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)
7
2.1: Management is the Hard Part. P. 82
7
8
2.1: The Need for Comprehensive Security. P. 83
8
9
2.1: Weakest Link Failure
A failure in any component will lead to failure for the entire system
9
• Complex • Cannot be managed informally
• Need Formal Processes • Planned series of actions in security management
• Annual planning
• Processes for planning and developing individual countermeasures
10
2.1: Security Management Is a Disciplined Process.
10
• A Continuous Process • Fail if let up
• Compliance Regulations • Add to the need to adopt disciplined security management
processes
11
2.1: Security Management Is a Disciplined Process
11
12
2.1: The Plan-Protect-Respond Cycle for Security Management. P. 85
Dominates security management thinking
12
• Vision • Your understanding about your role with respect to your company, its
employees, and the outside world drives everything else
13
2.1: Vision. P. 87
13
• Security as an Enabler • Security is often thought of as a preventer
• But security is also an enabler
• A company with good security can do things otherwise impossible • Engage in interorganizational systems with other firms
• Can use SNMP SET commands to manage systems remotely
• Must get in early on projects to reduce inconvenience
14
2.1: Vision
14
• Should Not View Security as Police or Military Force • Creates a negative view of users
• Police merely punish, they do not prevent crime; security must prevent attacks
• Military can use fatal force; security cannot even punish (HR does that)
15
2.1: Vision
15
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
16
2.1: Strategic IT Security Planning. P. 89
16
• Develop Remediation Plans • Develop a remediation plan for all security gaps
• Develop a remediation plan for every resource unless it is well protected
• Develop an Investment Portfolio • You cannot close all gaps immediately
• Choose projects that will provide the largest returns
• Implement these
17
2.1: Strategic IT Security Planning
17
What’s Next?
2.1 Introduction & Terminology
2.2 Compliance Laws and Regulations
2.3 Organization
2.4 Risk Analysis
2.5 Technical Security Architecture
2.6 Policy-Driven Implementation
2.7 Governance Frameworks
18
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
19
2.2: Legal Driving Forces. P. 90
19
What’s Next?
2.1 Introduction & Terminology
2.2 Compliance Laws and Regulations
2.3 Organization
2.4 Risk Analysis
2.5 Technical Security Architecture
2.6 Policy-Driven Implementation
2.7 Governance Frameworks
26
26
• Chief Security Officer (CSO) • 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
27
2.3: Organizational Issues. P. 98
27
• 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
2.3: Organizational Issues
28
• Top Management Support • Budget
• Support in conflicts
• Setting personal examples
29
2.3: Organizational Issues
29
• Relationships with Other Departments • Special relationships
• Ethics, compliance, and privacy officers
• Human resources (training, hiring, terminations, sanction violators)
• Legal department
30
2.3: Organizational Issues
30
• 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
31
2.3: Organizational Issues
31
• 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
32
2.3: Organizational Issues
32
• Outsourcing IT Security • Only e-mail or webservice
• Managed Security Service Providers (MSSPs) • Outsource most IT security functions to the MSSP
• But usually not policy
33
2.3: Organizational Issues
33
34
2.3: E-Mail Outsourcing. P. 102
34
35
2.3: Managed Security Service Provider (MSSP)
35
What’s Next?
2.1 Introduction & Terminology
2.2 Compliance Laws and Regulations
2.3 Organization
2.4 Risk Analysis
2.5 Technical Security Architecture
2.6 Policy-Driven Implementation
2.7 Governance Frameworks
36
36
• Realities • Can never eliminate risk
• “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
37
2.4: Risk Analysis. P. 107
37
2.4: Risk Analysis Single Loss Expectancy (SLE) Annualized Loss Expectancy
(ALE)
• 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
38
39
2.4: Classic Risk Analysis Calculation
Base
Case
Countermeasure
A
Asset Value (AV) $100,000 $100,000
Exposure Factor (EF) 80% 20%
Single Loss Expectancy (SLE): = AV*EF $80,000 $20,000
Annualized Rate of Occurrence (ARO) 50% 50%
Annualized Loss Expectancy (ALE): =
SLE*ARO $40,000 $10,000
ALE Reduction for Countermeasure NA $30,000
Annualized Countermeasure Cost NA $17,000
Annualized Net Countermeasure Value NA $13,000
Countermeasure A should reduce the exposure factor by 75% 39
40
2.4: Classic Risk Analysis Calculation
Base
Case
Countermeasure
B
Asset Value (AV) $100,000 $100,000
Exposure Factor (EF) 80% 80%
Single Loss Expectancy (SLE): = AV*EF $80,000 $80,000
Annualized Rate of Occurrence (ARO) 50% 25%
Annualized Loss Expectancy (ALE): =
SLE*ARO $40,000 $20,000
ALE Reduction for Countermeasure NA $20,000
Annualized Countermeasure Cost NA $4,000
Annualized Net Countermeasure Value NA $16,000
Countermeasure B should cut the frequency of compromises in half 40
41
2.4: Classic Risk Analysis Calculation Base
Case
Countermeasure
A B
Asset Value (AV) $100,000 $100,000 $100,000
Exposure Factor (EF) 80% 20% 80%
Single Loss Expectancy (SLE): = AV*EF $80,000 $20,000 $80,000
Annualized Rate of Occurrence (ARO) 50% 50% 25%
Annualized Loss Expectancy (ALE): =
SLE*ARO $40,000 $10,000 $20,000
ALE Reduction for Countermeasure NA $30,000 $20,000
Annualized Countermeasure Cost NA $17,000 $4,000
Annualized Net Countermeasure Value NA $13,000 $16,000
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.
41
• Uneven Multiyear Cash Flows • For both attack costs and defense costs
• Must compute the return on investment (ROI) using discounted cash flows
• Net present value (NPV) or internal rate of return (ROI)
42
2.4: Problems with Classic Risk Analysis Calculations
42
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
43
2.4: Problems with Classic Risk Analysis Calculations
43
• 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
2.4: Problems with Classic Risk Analysis Calculations
44
• 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 too often merely rate their resources by risk level
45
2.4: Problems with Classic Risk Analysis Calculations
45
• Problems with “Hard-Headed Thinking” • Security benefits are difficult to quantify
• If only support “hard numbers,” may underinvest in security
46
2.4: Problems with Classic Risk Analysis Calculations
46
• 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
47
2.4: Problems with Classic Risk Analysis Calculations
47
• Risk Reduction • 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
48
2.4: Responding to Risk
48
• 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
49
2.4: Responding to Risk
49
• Risk Avoidance • Not to take a risky action
• Lose the benefits of the action
• May cause anger against IT security
• Recap: Four Choices When You Face Risk • Risk reduction
• Risk acceptance
• Risk transference
• Risk avoidance
50
2.4: Responding to Risk
50
What’s Next?
2.1 Introduction & Terminology
2.2 Compliance Laws and Regulations
2.3 Organization
2.4 Risk Analysis
2.5 Technical Security Architecture
2.6 Policy-Driven Implementation
2.7 Governance Frameworks
51
51
• Technical Security Architectures • Definition
• All of a company’s technical countermeasures
• 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
52
2.5: Corporate Technical Security Architecture. P. 115
52
• Technical Security Architectures • Dealing with legacy technologies
• Legacy technologies are technologies put in place previously
• Too expensive to upgrade all legacy technologies immediately
• Must upgrade if seriously impairs security
• Upgrades must justify their costs
53
2.5: Corporate Technical Security Architecture
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
54
2.5: Corporate Technical Security Architecture
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
55
2.5: Corporate Technical Security Architecture
55
• Principles • Avoiding single points of vulnerability
• Failure at a single point can have drastic consequences
• DNS servers, central security management servers, etc.
56
2.5: Corporate Technical Security Architecture
56
• Principles • Minimizing security burdens
• Realistic goals • Cannot change a company’s protection level overnight
• Mature as quickly as possible
57
2.5: Corporate Technical Security Architecture
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
58
2.5: Corporate Technical Security Architecture
58
What’s Next?
2.1 Introduction & Terminology
2.2 Compliance Laws and Regulations
2.3 Organization
2.4 Risk Analysis
2.5 Technical Security Architecture
2.6 Policy-Driven Implementation
2.7 Governance Frameworks
59
59
• Policies • Statements of what is to be done
• Provide clarity and direction
• Does not specify in detail how the policy is to be implemented in specific circumstances
• Allows the best possible implementation at any time
• Vary widely in length
60
2.6: Policies. P. 119
60
• Tiers of Security Policies • Brief corporate security policy to drive everything
• Major policies • E-mail
• Hiring and firing
• Personally identifiable information
• …
61
2.6: Policies
61
• 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
62
2.6: Policies
62
• 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
63
2.6: Policies
63
Implementation Guidance ◦ Limits the discretion of implementers in order to simplify
implementation decisions and avoid bad choices in interpreting policies
None ◦ Implementer is only guided by the policy itself
Standards versus Guidelines ◦ Standards are mandatory directives
◦ Guidelines are not mandatory but must be considered
64
2.6: Implementation Guidance
64
• 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
65
2.6: Ethics. P. 128
65
• Code of Ethics: Typical Contents (Partial List) • Important for having a good workplace and to avoid damaging a firm’s
reputation
• Applies to everybody • Senior managers usually have additional requirements
• Improper ethics can result in sanctions, up to and including termination
• An employee must report observed unethical behavior
66
2.6: Ethics
66
• Code of Ethics: Typical Contents (Partial List) • An employee must involve conflicts of interest
• Never exploit one’s position for personal gain
• No preferential treatment of relatives
• No investing in competitors
• No competing with the company while still employed by the firm
67
2.6: Ethics
67
• Code of Ethics: Typical Contents (Partial List) • No bribes or kickbacks
• Bribes are given by outside parties to get preferential treatment
• Kickbacks are given by sellers when they place an order to secure this or future orders
• Employees must use business assets for business uses only, not personal use
68
2.6: Ethics
68
• Code of Ethics: Typical Contents (Partial List) • An employee may never divulge
• Confidential information
• Private information
• Trade secrets
69
2.6: Ethics
69
• Exceptions Are Always Required • 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
70
2.6: Exception Handling
70
• 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
71
2.6: Exception Handling
71
• Oversight • Oversight is a group of tools for policy enforcement
• Policy drives oversight, just as it drives implementation
• Promulgation • Communicate vision
• Training
• Stinging employees?
72
2.6: Oversight
72
• Electronic Monitoring • Electronically-collected information on behavior
• Widely done in firms and used to terminate employees
• Warn subjects and explain the reasons for monitoring
73
2.6: Oversight
73
• 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
74
2.6: Oversight
74
• 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
75
2.6: Oversight
75
• 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
76
2.6: Oversight
76
• Sanctions • If people are not punished when they are caught, nothing else matters
77
2.6: Oversight
77
The End
78