I use the TFM

How many here rely on good documentation?

"The importance of the TFM in supporting the operation of a secure computer system cannot be over estimated. Even if one assumes, hypothetically, that all users of a system and their applications are trusted, and that they will use all of the available protection mechanisms correctly, the system may still be administered and operated in an insecure manner. This may be especially true when administrative users lack the skill, the care, or the interest to use the system properly. ~ NCSC-TG-016 "

Yes.. I use TFM.. (isn't The TFM a bit double ?? (TFM == The F-ing Manual) right ??)

In my case:
http://www.slackbook.org/ (have the printed edition of Slackware Essentials from http://store.slackware.com/ )
O'Reilly: LPI Linux Certification in a nutshell
Ira Pohl & Al Kelley: A Book on C
Ira Pohl: C++ for C Programmers
SuSE books that came with the CD/DVD's

Some more O'Reilly books like Linux in a nutshell
And ofcourse: http://tldp.org/

Not sure but knowing !mitationrust a bit and looking at the text itself I do believe he means "Trusted Facility Manual" or "Trusted Facility Management".

Guide to understanding trusted facility management

Ah.. I knew I should have googled NCSC-TG-016

In that case.. Nope.. Our company will have to move to a different location to ever be a Trusted Facility..

Nope. I don't trust anything that has the word "trusted" in its name.
:cool:

No I don't!

Quote:

---

The TCSEC was originally published on 15 August 1983

---

How many viruses, trojans worms etc have we seen since then................and they hit places that should be compliant?

Quote:

---

The importance of the TFM in supporting the operation of a secure computer system cannot be over estimated

---

As soon as I read a statement like that I switch off because I know the rest will be bullcrap...........if real life were like that it would be like painting by numbers, and I could replace most of you with a 286 :D

The same can be said of design and development methodologies................follow them to the letter and you will design and develop nothing

Rules are made to be broken, corners to be cut................if you cannot handle that then you had better go live in an ivory tower, because you will not be able to hack it in the real world.

Whilst theoretical models are all well and good, the real world is driven by practicality affordability and acceptable risk; and those parameters are not within the ambit of the IT function.

In my experience, the best you can hope for is to get some of the most obvious concepts accepted. The only exception is legislatory compliance, of course.

My £ 0.02 :)

If you have any problems with this, just read poor old HTRegz's thread regarding "advice".......that is the real world I am afraid.

Yes it's a manual, more specifically as noted above, the Trusted Facility Manual. I think DoD terminology intimidates people. Trusted Facilities, doesn't always mean nuclear silos. These manuals should reside inside the hands of the local library admin. It's just that they can go that far in terms of describing the systems limits in terms of security. Hence COTS.

"The manual shall describe the operator and administrator functions related to security, to include changing the security characteristics of a user. DoD 5200.28-STD"

Basically people (vendor) who know 1,000 times more about the system than you, have documented their knowledge so admins and operators don’t have to waste their time (money) to attempt their own research on the systems security configurations. It’s really helpful when the system is first released to the public. One of the manuals purposes.


I was just curious in the methods you guys use to run your ships. If you guys rely on good documentation.... If you rely on trial and error?

You will be assimilated RC. :borg:

To me this seems to be the smartest way to accomplish what you're paid to do.

Hi Rusty~

Quote:

---

If you guys rely on good documentation.... If you rely on trial and error?

---

Those are not neccessarily antitheses?

As I feel that we may be talking at cross purposes here I will outline what I consider to be pretty normal or at least desirable.

There are 4 fundamental facets of security that must be considered:

Internal
External
Physical
Systems

You look at your processes and the procedures and applications that support them.

You look at your personnel and their responsibilities.

You allow your personnel sufficient access and authority to discharge those functions, AND ONLY THAT!

You establish appropriate checks and balances to monitor and manage your processes. By definition that includes the supporting procedures and applications.

The whole exercise should be conducted from the top down................."bottom up and you will belly up".

I say that because all organisations have a purpose or functionality. This is NOT to run processes, procedures or applications. They merely enable the organisation to achieve its objectives.

I do not set great store by vendor's manuals when it comes to processes or security. Firstly they are no substitute for a proper business analysis exercise and secondly, if they were that damn good, why do all these vendors keep releasing security patches (but never a patch for the manuals?)

:D

We use BS7799 (ISO17799 soon to be ISO27000 series) and aim to be compliant with it but not certificated to it. Manuals/documentation/policies and procedures are all used and written in such a way as to be compliant with BS7799.

We also use a derestricted subset of documents from the 'Manual of Protective Security (MPS)'. The MPS is restricted though I can make a business case to request particular documents.

I also have to comply with various codes of conduct where we do have to deal with protectively marked documents and hardware is rated against Common Criteria.

Hi Aspman

The problem with BS/ISO and most other documentation standards is precisely what they say: "Documentation"

You can have the crappest policies, processes and procedures on earth, but so long as they are properly documented and adhered to, you will pass certification.

My point is that they deal with replication rather than quality :)

Quote:

---

Originally posted here by nihil

You can have the crappest policies, processes and procedures on earth, but so long as they are properly documented and adhered to, you will pass certification.

---

I hope you're wrong there but somehow I doubt it :(

But it is the way in which most organisation rate their security or are rated. Real tests like a Pen test only make up a little of how secure you are percived to be.

I still find it hard to get my head round it sometimes. "We can't get hacked, I've got a great policy in place".

It's all just paper shuffling unless the policies and procedures (if they are good) are being followed and that has to be checked for compliance regularly. And that's why everyone hates me :cry: and I'm not even part of internal audit.

Hi Aspman

I do not see this as a problem so long as people understand that these limitations exist..............there is no such thing as the silver bullet :D

Certification is a process to determine if you have decided what to do, have documented it, and are actually doing it. In no way does it address "best practice". So long as this is understood and the question of best practice is dealt with in determining what you do, there is no problem, and certification indicates adherence to best practice.

As you say, a process is required to ensure that the certified processes and procedures are adhered to on an ongoing basis. I called these "checks and balances"............all you have to do is say that and "audit trail" and the beancounters will quietly wet themselves and leave you to get on with it :D

To illustrate my point, imagine that you have a project to implement an off the shelf stores management suite. Get hold of a copy of SSADM and PRINCE2 and just looking at the phase headings/modules determine how many would actually apply?

The first step in a project is usually to determine the methodologies and models you intend to comply with and select the bits that are actually relevant in your particular environment.

And anything additional that might constitute best practice

;)

Yes, I was starting to think I had a particular strain of Turettes, I say 'Audit Trail' so often round here.

Quote:

---

Originally posted here by nihil
No I don't!


"The TCSEC was originally published on 15 August 1983"

Rules are made to be broken, corners to be cut................if you cannot handle that then you had better go live in an ivory tower, because you will not be able to hack it in the real world.


I do not set great store by vendor's manuals when it comes to processes or security. Firstly they are no substitute for a proper business analysis exercise and secondly, if they were that damn good, why do all these vendors keep releasing security patches (but never a patch for the manuals?)

---

MS03-041:,MS03-042:,MS03-043:,MS03-044:,MS03-045:,MS03-046: etc..etc... Were created because people didn't follow the TFM to begin with.

It seems to me that you think there is no need for vendor documentation (TFM). Rules are made to be broken? We're talking a bout a career, possibly someone’s identity getting stolen, etc...etc.. I'm talking about computer security. Not standards for a TV remote and how to eat breakfast. You feel there's no need for good documentation, everything should be on the fly? Rules are made to be broken, so are systems too I guess?

You: So given a new facility with 1,000 new nodes, you'd configure the systems via your own knowledge, and to what configurations you see fit in terms of security? And when something was incorrectly configured, you apply another round of configuration, without a checklist, or did you make one up?

Me: Given a new facility with 1,000 new nodes, I'd configure to the TFM in order to run a trusted facility. Using verified instructions and checklist.


