1
Copyright © 2012, Elsevier Inc.
All Rights Reserved
Chapter 3
Separation
Cyber Attacks Protecting National Infrastructure, 1st ed.
2
• Using a firewall to separate network assets from intruders is the most familiar approach in cyber security
• Networks and systems associated with national infrastructure assets tend to be too complex for firewalls to be effective
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
Introduction
3
• Three new approaches to the use of firewalls are necessary to achieve optimal separation – Network-based separation
– Internal separation
– Tailored separation
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
Introduction
4
Fig. 3.1 – Firewalls in simple and complex networks
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
5
• Separation is a technique that accomplishes one of the following – Adversary separation
– Component distribution
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
What Is Separation?
6
• A working taxonomy of separation techniques: Three primary factors involved in the use of separation – The source of the threat
– The target of the security control
– The approach used in the security control
(See figure 3.2)
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
What Is Separation?
7
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
Fig. 3.2 – Taxonomy of separation techniques
8
• Separation is commonly achieved using an access control mechanism with requisite authentication and identity management
• An access policy identifies desired allowances for users requesting to perform actions on system entities
• Two approaches – Distributed responsibility
– Centralized control
– (Both will be required)
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
Functional Separation?
9
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
Fig. 3.3 – Distributed versus centralized mediation
10
• Firewalls are placed between a system or enterprise and an un-trusted network (say, the Internet)
• Two possibilities arise – Coverage: The firewall might not cover all paths
– Accuracy: The firewall may be forced to allow access that inadvertently opens access to other protected assets
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
National Infrastructure Firewalls
11
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
Fig. 3.4 – Wide area firewall aggregation and local area firewall
segregation
12
• Increased wireless connectivity is a major challenge to national infrastructure security
• Network service providers offer advantages to centralized security – Vantage point: Network service providers can see a lot
– Operations: Network providers have operational capacity to keep security software current
– Investment: Network service providers have the financial wherewithal and motivation to invest in security
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
National Infrastructure Firewalls
13
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
Fig. 3.5 – Carrier-centric network-based firewall
14
• Network-based firewall concept includes device for throttling distributed denial of service (DDOS) attacks
• Called a DDOS filter
• Modern DDOS attacks take into account a more advanced filtering system
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
DDOS Filtering
15
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
Fig. 3.6 – DDOS filtering of inbound attacks on target assets
16
• SCADA – Supervisory control and data acquisition
• SCADA systems – A set of software, computer, and networks that provide remote coordination of control system for tangible infrastructures
• Structure includes the following – Human-machine interface (HMI)
– Master terminal unit (MTU)
– Remote terminal unit (RTU)
– Field control systems
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
SCADA Separation Architecture
17
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
Fig. 3.7 – Recommended SCADA system firewall architecture
18
• Why not simply unplug a system’s external connections? (Called air gapping)
• As systems and networks grow more complex, it becomes more likely that unknown or unauthorized external connections will arise
• Basic principles for truly air-gapped networks: – Clear policy
– Boundary scanning
– Violation consequences
– Reasonable alternatives
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
Physical Separation
19
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
Fig. 3.8 – Bridging an isolated network via a dual-homing user
20
• Hard to defend against a determined insider
• Threats may also come from trusted partners
• Background checks are a start
• Techniques for countering insider attack – Internal firewalls
– Deceptive honey pots
– Enforcement of data markings
– Data leakage protection (DLP) systems
• Segregation of duties offers another layer of protection
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
Insider Separation
21
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
Fig. 3.9 – Decomposing work functions for segregation of duty
22
• Involves the distribution, replication, decomposition, or segregation of national assets – Distribution: creating functionality using multiple
cooperating components that work together as distributed system
– Replication: copying assets across components so if one asset is broken, the copy will be available
– Decomposition: breaking complex assets into individual components so an isolated compromise won’t bring down asset
– Segregation: separation of assets through special access controls, data markings, and policy enforcement
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
Asset Separation
23
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
Fig. 3.10 – Reducing DDOS risk through CDN-hosted content
24
• Typically, mandatory access controls and audit trail hooks were embedded into the underlying operating system kernel
• Popular in the 1980s and 1990s
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
Multilevel Security (MLS)
25
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
Fig. 3.11 – Using MLS logical separation to protect assets
26
• Internet separation: Certain assets simply shouldn’t be accessible from the Internet
• Network-based firewalls: These should be managed by a centralized group
• DDOS protection: All assets should have protection in place before an attack
• Internal separation: Critical national infrastructure settings need an incentive to implement internal separation policy
• Tailoring requirements: Vendors should be incentivized to build tailored systems such as firewalls for special SCADA environments
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 3 –
S e p a ra
tio n
National Separation Program
1
Copyright © 2012, Elsevier Inc.
All Rights Reserved
Chapter 6
Depth
Cyber Attacks Protecting National Infrastructure, 1st ed.
2
• Any layer of defense can fail at any time, thus the introduction of defense in depth
• A series of protective elements is placed between an asset and the adversary
• The intent is to enforce policy across all access points
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
Introduction
3
Fig. 6.1 – General defense in depth schema
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
4
• Quantifying the effectiveness of a layered defense is often difficult
• Effectiveness is best determined by educated guesses
• The following are relevant for estimating effectiveness – Practical experience
– Engineering analysis
– Use-case studies
– Testing and simulation
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
Effectiveness of Depth
5
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
Fig. 6.2 – Moderately effective single layer of protection
6
• When a layer fails, we can conclude it was either flawed or unsuited to the target environment
• No layer is 100% effective—the goal of making layers “highly” effective is more realistic
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
Effectiveness of Depth
7
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
Fig. 6.3 – Highly effective single layer of protection
8
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
Fig. 6.4 – Multiple moderately effective layers of protection
9
• A national authentication system for every citizen would remove the need for multiple passwords, passphrases, tokens, certificates, and biometrics that weaken security
• Single sign-on (SSO) would accomplish this authentication simplification objective
• However, SSO access needs to be part of a multilayered defense
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
Layered Authentication
10
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
Fig. 6.5 – Schema showing two layers of end-user authentication
11
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
Fig. 6.6 – Authentication options including direct mobile access
12
Layered E-Mail Virus and Spam Protection
• Commercial environments are turning to virtual, in- the-cloud solutions to filter e-mail viruses and spam
• To that security layer is added filtering software on individual computers
• Antivirus software helpful, but useless against certain attacks (like botnet)
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
13
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
Fig. 6.7 – Typical architecture with layered e-mail filtering
14
• Layering access controls increases security
• Add to this the limiting of physical access to assets
• For national infrastructure, assets should be covered by as many layers possible – Network-based firewalls
– Internal firewalls
– Physical security
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
Layered Access Controls
15
Fig. 6.8 – Three layers of protection using firewall and access controls
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
16
• Five encryption methods for national infrastructure protection – Mobile device storage
– Network transmission
– Secure commerce
– Application strengthening
– Server and mainframe data storage
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
Layered Encryption
17
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
Fig. 6.9 – Multple layers of encryption
18
• The promise of layered intrusion detection has not been fully realized, though it is useful
• The inclusion of intrusion response makes the layered approach more complex
• There are three opportunities for different intrusion detection systems to provide layered protection – In-band detection
– Out-of-band correlation
– Signature sharing
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
Layered Intrusion Detection
19
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
Fig. 6.10 – Sharing intrusion detection information between systems
20
• Developing a multilayered defense for national infrastructure would require a careful architectural analysis of all assets and protection systems – Identifying assets
– Subjective estimations
– Obtaining proprietary information
– Identifying all possible access paths
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 6 –
D e p th
National Program of Depth
1
Copyright © 2012, Elsevier Inc.
All Rights Reserved
Chapter 2
Deception
Cyber Attacks Protecting National Infrastructure, 1st ed.
2
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Introduction
• Deception is deliberately misleading an adversary by creating a system component that looks real but is in reality a trap – Sometimes called a honey pot
• Deception helps accomplish the following security objectives – Attention
– Energy
– Uncertainty
– Analysis
3
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
• If adversaries are aware that perceived vulnerabilities may, in fact, be a trap, deception may defuse actual vulnerabilities that security mangers know nothing about.
Introduction
4
Fig. 2.1 – Use of deception in computing
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
5
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Introduction
• Four distinct attack stages: – Scanning
– Discovery
– Exploitation
– Exposing
6
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Fig. 2.2 – Stages of deception for national infrastructure protection
7
• Adversary is scanning for exploitation points – May include both online and offline scanning
• Deceptive design goal: Design an interface with the following components – Authorized services
– Real vulnerabilities
– Bogus vulnerabilities
• Data can be collected in real-time when adversary attacks honey pot
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Scanning Stage
8
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Fig. 2.3 – National asset service interface with deception
9
• Deliberately inserting an open service port on an Internet-facing server is the most straightforward deceptive computing practice
• Adversaries face three views
– Valid open ports
– Inadvertently open ports
– Deliberately open ports connected to honey pots
• Must take care the real assets aren’t put at risk by bogus ports
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Deliberately Open Ports
10
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Fig. 2.4 – Use of deceptive bogus ports to bogus assets
11
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Fig. 2.5 – Embedding a honey pot server into a normal server complex
12
• The discovery stage is when an adversary finds and accepts security bait embedded in the trap
• Make adversary believe real assets are bogus – Sponsored research
– Published case studies
– Open solicitations
• Make adversary believe bogus assets are real – Technique of duplication is often used for honey pot
design
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Discovery Stage
13
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Fig. 2.6 – Duplication in honey pot design
14
• Creation and special placement of deceptive documents can be used to trick an adversary (Especially useful for detecting a malicious insider) – Only works when content is convincing and
– Protections appear real
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Deceptive Documents
15
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Fig. 2.7 – Planting a bogus document in protected enclaves
16
• This stage is when an adversary exploits a discovered vulnerability – Early activity called low radar actions
– When detected called indications and warnings
• Key requirement: Any exploitation of a bogus asset must not cause disclosure, integrity, theft, or availability problems with any real asset
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Exploitation Stage
17
C h a p te
r 2 –
D e c e p tio
n
Fig. 2.8 – Pre- and post-attack stages at the exploitation stage
Copyright © 2012, Elsevier Inc.
All rights Reserved
18
• Related issue: Intrusion detection and incident response teams might be fooled into believing trap functionality is real. False alarms can be avoided by – Process coordination
– Trap isolation
– Back-end insiders
– Process allowance
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Exploitation Stage
19
• Understand adversary behavior by comparing it in different environments.
• The procurement lifecycle is one of the most underestimated components in national infrastructure protection (from an attack perspective)
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Procurement Tricks
20
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Fig. 2.9 – Using deception against malicious suppliers
21
• The deception lifecycle ends with the adversary exposing behavior to the deception operator
• Therefore, deception must allow a window for observing that behavior – Sufficient detail
– Hidden probes
– Real-time observation
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Exposing Stage
22
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Fig. 2.10 – Adversary exposing stage during deception
23
Interfaces Between Humans and Computers
• Gathering of forensic evidence relies on understanding how systems, protocols, and services interact – Human-to-human
– Human-to-computer
– Computer-to-human
– Computer-to-computer
• Real-time forensic analysis not possible for every scenario
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
24
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
Fig. 2.11 – Deceptively exploiting the human-to-human interface
25
• Programs for national deception would be better designed based on the following assumptions: – Selective infrastructure use
– Sharing of results and insights
– Reuse of tools and methods
• An objection to deception that remains is that it is not effective against botnet attacks – Though a tarpit might degrade the effectiveness of a
botnet
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 2 –
D e c e p tio
n
National Deception Program
1
Copyright © 2012, Elsevier Inc.
All Rights Reserved
Chapter 8
Collection
Cyber Attacks Protecting National Infrastructure, 1st ed.
2
• Diligent and ongoing observation of computing and networking behavior can highlight malicious activity – The processing and analysis required for this must be done
within a program of data collection
• A national collection process that combines local, regional, and aggregated data does not exist in an organized manner
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
Introduction
3
Fig. 8.1 – Local, regional, and national data collection with aggregation
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
4
• At local and national levels data collection decisions for national infrastructure should be based on the following security goals – Preventing an attack
– Mitigating an attack
– Analyzing an attack
• Data collection must be justified (who is collecting and why)
• The quality of data is more important than the quantity
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
Introduction
5
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
Fig. 8.2 – Justification-based decision analysis template for data collection
6
• Metadata is perhaps the most useful type of data for collection in national infrastructure – Metadata is information about data, not what the data is
about
• Data collection systems need to keep pace with growth of carrier backbones
• Sampling data takes less time, but unsampled data may be reveal more
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
Collecting Network Data
7
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
Fig. 8.3 – Generic data collection schematic
8
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
Fig. 8.4 – Collection detects evidence of vulnerability in advance of notification
9
• National initiatives have not traditionally collected data from mainframes, servers, and PCs
• The ultimate goal should be to collect data from all relevant computers, even if that goal is beyond current capacity
• System monitoring may reveal troubling patterns
• Two techniques useful for embedding system management data – Inventory process needed to identify critical systems
– Process of instrumenting or reusing data collection facilities must be identified
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
Collecting System Data
10
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
Fig. 8.5 – Collecting data from mainframes, servers, and PCs
11
Security Information and Event Management
• Security information and event management (SIEM) is the process of aggregating system data from multiple sources for purpose of protection
• Each SIEM system (in a national system of data collection) would collect, filter, and process data
• Objections to this approach include both the cost of setting up the architecture and the fact that embedded SIEM functionality might introduce problems locally
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
12
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
Fig. 8.6 – Generic SIEM architecture
13
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
Fig. 8.7 – Generic national SIEM architecture
14
• Identifying trends is the most fundamental processing technique for data collected across the infrastructure
• Simplest terms – Some quantities go up (growth)
– Some quantities go down (reduction)
– Some quantities stay the same (leveling)
– Some quantities doing none of the above (unpredictability)
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
Large-Scale Trending
15
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
Fig. 8.8 – Growth trend in botnet behavior over 9-month period (2006–
2007)
16
• Some basic practical considerations that must be made by security analysts before a trend can be trusted – Underlying collection
– Volunteered data
– Relevant coverage
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
Large-Scale Trending
17
• Collecting network metadata allows security analysts track a worm’s progress and predict its course
• Consensus holds that worms work too fast for data collection to be an effective defense – There’s actually some evidence that a closer look at the
data might provide early warning of worm threats
• After collecting and analyzing, the next step is acting on the data in a timely manner
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
Tracking a Worm
18
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
Fig. 8.9 – Coarse view of UDP traffic spike from SQL/Slammer worm
(Figure courtesy of Dave Gross and Brian Rexroad)
19
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
Fig. 8.10 – Fine view of UDP traffic spike from SQL/Slammer worm (Figure courtesy of Dave Gross and Brian Rexroad)
20
• Once the idea for a national data collection program is accepted, the following need to be addressed – Data sources
– Protected transit
– Storage considerations
– Data reduction emphasis
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 8 –
C o lle
c tio
n
National Collection Program
1
Copyright © 2012, Elsevier Inc.
All Rights Reserved
Chapter 5
Commonality
Cyber Attacks Protecting National Infrastructure, 1st ed.
2
• Certain security attributes must be present in all aspects and areas of national infrastructure to ensure maximum resilience against attack
• Best practices, standards, and audits establish a low- water mark for all relevant organizations
• Audits must be both meaningful and measurable – Often the most measurable things aren’t all that
meaningful
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Introduction
3
• Common security-related best practices/standards – Federal Information Security Management Act (FISMA)
– Health Insurance Portability and Accountability Act (HIPAA)
– Payment Card Industry Data Security Standard (PCI DSS)
– ETSI Cyber Security Technical Committee (TC-CYBER)
– ISO/IEC 27000 Standard family (ISO27K) • ISO 27001 – Security management systems
• ISO 27002 – Code of practice for InfoSec controls
– COBIT - Control Objectives for Information and related Technology
– NIST Cybersecurity Framework
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Introduction
4
Fig. 5.1 – Illustrative security audits for two organizations
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
5
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Fig. 5.2 – Relationship between meaningful and measurable
requirements
6
• The primary motivation for proper infrastructure protection should be success based and economic – Not the audit score
• Security of critical components relies on – Step #1: Standard audit
– Step #2: World-class focus
• Sometimes security audit standards and best practices proven through experience are in conflict
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Meaningful Best Practices for Infrastructure Protection
7
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Fig. 5.3 – Methodology to achieve world-class infrastructure
protection practices
8
• Four basic security policy considerations are recommended – Enforceable: Policies without enforcement are not
valuable
– Small: Keep it simple and current
– Online: Policy info needs to be online and searchable
– Inclusive: Good policy requires analysis in order to include computing and networking elements in the local nat’l infrastructure environment
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Locally Relevant and Appropriate Security Policy
9
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Fig. 5.4 – Decision process for security policy analysis
10
• Create an organizational culture of security protection
• Culture of security is one where standard operating procedures provide a secure environment
• Ideal environment marries creativity and interest in new technologies with caution and a healthy aversion to risk
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Culture of Security Protection
11
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Fig. 5.5 – Spectrum of organizational culture of security options
12
• Organizations should be explicitly committed to infrastructure simplification
• Common problems found in design and operation of national infrastructure – Lack of generalization
– Clouding the obvious
– Stream-of-consciousness design
– Nonuniformity
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Infrastructure Simplification
13
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Fig. 5.6 – Sample cluttered engineering chart
14
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Fig. 5.7 – Simplified engineering chart
15
• How to simplify a national infrastructure environment – Reduce its size
– Generalize concepts
– Clean interfaces
– Highlight patterns
– Reduce clutter
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Infrastructure Simplification
16
• Key decision-makers need certification and education programs
• Hundred percent end-user awareness is impractical; instead focus on improving security competence of decision-makers – Senior Managers
– Designers and developers
– Administrators
– Security team members
• Create low-cost, high-return activities to certify and educate end users
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Certification and Education
17
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Fig. 5.8 – Return on investment (ROI) trends for security education
18
• Create and establish career paths and reward structures for security professionals
• These elements should be present in national infrastructure environments – Attractive salaries
– Career paths
– Senior managers
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Career Path and Reward Structure
19
• Companies and agencies being considered for national infrastructure work should be required to demonstrate past practice in live security incidents
• Companies and agencies must do a better job of managing their inventory of live incidents
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Responsible Past Security Practice
20
• Companies and agencies being considered for national infrastructure work should provide evidence of the following past practices – Past damage
– Past prevention
– Past response
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
Responsible Past Security Practice
21
• A national commonality plan involves balancing the following concerns – Plethora of existing standards
– Low-water mark versus world class
– Existing commissions and boards
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 5 –
C o m
m o n a lity
National Commonality Program
1
Copyright © 2012, Elsevier Inc.
All Rights Reserved
Chapter 4
Diversity
Cyber Attacks Protecting National Infrastructure, 1st ed.
2
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 4 –
D iv
e rs
ity
Introduction
• The securing any set of national assets should include a diversity strategy
• The deliberate introduction of diversity into national infrastructure to increase security has not been well explored
• Two system are considered diverse if their key attributes differ
• Diversity bucks the trend to standardize assets for efficiency's sake
3
Fig. 4.1 – Diverse and nondiverse components through attribute
differences
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 4 –
D iv
e rs
ity
4
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 4 –
D iv
e rs
ity
Diversity and Worm Propagation
• Worm propagation is an example of an attack that relies on a nondiverse target environment
• Worm functionality in three steps: – Step #1: Find a target system on the network for
propagation of worm program
– Step #2: Copy program to that system
– Step #3: Remotely execute program
– Repeat
• Diversity may be expensive to introduce, but saves money on response costs in the long run
5
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 4 –
D iv
e rs
ity
Fig. 4.2 – Mitigating worm activity through diversity
6
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 4 –
D iv
e rs
ity
Desktop Computer System Diversity
• Most individual computers run the same operating system software on a standard processor platform and browse the Internet through one or two popular search engines with the one of only a couple browsers
• The typical configuration is a PC running Windows on an Intel platform, browsing the Internet with Internet Explorer, searching with Google
• This makes the average home PC user a highly predictable target
7
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 4 –
D iv
e rs
ity
Fig. 4.3 – Typical PC configuration showing diversity
8
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 4 –
D iv
e rs
ity
Desktop Computer System Diversity
• Three Considerations – Platform costs
– Application interoperability
– Support and training
9
• Ultimate solution for making desktops more secure involves their removal – Not a practical solution
• Cloud computing may offer home PC users a diverse, protected environment
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 4 –
D iv
e rs
ity
Diversity Paradox of Cloud Computing
10
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 4 –
D iv
e rs
ity
Fig. 4.4 – Spectrum of desktop diversity options
11
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 4 –
D iv
e rs
ity
Fig. 4.5 – Diversity and attack difficulty with option of removal
12
• Modern telecommunications consist of the following two types of technologies – Circuit-switched
– Packet-switched
• When compared to one another, these two technologies automatically provide diversity
• Diversity may not always be a feasible goal – Maximizing diversity may defend against large-scale
attacks, but one must also look closely at the entire architecture
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 4 –
D iv
e rs
ity
Network Technology Diversity
13
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 4 –
D iv
e rs
ity
Fig. 4.6 – Worm nonpropagation benefit from diverse telecommunications
14
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 4 –
D iv
e rs
ity
Fig. 4.7 – Potential for impact propagation over shared fiber
15
• Any essential computing or networking asset that serves a critical function must include physical distribution to increase survivability
• Physical diversity has been part of the national asset system for years – Backup center diversity
– Supplier/vendor diversity
– Network route diversity
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 4 –
D iv
e rs
ity
Physical Diversity
16
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 4 –
D iv
e rs
ity
Fig. 4.8 – Diverse hubs in satellite SCADA configurations
17
• A national diversity program would coordinate between companies and government agencies – Critical path analysis
– Cascade modeling
– Procurement discipline
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 4 –
D iv
e rs
ity
National Diversity Program
1
Copyright © 2012, Elsevier Inc.
All Rights Reserved
Chapter 7
Discretion
Cyber Attacks Protecting National Infrastructure, 1st ed.
2
• Proprietary information will be exposed if discovered by hackers
• National infrastructure protection initiatives most prevent leaks – Best approach: Avoid vulnerabilities in the first place
– More practically: Include a customized program focused mainly on the most critical information
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
Introduction
3
• A trusted computing base (TCB) is the totality of hardware, software, processes, and individuals considered essential to system security
• A national infrastructure security protection program will include – Mandatory controls
– Discretionary policy
• A smaller, less complext TCB is easier to protect
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
Trusted Computing Base
4
Fig. 7.1 – Size comparison issues in a trusted computing base
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
5
• Managing discretion is critical; questions about the following should be asked when information is being considered for disclosure – Assistance
– Fixes
– Limits
– Legality
– Damage
– Need
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
Trusted Computing Base
6
• Security through obscurity is often maligned and misunderstood by security experts – Long-term hiding of vulnerabilities
– Long-term suppression of information
• Security through obscurity is not recommended for long-term protection, but it is an excellent complementary control – E.g., there’s no need to publish a system’s architecture
– E.g., revealing a flaw before it’s fixed can lead to rushed work and an unnecessary complication of the situation
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
Security Through Obscurity
7
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
Fig. 7.2 – Knowledge lifecycle for security through obscurity
8
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
Fig. 7.3 – Vulnerability disclosure lifecycle
9
• Information sharing may be inadvertent, secretive, or willful
• Government most aggressive promoting information sharing
• Government requests information from industry for the following reasons – Government assistance to industry
– Government situational awareness
– Politics
• Government and industry have conflicting motivations
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
Information Sharing
10
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
Fig. 7.4 – Inverse value of information sharing for government and industry
11
• Adversaries regularly scout ahead and plan before an attack
• Reconnaissance planning levels – Level #1: Broad, wide-reaching collection from a variety of
sources
– Level #2: Targeted collection, often involving automation
– Level #3: Directly accessing the target
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
Information Reconnaissance
12
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
Fig. 7.5 – Three stages of reconnaissance for cyber security
13
• At each stage of reconnaissance, security engineers can introduce information obscurity
• The specific types of information that should be obscured are – Attributes
– Protections
– Vulnerabilities
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
Information Reconnaissance
14
• Layering methods of obscurity and discretion adds depth to defensive security program
• Even with layered obscurity, asset information can find a way out – Public speaking
– Approved external site
– Search for leakage
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
Obscurity Layers
15
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
Fig. 7.6 – Obscurity layers to protect asset information
16
• Governments have been successful at protecting information by compartmentalizing information and individuals – Information is classified
– Groups of individuals are granted clearance
• Compartmentalization defines boundaries, which helps guides decisions
• Private companies can benefit from this model
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
Organizational Compartments
17
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
Fig. 7.7 – Using clearances and classifications to control information
disclosure
18
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
Fig. 7.8 – Example commercial mapping of clearances and classifications
19
• To implement a national discretion program will require – TCB definition
– Reduced emphasis on information sharing
– Coexistence with hacking community
– Obscurity layered model
– Commercial information protection models
Copyright © 2012, Elsevier Inc.
All rights Reserved
C h a p te
r 7 –
D is
c re
tio n
National Discretion Program

Get help from top-rated tutors in any subject.
Efficiently complete your homework and academic assignments by getting help from the experts at homeworkarchive.com