Security David D. Clark July, 2012. 2 Aspects of security Attacks on the network Routing, supply...

Security

David D. Clark

July, 2012

2

Aspects of security Attacks on the network

Routing, supply chain Attacks on communication

Confidentiality and integrity addressed with encryption. Availability?? The central objective of networks. What else? (Traffic analysis…)

Attacks on the host Infiltration (can lead to most anything) So either prevent infiltration or limit its consequences.

Denial of service A special case of availability.

Information assurance. Sign the information, not the connection.

National security

Attacks on the network itself

Today, routing is most obvious example. Get back to DNS later…

Regions issuing rogue routing assertions. E.g. Pakistan and false routes to Youtube.

Seems like a technical problem with a technical solution. All routing assertions should be signed. NOT a technical problem—no root of trust.

International tiff…

3

4

Some attacks on communication Deep packet inspection

Should we call this an “attack”? Re-writing of parts of content.

Changing embedded URLs in web pages. Byzantine packet handling.

Re-routing, adding and dropping. Man in the middle attacks.

DNS corruption (pharming) No architectural support today to mitigate this.

Design is redundant, but not in face of malice.

A simple approach Deal with confidentiality and integrity (spying and

changing) by using end-to-end encryption. Raises a number of subsidiary issues, but a good place to start.

The classic taxonomy misses a major issue. Talking to actors you don’t trust.

The norm today—email, web sites, etc. Encrypted communication with an actor you don’t trust is like

meeting a stranger in a dark alley. No witnesses.

What does that leave? Availability. What else? If “all” a network does is deliver packets, then availability is the

crux of the requirement. Why do we lack a theory of availability?

6

Availability First, as much as possible, make attacks on network and

communication into failures of availability. Limit the range of attacks and responses.

Think: what is excluded…? Mechanism: wrap an end-to-end confirmation of identity around

a connection. Cleanly makes many attacks on/by the network into an availability

problem. Second, develop a theory of availability.

At a high level: All critical resources must be supported in a rich, heterogeneous,

diverse form. It must be possible to detect and distinguish (to some degree)

failures. The point of detection must be able to invoke different resources.

In general, only the end-points can detect failures.

7

End-to-end checks To turn misdirection attacks into “availability problems”,

need a means to confirm with whom you are communicating. An issue of identity and shared information.

What notion(s) of identity will be suitable? (See below.) “You” means the end-nodes, but not just the human. If

the end-node can be trusted, software can help. Corrupted end-nodes are a central issue here. Can a trusted helper node help?

To detect Byzantine attacks, fault detection must be integrated into the carriage of data. Security and management are entangled.

Security mechanisms

Security mechanisms do not ensure correct successful operation. DNSSEC SSL/TLS IPsec SBGP and its kin Self-signed identifiers (public key hashes, etc)

They only give a clean indication of failure. What we wanted was success. Successful operation depends on the ability to select

and use trustworthy components.

Traffic analysis

Recording addresses, not content. Who talks to whom?

Incredibly powerful tool for intelligence gathering. Hardly need “wiretap”, which is the term for getting

the content. Encryption does not help.

This is “security” vs. “national security”. Counter-measure: encapsulate to hide address.

Example of encapsulation

Onion routing (TOR). See www.torproject.org.

Pick a sequence of presumably trustworthy TOR nodes from around the globe. In turn, encrypt your packet (addresses and all) using

the public key of each node. Each node peels off its layer of encryption (like

peeling an onion—get it?) and forwards it. Who uses TOR today?

Bad guys. Dissidents. Spies.

11

Protecting the end-node Node security

Classic end-nodes will always be insecure, but we can build fixed-function nodes that are pretty good. Can we build secure virtual machines?

What parts do we have to work with? Applications define the range of patterns of communication that

can be utilized, and what can be seen/modified in the communication.

Elements in the network can examine what is revealed. End-node controls the initiation of connections and what is

