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.

1. IST 725 Case Study 2 – Planning a Secure Partner Portal Mar 12, 2012
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 Page 1

2. IST 725 Case Study 2 – Planning a Secure Partner Portal Mar 12, 2012
• 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 Page 2

3. IST 725 Case Study 2 – Planning a Secure Partner Portal Mar 12, 2012
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 Page 3

4. IST 725 Case Study 2 – Planning a Secure Partner Portal Mar 12, 2012
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 IT IT Policies Security Trust Tiered
Identity Infrastructure Security Domains Levels Networks
Store Architecture Maturity
Company A On Premise On Premise Medium Responsible On premise Level 3 Intranet
– 1000 Use of user, – None
employees Technology transport,
bastion, data
Company B On Premise Hybrid - On High Responsible On premise Level 2 Intranet,
– 450 Premise and Use of user, – Partial Extranet
employees Cloud Technology, transport,
Information bastion,
Security Cloud
Hosted data
Company C Off Premise Hosted Cloud Low No internal Cloud Level 1 Intranet,
– 75 Service policies Hosted user, - Extranet,
employees transport, Trusted Internet
bastion, data
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.
Leo de Sousa Page 4
In this scenario, there are overarching objectives of sharing resources and collaborating and

5. IST 725 Case Study 2 – Planning a Secure Partner Portal Mar 12, 2012
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 Employees General Project 1 (role) Project 2 (role) Project 3 (role)
ESA Collaboration
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
Leo de Sousa Page 5
• economies of scale to reduce costs for accessing resources for research and collaboration

6. IST 725 Case Study 2 – Planning a Secure Partner Portal Mar 12, 2012
Here is a risk breakdown structure of the possible risks and mitigations to consider when
implementing a trust federation for a secure partner portal.
Risks Identified Mitigation Strategies
Loss of Control - rely on Review and audit policies and
external security practices
Review practices and limit
Differing Security Strength
participation
Increased Credential
User training
Exposure
Ability to remove trust if
Accepting External Access External OPSEC
breached
Loss of service - rely on home
External Operations
ID for access
Logging/Monitoring Log Monitoring Program
Partner Portal
Mitigations
Risks and
Maintain internal stds and
Operational Complexity
train admins
Internal vetting for high trust
External ID Vetting
access
Risks Identified Mitigation Strategies
User training and secure IDM
Credential Disclosure
practices
Accessing External Resources Operational Support Documentation and training
Policy controls of what data is
Information Disclosure
shared
Training and
Information Breach response/communication
plan
Leo de Sousa Page 6

7. IST 725 Case Study 2 – Planning a Secure Partner Portal Mar 12, 2012
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 IT IT Security Policies Security Trust Tiered
Identity Infrastructure Maturity Domains Levels Networks
Store Architecture
Company A On Premise On Premise Medium Responsible On premise Level 3 Intranet,
– 1000 Use of user, – None Extranet,
employees High Technology, transport, Level 2 Internet
Information bastion, data – Partial
Security (portal)
Company B On Premise Hybrid - On High Responsible On premise Level 2 Intranet,
– 450 Premise and Use of user, – Partial Extranet,
employees Cloud Technology, transport, Internet
Information bastion,
Security Cloud
Hosted data
Company C Off Premise Hosted Cloud Low No internal Cloud Level 1 Intranet,
– 75 Service policies Hosted user, – Extranet,
employees High Responsible transport, Trusted Internet
Use of bastion, data (internal
Technology, ), and
Information Level 2
Security – Partial
(portal)
Changes None None Companies Companies A Add a Develop Companies
A and C and C shared and A and B
increase increase their bastion and implem add new
their security data domain ent network
security practices to specifically Level 2 tiers to
practices to match B for the Trusts support the
match B shared for partner
partner collabor portal
portal ation
collaboratio
n work
Leo de Sousa Page 7

8. IST 725 Case Study 2 – Planning a Secure Partner Portal Mar 12, 2012
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.
Leo de Sousa Page 8