User:Mstone/Commentaries/Infrastructure 1: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
(wording) |
||
(7 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
Here are some proposed requirements for a software system and procedure for communal maintenance of infrastructure: |
Here are some proposed requirements for a software system and procedure for communal maintenance of infrastructure and of reference documentation describing that infrastructure: |
||
; Ease of Maintenance |
|||
: -- ''Reason: (locally) reversing entropy is hard enough as it stands.'' |
|||
; Data integrity |
; Data integrity |
||
: It should be possible to verify the integrity of reference documentation on an independent system booted from read-only media. |
: It should be possible to verify the integrity of reference documentation on an independent system booted from read-only media. |
||
: -- ''Reason: |
: -- ''Reason: when you're concerned about a system, you need to diagnose it against a mental model and you need to know whether any secrets it contained are still secret. It's important to be able to trust your mental model and to know what those secrets were.'' |
||
; Timely access |
; Timely access |
||
Line 9: | Line 12: | ||
; Credential rotation |
; Credential rotation |
||
: When people leave the VIG, |
: When people leave the VIG, they should not be granted access to newly created secrets. |
||
: If people ever leave the VIG non-amicably, it should be possible to quickly update important secrets throughout the communal infrastructure. |
: If people ever leave the VIG non-amicably, it should be possible to quickly update important secrets throughout the communal infrastructure. |
||
: It should be easy to |
: It should be easy to offer new VIG members access to current secrets. |
||
; Publishability |
; Publishability |
||
: Secrets should be carefully separated from public knowledge (e.g. with encryption or quarantine) so that everything else can be published. |
: Secrets should be carefully separated from public knowledge (e.g. with encryption or quarantine) so that everything else can be published. |
||
; Audit trail |
|||
: It should be possible to study the work of fellow administrators. |
|||
: Depending on the threat model, audit logs may also be an important security status artifact. |
|||
; Written threat model |
|||
: Everyone deserves to be able to evaluate the risks of proposed changes against a common standard. |
Latest revision as of 02:58, 26 November 2008
Here are some proposed requirements for a software system and procedure for communal maintenance of infrastructure and of reference documentation describing that infrastructure:
- Ease of Maintenance
- -- Reason: (locally) reversing entropy is hard enough as it stands.
- Data integrity
- It should be possible to verify the integrity of reference documentation on an independent system booted from read-only media.
- -- Reason: when you're concerned about a system, you need to diagnose it against a mental model and you need to know whether any secrets it contained are still secret. It's important to be able to trust your mental model and to know what those secrets were.
- Timely access
- Failures of otherwise critical pieces of infrastructure should not inhibit timely read or write access to the reference documentation.
- Credential rotation
- When people leave the VIG, they should not be granted access to newly created secrets.
- If people ever leave the VIG non-amicably, it should be possible to quickly update important secrets throughout the communal infrastructure.
- It should be easy to offer new VIG members access to current secrets.
- Publishability
- Secrets should be carefully separated from public knowledge (e.g. with encryption or quarantine) so that everything else can be published.
- Audit trail
- It should be possible to study the work of fellow administrators.
- Depending on the threat model, audit logs may also be an important security status artifact.
- Written threat model
- Everyone deserves to be able to evaluate the risks of proposed changes against a common standard.