Here are a couple of stabs at reorganization. This isn't a complete
re-do but just an idea to show my thinking.
While I'm really, really not trying to do a comprehensive model, I do
think it's worth keeping three things in mind:
1. Risk[1]/Threat: An impact on the SP if the exploit takes place.
It is assessed with respect to a revenue source or cost seen by
upper management, such as bandwidth, network element (e.g.,
router)
availability, and host denial of service. By [1], I mean the
expected
financial cost multiplied by the probability of the event.
I recognize that host denial of service is right at the edge of
the
charter, but I think we need to include things that prevent the
host
being used through the ISP network, such as a SYN-Flood.
2. Exploit: a class of technical attack
3. Security mechanisms: a class of measures, including hardware,
software
and procedures/personnel time, to detect and/or mitigate
exploits.
Table of Contents
1. Introduction
2. Problem Statement
3. Risls/Threats
3.1 Denial of access to network elements
3.2 Denial of access to bandwidth
This can be total or degraded
3.3 Denial of access to hosted servers
Again, can be total or degradation
4. Exploits
5. Security Mechanisms
5.1 Device Access Security (network element? Application
server?)
I'm not completely happy with this heading, as it's closer
to
a resource under risk than a service. Perhaps the best
example
in terms of risk is attacking the mechanism by which
legitimate
users gain access to resources. It could also include
theft of
service by unauthorized users.
5.1.1 Examples of exploits in the classes below.
5.1.1.1 Logical access
5.1.1.2 Console Access
5.1.1.3 HTTP
5.1.1.4 SNMP
5.1.2 Security Mechanisms applicable to the above exploits.
May also be usable against other exploits.
5.1.3 Security mechanisms
5.1.3.1 Authenticated access
5.1.3.2 Encrypted sessions
5.1.3.3 Usage logging
5.2 Bandwidth
Can include provider infrastructure or customer links
5.2.1 Examples of exploits
5.2.1.1 IP flooding
5.2.1.2 L2 broadcast storms
5.3 Routing control plane
5.4 Routing forwarding plane
5.5 Host processing (may be out of scope, or be included under
such things as 5.1 SYN-flood)
-----------------------------------
I haven't characterized the mechanisms under this line as specific to
a particular resource. They could appear under several resources. In
general, however, the items below need to be categorized into threats
and security mechanisms for the resources in jeopardy.
-----------------------------------
5. Filtering
5.1 Threat Description
5.2 Best Current Practice
5.2.1 General Inbound Traffic Filters
5.2.2 General Outbound Traffic Filters
5.2.3 Device Access Filters
5.2.4 Route Filters
5.2.5 MAC Address Filters
5.2.6 DoS Mitigation Filtering
5.2.7 SinkHole / Blackhole
5.2.8 uRPF
6. Logging (accounting)
6.1 Threat Description
6.2 Best Current Practice
6.2.1 What traffic is logged
6.2.2 What fields are logged
6.2.3 How long are logs kept
6.2.4 Local buffer vs syslog (for backup info)
6.2.5 Authentication from peer to peer of log files?
6.2.6 Integrity check of log files?
6.2.7 NTP source considerations
7. Device Integrity
7.1 Threat Description
7.2 Best Current Practice
7.2.1 Device Image Upgrade
7.2.2 Device Configuration
7.2.3 Management/Logging Information
8. Specific Protocol/Service Concerns
8.1 Threat Description
8.2 Best Current Practice
8.2.1 ICMP
8.2.2 Generally Unused Services
9. Policy/Procedural Considerations
9.1 Threat Description
9.2 Best Current Practice
9.2.1 Equipment Software Update
9.2.2 Equipment Configuration Change
--
Howard C. Berkowitz
5012 25th Street South
Arlington VA 22206
(703)998-5819 voice
(703)998-5058 fax (alas, sometimes poorly operated by "helpful" cat)