It means something to me (I work with the Common Criteria daily), but you do have a point: the certificates don't mean much to the general public beyond being a license to sell to the U.S. government.
I'd just like to point out that, while the Common Criteria (CC) is based on the U.S. Trusted Computer System Evaluation Criteria - the TCSEC, a.k.a. the Orange Book - it's also based on the European ITSEC and the Canadian CTCPEC... It's an international standard, and a common language for the world's security professionals.
Similarly, the Common Evaluation Methodology (CEM), a companion document to the CC, is an internationally-recognized methodology for conducting these evaluations, so that a gov't dept. in France knows exactly what was done in this SUSE evaluation (after they read the security target, anyway) and can make informed decisions based on that. Don't discount this international market: the list of countries that recognize these certificates is growing every year.
Now, on the subject of real security, again I hear what you're saying. These products get certified up to EAL4 (the highest level recognized internationally... We haven't developed the CEM beyond it yet) and you see flaws published every week. I think a big part of this problem is discretionary security versus mandatory (or real, you could say) security. Yes, you can evaluate a set of security funcitonal requirements (e.g., identification and authentication, stored data integrity, etc.), but at the end of the day, if we're trusting the process that's acting on behalf of the user, things are going to go awry. If we can't set an overall policy, regardless of whose in control of the individual processes, are we really secure? In certain environments, yes. That's where the CC is helping today. On the Internet? It could! Really! Mandatory access control and other necessary components are there, in the CC, but no products are claiming them. So where does that leaves us? These products that are getting certified are not secure in the Internet environment, that's where. And forums like this one scoff at the standard, when it's not the problem. It can, and will, in the future, certify SELinux, which does implement real security.
Finally, I just want to mention that the CEM covers more than code reviews. That's certainly part of the development class (ADV), but there's also configuration management requirements, delivery and operational requirements, installation, generation and start-up requirements, guidance document requirements, life-cycle support requirements, testing requirements and vulnerability assessment requirements (that, admittedly, only cover threats of a low attack potential at EAL4... as I said, we've got a ways to go with the methodology before we can certify Internet-secure operating systems).
It doesn't have to conform to a protection profile; that's just an option. The SUSE security target will list all the security functional and assurance requirements (the EAL3 assurance package in this case) that scope the evaluation (the "something," as you say).
That's too bad; I really liked the stuff. I haven't been using it much lately because I upgraded to Windows XP. I even had problems running it on Windows ME... I was hoping to see an upgrade from the 98 version at some point. Doesn't look like that'll happen now.
I'd been noticing a lot of the Studios set in the toy store bargain bins... Oh well, I hear there are other drivers available for the camera, and lots of movie-making software in general, no doubt. Hell, I'll accept a lot if it means Lego will be profitable again.
That was my first thought. Certainly Remail's ability to pull from many different sources (over an array of protocols) is one of Haystack's best features... Speaking as someone who *really* debated installing it, but, in the end, decided to put it off.
As an AC pointed out, if you can't run these systems in parallel for a trial period, it's going to be a tough sell for people who are pretty happy with their mail setup. To be honest, this idea of a conglomeration of content seems to scare people who are comfortable with computers (myself included). Not a bad thing... Just something to keep in mind when you're trying to sell it (as a good idea, I mean, setting aside the whole can of worms that is making money off it).
There's a difference, though. The security target evaluation (at the beginning of the evaluation - it really scopes the evaluation) is a sanity check. The evaluator would certainly fail the ASE components of a concrete lifejacket evaluation. The evaluator is making sure the functional requirements are mutually supportive, that the security problem they're solving is well defined, that the requirements themselves can solve that problem... It's far more than a "This is what I do... See, I'm doing what I say I do."
"Speaking as someone who works for the government"
Well, speaking as someone who works for a government's CC certification scheme, EAL2 actually does give you some assurance, and I've personally seen companies stumble in getting it. At that level, you're taking a closer look at the developer's design, configuration management and testing; you're making sure they conduct a proper vulnerability analysis, and devising your own penetration tests. It's a significant jump from EAL1.
The CC functional requirements are very specific. If two products claim to satisfy an identification requirement (for example) and both pass evaluation, then you have some assurance that they've both correctly implemented it. That assurance is based on the evaluation assurance level. That doesn't mean they're equal, but it sets the lower bound.
Incidentally, any security product can be evaluated under the CC; there are many functional requirements that wouldn't immediately come to mind (e.g., anonymity requirements in the privacy family FPR). Not only that, the CC allows for extensions, so if you can think up the requirements, products can be evaluated against them (although the ST evaluation may fail if your requirements are poorly written).
The Common Criteria are composed of two types of requirements: security functional and security assurance. The requirements are different for each evaluation, so you need to read what's called a security target to find out which ones are relevant to the specific evaluation.
For example, Windows 2000 was evaluated against all the security assurance requirements in the EAL4 package (plus a few). There were also a ton of security functional requirements based on what Windows 2000 provides (e.g., identification, authentication, audit, etc.). For details, read the Target of Evaluation Description section of the ST at http://niap.nist.gov/cc-scheme/CCEVS_VID402-ST.pdf
Red Hat's Enterprise Linux will have their own ST.
I'm glad to hear it. I've seen many people get entry level positions, but promotion is based on mandatory requirements that pit degrees against huge amounts of experience. It sounds like your progression was fairly smooth, but when you take the person's abilities out of the equation, it means a lot of waiting for that experience window to slide. For example, I've seen these sorts of mandatory requirements far too often:
- a technical degree in the field of CS or engineering and 2 to 4 years of experience in... vs. (no degree and) 6 to 8 years of experience in...
Still others will state:
- a technical degree or equivalent experience...
on paper, but favor university graduates in practice. It bugs me that the employers I've dealt with place so much value on them (despite the benefits I get from such a policy). I guess I've seen too many university graduates who give the rest of us a bad name recently, yet manage to get hired because they have the letters and suck up to the right people. Coop and term positions help to prevent this sort of thing, but less than you might think.
If I'd had it, I guarantee I wouldn't have my BCS today. It's a failing of the *North* American education system at the very least.
I got my counseling when I moved to New Brunswick in 1991 to do my last year of high school; it consisted of, "Oh, you're a Newfie? Definitely want to stay away from our French classes." (New Brunswick is Canada's only bilingual province... I'll leave the Newfie French to your imagination.)
Point being, I said to my dad, "I'm not really sure what to take..." His response, "Well, those computers are getting popular. I bet you'll make some money there." And that, folks, was the end of it. I took my first computer class in Grade 12 ("used my time wisely" on the 8088s in the lab), and went on to graduate with First Class Honours from UNB. Why am I bragging, you ask? I'm not. I just sick of reading all these dumb comments about how these people must love computers. C64s, Vic 20s... I'm not one of those people. I'm in the wrong field, and I'm taking steps to get out of it every day.
Career counseling is *extremely* important because unlike some fields (I'm trying to break into writing, for instance), this field is not very forgiving of "computer lovers" who don't have a technical *degree* (no matter how good they are). It may be more prevalent in gov't than industry, but you can't ignore it. My message is: "Find your path and get on it early."
Dr. Rebecca Mercuri wrote her thesis on mapping Common Criteria (CC) requirements to electronic voting technology. She makes some good points: new security functional requirements must be developed before this technology could be evaluated using the CC; the CC allows for this through the use of extended requirements.
However, I don't agree with her statements regarding the CC and what she calls counter-indications. She states that the CC should provide an explicit mechanism that prevents the inclusion of conflicting requirements, along the lines of forcing authors to include requirement dependencies or rationale for their absence. This is a bit ridiculous in my mind, since the mechanism is the evaluator. It's the security target evaluator's job to confirm that the security requirements are mutually supportive. If they conflict, the security target won't pass the evaluation (and therefore, neither will the product). There's absolutely no need for extra "if you include this, don't include that" spaghetti.
Agreed. FYI, semiformal and formal design specifications come in at the higher assurance levels of the Common Criteria. Semiformal refers to something written in a restricted syntax language (could be natural language) and, as you said, formal uses notation based on mathematical concepts.
EAL5 requires a semiformal functional specification and high-level design (along with other development evidence). A semiformal low-level design is required at EAL6 and formal specifications are required at EAL7.
I agree that all labs and all CC schemes are not created equal, but all schemes must undergo shadow certification by another scheme in the arrangement every 5 years as a minimum (i.e., one scheme sends some certifiers to another scheme to look over their certifiers' shoulders during an EAL3 or EAL4 certification to ensure that all their ducks are in a line).
A subset of the mplementation representation comes in at EAL4 and the evaluators get to pick what code they look at (based on what they find in the high and low level design docs, the user and administrator guidance, etc.).
I don't see why forcing a developer to state what their product does, and then holding them to that is a bad thing. It's up to the consumer to decide whether those security functions fit their needs. It's not like a developer can create their own security functional requirements, state that their product implements them, and receive their certification. It's the responsibility of the labs and their associated certification body to ensure that certified products not only do what they say they do, but also that any explicitly stated security requirements make sense and that their evaluated configurations are useful (i.e., no NT certifications without network connectivity, no PIX certifications without NAT, etc.). So long as they uphold their end of the deal, "poor products" will be excluded. I think it's important to point out that just because a product isn't a silver bullet doesn't mean that it doesn't solve one security problem very well. Of course, integration opens another can of worms...
I agree that a certification isn't worth much if you don't know what it means. I think that's a big advantage of the Common Criteria (CC). While it's a lot to digest, there are guides out there to help you through it.
I work for the Canadian Common Criteria Scheme and it's my job to ensure that the Canadian labs follow the CC correctly and consistently in their evaluations. I found the article invaluable and disturbing (especially the Bruce Schneier quote), since we're obviously looking for ways to promote the CC, and the article highlights the concerns we need to address.
I completely agree. I read one of his interviews last year and picked out an e-mail address. I thought, "What the heck; this guy has had such an impact on my life, I have to thank him."
Nothing big. Just a "I'm not even going to attempt expressing how grateful I am to you for creating all that you have." I mean, for me, it wasn't just D & D (although, that was a huge part of it). The Gord the Rogue books were the first books I read on my own. (Sea of Death, actually... mind you, it took a hell of a long time. Nothing against the book; I hated reading before that. Hard to believe, considering how much I love it now.)
Anyway, the next day he replied, thanking me for my note, and talking about how he's having trouble interesting his son in reading. I was blown away. Adding that chapter to such an important part of my childhood is something I'll always cherish.
They mentioned how he tries to keep on top of his e-mail again in this interview. I wouldn't have put much stock in that statement prior to my own experience. I can't imagine the volume he deals with. I have a hard time staying on top of my own. Genuine (and that describes his replies perfectly) people like Gary are rare.
Did anyone else read this book? I saw an interview with him on CBC a few years ago, when the book first hit the shelves, and I thought it sounded good.
I haven't read any of his books, and I'd like to read the best first:)
My employer purchased the book about 6 months ago on my recommendation. The FAQ and Cederqvist are great, but I thought this was the best way to introduce the office to CVS.
As the review said, when you're asking the technical questions, the answers can be found. I don't think that Fogel was trying to replace Cederqvist on that front.
Slashdot Mirror
It means something to me (I work with the Common Criteria daily), but you do have a point: the certificates don't mean much to the general public beyond being a license to sell to the U.S. government.
I'd just like to point out that, while the Common Criteria (CC) is based on the U.S. Trusted Computer System Evaluation Criteria - the TCSEC, a.k.a. the Orange Book - it's also based on the European ITSEC and the Canadian CTCPEC... It's an international standard, and a common language for the world's security professionals.
Similarly, the Common Evaluation Methodology (CEM), a companion document to the CC, is an internationally-recognized methodology for conducting these evaluations, so that a gov't dept. in France knows exactly what was done in this SUSE evaluation (after they read the security target, anyway) and can make informed decisions based on that. Don't discount this international market: the list of countries that recognize these certificates is growing every year.
Now, on the subject of real security, again I hear what you're saying. These products get certified up to EAL4 (the highest level recognized internationally... We haven't developed the CEM beyond it yet) and you see flaws published every week. I think a big part of this problem is discretionary security versus mandatory (or real, you could say) security. Yes, you can evaluate a set of security funcitonal requirements (e.g., identification and authentication, stored data integrity, etc.), but at the end of the day, if we're trusting the process that's acting on behalf of the user, things are going to go awry. If we can't set an overall policy, regardless of whose in control of the individual processes, are we really secure? In certain environments, yes. That's where the CC is helping today. On the Internet? It could! Really! Mandatory access control and other necessary components are there, in the CC, but no products are claiming them. So where does that leaves us? These products that are getting certified are not secure in the Internet environment, that's where. And forums like this one scoff at the standard, when it's not the problem. It can, and will, in the future, certify SELinux, which does implement real security.
Finally, I just want to mention that the CEM covers more than code reviews. That's certainly part of the development class (ADV), but there's also configuration management requirements, delivery and operational requirements, installation, generation and start-up requirements, guidance document requirements, life-cycle support requirements, testing requirements and vulnerability assessment requirements (that, admittedly, only cover threats of a low attack potential at EAL4... as I said, we've got a ways to go with the methodology before we can certify Internet-secure operating systems).
It doesn't have to conform to a protection profile; that's just an option. The SUSE security target will list all the security functional and assurance requirements (the EAL3 assurance package in this case) that scope the evaluation (the "something," as you say).
Hear, hear! Those creator, designer and inventor sets are excellent, and Lego should be commended for "getting back to their roots," so to speak.
I'll sheepishly point out that Lego's FAQ asks and answers the question I implied above: there is a Windows XP edition of Lego's Movie Maker software available. (Oh, and the FAQ also confirms that, yes, the Studios product line is done.)
That's too bad; I really liked the stuff. I haven't been using it much lately because I upgraded to Windows XP. I even had problems running it on Windows ME... I was hoping to see an upgrade from the 98 version at some point. Doesn't look like that'll happen now.
I'd been noticing a lot of the Studios set in the toy store bargain bins... Oh well, I hear there are other drivers available for the camera, and lots of movie-making software in general, no doubt. Hell, I'll accept a lot if it means Lego will be profitable again.
Actually, he was. He played Don (Anthony) Volpe.
I'd forgetten that Aiello was the other brother... Loved that guy in City Hall...
That was my first thought. Certainly Remail's ability to pull from many different sources (over an array of protocols) is one of Haystack's best features... Speaking as someone who *really* debated installing it, but, in the end, decided to put it off.
As an AC pointed out, if you can't run these systems in parallel for a trial period, it's going to be a tough sell for people who are pretty happy with their mail setup. To be honest, this idea of a conglomeration of content seems to scare people who are comfortable with computers (myself included). Not a bad thing... Just something to keep in mind when you're trying to sell it (as a good idea, I mean, setting aside the whole can of worms that is making money off it).
There's a difference, though. The security target evaluation (at the beginning of the evaluation - it really scopes the evaluation) is a sanity check. The evaluator would certainly fail the ASE components of a concrete lifejacket evaluation. The evaluator is making sure the functional requirements are mutually supportive, that the security problem they're solving is well defined, that the requirements themselves can solve that problem... It's far more than a "This is what I do... See, I'm doing what I say I do."
"Speaking as someone who works for the government"
Well, speaking as someone who works for a government's CC certification scheme, EAL2 actually does give you some assurance, and I've personally seen companies stumble in getting it. At that level, you're taking a closer look at the developer's design, configuration management and testing; you're making sure they conduct a proper vulnerability analysis, and devising your own penetration tests. It's a significant jump from EAL1.
The CC functional requirements are very specific. If two products claim to satisfy an identification requirement (for example) and both pass evaluation, then you have some assurance that they've both correctly implemented it. That assurance is based on the evaluation assurance level. That doesn't mean they're equal, but it sets the lower bound.
Incidentally, any security product can be evaluated under the CC; there are many functional requirements that wouldn't immediately come to mind (e.g., anonymity requirements in the privacy family FPR). Not only that, the CC allows for extensions, so if you can think up the requirements, products can be evaluated against them (although the ST evaluation may fail if your requirements are poorly written).
The Common Criteria are composed of two types of requirements: security functional and security assurance. The requirements are different for each evaluation, so you need to read what's called a security target to find out which ones are relevant to the specific evaluation.
f
For example, Windows 2000 was evaluated against all the security assurance requirements in the EAL4 package (plus a few). There were also a ton of security functional requirements based on what Windows 2000 provides (e.g., identification, authentication, audit, etc.). For details, read the Target of Evaluation Description section of the ST at http://niap.nist.gov/cc-scheme/CCEVS_VID402-ST.pd
Red Hat's Enterprise Linux will have their own ST.
I'm glad to hear it. I've seen many people get entry level positions, but promotion is based on mandatory requirements that pit degrees against huge amounts of experience. It sounds like your progression was fairly smooth, but when you take the person's abilities out of the equation, it means a lot of waiting for that experience window to slide. For example, I've seen these sorts of mandatory requirements far too often:
- a technical degree in the field of CS or engineering and 2 to 4 years of experience in... vs. (no degree and) 6 to 8 years of experience in...
Still others will state:
- a technical degree or equivalent experience...
on paper, but favor university graduates in practice. It bugs me that the employers I've dealt with place so much value on them (despite the benefits I get from such a policy). I guess I've seen too many university graduates who give the rest of us a bad name recently, yet manage to get hired because they have the letters and suck up to the right people. Coop and term positions help to prevent this sort of thing, but less than you might think.
If I'd had it, I guarantee I wouldn't have my BCS today. It's a failing of the *North* American education system at the very least.
I got my counseling when I moved to New Brunswick in 1991 to do my last year of high school; it consisted of, "Oh, you're a Newfie? Definitely want to stay away from our French classes." (New Brunswick is Canada's only bilingual province... I'll leave the Newfie French to your imagination.)
Point being, I said to my dad, "I'm not really sure what to take..." His response, "Well, those computers are getting popular. I bet you'll make some money there." And that, folks, was the end of it. I took my first computer class in Grade 12 ("used my time wisely" on the 8088s in the lab), and went on to graduate with First Class Honours from UNB. Why am I bragging, you ask? I'm not. I just sick of reading all these dumb comments about how these people must love computers. C64s, Vic 20s... I'm not one of those people. I'm in the wrong field, and I'm taking steps to get out of it every day.
Career counseling is *extremely* important because unlike some fields (I'm trying to break into writing, for instance), this field is not very forgiving of "computer lovers" who don't have a technical *degree* (no matter how good they are). It may be more prevalent in gov't than industry, but you can't ignore it. My message is: "Find your path and get on it early."
Dr. Rebecca Mercuri wrote her thesis on mapping Common Criteria (CC) requirements to electronic voting technology. She makes some good points: new security functional requirements must be developed before this technology could be evaluated using the CC; the CC allows for this through the use of extended requirements.
However, I don't agree with her statements regarding the CC and what she calls counter-indications. She states that the CC should provide an explicit mechanism that prevents the inclusion of conflicting requirements, along the lines of forcing authors to include requirement dependencies or rationale for their absence. This is a bit ridiculous in my mind, since the mechanism is the evaluator. It's the security target evaluator's job to confirm that the security requirements are mutually supportive. If they conflict, the security target won't pass the evaluation (and therefore, neither will the product). There's absolutely no need for extra "if you include this, don't include that" spaghetti.
Agreed. FYI, semiformal and formal design specifications come in at the higher assurance levels of the Common Criteria. Semiformal refers to something written in a restricted syntax language (could be natural language) and, as you said, formal uses notation based on mathematical concepts.
EAL5 requires a semiformal functional specification and high-level design (along with other development evidence). A semiformal low-level design is required at EAL6 and formal specifications are required at EAL7.
I agree that all labs and all CC schemes are not created equal, but all schemes must undergo shadow certification by another scheme in the arrangement every 5 years as a minimum (i.e., one scheme sends some certifiers to another scheme to look over their certifiers' shoulders during an EAL3 or EAL4 certification to ensure that all their ducks are in a line).
A subset of the mplementation representation comes in at EAL4 and the evaluators get to pick what code they look at (based on what they find in the high and low level design docs, the user and administrator guidance, etc.).
I don't see why forcing a developer to state what their product does, and then holding them to that is a bad thing. It's up to the consumer to decide whether those security functions fit their needs. It's not like a developer can create their own security functional requirements, state that their product implements them, and receive their certification. It's the responsibility of the labs and their associated certification body to ensure that certified products not only do what they say they do, but also that any explicitly stated security requirements make sense and that their evaluated configurations are useful (i.e., no NT certifications without network connectivity, no PIX certifications without NAT, etc.). So long as they uphold their end of the deal, "poor products" will be excluded. I think it's important to point out that just because a product isn't a silver bullet doesn't mean that it doesn't solve one security problem very well. Of course, integration opens another can of worms...
I agree that a certification isn't worth much if you don't know what it means. I think that's a big advantage of the Common Criteria (CC). While it's a lot to digest, there are guides out there to help you through it.
I work for the Canadian Common Criteria Scheme and it's my job to ensure that the Canadian labs follow the CC correctly and consistently in their evaluations. I found the article invaluable and disturbing (especially the Bruce Schneier quote), since we're obviously looking for ways to promote the CC, and the article highlights the concerns we need to address.
I completely agree. I read one of his interviews last year and picked out an e-mail address. I thought, "What the heck; this guy has had such an impact on my life, I have to thank him."
Nothing big. Just a "I'm not even going to attempt expressing how grateful I am to you for creating all that you have." I mean, for me, it wasn't just D & D (although, that was a huge part of it). The Gord the Rogue books were the first books I read on my own. (Sea of Death, actually... mind you, it took a hell of a long time. Nothing against the book; I hated reading before that. Hard to believe, considering how much I love it now.)
Anyway, the next day he replied, thanking me for my note, and talking about how he's having trouble interesting his son in reading. I was blown away. Adding that chapter to such an important part of my childhood is something I'll always cherish.
They mentioned how he tries to keep on top of his e-mail again in this interview. I wouldn't have put much stock in that statement prior to my own experience. I can't imagine the volume he deals with. I have a hard time staying on top of my own. Genuine (and that describes his replies perfectly) people like Gary are rare.
Cheers,Definitely. Happy endings abound.
Hell, we've seen how they deal with guilt :-)
-Iorek
Gotcha. Scary stuff, no matter what side of the law you're on.
-Iorek
Invita's sole purpose is to entice them to commit a crime. Are you saying the loophole is that Invita could be a legitimate company?
-Iorek
Did they consider any of the ramifications? Entrapment was the first word that popped into my head. Am I missing something? What's the loophole?
-Iorek
Did anyone else read this book? I saw an interview with him on CBC a few years ago, when the book first hit the shelves, and I thought it sounded good.
:)
I haven't read any of his books, and I'd like to read the best first
My employer purchased the book about 6 months ago on my recommendation. The FAQ and Cederqvist are great, but I thought this was the best way to introduce the office to CVS.
As the review said, when you're asking the technical questions, the answers can be found. I don't think that Fogel was trying to replace Cederqvist on that front.