Privacy, security and ethical reflection

Sangeeth08

ITC568_201860_Wk9_Protecting_Digital_Identities.pptx

Home >Computer Science homework help >Privacy, security and ethical reflection

ITC568 Cloud Privacy and Security

Protecting Digital Identities and Privacy

Week 9

Dr Peter White

Examine the legal, business and privacy requirements for a cloud deployment model

Evaluate the risk management requirements for a cloud deployment model

Critically analyse the legal, ethical and privacy concerns for the privacy and security of data deployed to the cloud

Develop a series of security controls to manage the security and privacy of data deployed to the cloud

Agenda

An Identity Management Architecture (IdMA) is defined by Windley as ‘a coherent set of standards, policies, certifications and management activities…aimed at providing a context for implementing a digital identity infrastructure that meets the current goals and objectives of the business’

White et al. defines an Identity Management Framework as ‘…one that combines the identity administration of entities and their identities with identity based access management to control access to the resources of an enterprise’

The IdMF is divided into two components:

Identity Administration, and

Identity based Access Management.

Identity Management

Identity Management Framework

White, P. (2008). Identity Management Architecture: A New Direction. Paper presented at the 8th International Conference on Computer and Information Technology CIT 2008, Sydney.

Identity Administration

Identification

Personal identification

Pseudonym identification

Verification

Verification against known data

Level of assurance required

Identity risk assessment

Enrolment

Digital Identity creation

Credential creation

Life cycle management

Entity management

Credential management

Audit & Governance

Identity Management Framework

Confirm uniqueness of the identity in the intended context

to ensure that individuals can be distinguished from one another and that the right service is delivered to the right individual.

Confirm the claimed identity is legitimate

to ensure the identity has not been fraudulently created (i.e. the identity is that of a real person) through evidence of commencement of identity in Australia.

Confirm the operation of the identity in the community over time

to provide additional confidence that an identity is legitimate in that it is being used in the community (including online where appropriate).

Confirm the linkage between the identity and the person claiming the identity

to provide confidence that the identity confirmed through objectives 2 and 3 is not only legitimate, but that the person claiming the identity is its legitimate holder. This has traditionally been done by comparing a person’s face against a photograph

Confirm the identity is not known to be used fraudulently

to provide additional confidence that a fraudulent (either fictitious or stolen) identity is not being used. This could be through checks against internal registers of known fraudulent identities or against ‘dummy records’ recorded in the system.

Attorney-General's Department. (2016). National Identity Proofing Guidelines. Canberra

Proof of Identity

Level	Description	Aim	Controls
1	Little confidence in the accuracy or legitimacy of a claimed identity. Appropriate for transactions with minimal consequences to the organisation or community from registration of a fraudulent identity.	Identity is unique within the context	Self-claimed or self-asserted identity (pseudonymity is possible, but not anonymity)
2 Bronze Standard	Some confidence in the claimed identity. Appropriate for transactions with some consequences associated with registration of fraudulent identities	Identity is unique within the context, identity recognised by authoritative sources	Evidence of identity through use of identity information or documents from authoritative sources
3 Silver Standard	High confidence in the claimed identity. Appropriate for transactions with serious consequences associated with fraudulent registration, such as allowing access to sensitive information, systems or people	Identity is unique within the context, identity recognised by authoritative sources, identity information is verified, identity is used in other contexts the person is linked to the identity	Evidence of identity through use of identity information or documents from authoritative sources + information or documents verified with an authoritative source
4 Gold Standard	Very high confidence in the claimed identity. Appropriate for transactions with very serious consequences associated with fraudulent registration to the organisation	Identity is unique within the context, identity recognised by authoritative sources, identity information is verified, identity used in other contexts the person is linked to the identity	Evidence of identity through use of identity information or documents from authoritative sources + information or documents verified with an authoritative source + individual witnessed in-person

Levels of Assurance

Identity based Access Management

Provisioning

Security groups

Roles

Resources

Elevated permissions

Authentication

Directory Services

Meta Directories

Authorisation

Life Cycle Management

Roles management

Permissions management

Access management

De-provisioning

Audit & Governance

Identity Management Framework

Sullivan(2015, p.150) sees Digital Identity as two components:

A small set of defined, static information that is presented for a transaction, such as

Name, DoB, gender, an identifier (usually numerical), signature, etc.

A much larger set of more detailed “other information” which is updated on an on-going basis to record transaction history, which can be used to profile an individual

Two major risks with Cloud-based Digital Identities:

Lack of control

Cloud clients may no longer be in exclusive control of the PII data committed to an outsourced system and may not be able to take the appropriate measures to protect and maintain the data

Lack of information on processing

Insufficient information about processing may create new problems for data controllers if they are unaware of potential threats & risks caused by outsourced processing operations and cannot mitigate against those risks

Identity Management in the Cloud

AWS Identity and Access Management (IAM) is a web service that is used to securely control access to AWS resources

IAM is used to control who can use AWS resources (authentication) and what resources they can use and in what ways (authorisation)

IAM can be used to:

Authenticate both internal and external users

Grant fine-grained access to resources

Manage access control for mobile applications

The AWS IAM module

From: http :// docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html

Best practices:

Lock Away AWS Account Root User Access Keys

Create Individual IAM Users

Use AWS Defined Policies to Assign Permissions Whenever Possible

Use Groups to Assign Permissions to IAM Users

Grant Least Privilege

Use Access Levels to Review IAM Permissions

