User talk:Mstone/Commentaries/Infrastructure 1

Data integrity seems odd. Why is this necessary? Either the secrets work or they don't. It's not clear what level of integrity is being called for here. Is a git repo sufficient? I can verify that the current repo is a fast-forward of my local copy, and i can review the individual commits for sanity. Is that sufficient?

"Publishability" -- what about your previous concern that inappropriate information would be inadvertently disclosed?

I'd add the following two requirements:

Ease of use -- it be as easy as possible to maintain the documentation and keep it in sync.

Credential rotation -- it should be easy to add new people able to access the secrets in the VIG. CScott 18:12, 20 August 2008 (UTC)

Additional possible requirements

Traceability of actions

• Actions on documentation are generally traceable through use of wiki history (inherent to the tool) or other version control steps (to be defined based on formats/tools).

• Actions on the infrastructure being maintained traceable are by a variety of means, primarily logging. Elements of this are also inherent in wiki software (block/protection logs). In some cases (e.g. move logs) logging alone is sufficient without requirement for elevated privs (when combined with a wiki's high level of action visibility and reversibility). NB: wiki moves are only cited as an example of how traceability can substitute for control in the right circumstances.

Dual personality approach (with some logging)- Separation of UserX and AdminUserX accounts (segregation of privs belonging to single user).

In some multiuser environments, it may be desirable to enforce a separation between admin (Superman) identities and user (Clark Kent) identities so that most daily work is done with minimally priv'ed accounts. In Windows environments, this is desirable in part because of the common malware protection failure consequence (hijacked privs), although this is possibly less risky in Linux environment, there are other good arguments in favor of this simple measure.

It is generally well known (and usually spoken in hushed tones) that the greatest IT threats are internal (apropos hhardy's citation of "Quis custodiet ipsos custodes"), and since adminning users is all about granting access and privs, it is generally a matter of risk mitigation, not prevention. Some sort of logging is an excellent risk mitigation tool because most of us have reputations that we value (semi-pseudonymous or otherwise) and logging poses the risk of discovery and exposure of malfeasance or misfeasance.

Points to consider:

• Logs can quickly grow to unmanageable size, being able to easily seaparate a subset of actions (e.g. focus on AdminUserX) for possible review is a useful step towards maintaining the utility of logging as a tool.
• In a high-risk environment (e.g. Sarbanes-Oxley compliant accounting system) actual examination of such logging is needed, in a low-risk environment, the simple existence of such logs is a deterrent and a valuable forensic/recovery resource, hopefully never to be needed.
• The utility of introducing such an accountability measure is to a great extent dependent on the ease of keeping/reviewing such logging on various types. Some thought should be put into the tools and configuration necessary to achieve sufficient information for accountability purposes.
• Segregation of privs (to take actions) is generally less burdensome than segregation of access (to see information).
• Having two logins may be viewed by some as an inconvenience. It is meant to be. Performing an "administrative action" should be a considered and deliberate act. In reality, having used such a system for years, even with regularly required password expiration policies, changing the two passwords in synchrony, it is a minimal burden to achieve a desirable goal.
• It is a matter of user training and having a documented "business procedure" to gain compliance with the dual personality system. User's running around wearing their "red capes" when not needed can be readily identified by examining logs of tracked AdminUser accounts during initial stages of implementing such a system. The priv'ed status of users identified as unwilling to comply with simple security related business practices should be reviewed with an eye towards a rapidly escalating series of management-determined actions, culminating in loss of admin priv'ed account.

For any security measure, you need to have a "threat model" that is realistic and not just a strawman or you would turn off all your computers and hide them in the closet. When you feel you know your people well enough, which you should before you consider granting elevated privs, "Trust, but verify" is an effective risk mitigation strategy.

cjl 20:19, 20 August 2008 (UTC)