- Email: [email protected]
Ensuring consistent security implementation within a distributed and federated environment
FEDERATED SECURITY
Ensuring consistent security implementation within a distributed and federated environment Paul Stephenson, CISSP, Siemens Insight Consulting Making sure partners in a federation all pull their weight to ensure no links in the security chain are broken needs strict code of conduct. Paul Stephenson puts forwards guidelines to ensure partners have to pull up their socks.
Introduction
When a group of companies or autonomous business units combine for a common purpose, such as conducting electronic commerce, collaborating on a research project, or simply to enjoy the economies-of-scale benefits of a shared infrastructure, they form a federation. Unlike a homogenous organization, in which security is controlled via a centrally-managed group, the federated partners are responsible for the security standards and management within their own environments And it is this autonomy of security management that introduces a number of issues and challenges to the overall security of the interconnected environment. The term “federated security” is receiving considerable attention, not least through the de-perimeterisation initiatives of the Jericho Forum, whose aim is to enable organizations to interconnect and interoperate using a trust model based on federated security and controls applied at the application and data-level. Similarly, the development of standards such as Security Assertion Markup Language (SAML) and WSSecurity are generating confidence in the ability to enable trusted, distributed and federated security. Much of this discussion of federated security has been focused on the technical ability to establish trust relationships for the purpose of devolved and delegated identity management; for example, to allow 12
Computer Fraud & Security
one organization (an identity provider) to manage its own end-users in such a way that a service provider can trust the credentials of a user attempting to access its services, and the user can benefit from increased mobility and single sign-on. However, there is a much wider security issue that must be addressed in a distributed and federated environment: despite the technical ability to interlink systems and to establish identity trust relationships, how can the individual partners of the federation be assured that the other partners have implemented adequate security standards and management practices such that they are not exposed to an unnecessary risk via the interconnection? It is the purpose of this paper to identify the wider security challenges of a federated environment and to offer options for addressing these challenges
Security issues in a distributed and federated environment
A federation is formed when two or more business units combine and interconnect for a common, shared purpose. Examples of federated environments include: 1 Large, multinational organizations, in which the in-country sales forces need to be managed locally, but need to connect to corporate financial reporting systems
2 organizations resulting from merger and acquisition activity in which administrative autonomy is retained in each business unit for political, cultural, organizational or financial reasons. 3 Temporary business partnerships established for the duration of an engineering or research project, in which the project members need to use common document storage, reporting and project management systems. 4 Multiple government departments combining to share IT resources. In each of these examples, there is a requirement for shared access to some services within the federated environment and, for those non-shared services, the individual partners to maintain and operate their own internal IT and computing infrastructures. In a single, homogenous and centrally-managed organization, the security of the IT environment is defined in terms of corporate policies and standards, and implemented via the security management organization. In such a scenario, there is a standardised approach to: 1 Physical security. 2 Data classification. 3 Access and authorization. 4 User and privilege management. 5 System hardening and assurance standards. 6 Incident management. 7 Vulnerability assessment and risk management. 8 Patching and system upgrades. 9 Policy enforcement. Connections between the corporate environment and the outside world can be controlled via centrally-managed gateways that enforce policies in relation to Internet use, email and Web content scanning, remote access authentication and inbound connections to Web services. In a federated environment, each partner will have their own security policies and standards and will manage their own security environment and, whilst these controls may be adequate within each of the partner environments, the problems arise when the partner organizations November 2006
FEDERATED SECURITY are linked together. If, for example, the federation is created so that Partner A is allowed to access information held on a system running within Partner B’s network then, technically, a trust relationship could be established such that Partner B accepted the credentials of users connecting from Partner A’s environment; this could be achieved using federated identity management systems, uni- or bi-directional Active Directory Forest trusts, Kerberos, PKI etc. But this is only part of the picture; how does each partner obtain assurance that their environment is not jeopardised by the connection of a less secure partner to the federation? For example, each partner could be at risk from the following:
Inadequate user management processes The technology might permit the trusted relationship to work, but it is important to ensure that appropriate user administration is in place. For example, the WS-Security standard allows for interoperability of identity credentials but does not ensure that the identity management systems are being correctly managed Weak password controls, failure to suspend or remove accounts for users who have left the organization, the ability to define privileged accounts without appropriate authorization, or the lack of processes to validate user identity during account resets could all result in unauthorized users exploiting the trust relationship and connecting to systems in the partner network.
Malware and hacking protection If one partner does not implement tools on their clients and servers for the detection of virus, spyware, rootkit, hacking tools and other malware to the same degree as the rest of the federation, then they risk infecting systems on the interconnected network, particularly during zero-day attacks.
Remote access systems The federation members need to be assured of the security of any remote November 2006
access and mobility services that have been implemented by other partners The presence of weakly-authenticated RAS servers or unsecured wireless access points in one partner’s environment could lead to the compromise of systems elsewhere in the federation.
Onward connections to other networks Any onward connections (e.g. to other third-parties or to the Internet) from one partner, if inadequately protected, could exposure the rest of the environment to hacking attacks and unauthorised accesses from the external networks.
Insufficient traffic filters Without appropriate filters on the network connection to the federated environment, it is possible that one network could be the source of accidental or malicious denialof-service traffic against another network. Similarly, malicious users in one environment could attempt to connect to services or infrastructure in another environment using ports that could be blocked at the interconnection point.
Poor management of systems and networks A poorly-managed system or network (e.g. by untrained personnel) could have consequences within the wider environment. For example, ports might be accidentally opened on Internet firewalls, incorrect privileges could be assigned to a user, applications might attempt to connect to the wrong system, DNS pointers might redirect users to the wrong server, invalid network routes might be propagated to other partners in the network. These issues can be further compounded by geographical considerations in a widely-dispersed organization, since different countries may be subject to different legislation (e.g. related to encryption, data privacy, activity monitoring) and cultural issues. Geographical distance also complicates the ability to monitor and oversee the activities of federation partners.
Options for ensuring consistent security in a federated environment
As can be seen from the issues identified in the previous section, the challenge is not just about the technical aspects of transferring trusted user credentials from one domain to another, but about ensuring that each domain within the federation complies with a minimum set of security standards and security management practices so that their connection to the network does not unduly put the other partners at risk. It is not possible to define within this paper the security standards that should be implemented within all distributed and federated environments, since each environment will differ in terms of the type and classification of data that is being stored, processed and transmitted, and in the nature of the required interconnection between the various partners. However, the following highlevel approach to minimising the risks in federated environments is proposed:
Define a policy for the federated environment All good security begins with a policy. In the same way that a single business might define its security policy, a federation needs to define its security posture in terms of its business goals, legal and regulatory requirements, nature and sensitivity of the assets, and the perceived threats against which the federation needs to be protected. Some form of governing body must exist to define and maintain the overall security policy for the federation as a whole.
Define the rules for membership of the environment The policy will be used to derive the “rules of membership” for the federation, in terms of the security standards and management practices that must be implemented and enforced in order for the partner to connect to the federation. For example, and depending on the nature of the federation, these rules might cover: Computer Fraud & Security
13
FEDERATED SECURITY 1 Risk assessment and mitigation: assurance that the partner has conducted a risk assessment of their environment and that risks have been addressed. 2 Connectivity standards: how the partner connects to the federation and what traffic is permitted to flow via that connection. 3 Security standards and controls: countermeasures and technical standards that must be applied within the partner domain (e.g. anti-virus software, two-factor authentication for remote access, platform hardening standards). 4 Network controls: rules governing permitted onward connectivity from the partner network, which could potentially allow external parties to reach other federation partners (e.g. remote access connections, internet links, leased-lines to business partners, unsecured wireless access points). 5 Management processes: how the partner manages risk, security incidents, user accounts, privileged userids, log files, security alerts, compliance, vulnerabilities and patching. 6 Data handling: how the individual partners should handle data based upon its classification Compliance with the relevant data privacy laws will be required and the partners will also need to maintain the confidentiality and integrity of any data that is accessed within the federation (e.g. confidential data must not be communicated outside of the federation
unless non-disclosure agreements exist etc). 7 Personnel processes: minimal process requirements for vetting personnel and ensuring that personnel have the correct skills and/or qualifications for their role. 8 Documentation: definition of the information that must be maintained (e.g. internal policies and standards, technical design, security controls, processes, risk assessments etc). Each partner should agree to a legallybinding contract that requires them to comply with the federation’s membership rules. The membership conditions may also define penalties for breaking the rules and jeopardising the security of the rest of the environment. This could involve financial penalties or, simply, disconnection from the environment until any non-compliance issues have been rectified. Many of the above membership rules could be embodied in a single requirement for the participating members to sign-up to industry-recognized security management standards (e.g. BS7799:2).
Assess compliance with the rules prior to connection The policy will define how a partner must prove their compliance to the rules of membership before they are allowed to connect and receive services This could take the form of a self-assessment, a formal certification by an independent assessor, a legally-binding declaration of compliance or a combination of these
Once a partner’s compliance status has been confirmed, their connection to the environment can be permitted.
Monitor the ongoing compliance to the rules On an ongoing basis, and particularly as and when policies and standards are updated, it is necessary to review the compliance status of the partners Depending on the nature of the environment, partners may need to periodically attest to their continued compliance, or they may be formally re-assessed and recertified by an assessor. Furthermore, individual partners will be required to notify the federation’s governing body whenever they have changed, or plan to change, certain aspects of their environment. For example, adding new connections to external parties, outsourcing aspects of their IT management, fundamental technology changes etc. In high-sensitivity or low-trust environments, specific technical controls and management processes might be implemented to monitor and detect evidence of deviation from the rules of membership. For example, intrusion detection systems (IDS) located between partners could raise alerts if port-scanning activity is detected. This would be indicative of potential hacking activity from one partner to another and would be counter to the rules of membership. In such cases, the process would take appropriate action to stop such activity, possibly resulting in the temporary suspension of the partner from the network.
Example: The UK Government Secure Intranet (GSi) The GSi, which was developed by the Communications-Electronics Security Group (CESG) and the National Infrastructure Security Co-ordination Centre (NISCC), provides a range of services to the (mostly) public sector organizations that connect to it. In addition to the core services of e-mail relay, managed Internet gateway and directory services, GSi can be configured to provide closed communities of higher security dependent upon the requirements of the connecting organizations and the classification of data that is being handled In order to protect the GSi infrastructure and the connected networks, any organization requiring GSi services must be accredited to ensure that the appropriate security measures and processes are in place, and they must sign-up to the GSi Code of Conduct (CoCo). Once accredited, and connected to GSi, the connection will need to be periodically re-assessed and re-accredited
14
Computer Fraud & Security
Summary
In summary, the solution to the challenge of ensuring a consistent security implementation in a distributed and federated environment is the establishment of an agreed baseline of security configuration and security management standards Participating federation partners must actively subscribe, and adhere, to these standards and mechanisms must be in place to regularly assess and ensure ongoing compliance. November 2006
Ensuring consistent security implementation within a distributed and federated environment Paul Stephenson, CISSP, Siemens Insight Consulting Making sure partners in a federation all pull their weight to ensure no links in the security chain are broken needs strict code of conduct. Paul Stephenson puts forwards guidelines to ensure partners have to pull up their socks.
Introduction
When a group of companies or autonomous business units combine for a common purpose, such as conducting electronic commerce, collaborating on a research project, or simply to enjoy the economies-of-scale benefits of a shared infrastructure, they form a federation. Unlike a homogenous organization, in which security is controlled via a centrally-managed group, the federated partners are responsible for the security standards and management within their own environments And it is this autonomy of security management that introduces a number of issues and challenges to the overall security of the interconnected environment. The term “federated security” is receiving considerable attention, not least through the de-perimeterisation initiatives of the Jericho Forum, whose aim is to enable organizations to interconnect and interoperate using a trust model based on federated security and controls applied at the application and data-level. Similarly, the development of standards such as Security Assertion Markup Language (SAML) and WSSecurity are generating confidence in the ability to enable trusted, distributed and federated security. Much of this discussion of federated security has been focused on the technical ability to establish trust relationships for the purpose of devolved and delegated identity management; for example, to allow 12
Computer Fraud & Security
one organization (an identity provider) to manage its own end-users in such a way that a service provider can trust the credentials of a user attempting to access its services, and the user can benefit from increased mobility and single sign-on. However, there is a much wider security issue that must be addressed in a distributed and federated environment: despite the technical ability to interlink systems and to establish identity trust relationships, how can the individual partners of the federation be assured that the other partners have implemented adequate security standards and management practices such that they are not exposed to an unnecessary risk via the interconnection? It is the purpose of this paper to identify the wider security challenges of a federated environment and to offer options for addressing these challenges
Security issues in a distributed and federated environment
A federation is formed when two or more business units combine and interconnect for a common, shared purpose. Examples of federated environments include: 1 Large, multinational organizations, in which the in-country sales forces need to be managed locally, but need to connect to corporate financial reporting systems
2 organizations resulting from merger and acquisition activity in which administrative autonomy is retained in each business unit for political, cultural, organizational or financial reasons. 3 Temporary business partnerships established for the duration of an engineering or research project, in which the project members need to use common document storage, reporting and project management systems. 4 Multiple government departments combining to share IT resources. In each of these examples, there is a requirement for shared access to some services within the federated environment and, for those non-shared services, the individual partners to maintain and operate their own internal IT and computing infrastructures. In a single, homogenous and centrally-managed organization, the security of the IT environment is defined in terms of corporate policies and standards, and implemented via the security management organization. In such a scenario, there is a standardised approach to: 1 Physical security. 2 Data classification. 3 Access and authorization. 4 User and privilege management. 5 System hardening and assurance standards. 6 Incident management. 7 Vulnerability assessment and risk management. 8 Patching and system upgrades. 9 Policy enforcement. Connections between the corporate environment and the outside world can be controlled via centrally-managed gateways that enforce policies in relation to Internet use, email and Web content scanning, remote access authentication and inbound connections to Web services. In a federated environment, each partner will have their own security policies and standards and will manage their own security environment and, whilst these controls may be adequate within each of the partner environments, the problems arise when the partner organizations November 2006
FEDERATED SECURITY are linked together. If, for example, the federation is created so that Partner A is allowed to access information held on a system running within Partner B’s network then, technically, a trust relationship could be established such that Partner B accepted the credentials of users connecting from Partner A’s environment; this could be achieved using federated identity management systems, uni- or bi-directional Active Directory Forest trusts, Kerberos, PKI etc. But this is only part of the picture; how does each partner obtain assurance that their environment is not jeopardised by the connection of a less secure partner to the federation? For example, each partner could be at risk from the following:
Inadequate user management processes The technology might permit the trusted relationship to work, but it is important to ensure that appropriate user administration is in place. For example, the WS-Security standard allows for interoperability of identity credentials but does not ensure that the identity management systems are being correctly managed Weak password controls, failure to suspend or remove accounts for users who have left the organization, the ability to define privileged accounts without appropriate authorization, or the lack of processes to validate user identity during account resets could all result in unauthorized users exploiting the trust relationship and connecting to systems in the partner network.
Malware and hacking protection If one partner does not implement tools on their clients and servers for the detection of virus, spyware, rootkit, hacking tools and other malware to the same degree as the rest of the federation, then they risk infecting systems on the interconnected network, particularly during zero-day attacks.
Remote access systems The federation members need to be assured of the security of any remote November 2006
access and mobility services that have been implemented by other partners The presence of weakly-authenticated RAS servers or unsecured wireless access points in one partner’s environment could lead to the compromise of systems elsewhere in the federation.
Onward connections to other networks Any onward connections (e.g. to other third-parties or to the Internet) from one partner, if inadequately protected, could exposure the rest of the environment to hacking attacks and unauthorised accesses from the external networks.
Insufficient traffic filters Without appropriate filters on the network connection to the federated environment, it is possible that one network could be the source of accidental or malicious denialof-service traffic against another network. Similarly, malicious users in one environment could attempt to connect to services or infrastructure in another environment using ports that could be blocked at the interconnection point.
Poor management of systems and networks A poorly-managed system or network (e.g. by untrained personnel) could have consequences within the wider environment. For example, ports might be accidentally opened on Internet firewalls, incorrect privileges could be assigned to a user, applications might attempt to connect to the wrong system, DNS pointers might redirect users to the wrong server, invalid network routes might be propagated to other partners in the network. These issues can be further compounded by geographical considerations in a widely-dispersed organization, since different countries may be subject to different legislation (e.g. related to encryption, data privacy, activity monitoring) and cultural issues. Geographical distance also complicates the ability to monitor and oversee the activities of federation partners.
Options for ensuring consistent security in a federated environment
As can be seen from the issues identified in the previous section, the challenge is not just about the technical aspects of transferring trusted user credentials from one domain to another, but about ensuring that each domain within the federation complies with a minimum set of security standards and security management practices so that their connection to the network does not unduly put the other partners at risk. It is not possible to define within this paper the security standards that should be implemented within all distributed and federated environments, since each environment will differ in terms of the type and classification of data that is being stored, processed and transmitted, and in the nature of the required interconnection between the various partners. However, the following highlevel approach to minimising the risks in federated environments is proposed:
Define a policy for the federated environment All good security begins with a policy. In the same way that a single business might define its security policy, a federation needs to define its security posture in terms of its business goals, legal and regulatory requirements, nature and sensitivity of the assets, and the perceived threats against which the federation needs to be protected. Some form of governing body must exist to define and maintain the overall security policy for the federation as a whole.
Define the rules for membership of the environment The policy will be used to derive the “rules of membership” for the federation, in terms of the security standards and management practices that must be implemented and enforced in order for the partner to connect to the federation. For example, and depending on the nature of the federation, these rules might cover: Computer Fraud & Security
13
FEDERATED SECURITY 1 Risk assessment and mitigation: assurance that the partner has conducted a risk assessment of their environment and that risks have been addressed. 2 Connectivity standards: how the partner connects to the federation and what traffic is permitted to flow via that connection. 3 Security standards and controls: countermeasures and technical standards that must be applied within the partner domain (e.g. anti-virus software, two-factor authentication for remote access, platform hardening standards). 4 Network controls: rules governing permitted onward connectivity from the partner network, which could potentially allow external parties to reach other federation partners (e.g. remote access connections, internet links, leased-lines to business partners, unsecured wireless access points). 5 Management processes: how the partner manages risk, security incidents, user accounts, privileged userids, log files, security alerts, compliance, vulnerabilities and patching. 6 Data handling: how the individual partners should handle data based upon its classification Compliance with the relevant data privacy laws will be required and the partners will also need to maintain the confidentiality and integrity of any data that is accessed within the federation (e.g. confidential data must not be communicated outside of the federation
unless non-disclosure agreements exist etc). 7 Personnel processes: minimal process requirements for vetting personnel and ensuring that personnel have the correct skills and/or qualifications for their role. 8 Documentation: definition of the information that must be maintained (e.g. internal policies and standards, technical design, security controls, processes, risk assessments etc). Each partner should agree to a legallybinding contract that requires them to comply with the federation’s membership rules. The membership conditions may also define penalties for breaking the rules and jeopardising the security of the rest of the environment. This could involve financial penalties or, simply, disconnection from the environment until any non-compliance issues have been rectified. Many of the above membership rules could be embodied in a single requirement for the participating members to sign-up to industry-recognized security management standards (e.g. BS7799:2).
Assess compliance with the rules prior to connection The policy will define how a partner must prove their compliance to the rules of membership before they are allowed to connect and receive services This could take the form of a self-assessment, a formal certification by an independent assessor, a legally-binding declaration of compliance or a combination of these
Once a partner’s compliance status has been confirmed, their connection to the environment can be permitted.
Monitor the ongoing compliance to the rules On an ongoing basis, and particularly as and when policies and standards are updated, it is necessary to review the compliance status of the partners Depending on the nature of the environment, partners may need to periodically attest to their continued compliance, or they may be formally re-assessed and recertified by an assessor. Furthermore, individual partners will be required to notify the federation’s governing body whenever they have changed, or plan to change, certain aspects of their environment. For example, adding new connections to external parties, outsourcing aspects of their IT management, fundamental technology changes etc. In high-sensitivity or low-trust environments, specific technical controls and management processes might be implemented to monitor and detect evidence of deviation from the rules of membership. For example, intrusion detection systems (IDS) located between partners could raise alerts if port-scanning activity is detected. This would be indicative of potential hacking activity from one partner to another and would be counter to the rules of membership. In such cases, the process would take appropriate action to stop such activity, possibly resulting in the temporary suspension of the partner from the network.
Example: The UK Government Secure Intranet (GSi) The GSi, which was developed by the Communications-Electronics Security Group (CESG) and the National Infrastructure Security Co-ordination Centre (NISCC), provides a range of services to the (mostly) public sector organizations that connect to it. In addition to the core services of e-mail relay, managed Internet gateway and directory services, GSi can be configured to provide closed communities of higher security dependent upon the requirements of the connecting organizations and the classification of data that is being handled In order to protect the GSi infrastructure and the connected networks, any organization requiring GSi services must be accredited to ensure that the appropriate security measures and processes are in place, and they must sign-up to the GSi Code of Conduct (CoCo). Once accredited, and connected to GSi, the connection will need to be periodically re-assessed and re-accredited
14
Computer Fraud & Security
Summary
In summary, the solution to the challenge of ensuring a consistent security implementation in a distributed and federated environment is the establishment of an agreed baseline of security configuration and security management standards Participating federation partners must actively subscribe, and adhere, to these standards and mechanisms must be in place to regularly assess and ensure ongoing compliance. November 2006