Planning A Secure Partner Portal

IST 725 Case Study 2 – Planning a Secure Partner Portal Mar 12, 2012

Leo de Sousa

Planning a Secure Partner Portal Using Enterprise Security Architecture

Leo de Sousa – IST 725

Abstract This paper describes the risks and impacts to be considered when planning a secure partner portal. Research organizations looking for efficiencies and cost savings seek to build trusted, collaborative relationships with other organizations. This approach introduces new IT security risks that do not exist in a closed business technology platform. As organizations choose to provide access to their internal systems, they need to consider how to manage risks from authentication, authorization and information security. A holistic approach is required to identify risks and impacts associated with allowing multiple organizations access to a collaborative environment for research. This paper takes an Enterprise Security Architecture approach to outline the risks and impacts of implementing a secure partner portal. The sections of this paper are (a) Introduction, (b) Enterprise Security Architecture Components, (c) Governance, (d) Changes in Risk Profile and (e) Conclusion. After reading this paper, the reader should have a clear understanding of a risk based approach to planning a secure partner portal for collaboration.

Introduction As stated, research organizations looking for efficiencies and cost savings seek to build trusted, collaborative relationships with other organizations. Confidentiality, integrity and availability are the key enterprise security goals that must be addressed and planned for by enterprise security architecture. They become even more important when we share network access, business processes and information via a partner portal with external partners. One strategy is to ensure each organization has “defense in depth” in their Enterprise Security Architecture and Infrastructure. Here is a generalized definition of a partner portal. “A partner portal is a Web-based application that allows a manufacturer's established partner (usually a distributor, reseller, installer, service provider, or other strategic partner) to obtain direct access to marketing resources, pricing and sales information, as well as technical details/support that are unavailable to other end users. For example, the partner portal may list new promotions or discounts for the partner, allow the partner to examine service memoranda, or connect the partner with an assigned sales support representative for configuration assistance. The partner portal is typically accessed through the manufacturer's Web site, and requires the use of secure logon credentials assigned to the partner.” (Bigelow, 2007) Implementing a secure partner portal as a technical capability for collaboration introduces new IT security risks that do not exist in a single company business platform. Some of the risks of collaborating with external partners are:


Leo de Sousa

• lack of availability of shared processes (availability) • allowing external access to internal systems (confidentiality) • breaches of legal regulations (confidentiality) • loss of corporate information (integrity) • protection of personal and confidential information (confidentiality)

As organizations choose to provide external access to their internal systems, they need to consider how to manage risks from external authentication, authorization and information security. Assessments of partner organizations’ security maturity, information security policies and agreed upon trust levels help identify some of the risk areas. Once these risk areas are defined, the partner organizations need to develop a risk management plan that establishes the level of trust and governance between their organizations. This information is the basis for building a governance approach to managing the secure partner portal and the collaborations it facilitates.

Enterprise Security Architecture Components The EA3 Cube Documentation Framework (Bernard, 2005, p. 38) provides an excellent starting point to understand the risks and impacts of implementing a secure partner portal. The EA3 Cube describes an Enterprise Architecture by documenting the current state of an enterprise and then documenting the future state with the changes implemented. Here is an image of the EA3 Cube Documentation Framework:

Collaborating companies should focus on planning and security around the data and information, systems and applications and networks and infrastructure layers. There should be a special focus on data and information as digital information is growing exponentially in their enterprises. As organizations focus on research collaboration with each other, data and information are common elements they create, share and exchange. Looking at the EA3 Cube, we can see how each component interacts to enable secure sharing of data and information in a secure partner portal. Enterprise Security Architecture (ESA) is one of the planning threads in the EA3 Cube. Enterprise Security Architecture helps identify issues and the risks that could impact a company and its partners. ESA also provides a framework for planning and implementing secure business practices.


Leo de Sousa

Enterprise Security Architecture provides an approach that helps organizations understand the design of “security policy, security domains, trust levels, tiered networks and most importantly the relationships among them.” (Arconati, 2002, p. 1) A risk impact analysis for each of the four items in the table below will assist in ensuring that the Secure Partner Portal enables collaboration while protecting each company’s security. Table 1: Components for Enterprise Security Architecture Elements Description Policy

A security policy is a formal statement of the rules by which people who are given access to an organization's technology and information assets must abide. (Arconati, 2002, p. 3) Data Classifications determines the level of protection needed to manage risk – usually public, proprietary, private (Arconati, 2002, p. 5)

Security Domains

Security domains separate the enterprise network into logical, discrete entities and each has its own security policy. (Arconati, 2002, p. 6) Domain Classifications logically separate security domains – usually, user domain, transport domain, bastion domain and data domain

Trust Levels

Trust levels are used to evaluate the security needs of each domain and determine what kind of authentication and authorization must be performed to permit connections to a domain. (Arconati, 2002, p. 7) Trust Level Classification specify minimum requirements – usually Level 3 – not trusted, Level 2 – trusted with variation, Level 1 - trusted

