Planning A Secure Partner Portal

283
-1

Published on

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.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
283
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Planning A Secure Partner Portal

  1. 1. IST 725 Case Study 2 – Planning a Secure Partner Portal Mar 12, 2012Planning a Secure Partner Portal Using Enterprise Security Architecture Leo de Sousa – IST 725 AbstractThis paper describes the risks and impacts to be considered when planning a secure partnerportal. Research organizations looking for efficiencies and cost savings seek to build trusted,collaborative relationships with other organizations. This approach introduces new IT securityrisks that do not exist in a closed business technology platform. As organizations choose toprovide access to their internal systems, they need to consider how to manage risks fromauthentication, authorization and information security. A holistic approach is required toidentify risks and impacts associated with allowing multiple organizations access to acollaborative environment for research. This paper takes an Enterprise Security Architectureapproach to outline the risks and impacts of implementing a secure partner portal. The sectionsof 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 readershould have a clear understanding of a risk based approach to planning a secure partner portal forcollaboration. IntroductionAs stated, research organizations looking for efficiencies and cost savings seek to build trusted,collaborative relationships with other organizations. Confidentiality, integrity and availabilityare the key enterprise security goals that must be addressed and planned for by enterprisesecurity 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 toensure each organization has “defense in depth” in their Enterprise Security Architecture andInfrastructure. Here is a generalized definition of a partner portal.“A partner portal is a Web-based application that allows a manufacturers established partner(usually a distributor, reseller, installer, service provider, or other strategic partner) to obtaindirect access to marketing resources, pricing and sales information, as well as technicaldetails/support that are unavailable to other end users. For example, the partner portal may listnew promotions or discounts for the partner, allow the partner to examine service memoranda, orconnect the partner with an assigned sales support representative for configuration assistance.The partner portal is typically accessed through the manufacturers Web site, and requires the useof secure logon credentials assigned to the partner.” (Bigelow, 2007)Implementing a secure partner portal as a technical capability for collaboration introduces newIT security risks that do not exist in a single company business platform. Some of the risks ofcollaborating with external partners are:Leo de Sousa Page 1
  2. 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 toconsider how to manage risks from external authentication, authorization and informationsecurity. Assessments of partner organizations’ security maturity, information security policiesand agreed upon trust levels help identify some of the risk areas. Once these risk areas aredefined, the partner organizations need to develop a risk management plan that establishes thelevel of trust and governance between their organizations. This information is the basis forbuilding a governance approach to managing the secure partner portal and the collaborations itfacilitates. Enterprise Security Architecture ComponentsThe EA3 Cube Documentation Framework (Bernard, 2005, p. 38) provides an excellent startingpoint to understand the risks and impacts of implementing a secure partner portal. The EA3Cube describes an Enterprise Architecture by documenting the current state of an enterprise andthen documenting the future state with the changes implemented. Here is an image of the EA3Cube 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 focuson data and information as digital information is growing exponentially in their enterprises. Asorganizations focus on research collaboration with each other, data and information are commonelements they create, share and exchange. Looking at the EA3 Cube, we can see how eachcomponent 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 companyand its partners. ESA also provides a framework for planning and implementing secure businesspractices.Leo de Sousa Page 2
  3. 3. IST 725 Case Study 2 – Planning a Secure Partner Portal Mar 12, 2012Enterprise Security Architecture provides an approach that helps organizations understand thedesign of “security policy, security domains, trust levels, tiered networks and most importantlythe relationships among them.” (Arconati, 2002, p. 1) A risk impact analysis for each of the fouritems in the table below will assist in ensuring that the Secure Partner Portal enablescollaboration while protecting each company’s security.Table 1: Components for Enterprise Security ArchitectureElements DescriptionPolicy A security policy is a formal statement of the rules by which people who are given access to an organizations 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 domainTrust 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 - trustedTiered 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 SecurityArchitecture caused by implementing a secure partner portal with three hypothetical companies. GovernanceIT Security Governance delivers the key capabilities to facilitate planning and decision makingfor enterprise risk management and strategic planning in a cybersecurity program. Building ashared governance model is the first step in creating a secure partner platform. The governancedocument establishes the rules that partners will follow while collaborating. Here are some ofthe 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 processLeo de Sousa Page 3
  4. 4. IST 725 Case Study 2 – Planning a Secure Partner Portal Mar 12, 2012The Canadian Access Federation (CANARIE, 2011) and the Internet2 InCommon TrustFederation (Internet2, 2012) are two examples of higher education federations. Bothfederations 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 canbe 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 theirproject specific roles in the proposed secure partner portal. Using an Enterprise SecurityArchitecture approach for each company, we can describe the current state and relationshipbased 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 thetrust relationships are established between the security domains based on the policy, and howtiered networks are physically utilized to support the policy.” (Arconati, 2002, p. 1) Once aholistic current state view of each company’s enterprise security architecture is captured, theycan be compared for compatibility. Mismatches should be identified as risks that need to beaddressed for a trust federation to be created. The successful implementation of the riskmanagement 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 MaturityCompany A On Premise On Premise Medium Responsible On premise Level 3 Intranet– 1000 Use of user, – Noneemployees Technology transport, bastion, dataCompany B On Premise Hybrid - On High Responsible On premise Level 2 Intranet,– 450 Premise and Use of user, – Partial Extranetemployees Cloud Technology, transport, Information bastion, Security Cloud Hosted dataCompany C Off Premise Hosted Cloud Low No internal Cloud Level 1 Intranet,– 75 Service policies Hosted user, - Extranet,employees transport, Trusted Internet bastion, dataNone of these three organizations have any collaboration agreements in place in their currentstate Enterprise Architecture. Company C does have an agreement with their cloud hostingservice provider as they do not have an onsite data center. The security architecture wasdeveloped separately in each company making them difficult to compare directly. By using thefour elements (policy, security domain, trust level, tiered networks), each company can becompared and risks identified. Changes in Risk ProfileBuilding a governance model requires focusing on the shared objectives of the three companies.Leo de Sousa Page 4In this scenario, there are overarching objectives of sharing resources and collaborating and
  5. 5. IST 725 Case Study 2 – Planning a Secure Partner Portal Mar 12, 2012project specific objectives where each company plays a specific role. Taking a risk basedapproach to this collaboration ensures that each company understands what they are committingto. The agreement also articulates what remedies are available should there be a breach of theterms of the agreement. A review of each company’s current state security architecture is astarting point to identify risks and develop mitigation strategies that can be put into the trustfederation participation agreement.Table 3: Company Roles Proposed for the Secure Partner PortalCurrent State Employees General Project 1 (role) Project 2 (role) Project 3 (role)ESA CollaborationCompany A 1000 Host Partner Partner LeadCompany B 450 Consult Lead Partner ConsultCompany C 75 Consult Consult Lead Partner “Federated identity management involves having a common set of policies, practices andprotocols in place to manage the identity and trust of users and services across organizations andsecurity domains.” (Basney, Koranda, & Welch, 2007, p. 8) The risk profiles of each companywill 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 identityproviders. This requires each company to vet and manage their own employees who will beparticipating in the trust, to the satisfaction of their partners. A common vetting procedureneeds to be established so that each company can mitigate the risk that untrusted parties will getaccess 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 identitiesinto 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 atrust federation. There are also risks associated with activity of employees’ actions – intentionalor accidental, risk of accidental data and information leakage/breaches and risks of operationalfailure of the technology that supports the partner portal. For each risk, the participatingcompanies must agree on a risk management plan.There are benefits to implementing a trust federation that offset the risks. Some of the obvioussavings 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 environmentLeo de Sousa Page 5 • economies of scale to reduce costs for accessing resources for research and collaboration
  6. 6. IST 725 Case Study 2 – Planning a Secure Partner Portal Mar 12, 2012Here is a risk breakdown structure of the possible risks and mitigations to consider whenimplementing 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 ProgramPartner 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 planLeo de Sousa Page 6
  7. 7. IST 725 Case Study 2 – Planning a Secure Partner Portal Mar 12, 2012 ConclusionResearch organizations looking for efficiencies and cost savings seek to build trusted,collaborative relationships with other organizations. Confidentiality, integrity and availabilityare the key enterprise security goals that must be addressed and planned for by enterprisesecurity architecture. They become even more important when we share network access,business processes and information via a partner portal with external partners. Collaboratingcompanies should focus on planning and security around the data and information layer with theexponential growth of digital information in their enterprises. There are four key EnterpriseSecurity 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 allpartners to understand the risk and benefits of participating and the impacts on theirorganization’s Enterprise Security Architecture. The table below shows the impacts on eachcompany’s future state enterprise security architecture at a high level for planning a securepartner 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 ArchitectureCompany 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 dataCompany 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 workLeo de Sousa Page 7
  8. 8. IST 725 Case Study 2 – Planning a Secure Partner Portal Mar 12, 2012 ReferencesArconati, 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_504Basney, 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-portalCANARIE. (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-frameworkInternet2. (2012, Feb 17). Building Identity Trust Federations. Retrieved from US Trust Federations: https://spaces.internet2.edu/display/USFederations/Building+Identity+Trust+FederationsShuey, R. (2009, Feb 18). Federations and InCommon. University Park, PA, USA.Leo de Sousa Page 8

×