Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Could standards around secrets be more explicit/helpful? #365

Open
1 task done
daniel-ac-martin opened this issue Jan 5, 2024 · 1 comment
Open
1 task done
Labels
Build release deploy Relates to BRD guild content content Secure development Relates to Security guild content Source management Relates to source management guild content

Comments

@daniel-ac-martin
Copy link
Contributor

Which content do you think should be reviewed?
SEGAS-00006: https://engineering.homeoffice.gov.uk/standards/managing-secrets/

Secrets MUST be generated in accordance with the Home Office Password Policy

Why do you think we should review this?
Is there a single standard policy that this refers to? If so, can we link to it?

If there is a standard policy, is it really up to scratch for production systems? e.g. Just because we would allow a user to have a 10-character long password that doesn't mean that a system to system password should be as short as that.

Also passwords are not the only secret, we could probably also do with some certificate standards.

Most likely these standards will need to be override-able by the local cyber/infosec people, but I still think we would benefit from a good default position.

Do you have a suggestion for how this could be improved?
"Passwords for system accounts should be randomly generated, and at least X characters long." (Where is X is quite a large number, but not so large as to break things. - 64?)

I've previously defined a certificate standard (for a specific system) along these lines:

It must expire in no more than two years
It must be at least 2048 bit in length
It must use the SHA256 hash algorithm

But that might need to be expanded upon and/or updated to be more stringent. (I defer to others on that.)

Please confirm the below

  • I have checked through the issues on the repository and don't think this has already been suggested
@edhamiltonHO
Copy link
Contributor

I've been talking to HOCS to find a good way to link to their internal policies and standards, not got a solution just yet but I'll DM a link across to you.

Would suggest that the requirement should be 'Secrets MUST be generated in line with HO standards' and then list (and preferably link) all the relevant standards for the different types of secrets

@jeff-horton-ho-sas jeff-horton-ho-sas added content Build release deploy Relates to BRD guild content Secure development Relates to Security guild content Source management Relates to source management guild content labels Jan 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Build release deploy Relates to BRD guild content content Secure development Relates to Security guild content Source management Relates to source management guild content
Projects
None yet
Development

No branches or pull requests

3 participants