Sunday, February 10, 2013

Non-repudiation–not a non-issue

To understand electronic non-repudiation, we must understand traditional non-repudiation from a legal perspective. The basis for a legal repudiation of a manual signature can pass only if the signature is a forgery, or an authentic signature was obtained via unconscionable conduct by a party to a transaction, fraud instigated by a third party, and undue influence exerted by a third party (McCullagh & Caelli, 2000).

From a technical perspective non-repudiation (NR) is basically proof that a certain principal sent or received the message in question. Every message exchange can be tied to a principal with a guarantee. An NR token is generated and verified that is sent by the principal – this way the principal cannot deny sending that message. In the same way, an NR token for a message received by the principal is created – this way the receipt of the message cannot be denied either.

The technical meaning of non-repudiation shifts the onus of proof from the recipient to the alleged signatory or entirely denies the signatory the right to repudiate a digital signature (McCullagh & Caelli, 2000). The use of a trusted system can solve the authentication, authorization and consequently non-repudiation issues by leveraging digital signatures.

Web-services. With more and more e-commerce being conducted on the Web and business-to-business transactions occurring, the importance of non-repudiation and digital signatures has gained a lot of importance. In the future, digital signatures will be commonly used in this area for providing non-repudiation services to the enterprise.

Sunday, February 3, 2013

Authorization–Legal Drinking Age ?

Authorization is the process by which valuable resources are protected and only limited access provided to principals who are authenticated. Principals are entities that request access to resources. Principals can be people or other servers. It is important to note that authorization can take place only when authentication of the principal has occurred previously. This makes sense because principals who are unable to prove their identity should not be given permission to access sensitive information.

http://whatisscotch.com/wp-content/uploads/2011/10/scotch-Whisky-Glass.jpg

Authorization in the Enterprise

In the enterprise environment access control comes in many flavors including discretionary, role-based, mandatory, and firewall types of access control. Discretionary authorization is the process by which two principal are given mutually exclusive access to the same resource. For example, principal A can be give read-only access to resource C while principal B can be given full access to the same resource. Usually such access control mechanisms are hierarchical in nature.

Access Control List

Discretionary access-control mechanisms typically maintain a list of principals and their associated permissions in an access control list (ACL). ACLs can be stored separately that can be accessed during the authentication or authorization process. Principals can also be parts of groups and have group access permissions applied. Role-base access control is applied when a usage role has to be applied across several principals. If there are multiple system users then a user group is created and a common ACL applied. Once the ACL is applied to the group, all principals that belong to the group automatically inherit the permissions too. It is still possible in most cases to override, overload or perform other polymorphic behaviors to user-permissions applied to principals. Applying access controls to security groups and principals works well in most cases.

Classifications. Classification levels may be used to specify authorization levels, in this scheme the resource, principal and groups are all supplied with a pre-defined authorization level, the level of comparative authorization defines the actual access roles. For example, if resource C is tagged as classified, resource D as unclassified, principal A as classified and principal B as unclassified then principal A can access both C & D while principal B can access only D. Such parallel hierarchies can determine the access logic with ease. In general, if a principal’s classification level is higher than that of the resource then the principal is given access to the resource.

Firewalls. Inter-network communications is often protected by a firewall in the enterprise. A firewall is a mechanism by which access to particular transport control protocol/Internet protocol (TCP/IP) ports on some network of computers is restricted based on the location of the incoming connection request. Firewalls are often a gateway that connects two or more networks. Rules can be applied to firewalls that can block certain ports, protocols and Internet protocol (IP) addresses from access the network. Proxy-servers are sometimes installed inside corporate networks that typically bypass the firewall.

Trust domains. Domains can be defined and be used to protect sensitive resources. This is accomplished by grouping all servers and processes that have the same access control policy into a domain. This trust-domain can interact at the micro level with a level of trust defined by the ACL. IP address with specific ports and communications can also be included in the domain as well. Security policy domains are also sometimes called realms.

Java technology. Java employs stringent security standards in the Java Virtual Machine (JVM), however when security domains are pre-defined, code can be executed over uniform resource locators (URL) within the trust-domains. Also multiple domains can be defined and trust at a certain level is defined, this way code executing in one domain can trust, and make useful calls to code running in another domain. The domain is thus called trusted domain. Sub-domains can be created and each sub-domain can have one or more parent domains. The partitioning of domains by creating sub-domains provides the ability to assign more restrictive permissions at the sub-domain level – but not higher access levels. Domains can also be federated; the federation of domains allows permissions to be assigned to domains and other sub-domains.

Auditing. Authorization requests can be logged by the servers, gateways and firewall. Audit logs can help isolate sequence of events of particular threads of events. Investigation of such type can be done in order to uncover any suspected authorization attempts into protected resources. A lot of information can be logged into the security log files. Typical information that is logged during a security audit is audit type events, timestamp of the event, identity of the principal requesting access, identification of the target source being requested, permission being requested on the target source, location from which the target source is being requested and any protocol-specific information respectively (Jaworski, Perrone & Chaganti, 2001). Due to the sensitive nature of security logs accessing security logs should be restricted to authorized principals.