security policy best practices #639
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Chr1st0ph3rTurn3r
requested changes
Nov 16, 2023
docs/sec_security_policy.md
Outdated
| ## Changing a Security Policy | ||
| Changing a security policy is a service impacting event as it is not possible to alter security keys and encryption ciphers for existing flows. Care must be taken to understand the blast radius of these changes. It goes without saying, but you must understand the security policy that needs to change and how it is being used for services and peer paths. If altering the global security policy that is used for all services, all traffic will be impacted. Sessions will not be terminated and reestablished; rather they will follow their own life cycle and the new policy will take effect for subsequent sessions. Changing a security policy should always be performed during a maintenance window after fully understanding the overall impact to the environment. Due to the fact that sessions are not terminated on security policy change, long-lived flows may need to be manually terminated in order for them to take on the properties of the new policy. | ||
|
|
||
| The best approach to making any change to a security policy is to create a new policy, with a new name, and apply it to the respective service, interface or adjacency. Doing so affords network administrators the ability to readily identify sessions that may not have adopted the new policy. |
There was a problem hiding this comment.
Suggested change
| The best approach to making any change to a security policy is to create a new policy, with a new name, and apply it to the respective service, interface or adjacency. Doing so affords network administrators the ability to readily identify sessions that may not have adopted the new policy. | |
| The best approach to making any change to a security policy is to create a new policy, with a new name, and apply it to the respective service, interface, or adjacency. This affords network administrators the ability to readily identify sessions that may not have adopted the new policy. |
docs/sec_security_policy.md
Outdated
| Completed in 0.12 seconds | ||
| ``` | ||
|
|
||
| Identify the sessions traversing the service, paying particular attention to those with an uptime greater than the time of the configuration change. If sessions exist with an uptime greater than the time of the `delete sessions` command, be sure to execute the `delete sessions` command again and confirm that they have been cleared. |
There was a problem hiding this comment.
Suggested change
| Identify the sessions traversing the service, paying particular attention to those with an uptime greater than the time of the configuration change. If sessions exist with an uptime greater than the time of the `delete sessions` command, be sure to execute the `delete sessions` command again and confirm that they have been cleared. | |
| Identify the sessions traversing the service, specifically looking for those with an uptime greater than the time of the configuration change. If sessions exist with an uptime greater than the time of the `delete sessions` command, execute the `delete sessions` command again and confirm that they have been cleared. |
docs/sec_security_policy.md
Outdated
|
|
||
| :::info | ||
| Note the output of:<br/> | ||
| `Forward Flows > Metadata Security Policy` which comes from the configuration `network-interface > adjacency > inter-router-security`, which is the metadata encryption policy<br/> |
There was a problem hiding this comment.
Suggested change
| `Forward Flows > Metadata Security Policy` which comes from the configuration `network-interface > adjacency > inter-router-security`, which is the metadata encryption policy<br/> | |
| - `Forward Flows > Metadata Security Policy`: This comes from the configuration of `network-interface > adjacency > inter-router-security`, which is the metadata encryption policy.<br/> |
docs/sec_security_policy.md
Outdated
| :::info | ||
| Note the output of:<br/> | ||
| `Forward Flows > Metadata Security Policy` which comes from the configuration `network-interface > adjacency > inter-router-security`, which is the metadata encryption policy<br/> | ||
| `Payload Security Policy` which comes from the configuration `service > security-policy`, which is the payload encryption policy<br/> |
There was a problem hiding this comment.
Suggested change
| `Payload Security Policy` which comes from the configuration `service > security-policy`, which is the payload encryption policy<br/> | |
| - `Payload Security Policy`: This comes from the configuration `service > security-policy`, which is the payload encryption policy.<br/> |
docs/sec_security_policy.md
Outdated
| Note the output of:<br/> | ||
| `Forward Flows > Metadata Security Policy` which comes from the configuration `network-interface > adjacency > inter-router-security`, which is the metadata encryption policy<br/> | ||
| `Payload Security Policy` which comes from the configuration `service > security-policy`, which is the payload encryption policy<br/> | ||
| `Reverse Flows > Decrypt Security Policy` which comes from the configuration `network-interface > inter-router-security`, which is the metadata decryption policy |
There was a problem hiding this comment.
Suggested change
| `Reverse Flows > Decrypt Security Policy` which comes from the configuration `network-interface > inter-router-security`, which is the metadata decryption policy | |
| - `Reverse Flows > Decrypt Security Policy`: This comes from the configuration `network-interface > inter-router-security`, which is the metadata decryption policy. |
|
@MichaelBaj I am having doubts that this procedure will work. This still needs to be tested.
|
ayungelson
reviewed
Dec 8, 2023
ayungelson
reviewed
Dec 8, 2023
docs/sec_security_policy.md
Outdated
| While the SSR affords you the ability to provision a unique security policy per service, in a typical hub-and-spoke topology, a single security policy can be shared among all services, with a separate security policy used for metadata encryption and authentication. | ||
| The SSR affords you the ability to provision a unique security policy per service. However, in a typical hub-and-spoke topology, a single security policy can be shared among all services, with a separate security policy used for metadata encryption and authentication. | ||
|
|
||
| HA interfaces between SSR nodes are directly connected between nodes and therefore pose no risk of interception. Given the additional computational cost of encrypting and decrypting traffic, it is recommended to not apply any security policy to `inter-node-security`. |
There was a problem hiding this comment.
it is recommended to not apply any security policy
I think you HAVE to apply a security policy - it's not an option to leave that blank - but I think we should recommend having the inter-node security policy to have encryption set to none, hmac set to disabled...
There was a problem hiding this comment.
yes, we will throw a validation error if you do not configure inter-node-security. Even if the router is not HA. In the field we typically create one that has encryption and hmac disabled for this purpose.
There was a problem hiding this comment.
Example:
security encrypt-hmac-disabled
name encrypt-hmac-disabled
description "Encryption and message authentication disabled"
hmac-cipher sha256
hmac-key (removed)
encryption-cipher aes-cbc-128
encryption-key (removed)
encryption-iv (removed)
encrypt false
hmac-mode disabled
adaptive-encryption false
exit
laneshields
reviewed
Dec 8, 2023
laneshields
reviewed
Dec 8, 2023
laneshields
reviewed
Dec 8, 2023
Chr1st0ph3rTurn3r
approved these changes
Dec 8, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.