Tiered Networks Tiered Network Model is a way to physically partition the enterprise network as specified by the enterprise security policy. (Arconati, 2002, p. 9) Tiered Network Classification has 3 tiers – usually internet tier, extranet tier and intranet tier.

This paper will apply these four elements to describe the changes to the Enterprise Security Architecture caused by implementing a secure partner portal with three hypothetical companies.

Governance IT Security Governance delivers the key capabilities to facilitate planning and decision making for enterprise risk management and strategic planning in a cybersecurity program. Building a shared governance model is the first step in creating a secure partner platform. The governance document establishes the rules that partners will follow while collaborating. Here are some of the items required for a governance plan:

• Costs of implementation and operations • Length of agreement • Amending and terminating the agreement • Participant and federation rights and responsibilities • Disclaimer, warrantee and liability limitations • Dispute resolution process


Leo de Sousa

The Canadian Access Federation (CANARIE, 2011) and the Internet2 InCommon Trust Federation (Internet2, 2012) are two examples of higher education federations. Both federations require participating members to complete and sign a participant operational practice (POP) document. Based on the completed POP, the member’s participation and trust level can be determined. This is a key risk mitigation policy step for creating a secure partner portal.

Consider three hypothetical research organizations, their general collaboration roles and their project specific roles in the proposed secure partner portal. Using an Enterprise Security Architecture approach for each company, we can describe the current state and relationship based on the following categories: Policy, Security Domains, Trust Levels and Tiered Networks. For each company we need to “observe how the security domains inherit the policy, how the trust relationships are established between the security domains based on the policy, and how tiered networks are physically utilized to support the policy.” (Arconati, 2002, p. 1) Once a holistic current state view of each company’s enterprise security architecture is captured, they can be compared for compatibility. Mismatches should be identified as risks that need to be addressed for a trust federation to be created. The successful implementation of the risk management strategies creates an identity trust federation.

Table 2: Overview of Companies – Current State Enterprise Security Architecture

Enterprise Identity Store

IT Infrastructure Architecture

IT Security Maturity

Policies Security Domains

Trust Levels

Tiered Networks

Company A – 1000 employees

On Premise On Premise Medium Responsible Use of Technology

On premise user, transport, bastion, data

Level 3 – None

Intranet

Company B – 450 employees

On Premise Hybrid - On Premise and

Cloud

High Responsible Use of Technology, Information Security

On premise user, transport, bastion, Cloud Hosted data

Level 2 – Partial

Intranet, Extranet

Company C – 75 employees

Off Premise Hosted Cloud Service

Low No internal policies

Cloud Hosted user, transport, bastion, data

Level 1 - Trusted

Intranet, Extranet, Internet

None of these three organizations have any collaboration agreements in place in their current state Enterprise Architecture. Company C does have an agreement with their cloud hosting service provider as they do not have an onsite data center. The security architecture was developed separately in each company making them difficult to compare directly. By using the four elements (policy, security domain, trust level, tiered networks), each company can be compared and risks identified.

Changes in Risk Profile Building a governance model requires focusing on the shared objectives of the three companies. In this scenario, there are overarching objectives of sharing resources and collaborating and


Leo de Sousa

project specific objectives where each company plays a specific role. Taking a risk based approach to this collaboration ensures that each company understands what they are committing to. The agreement also articulates what remedies are available should there be a breach of the terms of the agreement. A review of each company’s current state security architecture is a starting point to identify risks and develop mitigation strategies that can be put into the trust federation participation agreement.

Table 3: Company Roles Proposed for the Secure Partner Portal Current State ESA

Employees General Collaboration

Project 1 (role) Project 2 (role) Project 3 (role)

Company A 1000 Host Partner Partner Lead Company B 450 Consult Lead Partner Consult Company C 75 Consult Consult Lead Partner “Federated identity management involves having a common set of policies, practices and protocols in place to manage the identity and trust of users and services across organizations and security domains.” (Basney, Koranda, & Welch, 2007, p. 8) The risk profiles of each company will incur an increase in the levels of risk by implementing an Identity Trust Federation.

Each company in the federation will have to add and trust the other partners as identity providers. This requires each company to vet and manage their own employees who will be participating in the trust, to the satisfaction of their partners. A common vetting procedure needs to be established so that each company can mitigate the risk that untrusted parties will get access to confidential information such as identity and research project information.

There are two major use cases for risk in identity federation: risk of accepting external identities into an internal network and risk of asserting internal identities for use with external networks. (ID Federation Inc, 2012) These two risks only account for identity management issues in a trust federation. There are also risks associated with activity of employees’ actions – intentional or accidental, risk of accidental data and information leakage/breaches and risks of operational failure of the technology that supports the partner portal. For each risk, the participating companies must agree on a risk management plan.

