802
edits
Changes
Jump to navigation
Jump to search
Annex D: Secure Enterprise Systems Administration (view source)
Revision as of 08:39, 7 April 2021
, 08:39, 7 April 2021Created page with "<div class="center"><div style="float: right; z-index: 10; position: absolute; right: 0; top: 1;">File:JoinusonGCconnex.png|link=http://gcconnex.gc.ca/groups/profile/2785549..."
<div class="center"><div style="float: right; z-index: 10; position: absolute; right: 0; top: 1;">[[File:JoinusonGCconnex.png|link=http://gcconnex.gc.ca/groups/profile/2785549/gc-enterprise-security-architecture-gc-esa]]<br />[[File:ESAcontactus.png|link=mailto:ZZTBSCYBERS@tbs-sct.gc.ca]]</div>[[File:GOC ESA.jpg|center|link=http://www.gcpedia.gc.ca/wiki/Government_of_Canada_Enterprise_Security_Architecture_(ESA)_Program]] <div class="center">
{| style="border: 2px solid #000000; border-image: none;" width="1000px"
|-
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="175px" | [[Government of Canada Enterprise Security Architecture (ESA) Program|ESA Program Overview]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="125px" | [[ESA Backgrounder (Strategy)|ESA Foundation]]
! style="background: #C495F0; color: black" width="20%" scope="col" " width="125px" | [[ESA Requirements|ESA Artifacts]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="125px" | [[ESA Initiatives|ESA Initiatives]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="125px" | [[ ESA Tools and Templates]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="125px" | [[GC ESA Artifact Repository|ESA Reference Materials]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="100px" | [[ESA Glossary| Glossary]]
|}
{| style="border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1000px>"
|-
! style="background: #c2c2fa; color: black" width="25%" scope="col" " width="150px" | [[ESA Requirements]]
! style="background: #9a9af8; color: black" width="25%" scope="col" " width="225px" | [[ESA Security ConOps|ESA Concept of Operations]]
! style="background: #c2c2fa; color: black" width="25%" scope="col" " width="225px" | [[ESA Architecture Description Document (ESADD)|ESA Description Document]]
! style="background: #c2c2fa; color: black" width="25%" scope="col" " width="250px" | [[ESA Pattern Diagram Repository]]
|}
{| style="border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right:#000000 2px solid" width="1000px>"
|-
! style="background: #d7d7d7; color: black" width="14%" scope="col" colspan="2" | [[Annex A: Data Loss Prevention]]
! style="background: #d7d7d7; color: black" width="14%" scope="col" colspan="2" | [[Annex B: Cloud Security]]
! style="background: #d7d7d7; color: black" width="14%" scope="col" colspan="2" | [[Annex C: Secure Enterprise Application Delivery]]
! style="background: #969696; color: black" width="14%" scope="col" colspan="3" | [[Annex D: Secure Enterprise Systems Administration]]
! style="background: #d7d7d7; color: black" width="14%" scope="col" colspan="3" | [[Annex E: Vulnerability Management System]]
|}
</div></div>
{{TOCright}}
== Overview ==
[[File:Risks of Unsecured Privileged Identities (Lieberman Software).PNG|left|thumb|503x503px|Risks of Unsecured Privileged Identities (Lieberman Software)]]
A number of recent cyber attacks have exploited vulnerabilities in government IT management capabilities to exfiltrated sensitive information. These include the Canadian National Research Council (NRC) data breach in 2014 and the loss of personnel data by the US Office of Personnel Management (OPM) in April 2015. These attacks, together with those on commercial businesses (for example, Target in 2013), have motivated the GC to assess and improve the security of its IT management capabilities. These improvements encompass the people, process, and technical aspects of IT management.
Currently within the GC, management workstations are used for routine work and host email, web browsers, and other applications. The presence of these applications creates vulnerabilities that increase the risk of attackers gaining unauthorized access to privileged management functions. In particular, these applications may enable installation of malware that monitors subsequent execution of management applications and gather administrative credentials. Unauthorized access to administrative privileges has the potential to destroy the integrity of GC IT/IS resources, divulge sensitive information, violate the privacy of GC workers and Canadian citizens, and generally damage the reputation of the GC. It is desirable for client-side management applications to be hosted on dedicated management workstations, but practical considerations may require secure coexistence of management capabilities with production capabilities.
When credentials are obtained by an attacker, they allow the attacker to use the privileges associated with the credentials. If the credentials have more privileges than necessary for the legitimate credential owner to perform his or her assigned duties, this simply provides more opportunity for an attacker to cause damage. In particular, obtaining administrative privileges can allow an attacker to take complete control of a system that is then used to attack other systems. Centralized single sign-on (SSO) capabilities can make the situation worse as a single credential provides an attacker with access to multiple systems.
The image on the left shows some of the functions that can be performed anonymously by users with access to unsecured privileged user and service accounts. Lieberman Software observes in its Adaptive Privilege Management Executive Overview that, "unlike end users' personal login credentials, privileged credentials are not systematically managed in most organizations. This means that in all likelihood:
* Your organization has no comprehensive, up-to-date list of privileged logins that exist on your network
* You have no verifiable record of which privileged login credentials are known to different individuals
* You have no proof of who has used these privileged logins to gain access to any of your IT resources, when, and for what purpose
* There is no way to verify that each of your privileged account passwords are cryptographically strong, sufficiently unique, and changed often enough to be secure
* You have no complete list of privileged account passwords stored within your applications and no way of knowing which in-house and vendor personnel have knowledge of these credentials that might be used to access sensitive information."
<br>
For more information, please read the [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]] document.
<br>
== Operational Needs ==
The operational needs are divided into People and Process objectives and Technology objectives. The People and Process objectives identify current best practices that should already be in use, but it may be necessary to develop policy instruments and awareness training to reinforce the need to follow these practices. The Technology objectives are more forward-looking and are likely to require planning and investment to achieve over a period of time. The operational needs are summarized below and discussed in detail in the [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration v0.8.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]] document.
=== ''People and Process Objectives'' ===
Development of new policy instruments or updating of existing policy instruments that reduce vulnerability to privilege escalation attacks:
* Disabling of obsolete accounts and removal of excess privileges
* Improper use of privileged accounts for day-to-day non-administrative work activities
* Generation of strong administrative passwords and protection of passwords
* Establishment of periodic security awareness training for administrators
* Reduction of shared administrative accounts where allowed by technology
* Third party (vendors, contractors, etc.) administrative access to managed resources
=== ''Technology Objectives'' ===
Development of new technologies or updating of existing technologies and associated designs that address:
* Isolation of management interfaces from production networks to:
** Reduce the risk of vulnerable management interfaces being exploited to escalate privileges
** Protect against the effects of a denial-of-service attack on the production network to maintain visibility into the state of the IT/IS infrastructure and respond to incidents, and
** Reduce the risk of unauthorized modification (tampering) of management data that is not cryptographically protected
* Implementation of fine-grained privilege mechanisms that enable effective configuration of "least privilege" and "separation of duties"
* Security of local management capabilities that allow departments and other GC organizations to manage specialized resources that are not managed by SSC (e.g. back office applications)
* Security of remote access to management interfaces on managed resource for:
** Updating of configuration files and settings
** Manual installation of software
** Troubleshooting (help desk)
** Manual monitoring and forensics
* Support for secure machine-to-machine access by management servers to management interfaces on managed resources for:
** Automated installation of software, software updates, malware detection signatures, host-based protection signatures, and other policy information
** Receipt of audit events and other security information
<br>
For more information, please read the [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]] document.
<br>
== Assumptions and Constraints ==
The following assumptions and constraints are used in the [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]] document:
=== ''Assumptions'' ===
* Management responsibility for resources in shared data centres is split between SSC and partners
* Remote access is required for on-call and contract (outsourced) system administrators and support staff
*Remote access is required by vendors to update and troubleshoot equipment
*The GC uses out-of-band management interfaces for unattended ("lights-out") management of servers in data centres
*The GC has separate privileged management interfaces to GC services hosted by public and outsourced private or community cloud providers
*Managed resources (servers, network appliance, etc.) that do not support two-factor authentication will not be replaced
*The proposed concepts must encompass both GC enterprise-managed (e.g. SSC) and non GC enterprise-managed (e.g. the many small organizations) resources
=== ''Constraints'' ===
* The proposed solution must:
*# Balance security, cost, and usability
*# Be compatible with legacy systems, and
*# Must comply with existing laws, regulations, and policy instruments
<br>
For more information, please read the [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]] document.
<br>
== System Description ==
Technology works in conjunction with operational procedures (people and process) to protect GC IT/IS resources. Operational procedures ensure that the technology is operated and maintained in a secure operational state and performs its mission. Therefore, it is critical from a security standpoint that the people and processes are given equal consideration to the technology implementation.
=== Security Considerations ===
This section provides background information and identifies specific topics relevant to developing a plan for improving the security of administrative access.
The following sections, which can be expanded by clicking on 'Expand' on the far right, discuss the people and process considerations and technology considerations.
<br>
<div class="toccolours mw-collapsible mw-collapsed" style="width:100%">
'''People and Process Considerations''' <div class="mw-collapsible-content">
---- {{:Security Considerations: People and Process}} </div></div>
<div class="toccolours mw-collapsible mw-collapsed" style="width:100%">
'''Technology Considerations''' <div class="mw-collapsible-content">
---- {{:Security Considerations: Technology}} </div></div>
<br>
For more information, please read the [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]] document.
<br>
== Recommendations ==
This section makes a specific set of technical and people & process recommendations. Each recommendation should be evaluated based on risk and benefit.
An implementation strategy (IS) should be developed that defines a phased implementation of the recommendations. It is recommended that the GC develop a model that allows incremental improvements to be recorded on a scorecard. For an example of such a model, please read the [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration v0.8.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]] document.
=== ''Technical Recommendations'' ===
# Create a segregated management network that isolates management interfaces from production traffic. Evaluate physical and logical separation approaches. At minimum, ensure that server management interfaces (particularly IPMI) are not accessible from production networks.
# Identify processes that are continuously running, or can be launched, with administrative privileges and ensure that they are only accessible through out-of-band management interfaces connected to the management network. If there is no alternative to exposing privileged processes to the production network, configure firewall policy and use techniques, such as Private VLANs to limit access to those processes.
# Implement techniques that enable fine-grained escalation of privileges by software process, such that: (1) The user invoking the process is authorized to do so, (2) The process is granted escalated privileges for the minimum time necessary and not for the entire duration of its execution, and (3) The escalated privileges are the minimum required for the process to perform its defined function. Evaluate the use of PAM products that provide SUPM features.
# Deploy PAM, PSM, and SAPM solutions that mediate access to administrative accounts. These solutions should provide two-factor authentication, full session auditing, "four-eyes" real-time monitoring of session, and session approval capabilities. The ability to update managed resource authentication secrets automatically, either periodically or after each session, and to assign privileges to accounts dynamically, should also be considered in the evaluation criteria.
# Identify applications that rely on locally configured authentication secrets (passwords, shared keys, etc.) and evaluate integration with PAM/AAPM products to obtain authentication secrets dynamically from a centrally protected credential vault.
# Characterize classes of administrators, their needs for management and production workstations, and the threats to the GC Enterprise IT/IS infrastructure posed by each class of administrator. Deploy management access networks with network access control mechanisms (none, VPN, desktop/application virtualization, etc.) commensurate with the identified threat level. Evaluate which PAM solutions should be accessible to types of administrator based on risk.
# Define and implement a set of approved management workstation configurations. Dedicated and dual-boot solutions are the easiest and most secure. Consider virtualization and thin client technologies if simultaneous access to management and production environments is a compelling need for certain classes of administrator.
# Evaluate management access approaches to public cloud services used by the GC. Most public cloud services likely operate in a similar manner, but each cloud service will have unique characteristics that must be considered.
=== ''People and Process Recommendations'' ===
# Develop policies and processes that address:
#* Account auditing, including the following:
#** Disabling or deletion of orphan and other unnecessary accounts
#** Removal of excess privileges based on the account holder's assigned responsibilities
#** Creation of different accounts (with different credentials) for routine and administrative work
#** Changing default administrative passwords
#** Elimination of shared administrative accounts where technically possible
#* Approval of administrative access, issuance, and management of administrative credentialsRecording, storage, and analysis of administrative sessions compatible with Canadian privacy laws and regulations.
# Conduct independent audits (by a GC agency or an independent specialist auditor) on a schedule and unscheduled basis to verify compliance with policies and processes developed in support of secure administration.
# Review and, where necessary, improve security awareness training for administrators, emphasizing use of non-privileged accounts for routine work and protection of administrative tokens and credentials.
# Develop a security control profile to secure administration. The profile should include high integrity controls and may include high availability controls.
# Develop a security authorization approach that considers GC-wide community risks to the management and production domains. In extreme cases, this should result in departments being disconnected from the rest of the GC Enterprise IT/IS infrastructure if they fail to reasonably comply with technical and people & process policy instruments that result from secure administration recommendations and other recommendations developed as part of the ESA initiative.
<br>
For more information about technology and people & process recommendations, please read the [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]] document.
<br>
== References ==
* [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]]
* [http://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=12328 Operational Security Standard: Management of Information Technology Security]
[[Category:Government of Canada Enterprise Security Architecture (ESA) Program]]
[[Category:Enterprise Security Architecture]]
{| style="border: 2px solid #000000; border-image: none;" width="1000px"
|-
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="175px" | [[Government of Canada Enterprise Security Architecture (ESA) Program|ESA Program Overview]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="125px" | [[ESA Backgrounder (Strategy)|ESA Foundation]]
! style="background: #C495F0; color: black" width="20%" scope="col" " width="125px" | [[ESA Requirements|ESA Artifacts]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="125px" | [[ESA Initiatives|ESA Initiatives]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="125px" | [[ ESA Tools and Templates]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="125px" | [[GC ESA Artifact Repository|ESA Reference Materials]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="100px" | [[ESA Glossary| Glossary]]
|}
{| style="border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1000px>"
|-
! style="background: #c2c2fa; color: black" width="25%" scope="col" " width="150px" | [[ESA Requirements]]
! style="background: #9a9af8; color: black" width="25%" scope="col" " width="225px" | [[ESA Security ConOps|ESA Concept of Operations]]
! style="background: #c2c2fa; color: black" width="25%" scope="col" " width="225px" | [[ESA Architecture Description Document (ESADD)|ESA Description Document]]
! style="background: #c2c2fa; color: black" width="25%" scope="col" " width="250px" | [[ESA Pattern Diagram Repository]]
|}
{| style="border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right:#000000 2px solid" width="1000px>"
|-
! style="background: #d7d7d7; color: black" width="14%" scope="col" colspan="2" | [[Annex A: Data Loss Prevention]]
! style="background: #d7d7d7; color: black" width="14%" scope="col" colspan="2" | [[Annex B: Cloud Security]]
! style="background: #d7d7d7; color: black" width="14%" scope="col" colspan="2" | [[Annex C: Secure Enterprise Application Delivery]]
! style="background: #969696; color: black" width="14%" scope="col" colspan="3" | [[Annex D: Secure Enterprise Systems Administration]]
! style="background: #d7d7d7; color: black" width="14%" scope="col" colspan="3" | [[Annex E: Vulnerability Management System]]
|}
</div></div>
{{TOCright}}
== Overview ==
[[File:Risks of Unsecured Privileged Identities (Lieberman Software).PNG|left|thumb|503x503px|Risks of Unsecured Privileged Identities (Lieberman Software)]]
A number of recent cyber attacks have exploited vulnerabilities in government IT management capabilities to exfiltrated sensitive information. These include the Canadian National Research Council (NRC) data breach in 2014 and the loss of personnel data by the US Office of Personnel Management (OPM) in April 2015. These attacks, together with those on commercial businesses (for example, Target in 2013), have motivated the GC to assess and improve the security of its IT management capabilities. These improvements encompass the people, process, and technical aspects of IT management.
Currently within the GC, management workstations are used for routine work and host email, web browsers, and other applications. The presence of these applications creates vulnerabilities that increase the risk of attackers gaining unauthorized access to privileged management functions. In particular, these applications may enable installation of malware that monitors subsequent execution of management applications and gather administrative credentials. Unauthorized access to administrative privileges has the potential to destroy the integrity of GC IT/IS resources, divulge sensitive information, violate the privacy of GC workers and Canadian citizens, and generally damage the reputation of the GC. It is desirable for client-side management applications to be hosted on dedicated management workstations, but practical considerations may require secure coexistence of management capabilities with production capabilities.
When credentials are obtained by an attacker, they allow the attacker to use the privileges associated with the credentials. If the credentials have more privileges than necessary for the legitimate credential owner to perform his or her assigned duties, this simply provides more opportunity for an attacker to cause damage. In particular, obtaining administrative privileges can allow an attacker to take complete control of a system that is then used to attack other systems. Centralized single sign-on (SSO) capabilities can make the situation worse as a single credential provides an attacker with access to multiple systems.
The image on the left shows some of the functions that can be performed anonymously by users with access to unsecured privileged user and service accounts. Lieberman Software observes in its Adaptive Privilege Management Executive Overview that, "unlike end users' personal login credentials, privileged credentials are not systematically managed in most organizations. This means that in all likelihood:
* Your organization has no comprehensive, up-to-date list of privileged logins that exist on your network
* You have no verifiable record of which privileged login credentials are known to different individuals
* You have no proof of who has used these privileged logins to gain access to any of your IT resources, when, and for what purpose
* There is no way to verify that each of your privileged account passwords are cryptographically strong, sufficiently unique, and changed often enough to be secure
* You have no complete list of privileged account passwords stored within your applications and no way of knowing which in-house and vendor personnel have knowledge of these credentials that might be used to access sensitive information."
<br>
For more information, please read the [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]] document.
<br>
== Operational Needs ==
The operational needs are divided into People and Process objectives and Technology objectives. The People and Process objectives identify current best practices that should already be in use, but it may be necessary to develop policy instruments and awareness training to reinforce the need to follow these practices. The Technology objectives are more forward-looking and are likely to require planning and investment to achieve over a period of time. The operational needs are summarized below and discussed in detail in the [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration v0.8.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]] document.
=== ''People and Process Objectives'' ===
Development of new policy instruments or updating of existing policy instruments that reduce vulnerability to privilege escalation attacks:
* Disabling of obsolete accounts and removal of excess privileges
* Improper use of privileged accounts for day-to-day non-administrative work activities
* Generation of strong administrative passwords and protection of passwords
* Establishment of periodic security awareness training for administrators
* Reduction of shared administrative accounts where allowed by technology
* Third party (vendors, contractors, etc.) administrative access to managed resources
=== ''Technology Objectives'' ===
Development of new technologies or updating of existing technologies and associated designs that address:
* Isolation of management interfaces from production networks to:
** Reduce the risk of vulnerable management interfaces being exploited to escalate privileges
** Protect against the effects of a denial-of-service attack on the production network to maintain visibility into the state of the IT/IS infrastructure and respond to incidents, and
** Reduce the risk of unauthorized modification (tampering) of management data that is not cryptographically protected
* Implementation of fine-grained privilege mechanisms that enable effective configuration of "least privilege" and "separation of duties"
* Security of local management capabilities that allow departments and other GC organizations to manage specialized resources that are not managed by SSC (e.g. back office applications)
* Security of remote access to management interfaces on managed resource for:
** Updating of configuration files and settings
** Manual installation of software
** Troubleshooting (help desk)
** Manual monitoring and forensics
* Support for secure machine-to-machine access by management servers to management interfaces on managed resources for:
** Automated installation of software, software updates, malware detection signatures, host-based protection signatures, and other policy information
** Receipt of audit events and other security information
<br>
For more information, please read the [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]] document.
<br>
== Assumptions and Constraints ==
The following assumptions and constraints are used in the [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]] document:
=== ''Assumptions'' ===
* Management responsibility for resources in shared data centres is split between SSC and partners
* Remote access is required for on-call and contract (outsourced) system administrators and support staff
*Remote access is required by vendors to update and troubleshoot equipment
*The GC uses out-of-band management interfaces for unattended ("lights-out") management of servers in data centres
*The GC has separate privileged management interfaces to GC services hosted by public and outsourced private or community cloud providers
*Managed resources (servers, network appliance, etc.) that do not support two-factor authentication will not be replaced
*The proposed concepts must encompass both GC enterprise-managed (e.g. SSC) and non GC enterprise-managed (e.g. the many small organizations) resources
=== ''Constraints'' ===
* The proposed solution must:
*# Balance security, cost, and usability
*# Be compatible with legacy systems, and
*# Must comply with existing laws, regulations, and policy instruments
<br>
For more information, please read the [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]] document.
<br>
== System Description ==
Technology works in conjunction with operational procedures (people and process) to protect GC IT/IS resources. Operational procedures ensure that the technology is operated and maintained in a secure operational state and performs its mission. Therefore, it is critical from a security standpoint that the people and processes are given equal consideration to the technology implementation.
=== Security Considerations ===
This section provides background information and identifies specific topics relevant to developing a plan for improving the security of administrative access.
The following sections, which can be expanded by clicking on 'Expand' on the far right, discuss the people and process considerations and technology considerations.
<br>
<div class="toccolours mw-collapsible mw-collapsed" style="width:100%">
'''People and Process Considerations''' <div class="mw-collapsible-content">
---- {{:Security Considerations: People and Process}} </div></div>
<div class="toccolours mw-collapsible mw-collapsed" style="width:100%">
'''Technology Considerations''' <div class="mw-collapsible-content">
---- {{:Security Considerations: Technology}} </div></div>
<br>
For more information, please read the [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]] document.
<br>
== Recommendations ==
This section makes a specific set of technical and people & process recommendations. Each recommendation should be evaluated based on risk and benefit.
An implementation strategy (IS) should be developed that defines a phased implementation of the recommendations. It is recommended that the GC develop a model that allows incremental improvements to be recorded on a scorecard. For an example of such a model, please read the [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration v0.8.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]] document.
=== ''Technical Recommendations'' ===
# Create a segregated management network that isolates management interfaces from production traffic. Evaluate physical and logical separation approaches. At minimum, ensure that server management interfaces (particularly IPMI) are not accessible from production networks.
# Identify processes that are continuously running, or can be launched, with administrative privileges and ensure that they are only accessible through out-of-band management interfaces connected to the management network. If there is no alternative to exposing privileged processes to the production network, configure firewall policy and use techniques, such as Private VLANs to limit access to those processes.
# Implement techniques that enable fine-grained escalation of privileges by software process, such that: (1) The user invoking the process is authorized to do so, (2) The process is granted escalated privileges for the minimum time necessary and not for the entire duration of its execution, and (3) The escalated privileges are the minimum required for the process to perform its defined function. Evaluate the use of PAM products that provide SUPM features.
# Deploy PAM, PSM, and SAPM solutions that mediate access to administrative accounts. These solutions should provide two-factor authentication, full session auditing, "four-eyes" real-time monitoring of session, and session approval capabilities. The ability to update managed resource authentication secrets automatically, either periodically or after each session, and to assign privileges to accounts dynamically, should also be considered in the evaluation criteria.
# Identify applications that rely on locally configured authentication secrets (passwords, shared keys, etc.) and evaluate integration with PAM/AAPM products to obtain authentication secrets dynamically from a centrally protected credential vault.
# Characterize classes of administrators, their needs for management and production workstations, and the threats to the GC Enterprise IT/IS infrastructure posed by each class of administrator. Deploy management access networks with network access control mechanisms (none, VPN, desktop/application virtualization, etc.) commensurate with the identified threat level. Evaluate which PAM solutions should be accessible to types of administrator based on risk.
# Define and implement a set of approved management workstation configurations. Dedicated and dual-boot solutions are the easiest and most secure. Consider virtualization and thin client technologies if simultaneous access to management and production environments is a compelling need for certain classes of administrator.
# Evaluate management access approaches to public cloud services used by the GC. Most public cloud services likely operate in a similar manner, but each cloud service will have unique characteristics that must be considered.
=== ''People and Process Recommendations'' ===
# Develop policies and processes that address:
#* Account auditing, including the following:
#** Disabling or deletion of orphan and other unnecessary accounts
#** Removal of excess privileges based on the account holder's assigned responsibilities
#** Creation of different accounts (with different credentials) for routine and administrative work
#** Changing default administrative passwords
#** Elimination of shared administrative accounts where technically possible
#* Approval of administrative access, issuance, and management of administrative credentialsRecording, storage, and analysis of administrative sessions compatible with Canadian privacy laws and regulations.
# Conduct independent audits (by a GC agency or an independent specialist auditor) on a schedule and unscheduled basis to verify compliance with policies and processes developed in support of secure administration.
# Review and, where necessary, improve security awareness training for administrators, emphasizing use of non-privileged accounts for routine work and protection of administrative tokens and credentials.
# Develop a security control profile to secure administration. The profile should include high integrity controls and may include high availability controls.
# Develop a security authorization approach that considers GC-wide community risks to the management and production domains. In extreme cases, this should result in departments being disconnected from the rest of the GC Enterprise IT/IS infrastructure if they fail to reasonably comply with technical and people & process policy instruments that result from secure administration recommendations and other recommendations developed as part of the ESA initiative.
<br>
For more information about technology and people & process recommendations, please read the [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]] document.
<br>
== References ==
* [[Media:GC ESA ConOps - ANNEX D Secure Enterprise Systems Administration.pdf|GC ESA ConOps Annex D: Secure Enterprise Systems Administration]]
* [http://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=12328 Operational Security Standard: Management of Information Technology Security]
[[Category:Government of Canada Enterprise Security Architecture (ESA) Program]]
[[Category:Enterprise Security Architecture]]
