"TFM is a wonderful thing but it's got too much of a backbiting edge, being that the authors of said TFM believe their creation to be the 'be all end all bible' of their package/equipment."
This is odd... I am not familiar with such TFMs. Typically they do cover the following points:
What functions and privileges that should be controlled when running a secure facility.
The procedures for examining and maintaining the audit files.
Detailed audit record structure for each type of audit event shall be given.
Describe the operator and administrator functions related to security.
Changing the security characteristics of a user.
Guidelines on the consistent and effective use of the protection features of the system.
How these features interact.
How to securely generate a new trusted computing base.
Facility procedures, warnings, and privileges that need to be controlled in order to operate the facility in a secure manner.
Modules that contain the reference validation mechanism are identified.
Procedures for secure generation of a new TCB after modification of any modules.
Procedures to ensure that the system is initially started in a secure manner.
Procedures to resume secure system operation after any lapse in system operation.
I think the majority of these points must come from the vendor or they simply cannot be trusted... think about it how many terrible guides to XP or Linux security have you seen floating around the internet?
Quote:
Since we, as seasoned IT types, know vastly different, we're prepared for such fallacy, but I worry about the 'common user'. I use TFM to get basic operating terms and procedures, then take whatever and do my whorish best to break it and tinker.
Common users are most in need of this kind of documentation... would really nip the spread of worms and viruses right from the start.
Quote:
IMHO writing TFM is a pain in the arse due to required standards - it's like trying to fit a description of the mona lisa into a tight military stencil. Such standards restrict the author into tight boundaries which cause the 'not enough info' problem - perhaps they need to be loosened a bit or trashed entirely and a new set of guidelines written (GAGS remembering ISO9000)...
Military standards for TFM authoring? You mean the Yellow-Green Book (NCSC-TG-016)? Let's have a look at this harsh requirements:
"Audit
The TFM should describe the TCB commands and interfaces available to the auditor that enable him or her to monitor the accumulation of auditable events and to respond effectively to such event signals."
http://www.radium.ncsc.mil/tpep/libr...SC-TG-016.html
Holy cow, that sure is brutal. ;) You prolly think I picked an easy requirement? That is from the B3 section and completely covers B3 related auditing. (There are no additional requirements in the TFM for A1 systems)
The guideline is very loose, it merely addresses areas that ought to be covered and then areas that must be covered for specific evaluations. The idea is that at higher evaluations you should have high assurances because you know exactly how to configure the system to operate in a secure manner.
Quote:
Let us please not let this most interesting discussion degenerate into sparring - Some of us stand to learn a lot from this (me especially!)...
I couldn't agree more.
Quote:
*cough* Catch, it's Energy = MASS times speed of light squared... as taught to me back in 5th grade physics but hey, you've made a point there, which is why there's 'definitions of terms' required in all legal documents and should be in all TFM's - boring reading but necessary.
Yeah yeah... cut me some slack it was like 7am when I made that post and I was on my way to bed. I agree about defining the terms... however like I said, these threads can become conversational and it is very easy to forget that something defined in one thread may not carry over to a lateral thread.
cheers,
catch