There are benefits to implementing a trust federation that offset the risks. Some of the obvious savings are (Shuey, 2009, p. 5) (Basney, Koranda, & Welch, 2007, pp. 15-16):

• improved user experience allowing simplified access to collaboration materials using their home company identity credentials

• increased collaboration with partners which speeds time to market, provides shared profits and shares costs of research and development

• reduced operational overhead for managing identities and accounts for guest accounts in the internal company enterprise identity store – fewer helpdesk calls and incidents

• reduced risk of creating external/guest accounts within internal trusted systems • faster integration of new users and external/guest researchers into collaboration projects

and research – each company manages their own employees so that the work of identity and access management is done once at the home company and can be reused for the partner portal collaboration environment

• economies of scale to reduce costs for accessing resources for research and collaboration


Leo de Sousa

Here is a risk breakdown structure of the possible risks and mitigations to consider when implementing a trust federation for a secure partner portal.

Part

ner P

orta

l Ri

sks a

nd

Miti

gatio

ns

Accepting External Access

Risks Identified Mitigation Strategies

Loss of Control - rely on external security

Review and audit policies and practices

Differing Security Strength Review practices and limit participation

Increased Credential Exposure User training

External OPSEC Ability to remove trust if breached

External Operations Loss of service - rely on home ID for access

Logging/Monitoring Log Monitoring Program

Operational Complexity Maintain internal stds and train admins

External ID Vetting Internal vetting for high trust access

Accessing External Resources

Risks Identified Mitigation Strategies

Credential Disclosure User training and secure IDM practices

Operational Support Documentation and training

Information Disclosure Policy controls of what data is shared

Information Breach Training and

response/communication plan


Leo de Sousa

Conclusion Research organizations looking for efficiencies and cost savings seek to build trusted, collaborative relationships with other organizations. Confidentiality, integrity and availability are the key enterprise security goals that must be addressed and planned for by enterprise security architecture. They become even more important when we share network access, business processes and information via a partner portal with external partners. Collaborating companies should focus on planning and security around the data and information layer with the exponential growth of digital information in their enterprises. There are four key Enterprise Security Architecture elements to focus on when planning for a secure partner portal: policy, security domains, trust levels and tiered networks. Taking a risk based approach allows all partners to understand the risk and benefits of participating and the impacts on their organization’s Enterprise Security Architecture. The table below shows the impacts on each company’s future state enterprise security architecture at a high level for planning a secure partner portal.

Table 4: Overview of Companies – Future State Enterprise Security Architecture

Enterprise Identity Store

IT Infrastructure Architecture

IT Security Maturity

Policies Security Domains

Trust Levels

Tiered Networks

Company A – 1000 employees

On Premise On Premise Medium

High

Responsible Use of Technology, Information Security

On premise user, transport, bastion, data

Level 3 – None Level 2 – Partial (portal)


Company B – 450 employees

On Premise Hybrid - On Premise and

Cloud

High Responsible Use of Technology, Information Security

On premise user, transport, bastion, Cloud Hosted data

Level 2 – Partial


Company C – 75 employees

Off Premise Hosted Cloud Service

Low

High

No internal policies Responsible Use of Technology, Information Security

Cloud Hosted user, transport, bastion, data

Level 1 – Trusted (internal), and Level 2 – Partial (portal)


Changes None None Companies A and C increase

their security

practices to match B

Companies A and C increase their security practices to match B

Add a shared bastion and data domain specifically for the shared partner portal collaboration work

Develop and implement Level 2 Trusts for collaboration

Companies A and B add new network tiers to support the partner portal


Leo de Sousa

References Arconati, N. (2002). One Appoach to Enterprise Security Architecture. Retrieved from SANS

Institute Reading Room: http://www.sans.org/reading_room/whitepapers/policyissues/approach-enterprise-security-architecture_504

Basney, J., Koranda, S., & Welch, V. (2007). An Analysis of the Benefits and Risks to LIGO When Participating in Identity Federations. Urbana-Champaign, IL, USA.

Bernard, S. A. (2005). An Introduction to Enterprise Architecture 2nd Edition. Bloomington, IL: AuthorHouse.

Bigelow, S. J. (2007, Aug). partner portal. Retrieved from SearchITChannel - TechTarget: http://searchitchannel.techtarget.com/definition/partner-portal

CANARIE. (2011, Jul 6). Canadian Access Federation Participation Agreement. Ottawa, ON, Canada.

ID Federation Inc. (2012, Feb 21). Trust Framework. Retrieved from ID Federation: http://idfederation.com/trust-framework

Internet2. (2012, Feb 17). Building Identity Trust Federations. Retrieved from US Trust Federations: https://spaces.internet2.edu/display/USFederations/Building+Identity+Trust+Federations

Shuey, R. (2009, Feb 18). Federations and InCommon. University Park, PA, USA.

Planning A Secure Partner Portal

Documents

Transcript of Planning A Secure Partner Portal