Intrusion Tolerant Distributed Object Systems OASIS PI Meeting Norfolk, VA February 12-16, 2001...

Intrusion TolerantIntrusion TolerantDistributed Object SystemsDistributed Object Systems

OASIS PI MeetingOASIS PI MeetingNorfolk, VANorfolk, VA

February 12-16, 2001February 12-16, 2001

Gregg TallyGregg Tally Brent WhitmoreBrent [email protected]@nai.com [email protected]@nai.com

February 13, 2001 2

AgendaAgendaMotivationOverviewPlans and Progress to DateIntrusion Tolerant CORBA ArchitectureSummary

February 13, 2001 3

MotivationMotivationMission critical applications are being developed using

CORBA on COTS platformsCORBA Security protects at middleware level, but

applications vulnerable to O/S and network attacksFault Tolerant CORBA does not protect against

malicious faults

February 13, 2001 4

Technical Objectives Technical Objectives Provide intrusion tolerance for CORBA applicationsSystem level approach

– MiddlewareEliminate reliance on any single server

– secure, reliable group communication directly between clients and replicated servers

Detect Byzantine (arbitrary) faults in serversSupport heterogeneity (diversity of implementation)

– Boundary controllers (firewalls)Protocol inspectionEnd-to-end authentication between clients and servers

February 13, 2001 5

Existing ApproachesExisting ApproachesOMG supports Fault Tolerance for CORBA

– Doesn’t tolerate Byzantine faults– No firewall support

Prior and Current Research– Avoided ORB changes by intercepting process level

communications; forces homogeneous server implementation

– Uses “primary” or “lead” server that may not tolerate Byzantine faults

– Ensemble, Maestro, AQuA, Rampart, Eternal, others

February 13, 2001 6

Technical ApproachTechnical ApproachLeverage prior work on fault tolerant CORBA; secure,

reliable, authenticated multicast; total ordering; Byzantine fault detection

Modify prior work to fit intrusion tolerance requirementsActive replication of clients and servers with votingProtect client and server hosts with application proxy

firewall; include firewall in multicast groupIntegrate with open-source ORB

– Detect value faults in middleware– Replace transport layer with secure, reliable, authenticated

multicast

February 13, 2001 7

Expected AchievementsExpected AchievementsAt least one implementation of an ORB on two or more

heterogeneous platforms that tolerates Byzantine faultsIntegrated application proxy firewall support to protect

COTS client and server hostsUnderstand trade-off between performance and

degrees of intrusion toleranceDevelop Countermeasure Characterization to identify

assumptions and residual risks

February 13, 2001 8

Progress to DateProgress to DateDeveloping Intrusion Tolerant CORBA Architecture:

– Documented low-level use cases– Reviewed prior work:

Fault tolerant systems: Electra, EternalGroup communication systems: Rampart, Transis, ISIS,

AQuA, SecureRing / SecureGroup, Castro-LiskovCryptographic algorithms:

– Burmeister-Desmedt's Eurocrypt 94 paper– Shoup's Eurocrypt 2000 threshold signature paper– Menezes et al's "Handbook of Applied Cryptography",

OMG’s Fault Tolerant CORBA specificationsWSU / Verizon-BBN Virtual Voting Machine

February 13, 2001 9

Progress (cont’d)Progress (cont’d)Selected TAO as the prototype implementation ORBReceived source code for Castro-Liskov group

communication systemInitial architecture nearing completion

February 13, 2001 10

Intrusion Tolerant CORBAArchitecture

Intrusion Tolerant CORBAArchitecture


Conceptual OverviewConceptual Overview

Firewall

Secure,Reliable,

Auth.Multicast

GIOPProxy

Client ApplicationCode

IT ORB

Voter

Value Fault Detection / Voting

Redundant Msg. Exclusion

Time, Crash, otherFault Detection

Encode/Decode

Secure, Reliable, Auth. Multicast

FirewallM-CastGIOPProxy

Server Application

Code

IT ORB

Server Application

Code

IT ORB

Server Application

Code

IT ORB



Client-SideFirewall

Server-SideFirewalls

RedundantServers

ITDOS Services


Approach -- What’s Different ?Approach -- What’s Different ?All servers are equal

– eliminate need for “primary” or “lead” server

Detect value faults in the ORB– encoding of CORBA messages depends on the source