The TCSEC is a timeless well-documented publication of standards that are still very accurate in 2005. Yeah it relies on the Bell-La Padula security model. It's still good to go.

Nihil, you make a lot of retarded comments but this:

Quote:

---

How many viruses, trojans worms etc have we seen since then

---

takes the cake. It shows such a lack of understanding of the TCSEC, ITSEC, and CC that I can't even believe it.

When do transitional state models become obsolete? With the advent of new viruses, worms, and trojans? Of course not. All processes fall within the same model be they good processes or the product of malware.

The TCSEC is still valid today, it has merely been expanded and reorganized by the CC.

Quote:

---

Rules are made to be broken, corners to be cut

---

I guess now we see why the rest of the world is so incredibly far behind the US when it comes to computer security. So... what was the last high assurance system designed in the UK or by a UK company? Or... any other country for that matter?

You operate in a very different "real world" than those of us who require high assurance environments. If I cut corners and break rules... I get to go to federal prison. I think being anal raped as the result of following your advice is just a little too "real world" for me.

Quote:

---

I do not set great store by vendor's manuals when it comes to processes or security.

---

Fortunately for you, your job doesn't require it... in fact you prolly use systems that don't even have TFMs.

Quote:

---

Firstly they are no substitute for a proper business analysis exercise and secondly

---

Nor are they intended to be... they tell you how to apply the security policy to correctly meet your business requirements. Don't you find it difficult to debate something that you don't understand?

Quote:

---

if they were that damn good, why do all these vendors keep releasing security patches (but never a patch for the manuals?)

---

I've never needed to patch a system that followed the TFM, the majority of patches are for superfluous services or misconfigurations that allow a code level exception to violate the security policy. I cannot recall a single exploit for ANY system in the last 15 years that violated the TFM. Additionally TFMs are updated to comply with changes in the system... and would comply with changes in vulnerability types, except no new vulnerability types have been discovered in the last 30 years or so.

Quote:

---

You can have the crappest policies, processes and procedures on earth, but so long as they are properly documented and adhered to, you will pass certification.

---

This is not true either... ISO-17799 requires that you document how your security policies have been implemented in a manner that meets the business requirements. If they don't do that, how can you document it?

Quote:

---

I do not see this as a problem so long as people understand that these limitations exist..............there is no such thing as the silver bullet

---

Yes, there is such a thing as a silver bullet... it is called a process of continual improvement. ISO-21827 will get you on your way with regard to security.

cheers,

catch

Hi Rusty

Quote:

---

It seems to me that you think there is no need for vendor documentation (TFM)

---

Please do not get me wrong, I am not saying that..............my point is that it is VENDOR so will show the product in its best light? and will probably contain a lot of superfluous information? You must develop your own version for your particular environment? Also, beware of manuals .......they are like insruction sheets?..............I say: "go for the model, go for the methodology".........and write your own manuals from that?

I know that I use English a lot differently from yourself, please do not hold that against me :)

What I am trying to say is decide what you want to do then use the manual/documentation.

I fully agree/support/insist on documentation. Where I was suggesting a different, or more practical approach, in that it should be site/business/activity related. I am wary of "vanilla" and of manuals from a different environment?.................hey! if there were a "universal solution" would a lot of us have jobs? Sure! use the vendor stuff for templates or whatever, but make sure that the "issue ammo" is your own?


Catch

Quote:

---

Nihil, you make a lot of retarded comments

---

I have a little challenge for you :D ............. just go tell your CEO or CFO that they are "retards"............quote all the documents and standards that you like..............and see if you have the same job to go to in the morning?

:D

First, I didn't call you a retard.

Second, having recently left to found my own Information Security company... I am the equiv to the CEO.