Configure a Strong Password Policy for Your Users

Enable MFA for Privileged Users

Use Roles for Applications That Run on Amazon EC2 Instances

Delegate by Using Roles Instead of by Sharing Credentials

Rotate Credentials Regularly

Remove Unnecessary Credentials

Use Policy Conditions for Extra Security

Monitor Activity in Your AWS Account

The AWS IAM module

From: http :// docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

An identity federation can be established between two organisations by establishing trust between two security realms.

A federation server on one side (the Accounts side) authenticates the user through standard Lightweight Directory Access Protocol (LDAP) means and issues a token containing a series of claims about the user, including its identity.

On the other side, the Resources side, another federation server validates the token and issues another token for the local servers to accept the claimed identity.

This allows a system to provide controlled access to its resources or services to a user that belongs to another security realm without requiring the user to authenticate directly to the system and without the two systems sharing a database of user identities or passwords.

In practice a user might typically perceive this approach as follows:

The user logs into their local PC (as they typically would when commencing work in the morning).

The user needs to obtain information from a partner company's extranet website, for example to obtain pricing or product details.

The user navigates to the partner-company extranet site, for example: http://example.com.

The partner website now does not require any password to be typed in; instead, the user credentials are passed to the partner extranet site using a SAML 2.0 token (or similar)

The user is now logged into the partner website and can interact with the website as if logged in.

Another possibility – Federation?

What does this mean for organisations?

With federation, you can use single sign-on (SSO) to access your Cloud accounts using credentials from your corporate directory. Federation uses open standards, such as Security Assertion Markup Language 2.0 (SAML), to exchange identity and security information between an identity provider (IdP) and an application.

You also can add federation support to your web and mobile apps running in the Cloud. This means that:

You can provide SSO access for internal users

You can provide strong authentication and access control for external users of these apps

Federation

Stronger identity proofing processes will often, though not necessarily, require collection of greater amounts of personal information (the best designed identity proofing processes actually minimise the amount of personal information collected).

Collecting more personal information than is reasonably necessary can adversely impact on privacy and breach privacy legislation. This can also increase the potential consequences from any theft, loss or compromise of the personal information collected and retained as a result of the identity proofing process.

An identity-related risk assessment MUST include:

Consideration of the appropriate amount of information to collect,

The privacy implications from collecting and storing personal information for identity proofing purposes.

Organisations MUST ensure all handling of personal information aligns with relevant Commonwealth or state and territory privacy legislation, such as provisions regarding collection, consent, access to information, disclosure and retention.

Identity risk assessments SHOULD be coordinated with a privacy impact assessment, where appropriate.

Privacy impact assessments ‘tell the story’ of a project from a privacy perspective and helps manage privacy impacts.

Like an identity risk assessment, the specific details of a privacy impact assessment will be dependent on the context in which it is being conducted.

In broad terms, a robust privacy impact assessment describes how personal information flows, is used and stored.

It analyses the possible impacts on individuals’ privacy, and identifies and recommends options for managing, minimising or eradicating impacts.

Misuse of identity information is a key enabler of a range of fraudulent activities. The identity risk assessment SHOULD be undertaken within the context of the broader authentication, identity management, fraud, information security and risk management processes of the enrolling organisation.

A monitoring and evaluation plan SHOULD be developed as part of the design phase before an identity proofing process becomes operational

Privacy and Identity Management

Some steps for protection and privacy:

Determine if identity is necessary for the goal at hand

Determine the exact workflow and see if separate “domains” can be delinked

Eg. For online payments, the delivery service does not need to know the financial details, and the payments service does need to know the goods purchased and delivery details

Can a pseudonym be used as part of this transaction to further protect the digital identity?

Can tokens, or private credentials, be used to let individuals prove their authorisation (eg. over 18 years) without identifying them?

Implementing Privacy Policies that are accessible and understandable and are seen to be implemented

Adopting trust enhancing measures, such as

timely & helpful feedback,

Allowing users to access, correct, and in some cases, delete information about themselves

Providing a structured procedure for challenging conclusions drawn from user PII data and their transaction data

Protecting Digital Identities

Reading:

Sullivan, C. (2015). Protecting digital identity in the cloud. In Ko, R., & Choo, K.(Eds.). (2015). The Cloud Security Ecosystem: Technical, Legal, Business and Management Issues. Waltham, MA: Syngress.

Hansen, M., Schwartz, A., & Cooper, A. (2008). Privacy and Identity Management. IEEE Security & Privacy, (2), 38-45. Retrieved from http://ieeexplore.ieee.org.ezproxy.csu.edu.au/document/4489848/

White, P. (2008). Identity Management Architecture: A New Direction. Paper presented at the 8th International Conference on Computer and Information Technology CIT 2008, Sydney. Retrieved from: http://ieeexplore.ieee.org.ezproxy.csu.edu.au/document/4594710 /

Attorney-General's Department. (2016). National Identity Proofing Guidelines. Canberra: Attorney-General's Department Retrieved from https://www.ag.gov.au/RightsAndProtections/IdentitySecurity/Documents/NationalIdentityProofingGuidelines.PDF .

Watch:

Digital Identity and e-Citizenship at https:// youtu.be/ieFPW1EiAEs

Digital Identity Management at https:// youtu.be/fXz4YzW5GAQ

Digital Identity Management and Protection by Elisa Bertino at https:// youtu.be/p8vxra1mUVU

Tasks: