CC EAL-7 level COTS OS??

Neel,

Quote:

---

It's an open source project I was talking about, not open development. Do I need to keep telling you that over and over again ?

---

In the context of this conversation, to avoid ambiguity:
Open Source = software that users can view the source
Open Development = software that users can contribute to the development of.

So... if KID accepts input from users (no matter the filtering or approval mechanisms in place), which is it? And then again tell me what you've been telling me over and over.

Quote:

---

Process seperation just isn't an aspect of computer security that relies on hardware, just something that can be done with hardware. That's a choice.

---

Of course process separation can be done at the software level. No one denies that, in fact that is how lower assurance systems do it. Your crap about it being a choice... no ****ing duh, a choice REQUIRED BY HIGH LEVELS OF ASSURANCE.

"in order to achieve high levels of assurance, process separation needs to be done at the hardware level. "

"It shall make effective use of available hardware to separate those elements that are protection-critical from those that are not."

"I said that process segregation at the higher security levels needed to be done at the hardware level "

"One more point on this subject, to achieve high levels of security, such as TCSEC B3, which is more or less equal to ISO-15408 EAL6 with regard to assurance require data segregation at the hardware level "

Do you see theme yet? I have already quoted the an instance from the standard that specifically states hardware separation is required... are you saying that the standard is wrong? And in fact you don't need to follow that part of the standard in order to reach that evaluation level? Do you have a point, or are you just trying to make yourself look smart?

Cause I gotta tell ya, being blatantly ignorant of the CMM, CC, and TCSEC is one thing... but it is another to be willfully ignorant after links and references have been posted, and then to argue against excerpts from those standards... well none of that makes you look too smart. No matter how much off topic BS you throw around about the specifics of computer hardware, EM emissions, or obscure applications.


nihil,

Quote:

---

You cannot judge open source with non-open source standards?

---

Sure you can... by open source I assume you mean (for the purpose of this conversation) Open Development... and it evaluates very correctly at SW-CMM Level 1: An ad hoc development approach with success largely dependant on individual talent. That is open development to a T. If the shoe didn't fit so perfectly, I'd say you were right... but the exactness of that label leads me to think otherwise.

cheers,

catch

Hey catch,

Quote:

---

You cannot judge open source with non-open source standards?

---

Yes you picked up on my error.............I should have (and meant to have) said "and expect it to pass"?

Which would have taken us to CMM level 1 (and I still think that zero and negatives can be achieved :D ..............or maybe I have just had a few bad work experiences?)

To go back to an earlier point,.................you felt that there was no analysis and no learning from dealing with other suppliers?...............I am sorry I was a little loose in my description...............I was thhinking of a scenario where the customer and supplier were regular business partners and that you had a team that was complete, gelled, but some people got a paycheque with a different company logo on it ;)

That could give you CMM5 for the combined team? otherwise I would worry about the implications internally, where different individuals make up the development team?

Oh..........a comment on my posting style, when I use ? I am asking for feedback/advice, it means that the preceeding comments are not a personally held opinion, just something to discuss :)

Cheers

Hey this thread is getting interesting

Quote:

---

Not quite true? all you need to know is that you will have a technician ABC123 available at a point in time?

---

Correct. By who the person is I was moreso meaning who they work for, if they are a permanent or contract employee, qualifications, etc.. Things of that nature. You do not have to strictly define the person by naming them directly. Although in some high level development projects where exact specialties are needed it is very common to name resources directly.

Quote:

---

Now may we look at the real world, outside of ivy league walls and the ivory towers within?

All these marvellous self-gratification certifications mean jack sh1t in reality............sure, it tells you about an organisation and its ability to document etc.................BUT:

What it does NOT tell you is if the product will work???????!!!!!!!!!!!!!!!!!!!

---

I have to disagree with a couple of things here. First off, while CMM does appear to be something that is purely academic it is not. If you've ever wondered why your dialtone works on your phone everytime you pick it up it is because of the huge amount of planning and post project analysis that has gone into developing our current phone systems. Much of the academic study that was done to form CMM was done at companies such as AT&T and IBM.

If you've ever wondered why pilots don't have to reboot their computers midflight because of system crashes it is because the FAA requires avionic software developers to adhere to level 4 and 5 of CMM.