However previously if I said "You are retards for not following the TFM." they would say "We understand that it is your job not cost avoidance, but keeping us out of jail, so why exactly are we retards?" to which I would respond... "Because the contracts require that we utilize systems of X evaluation to maintain their data. The only way to ensure that X evaluations are met is by following the TFM... if we fail to do this we not only risk losing those clients and gaining a bad reputation... but potentially you could be facing jail time for fraud by accepting those contracts in the first place knowing the conditions." There would be a bit of silence, and then I would say "It'll cost me $Y and will take Z units_of_time to accomplish, everything is in this brief." They would then say... "Losing contracts is bad... and fraud charges are even worse...*murmmering about anal rape*... we really are retards... can we give you a raise?"

But I guess I just have a better reputation than you. ;)

Third, my old executive officers were versed in the TCSEC and knew that the development of new viruses, trojans, and worms and no impact on its validity. They also knew that its requirements are so valid that they have just been migrated into the current Common Criteria protection profiles and assurance levels.

cheers,

catch

Hey Catch

Quote:

---

Second, having recently left to found my own Information Security company... I am the equiv to the CEO.

---

YOU MISERABLE LITTLE TOAD! you never told us?

BEST WISHES MY FRIEND! Go! Catch Go!

I shall miss pulling your chain :D

Hey, buy the g/f a nice baseball bat for Christmas....................I mean hickory , not that duralumin crap!

Then say that your "personal stylist" (nihil) suggests that her nation take up baseball?

BTW.................what colour roses would you like on your coffin?

Congrats! you £$%^&*))

:p

OH! I forgot.................you are the CTP, not the CEO?

Hey, I got another one... Do you use the SOY? Or the DMP? Or the FFS?

ppl it sux 2 hav 2 read this n ges aftr te mening

How hard is it to just type out abbrieviations at least ocne in your post.

It's like a noob trying to sound smart, while you're not smart. When you need weird abbrieviations or weird words in general to get your message accros, you're just pretending to be smart. Smart people don't need them.

Hi neel

CEO = chief executive officer, managing director, "the boss"

CTP = chief tax payer



:D :p

EDIT: And Catch has been Googling for ages to find CTP...............but to no avail, cos I just made it up to pull his chain :D

Quote:

---

How hard is it to just type out abbrieviations at least ocne in your post.

It's like a noob trying to sound smart, while you're not smart. When you need weird abbrieviations or weird words in general to get your message accros, you're just pretending to be smart. Smart people don't need them.

---

While I agree this is best practice and a must for stand alone papers... I think it can get tiresome or even forgetful to spell something out in each new thread, especially if you make a new thread based on a tangent of another thread.

Anyhow... that is no excuse for you to be insulting. Lastly, before you go acting like you know how smart people act... is Einstein known for "Energy is equal to matter multiplied by the speed of light squared" or "E=mc^2"?

Thanks for the well wishes nihil.

cheers,

catch

catch,
You're right, it's no excuse to be insulting. Being insulting gets my point accros better though. I was just annoyed with the first post in this thread, since noone was sure what exactly imationrust ment.

On Einsteins thing, he wrote an entire article about that. E=mc^2 is just one word from that article. Most people don't know what it means either, so if you want to ask the "general public" a question about it, it's only normall to explain at least where it comes from. You can't expect people to spend several minutes figuring out your question first.

1)If you don't know an abbreviation just ask.

2)If you are going to use lots of abbreviation in a post be prepared to expand when asked.

I was going to put a post in site suggestions for an abbreviation bank but if everyone is prepaired to do 1,2 there isn't a lot of point.

Not worth getting hot and bothered about :)

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. 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.

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)...

Let us please not let this most interesting discussion degenerate into sparring - Some of us stand to learn a lot from this (me especially!)...

[edit]*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. [/edit]

For the umpteenth time, you add no value to these threads. People, this is just how neel reacts to things he doesn't comprehend. If you don't believe me, do a search for CC EAL-7 level COTS OS in google.

Seriously kid, if you don't understand something just ask. Or consult the RFC2828 or something. Read a book or two as well. ;)

But this whiny ****? Take it elsewhere.

!mitationRust,
Oh, I guess you misunderstood. What I was saying was: I think you are trying to hide your lack of knowledge and your non-lack of insecurity by using fancy words and abrievations. You use them to cause confusion, so you sound smart yourself.
I don't have a problem with the content of your threads, I have a problem with you. "Go read a book"? Now who was asking the questions again?

