CC EAL-7 level COTS OS??

Hey,

I did a search and did not find any mention of this so if it is a repeat I apologise in advance.

The news release is about a month old but I thought it was significant enough to be posted...

LynuxWorks is stating at http://linuxdevices.com/news/NS6765352929.html

Quote:

---

it will ship a new super-high-security operating system in July, 2005 that was designed to meet the very highest levels of military certification...

LynxSecure was designed for certification to Common Criteria EAL-7 (Evaluated Assurance Level 7), a level of certification unattained by any known OS to date.

---

I have seen alot of stuff debating the pro's and con's of an open source OS being able to meet the security requirements of EAL-7... but I say if Linux can meet these requirements all the better.

WOW...

F1fan

PS> For more info on EAL requirements ...http://csrc.nist.gov/cc/Documents/CC...RT3/PART36.HTM

Hmmm. I can't imagine an opensource OS using anything more than a smattering of code previously available, and actually achieving this rating easily.

I'm not saying it can't be done, but considering the track record of the likes of Sendmail, it would be difficult to do this without reinventing the wheel. I agree with the whole 'many eyes' argument that Eric and the zealots^H^H^H^H^H^H^Hboys make, I trully believe it works (as I type this post in Firefox). But I think the majority of the code out there being used may not be up to snuff to pass the scrutiny needed for EAL7.

Of course, if it is opensource, and they do succeed, and we all get to play with this 'new code' I believe they'll have to write...weeeeeeee!

If you read carefully in the article provided, you will note the product they are talking about is a security kernel that provides a Linux-like interface within a type verification system similar to SecureOS which provides a BSD-like environment.

It is NOT Linux.

It is not possible for an open development product to ever be evaluated EAL7.

Note, I did not say "not easy" or even "very difficult" I said "not possible."

Quote:

---

EAL7 also provides assurance through the use of a structured development process, development environment controls, and comprehensive TOE Evaluation assurance levels configuration management including complete automation, and evidence of secure delivery procedures.

---

Notice the "structured development process" bit. Considering open source development falls under Level 1 of the CMMI software development model, it cannot be considered structured under any circumstances.

Their system, on the surface appears more likely to be EAL5 at best... but we'll see. It should be noted that the system it question is not listed on the ISO-15408 "in progress list" though another EAL7 product is (but it isn't an OS).

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, clearly this cannot be achieved with code alone. Hence:

Quote:

---

Common Criteria EAL-7 (Evaluated Assurance Level 7), a level of certification unattained by any known OS to date.

---

is misleading. Even STOP 6.1.E currently the highest evaluated operating system against ISO-15408 only achieved that evaluation on the XTS-400 hardware platform.

To roughly compare ISO-15408/CC to TCSEC (with consideration to assurance levels):

EAL2 = C1
EAL4 = C2/B1
EAL5 = B2
EAL6 = B3
EAL7 = A1

And A1 evaluated systems do exist.

cheers,

catch

Hello Catch,

I would like your opinion (preferably professional/academic :D ) on this one:

You said:

Quote:

---

Considering open source development falls under Level 1 of the CMMI software development model, it cannot be considered structured under any circumstances.

---

Is that absolutely true?.............the reason I ask is that my experience with the CMM gave me the distinct impresion that it was an organisation's processes that earned a rating, rather than the OS/development style? So it ought to be possible to run an open source project under CMM?

If you have any references, I would be very interested, as I am sure others would be.

As for "security", I am with you 200% there..............I just have this feeling that it is security rather than structured methodology that is in the driving seat here?

interesting?

Hehe, I was reacting strangely to that comment as well. 'opensource development' and 'opensource software' are two different statements. We can do ALL development in house, and allow others to have it under an open source license...

Quote:

---

the reason I ask is that my experience with the CMM gave me the distinct impresion that it was an organisation's processes that earned a rating, rather than the OS/development style?

---

It is the organization's process I'm talking about. In this case the organization in the Linux development community.

Now "Open Source" typically means software that has had its code base contributed to by its user base. However, "Open Source" could just as easily mean any closed development product that makes its source code availible to the public. Although I cannot, offhand think of any products like the latter, I figured it better to place it safe and distinguish that I meant products that are developed by their user base.

Security is the by product of structured methodology.

The point of my original post was simply:

1. The product in question isn't Linux.
2. Linux can never reach that level of assurance.
3. No software product alone can ever reach that level of assurance.

cheers,

catch

