User:Mstone/Commentaries/Infrastructure 1: Difference between revisions

From OLPC
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: if you're concerned about a system then you probably don't know whether any secrets it contained are still secret.''
: -- ''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, it should be easy to remove their access to secrets created after their exit.
: 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 add give new VIG members access to current secrets.
: 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.