platform (i.e, byte ordering)– permits heterogeneous implementations

different O/S, hardware, ORBs– permits parametric comparisons

exact matches not required for inexact values (e.g., floating point)


Approach -- What’s Different ?Approach -- What’s Different ?Transparent object replicationApplication proxy firewall integrated into the

architecture– better protection for COTS client and server hosts– end-to-end authentication of client and server– may have better performance than IIOP/SSL proxies


Operating ConstraintsOperating Constraints f faulty processors3f available processorsDeterministic servicesSeparation of replicated servers

– network– geography


Simplifying AssumptionsSimplifying AssumptionsAddition of replacement servers not addressed (first

iteration)Network does not partition such that more than f

servers are unreachableSecure configuration mechanismOther CORBA services handle these application needs:

– object-level access control– audit– non-repudiation– user-level authentication


Architecture DetailedArchitecture Detailed

IT ORB

Voting Machine

Replication Manager

Encode/Decode

Secure Reliable Multicast

ApplicationCode

Group Manager

Replica Locator

ITDOS Services

Replicated Objects


Voting MachineVoting Machine

IT ORB

Voting Machine

Replication Manager

Encode/Decode


ApplicationCode

Group Manager

Replica Locator

ITDOS Services


Voting MachineVoting MachineBorrows from Washington State University/Verizon-

BBN workAbstracts out the voting algorithmDetermine result from possibly inexact matchesPermits alternatives to majority voting & strict

equivalenceExamples:

– mean, median, mode– majority rule – floating point comparison


ITDOS Services - Group ManagerITDOS Services - Group Manager

IT ORB

Voting Machine

Replication Manager

Encode/Decode


ApplicationCode

Group Manager

Replica Locator

ITDOS Services


Secure Multicast GroupsSecure Multicast GroupsTwo flavors

– Replica groups– Communication groups

Features– IP Multicast address– Intra-group message secrecy– Message authentication

Replicated Group Manager object– Creates/destroys groups– Tracks and manages membership– Administers secrecy, authentication, communication policy


Replica GroupsReplica GroupsBind VM algorithm selectionsDefine vote points

–Send request/receive reply–Send reply/receive request

“A” replicas

“B” replicas


Communication GroupsCommunication GroupsServes an invocation bindingAnalogous to unicast connectionsMembers see all requests & replies between

client & server replica groups

“A” replicas

“B” replicas


VotingVotingValue voting

– Receiver– Generates agreement on the value of the request or reply

Detection voting– Sender– Detects failure to invoke consistently on other objects

Consequences of failure– Remove offending process from all groups


VotingVoting

“A” replicas

“B” replicas

4 - Receive reply3 - Send reply

1 - Send request2 - Receive request

DDvv

DDvv

DDvv

DDvv

DDvv

DDvv

VVvv

VVvv

VVvv

VVvv

VVvv

VVvv

Detection Votes

Value Votes


ITDOS ServicesITDOS Services

IT ORB

Voting Machine

Replication Manager

Encode/Decode


ApplicationCode

Group Manager

Replica Locator

ITDOS Services


Replication ManagerReplication ManagerManages replication policy

– Replica group cardinality– Policy granularity at replica group level

Directs Group Manager to establish replica group memberships

Called by ORB at object activation– Replication transparent to client and server objects


Replica LocatorReplica LocatorNaming serviceHelps Replication Manager to:

– Initiate group creation– Track replica assignment to groups

Helps ORB bind CORBA objects to replica groups


Secure Reliable Multicast ProtocolSecure Reliable Multicast Protocol

IT ORB

Voting Machine

Replication Manager

Encode/Decode


ApplicationCode

Group Manager

Replica Locator

ITDOS Services


Secure Reliable Multicast ProtocolSecure Reliable Multicast ProtocolProperties

– Reliable Delivery by processesintegrity - delivered only once & only if sentagreement - all delivered or nonevalidity - delivered if sent

– Totally ordered– Secure

source authenticitymessage integrityconfidentiality

Uses IP multicast


SummarySummaryContinuing to refine Intrusion Tolerant CORBA

Architecture– Developed initial architecture– Re-use and modify prior work to meet IT CORBA

requirements– Expect to complete Architecture by end of March; begin

implementation

Plan to start Countermeasure Characterization in March


BackupBackup


MetricsMetricsCost/benefit of redundant servers