I disagree with the statement that open source software (as in developed by its userbase) can not be anything but cmm level 1. Even open source software can be well planned, tracked and controlled. Altough I agree that it mostly isn't and that it isn't in the case of the linux kernel, there actually are some projects who apply good rules about documenting of code and use of "formal" coding instead of quick workarround-the-problem "hacks" wich makes the developing prcess alot more proffesional.

As for the software being reliant on the hardware... That's kinda obvious, adding special security stuff to the hardware architecture makes things different... It is however a choice you make for the most suitable system practically. If for example for some radio application you only have a very limited frequency band, you can't use an architecture that uses more frequencies altough it would be more secure for some reason.

Quote:

---

I disagree with the statement that open source software (as in developed by its userbase) can not be anything but cmm level 1

---

This is because you are unfamiliar with the CMM.

Level 2 = the Repeatable Level; now what part of having a random college student from god knows where sending in a bug fix or tuned code is repeatable?

Can the open source project manager (if one existed) rely on this person/process? As soon as you accept random input, all notions of repeatability are out the window.

Quote:

---

The software process capability of Level 2 organizations can be summarized as disciplined because planning and tracking of the software project is stable and earlier successes can be repeated. The project's process is under the effective control of a project management system, following realistic plans based on the performance of previous projects.

---

-http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf

I didn't say software was reliant on hardware, I said that process segregation at the higher security levels needed to be done at the hardware level, consequently no chunk of code is sufficient by itself to achieve the higher security evaluations.

cheers,

catch

Quote:

---

It is the organization's process I'm talking about. In this case the organization in the Linux development community.

---

Thanks for the clarification, I thought that was what you might be saying.

Quote:

---

Security is the by product of structured methodology.

---

In an ideal world it would be integral, like automobile or airplane safety?.............I am using a very broad concept of "security" as well:)

Quote:

---

2. Linux can never reach that level of assurance.

---

Would I be right in thinking that a branded Unix product could (given the other environmental parameters)? The problem mainly lies in the fact that the Linux community is not integrated, so has not adopted structured methodologies?

OK I know there are major players who must use some form of structured methodologies, but there are no cross community standards?

Quote:

---

Originally posted here by catch
This is because you are unfamiliar with the CMM.

Level 2 = the Repeatable Level; now what part of having a random college student from god knows where sending in a bug fix or tuned code is repeatable?

Can the open source project manager (if one existed) rely on this person/process? As soon as you accept random input, all notions of repeatability are out the window.

-http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf

---

I am familiar with the cmm and the scenario you're sketching is quite the worse case scenario. It's like the minimum required to actually get anything working at all. I'm saying it doesn't have to be like that and actually isn't in the case of quite some projects, where people with actual programming job experience do stuff too.

Quote:

---

I didn't say software was reliant on hardware, I said that process segregation at the higher security levels needed to be done at the hardware level, consequently no chunk of code is sufficient by itself to achieve the higher security evaluations.

cheers,

catch

---

at higher levels everything mathers and the hardware is of lesser importance compared to the architectural changes required for special applications for there is a difference if a system is placed in a computerbunker or in for example a sattelite... linking hardware design directly to security then is weird... the software design describes how the hardware resources are used and the rest is a mather of choice and opinion.

Ok neel, seriously your ignorance is pissing me off.

Name an open development project that utilizes any semblance of repeatable project management... just one. Open development by its very definition is not repeatable, no matter how professional some of your programmers are. As soon as you accept any input from someone outside the scope of project management you are utilizing an ad hoc system... aka Level 1.

Quote:

---

linking hardware design directly to security then is weird... the software design describes how the hardware resources are used and the rest is a mather of choice and opinion.

---

No it isn't.

"The TCB shall maintain process isolation through the provision of distinct address spaces under its control. The TCB shall be internally structured into well-defined largely independent modules. It shall make effective use of available hardware to separate those elements that are protection-critical from those that are not."
- 3.3.3.1.1 System Architecture - DOD-5200.28-STD

Clearly hardware is critical in achieving this level of evaluation.

This is done in different ways, some use the different security rings available in the Pentium architecture (XTS-400). Others use a completely separate processor to handle the security kernel (LOCK) and still others use physically separated RAM chips in conjunction with a hard-coded security kernel (HYDRA).

These have nothing to do with the application of the system... they have to do with meeting the process separation requirements. They would need to be consistent on a satellite or in a bunker.

catch

Hi Catch,

We use PRINCE2 as a structured PM methodology over here..............possibly SSADM as the development methodology...........they are both UK government so seem to fit, but I do see your points on this one...............if you do not have structured specification and analysis, what is the point in having structured design, implementation and project management?