CMM is used extensively to develop software and if you are at level 4 or 5 not only do you know your software will work, you know it will work almost perfectly. I say almost perfectly because one of the basic premises of CMM is that no software will ever be 100% perfect, so you strive for what is possible, 5 9's. Projects that are run at CMM level 5 will not only provide almost error free products, 99.999% error free, they will produce those products on time and on budget.

You may think that this is purely acedemic, but I've worked on projects that were managed at level 3 and 4, I don't work on government projects that require level 5, and things run remarkable smooth for IT projects.


To tie this back into the original discussion at hand. The reason Catch says that software that is not developed at higher levels of CMM cannot achieve higher levels of EAL ceritification is because there is no assurance that the software was properly developed. Software developed at CMM level 5 will have less bugs than software developed at level 1. Which means that it will be inherently safer because the product will work as expected in a wider variety of situations.

Quote:

---

Neither can you expect open source to meet closed source standards.............they are DIFFERENT......the real issue should be which is the most appropriate in a particular situation?

---

Definitely. You can't even make a comparison between closed source and open source and then automatically think that that makes any relevance on CMM levels. There are thousands, if not millions of closed source projects that run at CMM level1. While it would be nice if all software manafacturers followed some semblance of intelligent design, very little do. Novell, Microsoft, Oracle(non government), Solaris(non-trusted), are all developed at best level 2 of CMM. In many cases I don't even think you can reach that level because they are depending on the excellence of a small group of programmers or individual efforts which puts you squarely at level 1.

The only times I have seen CMM strictly adhered to is government systems such as command and control of weapons systems, avionics, things of that nature.

Quote:

---

Correct. By who the person is I was moreso meaning who they work for, if they are a permanent or contract employee, qualifications, etc.. Things of that nature. You do not have to strictly define the person by naming them directly. Although in some high level development projects where exact specialties are needed it is very common to name resources directly.

---

My point was that you generalise in the early phases BUT when you get the go-ahead you want names and social security numbers or you do not have commitment :eek:

Quote:

---

The only times I have seen CMM strictly adhered to is government systems such as command and control of weapons systems, avionics, things of that nature.

---

Been there, done that :D my point is that CMM or any of the other standards do not tell you how to test anything...............they define environments, not how you live in them...........you can screw up just as easily under CMM/ISO/BSI as under no standard at all............................it is just that standards give you an environment in which success is more likely................if you do your jobs properly :)

To take this conversation in a slightly different way...

Many defense contractors are incapable of achieving CMM level 5, for the simple reason that level 5 requires continual improvement and many of old, working their way out, but some organizations still require them MIL/DOD standards require such strict adherence, that continual process improvement isn't possible.

This is where you get two schools of though... the commercial side that assumes nothing will ever be perfect, so constantly work to get better and better. And the military side, that is required to make a finished product with no functional flaws. Believe it or not, both methods work... one is just a hell of a lot more expensive than the other.

The real problem is, most people fall into the first group... and rather than making continual improvement efforts... they use this lack of achievable perfection as an excuse to sit on their hands... or in cases that bug me the most, suggest some moronic variation of locking your computer in a safe and burying it someplace as ideal security.

And now finally to my point... this type of attitude about software and about security and about all the areas addressed by the CMMI and the remaining CMMs... this type of attitude is costing your jobs. Where do you think the majority of Level 5 code houses are? That's right... India.

If western programmers don't shape up... there will be no programming jobs left for them here. Indians are cheaper and better. Western programmers are still hung up on the idea of individual talent... all that ego. All that ego demanding more money, refusing additional process... coupled with coupled with a crippling attitude on the inevitability of failure.

cheers,

catch

Quote:

---

Of course process separation can be done at the software level. No one denies that, in fact that is how lower assurance systems do it. Your crap about it being a choice... no ****ing duh, a choice REQUIRED BY HIGH LEVELS OF ASSURANCE.

"in order to achieve high levels of assurance, process separation needs to be done at the hardware level. "

"It shall make effective use of available hardware to separate those elements that are protection-critical from those that are not."

"I said that process segregation at the higher security levels needed to be done at the hardware level "

"One more point on this subject, to achieve high levels of security, such as TCSEC B3, which is more or less equal to ISO-15408 EAL6 with regard to assurance require data segregation at the hardware level "

Do you see theme yet? I have already quoted the an instance from the standard that specifically states hardware separation is required... are you saying that the standard is wrong? And in fact you don't need to follow that part of the standard in order to reach that evaluation level? Do you have a point, or are you just trying to make yourself look smart?

---

In your quotes it's not hardware separation but seperation of data on a hardware level. Any hardware does that and the standard is there because data that comes close to eachother phisically "might" have an effect on eachother. That possibility should be reduced to a minimum. How you do it is a choice not a requirement since the hardware requirement is already met without modification. It can be improved but it isn't a requirement since there's no exact indication to what extend the seperation should be.
I don't question the standard, I question you and your arguments and your way of thinking... Other then that you can stick your reply where it hurts because I'm done arguing with you about how good YOU know everything and I don't.

Quote:

---

I don't question the standard, I question you and your arguments and your way of thinking... Other then that you can stick your reply where it hurts because I'm done arguing with you about how good YOU know everything and I don't.

---

Kwiep, letting your feelings get in the way of a debate will not really help. While it is understandable regarding your frustration, it just opens the door for dismissal on your argument.

I had no idea about different assurance levels of assurance on operating systems, and did a little research on Google on that regard. While it is way over my head, the basics were clear. When dealing with lives, you must have reliability and assurance.

Quote:

---

In your quotes it's not hardware separation but seperation of data on a hardware level.

---

Ok, so you understand that much. Though some systems have found outright separate chips the best way to go, I never indicated this was required since I used XTS and the different security rings of the Pentium 2/3 as an example.

Quote:

---

Any hardware does that and the standard is there because data that comes close to eachother phisically "might" have an effect on eachother.

---

Not all hardware does this... and you know what? Even if all hardware did, that wouldn't make me any less correct... since I stated not chunk of code can ever achieve high assurance levels, it must include and make use of hardware to separate processes. Most existing systems don't do this. Everything runs in the same microprocessor ring, and of course RAM chips do such a fine job of separating data... process separation does include object reuse ya know. The majority of commercial hardware does nothing at all to protect existing labeled processes from utilizing unlabeled expired process objects.
The use of specific segregated hardware is to protect expired objects which are no longer within the scope of the system security policy from user software not included in the evaluation. If this is not done, new covert channels are opened and the evaluation isn't valid.

Quote:

---

How you do it is a choice not a requirement since the hardware requirement is already met without modification. It can be improved but it isn't a requirement since there's no exact indication to what extend the seperation should be.

---

Yes there is... the extend should be that the system's security policy cannot be violated through poor process separation! If it can be, you failed and will get a lower evaluation. This stuff isn't rocket science... basic system security theory.

About how I know everything and you don't? What happened to your CMM arguments? Was that a fine example of how much you know? Seriously, just get a grip and either decide that you'd like to learn something on a few topics that you seem to be new to, and decide that you're going to remain ignorant, dig your heels in and try to argue. But this whiny ****? Take it elsewhere.

catch

Catch,

Quote:

---

Many defense contractors are incapable of achieving CMM level 5, for the simple reason that level 5 requires continual improvement and many of old, working their way out, but some organizations still require them MIL/DOD standards require such strict adherence, that continual process improvement isn't possible.

---

Maybe it is me being obtuse, but I don't quite get that :) I think that there are a few words and at least one full-stop (period) missing?

1. CMM level 5 requires a recycling process to improve processes and supporting procedures as a result of ongoing experience............that sort of ties in with the "lessons learned" phase of project management?

2. You will get "backwoodsmen" or "jobsworths" who will resist change, because they are just putting in their time until retirement. However they know things due to having been around so long, that they can have some perceived use to the organisation? (they know the location of the hidden stash of teabags and biscuits)

3. Customer (MIL/DoD/MoD/NATO) requirements are so strict that you cannot always improve your processes?

OK, my experience has been that there was a positive initiative to challenge your processes and improve them. There was always funding and even awards for the staff who proposed them.

Sure I have encountered neanderthals, but they were never in a position where they could get in the way of things...............they had always been shuffled sideways or diagonally or whatever to somewhere they could do no real harm (just make damn sure you don't get one dumped on your project team ;) )

It is your last point that I find difficult..............I have never encountered customer requirements conflicting with internal development standards.............perhaps you could share a few examples (suitably sanitised, of course)

Cheers

Wow, I typoed the hell out of that...


basically I was saying that some companies still require the use of old depreciated standards that cover aspects like the development process. Doing things differently, even if better would be a gamble unlikely to be approved.

cheers,

catch