sent. Encryption blunts the power of examination/modification.

Network controls topology and completion of connections. A tussle over availability. Can enforce communication patterns.

12

The design challenge What trusted components, combined with

application modes that exploit them, can protect untrustworthy end-nodes from attack (in particular infiltration, sabotage and exfiltration)? The network can enforce the needed patterns of

communication. For example, OpenFlow.

Network elements can examine what the application chooses to reveal. Trusted and untrusted…

Application design patterns and building blocks should be part of the future network.

13

Prevent infiltration Require identity as part of session initiation.

Use agent to validate incoming service requests. “Firewall of the future”

Allow end-node (or trusted helper) to open ports dynamically. Eliminate well-known ports.

Make port scans less effective. Inspect incoming data for “bad stuff”.

Represents a loss of privacy, so use selectively. Host-centric actions.

Virtual machines for risky actions. Outsource risky apps to different machine.

14

Prevent exfiltration

If a machine is penetrated, limit the bad consequences. Could be use as zombie, deletion or

corruption of data, or theft. (This uncertainty is a major policy issue today.)

Theft is a major problem today. The problem with controlling theft:

How can an external agent tell if the transfer is legitimate?

15

Case studies Three stories:

Foreign hackers penetrate a system and send information back to their country. We try to block it.

Foreign citizens download public information from a U.S. web site. Their country tries to block it.

Users download pirated material from foreign site. The user’s country tries to block it.

What is the difference? We relabeled the actors. In one case, had to penetrate the sender to implement the pattern. In one case, the sender’s regime tries to block, in others the

receiver’s regime tries to block.

16

The design challenge, part two

How can we design applications and patterns of communication that can distinguish between these three stories, even if the sending machine has been penetrated?

17

Distinguish the stories In the first story:

Require that data being sent get an export permit (from a trusted machine), that the user must concur, and that we get a strong identity of the receiver before issuing the permit.

In the second story: Put the data into an open publish-subscribe or peer-to-peer

distribution system. Another example of the theory of availability. But protect the privacy of the requester…

But how to tell the second and third apart… Balance the interests…

Don’t forget other stories, such as unwelcome sending. These solutions involve application design.

Certain attacks can be degraded

For attacks that are economically motivated, it may be possible to render them no longer cost-effective.

Hint: Attacks against business--high value. Attacks against home computer--low value.

Requires collective action. Users cannot do this on their own.

Information assurance

Today we validate information by validating the source. Make a secure connection.

Most servers today do not support this... Once you have information (e.g. a web page), no way

to confirm it is legitimate. If information is signed, then it can be

authenticated independent of how it is distributed. But how do we know to trust the signature?

19

Remaining topics

DDoS National security

I ignore these due lack of time…

Summary

Good security is a balance among competing considerations.

It is not a problem that we can or should try to solve (totally) “in the network”.

Many problems arise (and must be handled) in the applications. Encouraging the design of secure

applications is central to a more secure future.

21

22

Aspects of security Attacks on the network

Routing, supply chain Attacks on communication

Confidentiality and integrity addressed with encryption. Availability?? The central objective of networks. What else?

Attacks on the host Infiltration (can lead to most anything) So either prevent infiltration or limit its consequences.

Denial of service A special case of availability.

Information assurance. Sign the information, not the connection.

National security

Who is responsible? Attacks on the network.

The network. Attacks on communication.

Confidentiality and integrity can be delegated to end-nodes. But remember communication among untrusting parties.

Availability is a shared responsibility. Mechanisms lead to clean failures, end-nodes (applications) must recover.

Attacks on hosts. Many parties have a role: end-node, trusted components, network,

application designer, user. DDoS.

A contested space. Information assurance

Sign the content, but how to trust the signature? National security.

23

24

Issues to consider Security Availability and resilience Better management Economic viability Meet society’s needs Support for tomorrow’s computing Exploit tomorrow’s networking Support tomorrow’s applications Fit for purpose (it works…)