So how can you get very far into CMM?

Please correct me if I am wrong..............this is really rather interesting to me

:)

Good stuff nihil.

I see this alot, the point in having structured design, implementation, and project management has less to do with high assurance software and more to do with profitable software.

However without structured analysis of both the product and the process, CMM-Level 4 will remain a dream.

"Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled."
- http://www.sei.cmu.edu/pub/documents...df/tr24.93.pdf

I highly recommend that document to anyone looking to learn about the SW-CMM, though it is a bit dated it is still a nice overview before delving into the CMMI.

cheers,

catch

Hmmm,

Quote:

---

I see this alot, the point in having structured design, implementation, and project management has less to do with high assurance software and more to do with profitable software.

---

Yes, I have studied structured methodologies over the years, particularly in house ones used by contractors. They all seem to start with some sort of bid/tender/proposal process, and take it from there.

There seems to be an underlying assumption that the customer (user) has provided full technical and functional requirements specifications and that they have a "business plan"

I know that we have both worked in defence/aerospace, and that in those sectors that assumption is reasonably true, in my experience at least.

The contractor is out to make a profit, and has structured methodologies to support this, the customer is looking for functionality and value for money, and also has structured methodologies to support this.

Provided that they work in unison on common projects they would be capable of achieving CMM level 5, both individually AND collectively? and we have a full life cycle development environment :)

Now, the problem arises when the customer has not completed the initial phases of the project cycle, and will not pay the contractor to do it. The contractor will probably not worry too much about this if it is a time & materials billed project

In this situation, the contractor could still rate CMM5, but combined with the customer the rating would be CMM1 (it probably should be 0 or a negative value? :D )

In case anyone is in doubt, and thinks that this is academic/theoretical bull****; I have actually worked in both those situations :eek:

So, if we apply this to open source, we have many customers with no clearly defined requirements, and many suppliers with variable development standards and cost models?

I cannot see how that can meet any kind of high level certification?


just my £0.02

Quote:

---

Provided that they work in unison on common projects they would be capable of achieving CMM level 5, both individually AND collectively?

---

No one is analyzing... and the developer isn't utilizing knowledge gained from the customer's previous efforts with perhaps different developers. The process is only as mature as it's least developed point.

You are exactly right with the maturity of the open development process.

cheers,

catch

Quote:

---

Originally posted here by catch
Ok neel, seriously your ignorance is pissing me off.

---

Ok catch, seriously your arrogance is pissing me off.

Quote:

---

Name an open development project that utilizes any semblance of repeatable project management... just one. Open development by its very definition is not repeatable, no matter how professional some of your programmers are. As soon as you accept any input from someone outside the scope of project management you are utilizing an ad hoc system... aka Level 1.

---

KID is one example. Altough everyone can download the source code and modify it, only submitted code is (if qualified) added to the project. Modification that are not added technically belong to other software "based on" KID.

Quote:

---

No it isn't.

"The TCB shall maintain process isolation through the provision of distinct address spaces under its control. The TCB shall be internally structured into well-defined largely independent modules. It shall make effective use of available hardware to separate those elements that are protection-critical from those that are not."
- 3.3.3.1.1 System Architecture - DOD-5200.28-STD

Clearly hardware is critical in achieving this level of evaluation.

This is done in different ways, some use the different security rings available in the Pentium architecture (XTS-400). Others use a completely separate processor to handle the security kernel (LOCK) and still others use physically separated RAM chips in conjunction with a hard-coded security kernel (HYDRA).

These have nothing to do with the application of the system... they have to do with meeting the process separation requirements. They would need to be consistent on a satellite or in a bunker.

catch

---

just like I said the seperation of elements can be done in many ways if you specify them on the software level. It's a mather of choice still if you essentially build two computer in one and using some electromagnetics trickbox to seperate the two, or just use two computers, maybe sharing some resources like RAM or whatever. On the hardware design level you sometimes don't have the options you'd use in a bunker, when yer designing a computer in a satelite. For example when chips get some ghz's more then they have now, there's a shitload of components that start to act like crazy antenna's and ****. You can minimize that using different designs, but you can't totally eliminate it. You'd need software to seperate the elements phisically and in time, making it quite irrelevant what hardware you use.

Quote:

---

KID is one example. Altough everyone can download the source code and modify it, only submitted code is (if qualified) added to the project. Modification that are not added technically belong to other software "based on" KID.

