Distributed System Security

1. Distributed System Security Presented by Ajith Reddy Guedem

2. What is a Distributed System? Distributed System is a collection of multiple, independent and physically separated computers • which do not share their primary memory • communicate through high-speed bus or telephone line or are a part of network • which invoke a process on another computer without the direct participation of the user • which act to the user like a single computer (single system image) *The big advantage of distributed object systems is their modularity and flexibility. Exactly this, however, makes security more complex.

3. What are the security threats in a Distributed System? A security threat is a potential system misuse that could lead to a failure in achieving the system security goals. • Deliberate or accidental disclosure of data - Information Compromise • Knowingly or unknowingly destroying the data - Integrity Violations • Blocking or removing the system resources from being used by authorized users - Denial of service • Failure of Authentication and recording this fact – Repudiation of some fact • Bypassing of controls by malicious or negligent users - Malicious or negligent misuse

4. What are the vulnerabilities in a Distributed System? Vulnerabilities are the weaknesses of the system that leave the system open to one or more threats. • Authorized user gaining access to data that is should not see • Security controls being bypassed • Eavesdropping on communication lines • Lack of accountability • Disrupting the communication between the objects • User pretending to be someone else and using the rights of the person illegally

5. Why is security more complex in CORBA (Distributed System)? Since distributed system is not as simple as a client-server system there are some issues with distributed objects- • Mutual suspicion • Evolve continuously • Interactions between them are not well understood • Are polymorphic • Highly scalable and Dynamic • Highly layered

6. C O R B A Common Object Request Broker Architecture • Is Basically a Middle Ware technology (used for creating distributed systems) • Was Invented by the Object Management Group(OMG), a consortium of companies in 1989 • Is a unifying standard for writing distributed object systems • Is Neutral with respect to platform, languagesandvendor

7. C O R B A Common Object Request Broker Architecture Why Should I care about CORBA ? • You can use CORBA for legacy system integration For example an existing banking application written in C++ CORBA gives you the ability to preserve it and reuse it by wrapping the existing application as a CORBA object and can be called from any application • CORBA allows you for advances middle ware development If there is a middle ware service that can be generalized you are likely to find it standardized as a CORBA service * for those who need it CORBA gives great functionality

8. C O R B A Common Object Request Broker Architecture What are the benefits of using CORBA ? • CORBA is not controlled by one company Controlled by a group of companies and hence prevents from becoming a standard that is specific to only one product or architecture • CORBA is language independent When using CORBA you invoke methods in objects that are written in different programming languages which allows legacy integration with languages such as COBOL. e.g: If you are using Java then you can use CORBA instead of Java Native Interface for invoking objects written in C++. • CORBA provides optimal value added services These are add on usable services such as Naming service, Trading service, Event service, Transaction service and other secure aspects which guard the vulnerability of distributed objects

9. C O R B A Common Object Request Broker Architecture What does CORBA offer programmers? • Programming language independence • Distinction between Interface and Implementation • Location transparency and Server activation • Automatic Stub and Skeleton code generation

10. The ORB Architecture CLIENT SERVER ORB BOA ORB OSAGENT OSAGENT OSAGENT OSAGENT

11. C O R B A Common Object Request Broker Architecture • ORB: The ORB layer acts as an indirect connection between the client and server • OS Agent: These act like software brokers each associated with an ORB. • There may be many OS Agents in the network which communicate with each other to get the required object reference. • BOA: An object adapter is the primary way that an object implementation accesses services provided by the ORB. • Services provided by the ORB through an Object Adapter often include: • generation and interpretation of object references • method invocation, security of interactions • object and implementation activation and deactivation • mapping object references to implementations, and registration of implementations

12. C O R B A Common Object Request Broker Architecture CORBA Security(CORBASec) • Corba Security is one of the CORBAservices • The best way to think of Corba Security is an invisible mechanism that insures correct user access to data resources. Developers should be able to model authorization policies based on their requirement structure and easily administrate those policies. • It’s presence is felt by all user applications developed using CORBA as well as all other CORBAservices that the manufacturer provides • It’s usage within a large application needs to be carefully tuned because it will inevitably put a load on performance

13. C O R B A Common Object Request Broker Architecture What are the security aspects of CORBA? • Ensure that the communication between distributed objects is secure distributed objects (especially CORBA/IIOP communications). • User authentication - to let users identify themselves only once to gain access to many systems. • System authentication- ensure that systems(hosts) identify themselves to other systems in a distributed environment.

14. C O R B A Common Object Request Broker Architecture MEASURES TAKEN • Authentication • Message Protection (Encryption) • Access Control • Audit • Non Repudiation * There are some security aspects that are out of the scope of CORBA spec such as • Denial of service caused due to flooding • Traffic analysis as

15. Where exactly should the security measures be taken? C O R B A

16. Various Layers of security in CORBA C O R B A

17. Common Object Request Broker Architecture C O R B A Authentication

18. Common Object Request Broker Architecture C O R B A • User sponsor- user login • User login program(user ID , password) • Principal authenticator creates the credential object • Current - represents the current execution context (accessed by target and client ORB) Authentication

19. Common Object Request Broker Architecture C O R B A Message Protection(Encryption) • To scramble the data so that outsiders cannot read it • Encryption methods depend on the varying degrees of performance/protection tradeoffs • Requests and responses are to be protected from • Integrity - to prevent undetected, unauthorised modification of messages and to preserve the order of the messages • this is done thru cryptographic checksums and sequence numbers • Confidentiality - to ensure that messages have not been read in transit • this is done thru encryption techniques

20. Common Object Request Broker Architecture C O R B A Security Context Establishment

21. Common Object Request Broker Architecture C O R B A • Security associations is bindinglast for several requests i.e. once a caller and target trust each other • Secure Invocationchecks binding • Secure invocationcreates Vault • Vault creates the security context object • Vaultestablishes security association

22. C O R B A Common Object Request Broker Architecture Authorization and Access control

23. Common Object Request Broker Architecture C O R B A • After client authentication there are two types of access control • Application level access controlfor security aware applications where both the client and target object call Domain Manager which in turn calls policy objects in enforce local access policies • ORB access controlfor both security aware and security unaware applications where is access control is built into the ORB and cannot be bypassed. ORB calls Client Access decision objects from security services to implement required rights according to the access policy.

24. C O R B A Common Object Request Broker Architecture Auditing

25. Common Object Request Broker Architecture C O R B A • There are two categories of audit policies • System audit policies • Records results of system related activities • like authentication, privileges, success or failure of authorization - these are enforced automatically • Application audit policies • Records results of application related activities • we can select events audited by - • object type or object • operation • time • principle attributes • success or failure of an operation

26. C O R B A Common Object Request Broker Architecture Non Repudiation

27. Common Object Request Broker Architecture C O R B A • Provide an irrefutable evidence for an claimed action or event • Give the sender proof of receipt • The target calls NRCredentials objects and generates the evidence - proof of receiptand is sent to the client with the response.Client verifies evidence called by client to check the proof of receipt. • Give the receiver with proof of origin • The client calls the NRCredentials object and generates the evidence which is then sent to the target .Target calls the verify evidence operation of its NRCredentials object

28. Common Object Request Broker Architecture C O R B A Questions and Comments?