– Tolerance of Byzantine faults (number of faulted servers) vs. impact on throughput due to additional replication

– Throughput measured by operations per second– Invocation latency

IA Countermeasure CharacterizationExperimentation at the TIC to validate countermeasure

claims


4 Questions - Threats / Attacks4 Questions - Threats / AttacksTolerate Byzantine (arbitrary) behavior by some threshold number (f) of

servers in a replicated group of (n) object servers.

Guarantee availability of the servers, provided that greater than the threshold number of servers has not been compromised.

Guarantee integrity of the communication between the clients and servers, and accuracy of the answers provided by the servers.

Confidentiality of the communication, unless a replicated server or Group Manager is compromised

Given these considerations, any attack against a replicated server in our system may be defended against as long as the resilience threshold (of the replicated group) is not exceeded. However, we should note that DOS attacks against individual servers can affect the system as a whole in that it may impede performance, and possibly affect the eventual exclusion of the attacked (but correct) process.


4 Questions - Assumptions4 Questions - AssumptionsThe OS and platforms are vulnerable to attack and failure, but a

vulnerability in one OS or platform does not necessarily imply that a different OS or platform has the same vulnerability (i.e., diversity of implementation provides better survivability).

We rely upon the integrity of the network infrastructure to the extent that not more than f replicated servers become unreachable. The network does not partition such that more than f of the replicated servers becomes unreachable.

We assume that there will be f faults in a replicated group at any one time, where the number of servers in the replicated group is > 3f.

Servers exhibit deterministic behavior.


4 Questions - Assumptions (cont’d)4 Questions - Assumptions (cont’d)A correct server can not be delayed indefinitely.Cryptography prevents identity forgery and traffic sniffingObject-level access control, audit, non-repudiation, and user-

level authentication are performed by other CORBA services.QoS and QoP are performed by entities external to our system.In a real deployment of our system, to limit the incidence of

simultaneous failures, network and geography separate the replicated servers.

We assume that the authentication tokens for each process are adequately protected and only available to authorized users.


4 Questions - Policies4 Questions - PoliciesPolicies governing group membership, based on identity of processes

wishing to join groups:– Rules indicating fault tolerance level, which directly impacts the number of

processes required for a replicated object group.– Policies on “open” operations. An open operation is performed when a client

wishes to establish a connection with a replicated group.Voting behavior. In certain cases, there may be legitimate differences in

values between replicas, even though the values are equivalent. There may be other cases where voting behavior can be driven by policy.

Object-access control, although these will be enforced by CORBA security mechanisms. Those mechanisms are outside the scope of our project.

Standard firewall behavior policies (permit / deny) to regulate the secure, reliable multicast protocol.

INFOCON changes, especially those for replication levels.


4 Questions - Collection of Projects4 Questions - Collection of ProjectsIntegrate with intrusion detection

– If an intrusion detection system noted a certain level of intrusion in a given network, an intrusion tolerant architecture could downgrade trust for entities within that network.

– Or, in a replicated system, remove a replica from that network, and add one to another to proactively counteract the attack.


ScheduleScheduleTask Deliverable 2000 2001 2002

Draft Intrusion Tolerant CORBAArchitecture Report

R

Intrusion Tolerant CORBAPrototype Implementation

S

Task 1

Final Intrusion Tolerant CORBAArchitecture Report

R

Draft Secure Reliable MulticastGIOP Firewall Proxy Arch. Rpt.

R

Secure Reliable Multicast GIOPFirewall Proxy Prototype

S

Task 2

Final Secure Reliable MulticastGIOP Firewall Proxy Arch. Rpt.

R

Intrusion Tolerant CORBAExperimentation Plan

R

Intrusion Tolerant CORBAExperimentation Report

R

Intrusion Tolerant CORBA Cost/Benefit Analysis

R

Task 3

Final Report (at contract end) R R = Report S = Software


Technology TransferTechnology TransferWork with OMG to revise existing specifications, create

new specifications– Fault Tolerance specification– Unreliable Multicast specification– Firewall specification

Joint experimentation with other DARPA and DoD programs

Conferences and workshops

Intrusion Tolerant Distributed Object Systems OASIS PI Meeting Norfolk, VA February 12-16, 2001...

Documents

Transcript of Intrusion Tolerant Distributed Object Systems OASIS PI Meeting Norfolk, VA February 12-16, 2001...