Having trouble keeping up again, neel?;) It seems to me that you've never watched the news, been through college, or drafted a proposal. You're sensitive, you feel condemned by common terminology because you're untutored, perhaps even incoherent.

But this whiny ****? Take it elsewhere. ;)

"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

Hey guys 'n gals........................one of our own, Catch has gone out there?..............where are the congrats and good wishes? am I the only one who cares?

And which one of you shall I pick on next?

:D

Catch, best wishes mate, and I shall have a Mass said for you................that will be three off this site this week..............at least yours is a happy one!

God bless

:)

Quote:

---

Having trouble keeping up again, neel? It seems to me that you've never watched the news, been through college, or drafted a proposal. You're sensitive, you feel condemned by common terminology because you're untutored, perhaps even incoherent.

But this whiny ****? Take it elsewhere.

---

Ooh, that's a though one. So if I understand you correctly you're saying I'm right?

Catch is a stand up guy, and may his security business live long and prosper. He already knows how I feel through em@ils about that....... wait! I meant Electronic mail, please forgive my ignorance! Yeah, bra, you're an authority when it comes to this profession, and I'm sure your name/ co name can be heard for miles in Silicon Valley.


neel, how obtuse can you be?

Your whiny ****? Take it elsewhere.

In fact I don't particularly care because the trolls have obliterated any decent content within this thread no matter how hard we try to keep it alive and informative. All of you need to be bitchslapped for this distinct lack of respect for one another, and for those of us who tried in vain to keep the discussion going. You make me sick. :mad:

black, I'm sorry it went the way it did, then again not really. I could've defined the acronym, would it benefit someone who thinks E=mc² is "just a word" and not a physical equation? I didn't think so.

Quote:

---

Originally posted here by nihil
Hey guys 'n gals........................one of our own, Catch has gone out there?..............where are the congrats and good wishes? am I the only one who cares?

And which one of you shall I pick on next?

:D

Catch, best wishes mate, and I shall have a Mass said for you................that will be three off this site this week..............at least yours is a happy one!

God bless

:)

---

Quite right Nihil

Best of luck Catch

If I help you, !mitationRust, it will be "turns" for us too. I tell you things, you tell me things. Not about this case, though. About yourself. Quid pro quo. Yes or no? ;)

Anyway, I have watched TCSEC in action since I joined the Army in 1990 and then when I went to private industry. Think about computer systems back then and then look at the way systems have evolved today. Quit your bitching, things were much harder to deal with back then.

This single doc has been my baseline for security everywhere I've gone and while it does take considerable effort to first implement, you'll recover your costs 100 fold in a very short amount of time.

While I'm not buying into the end all be all theory, the TCSEC is an excellent foundation to hang additional layers of security on. In our case, we've modified several NIST docs and fit them to our environment. At the end of the day, we meet the business requirements and the mandated requirements our good friends on Capitol Hill have promised are on the way. As a bonus, we've nuked most HIPAA and PCI requirements just by having this structure in place from the start. Think for a second how many places are going to be completely screwed trying to radically change the way their technology model is positioned in order to meet just one of the aforementioned.

Anyway, my 2 cents.

--TH13

That said, you need several things to be a success with this approach.
1) Management buy in.
2) The right security talent in multiple disciplines. (security doc writers, legal, technical, audit, etc.)
3) Enough resources to maintain and expand.
4) Zero tolerance policy with TEETH. By far, the hardest thing to aquire, especially if your security team is nested under the IT branch of the org chart.
5) A budget that grows each year. Pulling this off without bling is nearly impossible, especially when we're talking about human resources needed for this.

Your anagrams are showing, doctor. Quid pro quo, doctor.

After reading the clockwork-orange a few times, and then converting its text to speech for the MP3 player...um.....certain acronyms get burnt into your brain. Like the abovementioned, I can see how difficult the implementation can be for the nonproficient.