---

First, now you see why I made a point to seperate "Open source" from "Open Development", secondly, random user input cannot be predicted! As soon as you accept anything from outside the scope of your project management, you are using an ad hoc system.
Why do I need to keep telling you the same thing over and over?

And on the hardware issue you are not even close to addressing the issue at hand, so no point in my responding to save this point. No one is talking about the future (or exotic applications), right now... today, this very moment... in order to achieve high levels of assurance, process seperation needs to be done at the hardware level.

catch

Quote:

---

Originally posted here by catch
First, now you see why I made a point to seperate "Open source" from "Open Development", secondly, random user input cannot be predicted! As soon as you accept anything from outside the scope of your project management, you are using an ad hoc system.
Why do I need to keep telling you the same thing over and over?

---

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 ?

Quote:

---

And on the hardware issue you are not even close to addressing the issue at hand, so no point in my responding to save this point. No one is talking about the future (or exotic applications), right now... today, this very moment... in order to achieve high levels of assurance, process seperation needs to be done at the hardware level.

catch

---

no, the antenna example is already at hand since you have EM interference everywhere... you think current processors are a bunch of transistors placed in a piece of silicium as its suited without any attention to capacities between wires ? process seperation can be done with software today and that aspect won't change in the (near) future as does the need for security... 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.

Quote:

---

KID is one example. Altough everyone can download the source code and modify it, only submitted code is (if qualified) added to the project. Modification that are not added technically belong to other software "based on" KID.

---

I have to agree with Catch on this one. Anytime you cannot predictable plan and repeat when a piece of software will be available and whom will be the one updating it you are not following very basic principles of CMM. Just because you are following a strict submittal process does not make the process repeatable.

One of the very basic parts of project management is resource management. In an open source or open development project the resources that you have available to you are very flexible and not static. This is definitely not what you want if you are trying to achieve higher levels of CMM. While it could be possible for an open development project to reach higher levels, if properly managed, I've never seen it done.

Open source and open development, however you want to look at it, assumes that the user base will find a problem and fix that problem when they have the time and resources to do so. How is this planned development?

Having seen CMM in action at large telecommunication companies, where I work, and at IBM, where we outsource much of our work, the biggest thing to CMM is pre-project planning, and post project analysis. I've never seen an open source project strictly define the number of programmers needed, who those programmers are, their qualifications, when they work, who they work for, how their work is evaulated, who does the evaluation, etc... Which are all very basic parts of planning a project.

I don't really see how this applies to this piece of software though as this is not really open source software as I don't see them publishing the code, and I highly doubt that they will publish any of this "linux"-like OS under GNU.

Hmmm,

Quote:

---

One of the very basic parts of project management is resource management

---

Absolutely, in fact the classical approach/model says that if the PM does not have the identified and committed resources to start with, he should not even start the project?

Quote:

---

and whom will be the one updating it

---

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

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???????!!!!!!!!!!!!!!!!!!!

CMM, ISO, BSI...................all I have to do is demonstrate that I can replicate the same sh1t product 24/7/365, that my processes and supporting procedures are fully documented, and that all my people follow them...............and voila! I am certified................it is a bit like playing Russian Roulette with a Colt .45 auto...........as long as you can squeeze the trigger?.......................

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

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?

Personally, I see the value of both :)

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

Yes,

I can see some organisations sticking to "what we know" rather than looking ahead (hot stock tip: "SELL! SELL! SELL!) :D

However, I must say that in my experience this is more an attitude you find in the customer's camp than the contractors'. I would suggest that quality contractors realise that state of the art methodologies are how they make themselves competitive, competent and profitable.

What I have seen is situations where an organisation has invested so much time and effort into an older methodology that they are loath to write off that investment and start afresh.

Business and process re-engineering projects are notorious for their failure rate? :eek:

I have seen numerous cases where the customer has required certain methodologies to be used as part of the contract. That is OK, you just do your own thing, and provide their metrics/documentation etc. in addition............. and charge them for it.

Where I have seen a frightening situation, is an organisation trying to encompass CMM yet not training their staff accordingly. Sure you get all the documentation and checklists, but what are they worth if their underlying functionality is not understood and embraced by the practicioner?

"Has the XYZ document been filed in the ABC repository?".........."Yes"...........oooooooooooh another checkmark.............."is it a crock of sh1t?"..............errrrr............"Yes"..............it is the last question that does not get asked or answered.

;)

At the end of the day it is the quality of your personnel that counts.............no methodology is a "silver bullet"?